Shop OBEX P1 Docs P2 Docs Learn Events
Serial Port Communication with multiple Props and 1 serial port — Parallax Forums

Serial Port Communication with multiple Props and 1 serial port

ryfitzger227ryfitzger227 Posts: 99
edited 2013-06-12 11:51 in Propeller 1
Hello everyone!

I have another thread on here that I started a while back about Timing on a prop, but I wanted to look into something that I will need in the future of the project.

The project I'm working on will require 3 Propellers and 2 BS2s. All of those microcontrollers will in some way be communicating to a VB program. Instead of taking up 5 serial ports, and using 5 USB cords, I wanted to come up with a way to use just one USB cord and serial port to communicate & program all 5 of this chips.

I think I have found a solution. A TUSB2077A (http://www.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=366&uiTemplateId=NODE_STRY_PGE_T). - I will also have another board that has 4 BS2s on it. I'll use the TUSB2046B for that one.

I was just had a few questions about a couple of things. Would these ICs even work? Do I need one FTDI Chip, or one for each microcontroller? Has anyone ever worked with these ICs? If so, any information would be helpful!

I would basically just like everyones opinion on here on how to do this. If you have another idea, I'm open for suggestions!

Comments

  • prof_brainoprof_braino Posts: 4,313
    edited 2013-05-28 18:32
    There are probably a couple ways to do this, I am only familliar with doing this in propforth, which support multiple communications channels over one physical line.

    I would also suggest skipping the TI chip, (less parts is cheaper) as props can communicate directly (as a single giant prop with many cores) using MCS. MCS is simillar to Bean's multi-prop high speed communications, except MCS includes protocol. If you use propforth + MCS, there are 32 channels by default, and only one physical cable is needed. One has to also have appropriate software on the PC side, the stuff that come with propforth is the Go Language serial driver, but you could make your own serial interface in any language you choose.
  • ryfitzger227ryfitzger227 Posts: 99
    edited 2013-06-11 13:14
    prof_braino wrote: »
    There are probably a couple ways to do this, I am only familliar with doing this in propforth, which support multiple communications channels over one physical line.

    I would also suggest skipping the TI chip, (less parts is cheaper) as props can communicate directly (as a single giant prop with many cores) using MCS. MCS is simillar to Bean's multi-prop high speed communications, except MCS includes protocol. If you use propforth + MCS, there are 32 channels by default, and only one physical cable is needed. One has to also have appropriate software on the PC side, the stuff that come with propforth is the Go Language serial driver, but you could make your own serial interface in any language you choose.

    I don't want to get too complicated with this, that's why I chose that TI chip. My thought was that I could just make a couple of connections on the TI chip and then connect the D+/D- of FTDI chip to the correct pins on the TI chip. I thought that was the simplest option. I want to make this look somewhat professional, so I don't want to just go out and buy a USB hub from Walmart. I would like to create my own USB hub and just incorporate that onto the same PCB.

    Another thing that needs to be thought of is how to assign ports. I'm pretty sure with the BS2 you could just do something like {$PORT COM7} at the top of the program. How would you do that with the Propeller? In the VB program the COM ports are assigned in the code and can't be changed by the user.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2013-06-11 17:35
    ryfitzger227 wrote: »
    I don't want to get too complicated with this, that's why I chose that TI chip. My thought was that I could just make a couple of connections on the TI chip and then connect the D+/D- of FTDI chip to the correct pins on the TI chip. I thought that was the simplest option. I want to make this look somewhat professional, so I don't want to just go out and buy a USB hub from Walmart. I would like to create my own USB hub and just incorporate that onto the same PCB.

    Another thing that needs to be thought of is how to assign ports. I'm pretty sure with the BS2 you could just do something like {$PORT COM7} at the top of the program. How would you do that with the Propeller? In the VB program the COM ports are assigned in the code and can't be changed by the user.

    Sorry to say this but your configuration sounds like a total mish-mash as you have five serial ports mixed with Props and BS2s and you are depending upon fixed com port numbers over USB in Windows!!! When Windows enumerates USB coms ports it ends up giving each unique FTDI chip it's own comport number. Even though you could mess around and lock that device to a particular serial port it doesn't help when the device is replaced as you have to go through that exercise again.

    First off, why the mix of Props and BS2s? There are two very different types of firmware to maintain for one device plus using Props makes it a little easier to multiplex the coms. I would simply common all the receives together to the one FTDI chip and then tie all the transmits together via series resistors. The receive cog would detect a device select sequence (perhaps even just a $F1..$F5) so that it would buffer all data and enable the transmitter. This is assuming that you have control of the VB source and certainly that would simplify things.

    An alternative to this is to have a Prop dedicated solely to muxing 5 comports to one.

    I don't know if this is a one-off or there are more but you could lock down the serial# of the FTDI so that changing units would not necessitate reconfiguring the Windows coms ports.

    Just some thoughts.
  • jmgjmg Posts: 15,173
    edited 2013-06-11 18:12
    ryfitzger227 wrote: »
    I want to make this look somewhat professional, so I don't want to just go out and buy a USB hub from Walmart. I would like to create my own USB hub and just incorporate that onto the same PCB.
    .

    Just buy a USB hub to at least test your idea, & system, they are cheap enough ?

    I presume you want to connect USB-Star because all boards are supplied as modules, all with USB included ?
    So you are making a motherboard to take all these modules ?

    If all boards do not HAVE to use USB, but can use 3.3V Serial, then you can time-share a single FTDI-USB, by coding all
    modules to have the same protocol state engine. That costs SW, but not a huge amount.

    All units listen and parse the same RXD stream, and only ONE replies, to a packet for it.
    The TXD replies logically AND merge, to feed into the FTDI.RXD

    Typical of this is something like
    [startsymbol][Length][Address][Message]

    All units trigger on [StartSymbol] and extract Length. If Address is not them, they continue to count receive bytes until length.
    Then they go back to Wait on Start.


    ryfitzger227 wrote: »
    Another thing that needs to be thought of is how to assign ports. I'm pretty sure with the BS2 you could just do something like {$PORT COM7} at the top of the program. How would you do that with the Propeller? In the VB program the COM ports are assigned in the code and can't be changed by the user.

    This is why you need to try it. Windows shuffles COM ports, and a HUB gives it more to shuffle....
    Try it on various PCs and confirm how the whole system 'comes up', and then change a FTDI config slightly, and check again.
    Usually that moves the serial port in Windows.

    If the user does not change ports, your PC SW will need to go looking and verify the port is what it hopes it is.
    That can get tricky if OTHER products are on still more serial ports...
  • kwinnkwinn Posts: 8,697
    edited 2013-06-11 18:25
    I think Peter's suggestion of using a prop as a serial concentrator for the 5 serial ports and then passing the data to the PC via the FTDI chip is the simplest way to go.Most of the prop software you would need is already available, although you may need to tweak it a bit. Two cogs running copies of the four port serial object would take care of most of the communications.
  • Peter JakackiPeter Jakacki Posts: 10,193
    edited 2013-06-11 18:32
    kwinn wrote: »
    I think Peter's suggestion of using a prop as a serial concentrator for the 5 serial ports and then passing the data to the PC via the FTDI chip is the simplest way to go.Most of the prop software you would need is already available, although you may need to tweak it a bit. Two cogs running copies of the four port serial object would take care of most of the communications.

    Even using the single channel objects you would use 6 cogs plus one running Spin to manage the data and still have a "silver bullet" left over! Love the Prop.
  • kwinnkwinn Posts: 8,697
    edited 2013-06-12 11:51
    Peter Jakacki wrote: »
    Even using the single channel objects you would use 6 cogs plus one running Spin to manage the data and still have a "silver bullet" left over! Love the Prop.

    Yep, got to love the flexibility and adaptability the 8 cogs, deterministic timing, and software peripherals give you.
Sign In or Register to comment.