Communicating with multiple USART devices

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm in the early stages of designing a specialized automated assembly machine. It utilizes six axes - all controlled by stepper motors. I am planning to use two ATmega328 MCUs with 3-axis "grbl" G-code interpreters and a 'Master' MCU (ATmega328) to coordinate them both.

Although it is a Six Axis machine, no two axes will be moving at the same time. Also, once the G-code is debugged and finalized, there will be no need to change it and it will be coded in firmware. Therefore there is no need to have another device (laptop or SDcard reader) connected to the machine to provide the G-code.

 

The issue I am facing is that "grbl" receives the G-code through the RXD pin, which I understand is the Receive input for the USART. I would like to use the USART TXD of the 'Master' MCU to transmit G-code to both "grbl" devices. Although I am not very familiar with using the USART, I don't believe the protocol allows for selecting different devices like SPI does.

 

My thinking is to use a 1-of-2 noninverting demultiplexer to direct traffic to the desired device. I would rather not have to modify the "grbl" source code for alternative communication, especially if all I need to do is add a 27 cent demux chip.

 

Is this an appropriate way to communicate with the two USARTs?

 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use softUsart for your outgoing comms?

 

Should be easy to do.

 

Jim

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

SoftUART is a LOT easier for transmit than receive. If you have ah assignment choice, transmit is the one you want to do in software.

 

Jim

 

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Why not use softUsart for your outgoing comms?

Good suggestion Jim. It didn't dawn on me to do it in software.

 

I am looking for ways to do less programming though. This project is already complex, so anything I can do to simplify....

 

ka7ehk wrote:
SoftUART is a LOT easier for transmit than receive.

 

That's good to know, Jim. Fortunately I only need to transmit in this application.

 

In my googling, I stumbled upon the notion of using an MCU with two USARTs. I found the ATmega324 has two of them, plus it has 44 pins verses the 32 pins of the ATmega328 I am using, so it has more I/O that will likely come in handy.

 

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The M328PB has two usarts as well, but has a different pinout then the M328(PA), it also adds a few more i/o pins as well.

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
The M328PB has two usarts as well

WOW! Thanks Jim. I actually have the "PB" chips and didn't realize they were different. I just downloaded the correct datasheet.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aeroHAWK wrote:
Although I am not very familiar with using the USART, I don't believe the protocol allows for selecting different devices like SPI does.
Does by Atmel MPCM :

http://www.atmel.com/devices/ATMEGA328PB.aspx

...

ATmega328PB Complete
(file size: 5.53MB, 425 pages, revision C, updated: 10/2015)

http://www.atmel.com/Images/Atmel-42397-8-bit-AVR-Microcontroller-ATmega328PB_Datasheet.pdf

25. USART

(page 247)

25.9. Multi-Processor Communication Mode
Setting the Multi-Processor Communication mode (MPCMn) bit in UCSRnA enables a filtering function of
incoming frames received by the USART Receiver. Frames that do not contain address information will
be ignored and not put into the receive buffer. This effectively reduces the number of incoming frames
that has to be handled by the CPU, in a system with multiple MCUs that communicate via the same serial
bus. The Transmitter is unaffected by the MPCMn setting, but has to be used differently when it is a part
of a system utilizing the Multi-processor Communication mode.
If the Receiver is set up to receive frames that contain 5 to 8 data bits, then the first stop bit indicates if
the frame contains data or address information. If the Receiver is set up for frames with 9 data bits, then
the ninth bit (RXB8) is used for identifying address and data frames. When the frame type bit (the first
stop or the ninth bit) is '1', the frame contains an address. When the frame type bit is '0', the frame is a
data frame.
The Multi-Processor Communication mode enables several slave MCUs to receive data from a master
MCU. This is done by first decoding an address frame to find out which MCU has been addressed. If a
particular slave MCU has been addressed, it will receive the following data frames as normal, while the
other slave MCUs will ignore the received frames until another address frame is received.

aeroHAWK wrote:
Is this an appropriate way to communicate with the two USARTs?
No

For industrial automation, RS485 and Modbus (AVR driver) are common

