Il 22/01/2013 11:36, FreeRTOS info ha scritto:> On 22/01/2013 08: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, ... > > 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).No, the cost of the node is important.> You also have not mentioned anything about what is being communicated or > how (data size, throughput, addressing, address configuration, etc.).I'm starting a home-automation project. At the beginning the data exchanged on the bus will be very small, because just a small amount of nodes will be implemented. But I want to make a decision that will be future-proof. I don't know what will be the progress of the project (maybe I will want to integrate other home-networks).> 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.At the moment, CAN or RS485 should be enough, but I don't need the extra features of CAN (low latency and predictability). If an Ethernet node cost the same of a CAN/RS485 node, why not Ethernet? This is my doubt where this question arose.>> 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. > > Sending and receiving raw Ethernet is simple enough, as others have > mentioned, if you wanted to go up a level in abstraction then UDP might > be better. > > >> 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? > > Without knowing the requirements I couldn't say what the best solution > was. If you go the Ethernet route then I have recently released a small > UDP stack (http://www.FreeRTOS.org/udp) which might suite, again > depending on what else your system is doing and the hardware it is doing > it on.I don't think I'll use UDP. I need just Ethernet.
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
On Jan 22, 10:52�am, upsided...@downunder.com wrote:> ..... > > 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.Can you beleieve it, some can indeed still be bought... http://www.findchips.com/avail?part=dp8392 I checked because of your post (well I still have some devices working with that one here, I did the Ethernet design on the Nukeman back in 1993... an NSC Sonic and a DP8392 PHY so I guess I have some sort of a soft spot). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Reply by ●January 23, 20132013-01-23
On Tue, 22 Jan 2013 23:45:21 +0100, pozz <pozzugno@gmail.com> wrote:>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 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...Which can be very, very little if you can keep your UDP packets below about 576 bytes.
Reply by ●January 23, 20132013-01-23
On Tue, 22 Jan 2013 23:45:21 +0100, pozz <pozzugno@gmail.com> wrote:>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.With CAN you can run up to 500 kbit/s. For such distances, you might consider optoisolation, if the devices are powered from different distribution panels.>> 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.CAN also has lossless arbitration, the higher priority message gets true immediately, the other is sent immediately after the first. A collision in Ethernet will force retransmission of both packets after random latencies. Unless you have some rigid high level protocol between masters, "multi-master" sounds like a lot of collisions :-)
Reply by ●January 23, 20132013-01-23
On 22/01/13 23:45, pozz wrote:> 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. >CAN is much cheaper to implement than Ethernet. The hardware is cheaper - a Cortex-M3 with CAN controller will be cheaper than one with an Ethernet MAC, and a CAN driver is cheaper than an Ethernet PHY. With Ethernet you need magnetics and an RJ-45 connector - for CAN you can use whatever type of connector you want. Even if you want to follow the suggestion about using optical isolation for the long lines, CAN will still be cheaper in hardware. And for CAN, you can connect nodes by attaching them directly to the bus - no need for switches. The electronics design is easier with CAN - you have two lines from the microcontroller going to an 8-pin driver chip and two lines to your connector (plus common ground), with all the lines at 1 MHz max. With Ethernet you have a dozen or so lines between the MAC and the PHY at 25 MHz, and 4 lines from the PHY through the magnetics to the connector at 100 MHz. And of course the software is /much/ easier when using CAN (unless you are trying to follow a standard such as CANOpen or DeviceNet - don't go there unless it is a specific requirement for the project). From what I understand of your project, CAN is /definitely/ the best choice.
Reply by ●January 23, 20132013-01-23
On 22/01/13 18:18, Oliver Betz wrote:> 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 >No, I don't have numbers - and it's been a while since I have viewed a CAN bus on a scope. But I remember a distinct difference in the edge rates. For some rough numbers, high quality twisted pair (Cat 5 Ethernet) is about 50 pF/m, so at 30 m that is 1.5 nF. With 55 ohm termination, that's an RC-constant of around 80 ns. If we assume one RC time is good enough for a solid transition, that's still 8% of your 1 Mbit time slot. Add in the propagation delay on the cable, extra capacitance for the nodes, and greater impedance on typical CAN cables (compared to Cat 5), and you can see why it is this transition that is often the limiting factor in speed*length for a CAN bus. <http://www.softing.com/home/en/industrial-automation/products/can-bus/more-can-bus/bit-timing/practical-bus-length.php?navanchor=3010538> With CAN at 1 Mbps, 30 m is the limit for a reliable bus (depending on the number of nodes and the cable type, of course). With RS-485, where both transitions are driving, 500 m should not be a problem at 1 Mbps.
Reply by ●January 23, 20132013-01-23
upsidedown@downunder.com wrote:> On Tue, 22 Jan 2013 23:45:21 +0100, pozz <pozzugno@gmail.com> wrote: > >> 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. > > With CAN you can run up to 500 kbit/s. > > For such distances, you might consider optoisolation, if the devices > are powered from different distribution panels. > >>> 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. > > CAN also has lossless arbitration, the higher priority message gets > true immediately, the other is sent immediately after the first. A > collision in Ethernet will force retransmission of both packets after > random latencies. > > Unless you have some rigid high level protocol between masters, > "multi-master" sounds like a lot of collisions :-) > >The solution for collisions in Ethernet is switching, which contravenes the OP's preferred topology. -- Les Cargill
Reply by ●January 23, 20132013-01-23
David Brown wrote:> On 22/01/13 23:45, pozz wrote: >> 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. >> > > CAN is much cheaper to implement than Ethernet. The hardware is cheaper > - a Cortex-M3 with CAN controller will be cheaper than one with an > Ethernet MAC, and a CAN driver is cheaper than an Ethernet PHY. With > Ethernet you need magnetics and an RJ-45 connector - for CAN you can use > whatever type of connector you want. Even if you want to follow the > suggestion about using optical isolation for the long lines, CAN will > still be cheaper in hardware. > > And for CAN, you can connect nodes by attaching them directly to the bus > - no need for switches. > > The electronics design is easier with CAN - you have two lines from the > microcontroller going to an 8-pin driver chip and two lines to your > connector (plus common ground), with all the lines at 1 MHz max. With > Ethernet you have a dozen or so lines between the MAC and the PHY at 25 > MHz, and 4 lines from the PHY through the magnetics to the connector at > 100 MHz. > > And of course the software is /much/ easier when using CAN (unless you > are trying to follow a standard such as CANOpen or DeviceNet - don't go > there unless it is a specific requirement for the project). > > From what I understand of your project, CAN is /definitely/ the best choice. >What we don't know about the OP's application is how sophisticated the transmission scheme at the application level needs to be. I am biased to J1939 CAN, but you can't exactly do FTP over can ... easily. -- Les Cargill
Reply by ●January 23, 20132013-01-23
On 2013-01-22, pozz <pozzugno@gmail.com> wrote:> 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...IP is simple. So is UDP. You can use raw Ethernet, but it many ways it ends up being more work than raw ethernet. There are all tons of tools you can use to test and troubleshoot UDP/IP stuff. You'll have nothing if you go with raw Ethernet. If you ever want any sort of Windows or Linux programs to talk to these widgets, you'll regret doing raw Ethernet. -- Grant Edwards grant.b.edwards Yow! How do I get HOME? at gmail.com
Reply by ●January 23, 20132013-01-23
On 23/01/13 22:34, Grant Edwards wrote:> On 2013-01-22, pozz <pozzugno@gmail.com> wrote: >> Il 22/01/2013 09:52, upsidedown@downunder.com ha scritto:>>> 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... > > IP is simple. So is UDP. > > You can use raw Ethernet, but it many ways it ends up being more work > than raw ethernet. There are all tons of tools you can use to test and > troubleshoot UDP/IP stuff. You'll have nothing if you go with raw > Ethernet. If you ever want any sort of Windows or Linux programs to > talk to these widgets, you'll regret doing raw Ethernet. >IP and UDP are significantly more work than raw Ethernet. They may be relatively simple, especially compared to TCP, but there are a lot of details to get right. Typically you handle this by using a third-party stack (LWIP being a common choice). And unless you find ready-made code for your particular choice of microcontroller, you still need to make a driver to get packets in and out of your MAC. With raw Ethernet, this driver is /all/ that you need. You give the Ethernet MAC your source MAC address. You send packets of data to a specific known MAC address or to the broadcast address. You receive packets from others that are either to your own address, or broadcasts. It's that simple. The MAC handles collisions, retries, framing, and (typically) basic checksumming. If you want to monitor your data, stick Wireshark on the network (as always with Wireshark, you need to use a switch with mirroring on a port, or find a good old fashioned hub rather than a switch). If you want to write PC code to communicate with your system, it's easy with Linux - just open a raw socket and away you go. You can happily use languages like Python for this to do it quickly and simply. With Windows, life is more complicated - but it is still possible. Raw Ethernet is faster, more predictable and has lower overheads than IP - even UDP. That is why it is used for protocols like ATA over Ethernet. What you can't do, of course, is use standard programs that work with UDP, TCP/IP, or other IP-based protocols. You can't use a DHCP server to organise your network, or ftp to update software, or telnet to test your application. Having said that, I have no doubts that CAN is a better choice in this particular application (based on the info we have been given so far, of course).
