• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 31 subscribers
  • Views 486 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Connect two Hercules for simple message

matteo lucarelli
Genius 3265 points
Other Parts Discussed in Thread: HALCOGEN, MAX232

Hi,

I've to connect two HDK board for a simple message exchange (some brief data and status chunk) with no particular timing requirement. Which is the lighter way to do this? SCI, SPI, UART? For lighter i mean the faster to implement in the software taking account also of the code generated by Halcogen. Better if the receiver is buffered to avoid any timing issue.

Thank you

  • 0
    TI__Genius 9015 points

    Hello Matteo,

    I have forwarded your question to one of our experts and they will respond soon.

  • 0
    TI__Guru 68920 points

    Matteo,

    I'd probably look at either SPI or CAN.    If you hadn't mentioned buffering I'd probably have said SCI.  But the buffering on the SCI module isn't a "FIFO" style buffer like on a 16550 UART, it's really intended to support LIN and it's got a fixed size.   So I'd probably avoid the SCI if I wanted buffering.

    SPI v.s. CAN.

    With buffering, it's MibSPI not SPI,  so let's start there.

    SPI is faster, but is intended as a chip to chip interface meaning on the same board or in a stack of boards.  You can of course send SPI data over a cable but that's stretching it's intended use.  If it's only a few inches of cable no problem but if you're considering this for a solution where later your system will have modules separated by a decent length of cable you might as well start out with CAN now.

    From a software standpoint I think both MibSPI (with buffering) and CAN are going to be about the same amount of trouble - assuming as you describe you're just sending a few messages with relaxed timing and you're not implementing some CAN standard protocol stack.

    CAN might be a little more work to 'debug' with an oscilloscope or logic analyzer whereas SPI is a little more 'raw' ... just clock & data - and single ended signals.  

    One reason you might really want to go CAN with the HDK is that the HDK includes CAN transceivers and nice 3-terminal blue screw connectors.   So you can just get a length of wiring,  screw the two boards togehter, and pretty much only worry about 'software'.   Whereas with SPI, you'll have to pick up the SPI pins from the 2mm board-to-board headers, come up with some type of cabling, and you might run into signal integrity problems that take time to resolve.

    Now on the other hand - if in the long run you intend to have 2 RM48's on the same board and just tie them directly together, no transceivers between them - then maybe you should go with MibSPI now since you will likely want to remove the transceivers on a single board solution (cost reasons) and then you'll have to eventually go to MibSPI anyway.

    Hope that helps.  

    EDIT: additional comment.  If you want to connect two MibSPI together and use the buffering, please make sure to at least connect clock, somi, simo, and one chip select.   Don't leave the chip select out because it's a point to point connection, this chip select is needed because of the way buffering works on the slave SPI.

  • 0 in reply to Anthony F. Seely
    Genius 3265 points

    Hi Antony,

    thanks for the useful informations. I forgot to mention a couple of fact:

    • the board I'll have to connect will ba one RM48HDK and one RM48(orTMS570) control card.
    • for diagnostic porpouse in the final system both of the board will require to be connected independenlty to a standard PC with the same channel

    So I need something available in the control card too (do this exclude CAN?) and on a PC. Probably the LIN/SCI is the most handy in this case. Isn't it?

    What's the difference between using the SCI and the LIN?

    Do the SCI/LIN is directly compatible with a serial RS232 on a PC? And what about the SPI in this case?

    Can I route the SCI to the USB port (the RM48HDK has two of them in addition to the mini USB used by the JTAG) in the same way as the debug terminal do with the debug console?

    Thank you

  • 0 in reply to matteo lucarelli
    TI__Guru 68920 points

    Matteo,

    Please be aware that if you try to connect the USB host port on the RM48HDK to the USB device (JTAG) port on the CNCD, while this will work you will need two different USB software components.  You'll need a CDC device driver for the CNCD - there is an example of such a driver with HalCoGen.  But on the host side (the RM48 HDK) you will need an USB host stack.  This is not a huge problem because the RM48 has an industry standard OHCI host controller, but you really will need a commercial solution.   Many of the commercial RTOS vendors on our third party partners list have USB host stacks available.

    If you always have a PC between the two boards you might be able to plug both boards into the PC as USB devices, and write some software on the PC that loops the two COM ports that they enumerate to together; using the PC as a bridge.  Haven't tried this but it might work.

    Otherwise, if you want to use UART the best approach is to use the 2nd UART (it's available on the HDK, not sure about the CNCD ... would need to check schematics) for the board-to-board link.

    SCI is compatible in terms of data frames with a PC UART, but not directly compatible at the electrical interface layer with a PC's RS-232 port.  You need an RS232 transceiver like MAX232 between the PC and the board's SCI port --or-- the more modern approach is the USB-UART connection.   But as I mentioned above, this USB-UART connection would be more complicated for board-to-board. 

    LIN is an automotive network - a lower bit-rate and reduced wiring cost alternative to CAN.  You can read about it from http://www.lin-subbus.org/ but if you're not already familiar with LIN this use case probably doesn't justify becoming famililar with it.  

    LIN doesn't directly relate to a PC's UART but on the MCU side we can implement LIN as an SCI plus a 'front end' so this is where SCI/LIN comes from.   SCI is the base UART and the LIN logic can be disabled so you can just use the SCI/LIN as a UART.

    You might look at Ethernet as an option if you want board to board,  board to PC, and buffering.   There's also no hardware work if you go this way as the CNCD and the HDKs both have Ethernet jacks. 

    The only thing I'd say about ethernet is that it doesn't fit you're 'simple software' requirement.   However, if I had to chose between Ethernet and USB for what you're doing I'd go with Ethernet because you'd only need one software component and it would be the same for the HDK and the CNCD rather than the USB case where you would need a USB host stack for the HDK and a device driver for the CNCD.   Ethernet is also directly supported by the PC,  you could simultaneously connect the two boards together and to the PC through a switch,  and you've got nice tools like 'wireshark' on the PC to monitor ethernet traffic.   

    But again you'd need a good TCP/IP stack.   We do have an lwIP stack example posted on the embedded processor wiki that works with FreeRTOS and HalCoGen, but it's not very mature and we've had trouble supporting customers with this example.   I'd really not suggest this but strongly suggest a commercial TCP/IP stack if you want to go this route.