Forums

ARM7 with two UARTs with hardware flow control

Started by Sandeep Dhull February 6, 2012
I am trying to solve two problems that are related to each other ...

* I have been looking for an ARM7 that has two UART modules with full hardware flow control. I checked NXP's website, but all I could find was MCUs with say UART1 with hardware flow control, and UART0,2,3 with TX#/RX# lines.I have to interface with a Bluetooth module and a GSM module, and both need hardware flow control to work properly. I have been strictly advised by a senior engineer that I must refrain from trying to use GPIOs as a "cheap" replacement for dedicated hardware flow control pins. However, I haven't been successful in finding an ARM7 that satisfies this criteria. Any suggestions?
* As a direct consequence of the MCU I find, we will need a development board that gives me access to the two UARTs with hardware flow control. Since I haven't been able to find a MCU that satisfies this criteria, finding the dev board is obviously pending.
I would appreciate all inputs regarding this.Thanks in advance!!

SD



An Engineer's Guide to the LPC2100 Series

Hi

The majority of RTS/CTS lines in the UARTs are not much more than elaborate GPIOs. In HW flow control it is usually still necessary to control these from SW and handle any CTS interrupts to stop and start transmission.

Since the UARTs tend to be double buffered or have several enties in their FIFO interrupt reaction time is not critical and automatic RTS is only needed when operating at very high rates (probably over 1Mb/s) where it may be necssary to stop the peer before the RX FIFOs overflow (due to lack of rx interrupt servicing), but that would probably also only be necessary when the UART interrupts have been given too low a priority anyway.

HW flow control comes in two flavors:
- the one that stops input buffer overflow when the input buffer is getting quite full (that is, the UART reception driver is having no problems keeping up with the data rate but the application handling the data content is and the input buffer cpnteht size hits a high-water mark)
- and the one that protects the UART input buffers/FIFOs

The first can be controlled simply by using a GPIO - the hardware RTS/CTS will not help. The second can only be done in hardware, but it is required only when the data rate is very high (not at typical speeds like 115k, where it would only be needed if there were a basic SW design problem or where interrupt absolutely have to be blocked for periods of several hundred us).

The freescale Coldfires V2s have multiple UART RTS/CTS according to the second requirement. In the case of ARMs many chips have RTS/CTS signals but you need to be careful that they really do fully automated control as in case two since many RTS lines are simple UART outputs that are not much more than GPIOs and the CTS inputs are also no more that a GPIO with edge triggered interrupt (as most GPIOs can do too).

Regards

Mark

--- In l..., Sandeep Dhull wrote:
>
> I am trying to solve two problems that are related to each other ...
>
> * I have been looking for an ARM7 that has two UART modules with full hardware flow control. I checked NXP's website, but all I could find was MCUs with say UART1 with hardware flow control, and UART0,2,3 with TX#/RX# lines.I have to interface with a Bluetooth module and a GSM module, and both need hardware flow control to work properly. I have been strictly advised by a senior engineer that I must refrain from trying to use GPIOs as a "cheap" replacement for dedicated hardware flow control pins. However, I haven't been successful in finding an ARM7 that satisfies this criteria. Any suggestions?
> * As a direct consequence of the MCU I find, we will need a development board that gives me access to the two UARTs with hardware flow control. Since I haven't been able to find a MCU that satisfies this criteria, finding the dev board is obviously pending.
> I would appreciate all inputs regarding this.Thanks in advance!!
>
> SD
>
>
>

On 06/02/2012 16:58, Sandeep Dhull wrote:
> I am trying to solve two problems that are related to each other ...
>
> * I have been looking for an ARM7 that has two UART modules with full
> hardware flow control. I checked NXP's website, but all I could find was
> MCUs with say UART1 with hardware flow control, and UART0,2,3 with
> TX#/RX# lines. I have to interface with a Bluetooth module and a GSM
> module, and both need hardware flow control to work properly. I have
> been strictly advised by a senior engineer that I must refrain from
> trying to use GPIOs as a "cheap" replacement for dedicated hardware flow
> control pins. However, I haven't been successful in finding an ARM7 that
> satisfies this criteria. Any suggestions?
> * As a direct consequence of the MCU I find, we will need a development
> board that gives me access to the two UARTs with hardware flow control.
> Since I haven't been able to find a MCU that satisfies this criteria,
> finding the dev board is obviously pending.
> I would appreciate all inputs regarding this. Thanks in advance!!

Are you sure you really need flow control for the GPS? It's optional on
the ones I've used, and I've managed without it.

If you really need it, you could probably implement it with ordinary I/Os.

Leon
--
Leon Heller
G1HSM
Mark,

