Clarification on # of Nano UARTS

[Ridgeglider]

I was pretty sure the 54415 had 10 UARTS, of which 8 are available on the Nano. However, The UART chapter of the MCF5441X Ref Manual states in section 41.1, the Introduction: "This chapter describes the use of the three universal asynchronous receiver/transmitters (UARTs)..."

What am I missing? This must be a typo???

[pbreed]

The freescale manual are cut copy and paste fromv ersion to version.
Since most coldfires had 3 uarts... err.... the doc says so

The chip has 10 logically grouped into uart 0,1,2,3 and 4,5,6,7,8,9

If you want to talk directly to the uart hardware... look here first

nburn\nan54415\system\localio.c

look at the function uartstruct * GetUartRecord(int uart_num)

For mapping the uarts to interrupt vectors etc... look here
Look in nburn\nano54415\system\serial.cpp

const int SerialSimMap[10]={0,0,0,0,1,1,1,1,1,1,};
const int SerialVectorMap[10]={26,27,28,29,48,49,50,51,52,53};


Hope that helps.

[Ridgeglider]

Paul, yes, as always, very helpful. Appreciated!

[dciliske]

And of the 8 available uarts on the nano, 3 have full hardware handshaking, 2 additional uarts are unrelated to the 3 with hardware handshaking, and 3 final uarts use the first three's hardware handshaking pins for tx/rx.

So it looks like this:
Up to 3 uarts: full hardware handshaking
3-5 uarts: 3 with full hardware handshaking, 2 without
6-8 uarts: 2 w/hw hs, 4 w/o - 1 w/hw hs, 6 w/o - 8 w/o

-Dan

[versamodule]

You can get a graphical view of it here.

http://www.versamodule.com/NanoCheetSheet/Main.html

[Lachlanp]

The UART0 CTS/RTS lines are connected to the Debug port. Can these be used as UART4 RX/TX without effecting the debug port operation (E.g. stdio, sterr, etc and iprintf).

Regards
Lachlan

[Ridgeglider]

Lachlan, I think it depends on what external hardware you have beyond the Nano. CTS is an input to the uC, so for example on the U1_3V_CTS line there is a jumper on the Nano Dev Board so that it can be disconnected from being driven by the RS232 driver chip during non-RS232 configurations. That way, the U1_CTS line can be reconfigured as the U5TX line w/o being driven from both ends.

In the case of the Nano U0 CTS line, on the nano Dev board, this is connected to the USB driver IC w/o a jumper, which I think means it will always be driven by the USB chip, which it would seem conflicts with configuring to use as U4Tx. Then again, the Nano U0CTS line (oddly?? connects to the USB IC's RTS pin, not the USB IC's CTS pin so maybe I have things confused...? Still fuzzy on how the USB IC works... Maybe the NB folks can clarify this?

If this really is a conflict, a jumper on line the would be great in a future rev of the nano dev board...

Regarding U0 lines, I think the default serial flow control protocol is XON/XOF software flow control for all COM channels, not hardware CTS/RTS flowcontrol. So, from a purely software config stance, I think these 2 lines (U0 CTS/RTS) should be able to be reconfigured to U4TX/Rx using Pins[30].function(PIN_30_UART4_TXD) and Pins[28].function(PIN_28_UART4_RXD) assuming they don't conflict w/ a USB IC in your specific external hardware. U0 should continue just fine as stdio w/o the hardware handshake pins.

By the way, I continue to use the http://www.versamodule.com/NanoCheetSheet/Main.html tool to visualize these pin arrangements. VERY nice, and much faster than searching the pins.h.

[Lachlanp]

Thanks for the input. I use the nanas in my own boards so I can do the physical connection the way that I want.

My concern is if there is anything in software that is going cause config with me using uart4 and remove the RTS/CTS control lines. For debug, there should not be the case where there is a data overrun because I understand that the receive buffer is about 2k in length ( this was answered elsewhere) and we are talking small amounts of data. On the PC side there should also be no problem.

If however, the iprintf code uses the CTS.RTS lines and I cannot change that in software, then I would have problem using U4. As you say, it is difficult to check this using the evaulation board without cutting tracks.

Let me know if anyone else has specific knowledge.

Regards
Lachlan

[Ridgeglider]

If you have your own IO after the Nano, I think you'll be OK. See page 220, the start of the Serial Library documentation in C:\nburn\docs\NetBurnerRuntimeLibrary\NetBurnerRuntimeLibraries.pdf. You have full control over flow control (hardware, software, or none) for any of the uart ports. That said, I don't think all the uarts support hardware flow control, but if they do, you can enable/disable it.

 OpenSerial – Opens a serial port
 SimpleOpenSerial – Shortcut macro to open a serial port
 SerialClose – Closes a serial port [using close() works as well]
 SerialEnableTxFlow – Enables software flow control on transmit (XON/XOFF)
 SerialEnableRxFlow – Enables software flow control on receive (XON/XOFF)
 SerialEnableHwTxFlow – Enables hardware flow control on transmit (RTS/CTS)
 SerialEnableHwRxFlow – Enables hardware flow control on receive (RTS/CTS)
 Serial485HalfDupMode – Configures for RS-485 half- or full-duplex mode
 SendBreak – Sets a break in the transmission for a given period of time
 serwriteaddress – Writes address values (used only with multidrop parity setting)
 GetUartErrorReg – Reads the status of the UART error register

Additionally, you can easily specify any uart as stdio for stdin, stout, and stderr. If you do, that's where printf() output is transmitted, and where functions like getchar() receive from by doing something like this:

Code: Select all

SerialClose( 0 );
fdSerial = OpenSerial( 0, 115200, 1, 8, eParityNone );
ReplaceStdio( 0, fdSerial ); // stdin via UART 0
ReplaceStdio( 1, fdSerial ); // stdout via UART 0
ReplaceStdio( 2, fdSerial ); // stderr via UART 0

[Lachlanp]

Thanks,
I think you are right that the NANO does not use the hardware handshaking for UART0 and the USB. I will cut the tracks on the evaluation board and then try to upload a program to make sure there is no reliance on hardware flow control when using the emergency backdoor programming technique.

If that works OK a few times, then I will disconnect the RTS/CTS in my designs.

Regards
Lachlan