[ECOS] Alarms and Threads Program Problem :: Help Required

[R. Vamshi Krishna]

Hello,

First I wanted to say that I inadvertantly sent the mail only to Gary.
So here I am forwarding it to ecos-discuss.

- Vamshi.


R. Vamshi Krishna wrote:


Thank You very much.
I too was able to run it here.

Can u tell me how u were able to capture the o/p of the execution.

Can we use a USB pen-drive to capture the diagnostic messages.
If yes then how ?

I want to be able to see the diagnostic messages offline.

- Vamshi


Gary Thomas wrote:

On Thu, 2005-08-18 at 22:09 +0530, R. Vamshi Krishna wrote:
 

> Hello,
>
> I am trying to write a program that has 3 threads executing for 1,2,1 
> seconds each.
> These threads must each execute every 5,6,4 seconds respectively.
>
> (Actually in Program I have multiplied these by a factor of 40 ).
>
> I have tried the following program. One might expect the timing to get 
> screwed up, but
> actually the application hangs after saying the following :
>
> "Thread 2A :: Time Before Execution is 1"
> hal_isr_default(33) : data (0)
> "Thread 2A :: Time After Execution is 27"
> "Thread 3 finished at :: 27"
>
> Then I get something like
> $..thread .. and some weird numbers ...
>   



This means that your code crashed and GDB is trying to tell you why.

 

> PS : Note that  it is  Thread  3 that says it is finishing.
>   



Which if you read your code, just means that thread 3's alarm went
off before it had a chance to actually execute.

 

> Can someone tell me where am I going wrong ??
>
> - Vamshi
>
> Misc Data :
>    - Using Bitmap Scheduler
>    - Template is Kernel
>    - Turned Cache Off
>    - i386 Target with Realtek NIC card.
>   



A few questions/observations:
 * Are you sure that the stack size of 4096 is adequate?  There are HAL
   defines for these which would be much safer to use.
 * Whenever you have a number of threads trying to print on the
   console, you can get scrambled results.  There are many ways around
   this, but if you want to print from DSR context (your alarm    
functions run in DSR context), you'll need special protection.
 * Hard coding your loops, etc, is fraught with problems.  You can
   easily compute these things at runtime.

I made a few modifications to your code (none that changed your basic
code, just some improvements) and it runs just fine on my platform.
The modified version is attached - perhaps you want to try it.

Here are the first few lines of output:

Thread 1A :: Time Before Processing :: is 3
Thread 1A :: Time After Processing :: 44
Thread 2A :: Time Before Processing is 44 Thread 2A :: Time After 
Processing is 125 Thread 3A :: Time Before Processing is 126 Thread 3A 
:: Time After Processing is 167 Thread 1 finished at :: 203 Thread 1A :: 
Time Before Processing :: is 203
Thread 1A :: Time After Processing :: 244
Thread 2 finished at :: 284 Thread 2A :: Time Before Processing is 284 
Thread 3 finished at :: 286 Thread 2A :: Time After Processing is 365 
Thread 3A :: Time Before Processing is 366 Thread 1 finished at :: 403 
Thread 1A :: Time Before Processing :: is 403
Thread 1A :: Time After Processing :: 444
Thread 3 finished at :: 446 Thread 3A :: Time After Processing is 450 
Thread 3A :: Time Before Processing is 450 Thread 3A :: Time After 
Processing is 491 Thread 2 finished at :: 524 Thread 2A :: Time Before 
Processing is 524 Thread 1 finished at :: 603 Thread 1A :: Time Before 
Processing :: is 603
Thread 3 finished at :: 606 Thread 1A :: Time After Processing :: 644
Thread 2A :: Time After Processing is 648 Thread 3A :: Time Before 
Processing is 648 Thread 3A :: Time After Processing is 689
It kept running happily until I killed it.

Note that you're not getting exactly the thread behaviour
that you specified.  This is because of thread priorities
and preemptive scheduling.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss