0

This question is about firmware for an 8 outgoing channels IR transmitter. It is a micro-controller board with 8 IR leds. The goal is to have a transmitter capable of sending streams of data using one or multiple channels. The data is delivered to the board over UART and then transmitted over one or multiple channels.

My transmitter circuit is faster than the UART, so no flow control is required.

Currently I have the channel fixed in the firmware, so each byte from the UART is transmitted directly. This means that there is no way to set the desired channel over UART, which is what I want.

Of course, the easiest solution is to append the data byte with a control byte in which each bit represents one channel. This had the advantage that each byte can be routed to one or more channels, but of course increases overhead dramatically.

Because of the stream type of transmission, I am trying to avoid a length field in my transmitter.

My research work is in the network stack on top of this.

My question is if there are schemes or good practices to solve this. I expect that similar problems are in robotics, where sensor data streams cross control signals all the time, but I could not find a simple and elegant solution.

Brian Tompsett - 汤莱恩
  • 5,753
  • 72
  • 57
  • 129
Lennart
  • 70
  • 1
  • 7

2 Answers2

1

Seems like the only sensible solution is to create a carrier protocol for the UART data. You might want this anyway, since UART has poor immunity to EMI. You can make it more reliable by including a CRC check to the protocol. (Please note that the built-in error handling of UART through start/stop/parity is very naive and very much outdated since the mid 70s or so.)

Typically these protocols go like <sync token> <header> <data> <checksum>, where the header may contain a data length and the data can then be of variable length.

Probably not an option at this point, but SPI would have been a much more pleasant interface to work with for this. You could then have one shift register per 8 IR diodes and select channel through the SPI slave select through some MUX/DEMUX circuit. Everything would work synchronously and no carrier protocol is needed. And it would completely remove the need for a MCU between the data sender and the diodes.

Lundin
  • 195,001
  • 40
  • 254
  • 396
1

I generally use the SLIP transmission protocol in my projects. It is very fast, easy to implement, and works very good to frame ANY packet you want.

http://www.tcpipguide.com/free/t_SerialLineInternetProtocolSLIP.htm https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=slip%20protocol

Basically, you feed each byte to be transmitted or received into a function that uses 0xC0 as both a header and a footer. Since 0xC0 is a valid byte in the data packet that you could be sending a few transformations are made to data bytes of 0xC0 in order to GUARANTEED that 0xC0 will only be a header and footer.

Then using the reverse algorithm on the other side you can frame the incoming data and look for 0xC0 twice in the right order. This signifies a full packet that will can be buffered up and flagged for main cpu processing.

The SLIP will guarantee the right framing of the packet.

Then it is up to you to define your own packet format that exists as the data field inside the SLIP packet has correctly framed the packet.

I often do the following...

<0xC0> ...<0xC0>

Use different opcodes for your different channels. You can easily add another layer with Acknowledgements if you want.

bassplayer142
  • 380
  • 2
  • 3
  • 15
  • Thanks for pointing in the SLIP direction! Especially the first link to tcpipguide.com is helpful. I added the SLIP layer and use it to indicate a new frame. The first three bytes of every frame select the channel. After this, we can send any number of bytes until the end-of-frame character. After this character, it is possible to do a new channel selection. The trick is the encoding of the special character which completed my solution. – Lennart Dec 06 '14 at 15:35