This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Alarms and Threads Program Problem :: Help Required
- From: Gary Thomas <gary at mlbassoc dot com>
- To: "R. Vamshi Krishna" <vamshi at cse dot iitb dot ac dot in>
- Cc: ecos-discuss at sources dot redhat dot com
- Date: Mon, 22 Aug 2005 06:08:00 -0600
- Subject: Re: [ECOS] Alarms and Threads Program Problem :: Help Required
- References: <43063125.10200@cse.iitb.ac.in>
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