multiple rs232 in one AVR?

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

Hi guys

Have anyone of you done something like this? Have multiple (say 4) rs232 devices connected to one AVR.

I want to make a fusion device that can combine multiple rs232 data and send them through Ethernet.

PS:

How can I manage a situation when 4 ports have incoming message at the same time? Or should I use 4 AVRs to handle each port?

Thanks guys!

Zhuhua Wu - Electronic Engineering Student

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

I would use an AVR with at least two UARTS. Then, a couple of external UARTS or one or more Tiny devices configured as UARTS. I think that there may be a few Mega devices with 4 UARTS and those might be worth considering though they are probably high pin-count chips.

At modest baud rates, "simultaneous" incoming messages are not much of an issue. You do not have to read the character from the UART instantly - you only need to read one before the END of the next character (on the same UART). That gives you a whole character time to play with.

Then, you have 4 separate buffers, one for each UART. It is mostly a matter of juggling the ball and not dropping it.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Does it have to be an AVR :?:

There are plenty of ARMs with well over 4 UARTs...

There are also multi-UART chips which connect to a microcontroller via SPI, etc,...

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I want to make a fusion device that can combine multiple rs232 data and send them through Ethernet.


Perhaps the overall system design would be easier if you widen your horizon beyond AVR8.

Yes, a Mega640 (family) has 4 USARTs. But how are you going to talk to the Ethernet? With a module? What is the interface to that module? If you answer "UART" now you are up to five... Perhaps it is SPI?

Many Xmega models have five or more UARTs. But none have a built-in Ethernet.

So for that you might need to look at Cortex or other microprocessor family.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

ka7ehk wrote:
I would use an AVR with at least two UARTS ... I think that there may be a few Mega devices with 4 UARTS

Use the Microcontroller Product Selector search tool to find them:

http://www.atmel.com/products/se...

The Microcontroller Product Selector wrote:
Matching Results: 194

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...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
The Microcontroller Product Selector wrote:
Matching Results: 194
Most of those are AVR32 or SAM. When constraining the selector to AVR8, there are 23 matches. Three of those are mega (640/1280/2560), the rest are xmega.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

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

Hi
Thanks for all the replies, they answered some of my question, which is great.

Regarding limit to ARV8, it's not my intention to limit to just AVR8, but when I wrote this question, AVR8 is the mcu in my mind, so sorry about that.

So another question: I have never use an xmega or ARM, are they hard to use for someone like me coming from AVR8?

Zhuhua Wu - Electronic Engineering Student

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

XMega is more like Mega. Same instruction set. Registers are similar but can be different. Loads of special features (like DMA, fast ADC, DAC, etc) that you do not have to use.

ARM is a lot more different, from what I understand (no first hand experience).

One of the things you will find is that larger numbers of UARTs seem to come with higher pin counts. That makes those chips harder to deal with by a hobby person. This is true for all the chips mentioned above, I think.

Jim

Jim Wagner Oregon Research Electronics, Consulting Div. Tangent, OR, USA http://www.orelectronics.net

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

Well, I found stm32fx discovery "kits" -pre soldered, pins get manageable with vero boards or broad beards- which are cheaper than Arduini (and than other avr-cards : arduini are cheaper than "plain" avr cards).

- Application notes are bigger (700-1700 pages vs 300 pp)

- there are less tutorials : Geoffrey's Brown book http://www.cs.indiana.edu/~geobr... and aquilins tutorials http://www.aquilin.nl/?page_id=4 tought me a lot.

-without a priori knowledge from avrs, I would have suffered a lot...

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

Do you need EthernetToQuadUART or do you need challenges?
There are ethernet switches available and EthernetToUART adapters, you know.

No RSTDISBL, no fun!

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

Quote:
- Application notes are bigger (700-1700 pages vs 300 pp)

You mean Manuals!
I have never seen an application note spanning through 300 pages...
aevdk

No RSTDISBL, no fun!

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

Yes, I should have meant manuals....

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

Quote:

XMega is more like Mega. Same instruction set. Registers are similar but can be different. Loads of special features (like DMA, fast ADC, DAC, etc) that you do not have to use.

