How are flocks connecting there RPI with external world(Other embedded circuits)? any standards.. if not which 1 you will pick?

Thus far I've been using the Adafruit Pi CobblerAdafruit Pi Cobbler to interface the header with a breadboard and programming in Python using libraries like RPi.GPIO.  I've really enjoyed Adafruit's tutorials: http://learn.adafruit.com/category/raspberry-pi

Since you've already dealt with 1) Use I/O header, and 2) Use of USB port, I think I'll add the missing alternative, 3) Use of Ethernet.

Some people consider USB a fixture and a sacred cow, but I've been of the opinion that it's a bit of a poor man's alternative to Ethernet ever since USB was released.  Maybe USB had a point in the very early days when Ethernet was still a bit bulky and costly, but that doesn't apply today.  Everything that USB does in 2012 could be done far more effectively and flexibly with Ethernet, and with IPv6 even more so because autoconfiguration makes IPv6 as plug'n'play as USB.

What's more, with IP addresses being extremely plentiful under IPv6, you can easliy conceive of hundreds or millions of sensors connected by IP, and of course this is exactly what the Internet of Things is already engaged in doing.  And if your interest is in local communications only, and you have no interest in higher-level protocols or the Internet in your application, then raw Ethernet provides an extremely fast and efficient way of transferring data within a local set of boards or machines.

All of which is a preamble to my recommendation:  "Think big, think ahead".  Why not make every sensor, actuator, slave and controller in your system networked, linked together by cheap Etherent switches, and even powered from Ethernet using PoE to eliminate power supplies?  All the bits you need are available, so it's more a case of thinking differently than doing research.

Of course you'll still need the GPIO headers to connect the Pi to low level devices, but when it comes to connecting together such boards into a system, I really think Ethernet (and IPv6) is the way to go.  The very low cost of the Pi helps a lot of course.

Once networked, you'll find your system's abilities expanding rapidly, because the net is a very synergistic place where everything piggybacks on everything else and new emergent phenomena appear every day.  I think you'd benefit from that.

So would everybody else, but few people seem to realize it.

Morgaine.

Morgaine Dinova wrote:

 

USB has so much more built in that it is hugely more complex than Ethernet, which is just a very low level unverified [it is verified, but not corrected] frame transfer mechanism...

 

Higher levels of protocol that ride on top of Ethernet are not Ethernet, and do not contribute to the complexity of Ethernet...

USB does define the packet and software layers, so yes, if you ignore those parts of an Ethernet-based communctions stack that does give Ethernet an advantage.  So it seems to me that if you're going to make a fair comparison, you really need to do it layer by layer.  At the physical level, they're pretty similar complexity.  However, with Ethernet 100baseT you do have the complexity of MLT-3, and 1000baseT is loads of fun using all four pairs.  In contrast, I believe USB-3.0 just uses 8B10B coding.  You do have scrambling with both.  USB doesn't have to drive as far, so you can use lower-power drivers.  USB also gives you power for free, while PoE is an extra-cost option.  Ethernet Auto-MDIX is fun, something you don't need with USB since it's half duplex.  Let's ignore WiFi and Ethernet-level support for IEEE-1588 Precision Timing Protocol.

The link layers are similar, with best effort data transfers.  However, USB does give you single-packet loss detection, so you don't need the higher-level protocol to handle it.  USB hubs are very simple devices, since the flow is always between host and device and you don't need to store much.  An Ethernet hub is likewise very simple, but nobody uses those nowadays.  Instead, you have Ethernet switches, which implement bridge functionality in hardware.  Bridge functionality is nasty, since the bridge has to learn the MAC addresses of frames coming in each port so it doesn't have to broadcast, and there's a limited amount of frame buffering in the switch, and you need to implement flow control, and you need to auto-negotiate to determine whether to implement flow control, and which speed to use, and whether you can do full duplex.

