Thank you for your reply Andy. Regarding the tricks you mentioned, I sure can increase the baudrate but I saw some people having trouble at the maximum speed. That is the main reason I chose a lower rate.

As for chopping the transmission, don't you think this strategy is less efficient since you multiply the sending operation? Of course putc() doesn't have to guess the length and type of the data but anyway, being on an sub triggered by an interrupt, I fear that the total time in that interruption could be a problem.

Additionally, if I were to add a timestamp to the sampled data (with a simple timer for example), how could I modify the code to remain time efficient?

Thanks again

Printf has to parse the format string, allocate an output buffer and then create the output string which then needs to be written to the serial port. A 32 bit number is potentially 9 digits long so your looking at writing at least that many bytes to the port. If you go over 16 bytes then you'll have to wait for some of the data to have been sent before you can put it all in the transmit buffer. On the other hand putc writes a single byte into the transmit buffer, assuming there is space this is very fast.

In other words the putc method isn't just slightly faster, it's a massive speed improvement.

You could easily add a timestamp, just keep the transmission size to a minimum. If the total message size is over the size of the hardware transmit buffer (16 bytes or less depending on the board) then use something like modserial to buffer the port of you'll end up blocking waiting for the transmit.

And do a sanity check on your baud rate, RS232 sends 10 bits per byte, make sure your message size multiplied by the measurement frequency is less than the baud rate.

I really appreciate your insight on that. My main concern regarding chopping the 32 bits is the timing. If the total message needs to be split up then the acquisition loop becomes more complicated then potentially lasts longer.

I took the "bypass" option (LPC_TIM3->TC) in that post https://developer.mbed.org/forum/mbed/topic/2365/ to get the timer count. Is there any equivalent low level operation for the printf issue?

This post https://developer.mbed.org/forum/helloworld/topic/2095/ mentions other ways to stream data to PC, would you recommend a different approach?

Regards,

The message isn't getting "split up" at all. RS232 sends data 1 byte at a time. The end result of what goes down the wire is identical for

putc('1');
putc('2');
putc('3');
<<//code>>
and
<<code>>
printf("123");

The only difference is how many CPU cycles are taken to send the data. If you split it up manually then at the very least you are saving a while loop which means it will be faster.

The low level version of printf would be to format the data yourself and then write the data into the UART tx buffer one byte at a time. putc() will have a more overhead than writing the buffer directly because it will also check that there is space and enable the transmit if needed but unless you need every last CPU cycle that overhead is worth it in exchange for the simpler code.

The downside to raw binary is there is no clear indication between values. Some sort of delimiter is probably a good idea (e.g. add a 0, 0xff of 0x55 byte at the end of the data) in order to give you a means of getting the two ends in sync. The value could show up in data but over time it would allow the two ends to sync up. A longer delimiter makes it easier to sync but means transmitting more bytes.

Text makes getting a sync between the two trivial but at the cost of a massive increase in message length.

As for other completely different methods, it depends on how much work you want to do and whether you need the data in real time. Generally they will add CPU overhead so it depends if you are bandwidth limited or CPU limited.

Thanks again for this clear explanation. It seems that putc() is a good trade-off and I will manage to get it to work the right way.

Initially, I wanted to have the data in real time. The mbed is hooked up with the ADC AD7190 that can go up to 4.8kHz, so there is the bandwidth limit. The mbed then just format the data before sending it as I prefer to log raw data to work on it without losing something.

I got fooled by that real time constraint that can more or less never be respected since the serial link is not a real time priority, thus the timestamp.