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

[Gary Thomas <gary at mlbassoc dot com>]

On Sat, 2005-08-20 at 00:51 +0530, R. Vamshi Krishna wrote:
> 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 use Linux :-)  It's a simple case of telling minicom to log the data
to a file, then cut & paste.  This eCos application only knows about
simple, diagnostic, I/O which in this case goes to the serial port.
You have to capture the serial data outside of the application. 

I'm sure that you can find a way to do this (even on Windows).  If
not, start running on Linux :-)

> 
> 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.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


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