UART multiprocessor communication

[davidwang1969]

Posted on May 15, 2010 at 12:21

UART multiprocessor communication

#lmgtfy #uart-multi-communication #uart-multi-communication #uart-multi-communication #stm32-uart-usart #lmgtfy:-stm32-resources

[Andrew Neil]

Posted on May 17, 2011 at 13:51

''I can't download the detailed datasheet of STM32''

Why not? What is preventing you? They're all here: 

http://www.st.com/mcu/familiesdocs-110.html

It's the RM0008 Reference Manual that you require...

[davidwang1969]

Posted on May 17, 2011 at 13:51

we know, a device can receive msg form host(using RS485 bus) by multiprocessor mode, the nineth bit is used to notify the device and then the device can receive other bytes, no any other slave address is needed. firmware can judge the first byte(address byte), if it equal to itself, then disable multicommunication fucntion, receiving the other bytes, enable the multiprocessor function again. so device can receive any address package, but ST32 provide a slave address, it cannot receive broadcast address(host can send a broadcast package, all device shall recceive this broadcast package and take some action simutanously).

I want to know whether STM32 can receive a special address package(set by slave address) and also receive a broadcast address(such like 0xFF)?  

[picguy2]

Posted on May 17, 2011 at 13:51

For two devices such as PC host STM32 target RS-232 is a piece of cake.  You will likely need a RS-232 / USB device on the host side but these are inexpensive.

However, it looks like you are wanting to connect multiple devices to (a) each other or (b) multiple slave devices to a not necessarily PC host.  For hardware considerations you may wish to use single wire half duplex communication (see “single wire�? in the docs) or external drivers for off PCB communication. But you are likely thinking of using 11-bit frames and addressing a specific device to receive.  At low baud rates - even 38.4K is low - the non DMA interrupt overhead is nothing to worry about.  Let every device receive all messages discarding those for someone else.  Even if your ISR takes 300 clocks per byte at 38.4K baud this is a little under 1200 clocks per millisecond out of the 72000 clocks available.  If a well under 2% CPU time hit kills your application you already need additional computational horsepower.  RS-232 DMA transmit works.  DMA read with idle detection may work.  I had a problem with it but the project died due to funding issues in the down economy.  Additional exploration after producing an adequate workaround was not worth the effort. You may find my http://www.hmtown.com/fifo.htm page to be of interest. Try not to fall into the trap of keeping an 8051 communication protocol when moving into the 32-bit world.  This is a good time to rethink old designs now that historical constraints have been lifted.

[Andrew Neil]

Posted on May 17, 2011 at 13:51

''Try not to fall into the trap of keeping an 8051 communication protocol when moving into the 32-bit world.''

On the other hand, do not fall into the trap of throwing the baby out with the bathwater! The so-called ''9-bit'' multiprocessor protocol is widely used among many architectures - not just the 8051. It also forms the basis of a number of industry-standard protocols; eg, if you have ever bought anything from an automatic vending machine, then your purchase almost certainly relied upon it! Many processors (including the STM32) have built-in hardware to do the address recognition automatically with zero processor overhead - why not take advantage of that?! No, this is not a dead relic of a bygone age - it is alive and well and applicable today!

[davidwang1969]

Posted on May 17, 2011 at 13:51

Thanks a lot!

In fact,  I want to use STm32F107 as a host controller (master), and many 8051 devices as slave by RS485 bus. 11 bits(1 start,8+1 bit data, 1 stop). data package is just like:address +package length+ data0 +...dataN+ crclow byte+crchighbyte. the first byte is address,the nineth bit is 1,the other 8bits is address, the other bytes in the data package are just data, its nineth bit is zero. When this package is sent by STm32, the device which address is eaqual the first byte can receive the other data,otherwise waiting for address again. (8051 can be interrupted by nineth bit if in multi communication mode). Of course, the device can receive any address which nineth bit is 1. for example, the broadcast address. I think the uarts in ST32M can not be intterupted by nineth byte just like 8051 uart. Can anybody also use this feature like me?

[davidwang1969]

Posted on May 17, 2011 at 13:51

In fact, in my project,the baudrate is 19200!

[davidwang1969]

Posted on May 17, 2011 at 13:51

In fact, I am now updating an old SCADA system which was developed ten years before. all devices, including master controller, were controlled by 8051.only the master controller need to be upgade. so I have to select a MCU with multi communication feature just like 8051, if ok, it will be very easy.

So uarts on STM32 can work just like 8051?

[Tesla DeLorean]

Posted on May 17, 2011 at 13:51

There are specific examples of 9-bit multiprocessor USART programming in the ST library code.

The STM32 is definitely capable of 9-bit serial comms, and would be quite capable of handling the protocol you describe in software, regardless of the hardware support for addressing. You'll have to get an eval board+software and prove it to yourself.

[Andrew Neil]

Posted on May 17, 2011 at 13:51

''I think the uarts in ST32M can not be intterupted by nineth byte just like 8051 uart.''

From a brief look at the Documentation, I think it can! You need to study the documentation (in particular, the User Manual) carefully to confirm this...''only the master controller need to be upgade. so I have to select a MCU with multi communication feature just like 8051'' The automatic address detection is only of use in the slaves - it really has no benefit in the master. Even if your master controller doesn't specifically support ''9-bit'' mode, it is usually easy enough to ''spoof'' this by manipulating the parity bit (eg, I have seen this done on PCs)