I would like to move relatively large amounts of data from my STM32F427 device to a remote PC. Speed wouldn't be an issue, if not for the distance, which is not known at this point, but assumed at least 15-20 meters up to a couple of hundred meters.
For my project I decided that 4 to 10 megabits should be sufficient to manage sending away of all the generated data before the next measurement cycle.
With the requirements in place, we can right away rule out interfaces, that do not work well over larger distances, such as SPI, CAN, I2C, UART (RS-232), USB. Wireless communications we'll not include at this time, because of reasons.
AFAIK this leaves us with either Ethernet or industrial RS-485. Ethernet is fast, works over relatively long distances, but it has complexity, cost and power consumption concerns along with it. Plus RS-485 is already used as a part of an existing infrastructure, so it would be nice to tap into that as an extra point in a multidop system.
According to Maxim app-note we should be able to get our 10Mbit within 30 meters and proportionally derating speed-wise with distance after that.
So, what is this RS-485? It's essentially a half-duplex (unidirectional) transmission line made out of 2 wires. The signal is differential, meaning, that it gets evaluated as a difference between two lines. Unlike this, RS-232, which is single-ended (i.e. ground-referenced) tends to pick up noise on data line, creating spikes. These spikes might get interpreted as a binary 1, where it shouldn't be. Differentional signalling picks up this noise with both lines and thus it gets ignored as a common-mode noise. More about this you can read in all about circuits article.
Anyhow, let's stick with RS-485 for now. As with any communications network (even point-to-point communications are a network, just a very simple one), it consists of two ends - transmitter and receiver. Both of these ends should support data rates.
Let's look at our application end - it's an STM32F427 MCU, which has 4 USART peripherals, of which 2 (USART1 and USART6) are clocked from APB2 with maximum of 90MHz. With 8x oversampling, we get maximum throughput of about 11.25 Mbit, which fits our bill. But that's USART at 3.3V. But we want RS-485! Well, we'll have to have an external converter there. MAX3460 is a 20Mbps transceiver, which should be able to convert our USART signal into proper set of RS-485 signals (2 pairs for TX and 2 pairs for RX). All it requires is a bypass cap and an extra signal for TXE.
PC end also requires something, that is able to receive RS-485 at these speeds. We cannot just feed it into a COM port. We could follow similar scheme of having a RS-485 transceiver followed by a serial-to-USB converter. Except most of the converters (e.g. FT232 or PL2303 based) are not capable of handling such data rates. At least, not according to the specs. FTDI reports support for baud rates up to 3Mbps, which is way too short. So, el-cheapo converters are out of the question. As it turns out, FTDI has FT2232H chip, which supports up to 12Mbaud. In comparison, it's not as cheap as regular FT232 - 29$ on digikey or 19$ on ebay, but I guess I could give it a try. Not many other choices are there.
Once I get the parts, I'll definitely try it out and write a report on it.
For my project I decided that 4 to 10 megabits should be sufficient to manage sending away of all the generated data before the next measurement cycle.
With the requirements in place, we can right away rule out interfaces, that do not work well over larger distances, such as SPI, CAN, I2C, UART (RS-232), USB. Wireless communications we'll not include at this time, because of reasons.
AFAIK this leaves us with either Ethernet or industrial RS-485. Ethernet is fast, works over relatively long distances, but it has complexity, cost and power consumption concerns along with it. Plus RS-485 is already used as a part of an existing infrastructure, so it would be nice to tap into that as an extra point in a multidop system.
According to Maxim app-note we should be able to get our 10Mbit within 30 meters and proportionally derating speed-wise with distance after that.
So, what is this RS-485? It's essentially a half-duplex (unidirectional) transmission line made out of 2 wires. The signal is differential, meaning, that it gets evaluated as a difference between two lines. Unlike this, RS-232, which is single-ended (i.e. ground-referenced) tends to pick up noise on data line, creating spikes. These spikes might get interpreted as a binary 1, where it shouldn't be. Differentional signalling picks up this noise with both lines and thus it gets ignored as a common-mode noise. More about this you can read in all about circuits article.
Anyhow, let's stick with RS-485 for now. As with any communications network (even point-to-point communications are a network, just a very simple one), it consists of two ends - transmitter and receiver. Both of these ends should support data rates.
Let's look at our application end - it's an STM32F427 MCU, which has 4 USART peripherals, of which 2 (USART1 and USART6) are clocked from APB2 with maximum of 90MHz. With 8x oversampling, we get maximum throughput of about 11.25 Mbit, which fits our bill. But that's USART at 3.3V. But we want RS-485! Well, we'll have to have an external converter there. MAX3460 is a 20Mbps transceiver, which should be able to convert our USART signal into proper set of RS-485 signals (2 pairs for TX and 2 pairs for RX). All it requires is a bypass cap and an extra signal for TXE.
PC end also requires something, that is able to receive RS-485 at these speeds. We cannot just feed it into a COM port. We could follow similar scheme of having a RS-485 transceiver followed by a serial-to-USB converter. Except most of the converters (e.g. FT232 or PL2303 based) are not capable of handling such data rates. At least, not according to the specs. FTDI reports support for baud rates up to 3Mbps, which is way too short. So, el-cheapo converters are out of the question. As it turns out, FTDI has FT2232H chip, which supports up to 12Mbaud. In comparison, it's not as cheap as regular FT232 - 29$ on digikey or 19$ on ebay, but I guess I could give it a try. Not many other choices are there.
Once I get the parts, I'll definitely try it out and write a report on it.
No comments:
Post a Comment