Conversion to TX interrupts

Questions on UARTs, and serial communication
Post Reply
basicchip
Posts: 845
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Conversion to TX interrupts

Post by basicchip » Fri Apr 05, 2013 12:53 am

We converted to TX interrupts and using buffers in early March. Our initial tests show no problems, but we started moving some earlier Modbus code over to BASIC for a consulting project. And with the port we put together some serial torture tests, and we started to see some issues, many of which the transmission of serial would get out of sync with the pointers and would go mute.

We have isolated and fixed that code on both the C and BASIC side. MakeItC has been updated to include the new sources and BASICtools now checks for these firmware versions, and flags a warning for those.

We will contact the people that we know may have the issue to offer a firmware fix.



firepuppy
Posts: 6
Joined: Fri Feb 15, 2013 4:14 pm

Re: Conversion to TX interrupts

Post by firepuppy » Thu May 02, 2013 9:44 pm

Bruce,

Yes, please, I'd like to have the new firmware to try this again; I saw similar behavior to what you are describing in my early tests of v8.20 back in Feb.

I PM'd you regarding this in more detail.

Thanx,
emmette

firepuppy
Posts: 6
Joined: Fri Feb 15, 2013 4:14 pm

Re: Conversion to TX interrupts

Post by firepuppy » Wed May 22, 2013 8:58 pm

Bruce,
I am still seeing overflow issues when using TXD1 to transmit data; I have tried your new firmware and have even had a go at directly addressing the NXP UART1 registers, but still seeing some problems. Specifically, I saw no way in the the NXP documentation to tell when the FIFO TXD buffer was getting full...

Can you tell me how your code for TXD1 works or give me any insight into managing the NXP FIFO myself??

Stuck on this for now...
Thanx,
emmette

basicchip
Posts: 845
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Re: Conversion to TX interrupts

Post by basicchip » Wed May 22, 2013 10:55 pm

The source code for TXD on the UARTs is published as part of the C download. The NXP FIFOs only report empty or not empty.

We have extensively tested our code, which will buffer up to (128/256 ??) bytes before it waits for bytes to be transmitted, serviced by interrupts. But this is not the only software in the system, there is the FTDI USB serial converter that buffers data before sending over the USB. then you also have the USB serial driver, USB driver, then Windows itself. Then your application code.

You can easily overrun the PC. You can't just blast data at PC and expect it to catch it all. At the BASIC end we will send it as fast as the serial port can take it, and it throttles the BASIC program when the buffer is full. We did loop back tests for days both between 2 ARM devices and between an ARM and the PC using both C and Tcl on the PC. So we are pretty confident in our code.

firepuppy
Posts: 6
Joined: Fri Feb 15, 2013 4:14 pm

Re: Conversion to TX interrupts

Post by firepuppy » Fri May 31, 2013 4:41 pm

Bruce,
Thanx for your reply from last week; after reviewing the C sources from the latest download, I have a few ?'s:

1. I assumed the relevant pieces are in uart.c & uart.h; is this correct?

2. I noticed in the comments you may be assuming UART1 is connected to P2.0/P2.1; I am using P0.15/P0.16 instead (to get closer to the modem control pins (RTS1/CTS1/DCD1), which I am connecting to the relevant pins on my device). Do you see any problems this will cause with your code?

3. It doesn't look like you are handling MSR interrupts (e.g.: CTS state change) in your UART1 ISR; what are your thoughts on using hardware flow control on UART1??

4. In the transmit portion of your code, it looks like you are buffering up to 64 bytes (I am using ProPlus boards) instead of 128 or 256; is that correct or am I missing something?

5. Reading further in your code; it looks like, after starting to buffer, when you are interrupted on an empty FIFO, you dump up to 15 bytes at a time and wait for it to empty again. Is that basically it?

