Lpc2000

Hi Robert,

Well you were certainly dean on the money.

It's not completely solved yet, and I do know there is a context

switch issue as well, but these are my findings so far :

> 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.

The RF normally runs at 64 kBps, and the RX INT is a state machine that looks for

preamble, checks the Frame sync header, handles all DLL stuff, including CRC on-the-fly.

It is very important that I don't have overruns. If a char is lost, then the FHSS stuffs up etc.

That puts already quite a bit of demand on RTIOS, as the time spent in the Kernel cannot

be more than just under 2 chars at 64 kBps, or ~ 312 uS.

That was quite a bit of a challenge on MSP430, especially for auto-event handling and

timers.

On ARM it's much more relaxed, but I'm quite new to it.

;

> 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!

The UART operation on LPC2000 is still confusing wrt the TX FIFO.

The UM states that THRE asserts when 2 or more chars are in the FIFO, but then

somewhere else it states that each char asserts it.

That would have explained why I always had a char too many, because the FIFO

only INTs with 2 or more chars on THRE. If that were the case then I'm barking up

the wrong tree with my THRE Handler.

I find the User's manual too vague about it, maybe it's because it's supposed to be

16C550. I've never really programmed PCs and I never want to, so I'm not used

to these UARTs.

If someone can clarify a bit better what the hell the deal is exactly with the TX FIFO,

I'd be grateful. I've googled around on 16C550 till I'm silly, but not much luck

finding a description how exactly the TX FIFO works. Is it a FIFO between THR and

the actual Shift register ? That's my interpretation, but then you still get the same

amount of TX interrupts anyway, just that they're spaced together in time a lot more,

with more gap in between.

I don't see the point, or maybe I just don't get it. The RX, fair enough, that is great

having a FIFO there.

I turned optimisation off, and inserted a write of 0x01 to UOIER before I handle

the buffer or pointer, so THRE interrupt is disabled.

When I started it, the code resets itself in no time.

It's obvious that indeed an atomic operation is needed. I didn't expect that.

And you're dead right about the timing issues, optimisations affect how fast the

execution is, hence the asynchronous timing effect on each other, and that confused

me.

Never had such bloody headaches with this sort of thing.

What a pain.

Now it's pretty much fixed, except that running code still "resets" itself.

I can't work out what's getting trashed where.

I _should_ work now, there are no other coding issues wrt multiple access,

but it doesn't.

Oh, well I'll be off the streets for a bit.

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

I'm gonna need it !

All the best,

Kris