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

Like many others, I've used the GPIO header for LEDs.  Very quick and easy at the device register level, except for having to sudo unless you want to write a device driver.  If you don't want a cable, it's easy to make a PCB sandwich.

USB is attractive, and I intend to come up the learning curve on USB software one of these months.  RasPi has known USB issues with lost packets in some cases, so you must make sure your application can handle lost packets, for example by using a high-level protocol like TCP that retransmits lost packets.

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.