When writing in C the instruction set doesn't really matter. The difference that does matter are the peripherals available. These things tend to be on a sliding scale of complexity. If you take the very simple case of GPIO then a tiny/mega has just 3 registers to control things (well OK some have PU registers and stuff but generally this is true). An Xmega has more like 8..12 registers so there are more facilities available. However the point is that 3 of those registers are just like the 3 in tiny/mega so if you stick to using those it need not be any more complex than tiny/mega though names/bitnames have changed a bit. AVR32-UC3/ARM are possibly a step up again. This time you might find it's more like 15..18 registers. They can possibly do even more than the Xmega and certainly more than the tiny/mega and there are added complexities in using GPIO in that the peripheral clock to the GPIO domain needs to be enabled before the thing can be used at all. But again (having turned it on) there are likely just 3 core registers that will let you use them just like tiny/mega. The only tricky bit is working out which ones they are.

The same holds true for SPI and timers and UARTs and so on. The "big chips" tend to have bigger, more complex, more feature packed peripherals so working out how to use them "simply" can be a challenge. Of course all those added features are there for YOUR benefit - they are to make the programmers job simpler. For example you might choose to set up a UART to do DMA. In this case you don't even really need to worry about interrupts and ring buffers and stuff. You just tell the UART to receive characters and dump them in that memory buffer over there and it just does it all for you. It will still interrupt but now it'll be to say things like "your buffer is full" or whatever.

I could well envisage a solution in ARM (or UC3) where you setup your multiple UARTs to DMA. They all fill their own private buffers and when you get the message that one of the buffers is full you wrap it into a TCP/IP packet and shoot it off down the line (using the Ethernet controller the chip already has).

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

The job would be reasonably easy using a tiva c board ($20 delivered) that has ethernet and 6 uarts. Energia is a arduino workalike for this.

Other options are mbed boards - online tools and extensive libraries.

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

dbrion0606 wrote:
Well, I found stm32fx discovery "kits" -pre soldered, pins get manageable with vero boards or broad beards- which are cheaper than Arduini (and than other avr-cards : arduini are cheaper than "plain" avr cards).

- Application notes are bigger (700-1700 pages vs 300 pp)

- there are less tutorials : Geoffrey's Brown book http://www.cs.indiana.edu/~geobr... and aquilins tutorials http://www.aquilin.nl/?page_id=4 tought me a lot.

-without a priori knowledge from avrs, I would have suffered a lot...

From what I can understand is, I can write code with Atmel Studio for sam32 since 6.0, am I correct?

Zhuhua Wu - Electronic Engineering Student

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

clawson wrote:
Quote:

XMega is more like Mega. Same instruction set. Registers are similar but can be different. Loads of special features (like DMA, fast ADC, DAC, etc) that you do not have to use.

When writing in C the instruction set doesn't really matter. The difference that does matter are the peripherals available. These things tend to be on a sliding scale of complexity. If you take the very simple case of GPIO then a tiny/mega has just 3 registers to control things (well OK some have PU registers and stuff but generally this is true). An Xmega has more like 8..12 registers so there are more facilities available. However the point is that 3 of those registers are just like the 3 in tiny/mega so if you stick to using those it need not be any more complex than tiny/mega though names/bitnames have changed a bit. AVR32-UC3/ARM are possibly a step up again. This time you might find it's more like 15..18 registers. They can possibly do even more than the Xmega and certainly more than the tiny/mega and there are added complexities in using GPIO in that the peripheral clock to the GPIO domain needs to be enabled before the thing can be used at all. But again (having turned it on) there are likely just 3 core registers that will let you use them just like tiny/mega. The only tricky bit is working out which ones they are.

The same holds true for SPI and timers and UARTs and so on. The "big chips" tend to have bigger, more complex, more feature packed peripherals so working out how to use them "simply" can be a challenge. Of course all those added features are there for YOUR benefit - they are to make the programmers job simpler. For example you might choose to set up a UART to do DMA. In this case you don't even really need to worry about interrupts and ring buffers and stuff. You just tell the UART to receive characters and dump them in that memory buffer over there and it just does it all for you. It will still interrupt but now it'll be to say things like "your buffer is full" or whatever.

I could well envisage a solution in ARM (or UC3) where you setup your multiple UARTs to DMA. They all fill their own private buffers and when you get the message that one of the buffers is full you wrap it into a TCP/IP packet and shoot it off down the line (using the Ethernet controller the chip already has).

I can only understand the first two paragraph, but sounds like ARM is something worth looking into, even I don't know a thing about DMA. Guess I will start from "What is DMA"

