How can I get 1-10MB/s of debugging data to and from a dev board?

Here's the fundamental problem I have: I'm looking at a dev board for, say, a TI/AD/Microchip microprocessor or DSP. This is long before a full product design; we're talking proof-of-concept work here. I want to send data from a PC to be processed by my firmware, or have my firmware send data to my PC. And I want the rate to be of the order of 1-10MB/s.

15+ years ago, 1-10MB/s would have been quite niche. kB/s would have been more usual, and the dev board would have had a DB9 connector on it. I could have just plugged a serial cable between the dev board and my PC, perhaps with a USB-to-serial converter, and read and write to COMX or /dev/ttySX.

However, this scheme has a number of limitations that are now starting to show up:

• I want MB/s, not kB/s.
• The absolute max UART rate a 100MHz device could manage is still only 0.7 MB/s. SPI on the other hand allows up to 3-4 MB/s.
• It's incredibly rare for PCs to come with serial ports now, so specialised adaptors are needed to interface with a PC eg. USB to serial cable.

But I'm stumped for what I could use to replace the old serial scheme. The main context for this question is sending serialised debugging data between vendor dev boards and a PC before design is finalised, so anything requiring secondary devices eg. Bluetooth isn't super useful. The µPs I typically work with are in the realm of TI's MSP430, Microchip's PIC32M*, and low power DSPs like the TI C55x or C674. Their dev boards might typically come with headers connected to SPI/I2C/UART peripherals.

Ethernet would require full implementation of a networking stack, which isn't really practical on the constrained DSPs or µPs I often work with. Furthermore most PCs only have one ethernet port, if at all, so you wouldn't be able to use it for wired networking.

Ground-up USB requires getting a vendor ID from a 3rd party, and reinventing all sorts of wheels at the driver and software level just to get data from one device to another.

Ideally I'd like to just be able to dump bytes in a peripheral register on my µP and drain it using Python on the PC or vice versa, using a cable most IT departments would have lying around, and get 1-10 MB/s. A bonus would be not having to poll every available port of whatever kind to find the device on a PC. Is this possible?

• Is this for: development debugging, or field diagnostics by a programmer, or field diagnostic by a technician with limited training? – Nick Alexeev Aug 25 '17 at 4:11
• @NickAlexeev Let's say development debugging. I'm looking for something that's easy to do on a "typical" dev board; field diagnostics would involve the final product where we could eg. design in a high speed FTDI chip connected via I2C. Make sense? – detly Aug 25 '17 at 4:14
• Serial to USB are cheap and common with many available comm drivers. What better universal host solution do you need ? The FT602 is a FIFO interface to SuperSpeed USB (USB 3.1 Gen 1) USB Video Class (UVC) bridge chip – Sunnyskyguy EE75 Aug 25 '17 at 4:36
• @TonyStewart.EEsince'75 Ideally I want something where I don't have to design a separate PCB and get it manufactured. All the FTDI USB-to-header cables I could find use the FT234XD, which only goes up to 3 Mbaud or ~3-400kB/s. – detly Aug 25 '17 at 4:43
• what's wrong with buying a USB2 or USB3 adapter? – Sunnyskyguy EE75 Aug 25 '17 at 5:43

Modern successor for a RS232 communication port is supposed to be USB. However, people need to realize that if it is used for debug purposes, it must have some serious architecture support at system level, the port must have some internal bridges to uP registers and memories.

Starting in 2002, Intel has made an attempt to implement mandatory debug functions into open-standard EHCI controller. There was even some support for it, from Linux and Microsoft side, although, as I understand, all the effort had limited success.

With an advent of USB 3, the effort was resurrected, see USB 3.1 Debug Class Specifications.

Most recent Type-C connector also defines "Debug Accessory Mode", see pp 59-60. I believe there are several auxillary verions in the works on how to use the pins in alternate way, including JTAG functionality.