And then you have Spanning Tree Protocol.  That's a fun algorithm.  There's a quote that reading the STP standard is a good cure for insomnia, and thinking about it can be an effective contraceptive as well.  If STP is too simple for you, how about Rapid STP?  Since USB is physically limited to tree interconnect, there's no STP.  Yes, if you're making an end device you don't need to worry about STP, but it's fair to compare USB tree enumeration with Ethernet STP as far as complexity is concerned.

We're still at the link layer and haven't started sending any networking packets yet.

I've done a lot of work with Ethernet hardware and software, and there's a lot of complexity there.  I haven't done actual implementation of USB, but I've read a lot of the USB 2.0 standard and IMO the USB physical and link layers are simpler.  Ethernet is a lot more versatile since it's peer-to-peer and can drive 100m, and higher performance since it's full duplex, supports multiple simultaneous data streams, and isn't polled.  But that comes with higher-cost components, more board area, and higher power budget.

Like many tools in an engineer's bag of tricks, each has its advantages, disadvantages, and uses.

JMO/YMMV

Gary Stewart wrote:

 

No Morgaine you logic is terribly and obviously flawed.

Please stop attacking people and instead address the arguments they are making.  This isn't a debating chamber, it's an engineering forum.

You don't have the easy programming interface to Ethernet you claim as its main

advantage without the upper level protocols. That is after all exactly what they are for and why everybody uses them.

That was not the claim.  I claimed that Ethernet was less complex than USB, which it is, as your own response proved, since you very nicely bullet-pointed all the things that USB has to do which the simple frame transfer mechansim of Ethernet does not have to do.

The fact that almost nobody uses Ethernet alone does not say anything about the complexity of Ethernet alone.  If you want to discourse on the complexity of Ethernet then talk about Ethernet, don't talk about IP and TCP and HTTP and SOAP and Websocket and all the cloud protocols and still more that rides on top of Ethernet.  They are all completely irrelevant to the matter of whether Ethernet is complex or not.

This is why engineers separate communications systems into layers, so that they can talk about one layer at a time sensibly.  Please do so, if you're an engineer.  And if you're not an engineer, that's fine too, but then sit back attentively and you'll see how engineers analyse things one piece at a time so that they can be understood easily.

And the piece we're talking about at the moment is Ethernet.

Morgaine.

John Beetem wrote:

 

Morgaine Dinova wrote:

 

USB has so much more built in that it is hugely more complex than Ethernet, which is just a very low level unverified [it is verified, but not corrected] frame transfer mechanism...

Yes, sorry, I was less than fully precise there.  When I said unverified I had delivery verification in mind, since the sender doesn't know if the recipient receives a given Ethernet frame or not as ACKs are not part of the protocol.  Ethernet really is very basic, intentionally.  Each frame does however carry a 32-bit CRC (frame check sequence), so if the packet does actually arrive then its data integrity can be determined, which is the meaning you attached to my word "verified".  So it's a bit of both, integrity is verified but delivery is not.

So it seems to me that if you're going to make a fair comparison, you really need to do it layer by layer.

Yes indeed, that makes a lot of sense.

At the physical level, they're pretty similar complexity.  However, with Ethernet 100baseT you do have the complexity of MLT-3, and 1000baseT is loads of fun using all four pairs.  In contrast, I believe USB-3.0 just uses 8B10B coding.  You do have scrambling with both.  USB doesn't have to drive as far, so you can use lower-power drivers.  USB also gives you power for free, while PoE is an extra-cost option.  Ethernet Auto-MDIX is fun, something you don't need with USB since it's half duplex.

Pretty much balanced there, one physical layer has a few extra features in one area and the other has a few extra features in another area, none of which impose a major burden of complexity on their respective layer.

