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

[R Vamshi Krishna]

Thank You.
I will surely try using serial connection.

-- Vamshi

On Mon, 22 Aug 2005, Gary Thomas wrote:

> On Mon, 2005-08-22 at 19:24 +0530, R Vamshi Krishna wrote:
>> 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 ??
>
> There is no support in eCos for host USB (which is what you would
> need for this).  Use a serial connection instead of the screen.
>
>>
>> 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