Netburner Carrier Board and RTS/CTS

[tod]

I know you hardware guys are going to laugh at me but...
On the NetBurner carrier board (MOD-DEV100) I want to use Serial Port 1 (J8) to communicate with my touchscreen. When I turn on rts for transmit, that is:

Code: Select all

            SerialEnableHwTxFlow(m_portNumberToUse, enable);
            SerialEnableHwRxFlow(m_portNumberToUse, disable);

No data goes out. If I disable TxFlow some of the data goes out but not all of it. I'm assuming it's a flow control issue. The rest of the setup is std 115200, 8N1 No parity. When I set up to use the TouchScreen from a PC's serial port and test with
SerialPort::Handshake = Handshake.RequestToSend
it works fine. I can tell the cable from the touch screen has pins 2,3,5,7 and 8 connected which corresponds to the pins on the MOD100 schematic. I have to use a Null Modem adapter on J8. What do I do to get RTS/CTS to work?

I did notice on two of the schematics R1p08 and R1p09 that it appears I need to put a jumper on JP10 for CTS. I don't see anything for RTS - does it go to another page somewhere? R1p12 doesn't show this header. What is the difference among all the r1pxx versions? I would assume only one goes with my board (a rev V1.04).

Tod

[rnixon]

Unless the other side asserts CTS, you can't transmit. Thats how h/w flow control works. You could try pulling CTS high an see if that works. I'm going from old memory here, but I think that might be right. In other words, just because you raise RTS doesn't mean you can xmit.

[tod]

Since I had handshaking set to RequestToSend on the PC and it worked, then the device must be asserting CTS no? Maybe the Null modem adapter interferes or it has something to do with the DTE/DCE dance.

Oh well, if I can't figure it out by Monday I'll just have to swallow my pride and go visit the hardware guys.

[tod]

I think I was on the wrong track. I ran some more tests and it appears I only have a problem with the writestring() method. I was using both writeall() and writestring(). I'm beginning to think the six month break was too long, am I forgetting something simple? Do I need to do something to insure that writestring() flushes when it's done?

BTW thanks for the earlier response rnixon, it did help jog my brain some.

[tod]

OK - Never-mind. The problem appears to be on the device end. I can write out some more binary commands and then the rest of the writestring() data shows up.

[v8dave]

Hi Tod,

Can you hook up the TX to a serial port on your PC and see if you see all the bytes are coming in there. This will indicate if writestring itself is sending all the bytes out the port at least. What is the purpose of RTS on the remote device?

Is CTS being driven from your touch screen controller?

By the way, Rnixon had the CTS input the reverse (assuming he was referring to the micro connection). It needs to be LOW on the microcontroller input to make it active.

Dave...

[rnixon]

Thanks for pointing that out v8dave. I should have avoided saying high or low and just went with the ambiguous "asserted"

[v8dave]

No worries. Even after almost 30 years doing electronics I still get RS232 wiring wrong or can't remember which pin is TX and RX and end up getting out the meter and checking the voltages on the connectors. )

Dave...

[tod]

v8 and rnixon
Thanks for the input. Turns out it was my misunderstanding of NB's writestring() command. On the PC I wrote my own WriteString and it was sending out the entire string including the terminator. It appears the NB writestring() does NOT send out the terminator ('\0' ), and that was causing the touchscreen problems. I suspect not sending the terminator is for most cases desirable behavior. Since I was checking the string.length() against the number of bytes written I should have realized the terminator wasn't going. Once I added a SerialPort::WriteStringWithTerminator() to my class all the string commands starting going in their entirety. Problem solved.

[v8dave]

Hi Tod,

A terminator of ZERO is not one I have seen before. Normally it is carriage return or line feed if the message is ASCII.

Glad you got it sorted in the end.

By the way, a really useful PC app I have found for serial comms is a programme called Docklight from these guys:

http://www.docklight.de/

It is a great little tool and allows both ASCII and binary display. You can also use 2 com ports to decode 2 way traffic and write little scripts that will decode the message if it is binary etc.

Cheers
Dave...