Another way is IO-Link (3 wire cable, single or multiple channel transceivers, 230Kbps max)

Likely other ways

 

P.S.

aeroHAWK wrote:
... a specialized automated assembly machine. ...

I am planning to use two ATmega328 MCUs with 3-axis "grbl" G-code interpreters and a 'Master' MCU (ATmega328) to coordinate them both.

....

Therefore there is no need to have another device (laptop or SDcard reader) connected to the machine to provide the G-code.

Serial Port JSON Server (SPJS) is not as you want but is one way to process grbl.

Instead of a mega328 for the central role there would be an embedded Linux board.

An embedded Linux board might fit within the assembly machine.

These are small (Raspberry Pi, BeagleBone) and smaller (System-on-Module or SoM)

BeagleBone Black Industrial covers the industrial temperature range and the Raspberry Pi Compute Module (CM1, CM3, CM3 Lite) covers almost all of it.

There are third party industrial SoM that have a similar MPU to those popular boards.
Could port SPJS to a Linux running on an Atmel SAMA5 SoM.

Instead of a laptop, there are a plethora of industrial PC that might be small enough, or, there are near PC in the form of Computer-on-Module (CoM); some of these are off-the-shelf with either Linux or Windows (Pro, Enterprise, Enterprise IoT, Embedded or Windows 10 IoT)

Windows 10 IoT Core is running on Raspberry Pi, Intel Joule (a small CoM), Minnowboard Max, etc

A CoM might fit in the machine; an industrial PC might be a squeeze.

 

ChiliPeppr

Hardware Fiddle

http://chilipeppr.com/

Microsoft

Official Site - Windows IoT

Windows 10 IoT Core

https://developer.microsoft.com/en-us/windows/iot

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
Instead of a mega328 for the central role there would be an embedded Linux board.

An embedded Linux board might fit within the assembly machine.

I have a limited level of expertise in the realm of embedded microcontrollers. I have looked into the BeagleBone Black with great interest. Unfortunately, the timeframe available for this project isn't suitable for my learning a whole new system. I need to solve the problems with the tools I already have in my toolbelt. So at this point that means AVR.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. Antoine de Saint-Exupery (1900 - 1944)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aeroHAWK wrote:
I stumbled upon the notion of using an MCU with two USARTs. I found the ATmega324 has two of them, ...
... three for mega324PB

IO-Link for 4 UARTs central to 4 devices :

Linear Technology IO-Link 4 UART transceiver

via

http://www.linear.com/product/LTC2874

Has Linduino source code (Arduino compatible Uno-like plus isolated USB)

Per the MCU/MPU product selector, AVR with 4 or more UART :

  • mega1280, mega2560, mega640
  • XMEGA A1U, A3U, A4U

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wow, sounds like a fun, (and complex), project.

 

I suspect the G-code is initially coming from a PC to the Master micro?

 

If so, that would be easiest to implement with a hardware USART which does both Tx and Rx with the PC.  It will be much easier if that is a two-way data link.  Select a baud rate friendly Xtal frequency, and use an Xtal on all three micros.

 

Are the Slave micros physically close to the Master micro?

 

Are you intending to have bi-directional communications between the Master and the two Slaves?

 

(I am in favor of bidirectional comm's, but perhaps you don't require them, or perhaps the Slave just toggles a HW pin that the Master is reading on one of its HW pins, etc.)

An "easy" option, if you use one of the two HW USART micros for both the Master and at least one of the two slaves is to have the Master put its data in a "packet" for transmission to the Slaves.  You probably should be doing this anyways...  One of the first bytes in the packet is a destination ID, (e.g. 1, 2, ...) for the Slave for which the data is intended.

 

Master passes all packets, for both Slaves, out its Slave USART.  This connects to Slave 1.  Slave 1 processes Slave 1 commands.  Slave 1 uses its second USART to pass on the packet to Slave 2 if it is a Slave 2 packet.  Slave two only requires one USART, to talk to Slave 1.

 

Each Slave has the ability to pass data back upstream to the Master, although Slave 1 has to pass Slave 2's messages through itself.

 