I appreciate the detailed answer. The MCU is expected to receive files over Bluetooth and ship them out over GSM, and the dedicated flow control lines are required for those two interfaces. I'll dig deeper into my system requirements and get back with my observations/further questions.

Thanks!
SD
________________________________
From: Mark
To: l...
Sent: Monday, February 6, 2012 1:59 PM
Subject: [lpc2000] Re: ARM7 with two UARTs with hardware flow control


 
Hi

The majority of RTS/CTS lines in the UARTs are not much more than elaborate GPIOs. In HW flow control it is usually still necessary to control these from SW and handle any CTS interrupts to stop and start transmission.

Since the UARTs tend to be double buffered or have several enties in their FIFO interrupt reaction time is not critical and automatic RTS is only needed when operating at very high rates (probably over 1Mb/s) where it may be necssary to stop the peer before the RX FIFOs overflow (due to lack of rx interrupt servicing), but that would probably also only be necessary when the UART interrupts have been given too low a priority anyway.

HW flow control comes in two flavors:
- the one that stops input buffer overflow when the input buffer is getting quite full (that is, the UART reception driver is having no problems keeping up with the data rate but the application handling the data content is and the input buffer cpnteht size hits a high-water mark)
- and the one that protects the UART input buffers/FIFOs

The first can be controlled simply by using a GPIO - the hardware RTS/CTS will not help. The second can only be done in hardware, but it is required only when the data rate is very high (not at typical speeds like 115k, where it would only be needed if there were a basic SW design problem or where interrupt absolutely have to be blocked for periods of several hundred us).

The freescale Coldfires V2s have multiple UART RTS/CTS according to the second requirement. In the case of ARMs many chips have RTS/CTS signals but you need to be careful that they really do fully automated control as in case two since many RTS lines are simple UART outputs that are not much more than GPIOs and the CTS inputs are also no more that a GPIO with edge triggered interrupt (as most GPIOs can do too).

Regards

Mark

--- In l..., Sandeep Dhull wrote:
>
> I am trying to solve two problems that are related to each other ...
>
> * I have been looking for an ARM7 that has two UART modules with full hardware flow control. I checked NXP's website, but all I could find was MCUs with say UART1 with hardware flow control, and UART0,2,3 with TX#/RX# lines. I have to interface with a Bluetooth module and a GSM module, and both need hardware flow control to work properly. I have been strictly advised by a senior engineer that I must refrain from trying to use GPIOs as a "cheap" replacement for dedicated hardware flow control pins. However, I haven't been successful in finding an ARM7 that satisfies this criteria. Any suggestions?
> * As a direct consequence of the MCU I find, we will need a development board that gives me access to the two UARTs with hardware flow control. Since I haven't been able to find a MCU that satisfies this criteria, finding the dev board is obviously pending.
> I would appreciate all inputs regarding this. Thanks in advance!!
>
> SD
>
>
>




Leon,

I am using a GSM module, not a GPS module :)

To answer your question, yes ... flow control is required for work with this module. As I wrote in my response to Mark earlier, let me dig deeper and I'll get back with my observations.

Thanks!
SD
________________________________
From: Leon Heller
To: l...
Sent: Monday, February 6, 2012 2:52 PM
Subject: Re: [lpc2000] ARM7 with two UARTs with hardware flow control


 
On 06/02/2012 16:58, Sandeep Dhull wrote:
> I am trying to solve two problems that are related to each other ...
>
> * I have been looking for an ARM7 that has two UART modules with full
> hardware flow control. I checked NXP's website, but all I could find was
> MCUs with say UART1 with hardware flow control, and UART0,2,3 with
> TX#/RX# lines. I have to interface with a Bluetooth module and a GSM
> module, and both need hardware flow control to work properly. I have
> been strictly advised by a senior engineer that I must refrain from
> trying to use GPIOs as a "cheap" replacement for dedicated hardware flow
> control pins. However, I haven't been successful in finding an ARM7 that
> satisfies this criteria. Any suggestions?
> * As a direct consequence of the MCU I find, we will need a development
> board that gives me access to the two UARTs with hardware flow control.
> Since I haven't been able to find a MCU that satisfies this criteria,
> finding the dev board is obviously pending.
> I would appreciate all inputs regarding this. Thanks in advance!!

Are you sure you really need flow control for the GPS? It's optional on
the ones I've used, and I've managed without it.

If you really need it, you could probably implement it with ordinary I/Os.

Leon
--
Leon Heller
G1HSM





SD

See also chapter 7 of the following document: http://www.utasker.com/docs/uTasker/uTaskerUART.PDF

Regards

