* Re: [ECOS] Alarms and Threads Program Problem :: Help Required
@ 2005-08-19 19:19 R. Vamshi Krishna
2005-08-22 12:09 ` Gary Thomas
0 siblings, 1 reply; 6+ messages in thread
From: R. Vamshi Krishna @ 2005-08-19 19:19 UTC (permalink / raw)
To: ecos-discuss
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 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Alarms and Threads Program Problem :: Help Required
2005-08-19 19:19 [ECOS] Alarms and Threads Program Problem :: Help Required R. Vamshi Krishna
@ 2005-08-22 12:09 ` Gary Thomas
2005-08-22 13:55 ` R Vamshi Krishna
0 siblings, 1 reply; 6+ messages in thread
From: Gary Thomas @ 2005-08-22 12:09 UTC (permalink / raw)
To: R. Vamshi Krishna; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Alarms and Threads Program Problem :: Help Required
2005-08-22 12:09 ` Gary Thomas
@ 2005-08-22 13:55 ` R Vamshi Krishna
[not found] ` <1124720053.28508.39.camel@hermes>
0 siblings, 1 reply; 6+ messages in thread
From: R Vamshi Krishna @ 2005-08-22 13:55 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Alarms and Threads Program Problem :: Help Required
[not found] ` <1124720053.28508.39.camel@hermes>
@ 2005-08-22 14:28 ` R Vamshi Krishna
0 siblings, 0 replies; 6+ messages in thread
From: R Vamshi Krishna @ 2005-08-22 14:28 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [ECOS] Alarms and Threads Program Problem :: Help Required
2005-08-18 16:38 R. Vamshi Krishna
@ 2005-08-18 17:43 ` Gary Thomas
0 siblings, 0 replies; 6+ messages in thread
From: Gary Thomas @ 2005-08-18 17:43 UTC (permalink / raw)
To: R. Vamshi Krishna; +Cc: eCos Discussion
[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]
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
------------------------------------------------------------
[-- Attachment #2: alarm-test.c --]
[-- Type: text/x-csrc, Size: 6040 bytes --]
#include <cyg/kernel/kapi.h>
#include <stdio.h>
#include <stdlib.h>
#include <cyg/infra/diag.h>
#include <cyg/hal/hal_arch.h>
#define RVK 40
/*
Thread Data-Structure for 3 threads.
*/
cyg_thread thread_s[3];
/*
Stack Space for 3 threads
*/
char stack[3][CYGNUM_HAL_STACK_SIZE_TYPICAL];
/*
Handles for threads.
Also thread entry functions
*/
cyg_handle_t modeA_thread1, modeA_thread2, modeA_thread3;
cyg_thread_entry_t thread1A_entry, thread2A_entry, thread3A_entry;
/*
Forward-Definition of functions
*/
void thread1A_alarm_func(cyg_handle_t, cyg_addrword_t);
void thread2A_alarm_func(cyg_handle_t, cyg_addrword_t);
void thread3A_alarm_func(cyg_handle_t, cyg_addrword_t);
/*
Alarms and Counters related Data Structures
*/
cyg_handle_t thread_counter[3], system_clockH[3], thread_alarmH[3];
cyg_alarm thread_alarm[3];
void
safe_printf(char *fmt, ...)
{
CYG_INTERRUPT_STATE old_intr;
va_list ap;
HAL_DISABLE_INTERRUPTS(old_intr);
va_start(ap, fmt);
diag_vprintf(fmt, ap);
HAL_RESTORE_INTERRUPTS(old_intr);
}
int loops_per_tick;
void
init_loops_per_tick(void)
{
int old_ticks, new_ticks;
int j;
if (loops_per_tick != 0) return;
loops_per_tick = 0;
old_ticks = (int) cyg_current_time();
// Wait for time to roll
while ((new_ticks = (int)cyg_current_time()) == old_ticks) ;
// Now, see how many loops can happen before the next tick
old_ticks = new_ticks;
// Wait for time to roll
while ((new_ticks = (int)cyg_current_time()) == old_ticks) {
for (j = 0; j < 10000; j++) ;
loops_per_tick++;
}
safe_printf("%d loops per tick\n", loops_per_tick);
}
/*
Kernel Flags
*/
cyg_flag_t flag[3];
/*
Starting the application.
*/
void cyg_user_start(void)
{
/*
Create 3 threads 1A, 2A, 3A .
*/
cyg_thread_create(3,thread1A_entry,(cyg_addrword_t) 0,"Mode A thread 1",
(void *) stack[0],CYGNUM_HAL_STACK_SIZE_TYPICAL,&modeA_thread1,&thread_s[0]);
cyg_thread_create(4,thread2A_entry,(cyg_addrword_t) 0,"Mode A thread 2",
(void *) stack[1],CYGNUM_HAL_STACK_SIZE_TYPICAL,&modeA_thread2,&thread_s[1]);
cyg_thread_create(5,thread3A_entry,(cyg_addrword_t) 0,"Mode A thread 3",
(void *) stack[2],CYGNUM_HAL_STACK_SIZE_TYPICAL,&modeA_thread3,&thread_s[2]);
/*
Intialize the Kernel Flags
*/
cyg_flag_init(&flag[0]);
cyg_flag_init(&flag[1]);
cyg_flag_init(&flag[2]);
/*
Initialize the alarms
Period of each thread is (200/240/120) ticks of real-time clock.
*/
cyg_thread_resume(modeA_thread1);
cyg_thread_resume(modeA_thread2);
cyg_thread_resume(modeA_thread3);
}
void thread1A_entry(cyg_addrword_t data)
{
int i,j;
init_loops_per_tick();
system_clockH[0] = cyg_real_time_clock();
cyg_clock_to_counter(system_clockH[0], &thread_counter[0]);
cyg_alarm_create(thread_counter[0],thread1A_alarm_func,
(cyg_addrword_t) 0, &thread_alarmH[0], &thread_alarm[0]);
cyg_alarm_initialize(thread_alarmH[0],cyg_current_time()+200,200);
for(;;)
{
/*
The following code executes for 40 ticks (approx) .
This was determined experimentally.
*/
safe_printf("Thread 1A :: Time Before Processing :: is %u\n",
(unsigned int) cyg_current_time());
for(i=0;i<40*loops_per_tick;i++)
{
for(j=0;j<10000;j++)
{
;
}
}
safe_printf("Thread 1A :: Time After Processing :: %u\n",
(unsigned int) cyg_current_time());
/*
Wait for Kernel Flag to Signal.
*/
cyg_flag_wait(&flag[0],0x1,
CYG_FLAG_WAITMODE_AND | CYG_FLAG_WAITMODE_CLR);
}
}
void thread2A_entry(cyg_addrword_t data)
{
int i,j;
init_loops_per_tick();
system_clockH[1] = cyg_real_time_clock();
cyg_clock_to_counter(system_clockH[1], &thread_counter[1]);
cyg_alarm_create(thread_counter[1],thread2A_alarm_func,
(cyg_addrword_t) 0, &thread_alarmH[1], &thread_alarm[1]);
cyg_alarm_initialize(thread_alarmH[1],cyg_current_time()+240,240);
for(;;)
{
/*
The following code executes for 80 ticks (approx) .
This was determined experimentally.
*/
safe_printf("Thread 2A :: Time Before Processing is %u \n",
(unsigned int) cyg_current_time());
for(i=0;i<80*loops_per_tick;i++)
{
for(j=0;j<10000;j++)
{
;
}
}
safe_printf("Thread 2A :: Time After Processing is %u \n", (unsigned int) cyg_current_time());
/*
Wait for Kernel Flag to Signal.
*/
cyg_flag_wait(&flag[1],0x1,
CYG_FLAG_WAITMODE_AND | CYG_FLAG_WAITMODE_CLR);
}
}
void thread3A_entry(cyg_addrword_t data)
{
int i,j;
init_loops_per_tick();
system_clockH[2] = cyg_real_time_clock();
cyg_clock_to_counter(system_clockH[2], &thread_counter[2]);
cyg_alarm_create(thread_counter[2],thread3A_alarm_func,
(cyg_addrword_t) 0, &thread_alarmH[2], &thread_alarm[2]);
cyg_alarm_initialize(thread_alarmH[2],cyg_current_time()+160,160);
for(;;)
{
/*
The following code executes for 40 ticks (approx) .
This was determined experimentally.
*/
safe_printf("Thread 3A :: Time Before Processing is %u \n",
(unsigned int) cyg_current_time());
for(i=0;i<40*loops_per_tick;i++)
{
for(j=0;j<10000;j++)
{
;
}
}
safe_printf("Thread 3A :: Time After Processing is %u \n",
(unsigned int) cyg_current_time());
/*
Wait for Kernel Flag to Signal.
*/
cyg_flag_wait(&flag[2],0x1,
CYG_FLAG_WAITMODE_AND | CYG_FLAG_WAITMODE_CLR);
}
}
/*
Alarm-Handlers that suspend the various threads.
*/
void thread1A_alarm_func(cyg_handle_t alarm, cyg_addrword_t data)
{
safe_printf("Thread 1 finished at :: %u \n",
(unsigned int) cyg_current_time());
cyg_flag_setbits(&flag[0], 0x1);
}
void thread2A_alarm_func(cyg_handle_t alarm, cyg_addrword_t data)
{
safe_printf("Thread 2 finished at :: %u \n",
(unsigned int) cyg_current_time());
cyg_flag_setbits(&flag[1], 0x1);
}
void thread3A_alarm_func(cyg_handle_t alarm, cyg_addrword_t data)
{
safe_printf("Thread 3 finished at :: %u \n",
(unsigned int) cyg_current_time());
cyg_flag_setbits(&flag[2], 0x1);
}
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
* [ECOS] Alarms and Threads Program Problem :: Help Required
@ 2005-08-18 16:38 R. Vamshi Krishna
2005-08-18 17:43 ` Gary Thomas
0 siblings, 1 reply; 6+ messages in thread
From: R. Vamshi Krishna @ 2005-08-18 16:38 UTC (permalink / raw)
To: ecos-dicscuss; +Cc: ecos-discuss
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
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 ...
PS : Note that it is Thread 3 that says it is finishing.
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.
[-- Attachment #2: alarm-test.c --]
[-- Type: text/x-csrc, Size: 4934 bytes --]
#include <cyg/kernel/kapi.h>
#include <stdio.h>
#include <stdlib.h>
#define RVK 40
/*
Thread Data-Structure for 3 threads.
*/
cyg_thread thread_s[3];
/*
Stack Space for 3 threads
*/
char stack[3][4096];
/*
Handles for threads.
Also thread entry functions
*/
cyg_handle_t modeA_thread1, modeA_thread2, modeA_thread3;
cyg_thread_entry_t thread1A_entry, thread2A_entry, thread3A_entry;
/*
Forward-Definition of functions
*/
void thread1A_alarm_func(cyg_handle_t, cyg_addrword_t);
void thread2A_alarm_func(cyg_handle_t, cyg_addrword_t);
void thread3A_alarm_func(cyg_handle_t, cyg_addrword_t);
/*
Alarms and Counters related Data Structures
*/
cyg_handle_t thread_counter[3], system_clockH[3], thread_alarmH[3];
cyg_alarm thread_alarm[3];
/*
Kernel Flags
*/
cyg_flag_t flag[3];
/*
Starting the application.
*/
void cyg_user_start(void)
{
/*
Create 3 threads 1A, 2A, 3A .
*/
cyg_thread_create(6,thread1A_entry,(cyg_addrword_t) 0,"Mode A thread 1",
(void *) stack[0],4096,&modeA_thread1,&thread_s[0]);
cyg_thread_create(4,thread2A_entry,(cyg_addrword_t) 0,"Mode A thread 2",
(void *) stack[1],4096,&modeA_thread2,&thread_s[1]);
cyg_thread_create(5,thread3A_entry,(cyg_addrword_t) 0,"Mode A thread 3",
(void *) stack[2],4096,&modeA_thread3,&thread_s[2]);
/*
Intialize the Kernel Flags
*/
cyg_flag_init(&flag[0]);
cyg_flag_init(&flag[1]);
cyg_flag_init(&flag[2]);
/*
Initialize the alarms
Period of each thread is (200/240/120) ticks of real-time clock.
*/
cyg_thread_resume(modeA_thread1);
cyg_thread_resume(modeA_thread2);
cyg_thread_resume(modeA_thread3);
}
void thread1A_entry(cyg_addrword_t data)
{
int i,j,temp;
system_clockH[0] = cyg_real_time_clock();
cyg_clock_to_counter(system_clockH[0], &thread_counter[0]);
cyg_alarm_create(thread_counter[0],thread1A_alarm_func,
(cyg_addrword_t) 0, &thread_alarmH[0], &thread_alarm[0]);
cyg_alarm_initialize(thread_alarmH[0],cyg_current_time()+200,200);
for(;;)
{
/*
The following code executes for 40 ticks (approx) .
This was determined experimentally.
*/
diag_printf("Thread 1A :: Time Before Processing :: is %u\n",
(unsigned int) cyg_current_time());
for(i=0;i<4600;i++)
{
for(j=0;j<10000;j++)
{
;
}
}
diag_printf("Thread 1A :: Time After Processing :: %u\n",
(unsigned int) cyg_current_time());
/*
Wait for Kernel Flag to Signal.
*/
cyg_flag_wait(&flag[0],0x1,
CYG_FLAG_WAITMODE_AND | CYG_FLAG_WAITMODE_CLR);
}
}
void thread2A_entry(cyg_addrword_t data)
{
int i,j;
system_clockH[1] = cyg_real_time_clock();
cyg_clock_to_counter(system_clockH[1], &thread_counter[1]);
cyg_alarm_create(thread_counter[1],thread2A_alarm_func,
(cyg_addrword_t) 0, &thread_alarmH[1], &thread_alarm[1]);
cyg_alarm_initialize(thread_alarmH[1],cyg_current_time()+240,240);
for(;;)
{
/*
The following code executes for 80 ticks (approx) .
This was determined experimentally.
*/
diag_printf("Thread 2A :: Time Before Processing is %u \n",
(unsigned int) cyg_current_time());
for(i=0;i<9206;i++)
{
for(j=0;j<10000;j++)
{
;
}
}
diag_printf("Thread A2 :: Time After Processing is %u \n", (unsigned int) cyg_current_time());
/*
Wait for Kernel Flag to Signal.
*/
cyg_flag_wait(&flag[1],0x1,
CYG_FLAG_WAITMODE_AND | CYG_FLAG_WAITMODE_CLR);
}
}
void thread3A_entry(cyg_addrword_t data)
{
int i,j;
system_clockH[2] = cyg_real_time_clock();
cyg_clock_to_counter(system_clockH[2], &thread_counter[2]);
cyg_alarm_create(thread_counter[2],thread3A_alarm_func,
(cyg_addrword_t) 0, &thread_alarmH[2], &thread_alarm[2]);
cyg_alarm_initialize(thread_alarmH[2],cyg_current_time()+160,160);
for(;;)
{
/*
The following code executes for 40 ticks (approx) .
This was determined experimentally.
*/
diag_printf("Thread 3A :: Time Before Processing is %u \n",
(unsigned int) cyg_current_time());
for(i=0;i<4600;i++)
{
for(j=0;j<10000;j++)
{
;
}
}
diag_printf("Thread 3A :: Time After Processing is %u \n",
(unsigned int) cyg_current_time());
/*
Wait for Kernel Flag to Signal.
*/
cyg_flag_wait(&flag[2],0x1,
CYG_FLAG_WAITMODE_AND | CYG_FLAG_WAITMODE_CLR);
}
}
/*
Alarm-Handlers that suspend the various threads.
*/
void thread1A_alarm_func(cyg_handle_t alarm, cyg_addrword_t data)
{
diag_printf("Thread 1 finished at :: %u \n",
(unsigned int) cyg_current_time());
cyg_flag_setbits(&flag[0], 0x1);
}
void thread2A_alarm_func(cyg_handle_t alarm, cyg_addrword_t data)
{
diag_printf("Thread 2 finished at :: %u \n",
(unsigned int) cyg_current_time());
cyg_flag_setbits(&flag[1], 0x1);
}
void thread3A_alarm_func(cyg_handle_t alarm, cyg_addrword_t data)
{
diag_printf("Thread 3 finished at :: %u \n",
(unsigned int) cyg_current_time());
cyg_flag_setbits(&flag[2], 0x1);
}
[-- Attachment #3: Type: text/plain, Size: 148 bytes --]
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-08-22 14:28 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-08-19 19:19 [ECOS] Alarms and Threads Program Problem :: Help Required R. Vamshi Krishna
2005-08-22 12:09 ` Gary Thomas
2005-08-22 13:55 ` R Vamshi Krishna
[not found] ` <1124720053.28508.39.camel@hermes>
2005-08-22 14:28 ` R Vamshi Krishna
-- strict thread matches above, loose matches on Subject: below --
2005-08-18 16:38 R. Vamshi Krishna
2005-08-18 17:43 ` Gary Thomas
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).