My design is not using the FTDI or any USB interface, but rather connecting the UART1 pins (incl RTS/CTS/DCD) to a Class 1 Bluetooth module (Sena Parani BCD110) on my board which then sends the data over the air to a Windows PC with a Bluetooth USB adapter (Sena Parani UD100). I realize I still have the capability to overrun any of the devices in this chain. I am sending a 10-char msg @ 230Kbaud every millisecond, which theoretically should give me an extra 500 microseconds of busywait time between each msg (~50 microsecs to compute msg + ~450 microseconds to transmit 10 chars @ 230Kbaud). Everything works fine for the first N messages, where N seems to be between 40 and 300 msgs before I start to see overrun problems. What I believe is happening is that the Sena Bluetooth module is buffering some fairly large number of chars before building & transmitting a packet. When it finally does start to transmit over the radio side, it appears to be dropping CTS until the entire 1500? char packet is successfully transferred, which might be more than a millisecond, causing my program to hang waiting for CTS to go high again, thereby losing data.

One possible solution to this is to increase the TX buffer size; is there a way for me to override this in BASIC ??

Thanx in advance for any help you can provide with this issue,
emmette

basicchip
Posts: 845
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Re: Conversion to TX interrupts

Post by basicchip » Fri May 31, 2013 7:20 pm

1. uart.c and uart.h are the appropriate files

2. you can redirect the UART to another set of pins, it won' be altered by BASIC unless you call baud()

3. we do not use flow control interrupts

4. probably correct (as the code is over 10K lines now, I haven't memorized it yet)

5. I believe we send 16 bytes on TX FIFO is empty.

A quick look at the NXP user manual, it looks like you should be able to enable CTS flow control. In any case you can always write your own UART interrupt routine in BASIC, though I don't think that is necessary to use CTS. I have not used this myself.

firepuppy
Posts: 6
Joined: Fri Feb 15, 2013 4:14 pm

Re: Conversion to TX interrupts

Post by firepuppy » Fri May 31, 2013 8:02 pm

Thanks again for the quick reply and for answering most of my questions.
I surmized the 15 instead of 16 bytes at a time from a line I saw in uart.c, something to the effect of

" uartTXFIFOcnt = 15; // seems like 16 breaks it "

I currently have auto-CTS enabled on the NXP and that's how I'm seeing the signal drop; just polling it for now since I don't have an ISR. I did START to write my own UART interrupt routine to manage hardware flow control signal changes, but quickly realized that I'd have to redo ALL your work in uart.c since the NXP requires a single ISR to handle ALL of the possible kinds of UART interrupts (errors, reads, writes, etc). I may still do that if necessary, but I believe I could do away with monitoring CTS if I can get a big enough TX buffer to handle the delays when the Bluetooth module is sending out packets.

The only question I didn't get answered was my last one: is it possible to allow me to override the size of your TX buffer (possibly by allocating my own and giving you a pointer to it ??) ?? From my testing, I may need as much as 512 bytes to handle the amount of time my Bluetooth device is "paused" (CTS low for ~ 24 milliseconds!!)

Thanx again,
emmette

basicchip
Posts: 845
Joined: Fri Oct 19, 2012 2:39 am
Location: Lake Tahoe, CA
Contact:

Re: Conversion to TX interrupts

Post by basicchip » Fri May 31, 2013 8:59 pm

I've fixed that comment, 16 bytes are sent out, which fills the FIFO. Earlier versions of the code had some issue.

The firmware is hard coded with the buffer sizes, so to change it you would have to replace the firmware interrupt with one written in BASIC. While the pointer is in a table, and in theory we could tell you where that is in the current version it wouldn't change the size.

firepuppy
Posts: 6
Joined: Fri Feb 15, 2013 4:14 pm

Re: Conversion to TX interrupts

Post by firepuppy » Mon Jun 03, 2013 1:51 pm

Bruce,
Thanx once again for the quick response. I did some more testing over the weekend and determined positively that the problem lies with the Sena BT device I'm talking to. Even though BT comms is supposed to run at least 1Mbps with a max application throughput of .7Mbps (according to Wikipedia), the device I'm using will only stand about 75Kbps sustained!! I did try disabling flow control and was able to push that up to about 140Kbps before I started losing data. In my case, I need a maximum of 12000 CPS, so I should be good to go with no HWFC. I have appended a char count to the end of my data stream to make sure I haven't lost anything, but all my testing so far shows no loss after several Mb of data transferred.

I have another (sort of related) issue with TIMER accuracy (related since you mention in the docs that UART interrupts affect it), but I think I'll start a new thread in the Kitchen Sink forum I guess.

Thanx again for your help on this problem,
emmette

Post Reply