one of those places to look for these 'complicated' stuff is ethernet
https://www.microchip.com/en-us/product ... ernet-phys
https://www.ti.com/interface/ethernet/p ... rview.html
https://www.broadcom.com/products/ether ... poe/copper
https://www.digikey.com/en/products/fil ... eivers/710
but that those would be ethernet 10/100 mbps ethernet is quite common, and so is 1 gbps these days.
some of the bigger stm32 chips e.g. stm32f405 has a built-in mac and can interface a ethernet phy over the mii, rmii interface
I've been thinking about serializing and deserializing NRZI signals in software e.g. using spi
https://www.engineersgarage.com/signal- ... -part-5-6/
well there are 'cheap' transceivers, you can literally buy them
https://www.onsemi.com/products/interfa ... s/USB1T11A
https://www.onsemi.com/download/data-sh ... t11a-d.pdf
I can figure out how to connect stm32 to e.g. usb1t11a usb fulls speed transceiver 12 Mbps
the thing is the signals that I'd receive is usb NRZI signals and I need to do the complicated "serial interface engine" part.
Trouble with this is I've seen quite a few VHDL designs say for FPGA to do that "serial interface engine"
but there is no easy 'software' methods to do NRZI, bit stuffing, signalling end of packet using 'single-ended-zero' (pull both differential lines down to zero) etc
note also that Ti has various LVDS serializers / deserializes, some of which goes up to gigabits speeds
https://www.ti.com/interface/lvds-m-lvd ... rview.html
those may be worth looking up in case there is something that works
as for usb, I'd guess stm32's native hardware (e.g. some bigger chips F4xx like F405/F407, etc are likely the most cost-effective and fuss free options if you want to simply use that chip and do a usb-host, you would need a usb hub, but I'd guess that is easy, then that all the down stream usb devices can be practically any stm32 with usb. usb does what is practically time division multiplexing, with the host polling every port at 1 ms intervals, if you have 10 devices including the hub, that 12 mbps bandwidth gets divided by 10.
there is also high speed usb 2.0 480 Mbps, but that is like ethernet and requires an external usb 2.0 high speed ulpi transceiver and interfacing.
this is also mainly supported by the 'bigger' chips
High Speed Serial
Re: High Speed Serial
@DrBanana
e.g. for stm32f103 rm0008 reference manual
https://www.st.com/resource/en/referenc ... ronics.pdf
chapter 27 Universal synchronous asynchronous receiver transmitter (USART) pg.584 onwards
interesting sections are
27.3.3 Receiver
Figure 284. Data sampling for noise detection
it shows the 16x oversampling by uart to recover the bit
27.3.4 Fractional baud rate generation
Tx/ Rx baud = pclk / (16 * USARTDIV)
Only USART1 is clocked with PCLK2 (72 MHz max). Other USARTs are clocked with
PCLK1 (36 MHz max).
accordingly USARTDIV is a 'fractional' divisor, but that assuming that you use integers, and that you can only use uart1
then that the fastest baud rates is 72 mhz / 16 = 4,500,000 baud
if integer 2 is used, that is 72 / ( 16 x 2) = 2,250,000 baud
I'd like to suggest that the transmitting end (could be downstream) should use 2,250,000 baud or 4,500,000 baud exact (not 2.5 Mbaud).
This is so as to match the maximum integer divisor baud rates achievable on stm32.
Then as the uart process 1 byte (8 bits) at a time, that works out to be 281,250 bytes per sec for 2.25 Mbaud and 562,500 bytes per sec at 4.5 Mbaud.
Based on my various experiences with interrupts, ISR max out in the low 100s k interrupts per seconds, e.g. with stm32f103 ADC, timer interrupts driven adc aquisition max out at below 500 k samples per sec, and my Timer ISR only did 1 thing which is to write a single bit SW_START in an ADC register to start the next sampling. processing interrupts from uart (i.e. serial receive) certainly cannot catch up as it does more than 1 single instruction to write a register.
This practically means that you need to resort to DMA. To use DMA, I'd guess the better approach is to use say like stm32cubeIDE, generate the codes, google for tutorials on the web on how to do that. Then copy those codes back into stm32duino sketches. The catch is that you may need to review where and how to 'disable' the uart codes as you won't be using HardwareSerial i.e. the Serial() api that is in Arduino. You could also review Serial() codes to see if you could adapt that in your local copy.
but what is more important is this, I take a look at a better chip stm32f411ce
https://www.st.com/resource/en/datashee ... f411ce.pdf
this chip has APB2 that can go up to 100 Mhz
this is available from WeAct in a nice well made high quality board
https://github.com/WeActStudio/WeActStu ... iSTM32F4x1
the ref manual is rm0383 STM32F411xC/E advanced Arm®-based 32-bit MCUs
https://www.st.com/resource/en/referenc ... ronics.pdf
19 Universal synchronous asynchronous receiver transmitter (USART)
19.3.4 Fractional baud rate generation
Equation 1: Baud rate for standard USART (SPI mode included) = Pclk / ( 8 × ( 2 - OVER8 ) × USARTDIV )
USARTDIV is an unsigned fixed point number that is coded on the USART_BRR register.
• When OVER8=0, the fractional part is coded on 4 bits and programmed by the
DIV_fraction[3:0] bits in the USART_BRR register
• When OVER8=1, the fractional part is coded on 3 bits and programmed by the
DIV_fraction[2:0] bits in the USART_BRR register, and bit DIV_fraction[3] must be kept
cleared.
what is quite interesting is the ability to select 8x oversampling vs 16x oversampling on a stm32f411
using 16 x oversampling and using APB2 at 100 Mhz and a usartdiv = 1 that gives
baud rate = 100 x 10^6 / 16 = 6,250,000 baud (6.25 Mbits per sec ) !
and using 8 x oversampling
baud rate = 100 x 10^6 / 8 = 12,500,000 baud (12.5 Mbits per sec ) !
this is in line with the spec sheets
https://www.st.com/en/microcontrollers- ... 411ce.html
and with the same reasoning use fixed integer divisible baud rates e.g.
16x oversampling
baud rates
USARTDIV = 1 -> 6,250,000 baud (6.25 Mbaud)
USARTDIV = 2 -> 3,125,000 baud (3.125 Mbaud)
USARTDIV = 3 -> 2,083,333.333 baud (2.08333... Mbaud)
8x oversampling
baud rates
USARTDIV = 1 -> 12,500,000 baud (12.5 Mbaud)
USARTDIV = 2 -> 6,250,000 baud (6.25 Mbaud)
USARTDIV = 3 -> 4,166,666.66 baud (4,166,666.666... Mbaud)
USARTDIV = 4 -> 3,125,000 baud (3.125 Mbaud)
at these high baud rates exact baud rate matching from the other end is critical, it needs an exact match, not even missing a beat
the parts about DMA remains relevant
but you could nevertheless try some luck, e.g. using an exact baud rate of 3,125,000 baud (3.125 Mbaud) on the stm32f411 with those plain old interrupts on stm32f411 (f4xx) maybe with some luck it may work without DMA, but no promises, finger crossed
if these works, stm32 are very good rs485, rs422 devices. those baud rates compared to *old* 9600 baud stuff are 'astronomical'
you need *hard core* good quartz crystals to drive the cpu clocks on those stm32s e.g. stm32f411 etc and paying attention to the
*wire* the electrical signals stuff (e.g. exact integer baud matching) to practically achieve it I'd think. sloppy signals I'd think won't make the Mbps grade.
it may take a scope to work those lines at those speeds, a bit of stray capacitance can round all those signals to look more like degraded sine waves than bits travelling along the wire.
As your preferred baud rates is in the 'moderately mid/high' Mhz baud rates, I took a closer look at the reference manualsDrBanana wrote: Mon Jan 06, 2025 3:19 pm Yes thats exactly what I want at the end. I need to read some data from a sensor thats using RS485 NRZ with 2.5Mhz rate. I cant change baud rate because its hard coded in sensor.
Is there any chip I can use that handles all this ?
e.g. for stm32f103 rm0008 reference manual
https://www.st.com/resource/en/referenc ... ronics.pdf
chapter 27 Universal synchronous asynchronous receiver transmitter (USART) pg.584 onwards
interesting sections are
27.3.3 Receiver
Figure 284. Data sampling for noise detection
it shows the 16x oversampling by uart to recover the bit
27.3.4 Fractional baud rate generation
Tx/ Rx baud = pclk / (16 * USARTDIV)
Only USART1 is clocked with PCLK2 (72 MHz max). Other USARTs are clocked with
PCLK1 (36 MHz max).
accordingly USARTDIV is a 'fractional' divisor, but that assuming that you use integers, and that you can only use uart1
then that the fastest baud rates is 72 mhz / 16 = 4,500,000 baud
if integer 2 is used, that is 72 / ( 16 x 2) = 2,250,000 baud
I'd like to suggest that the transmitting end (could be downstream) should use 2,250,000 baud or 4,500,000 baud exact (not 2.5 Mbaud).
This is so as to match the maximum integer divisor baud rates achievable on stm32.
Then as the uart process 1 byte (8 bits) at a time, that works out to be 281,250 bytes per sec for 2.25 Mbaud and 562,500 bytes per sec at 4.5 Mbaud.
Based on my various experiences with interrupts, ISR max out in the low 100s k interrupts per seconds, e.g. with stm32f103 ADC, timer interrupts driven adc aquisition max out at below 500 k samples per sec, and my Timer ISR only did 1 thing which is to write a single bit SW_START in an ADC register to start the next sampling. processing interrupts from uart (i.e. serial receive) certainly cannot catch up as it does more than 1 single instruction to write a register.
This practically means that you need to resort to DMA. To use DMA, I'd guess the better approach is to use say like stm32cubeIDE, generate the codes, google for tutorials on the web on how to do that. Then copy those codes back into stm32duino sketches. The catch is that you may need to review where and how to 'disable' the uart codes as you won't be using HardwareSerial i.e. the Serial() api that is in Arduino. You could also review Serial() codes to see if you could adapt that in your local copy.
but what is more important is this, I take a look at a better chip stm32f411ce
https://www.st.com/resource/en/datashee ... f411ce.pdf
this chip has APB2 that can go up to 100 Mhz
this is available from WeAct in a nice well made high quality board
https://github.com/WeActStudio/WeActStu ... iSTM32F4x1
the ref manual is rm0383 STM32F411xC/E advanced Arm®-based 32-bit MCUs
https://www.st.com/resource/en/referenc ... ronics.pdf
19 Universal synchronous asynchronous receiver transmitter (USART)
19.3.4 Fractional baud rate generation
Equation 1: Baud rate for standard USART (SPI mode included) = Pclk / ( 8 × ( 2 - OVER8 ) × USARTDIV )
USARTDIV is an unsigned fixed point number that is coded on the USART_BRR register.
• When OVER8=0, the fractional part is coded on 4 bits and programmed by the
DIV_fraction[3:0] bits in the USART_BRR register
• When OVER8=1, the fractional part is coded on 3 bits and programmed by the
DIV_fraction[2:0] bits in the USART_BRR register, and bit DIV_fraction[3] must be kept
cleared.
what is quite interesting is the ability to select 8x oversampling vs 16x oversampling on a stm32f411
using 16 x oversampling and using APB2 at 100 Mhz and a usartdiv = 1 that gives
baud rate = 100 x 10^6 / 16 = 6,250,000 baud (6.25 Mbits per sec ) !
and using 8 x oversampling
baud rate = 100 x 10^6 / 8 = 12,500,000 baud (12.5 Mbits per sec ) !
this is in line with the spec sheets
https://www.st.com/en/microcontrollers- ... 411ce.html
and with the same reasoning use fixed integer divisible baud rates e.g.
16x oversampling
baud rates
USARTDIV = 1 -> 6,250,000 baud (6.25 Mbaud)
USARTDIV = 2 -> 3,125,000 baud (3.125 Mbaud)
USARTDIV = 3 -> 2,083,333.333 baud (2.08333... Mbaud)
8x oversampling
baud rates
USARTDIV = 1 -> 12,500,000 baud (12.5 Mbaud)
USARTDIV = 2 -> 6,250,000 baud (6.25 Mbaud)
USARTDIV = 3 -> 4,166,666.66 baud (4,166,666.666... Mbaud)
USARTDIV = 4 -> 3,125,000 baud (3.125 Mbaud)
at these high baud rates exact baud rate matching from the other end is critical, it needs an exact match, not even missing a beat
the parts about DMA remains relevant
but you could nevertheless try some luck, e.g. using an exact baud rate of 3,125,000 baud (3.125 Mbaud) on the stm32f411 with those plain old interrupts on stm32f411 (f4xx) maybe with some luck it may work without DMA, but no promises, finger crossed
if these works, stm32 are very good rs485, rs422 devices. those baud rates compared to *old* 9600 baud stuff are 'astronomical'
you need *hard core* good quartz crystals to drive the cpu clocks on those stm32s e.g. stm32f411 etc and paying attention to the
*wire* the electrical signals stuff (e.g. exact integer baud matching) to practically achieve it I'd think. sloppy signals I'd think won't make the Mbps grade.
it may take a scope to work those lines at those speeds, a bit of stray capacitance can round all those signals to look more like degraded sine waves than bits travelling along the wire.