Hi Scott,
Thanks for the additional information.
I am kind of wishing I had not gone with this board now as there are just too
many issues with it in regards to doing things in DynamicC. It is a shame really
as the XGraph boards are nicely priced and are let down by this poor
compiler.
I am working on a 7" LCD display for the Netburner and once this is working this
will become my platform of choice. There is a newer 250Mhz Netburner on the
horizon so I will see how that goes.
I am also playing with the Atmel AVR32 and although the documentation on the
compiler is very thin, the code seems to work well and the processors have a lot
of potential and power. These once I am fully familiar with them will become my
processor of choice. Price wise they are actually cheaper from my regular
supplier than the ATMega devices.
Rabbit desperately need a new compiler and I just don't see this happening
in the near or distant future. For simple task applications they are fine but
they fall over when you start to want to do something more complex.
Daveā¦
From: r... [mailto:r...] On Behalf Of Scott Henion
Sent: 11 November 2011 12:27
To: r...
Subject: Re: [rabbit-semi] Re: Strange UCOS behavior
The problem with the rabbit is it is slow and some of the hardware can not
handle much interrupt latency. Serial ports are one, Ports A-D have no FIFO so
interrupts have to be processed in one character time or characters are lost.
Ports E-F do have a 4-byte FIFO, so they are less of an issue.
uCOS is written in C and with DC's inefficient compiler, it spends a lot of
time in the OS. Interrupts that don't use OS calls should not need any
change. They can enable interrupts if they can guarantee they will finish before
the next interrupt. Not the case if multiple devices use the same interrupt
level.
The Netburner is an order of a magnitude faster and the compiler generates much
better code, so there is less of a problem. I've moved on to PIC32 to have
much more speed (and much cheaper hardware.) I have also used the Netburner
modules with success but am not sure on their future.
There has long been bugs in the uCOS support in DC. When porting the stack to
Softools, we found unbalanced semaphore calls. Later libraries seem to ignore
uCOS even exists. The debugger seems to have real issues with it, had to make
sure all debugging in the PPP code was turned off.
We basically did not use uCOS with Softools. I used the CoExec task switcher
(works in DC 9.x also) and users that needed hard real-time used Turbotask.
I bought the uCOS book back when it came out. The disk has sat unused. It looked
overly complicated for low-end processors.
--
------
Scott G. Henion, Consultant
Strange UCOS behavior
Started by ●October 31, 2011
Reply by ●November 11, 20112011-11-11