Lpc2000

Hey all.

Well, I built a toolchain for Linux, downloaded and installed newlib
and newlib-lpc.  To get it all working I created a file sys_isatty.c
which defines int isatty(int i) { return 1 }.  Then I got uart0_int
working properly for writing and made it asynchronous to speed things
up a bit.

But, heres the problem: I cannot use write() or read() directly on
either com1 or com1_int.  When I do a write(stdout, "HI!",
sizeof("HI!"));  it locks up on me completely.

Has anyone gotten newlib-lpc read() and write() working properly?

-Jake

Quoting ourslandj <xmm0@...>:
> Well, I built a toolchain for Linux, downloaded and installed newlib
> and newlib-lpc.  To get it all working I created a file sys_isatty.c
> which defines int isatty(int i) { return 1 }.  Then I got uart0_int
> working properly for writing and made it asynchronous to speed things
> up a bit.
>
> But, heres the problem: I cannot use write() or read() directly on
> either com1 or com1_int.  When I do a write(stdout, "HI!",
> sizeof("HI!"));  it locks up on me completely.

Are you making the ioctl calls to set up the interrupts?

Robert

--- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
>
> Quoting ourslandj <xmm0@...>:
> > Well, I built a toolchain for Linux, downloaded and installed newlib
> > and newlib-lpc.  To get it all working I created a file sys_isatty.c
> > which defines int isatty(int i) { return 1 }.  Then I got uart0_int
> > working properly for writing and made it asynchronous to speed things
> > up a bit.
> >
> > But, heres the problem: I cannot use write() or read() directly on
> > either com1 or com1_int.  When I do a write(stdout, "HI!",
> > sizeof("HI!"));  it locks up on me completely.
> 
> Are you making the ioctl calls to set up the interrupts?
> 
> Robert
>

Thanks for the rapid response!!!

Yessir.

I turned on -Wall (I thought I already had!) well, it pointed out that
I was making a pointer to an int by using write(stdout.....) instead
of write(fileno(stdout)... 

So, that pretty much solved that problem.  Boy, do I feel like an idiot.

Anyhow, I encountered a race condition with test10.c if I make the
output more than the size of the send_buffer (32).  Do you also get
that?  I made a solution and if you'd like I'd be more than happy to
contribute!

Quoting ourslandj <xmm0@...>:
> --- In lpc2000@yahoogroups.com, Robert Adsett <subscriptions@...> wrote:
>> Quoting ourslandj <xmm0@...>:
>> > But, heres the problem: I cannot use write() or read() directly on
>> > either com1 or com1_int.  When I do a write(stdout, "HI!",
>> > sizeof("HI!"));  it locks up on me completely.
>>
>> Are you making the ioctl calls to set up the interrupts?
>>
> Thanks for the rapid response!!!

Glad to help when I can.

> Yessir.
>
> I turned on -Wall (I thought I already had!) well, it pointed out that
> I was making a pointer to an int by using write(stdout.....) instead
> of write(fileno(stdout)...
>
> So, that pretty much solved that problem.  Boy, do I feel like an idiot.

It happens to all of us from time to time.

> Anyhow, I encountered a race condition with test10.c if I make the
> output more than the size of the send_buffer (32).  Do you also get
> that?  I made a solution and if you'd like I'd be more than happy to
> contribute!

I'll have to check.  I'm away from the source until later today but I'll check
then.  In the meantime please do send on the fix (Use the links on the
website).  I'll incorporate it and credit you as soon as I can test it.
  A race
condition is worth fixing immediately and I should have the few minutes needed
to check that out tonight.

Robert

At 11:12 AM 3/8/06 -0500, Robert Adsett wrote:
>Quoting ourslandj <xmm0@...>:
> > Anyhow, I encountered a race condition with test10.c if I make the
> > output more than the size of the send_buffer (32).  Do you also get
> > that?  I made a solution and if you'd like I'd be more than happy to
> > contribute!
>
>I'll have to check.  I'm away from the source until later today but I'll check
>then.  In the meantime please do send on the fix (Use the links on the
>website).  I'll incorporate it and credit you as soon as I can test it.
>   A race
>condition is worth fixing immediately and I should have the few minutes needed
>to check that out tonight.

As promised Jacob sent along his changes and I went over them and reviewed 
his symptoms.  With his help I think we've traced down the root cause.

It turns out not to be a race condition.  At least not a race condition in 
the software, I have a sneaking suspicion that underlying cause of one of 
the needed fixes is a HW race.

One fix is to turn on the FIFO even though it's not used.  Back when I 
originally wrote this driver I missed the note to the effect that the FIFO 
was necessary.  I ran into a problem that I 'fixed' by only servicing a 
single serial interrupt source per interrupt.  I was never comfortable with 
that fix and there is a note in the source about there being a possible 
undocumented HW race condition.  Since this appears that this change may 
fix the problem I will probably go back and re-address the interrupt 
service to make it more conventional.

The second bug was that I embarrassingly left off the volatile modifier in 
a number of places. Sheesh.

Update is available as release 5a at 
http://www.aeolusdevelopment.com/Articles/download.html

Thanks Jacob, much appreciated.

Robert

" 'Freedom' has no meaning of itself.  There are always restrictions,   be 
they legal, genetic, or physical.  If you don't believe me, try to chew a 
radio signal. "  -- Kelvin Throop, III
http://www.aeolusdevelopment.com/