The link layers are similar, with best effort data transfers.  However, USB does give you single-packet loss detection, so you don't need the higher-level protocol to handle it.  USB hubs are very simple devices, since the flow is always between host and device and you don't need to store much.  An Ethernet hub is likewise very simple, but nobody uses those nowadays.  Instead, you have Ethernet switches, which implement bridge functionality in hardware.  Bridge functionality is nasty, since the bridge has to learn the MAC addresses of frames coming in each port so it doesn't have to broadcast, and there's a limited amount of frame buffering in the switch, and you need to implement flow control, and you need to auto-negotiate to determine whether to implement flow control, and which speed to use, and whether you can do full duplex.

 

And then you have Spanning Tree Protocol.  That's a fun algorithm.  There's a quote that reading the STP standard is a good cure for insomnia, and thinking about it can be an effective contraceptive as well.  If STP is too simple for you, how about Rapid STP?  Since USB is physically limited to tree interconnect, there's no STP.  Yes, if you're making an end device you don't need to worry about STP, but it's fair to compare USB tree enumeration with Ethernet STP as far as complexity is concerned.

Although switches "live" at the link level, they're totally transparent in their operation and don't impact at all on the complexity of implementation nor the complexity of operation of the link layer's interface endpoints.  Two Ethernet interfaces talking to each other behave identically whether or not they are connected via a switch.  It's not like USB where you add a hub and suddenly the upstream endpoint gains a whole new level of operational complexity.

So while I certainly don't dispute that switches are complex beasts to create, their link layer complexity is in a side lane of its own, not impacting on the complexity of the link layer between a pair of interfaces.  As for spanning tree ... there's room for a great book of the Soul of a New Machine type to be written around that subject.  It would be a mixture of success and calamity and insight and a serious rival to lay books on quantum mechanics. :-)

We're still at the link layer and haven't started sending any networking packets yet.

 

I've done a lot of work with Ethernet hardware and software, and there's a lot of complexity there.  I haven't done actual implementation of USB, but I've read a lot of the USB 2.0 standard and IMO the USB physical and link layers are simpler.  Ethernet is a lot more versatile since it's peer-to-peer and can drive 100m, and higher performance since it's full duplex, supports multiple simultaneous data streams, and isn't polled.  But that comes with higher-cost components, more board area, and higher power budget.

 

Like many tools in an engineer's bag of tricks, each has its advantages, disadvantages, and uses.

JMO/YMMV

Sure, I agree there.  But the redux is that USB does a whole lot more, and that extra functionality not only gives USB extra operational complexity but those features also have to be implemented so there's more complexity in silicon as well.  To make a rather ugly analogy, Ethernet is like a RISC interconnect whereas USB is like a CISC one.  Like RISC, Ethernet is a pretty KISS approach almost entirely devoid of nice features, which have to be implemented at a higher level ("in the compiler", in this analogy) if your application needs them.

But note that not all applications need those extra features, and when they don't then the barebones nature of Ethernet comes in very handy.

Morgaine.

It's worth pointing out here that this thread is about how to (quoting) "connect RPI with external embedded boards".  What prompted me to suggest Ethernet as a third option for Bhaumik Shah was that many simple sensors provide data that is naturally isochronous, and they often don't benefit from upper layer protocols at all.

If you're measuring a fluctuating voltage or pressure or temperature then it usually matters little if one data point doesn't arrive because the next one will supercede it.  Retransmitting a datum because it didn't arrive the first time is often not only pointless but of negative value, because it's likely to arrive too late, and if the relevant time slot has passed then after processing it you'd have to discard it.  That would just consume resources for nil benefit.

It's common to encounter this requirement in live media transport, but it's equally applicable to many low-level engineering communications.  Barebones Ethernet is a good match for this kind of application.

PS. Additional benefit:  galvanic isolation, since Ethernet is magnetically coupled at both ends of a link.  This can be crucially important for some types of sensor network, especially if extending across more than one building.  Even if isolation is not a design requirement, it's standard in the Ethernet specification and hence your more expensive machines will be less at risk from problems occurring at remote sensors than they might otherwise be..

