Lpc2000

At 07:22 PM 2/18/04 +1100, you wrote:

<snip>
>
>The large (sort of) buffer is the minimum needed to create a pseudo-full
>duplex RS232 wireless link between 2 nodes. While data is being serviced on
>the RF in one direction, the other side's RS232 RX buffer can fill up, and 
>compensate
>for the Half Duplex nature and Line Turn Around delays.
>When it's in Binary mode, the scheme above isn't used, the buffer is 
>filled up,
>and then the INTs are enabled, so the CPU can spend most of its time doing 
>other
>things. RTS/CTS is used there.
>And yes, afterwards my own small but fast RTOS will be plugged back in, so 
>I'll use
>counting semaphores to handle the ring buffers.

I knew there had to be a reason :)  Half duplex buffering makes a lot of sense.

>
> > That raises a bunch of design issues to mind.  Why such a large gap?  Why
> > not add to buffer as soon as any room is available?  And finally why two
> > different variables to keep track of the room in the ring buffer?
>Partially as above, the large gap is there to reduce CPU loading, if too 
>much data
>is being written too fast into the ring buffer.
>I find using a Head and a Tail more convenient to manage, rather than 
>having to
>reset the pointer all the time, it's also easier to do the ground work w/o 
>the RTOS,
>but have the whole system built up so it's easy to assign tasks and only 
>change the
>"foreground" code, then _actually_ being foreground code instead of some 
>sort of
>a superloop. The dead CPU time is then being used better. I'm trying to 
>optimise
>what will be in what task, and minimise # of tasks, because many full 
>featured OSs
>reschedule as slow as buggery. Latency issues galore then.

OK, I see what you are after here.  Makes sense.  Most of the serial work 
I've done has had serial as a low priority compared to the rest of the code 
(It's more important for the machine to run than for it to communicate text 
to someone).  That being the case it would only poll during dead time 
anyway.  I have done CAN and other network machine comms where that wasn't 
the case though.

<snip>
>That's a very good point you make Robert.
>I will make sure TX INTs are disabled when I modify tx_chars.
>I've had it sitting there dumping data out while executing Basic for 
>hours, and it ran
>with no problems, whereas a specific Basic program caused it to hang in 
>that "loop"
>within 30-40 secs at the most.
I have seen that sort of behaviour with access control issues.  Changing 
unrelated code changes the observed behaviour.  The messiest I've run into 
was a problem with a third party RTOS that took some time to find (mostly 
because of chip bugs).  The problem ended up being a sequence that worked 
only if compiler optimization was on above a certain level.  Amazingly 
enough the RTOS company claimed it wasn't a bug (and had no intention of 
changing it) since it worked fine with optimization on!

>It must be a library call somewhere that messes up something.

Uggh, wild pointer or library re-enabling interrupts or ...   Good luck.


" '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