Hardware flow control controlling RTS / CTS with IOCTL

[CarlFST60L]

Hi,

Can someone please post an example of using ioctl to set RTS?

I have opened a port with:

fp = fopen( "ittyb:", (pointer)(IO_SERIAL_RAW_IO | IO_SERIAL_HW_FLOW));

Now when I transmit data out of ittyb with

fprintf(fp, "test");

Is the driver suppose to set the control the RTS output pin? Or do I need to manually control RTS using "_IO_IOCTL_SERIAL_SET_HW_SIGNAL" and "IO_SERIAL_RTS"?If so, how do I properly use ioctl with these commands?

Also, IOCTL.h does define all the hardware flow control pins (which are not supported on either eval kit). How do I enable and allocate them for my own BSP/PSP? (I havnt looked into this, thought I would just and this question while im here)...

[Ed_EmbeddedAcce]

Hi,

By default the open mode is XON/XOFF which is set when the device is opened.  If you want hardware flow control you can create your own open mode define like the default one but specify hardware flow control.  Take a look in the header file for all the options.

IO_SERIAL_HW_FLOW_CONTROL

   #define BSP_DEFAULT_IO_OPEN_MODE                      (pointer) (IO_SERIAL_XON_XOFF | IO_SERIAL_TRANSLATION | IO_SERIAL_ECH

Hope this helps 

[CarlFST60L]

Sorry, Im confused, was that a response to my post?

Are you saying the example I posted of opening ittyb using IO_SERIAL_HW_FLOW_CONTROL is wrong?

Note: I reaslise that I did not copy and past my example as I was not at the computer any longer, so my example is slightly wrong i.e. missing _CONTROL in IO_SERIAL_HW_FLOW_CONTROL, but I did copy and past the code from the serial.h file.

Message Edited by CarlFST60L on 2009-04-01 09:26 PM

[CarlFST60L]

Can someone please tell me how to use CTS/RTS under MQX with a simple example using IOCTL?

Also, does CTS/RTS get handled automatically using the below example:

//In some task...
pointer fd; fd = (pointer)("ittyb:", (pointer)(IO_SERIAL_RAW_IO | IO_SERIAL_HW_FLOW_CONTROL);frpintf(fd, "This is a test\r\n");

With the above example, the software appears to take no notice of inputs or outputs for hardware flow contro. I have manually forced the output to allow transfer. Its as if there is no hardware flow control support, or, i am doing something wrong.

[Pixo · Accepted solution]

I had the same problem and I posted a SR over TIC.  Here is the answer I got:

"Service Request SR 1-555576139: After verify the UART driver I verified that it does not implement the IO_IOCTL_SERIAL_GET_HW_SIGNAL, IO_IOCTL_SERIAL_SET_HW_SIGNAL and IO_IOCTL_SERIAL_CLEAR_HW_SIGNAL in the _io_ioctl() function. For that reason the hardware control is not working as should. It might be possible that future releases implement it. What you can do to control manually is to set the RTS and CTS pins as GPIO."

[CarlFST60L]

Thanks Pixo, I had wasted a full day trying just about everything under the sun to get this to go.

Not sure what Ed was talking about earlier. The modem is not in XON/XOFF mode by default, and, now we find hardware flow control doesn't work.

Its quite a surprise that the options are there in the software configuration, the hardware is there (well CTS / RTS anyway), but the software doesn't work. I have read the release notes for the next version (3.1) but this issue was not addressed.

It makes me think that MQX/Freescale/Embedded access MUST invest some serious time in making documentation to allow for various custom firmware boot loaders, and at least a full example of a serial boot loader. It is becoming very clear that MQX is not complete and will need future software updates to allow 'full support' for hardware and processor peripherals. I know I am writing various 'drivers' that are just patch's to get us going as we sure did not plan to be developing so many low level drivers which are just missing from MQX.

Thanks again Pixo.

[CarlFST60L]

I have searched the release notes for 3.1, 3.2 and 3.3 and nothing came up under 'flow', 'CTS' or 'RTS'.

Was the hardware flow control added? Or am I stuck manually controlling CTS/RTS?

I just quickly enabled hardware flow control and was not able to see the correct voltages (although only quickly, I dont want to waste time on it again)... We use a multiplexer in our design and its quite ugly to manually handle hardware flow control.

If its not supported, can you guys remove all your references to it in the software. There is no point having all the definitions for something that doesnt work, other than to cause confusion to developers.

[Jetoleg]

I am having similar problem with RTS control (it absolulty required for RS485 halfduplex coms). Funny to say but MSF52259 chip has excelent hardware option for such flow control - see UMR2 register bit 5 TXRTS. When set to one RTS pin is automaticly manipulated by chips UART (MSF52259 Reference mamual pafe 28-7).

I found the place in MQX where OS is setting UMR2 register values. It seams to be in fuction _mcf52xx_uart_serial_polled_ioctl in serl_pol_mcf52xx.c file. But there only stop bit length control portion of the UMR2 register is manipulated.

By the way proper bit values already declared in MXQ file mcf52xx_uart.h (see defenition of MCF52XX_UART_UMR2_TXRTS ), but sadly  it's not used anywhere in actual control function. I think I could right proper function extensions for _mcf52xx_uart_serial_polled_ioctl, but I am not sure what I have to compile after that. Is recompiling BSP would be sufficient for it or I have to recompile entire MQX build?

Another concern for such modification is MQX update. If alter MQX code the new releses installation would wipe it off clean I will be forced to found same solution all over again.

Is anyone did such things before? Does it really the way to fix inhereted MQX problem or I better off with making my own serial drivers?

[WHookway]

Hi,

I have a similar need in that I need to control the RTS signal directly.  I have written my own interrupt handler and I am now trying to control RTS.  From the debugger I cannot toggle the output from the registers or my code.  Note: I believe the mcf52xx_uart.h structure has an error at the end, the UOP0 register is incorrectly named UIP0 in the WRITE structure.  As the RTS and CTS are lumped in with the same pin group as the TX and Rx lines (in terms of Primary Pin function), is there any additional setup required in terms of the GPIO structure when it is desired to control these pins manually?

Thanks,

Will

[WHookway]

Hi,

Sorry, since the handshaking signals were connected to the COMM connector and the serial initialization routine was setting up the primary function for Tx and Rx, I figured that the handshaking lines were setup also.   Needed to add the appropriate GPIO primary function setup for the RTS and CTS lines.  A fresh look caught this Monday morning.

Regards,

Will