k60 UART Interrupts

[MWMinor]

Hi everyone

I'm using CW10.6 and MQX4.1 and developing an application with the K60 on a TWSK60 tower assembly.

I have connected a TFT display which has a serial port (just TX/RX) which I'm driving through UART4 (ttye:) on the K60 board. The commands for the display are sent as "printf" string commands.

For example;

void *fh_ptr;

fh_ptr = (void *)fopen("ttye:", BSP_DEFAULT_IO_OPEN_MODE);

if (fh_ptr == NULL) {

printf("Cannot open the interface to the display\n"); /* prints on default IO port */

_task_block();

} /* ttye port available */

_io_set_handle(IO_STDOUT, fh_ptr);

printf("FRAME 10 10 300 204 5 0 %d\n",ORANGE); /*draws a frame on the display at coordinates 10 10 */

Every was going nicely until I needed to receive some data from the display (it has a touch screen capability and sends characters down the serial port to indicate coordinates etc) so thought I would just reconfigure the ttye: port to be an interrupt driven one by making the change to the config.h file and enabling the ittye: instead of ttye:

I'm sure there are some other changes I need to make like adding some form of interrupt service routine to deal with characters received from the display, but I'm really struggling to find either examples or sufficiently clear words in the documentation. On top of that, the printf commands no longer consistently get through to the display

Can anyone help me please...?

Ken

[MWMinor]

After a few days of working this problem I have moved forward to the point where I can send characters to the display over the serial port but the receive side of things is still causing me a problem, made worse by the fact that the receive port seems to be storing the data as it's transmitted out. This is really messing up the receiver.

What I think I need is a mechanism of disabling the receiver when I transmit, then enable the receiver (perhaps by an interrupt) when we want to listen for any incoming traffic and there is nothing to transmit.

I could do with some guidance on developing the ISR and how to include this into my code.

Any assistance would be appreciated

Ken

[matthewkendall]

You don't need to develop an ISR. If you configure your project (in user_config.h) to use the interrupt-driven driver then open the "ittye:" port you need do no more. The driver includes ISRs to handle the transmit and receive queues and you can simply use getc and putc (or higher level things like printf) in the normal way.

If you are seeing transmit characters coming back on your receive path, and you have a normal full-duplex underlying hardware link, then you likely have local-echo enabled at one end of the link. At the MQX end this is configured by the flags you pass to fopen. I see you are passing BSP_DEFAULT_IO_OPEN_MODE; your BSP will tell you what that decodes to. You may need to pass something else.

[MWMinor]

Hi Matthew,

I've managed to progress this a little further but still having problems. I removed the IO_SERIAL_ECHO from BSP_DEFAULT_IO_OPEN_MODE but that made little difference. I then disconnected the display and used a scope to look at the Tx/Rx signals generated and can see the processor is putting out the same signals on both. ie when I transmit, the data can be seen on Tx AND Rx....!

Any ideas as to how to stop this happening...?

Ken

[MWMinor]

Hi Matthew

Thanks for the answers. The hardware I am using at the moment is a TWR-K60D100M assembly and the BSP is one I cloned from that supplied by Freescale for that tower board, so I assume somewhere in the documentation I'll find out how to decode BSP_DEFAULT_IO_OPEN_MODE. The serial port is a very simple one TX and RX only. No handshake controls so I guess not full duplex, but it does seem like the port is being configured to look like a terminal and just echo's characters back. I'll keep looking...

Regards

Ken