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.

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.