I want to implement low cost rs485-connected data collection nodes, and need to choose a microcontroller for them that will support baud rates of more than say 400 kbps, preferably up to 1 mbps. I know there are some PIC18Fxxxx's that have an "Advanced UART" that are claimed do this. Other alternatives?
- Chris
Almost any uC with a HW uart will do those Baud rates, so you should select more by pin count, and Analog performance. GoalAsic do a C51 variant with RS485 HW inbuilt, but most solutions have an external RS485 driver.
For small uC with good analog resources, see the Silicon Labs series - many have 2% Oscillators, so you can avoid Xtals.
The Philips LPC family have medium analog performances, and are available in 8/10/14/16/20/28/32 pins.
-jg
Having the terminals handle the rates is not the major problem. However getting a clean signal from point to point is another matter. You should first do some experiments with the actual wiring and line terminations etc, put some signals on and see how they appear at various points. Haul out the scopes. Watch out for how the lines get turned around.
The protocols you use will also make a major difference.
--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
USE worldnet address!
Thanks for the information, to all who replied. What characteristics of the protocol affect the rate? What are examples of fast ones? Ones that are simple to parse?
I imagine a usart with a large buffer would also help, especially for short bursty messages?
- Chris
"Christopher Graham" skrev i meddelandet news:azmEd.39740$Xk.27116@pd7tw3no...
need
The AT91SAM7S32 Series has dual UART with some nice features for RS-485.
Production parts have entered the fab, but will only be available in a few months
- Takes 3-4 months normally,
-- Best Regards, Ulf Samuelsson ulf@a-t-m-e-l.com This is a personal view which may or may not be share by my Employer Atmel Nordic AB
If you can limit the speed below 250 kbit/s, the slew-rate limited RS-485 transceivers could be used, with a reduced risk of all kinds of EMC problems.
Profibus-DP is essentially asynchronous characters over RS-485, thus following those wiring rules should give good results on any RS-485 bus. Profibus-DP is not very picky about the hardware up to about 1.5 Mbit/s, but running it at 12 Mbit/s @ 100 m requires quite a lot attention to the details (minimal intermediate node stub length, series inductors in each node connector to compensate for the stub stray capacitance etc.).
The critical parameter is the transmitter turn off. Preferably, this should be handled directly by the UART hardware, if not, an interrupt should at least be available, when the last character has _actually_ been transmitted. It should be noted, that on 16550 UART clones, an interrupt is available only when the last byte has been inserted into the Tx-shift register and you have to constantly poll for a separate status bit to check when the last stop bit of the last byte has actually been sent, before turning off the transmitter.
Depending of the kind of application, constant polling at the last character may or may not be an option. Thus, it is very important to check the behaviour of the internal UART before selecting the micro controller.
In any high speed half-duplex system, the Tx/Rx and Rx/Tx turnaround delays are critical for any decent throughput. In a multidrop network, each node listens to all the traffic, but is only interested in messages addressed to it, thus, some processing power is lost monitoring the line in order to skip uninteresting data, so that the next addressing information can be detected. Thus, the protocol should be designed in such a way that nodes that are not addressed, can skip whole messages without too much processing.
Paul
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.