LeafLabs Garden

A place to share, learn, and grow...

1. 

   Adam
   Member

   Here's some preliminary results for some serial send performance testing I've been doing with an Orone Mini F3 connected to a Mac OS X 10.8 laptop.

   I can get about 50KB/s from a stock Maple Mini.
   I can get about 300KB/s (about 2.4 Mbit/s) from an Orone Mini F3 using an FTDI FT232H board connected to Serial 1 (USART 1) using a Python program that uses the FTDI virtual com port drivers via PySerial. It's limited by Mac OS X kernel serial driver.

   I can get about 447KB/s (almost 3.6 Mbit/s) from an Orone Mini F3 using an FTDI FT232H board on Serial 1, using a Python program that does not use the FTDI virtual com port drivers, but instead talks directly to the FTDI chip via the PyFTDI module.

   I'll post detailed results and code tomorrow.

   It seems like I should be able to get the F3's USARTs to do almost 9Mbit/s, as that is what the STM32F303 reference manual says the hardware supports. The FT232H can do up to 12Mbit/s.

   But I run into problems if I set a baud rate on the Serial port that is higher than 4.5Mbit/s - the Orone Mini F3 hangs immediately. Does anyone know what might be wrong? I've looked at the usart.c file in the ibmaple/stm32f3/usart.c file - there's a max baud rate specified there, and I've changed that to

   .max_baud = 9000000UL,

   But that doesn't seem to stop the hangs.

   Does anyone have ideas on how to get closer to the maximum baud rate? For my application, I need to get about 8Mbit/s.

   Update: it looks like the F1 and F3 have different ways of setting the baud rate - since the F3's USARTs are much faster. Looks like I will need to set the OVER8 (oversampling bit) in the USART status register, and calculate the dividers differently. I will check that out tomorrow...

   Posted 2 years ago #
2. 

   ventosus
   Member

   iirc, .max_baud = ... is only used in wirish to check for valid baud rate arguments, but not in libmaple. If you set up USART from wiriish, this has to changed indeed.

   Note, maximal baud rate depends on the clock domain of the peripheral: only USART1 is on the APB2 clock domain (72MHz), the other USARTs are on APB1 (36MHz).

   To change oversampling from the default 16 to 8, only setting the OVER8 bit will not do, as the divider (USARTDIV) must be written to the BRR register in a specific way. This is not implemented (yet) in the F3-port.

   When OVER8 = 0, BRR [3:0] = USARTDIV [3:0]
   When OVER8 = 1, BRR [2:0] = USARTDIV [3:0] shifted 1 bit to the right. BRR [3] must be
   kept cleared.

   The following modified function is not tested, but may do the trick.

   
libmaple/libmaple/stm32f3/usart.c
---------------------------------

   void usart_set_baud_rate(usart_dev *dev, uint32 clock_speed, uint32 baud) {
   /* Figure out the clock speed, if the user doesn't give one. */
   if (clock_speed == 0) {
   clock_speed = _usart_clock_freq(dev);
   }
   ASSERT(clock_speed);

   int32 divider = clock_speed / baud;
   uint32 tmpreg = clock_speed % baud;
   /* round divider : if fractional part i greater than 0.5 increment divider */
   if (tmpreg >= baud / 2)
   divider++;

   if (divider < 16) { // OVER8
dev->regs->CR1 |= USART_CR1_OVER8;
divider *= 2;
dev->regs->BRR = (divider & 0xff0) | ( (divider & 0xf) >> 1);
}
else { // OVER16
dev->regs->CR1 &= ~USART_CR1_OVER8;
dev->regs->BRR = (uint16)divider;
}
}


   Posted 2 years ago #
3. 

   ventosus
   Member

   EDIT: this should read:

   dev->regs->BRR = (divider & 0xfff0) | ( (divider & 0xf) >> 1);

   Posted 2 years ago #
