Strange UCOS behavior

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 Start a New Thread