Thanks again, as always I learn something from you everytime.

Zhuhua Wu - Electronic Engineering Student

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

Quote:

From what I can understand is, I can write code with Atmel Studio for sam32 since 6.0, am I correct?


You should be using 6.2 not 6.

Anyway AS6.2 has support for Atmel's Cortex M ARM chips which means SAMD20/21, SAM3 and SAM4. It does not support SAM7 or SAM9 and it most definitely does not support STM32 as that is a range of Cortex M0/M3/M4 processors from ST Microelectronics who are one of Atmel's main competitors. The board dbrion suggested to you was STM32 nothing to do with Atmel.

It's true that some of Atmel's competitors (STM, NXP, Freescale, Nuvotron, TI, Fujitsu, Toshiba, etc, etc) may well have Cortex M3 and M4 chips more suited for what you want to do (having Ethernet controllers especially) but for those you wil have to explore what development environments are available. What you will find is that many many of them do use GNU GCC for ARM but what you need to explore is whether you like the IDE that wraps around it and the debugging tools that are available. Also most don't have a completely "free" IDE in the same way that Atmel has Studio 6.2 with arm-gcc. You will find many that have a code size limit (often 128K or 256K) beyond which the IDEs may actually cost significant amounts of money.

So there is some advantage in trying to stick to Atmel Cortex M3/M4 chips (SAM3/SAM4) but what you may find is that development+debugger boards from Atmel typically cost 2 or 3 times that of their competitors. Many supply a board with a powerful CPu and debugger for $10-15 while Atmel charge more like $45.

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

Brutte wrote:
Do you need EthernetToQuadUART or do you need challenges?
There are ethernet switches available and EthernetToUART adapters, you know.

I am just researching for now, but I think I will need to fully understand how to solve the problem I got now, and solve it, before I move on to next one.

Zhuhua Wu - Electronic Engineering Student

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

Main issue I see , from a hobbyist point of view, with TI is that they make (almost) perfect demo boards, at low prices; then, in a short lapse of time -2yrs- their demo boards become rare and expensive (msp430 launchpad was 5 E$ in a shop 18 months ago; now, it is about 20 E$ in the same shop..)
ST and atmel have a less agressive policy with demo boards....

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

Quote:

"What is DMA"

Direct Memory Access.

If you think about what most ISR()s in your code are actually doing they tend to respond to some device saying "ready" at which point the ISR() just goes and gets the result, stores it in a buffer somewhere and then triggers the start of the next event.

DMA is effectively a way to automate all that so that you just tell the peripheral+DMA controller. "buffer here, 10 bytes to send/receive, just do it".

Just as you don't HAVE to use interrupts for a UART you don't HAVE to use DMA either. But each of these things is a step forward towards having the whole process entirely automated. It takes the load off the CPU which is then free to do other stuff. The only "cost" is that the DMA sometimes needs to access memory (usually RAM) as well as the CPU when it wants to read or write a byte. It might do this with shared access memory (if the CPU is really expensive!) or it may use a technique called "cycle stealing" where it effectively blocks the CPU access for one or two cycles while it gets in and makes its own access.

As I say DMA (and all those fancy features added by +5 or +10 additional GPIO registers for example) are just "bells and whistles". In the hands of a good system designer they are tools to make the overall implementation "better" but they can just as easily be ignored.

Just as when you first use a UART you likely program it synchronously (getchar/putchar blocking routines) but when you are confident it works you then switch on the interrupts, provide buffers and operate it asynchronously for a "better" solution then that's true for things like DMA. You can implement a simpler solution then trade up to an even better one when ready - though if you plan to do this you should do your system design with this in mind - don't architect a design that can only work with the simpler scheme but keep the thought "suppose I now did this with DMA" at the back of your mind.

One thing you will find if you trade up CPUs is that you wil likely move from 16/20MHz tiny/mega or even 32MHz Xmega to chips that can now do 120-160MHz and in 32bit and with 3 stage pipelines. So the amount of raw "grunt" available is phenomenal. So you could likely service 4 or 6 UART simply with polling routines and still not miss anything if you didn't want to use interrupts or DMA. Of course such a design might not be advisable but I'm just making the point that fast CPUs give you loads more time to "do stuff". (sounds like I'm arguing for sloppy programming!)