This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Connecting Multiple TMS570s to Labview

Hi,

I'm looking to connect around 10 TMS570s to a laptop running Labview,  the TMS570s will occasionally need to take commands from Labview, however for the majority of the time the TMS570s will just need to transmit data back to Labview.

The data rates will not push any of the communication peripherals offered by the TMS570, it is more a concern of getting data from all the different TMS570s in a speedy manor without congestion or getting garbled.  Another concern I suppose is the ease at which this can be implemented but the most important is obviously data integrity.

I've done a search to see if a similar question has been asked but it turned up no results; so, does anyone at TI or in the community have any experience or opinions on how this can be best addressed.

Kind regards,

Alan Day 

  • Hello Alan,

    We have done similar setups here at TI for device validation and testing. In our case we developed a large "mother board" that could handle 12 devices at a time. Each device socket had it's own unique ID based on a jumper configuration for socket number and mother board number. We designed the system to be expandable in that we could daisy chain multiple mother boards together so that the combination of mother board number and socket number would identify the specific device communicating.

    From the communication side, we used CAN so that each device could transmit information on the bus with device specific IDs helping to indentify which bucket to place the data when received by the host PC. For efficiency, we had a sequence setup where the host could send a specific message ID that would trigger an auto reply from the devices so that the host could identify which devices were present/active and optimize associated timeouts, data storage, etc. In our case, we didn't really care much if a particular device socket was empty and a failure to respond indicated a device failure without errors or retries being generated so it had no impact on the other devices on the bus/under test. You may care more about this and would have to design your protocol accordingly.

    Since CAN already has built in arbitration and bus fault handling, this proved to be a good approach. For enhanced testing we could assign specific CAN message groups to execute specific tests and respond with results that were logged by the host PC.

    Hope this helps with some ideas.

  • Hello Alan,

    Did we sufficiently answer your question? If so, could you validate the answer so we may close the thread?