4. 

   Adam
   Member

   ventosus,

   Thank you! I got it to work - I didn't see your post until now, but I wrote this very similar code instead in libmaple/stm32f3/usart.c:

   `
   void usart_set_baud_rate(usart_dev *dev, uint32 clock_speed, uint32 baud) {
   /* Figure out the clock speed, if the user doesn't give one. */
   if (clock_speed == 0) {
   clock_speed = _usart_clock_freq(dev);
   }
   ASSERT(clock_speed);

   if (baud <= 4500000UL) {
   // default is 16x oversampling mode
   uint32 divider = clock_speed / baud;
   uint32 tmpreg = clock_speed % baud;
   /* round divider : if fractional part is greater than 0.5 increment divider */
   if (tmpreg >= baud / 2)
   divider++;

   dev->regs->BRR = (uint16)divider;
   dev->regs->CR1 &= ~USART_CR1_OVER8;
   } else {
   /* use 8x oversampling mode to get faster speeds

   When OVER8==1
   – BRR[2:0] = USARTDIV[3:0] shifted 1 bit to the right.
   – BRR3 must be kept cleared.
   – BRR[15:4] = USARTDIV[15:4]

   */
   uint32 divider = 2*clock_speed / baud;
   uint32 tmpreg = 2*clock_speed % baud;
   /* round divider : if fractional part is greater than 0.5 increment divider */
   if (tmpreg >= 2*baud / 2)
   divider++;

   uint16 brrValue = ((uint16)divider & 0xfff0) | (((uint16)divider & 0x0f) >> 1) ;
   dev->regs->BRR = brrValue;
   dev->regs->CR1 |= USART_CR1_OVER8;
   }
   }
   `

   Re: clock domains, yes, I re-read the clock section of the F3 reference manual and see you are right. I am currently using USART1 so that was just lucky I guess. I will change my code to make sure you can only use the higher baudrates on USART1.

   But the code above works with USART1, and I can get the serial port to set the baudrate up to 9Mbit/s. I would like to send you a pull request for this when I've fixed it up - will you let me know if you do want that?

   Now my problem is sending characters fast enough. The usart_tx() routine can only hit about 3.4Mbit/s. That's still too slow for me.

   I wrote a DMA to USART program, based on Marti's USART to DMA program. This can do about 5.3Mbit/s. Still too slow.

   Now I'm trying to figure out where the bottleneck is - in my DMA to USART program, or in the PyFTDI driver. I seem to be able to send FTDI to FTDI (with no flow control) at about 6.3Mbit/s - quite a bit faster but still not fast enough.

   The F303 reference manual implies that the DMA to USART approach should be able to transmit at the full rate of the USART, 9Mbit/s. I need to look at my programs to see what's actually happening.

   I have a couple of STM32F4 boards that are clocked at 168MHz. I may try this experiment with one of them to see if the faster clock speed makes a difference. There's the hassle of getting the F4 code working, though... I haven't gotten the F4 boards to work with libmaple yet...

   Posted 2 years ago #
5. 

   Adam
   Member

   In case anyone's interested in the code...

   Here's the DMA to USART program:

   https://github.com/adamfeuer/maple_performance_testing/blob/master/maple/usart_dma.cpp

   Here's the write buffer to USART program:

   https://github.com/adamfeuer/maple_performance_testing/blob/master/maple/send_standard_blink_serial_buf.cpp

   Here's the PyFTDI Python program that reads from the PyFTDI chip via USB 2.0 HS:

   https://github.com/adamfeuer/maple_performance_testing/blob/master/python/receive_data_pyftdi.py

   Posted 2 years ago #
6. 

   ventosus
   Member

   @Adam, testing and pull-requests are more than welcome.

   Posted 2 years ago #
7. 

   gbulmer
   Moderator

   Adam - excellent progress!

   I have always assumed that the baud-rate includes start and stop bits.
   So a UART using one start and one stop bit, 9Mbaud would be 7Mbit/s data, a loss of more than 20%.

   " I seem to be able to send FTDI to FTDI (with no flow control) at about 6.3Mbit/s"
   Is that the High-speed FTDI, or the Full-speed FTDI?

   Posted 2 years ago #
8. 

   Adam
   Member

   @ventosus, I will send you a pull request with the working OVER8 code along with the Serial1 higher speed.

   @gbulmer, I was testing with a FTDI UM232H module, which has a FTDI 232H chip. It was in USB 2.0 high-speed mode. Re: the stop and parity bits, yes considering that it's pretty close to the max the STM32F303 can do.

   I wish ST would come out with an STM32 chip with an on-chip USB 2.0 HS PHY. But they don't have one yet. The SAM3X8E has an on-chip USB 2.0 HS PHY, and has a 4KB buffer too...

   So I just set up a similar test on the Arduino Due (using a slightly modified version of this code: http://forum.arduino.cc/index.php/topic,154424.0.html).

   I reliably get about 3.6MB/s from the SerialUSB interface on the Arduino - 28.8 megabits/s !

   So for my current needs, it looks like a SAM3X8E-based board using Arduino software is probably the way to go...

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.