However, the old RS232 is not going away and refuses to die. The reason is that most uP and mini-OS are relying on venerable COM ports for many functions, and all Linux/Android flavors have a built-in debug support in kernel. And the UART circuitry/port is fairly simple to implement in silicon with very few resources. However, instead of placing bulky DB-9 connectors (which sometimes are bigger than the device itself) people are embedding a UART-USB converter on-board (typically of FTDI type), and use the miniature u-A/B USB connectors to attach to debug host, emulating COM port and using standard terminal software to access it.

• I'm sorry, I should have been clearer with what I meant by "debugging". I wasn't talking about break-and-step level debugging, but higher level serialisation of state and data eg. dumping samples of audio, states of a state machine, etc. – detly Aug 27 '17 at 4:36

I assume you are talking about a UART or serial interface, RS232 is an electrical and pin standard (simply defines what voltage levels a one and a zero are but not the state changes, protocols, speeds, etc).

Not sure where you got the 160000, you can easily go much faster than that with a cheap ftdi part. As well as fast jtag, swd, spi, i2c, etc with the same part (one with mpsse). (or roll your own protocol).

Depends on what your definition of PC is, desktops are dead, laptops are dying (all being replaced by tablets and phones), the primary PCs remaining are servers and they typically have at least one serial port as that is the primary display interface for booting/debugging, etc. But I know what you mean.

With the general lack of a need for RS232, usb to uart works just fine for a primary debug from a host/development pc against a target embedded board/system/chip.

For the ones you mentioned you can out run at least some of them with a usb uart solution so the MCU is the bottleneck there. Of the parts available you are more likely to find ones with uarts than with usb, certainly not ethernet. Your number one interface is uart, the ftdi parts and probably others make it easy to access any vendor specific or standardized protocols, or wiggle strap pins so you can use the uart to program the part in circuit. These vary from custom protocols (avr xmega), to stock spi while in reset (avr if I remember right), uart (msp430, a number of other brands/models), jtag, swd for the cortex-ms, all with a simple ftdi breakout board.

uart still dominates as generally having the lightest footprint on the bootloader. ethernet as you pointed out requires a stack, even cheating with UDP, you still need way more code than checking the receive buffer not empty bit and reading an already processed byte out of a uart peripheral. usb, if the mcu has it may be mostly done in hardware, so there are some that it is a lightweight thing but you often still have to enumerate yourself and respond to the host when requested, possibly more work than a dumbed down udp stack (the ones I have used it is other than the EZ-USB 8051).

You can get up to a MB/s with uart on some devices, but faster than that you are going to have to build a stack usb or ethernet or custom.

• I'm going to address things in separate comments here, hope you don't mind. Good catch on the RS232 thing, I do that a lot because they used to be so synonymous. Fixed in the question. – detly Aug 29 '17 at 3:11
• The 16kB/s figure was an error, it should have been 0.69 MB/s (for a 100MHz DSP with a min. 16 divisor for UART baud and 8-N-1 protocol). – detly Aug 29 '17 at 3:17
• Re. FTDI parts - I have used such parts in products before, and I agree they're very useful. But my problem concerns those times when I'm nowhere near that stage yet... when I'm looking at different dev boards, trying to establish proof of concept, etc. I don't really want to spend time designing Yet Another Breakout PCB that'll fall apart before the next project starts! I mean, if I have to, I have to... but if there's a cable or ready-made board, I want that! – detly Aug 29 '17 at 3:21
• Re. the dying PC - sure they're not driving sales like they used to, but I think they're far from dead, especially in the context of development and design. However, even engineers need our laptops, and the trend there is fewer connectors of fewer different types. – detly Aug 29 '17 at 3:22
• the bus pirate is basically an ftdi breakout board. you dont have to re-design anything, though one breakout board can work for all projects just like a screwdriver move it from one to another. – old_timer Aug 29 '17 at 4:03

If the MCU is a Cortex-M you could look at Segger's J-Trace or J-Link and use it with RTT. RTT is a kind of a terminal-over-JTAG. The MCU places data in a RAM buffer and the debugger polls it. They advertise a speed of 3 MB/s.