Serial protocol for sending image data

0
votes

We have a custom-built microcontroller card (ST32 / ARM Cortex M3) which has a camera attached. The camera captures 10-bit greyscale at 1280x1024 resolution. We need to send that image data back to a PC host over serial. That's quite a big chunk of data; at 115200 baud transfer would be 3 minutes, assuming everything goes fine. Anything I implement to ensure robustness would seem to slow that process down (eg split into blocks, checksum the blocks, ask for resend if corrupt). So was wondering how people might make a good compromise between speed and integrity.

We are currently seeing real transfer times of about 6 minutes. We had to set the UART baud rate at a weird value - 1036800 - because at 115200 there were issues (PC is running at 115200). I'm more software than hardware so any thoughts as to why that might happen would be helpful!

2
serial-portembedded
Your baud rate calculation is off by a factor of 9. Perhaps you have one of the 72 MHz parts which uses a x9 PLL from an 8 MHz clock, and have the constants in your calculation based on the assumption that the PLL is active, but are actually running (or at least clocking the peripherals) without the PLL, 9 times slower than your calculation assumes. Or maybe you have a prescaler active on the peripheral clock - Chris Stratton

2 Answers

5
votes

Start by doing some easy compression on your image.

Either run-length encoding or delta encoding will give you less data to send.

There are much better algorithms like TIFF but you may want to trade off the complexity of TIFF-ing your buffer for easier software on the embedded side.

Then you can afford something simple like Xmodem for your compressed data.

That has the useful property of being a standard protocol too.

That might lead you to using a terminal+xmodem transfer style interface to your host. That would make debugging the interface pretty simple too.

4
votes

Tim Williscroft's answer about compressing your data is a nice first step.

Now from the serial protocol side, the real transfer rate depends a lot on how you configure and implement your software both side. The baud rate is not the only thing to care about:

  • Are you using hardware flow control? If using hardware flow control, you will be able to significantly increase the baud rate (x10) without generating overrun errors.
  • From the STM32 are you using DMA, interrupts or even worth polling method to manage the data transmission? I don't know the exact STM32 reference you are using but on the STM32 I used, the UART transmission FIFO was limited to 1 byte. So you are merely obliged to use DMA if you have performance issues.
  • Still from the STM32 side, you can greatly improve performances taking care on the bus accesses (and possible conflicts arbitration) your application is doing.
  • Moreover on STM32, all clocks are configurable. Using an external high speed oscillator (if one available on board) may be a good way to improve performance over the internal RC oscillator. Also take care about internal bus clock configuration!
  • Now from the PC side, the performance may be impacted depending how your application bufferize & treat the received data.

The first thing to do is to look where the time is taken: Observe your UART signal with a scope. As you said the transfer takes twice the theoretical time, you shouldn't see a continuous signal. Without hardware flow control it is the STM32 that takes time to output data. With hardware flow control, also look at the flow control signal to determinate which side causes the pauses (it may be both).