Mark
--- In l..., Sandeep Dhull wrote:
>
> Mark,
>
> I appreciate the detailed answer. The MCU is expected to receive files over Bluetooth and ship them out over GSM, and the dedicated flow control lines are required for those two interfaces. I'll dig deeper into my system requirements and get back with my observations/further questions.
>
> Thanks!
> SD
>
>
> ________________________________
> From: Mark
> To: l...
> Sent: Monday, February 6, 2012 1:59 PM
> Subject: [lpc2000] Re: ARM7 with two UARTs with hardware flow control
>
>
>  
> Hi
>
> The majority of RTS/CTS lines in the UARTs are not much more than elaborate GPIOs. In HW flow control it is usually still necessary to control these from SW and handle any CTS interrupts to stop and start transmission.
>
> Since the UARTs tend to be double buffered or have several enties in their FIFO interrupt reaction time is not critical and automatic RTS is only needed when operating at very high rates (probably over 1Mb/s) where it may be necssary to stop the peer before the RX FIFOs overflow (due to lack of rx interrupt servicing), but that would probably also only be necessary when the UART interrupts have been given too low a priority anyway.
>
> HW flow control comes in two flavors:
> - the one that stops input buffer overflow when the input buffer is getting quite full (that is, the UART reception driver is having no problems keeping up with the data rate but the application handling the data content is and the input buffer cpnteht size hits a high-water mark)
> - and the one that protects the UART input buffers/FIFOs
>
> The first can be controlled simply by using a GPIO - the hardware RTS/CTS will not help. The second can only be done in hardware, but it is required only when the data rate is very high (not at typical speeds like 115k, where it would only be needed if there were a basic SW design problem or where interrupt absolutely have to be blocked for periods of several hundred us).
>
> The freescale Coldfires V2s have multiple UART RTS/CTS according to the second requirement. In the case of ARMs many chips have RTS/CTS signals but you need to be careful that they really do fully automated control as in case two since many RTS lines are simple UART outputs that are not much more than GPIOs and the CTS inputs are also no more that a GPIO with edge triggered interrupt (as most GPIOs can do too).
>
> Regards
>
> Mark
>
> --- In l..., Sandeep Dhull wrote:
> >
> > I am trying to solve two problems that are related to each other ...
> >
> > * I have been looking for an ARM7 that has two UART modules with full hardware flow control. I checked NXP's website, but all I could find was MCUs with say UART1 with hardware flow control, and UART0,2,3 with TX#/RX# lines. I have to interface with a Bluetooth module and a GSM module, and both need hardware flow control to work properly. I have been strictly advised by a senior engineer that I must refrain from trying to use GPIOs as a "cheap" replacement for dedicated hardware flow control pins. However, I haven't been successful in finding an ARM7 that satisfies this criteria. Any suggestions?
> > * As a direct consequence of the MCU I find, we will need a development board that gives me access to the two UARTs with hardware flow control. Since I haven't been able to find a MCU that satisfies this criteria, finding the dev board is obviously pending.
> > I would appreciate all inputs regarding this. Thanks in advance!!
> >
> > SD
> >
> >
> >
>
>
>
>
>
>

--- In l..., Sandeep Dhull wrote:
>
> I am trying to solve two problems that are related to each other ...
>
> * I have been looking for an ARM7 that has two UART modules with full hardware flow control. I checked NXP's website, but all I could find was MCUs with say UART1 with hardware flow control, and UART0,2,3 with TX#/RX# lines.I have to interface with a Bluetooth module and a GSM module, and both need hardware flow control to work properly. I have been strictly advised by a senior engineer that I must refrain from trying to use GPIOs as a "cheap" replacement for dedicated hardware flow control pins. However, I haven't been successful in finding an ARM7 that satisfies this criteria. Any suggestions?
> * As a direct consequence of the MCU I find, we will need a development board that gives me access to the two UARTs with hardware flow control. Since I haven't been able to find a MCU that satisfies this criteria, finding the dev board is obviously pending.
> I would appreciate all inputs regarding this.Thanks in advance!!
>
> SD
>
>
>
Hi,
not an ARM7 but a Cortex-M3. You can use PSoC 5. It has programmable Logic on chip and a tool that lets you build your UARTS with HW flow control.
You can even use the PSoC 3 (8051 based), that can easily do many UARTs with flow control.

The tool to program it is called PSoC Creator and you can download it free of charge from the Cypress website
http://www.cypress.com/go/creator

The peripherals are called components and you add what you need.

On the other hand you can use one HW controlled UART and another one.... as mentioned before. This is a piece of cake for an ARM7 or a Cortex to do it in software. However, if your superior engineer mandates HW flow control, check out the PSoC. If you need more than 2 with HW flow control, not a problem either, or if you need more Timers than on a regular MCU... You get the idea. If you need many of one peripheral, in your case 2 UARTs with HW flow control, the PSoC is really a great solution.
http://www.cypress.com/go/psoc
If however the ARM7 has everything you need, go for that one.

Bob