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

[R Vamshi Krishna <vamshi@cse.iitb.ac.in>]

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