Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: [lpc2000] Best solution for multiMCU comm

2005-01-27 by Peter Jakacki

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.

For a hardware interface I would not bother with diodes and pullups but 
rather tie the rx and tx lines together on the CPU and then couple this 
to a common coms bus through a current limiting resistor (say 100 - 
220ohms) for those recalcitrant nodes. A very light pullup will be 
needed to keep the line high when inactive. You can always disable the 
transmitter output when listening and it still has plenty of drive, 
especially for higher speeds. Then again, the diode/pullup option has 
some advantages too. No need for 485 unless you are running 
higher-speeds/longer distances.

CAN is ideal for this application but unfortunately the 932s don't have 
them.

*Peter*

Marko Pavlin (home) wrote:

>Hello!
>
>I would like to connect several P89LPC932 (x51 core) slaves to single 
>LPC2xxx master. Each slave has unused SPI and UART, which can be used 
>for this communication. One slave is addressed at once.
>
>What would be best solution for that? I think SPI is ideal for that. I 
>could use free port pins for slave selects. Is there any other (more 
>scalable) option without external/additional components? How many slaves 
>can I connect to single master to avoid port overloading? Data transfer 
>rate is very low (~100 bytes/s per slave) and distance between master 
>and slaves is <1m.
>
>Any further suggestions or tips&tricks?
>


-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.300 / Virus Database: 265.7.5 - Release Date: 1/26/05

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.