Using The Serial Port in uTasker

[mhoneywill]

Hi Mark,

I'm evaluating various sections of the uTasker project, and I'm now looking at the serial ports.

I would like to use all three ports on an LM3S6965 for my own use,

Port 1 - connected via USB serial chip to a PC (115200baud)
Port 2 - connected via half duplex RS485 to a modbus device (115200baud)
Port 3 - Connected full duplex to a Crystalfontz RS232 display (19200baud)

I'm a bit confused how to setup the serial ports, what I don't want is to have the demo telnet menu apearing on one of the ports.

What I want to do is have all tree serial ports free for me to use, and debug output redirected via the Telnet interface, I like the idea of "debug printf's" going via Telnet. And lastly I don't want the normal Telnet menu at all.

What defines do I need to do the above?

Cheers

Martin

[mark]

Hi Martin

Basically you need to remove two things:
#define DEMO_UART and
#define USE_MAINTENANCE
but keep #define SERIAL_INTERFACE

The Luminary project does needs some adjustments for disabling DEMO_UART: in application.c change
#ifdef SERIAL_INTERFACE to
#if defined SERIAL_INTERFACE && defined DEMO_UART

and then this UART will no longer be used. All three will be freely available for other uses (0, 1, 2 for UARTs 0, 1 and 2). Configure them as required and read and write using the fnWrite() and fnRead() commands, equivalent to the existing DEBUG UART code which will no longer exist.

Removing USE_MAINTENANCE will remove all menu support, but will also remove the Telnet interface with it.
You will need to copy the parts from debug.c which installs the TELNET listener (including the task which handles ARP events for TELNET - or else put this into another existing task), and the Telnet listener itself. If you remove the menu handling it will be then work as a sort of printf() output.

Alternatively you can keep USE_MAINTENANCE but just remove the menu handling in fnTELNETListener() in debug.c. This is the easiest path for first tests.

Regards

Mark

[mhoneywill]

Hi Mark,

#ifdef SERIAL_INTERFACE

appears in lots of files should I also change it to

#if defined SERIAL_INTERFACE && defined DEMO_UART

in the following files

webinterface.c (3 times)
application.c  (9 times)
debug.c (15 times)


I think I should not change it in

app_hw_lm3sxxxx.h
tty_drv.c
driver.c
LM3sxxx.c

I've tried the above and it seems to work, the debug menu appears on the Telnet port.

I think the above would be a good modification to make to the project, so you would have to define DEMO_UART to force the debug menu to appear on the serial port, otherwise it would appear on the Telnet port.

I added the following

extern void fnMyFirstTask(TTASKTABLE *ptrTaskTable)
{
  static unsigned char ucCounter = 0;
 
  fnDebugMsg("Hello, World! Test number ");
  fnDebugDec(ucCounter++, 0, 0);
  fnDebugMsg("\r\n");
}

And added

  { "xmytask!!", fnMyFirstTask,  NO_QUE,    (DELAY_LIMIT)(5 * SEC), (DELAY_LIMIT)(2 * SEC), UTASKER_STOP}, // my first task (runs after a delay of 5s and then periodically every 2s)

to the ctTaskTable definition in TaskConfig.h

and also added

extern void fnMyFirstTask(TTASKTABLE *ptrTaskTable); // prototype

to TaskConfig.h

Now I also get "Hello, World! Test number nn" printed to the Telnet port so debug printf seems to work also, I've just left the menu in for the moment.

I've detailed what I've done above so others might find it easier to follow.

Cheers

Martin

[mark]

Hi Martin

The development project (and Coldfire SP version) already includes the capability of removing the DEMO_UART so this will be standard as of next SP release.

In fact the menu is available on the DEMO UART, USB or TELNET (depending on which is active). Since you have removed the UART it will never appear there again in that configuration.

To stop the TELNET menu appearing when you connect, simply remove
fnDoAdmin(DO_SHOW_CONFIG, 0);
and
fnDisplayHelp(0);
in fnLoginSuccess();

I never found that the menu disturbed since it only appears on connection and then all debug messages operate as normal. It can then still be used as command line interpreter for various needs. It is also possible to quite easily add new menus specifically for particular debug work during the course of a project (eg. requesting registers and looking at variables, etc.).

Regards

Mark

[jezc]

Hi Martin / Mark,

I'm trying to get the UARTs on the LM3S6432 going with
1) RS232 hardware flow control (RTS/CTS in particular)
2) RS485 half-duplex

As far as I can tell, there's no direct support in the UART block for either of these features (unlike many other parts from other vendors) so if either of you can give me some pointers on how best(?) to manage this, I'd be very grateful.

I think there's some code available from Ti to show one form of RTS/CTS control using GPIO pins which I'll try to implement for the first point, but I've not yet found anything to help me with the RS485 direction control.

Cheers,
    Jez

[mark]

Hi Jez

The RTS/CTS flow control should be available as follows:

1) Enable SUPPORT_HW_FLOW so that the support is activated.
2) When you open the serial interface set the mode RTS_CTS as parameter.
3) This will configure GPIOs as RTS and CTS. In app_hw_lm3sxxxx.h you can specifiy which ports are used for the jobs - eg.

        #define CTS_0_PIN          PORTA_BIT3
        #define CTS_0_PORT_POWER   CGC_GPIOA
        #define CTS_0_PORT_ENABLE  GPIODEN_A
        #define CTS_0_PORT_DDR     GPIODIR_A
        #define CTS_0_PORT         PORT_A
        #define CTS_0_INT_PRIORITY 3

        #define RTS_0_PORT         GPIODATA_D
        #define RTS_0_PIN          PORTD_BIT1
        #define RTS_0_PORT_POWER   CGC_GPIOD
        #define RTS_0_PORT_ENABLE  GPIODEN_D
        #define RTS_0_PORT_DDR     GPIODIR_D

This is configuring CTS and RTS on UART0 on the pins PA-3 and PD-1. CTS is also given an interrupt priority since it is then automatically configured as a port interrupt and controls the transmit flow based on the state that it reads (with state change interrupts stopping and restarting the flow as appropriate).
If the input buffer gets critically full (number fo characters greater than the "high water level") the tty driver calls fnControlLine(Channel, CLEAR_CTS, tx_ctl->opn_mode); and the Stellaris driver then sets the defined GPIO stat eaccordingly (once the buffer becomes empty the RTS line is then automatically re-asserted).

Therefore I would expect that the RTS/CTS operation is fully implemented for your chip (the GPIO bit is generic so you can chose the pins that would like to assign).

Most of the RTS/CTS operation is described in http://www.utasker.com/docs/uTasker/uTaskerUART.PDF.

In chapter 8 in the same document there is a description of how RS485 is realised for chips that don't have automatic control. Usually it is necessary to use a timer to ensure that the line is accurately controlled, which is also valid for the Stellaris devices. The code reference in the document should be OK to control this - it is implemented like this in the MODBUS module, which has also used on Stellaris parts in RS485 mode.

Regards

Mark

[jezc]

Hi Mark,

Thank you for such a prompt & informative response - I will try that (and probably prove the RTS/TS operation first, then move onto teh RS485) and ask if/when I get stuck!

Cheers,
    Jez