Morgaine,

I didn't attack you, I attacted your argument because it was and still is obviously flawed. I'll remind you about you attitude on

attacking people/name calling the next time you use your favorite, Raspberry Pi fanbois.

The complexity of Ethernet vs USB at the media or link level has little if anything to do with actually using them in the real

world because it is hiden behind the hardware drivers and those protocol layers you speak of. Once again, that is exacty

why the protocol layers exist. I have done a fair amount of Ethernet sockets programming using the TCP/IP and UDP/IP

and have built my own Linux based Ethernet router so I am very familiar with how easy it is to use as well as the concept

of protocol layers thank you. Communicating with any layer other that the one specifically provided for applications with

either interface will require a complicated kernel level interface that will have to be written, tested, and debugged (in kernel

space, lots o'fun) before it can be used.  As I previously said, and you clearly ignored, you do not have to implement any

of the "complex" functions of the USB interface that you don't need when you talk to it at the same raw level as the

Ethernet interface so you gain nothing there either. So why would anybody want to do all that low level programming to

implement a raw Ethernet or USB interface when easy to use protocol stacks and application interfaces already exits

for both interfaces ?

While simple sensors may not themselves benefit from upper level protocols, as far as I know all of them that have an

Ethernet interface support at least a limited TCP/IP, UDP/IP or even HTTP interface protocol. The ones that use USB

interfaces can use application layer programming interfaces already available for Linux taking full advantage of all

or none of the USB complexity they do or do not need. Not to mention that it is a lot easier to find programmers for

application level interfaces than it is for intermediate protocol or raw level interfaces.

And that is where your Ethernet vs. USB complexity sideshow comes crashing down. Welcome to the modern era of

sensor interfaces and "easy programming". Just what the sensor vendors ordered.

As to media layer electrical isolation, you can easily find USB equipment to do this too if you need it (Google it).

P.S. Still waiting.

On the issue of Ethernet complexity, I can't help you further since you refuse to use the engineering concept of dividing a communications stack into layers so that properties of single layers can be discused separately.

On sensor networks, you miss the point despite it having been outlined clearly.  Just because a facility like TCP or HTTP already exists doesn't mean that it's always good to use it.  Horses for courses.  As I pointed out already, a protocol that uses a retransmission mechanism is not only of no benefit in the transmission of isochronous data but can actually add a negative contribution.

And finally, even a non-ACKed upper protocol like UDP adds overhead of around one order of magnitude compared to MAC-level communications, which means your isochronous sampling is limited to being an order of magnitude slower.  That may or may not be adequate, again it's horses for courses.  An engineer doesn't use just a single tool, but employs a large toolkit of solutions and chooses them appropriately to the problem in hand.

You seem to want an all-in-one debate instead of an engineering analysis of pros and cons.  Not interested.

Morgain wrote: On the issue of Ethernet complexity, I can't help you further since you refuse to use the engineering concept of dividing a communications stack into layers so that properties of single layers can be discused separately.

I have no idea what you think you are talking about. What you keep advocating is the complete bypassing of all but the lowest layer of the protocol stack. Furthermore you continue to ignore that

to do this will REQUIRE that you write a program that runs in kernel space to interface to because all the layers below the application layer only talk to layers that are in kernel space which

negates your argument about trying to avoid complexity.

Morgaine wrote: On sensor networks, you miss the point despite it having been outlined clearly.  Just because a facility like TCP or HTTP already exists doesn't mean that it's always good to use it.  Horses for courses.  As I pointed out already, a protocol that uses a retransmission mechanism is not only of no benefit in the transmission of isochronous data but can actually add a negative contribution.

If the sensor network already uses these protocols it is very unlikely that they support any lower level interface and almost certainly do not support a MAC level interface. Uh, USB directly supports

isosynchronous communications (that is the bandwidth guaranteed part, and no they don't retransmit either). And it directly supports guaranteed latency when you need that in your sensor interface

engineering toolbox while still presenting you with a much less complex user level (not kernel level) API. See, it really is hard to make "logical" arguments when you don't know what (...) you are

talking about.

Morgaine wrote: And finally, even a non-ACKed upper protocol like UDP adds overhead of around one order of magnitude compared to MAC-level communications, which means your isochronous sampling is limited to being an order of magnitude slower.  That may or may not be adequate, again it's horses for courses.  An engineer doesn't use just a single tool, but employs a large toolkit of solutions and chooses them appropriately to the problem in hand.

See previous reply about isosynchronous USB. MAC level communications ? You have got to be kidding. I mean really Morgaine where in the world do you dream up this stuff. There is more

complexity to MAC level communications than you know (There is that darn almost complete lack of knowledge thing again).

Morgaine wrote: You seem to want an all-in-one debate instead of an engineering analysis of pros and cons.  Not interested.

No Morgaine, the only thing I am interested in is countering your illogical, non sequitur arguments about things you know little if anything about. I can see why you wouldn't be interested.

As I recall the original question which prompted this discussion the issue was communicating with simple external devices. So that means that we must consider the issues in implementing the system at both ends. Ignoring the reliability issues the RPi can use USB or TCP/IP over Ethernet with about equal facility.

There are modern micros with either Ethernet interfaces or USB host or device interfaces or all three readily available at low cost.

My experience is that it is reasonably easy to implement a low performance USB device or TCP/IP interface in software on such micros by using large chunks of ready made IP (free or paid for). I've done a lot more on the Ethernet side of things and would go that way if possible because:

longer cables

free 'wire' type debugging tools that will run on a cheap PC

faster data rates for less effort (10/100 Ethernet is easier hardware-wise than High Speed USB)

much nicer range of higher level protocols (TCP,UDP,FTP, HTML et etc)

ease of software debugging (you can make two processes on a single computer talk to each other by IP quite easily for testing)

Michael Kellett

Morgaine, thanks a lot for mentioning Ethernet in this discussion (and thanks to the original OP for bringing this subject up), I am a noob in all embedded and engineering but I never thought Ethernet could be a simple and inexpensive alternative; I always thought Ethernet in the mcu world means Arduino + Ethernet shield which is pretty expensive. Well, I also assumed you mean http when you mentioned Ethernet (which again shows my ignorance in this matter).

Given all this, can you please recommend some reading related to this subject, I would really love to learn more about it. I know I can find tons of resources on the net but I was wondering if you'd be kind enough to point me to some specific docs related to sensors (or boards), how could they talk to the Pi via Ethernet, how would the code look like.

I'd be grateful if you can point me to anything easier to read for a beginner like me and thanks in advance for taking the time.

I would like to add another missing alternative: wireless TTY, see:

http://shop.ciseco.co.uk/rf-module-range/

I'm planning a cluster of autonomous Arduinos programmed (Arduino IDE)and controlled wirelessly from a RPi.

Review available at :

http://goo.gl/SwoCA

I would like to add another missing alternative: wireless TTY, see:

http://shop.ciseco.co.uk/rf-module-range/

I'm planning a cluster of autonomous Arduinos programmed (Arduino IDE)and controlled wirelessly from a RPi.

Review available at :

http://goo.gl/SwoCA

I've got a little project on the go for a remote camera++++ so I'm using the new RPI cam but since this is outside and I needed to power the device anyway I've just taken the POE route so rather crudely I've taken the inner 2 pairs for the standard Ethernet  data and cut the other two pairs to feed a Jellybean 2A 5V regulator from off EBAY. I push 12ish Volts down the outer cores and nice sweet 5V comes out for the RPI and I get my data back all on a single and cheap cable.

Bury it Forget it ..Job done

Aggh almost forgot ...A buddy of mine is sending pics from his RPI and Arduino using a QRP SSTV rig so that's a valid alternative if you aint in a hurry!