• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 594 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.

How do I convert from McBSP to RS-485?

Theresa Klein
Prodigy 100 points
Other Parts Discussed in Thread: ISO35, ISO15

I want to use the peripheral expansion on my C6713 DSK to communicate with a number of items attached to an RS-485 bus.

So far, I have configured the mcBSP as a UART and can talk to a daughter card using it. But to convert to RS-485, I need to be able to enable/disable the DE and RE (driver enable, receive enable) pins on the RS-485 chip.

However, with the UART code I got from the Driver Development Kit, it doesn't look like there is a signal available for that. (Maybe I'm missing something?)

Has anyone done this before (converted from mcbsp to rs-485), or is there a chip already available that can convert directly from mcbsp to rs-485 ?

 

  • 0
    Expert 1710 points

    I haven't implemented this before myself with a TI DSP / McBSP, and I don't know the pinout of your particular DSK board, however I have a couple of ideas that might help.

    Firstly, depending on the bus sharing protocol of your RS-485 network, you may be able to just toggle the driver enable pin using a general purpose I/O output signal via code and not require the UART/McBSP itself to support generating any kind of framing signal to enable the RS-485 driver output during transmission.  It is possible you could just set the driver enable signal, send your packet of data, then clear the driver enable signal via GPIO.  As for the receiver enable, that is sort of up to the system level collision detection and protocol requirements.  If it is acceptable or necessary for the DSP node to hear itself talk then you could potentially just force receive enable to always be true.  Then you could obviously receive other nodes' data as well as monitor the transmission of your own node's outgoing data on the bus via the local receiver.  If the local node was contending for the bus and collides with another node you could possibly see a data error in the bus data being monitored versus the local node's transmitted data queue due to multiple drivers being active on the bus. That may be a useful/required feature for your higher level protocols.

     

    As for a direct interface chip -- the first thing that came to mind after using a generic RS-485 to UART transceiver would be to use a RS-485 transceiver and UART integrated combination with a SPI or I2C interface.  For instance, MAXIM's MAX3140 is such a device.  Maybe it will do the RE/TE as you desire.

    http://www.maxim-ic.com/quick_view2.cfm/qv_pk/2033

    You could use some of TI's MSP430 microcontrollers which include a UART and a distinct SPI or I2C port to act as a single chip programmable interface between an I2C or SPI port and a UART output, though you would additionally need an RS-485 transceiver to interface to the UART port on the MCU in this case.  I suppose that the added programmability of the MCU chip could help implement your protocol in this case.

    TI's ISO35 is an isolated full duplex RS-485 transceiver, and the ISO15 is a half duplex model; there are other variants with various speeds and features in the series.  That might be useful if you need isolation and an external transceiver function to interface to an external UART/control port.

    http://focus.ti.com/docs/prod/folders/print/iso35.html

    In UART mode it wouldn't be uncommon to use auxiliary flow control / port signals such as might be used for DTR, RTS, et. al. to control GPIO functions like transmitter / receiver enable if you have such signal outputs available in the McBSP mode and interface your DSK implements.

     

     

  • 0 in reply to C. Hayes
    Prodigy 100 points

    Hmm. Yeah, I was thinking of just using one of the daughtercard control bits to turn on and off the driver enable.  That way I can leave the other McBSP alone. I think I could probably get away with leaving the receiver on all the time, and just ignore any packets not intended for the DSP board.

    I was just hoping maybe there was already existing code or a more elegant way of doing it.

    Second thought ... how do I set it up as a pipe or a stream, so I can use the higher-level API functions?