On 22/01/13 13:41, upsidedown@downunder.com wrote:> On Tue, 22 Jan 2013 12:58:39 +0100, David Brown > <david@westcontrol.removethisbit.com> wrote: > >> On 22/01/13 11:55, upsidedown@downunder.com wrote: >>> On Tue, 22 Jan 2013 10:36:43 +0000, FreeRTOS info <noemail@given.com> >>> wrote: >>> >>>>> I think Ethernet is a very good bus technology that solves many >>>>> problems to the developer: framing, multi-master, addressing, >>>>> conflicts, ... >>>> >>>> Ethernet has plentiful low cost cabling and router options, but you have >>>> not mentioned the price point for your nodes. Adding Etherent will >>>> raise the price of the nodes (maybe that doesn't matter if this is a one >>>> off with only 10). >>>> >>>> You also have not mentioned anything about what is being communicated or >>>> how (data size, throughput, addressing, address configuration, etc.). >>>> It might be that you have considered all this and concluded that >>>> Ethernet is your best solution, but other people reading the post will >>>> wonder if it is overkill for what you want. Lots of people have >>>> mentioned CAN already, but multi-drop RS485/422 could also be a very >>>> simple and low cost solution if it meets your requirements. >>> >>> CAN is essentially RS-485, in fact, in the early development stages, >>> standard RS-485 chips were used (data to Driver Enable pin, Data pin >>> tied to dominant state). >> >> No, CAN is not essentially RS-485. You can - as you say - use RS-485 >> drivers configured in a non-standard way to handle the physical layer of >> CAN. But CAN provides a protocol layer on top of that which is very >> different from the UART layer used with RS-485. >> >>> >>> If multi-master is a critical requirement, I would suggest CAN or >>> Ethernet, however, if standard two wire RS-485 is required, then some >>> higher level protocol, like token passing is needed. > > I am sorry, I forget to include "electrically" in my statement about > RS-485. > >Fair enough - there are a lot of electrical similarities. However, there are electrical differences too. With RS-485, the drivers can pull the lines high or low with quite a large current - this lets you run either very fast (such as 12 Mbps) or very far (up to several km). With CAN, you only drive dominant - recessive is by termination resistors, and is thus much slower on long high-capacitance lines. In addition, the CAN bus requires the whole bus to be stable at each state within half a bit time (whereas with a long or fast RS-485 bus, you can have several bits in flight at once). This means that your CAN bus is much shorter or slower than an RS-485 bus could be.
Smalles Ethernet (no TCP/IP) implementation, even 10Mbps
Started by ●January 22, 2013
Reply by ●January 22, 20132013-01-22
Reply by ●January 22, 20132013-01-22
David Brown wrote: [...]>However, there are electrical differences too. With RS-485, the drivers >can pull the lines high or low with quite a large current - this lets >you run either very fast (such as 12 Mbps) or very far (up to several >km). With CAN, you only drive dominant - recessive is by termination >resistors, and is thus much slower on long high-capacitance lines. Insince it is a transmission line, the dominant -> recessive transition is also fast on long lines. The cable capacitance is less a problem than the lumped capacitance of transceivers etc. Oliver -- Oliver Betz, Munich despammed.com is broken, use Reply-To:
Reply by ●January 22, 20132013-01-22
On 22/01/13 17:18, Oliver Betz wrote:> David Brown wrote: > > [...] > >> However, there are electrical differences too. With RS-485, the drivers >> can pull the lines high or low with quite a large current - this lets >> you run either very fast (such as 12 Mbps) or very far (up to several >> km). With CAN, you only drive dominant - recessive is by termination >> resistors, and is thus much slower on long high-capacitance lines. In > > since it is a transmission line, the dominant -> recessive transition > is also fast on long lines. > > The cable capacitance is less a problem than the lumped capacitance of > transceivers etc. > > Oliver >That's true - but the dominant to recessive transition by terminating resistor is still slower than a driven transition. It is the limiting factor in the speed vs. length trade-off. mvh., David
Reply by ●January 22, 20132013-01-22
David Brown wrote: [...]>>> km). With CAN, you only drive dominant - recessive is by termination >>> resistors, and is thus much slower on long high-capacitance lines. In >> >> since it is a transmission line, the dominant -> recessive transition >> is also fast on long lines. >> >> The cable capacitance is less a problem than the lumped capacitance of >> transceivers etc. > >That's true - but the dominant to recessive transition by terminating >resistor is still slower than a driven transition. It is the limiting >factor in the speed vs. length trade-off.Do you have numbers? I made tests only with approx. 30m twisted pair cable and it's more than one year ago, but IIRC there was no big difference in rise/fall time. Of course, you shouldn't measure with a standard 10:1scope probe beause it adds too much capacitance to the node. Oliver -- Oliver Betz, Munich despammed.com is broken, use Reply-To:
Reply by ●January 22, 20132013-01-22
On Tuesday, January 22, 2013 2:14:04 AM UTC-6, pozz...@gmail.com wrote:> I have to create a small network composed by some nodes. At the moment, the number of nodes is about 10, but I want to have a flexible architecture that could increase in the future. > > > > I think Ethernet is a very good bus technology that solves many problems to the developer: framing, multi-master, addressing, conflicts, ... > > > > I don't need the full TCP/IP stack that needs high resources. I just want to send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485). > > I don't need very high-speed, so it could be sufficient the 10Mbps. 100Mbps could be nice in the future. > > > > What is the smallest and cheapest solution? A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector? > > > > Another problem could be the cabling of the network. Usually Ethernet is a star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology: > > > > +---+ +---+ +---+ > > | |---| |---| | > > +---+ +---+ +---+ > > > > How can I implement this small two-ports hub/switch in every single node of the network?Have a look at some of the 'industrial' ethernet parts that Micrel sells. KSZ8842-16MQL has a two port switch plus MAC with an 8/16 bit interface. I haven't used it, but looks like it's similar to your requirements.
Reply by ●January 22, 20132013-01-22
On 22/01/13 09.14, pozzugno@gmail.com wrote:> I have to create a small network composed by some nodes. At the moment, the number of nodes is about 10, but I want to have a flexible architecture that could increase in the future. > > I think Ethernet is a very good bus technology that solves many problems to the developer: framing, multi-master, addressing, conflicts, ... > > I don't need the full TCP/IP stack that needs high resources. I just want to send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485). > I don't need very high-speed, so it could be sufficient the 10Mbps. 100Mbps could be nice in the future. > > What is the smallest and cheapest solution? A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector? > > Another problem could be the cabling of the network. Usually Ethernet is a star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology: > > +---+ +---+ +---+ > | |---| |---| | > +---+ +---+ +---+ > > How can I implement this small two-ports hub/switch in every single node of the network?Hi! Please tell us (the group) what you choose and why. (Search: https://www.google.com/search?q=wired+sensor-network+microcontroller ) Take a look at: "Powerpoint": Introduction to sensor hardware - Network and Systems Lab: http://nslab.ee.ntu.edu.tw/courses/wsn-labs-fall-11/slides/Intro.ppt "Powerpoint": Smart Sensor Design and Networking Standards - Esensors, Inc.: http://www.eesensors.com/media/wysiwyg/docs-pdfs/ESP05_Smart.pdf Quote: "... Numerous (>100) incompatible sensor networks are currently in use � each speaking a different language ... * The IEEE 1451 Smart Transducer Protocol standard is the best universal solution
Reply by ●January 22, 20132013-01-22
On 22/01/13 09.14, pozzugno@gmail.com wrote:> I have to create a small network composed by some nodes. At the moment, the number of nodes is about 10, but I want to have a flexible architecture that could increase in the future. > > I think Ethernet is a very good bus technology that solves many problems to the developer: framing, multi-master, addressing, conflicts, ... > > I don't need the full TCP/IP stack that needs high resources. I just want to send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485). > I don't need very high-speed, so it could be sufficient the 10Mbps. 100Mbps could be nice in the future. > > What is the smallest and cheapest solution? A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector? > > Another problem could be the cabling of the network. Usually Ethernet is a star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology: > > +---+ +---+ +---+ > | |---| |---| | > +---+ +---+ +---+ > > How can I implement this small two-ports hub/switch in every single node of the network?Hi! (full version) Please tell us (the group) what you choose and why. (Search: https://www.google.com/search?q=wired+sensor-network+microcontroller ) Take a look at: "Powerpoint": Introduction to sensor hardware - Network and Systems Lab: http://nslab.ee.ntu.edu.tw/courses/wsn-labs-fall-11/slides/Intro.ppt "Powerpoint": Smart Sensor Design and Networking Standards - Esensors, Inc.: http://www.eesensors.com/media/wysiwyg/docs-pdfs/ESP05_Smart.pdf Quote: "... Numerous (>100) incompatible sensor networks are currently in use � each speaking a different language ... * The IEEE 1451 Smart Transducer Protocol standard is the best universal solution
Reply by ●January 22, 20132013-01-22
On 22/01/13 09.14, pozzugno@gmail.com wrote:> I have to create a small network composed by some nodes. At the moment, the number of nodes is about 10, but I want to have a flexible architecture that could increase in the future. > > I think Ethernet is a very good bus technology that solves many problems to the developer: framing, multi-master, addressing, conflicts, ... > > I don't need the full TCP/IP stack that needs high resources. I just want to send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485). > I don't need very high-speed, so it could be sufficient the 10Mbps. 100Mbps could be nice in the future. > > What is the smallest and cheapest solution? A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector? > > Another problem could be the cabling of the network. Usually Ethernet is a star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology: > > +---+ +---+ +---+ > | |---| |---| | > +---+ +---+ +---+ > > How can I implement this small two-ports hub/switch in every single node of the network?Hi! (full version) Please tell us (the group) what you choose and why. (Search: https://www.google.com/search?q=wired+sensor-network+microcontroller ) Take a look at: "Powerpoint": Introduction to sensor hardware - Network and Systems Lab: http://nslab.ee.ntu.edu.tw/courses/wsn-labs-fall-11/slides/Intro.ppt "Powerpoint": Smart Sensor Design and Networking Standards - Esensors, Inc.: http://www.eesensors.com/media/wysiwyg/docs-pdfs/ESP05_Smart.pdf Quote: "... Numerous (>100) incompatible sensor networks are currently in use � each speaking a different language ... * The IEEE 1451 Smart Transducer Protocol standard is the best universal solution
Reply by ●January 22, 20132013-01-22
On 22/01/13 09.14, pozzugno@gmail.com wrote:> I have to create a small network composed by some nodes. At the moment, the number of nodes is about 10, but I want to have a flexible architecture that could increase in the future. > > I think Ethernet is a very good bus technology that solves many problems to the developer: framing, multi-master, addressing, conflicts, ... > > I don't need the full TCP/IP stack that needs high resources. I just want to send raw Ethernet packets to the bus and receive raw packets from the bus (like for RS485). > I don't need very high-speed, so it could be sufficient the 10Mbps. 100Mbps could be nice in the future. > > What is the smallest and cheapest solution? A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector? > > Another problem could be the cabling of the network. Usually Ethernet is a star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology: > > +---+ +---+ +---+ > | |---| |---| | > +---+ +---+ +---+ > > How can I implement this small two-ports hub/switch in every single node of the network?Hi! (full version 4) Please tell us (the group) what you choose and why. (Search: https://www.google.com/search?q=wired+sensor-network+microcontroller ) Take a look at: "Powerpoint": Introduction to sensor hardware - Network and Systems Lab: http://nslab.ee.ntu.edu.tw/courses/wsn-labs-fall-11/slides/Intro.ppt "Powerpoint": Smart Sensor Design and Networking Standards - Esensors, Inc.: http://www.eesensors.com/media/wysiwyg/docs-pdfs/ESP05_Smart.pdf Quote: "... Numerous (>100) incompatible sensor networks are currently in use � each speaking a different language ... * The IEEE 1451 Smart Transducer Protocol standard is the best universal solution * Supported by NIST, IEEE and many Federal agencies ... IEEE 1451 Advantages * Comprehensive enough to cover nearly all sensors and actuators in use today (not 20/80% approach) * Many operating modes (buffered, no-buffer, grouped sensors, timestamps, timed data, streaming ...) * Extensive units, linearization and calibration options * Multiple timing and data block size constraints handled. * Compatible with most wired and wireless sensor buses and networks (point-to-point, mesh, TIM-to-TIM, mixed networks). * Efficient binary protocol (especially suitable for wireless) * Standard is 400+ pages for basic part, over 1500 page total ... * A compliance test procedure is also desirable to prove that the design is correct ..." BACnet: http://en.wikipedia.org/wiki/BACnet Quote: "... BACnet is a communications protocol for building automation and control networks. It is an ASHRAE, ANSI, and ISO standard protocol. ... The BACnet protocol defines a number of data link / physical layers, including ARCNET, Ethernet, BACnet/IP, Point-To-Point over RS-232, Master-Slave/Token-Passing over RS-485, and LonTalk. ..." http://www.bacnet.org/ stitcs.com: White Paper: BACnet vs. Lon�The War is Over: http://www.stitcs.com/en/LonWorks/Bacnet%20vs%20LonWorks.pdf Citat: "...How BACnet won the war. The outcome of most wars is determined by a few key battles. In the war of open protocols for building controls, BACnet�s decisive victory is defined by three: Industry-wide acceptance, greater benefits than LonWorks and a change in manufacturers� ideology about their building protocols offerings..." Open-Source BACnet Protocol stack for Linux: http://bacnet4linux.sourceforge.net/ Open-Source BACnet Protocol stack for embedded systems: http://bacnet.sourceforge.net/ Open-Source BACnet Protocol stack in Java: http://bacnet4j.sourceforge.net/ BACpypes, Open-Source BACnet Protocol stack in Python: http://bacpypes.sourceforge.net/ BACsharp, Open-Source BACnet Protocol stack in C#: http://bacsharp.sourceforge.net/ Might be useful for wired also: 12/04/07, Choosing the best system software architecture for your wireless smart sensor design: Part 1: http://www.embedded.com/design/networking/204700594 12/10/07, Choosing the best system software architecture for your wireless smart sensor design: Part 2: http://www.embedded.com/design/networking/204800543 12/17/07, Choosing a system software architecture for your wireless smart sensor design: Part 3: http://www.embedded.com/design/networking/204805677 Energy-aware wireless-wired communications in sensor networks: http://www2.warwick.ac.uk/fac/sci/eng/research/sensors/mbl/database/ieeesensors09/PDFs/Papers/019_5826.pdf Quote: "... In our sensor network architecture sensor units are organized in clusters where communication rely on a fieldbus, with each cluster connected to rest of the network through wireless links. A reliable and efficient data transmission model has been proposed for the intra-cluster communication, which takes into account energy constraints keeping the involved units in a power saving state as long as possible. ..." Network and Control Protocol for a Wired Self-Organising Sensor: http://www.idc.ul.ie/ztiles/publications/networkprotocols.pdf - http://en.wikipedia.org/wiki/Sensor_node - http://en.wikipedia.org/wiki/Wireless_sensor_network#Operating_systems - http://en.wikipedia.org/wiki/Mesh_networking http://en.wikipedia.org/wiki/Optimized_Link_State_Routing_Protocol A layer 2 routing protcol: http://www.open-mesh.org/projects/batman-adv/wiki http://www.open-mesh.org/projects/batman-adv/wiki/Wiki http://www.open-mesh.org/projects/open-mesh/wiki/2013-01-15-batman-adv-2013-0-0-release Quote: "... The batman-adv Ethernet type (0x4305) was accepted as "official" Ethernet type inside the Linux kernel to help avoiding future collisions with other protocols. ..." http://en.wikipedia.org/wiki/B.A.T.M.A.N. http://www.open-mesh.org/projects/open-mesh/wiki http://en.wikipedia.org/wiki/List_of_open_source_routing_platforms br, Glenn
Reply by ●January 22, 20132013-01-22
Il 22/01/2013 09:52, upsidedown@downunder.com ha scritto:> On Tue, 22 Jan 2013 00:14:04 -0800 (PST), pozzugno@gmail.com wrote: > >> I have to create a small network composed by some nodes. At the moment, the number of nodes is about 10, but I want to have a flexible architecture that could increase in the future. >> >> I think Ethernet is a very good bus technology that solves many problems to the developer: framing, multi-master, addressing, conflicts, ... > > What is the distance between stations and the total line length ?I could imagine a maximum total line length of 100m. Anyway I have the possibility to use normal Ethernet switches to increase the network physical size with a small increase in cost.> What are your actual data throughput requirements ?It is actually low: 57600bps could be enough. But I have some ideas to implement in the feature.> Have you checked if this could be implemented with CAN (Controller > Area Network) ? This would also solve the same problems as you listed.Indeed I already thought about CAN. But the main focus of CAN bus is predictability and low latency that I don't need. Maybe the cost of a CAN network could be very low, but I don't know what could be the cost of a simple Ethernet network. Is it still high? Texas produces many microcontroller of Stellaris family with Ethernet MAX and PHY integrated. It is only to add magnetics and connector to implement a fully 10-100Mbps Ethernet node.>> I don't need the full TCP/IP stack that needs high resources. >> I just want to send raw Ethernet packets to the bus and receive raw packets from the bus >> (like for RS485). > > Consider using UDP instead of using raw Ethernet frames and it is > easier to use normal diagnostic tools much easier. It actually adds > only a few bytes into the frame header and requires the simple ARP > protocol to be implemented.UDP means IP...>> I don't need very high-speed, so it could be sufficient the 10Mbps. >> 100Mbps could be nice in the future. > > And consume a lot more power. > >> What is the smallest and cheapest solution? A microcontroller with embedded MAC and an external PHY, magnetics and connector, or a microcontroller with an external Ethernet controller (with MAC+PHY integrated), magnetics and connector? >> >> Another problem could be the cabling of the network. Usually Ethernet is a star-topology network: all the nodes are connected to a center, that is a switch or a hub. I'd like to have a small two-ports hub/switch on each single node, so I can make a "line" topology: >> >> +---+ +---+ +---+ >> | |---| |---| | >> +---+ +---+ +---+ >> >> How can I implement this small two-ports hub/switch in every single node of the network? > > Have you considered RG-58 coaxial cable on 10Base2 :-) > > You would need only one transceiver in each node and a T-coaxial > connector at each node. I have no idea, if 10base2 transceivers are > still available and what they cost. > > I would still suggest first checking, if CAN would be sufficient. >
