At 01:49 PM 1/27/05 +1000, you wrote:
>I have to say that the UART solution is the easiest and the best
>although it's a pity that Philips implemented a PC style UART on the ARM
>(no 9-bit mode). But with the 16-byte FIFO it does take some of the load
>off the CPU. The SPI approach suffers for many reasons, mainly because
>there are no buffers and so incurs a high overhead. But never rule it
>out, do your sums first, it may be fine in your app.
You can do 9 bit on a 16550 (at least a real one) using a technique I've
seen referred to as parity modulation. The ideas is to use 8 bit with mark
or space parity. You set up the UART to interrupt on a parity violation
and then set it to space parity. When you receive a character with mark
parity you get an interrupt and that's your 'address' byte. Just as with
normal 9 bit you can then switch receive all characters if selected or just
wait for the next parity violation.
I may have the sense of whether to use mark and space backwards, it's been
a while. And I have no idea if the nearly compatible UART in the LPC's can
do it or not.
If the lines stay on board I'd certain consider SPI, but I'm always
reluctant to run TTL signals off board unprotected. You could use 232 or
485 style drivers I suppose but at that point you might as well use the
UART and save the select pins.
>CAN is ideal for this application but unfortunately the 932s don't have
>them.
Depending on what you need to pass around another automotive derived
signalling spec to look at is LIN, fewer wires and less communications
capability (lower baud, fewer and smaller packets) than CAN.
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