|
|
View previous topic :: View next topic |
Author |
Message |
umka
Joined: 28 Aug 2007 Posts: 99 Location: New Zealand
|
Multi uC network |
Posted: Fri Jun 26, 2009 11:53 pm |
|
|
What is the best way to do a multi uC network? Thoughts would be RS232, RS485, I2C.
The idea is to have a single bus cable to run around an electric motorcycle, 24kw DC motor, instead of having a large wiring loom. This will greatly reduce the wiring mess. I guess this means the environment is quite noisy! |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sat Jun 27, 2009 12:58 am |
|
|
Among the physical layers, that are available for uP without special hardware (except for the necessary drivers), RS485 offers the best interference supression. It's also used for a number of industrial field busses. But a well-considered signal and supply wiring is still necessary. Optical isolated RS485 is superior, when common mode interferences must be expected to exceed the RS485 receivers capability, but you have to calculate at lest $5-$10 additional costs for each network node. |
|
|
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
RE: |
Posted: Sat Jun 27, 2009 3:50 am |
|
|
Controller Area Network (CAN) is also a good choice, I believe these are used in automobiles..
thanks
arunb |
|
|
asmallri
Joined: 12 Aug 2004 Posts: 1634 Location: Perth, Australia
|
|
|
Steve H Guest
|
|
Posted: Sat Jun 27, 2009 1:58 pm |
|
|
CAN is probably the best choice - it is well understood and is used in Automotive applications already. Automotive (including Motorcycles) is very challenging because of the heat / cold and electrical noise. Best to choose a solution that offers a physical layer that is hardened against this - which CAN does offer.
My 2 cents worth - HTH Steve H. |
|
|
FvM
Joined: 27 Aug 2008 Posts: 2337 Location: Germany
|
|
Posted: Sat Jun 27, 2009 4:15 pm |
|
|
CAN isn't bad, but interference strength isn't generally better than RS485, that's also used as automotive control bus by several manufacturers.
Because CAN requires special hardware (the same with the previously mentioned Ethernet), it reduces the available processor choice respectively increases system costs. |
|
|
arunb
Joined: 08 Sep 2003 Posts: 492 Location: India
|
|
|
Ttelmah Guest
|
|
Posted: Sun Jun 28, 2009 2:41 am |
|
|
The 'network choice' selection, depends on a lot of things, many of which have not been asked:
1) How much data needs to be sent?.
2) How many processors in the network?.
3) What is the topology?. Is it actually a 'loop'?.
4) Who is going to originate the transactions?. One master, or multiple devices?.
5) Is their any redundancy in the data itself?.
6) What is the total reliability criterion?.
7) What are the timing restrictions on receiving legitimate data?.
Now, once you know the volume of data,your choices of transfer medium become constrained. If you need to send hundreds of thousands of bytes per second, several of the possibilities are immediately 'ruled out'.
Then you look at the design of the possible links, to see what the likely error rate with your noise sources will be.
If the layout is a loop, you might want to consider a 'token ring' type system, versus a single loop. There are advantages and disadvantages to both approaches, but the ring approach gets much slower with large numbers of devices, but makes multiple masters easier.
With these, you then look at your reliability criteria, together with timing restrictions, to see if you can meet these with a 'retransmit', or if the costs of re-negotiating a link, force the data to become self redundant. This is what you have on things like space craft links, where the 'turn round time', and limited storage on the source craft, mean that you have to add to the data things like Shannon encoding, so that bits can be lost, but still recovered.
You then have two parts to what you send. The physical 'layer', and the protocol. You can (for instance), send TCP/IP, over RS485, or over Ethernet. Similarly, you could decide to use Ethernet transceivers and buffers, because of their high data rates, and easy provision of a buffered interface, but use your own software protocol, with smaller packets, limited to the needs of your application, rather than implementing a full 'network' connectivity.
You need to sit down, and draw a 'tree' of needs for the interface, based on my questions. Then add notes about likely noise (for example, is their just one part that is going to be worse - near the engine,and how many processors will be in this area). It might make it possible to consider extra protection for part of the connection only.
Only with rather more complete initial data, is anything more than simple suggestions, going to be possible.
Best Wishes |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|