This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Alarms and Threads Program Problem :: Help Required



I too use Linux (FC3) ;-)


But what I am doing is I use floppy to boot the target pc.
Then I use TFTP protocol to download the application onto
the target from the host.

So I have not as yet used minicom.
Also the application is meant for a miniature vehicle.

So it would not have connection to any PC.

The target must itself send Diagnostic messages + our own
messages for offline interpretation.


I would like to use a USB pen-drive for this. Mine is 2.0 USB compliant but I am not clear of the terminilogy used in eCos docs.

Can anyone guide me. What do I need to implement? Do I have to write a specific driver or use default driver ??

Thanking you,

-- Vamshi




On Mon, 22 Aug 2005, Gary Thomas wrote:


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.



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]