eTPU based serial

[v8dave]

Has anyone used the eTPU for serial communications on the MOD5234?

I have looked through all the code and libraries I can find etc and can't see for a way to know if the data has been transmitted?

I am using 2 serial ports on the eTPU with RS485 and I need to know when the transmit buffer is empty so that I can switch the RS485 driver to receive.

Also wonder what functions are available once I open the channels for serial use and have a file descriptor. Very little in the way of document, or at least what I can find in the installation.

Cheers,
Dave...

[Ridgeglider]

SEE the serial library section of:
C:\nburn\docs\NetBurnerRuntimeLibrary\NetBurnerRuntimeLibraries.pdf

Code: Select all

void Serial485HalfDupMode( int port, int enab );

It seems to me that this function had an issue that forced it to only work on Com2 despite the input argument, but that if you looked at the code it was easy to fix. I think this was because only Com2 on the NB dev boards supported RS485. Sorry to be foggy on the details.

I also seem to remember that this bug was fixed in a recent release.

[v8dave]

I saw this but I can't see how it can be used with the eTPU UARTS.

I am happy to control the RS485 driver IC myself. COM0 is the debug port, COM1 is not used as I have this allocated to CAN and COM2 is used to drive a modem as the PPP library only supports the standard UARTS.

Dave...

[Ridgeglider]

OK, just looked at the code... I see your point. Hmmm. There are some etpu hardware flow control uart modules: C:\nburn\MOD5234\system\ETPU\functions_API\etpu_uart_fc.c

Maybe an etpu pin configured as RTS (through an inverter?) would work as the RS485 throttle?

[v8dave]

Thanks RG, I'll check it out tomorrow when I get back to coding and report on my progress.

Dave...

[rnixon]

I think the common way to etpu serial is if you just need tx/rx. If you want to do RS-232 hardware flow control or half duplex RS-485 where you have to control the tx enable, you need to do it manually in some other part of your code. Its not supported by the etpu.

[v8dave]

Yeah, I know about controlling it. What I need is a way of knowing if the transmit buffer is empty so that I can then do the RS485 TX/RX switching in my code. At this time, I am still looking to see how to know this information. I am going to check out the info from RG later.

Cheers,
Dave...

[Chris Ruff]

I have solved this problem in the past by setting a hardware timer to one character time at the present baud rate and setting up an interrupt for that timer.

When the Tx code sends the last char it sets the timer. When the timer goes off and your code is invoked in the interrupt, that code either releases the mike button (direction bit) or sets a flag for task code to release the mike button.

Chris

[Ridgeglider]

Chris: Wouldn't your timer solution require that (for large blocks of output) either no other tasks run while your timer is ticking? Or (for smaller blocks) that or that you know exactly when the UART internal buffer is fully loaded and the Tx is triggered. I think so, and therefore it seems like a plausible although somewhat inconvenient solution.

Any idea if an inverted RTS signal can be used to gate this? Somehow I think so, but not 100% sure... I think that's why the RS485 circuits on the NB dev boards have the inverter in the RTS line J2[38]. Thus pin can be configured as RTS for either Com1 or Com2 and I believe the '485 half-duplex code sets up the RTS functionality of the internal UARTS. (IE not GPIO??) If so, it would seem pretty straightforward to use the flowcontrol modes on the eTPU the same way.

[Chris Ruff]

Actually, there is quite a lot of hand wringing about this by RS-485 users.

The fundamental trick is to know when the last bit has wiggled out of the transmitter. Certain UART configurations will interrupt you when this last bit is gone, certain UARTs will move RTS when the last bit is gone when you configure it that way. The problem here is that the primitive TPU serial device has no such stuff. So if you are the one that spews out the bytes then you will know where the end of your message is and you can set the hardware timer up.

The timer interrupts everything, so uCOS is not a hindrance. When you wake up in the interrupt you release the mike button. and yer done.

When it is time to squeak again, you press the mike button, start up the transmitter routine, and it sets the timer at the last byte in the circulat buffer or when the line-feed is encountered or whatever

Chris