0

I have the following problem:

A micro controller with the possibility to talk with PC via several communication interfaces: RS232, USB are present. Ethernet is not available. The software is bare metal with optional embedded OS.

The hardware is not important as this is applicable to any microcontroller and physical communication interface.

Several communication channels are needed simultaneously:

  • 1 for a simple console - debug purpose: uC <-> PC
  • 1 for getting real time samples from the ADC to PC: uC -> PC
  • 1 for sending real time samples from PC to DAC: PC -> uC
  • 1 setting different parameters of the acquisition/conversion, start/stop, etc: uC <-> PC

Ideally only one physical interface should be used RS232 or USB (preferable).

Is there something already available to multiplex different channels on a single physical one ? message passing, remote procedure call.

Trygve Laugstøl
  • 7,440
  • 2
  • 36
  • 40
c george
  • 1
  • 1
  • 1
    You can design a protocol to perform all of those tasks over almost any communication link. – kenny Dec 29 '12 at 12:32
  • 1
    You start out saying that there is no possibility to communicate with a PC, and then ask how to communicate with one!? The difficult we can do right now, the impossible will take a little longer. Did you rather mean perhaps that your microcontroller has no available communication peripheral? Another way of reading this is that you have no microcontroller at all. Please clarify or the question is likley to get down votes I fear. – Clifford Dec 29 '12 at 12:44
  • 1
    You may have biased responses by tagging FreeRTOS and USB while stating in the question that any connection and any or no OS is acceptable. You should probably review those tags or the question since they are at odds with one another. – Clifford Dec 29 '12 at 12:55
  • @Clifford. I suspect there is a missing period between USB and Ethernet, ie, RS232 and USB are available, Ethernet is not. – Chris Stratton Dec 29 '12 at 18:05
  • Yes, sorry for that, RS232 and USB are available. Ethernet is not. – c george Dec 29 '12 at 18:38
  • -->Hardware: What features do you need? acquisition rate? amount of data? amount of IO? signal quality? Economic budget? When talking about something ready to use, referred to? a generic SoC? or a full custom ASIC? You need real parallel processes? -->Software: I think the solutions with SLIP frame recommended by @Clifford is correct. – RTOSkit Dec 29 '12 at 22:21
  • @RTOSkit: to be fair src mentioned SLIP before me; the duplication was because he posted while I was typing. – Clifford Dec 30 '12 at 08:53
  • then 1 "up" to src, seems weird but sometimes the structural form of a answer sounds better than another despite having the same content – RTOSkit Dec 30 '12 at 19:22

3 Answers3

4

If you have an IP stack on the uC, then you can probably use SLIP or PPP to communicate through a serial link. On the other extreme, if you have a barebones system take a look at those protocols and things like HDLC because you will end up implementing something similar.

src
  • 541
  • 2
  • 6
  • @cgeorge: No doubt you'll have Googled it by now: [OSHLDC](http://sourceforge.net/projects/opensourcehdlc/). – Clifford Dec 30 '12 at 09:00
  • @cgeorge Sorry but I don't know. In the systems I've worked with, the embedded part was either a fat system with ethernet and IP stack or, when using a serial line like in your case, the client demanded a custom protocol, so we have to write it from scratch (and the board vendor provided the drivers for the OS we were using, RTEMS). – src Dec 30 '12 at 09:06
2

An obvious choice would be to use a TCP/IP stack. Each open "socket" is independent of any other and a link can support multiple simultaneous connections.

TCP/IP can be transported over Ethernet or over a serial connection via PPP or SLIP. A an asynchronous serial connection (COM port) can be emulated over USB by implementing a CDC/ACM class device, however if your device is to be released commercially you will need a USB vendor ID.

Some sort of multi-threading kernel may make handling multiple connections simpler, but is by no means necessary.

Clifford
  • 88,407
  • 13
  • 85
  • 165
  • The micro controller is not very powerful, arm @ 50Mhz. What is the typical footprint of an tcp/ip stack, and runtime overhead ?, Can you recommend an opensource tcp/ip stack implementation ? Thanks. – c george Dec 29 '12 at 18:46
  • TCP/IP can be lightweight, the memory footprint is probably the significant factor. Take a loop at [lwIP](http://savannah.nongnu.org/projects/lwip/) for example. – Clifford Dec 30 '12 at 08:56
-1

RS232

Almost nobody still ships RS232 on a PC/Notebook.

Is there something already available to multiplex different channels on a single physical one?

You aleady mentioned that you wanted to use USB, which supports multiple pipes on a device, called endpoints. The USB standard allows up to 32, but a specific micro controller may have implemented less endpoints, or has restrictions on endpoint types.

On the PC (Host) side you can use WinUSB or LibUSB to access these pipes.

Edit:

I use USB-to-RS232 converters personally, they can work but I must advise rather strongly against them for new designs:

  • Different USB Port can result in different COM port number
  • Unplugging a USB2COM while the port is "in use" results in COM port not working when replugging
  • Many driver issues on cheaper converters
  • Good luck trying to find Win8 drivers for older adapters
  • The 1ms USB frame time can negatively impact some RS232 protocols

All problems are minor, but you can avoid them when using USB directly.

real time samples

This raises the question of available bandwidth, where USB ususally has 12 MBit/s (or even 480 on some high-end micros). Most USB-2-RS232 adapters max out at 460800 or 921600 Baud.

Turbo J
  • 7,563
  • 1
  • 23
  • 43
  • This would almost be a good answer, and raises the possibility of using USB itself as a channel multiplexer. However the initial complaint about RS232 not being supported on recent machines is a bit misleading, since converters are widely available, inexpensive, and routinely used for this. Replacing that with a caution to test the RS232 implementation with a USB/serial converter would be more helpful - because the greater latency of such converters over more closely coupled legacy serial ports can indeed sometimes cause problems with the way software might try to use the channel. – Chris Stratton Dec 29 '12 at 18:09
  • Yes, I like the idea with usb and the multiple pipes ... the problem is that I only have 2 endpoint pairs on the device ... in this case this translates to only 2 channels ... not enough, one idea would be to use one channel for an CDC console, and the other to multiplex the rest of the channels. – c george Dec 29 '12 at 18:52