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

Thank you all for your views. I knew this post would be little bit controversial, and eventually it went little bit ofcouse but the fun part is its still knowledgeable.

Being and embedded person and my exploration on RPI has made me to conclude that all the lower levels interface like more led's, switches other sensors should not be connected to RPI directly. To better understand this I would like to bring an example.

Suppose I want to make a robot using RPI, I can make a motor driver breakout and connect it directly to RPI and ofcourse code on RPI is no big deal, But RPI is much more computational power to just drive a motor and thus i want to put all this motor control and small sensor stuff to a companion board attached to my RPI. Thus RPI can focus on algorithmic claculation part (Putting ROS or Open CV).

Now with 8 bit microcontroller i would not have much option with USB and Ethernet, I now there are alternative avaiable but i feel its overkill for 8 bit. RS232 comes handy in this case. I can convert  RS232 to USB CDC using FT232RL or CP2102 or some other option.

I would futher like to create an open interface for RPI to communicate with expansion board.

Hence a good interface

Bhaumik Shah wrote:

 

Suppose I want to make a robot using RPI, I can make a motor driver breakout and connect it directly to RPI and ofcourse code on RPI is no big deal, But RPI is much more computational power to just drive a motor and thus i want to put all this motor control and small sensor stuff to a companion board attached to my RPI. Thus RPI can focus on algorithmic claculation part (Putting ROS or Open CV).

 

Now with 8 bit microcontroller i would not have much option with USB and Ethernet, I now there are alternative avaiable but i feel its overkill for 8 bit. RS232 comes handy in this case. I can convert  RS232 to USB CDC using FT232RL or CP2102 or some other option.

I wouldn't bother with an 8-bit micro in the 21st Century.  ARM Cortex-M0 (or M0+) chips are really cheap, and you can just write 32-bit C code without worrying about 8-bit nonsense.  If you need serious real-time motor control, the ARM Cortex-M4 is a nice architecture.  I'd look at the NXP LPC4350 dual-core which has both a Cortex-M4 and a Cortex-M0, so the first can be used for hard real-time and the second can be used for communication and supervision.  The STM32 F3 and F4 series are very nice as well.  I need to take a look TI Stellaris LM4F120 (Cortex-M4) one of these days.  All those Cortex-M4 chips have hardware floating point.

Another nice alternative to 8-bit is the 16-bit TI MSP430.  If I remember correctly, its instruction set is based on the PDP-11, so old timers can write programs while bathing in an sea of nostalgia.

USB is a nice way to talk to them, but SPI would probably work well and keep software really simple.

Bhaumik Shah wrote:

 

Suppose I want to make a robot using RPI, I can make a motor driver breakout and connect it directly to RPI and ofcourse code on RPI is no big deal, But RPI is much more computational power to just drive a motor and thus i want to put all this motor control and small sensor stuff to a companion board attached to my RPI. Thus RPI can focus on algorithmic claculation part (Putting ROS or Open CV).

 

Now with 8 bit microcontroller i would not have much option with USB and Ethernet, I now there are alternative avaiable but i feel its overkill for 8 bit. RS232 comes handy in this case. I can convert  RS232 to USB CDC using FT232RL or CP2102 or some other option.

I wouldn't bother with an 8-bit micro in the 21st Century.  ARM Cortex-M0 (or M0+) chips are really cheap, and you can just write 32-bit C code without worrying about 8-bit nonsense.  If you need serious real-time motor control, the ARM Cortex-M4 is a nice architecture.  I'd look at the NXP LPC4350 dual-core which has both a Cortex-M4 and a Cortex-M0, so the first can be used for hard real-time and the second can be used for communication and supervision.  The STM32 F3 and F4 series are very nice as well.  I need to take a look TI Stellaris LM4F120 (Cortex-M4) one of these days.  All those Cortex-M4 chips have hardware floating point.

Another nice alternative to 8-bit is the 16-bit TI MSP430.  If I remember correctly, its instruction set is based on the PDP-11, so old timers can write programs while bathing in an sea of nostalgia.

USB is a nice way to talk to them, but SPI would probably work well and keep software really simple.

John wrote: Personally, I'd be leery of supplying more than 1A through the RasPi Micro USB power jack.  Not only is the USB connector limited as you pointed out, but we don't know the current capacity of the 5V traces on the RasPi PCB.

True, the only thing we know for sure is they are good for at least 1A.

John wrote: Also, most Micro USB cables can just barely supply RasPi's 700 mA. Above that the voltage drop across the

Micro USB cable could easily be too much.

I don't know about the most part. I have found a couple that have very little measured voltage drop and for

full specification compliance they "should" support full current. Many obviously don't. What I have found

is the very flexible ones tend to have the small thin conductors wrapped around a multi-thread (as in cloth)

string used for strain relief.

I have also found several 1.2A to 1.5A supplies with micro USB connectors. If the power supply is rated this

way, the power cord should support it.

John wrote: If I had an add-on board that needed more than 300 mA at 5V I'd consider putting a 5.5mm barrel connector on the add-on board and letting the add-on board power RasPi through the GPIO connector.  The FTDI RasPi expansion module does this: http://www.ftdichip.com/Products/Modules/RPi.htm

Yes, that works for me too, but I don't know if the 5V trace run to the expansion connector can handle the 700mA needed by the Raspberry Pi either. I have not seen anything

about the PCB artwork being released. Has that been mentioned by the RPF ?

John wrote: USB is a nice way to talk to them, but SPI would probably work well and keep software really simple.

I don't have much working experirence with SPI but what I do know is that it is much faster than serial, lots of people use it, most if not all SOC's and microcontrollers

support it, lots of ICs (D/A, A/D, sensors, etc.) support it, and it should work as well as any of the alternatives previously discussed. The only minor quibble I have with

SPI is the need for seperate select lines (one more wire) when multiple channels are needed. Not much of a problem really. And high speed versions of I2C have

about the same list of goodies as I provided for SPI and should work also.

So many serial busses, so little time.

Gary Stewart wrote:

 

John wrote: Also, most Micro USB cables can just barely supply RasPi's 700 mA. Above that the voltage drop across the  Micro USB cable could easily be too much.

 

I don't know about the most part.

 

...

 

Yes, that works for me too, but I don't know if the 5V trace run to the expansion connector can handle the 700mA needed by the Raspberry Pi either. I have not seen anything  about the PCB artwork being released. Has that been mentioned by the RPF ?

Yes, the "most" is an over-statement.  However, quite a few Razzers have had bad Micro USB cables and it's a common source of frustration of the form: "I have tried x power supplies, and I still can't get TP1-TP2 above 4.2V".  The reality is that when you order a Micro USB cable over the Internet you have no idea if it's made out of AWG 28 or AWG 36.  So it's one of those known potential problems I try to avoid.

I have read of a number of Razzers powering their RasPis using the GPIO connector and never heard of a trace burning out.  I think I recently read that RPF is planning to release artwork soon, but I can't find where I saw it (grumble).  The smart thing would be for RPF to release schematics and artwork before manufacturing so extra eyes can find problems like the silly notion of removing F1 and F2 entirely.  Maybe they fear that the signal/noise ratio would be too small.