What is the best way to communicate with Parallax Propeller?

[RodneyFulk]

I am a newbie and waiting for my First QSB which should be here in a couple days.

I know little about hardware so I am sorry if my question is simple.

My plan is to use the I.MX53 QSB to communicate with a series of Parallax Propeller processors but i am curious what the best way to do this is? I will be using a network of Propellers as sensor interfaces to collect information and possibly control relays and also communicate with specialized devices such as GPS or ODBII. I will also have multiple cameras that will be interfaced to Propellers as well. These Propeller connected cameras will mostly just capture the feed and then upload that data to the QSB.

SO what I am wondering here is what type of connection should I be looking at to communicate with these Propellers? If you are unfamiliar then a similar setup would be an Arduino.

The vast majority of information should be simple text data such as the data from a GPS or other low bandwidth data but there is also the potential of fast data dumps such as the video. The data will be collected on the much slower Propeller systems and I will likely hook up a SATA hard drive to the QSB to store the video but most other data will be used in real time.  Theoretically these cameras may also provide a live feed to the QSB if I can figure out how to make it all work.

Thanks for any help!

[KrishnaPavan]

You will have to use Ethernet, for large data transmissions.

UART will not help.

[RodneyFulk]

Thanks for the rapid responses guys. I believe the USB and I2C seem to be the most used interfaces.

I will be using this in an automotive environment to make a very sophisticated security, utility and convenience "application".

At this time I expect the only thing requiring any substantial bandwidth is downloading of the video but that can be done at any time. If I actually provide a live feed it will likely be just one camera at a time. The Propeller chips have lots of GPIO pins and should work as specialized device controller. For instance if I totally computerize the HVAC system in my truck I will do it all from the Propeller and all that the i.MX will need to do is be able to tell it to set a certain temp, make changes to the mixture, turn on the A/C etc.

So sounds like to do simple controls and get back small amounts of response the I2C communications should work but if I want to get into dumping a 1 gig video file or provide a live feed I should provide a USB connection for that.

I also realize that at some point I may go beyond the capabilities of the i.MX53 QSB and will have to consider the newer i.MX6 processor but for now the i.MX53 is much better supported and I can atleast do some development work now to figure out what is possible and what is not before I start designing the whole system to find half of it won't work out as planned.

Mark, by chaining USB hubs are you saying I can only have 4 hubs? so if I have 4 connections to each hub I could have a maximum of 16 connections? I may use a mixture of I2C and USB depending on the bandwidth required if that makes sense.

Again thanks! Especially Mark for a lead on some other things to research. My hardware skills are pretty basic. I understand what capacitors, resistors, transistors, diodes are etc.. But get much beyond that and I get lost easy. I started a technicians class but didn't get to far. Things like voltage dividers and pull up/down resistors or anything much more involved and I need help.

[TheAdmiral]

I took a look at the P8X32A datasheet, and the pin description table lists P30 and P31 supporting serial UART communications. It looks like I2C is only to interface with EEPROM. In addition, the Typical Connection Diagram shows the UART signals being sent to a serial-to-USB converter.

I don't think that a straight I2C or Serial UART backbone will have enough bandwidth to do what you want, with several processors attached. Therefore, I am think that your best bet would be to convert all the serial UART signals coming out of each processor to USB. Freescale has a chip to do this: USB2SER. This will allow the USB structure to assign unique IDs to each processor for communications purposes, and allow the Quick Start board to act as master of the USB bus.

How you would combine all USB devices to connect to the Quick Start board is up to you, but one possibility, if you are using one PCB, is to route the traces directly (no connector) to a hub USB chip (SMSC USB2514 is an example). Then you could attach one USB cable from that board over to the Quick Start board. If you have several separate boards, put one USB cable connector down on each, route the cables to an external hub, then route to Quick Start board. Your are allowed to have four hubs in chain, so you should be able to device something that works.

If you are going to need more bandwidth than USB allows, you are going to need to go to Ethernet. And that will get expensive.

Mark

[JorgeRama_rezRi]

Hi Rodney,

The i.MX processor has different types of communication protocols integrated, for example: USB, I2C, SPI. To be honest, I'm not acquainted with the Parallax processors, but I took a quick look at the website and seems like the P8X32A-M44 and P8X32A-D40 only have I2C communication, so you can use one of the I2C ports available in the QSB to communicate with your Parallax processor.

Best regards.

Jorge.