[ECOS] AT91SAM7S256 problem with test/example twothreads

[ECOS] AT91SAM7S256 problem with test/example twothreads

[Jesper K. Pedersen]

I am at my wits end getting the twothreads example working on my Olimex
P256 board (AT91SAM7S256 based).

Calling the cyg_mutex_init does not return. Also I notice that the call
to the printf line before the call to cyg_mutex_init prints extremely
slow on my terminal.

I have set the default console up to tty0 going to ser0. This part
works fine with my other software running on the board (normal expected
transmission speed).

Are there any "gotcha'" involving threading on the AT91 series
microcontrollers?

Best regards
JesperKP

Extra info (note I have added a couple of debugging lines):

void cyg_user_start(void)
{
  printf("Entering twothreads' cyg_user_start() function\n\r");

  cyg_mutex_init(&cliblock);

  printf("cyg_mutex_init() done\n\r"); // <--- Never gets sent 

  cyg_thread_create(4, simple_program, (cyg_addrword_t) 0,
		    "Thread A", (void *) stack[0], 4096,
		    &simple_threadA, &thread_s[0]);
  printf("Done setting up ThreadA\n\r");

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

Re: [ECOS] AT91SAM7S256 problem with test/example twothreads

[Jesper K. Pedersen]

On Sun, 17 Jun 2012 16:43:02 +0200
"Jesper K. Pedersen" <linux@famped.dk> wrote:

> I am at my wits end getting the twothreads example working on my
> Olimex P256 board (AT91SAM7S256 based).
> 
> Calling the cyg_mutex_init does not return. Also I notice that the
> call to the printf line before the call to cyg_mutex_init prints
> extremely slow on my terminal.
> 
> I have set the default console up to tty0 going to ser0. This part
> works fine with my other software running on the board (normal
> expected transmission speed).
> 
> Are there any "gotcha'" involving threading on the AT91 series
> microcontrollers?
> 

Problem was solved.

For some reason if you put any output function (printf's) in the
cyg_user_start the threading will hang.

Removing all output will allow for threading and the example works as
expected.

I wonder if this is intended or if its a bug in the A91SAM7 eCos.

Best regards
JesperKP

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

Re: [ECOS] AT91SAM7S256 problem with test/example twothreads

[Lambrecht Jürgen]

On 06/19/2012 03:16 PM, Jesper K. Pedersen wrote:
> On Sun, 17 Jun 2012 16:43:02 +0200
> "Jesper K. Pedersen"<linux@famped.dk>  wrote:
>
>> I am at my wits end getting the twothreads example working on my
>> Olimex P256 board (AT91SAM7S256 based).
>>
>> Calling the cyg_mutex_init does not return. Also I notice that the
>> call to the printf line before the call to cyg_mutex_init prints
>> extremely slow on my terminal.
>>
>> I have set the default console up to tty0 going to ser0. This part
>> works fine with my other software running on the board (normal
>> expected transmission speed).
>>
>> Are there any "gotcha'" involving threading on the AT91 series
>> microcontrollers?
>>
> Problem was solved.
>
> For some reason if you put any output function (printf's) in the
> cyg_user_start the threading will hang.
>
> Removing all output will allow for threading and the example works as
> expected.
>
> I wonder if this is intended or if its a bug in the A91SAM7 eCos.
>
> Best regards
> JesperKP
>
I have lots of diag_printf's in my cyg_user_start() running on an AT91 
ARM7 and a ARM9.
Maybe because you use printf?
Be carefull:  Code running in initialization context runs with 
interrupts disabled and the scheduler locked. Only after cyg_user_start, 
the scheduler starts and resumes all threads.
Maybe (if I remember well; search the list for the diff between both 
printfs) printf uses interrupts (to know when the hardware has sent a 
byte), and diag_printf doesn't.

You must also realize that printf's can take a lot of CPU.

And no, it is certainly not intended or a bug in the ecos CVS code 
(although I don't know the twothreads test): it is your bug ;-) .

Success,
Jürgen

-- 
Jürgen Lambrecht
R&D Associate
Tel: +32 (0)51 303045    Fax: +32 (0)51 310670
http://www.televic-rail.com
Televic Rail NV - Leo Bekaertlaan 1 - 8870 Izegem - Belgium
Company number 0825.539.581 - RPR Kortrijk

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

Re: [ECOS] AT91SAM7S256 problem with test/example twothreads

[Jesper K. Pedersen]

On Tue, 19 Jun 2012 22:18:14 +0200
Lambrecht Jürgen <J.Lambrecht@TELEVIC.com> wrote:

> On 06/19/2012 03:16 PM, Jesper K. Pedersen wrote:
> > On Sun, 17 Jun 2012 16:43:02 +0200
> > "Jesper K. Pedersen"<linux@famped.dk>  wrote:
> >
> >> I am at my wits end getting the twothreads example working on my
> >> Olimex P256 board (AT91SAM7S256 based).
> >>
> >> Calling the cyg_mutex_init does not return. Also I notice that the
> >> call to the printf line before the call to cyg_mutex_init prints
> >> extremely slow on my terminal.
> >>
> >> I have set the default console up to tty0 going to ser0. This part
> >> works fine with my other software running on the board (normal
> >> expected transmission speed).
> >>
> >> Are there any "gotcha'" involving threading on the AT91 series
> >> microcontrollers?
> >>
> > Problem was solved.
> >
> > For some reason if you put any output function (printf's) in the
> > cyg_user_start the threading will hang.
> >
> > Removing all output will allow for threading and the example works
> > as expected.
> >
> > I wonder if this is intended or if its a bug in the A91SAM7 eCos.
> >
> > Best regards
> > JesperKP
> >
> I have lots of diag_printf's in my cyg_user_start() running on an
> AT91 ARM7 and a ARM9.
> Maybe because you use printf?
> Be carefull:  Code running in initialization context runs with 
> interrupts disabled and the scheduler locked. Only after
> cyg_user_start, the scheduler starts and resumes all threads.
> Maybe (if I remember well; search the list for the diff between both 
> printfs) printf uses interrupts (to know when the hardware has sent a 
> byte), and diag_printf doesn't.
> 
> You must also realize that printf's can take a lot of CPU.
> 
> And no, it is certainly not intended or a bug in the ecos CVS code 
> (although I don't know the twothreads test): it is your bug ;-) .
> 

If you look in the ecos-3.0-user-guide.pdf on page 52 "A Sample Program
with Two Threads" it is shown with printf's in the cyg_user_start.

If that is not a correct way to do it - perhaps that example should be
changed? :-D

Best regards
JesperKP

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

RE: [ECOS] AT91SAM7S256 problem with test/example twothreads

[Lambrecht Jürgen]

> -----Original Message-----
> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-
> owner@ecos.sourceware.org] On Behalf Of Jesper K. Pedersen
> Sent: woensdag 20 juni 2012 7:38
> To: ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] AT91SAM7S256 problem with test/example twothreads
> 
> On Tue, 19 Jun 2012 22:18:14 +0200
> Lambrecht Jürgen <J.Lambrecht@TELEVIC.com> wrote:
> 
> > On 06/19/2012 03:16 PM, Jesper K. Pedersen wrote:
> > > On Sun, 17 Jun 2012 16:43:02 +0200
> > > "Jesper K. Pedersen"<linux@famped.dk>  wrote:
> > >
> > >> I am at my wits end getting the twothreads example working on my
> > >> Olimex P256 board (AT91SAM7S256 based).
> > >>
> > >> Calling the cyg_mutex_init does not return. Also I notice that the
> > >> call to the printf line before the call to cyg_mutex_init prints
> > >> extremely slow on my terminal.
> > >>
> > >> I have set the default console up to tty0 going to ser0. This part
> > >> works fine with my other software running on the board (normal
> > >> expected transmission speed).
> > >>
> > >> Are there any "gotcha'" involving threading on the AT91 series
> > >> microcontrollers?
> > >>
> > > Problem was solved.
> > >
> > > For some reason if you put any output function (printf's) in the
> > > cyg_user_start the threading will hang.
> > >
> > > Removing all output will allow for threading and the example works
> > > as expected.
> > >
> > > I wonder if this is intended or if its a bug in the A91SAM7 eCos.
> > >
> > > Best regards
> > > JesperKP
> > >
> > I have lots of diag_printf's in my cyg_user_start() running on an
> > AT91 ARM7 and a ARM9.
> > Maybe because you use printf?
> > Be carefull:  Code running in initialization context runs with
> > interrupts disabled and the scheduler locked. Only after
> > cyg_user_start, the scheduler starts and resumes all threads.
> > Maybe (if I remember well; search the list for the diff between both
> > printfs) printf uses interrupts (to know when the hardware has sent a
> > byte), and diag_printf doesn't.
I have searched the list in your place, and a printf needs interrupts, so indeed, it will not run in cyg_user_start().

> >
> > You must also realize that printf's can take a lot of CPU.
I meant diag_printf's.

> >
> > And no, it is certainly not intended or a bug in the ecos CVS code
> > (although I don't know the twothreads test): it is your bug ;-) .
> >
> 
> If you look in the ecos-3.0-user-guide.pdf on page 52 "A Sample Program
> with Two Threads" it is shown with printf's in the cyg_user_start.
> 
> If that is not a correct way to do it - perhaps that example should be
> changed? :-D
Indeed.
I thought the two-thread example came from CVS ecos sources. But it comes from an example from the user guide. So the writer of it should reply.
The example is wrong, must be diag_printf instead.

Kind regards,
Jürgen
> 
> Best regards
> JesperKP
> 
> --
> Before posting, please read the FAQ:
> http://ecos.sourceware.org/fom/ecos
> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


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