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:

 

... and of course this is exactly what the Internet of Things is already engaged in doing...

Personally, I think the "Internet of Things" (IoT) should be called the "Internet of Digital Things" (IoDiT).  I think the latter acronym -- with a small permutation -- captures the concept very nicely.

I do like Ethernet, but it's costly, complex, and IMO overkill for applications that USB does well.  I rather like USB at the physical and packet layers.  I have yet to delve into USB software, which so far looks like Software Engineering with Cats.  Toot!

John Beetem wrote:

 

I do like Ethernet, but it's costly, complex, and IMO overkill for applications that USB does well.

It used to be costly, but it is no more.  As long as your project isn't literally counting pennies (and some really are, so fair enough there), the cost differences are minimal, and easily pay for themselves in extra functionality.

I'm not an expert in USB so I can't compare its complexity properly with that of Ethernet, but Ethernet is extremely simple, and what little I do I know of USB suggests that it is extremely complex despite being so limited.  I think it had a role in its day, but frankly I don't understand why we're still using it when Ethernet is so much better.

And finally, overkill ... well that's like saying that USB is overkill when we could be using the simpler RS232.  I don't think the "overkill" concept really means much in this context, but if we have to use the term then I'd say that USB is overkill when Ethernet does the job.

Moraine said: and what little I do I know of USB suggests that it is extremely complex despite being so limited

Yea you really should read up on the subject, otherwise your "logic" may be flawed.

1) With USB you can guaranty the amount of bandwidth needed will be avaialable (within the amount available of course) which you can not do with Ethernet.

2) With USB you can guaranty latency (at least to the millisecond, although this also depends on the processor of course) which you can not do with Ethernet.

3) Most of the "complexity" is in the driver where it belongs.

Actually, Ethernet and IP has mechanisms for marking your hi-pri traffic.

Latency can easily be sub-millisecond on same-network.

However, often it is possible to design (depends on the use-case) so that you don't

need high bandwidth or low latency.

Personally I'm a fan of RS232-like asynch protocols and Ethernet.

USB has its uses too of course.

IoT will see a lot more IP being used, with varying physical layers.

shabaz,

Yes but it can not and does not guaranty it. One problem with the USB latency/bandwidth guaranties is that on a

given host to device interface you can only guaranty one or the other, not both at the same time.

You can also use a USB interface exactly like you would with a RS-232RS-232 interface. I have a device I designed with

a microprocessor that only has a async serial port. The serial port is connected to an FTDI-232BM serial to USB

converter. It plugs into the host USB interface but the programming interface is just like any normal serial port. I

did this for several reasons. The microprocessor I was using did not have a USB interface. The USB interface

provides the power for the device, and by adding a RS232 level converter (on a header provided for this), it can

be used with a normal serial port too, although it then needs and external power supply. The sofware to use the

device is the same for both interfaces, only the /dev name is different depending on which one is being used.

Gary Stewart wrote:

 

Yea you really should read up on the subject, otherwise your "logic" may be flawed.

 

1) With USB you can guaranty the amount of bandwidth needed will be avaialable (within the amount available of course) which you can not do with Ethernet.

2) With USB you can guaranty latency (at least to the millisecond, although this also depends on the processor of course) which you can not do with Ethernet.

3) Most of the "complexity" is in the driver where it belongs.

Your points confirm what my limited knowledge of USB had suggested exactly.  USB has so much more built in that it is hugely more complex than Ethernet, which is just a very low level unverified frame transfer mechanism.

So neither was my logic flawed nor were the observations that my minimal acquaintance had suggested flawed, you've proved that they were spot on.  In contrast, your conclusion about their comparative complexity is clearly incorrect by your own observations.

Higher levels of protocol that ride on top of Ethernet are not Ethernet, and do not contribute to the complexity of Ethernet.  For what it's worth though, the complexity of upper layers is all in the kernel where it belongs and transparent to users and applications.

No Morgaine you logic is terribly and obviously flawed. 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. Otherwise you will

have to talk directly to the Ethernet driver at some slightly higher level of abstraction to remove hardware dependencies. This means that

at least part of the "user" interface you will have to write will run in kernel space probably as a loadable module and have to send data

back and forth between user and kernel space. Yea this is getting easier all the time (/sarcasm).

With USB, all the complexity you fear is in the host kernel driver as it should be. You only have to deal with the "easy" API which is

again, why such things exits. If you don't need all the complexity (guaranteed latency or bandwidth) or have a CPU that has trouble

handling it, you can use a much less complicated host kernel driver for it and still have the "easy" upper level API to deal with. This

is what USB OTG does. There are different, much, much less complex requirements for the device side driver. If you don't understand

what that means read up on USB. I don't have a hundred pages to explain it to you. So logically speaking of course, you do requre

knowledge of USB to make "logical" arguments, DUH.

P.S. Still waiting on the "logical" scientifically based engineering explanation of your data 100% reliability (your exact  somewhat stilted

       phrasing) requirement for the Raspberry Pi, or in your belief in its current availability on any other computer on Earth for that matter.

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.

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.