Packets should have a checksum or CRC to help verify that the Slave received the packets correctly.

The Acknowledgement is either OK, Resend it, ...

 

Just another option for you to consider.

 

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

A cheap n cheerful solution might be to use a couple of port pins and resistors. I'm assuming the interconnections will be short ( as in a few inches).

 

PortPin1----------------|

TxD--|----/\/\/\/\/\/---|---------------SLAVE1

         |

         |---/\/\/\/\/\/---|---------------SLAVE2

PortPin2----------------|

                

Let's make the resistors 4K7

The port pins are either set to output a '1' or as an input. When set to output '1' it will effectively block data going to the associated slave.

Upsides - cheap n cheerful.

Downsides - the series resistance along with stray capacitances form a low pass filter. This can become significant at higher data speeds. Make the series resistance too low and the port pins will have trouble making the correct voltage levels. I wouldn't go much below 1k.

Excuse me while I go and wash my striped apron.......................

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

aeroHAWK wrote:
Although it is a Six Axis machine, no two axes will be moving at the same time

Are you certain of this constraint?  Even a simple G0 or G1 move may involve simultaneous movement of multiple axes.  In order to satisfy this requirement, even these simple moves must be contrived to be limited to just one axis.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

gchapman wrote:
Atmel (sic) MPCM

Note that this has nothing specifically to do with Atmel; eg, it was a standard feature of the 8052.

 

http://www.8052.com/forum/read/6...

 

If you have ever bought anything from an automatic vending machine, the chances are that your purchase relied upon it!

 

http://www.8052.com/forum/read/1...

 

Per the MCU/MPU product selector, AVR with 4 or more UART :

  • mega1280, mega2560, mega640
  • XMEGA A1U, A3U, A4U

 And, of course, if you go to SAM there are options with 6 and more UARTs.

 

And there are multi-UART chips which connect to a microcontroller via SPI or I2C ...

 

Edit: added links

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Fri. Feb 3, 2017 - 12:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for I was not aware.

awneil wrote:
And, of course, if you go to SAM there are options with 6 and more UARTs.
SAM USART Multidrop Mode has the frame type (address or data) in the parity bit position whereas AVR MPCM has it in either the stop bit or the most significant data bit (9 of 9)

Is there a convention for such?

Thanks!


http://www.atmel.com/products/microcontrollers/arm/sam-s.aspx?tab=documents

...

SAM S70 Complete
(file size: 7 MB, 1605 pages, revision D, updated: 01/2016)

http://www.atmel.com/Images/Atmel-11242-32-bit-Cortex-M7-Microcontroller-SAM-S70Q-SAM-S70N-SAM-S70J_Datasheet.pdf

(page 982)

44.6.3.9 Multidrop Mode
If the value 0x6 or 0x07 is written tothe PAR field in the US_MR, the USART runs in Multidrop mode. This mode
differentiates the data characters and the address characters. Data is transmitted with the parity bit at 0 and
addresses are transmitted with the parity bit at 1.
If the USART is configured in Multidrop mode, the receiver sets the PARE parityerror bit when the parity bit is high.
and the transmitter is able to send a character with the parity bit high when a 1 is written to the SENTA bit in the
US_CR.
To handle parity error, the PARE bit is cleared whena 1 is written to the RSTSTA bit in the US_CR.
The transmitter sends an address byte (parity bit set) when SENDA is written to in the US_CR. In this case, the
next byte written to the US_THR is transmitted as an address. Any character written in the US_THR without having
written the command SENDA is transmitted normally with the parity at 0.

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In some language I don't understand: https://www.youtube.com/watch?v=...

 

Or here: http://grblminicnc.blogspot.com/...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gchapman wrote:
SAM USART Multidrop Mode has the frame type (address or data) in the parity bit position

I haven't looked at that for the SAMs.

My point with the SAMs is that there are plenty with so many U(S)ARTs that you wouldn't need to worry about it!

 

AVR MPCM has it in either the stop bit or the most significant data bit (9 of 9)

Is there a convention for such?

IIRC, to be compatible with what the 8052 did, it would have to be the most significant data bit ... ?

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...