Is there a way to control the amount of data at the uart input required to generate an event? There could also be a timer to control when to generate an event after data has started to arrive. I want to start processing the input data earlier, rather than waiting for the whole message to arrive.
This is because I need to detect from the signalling at the start of the message what the baud rate is, then switch it before the rest of the message comes in. I’m not sure this is possible with the API we are presented with.
You can subscribe to unsolicited events on UART. AFAIR you will get an event on every new char typed in. But I’m not sure you will be able to translate data from one baudrate to another.
Thanks PennyBlack, but the issue is with a input char rate of say 240 chars per sec from a device, you don’t get an event for each char, you get a chunk of chars in the input buffer.
Unless you are pointing to something else?
But if the baudrate is incorrect the very first char will be incorrect. How are you going to correct it? And if you have higher baudrate on receiver than on transmitter you will get only a part of char and information about sent char will be lost.
Ooops, sorry about the name BlackyBlack, I remembered it wrong.
The system I am connecting to has two possible baud rates, 1200 and 2400. There is a string of a specially choosen char at the beginning of the message. If you read these at 2400 you get one type of char, at 1200 a different char so you can work out which baud rate is required. Then you switch the baud rate of the port and read the rest of the message correctly. Not nice, but it works where you have low level control of the uart.
I just found in the user guide that the baud rate can not be changed while the port is in the data state, so I would have to switch it to AT mode then back. No idea how fast the FSU will respond to this. Not looking likely.
There is no handshaking unfortunately but there is generally a retransmission, but this is a last port of call as the messages are prone to error. The optimum is to switch mid-message. Think I’m going to be relying on the re-transmission though …
It not a nice network to talk to!
Thanks for the thoughts.
There are similar controls to the ones I am interested in if you make a virtual com port mux (+CMUX), but I guess these are all going to be multiples of the existing timing/buffer fullness. It talks about 20ms being the minimum unit there. That would be 5 chars at 2400 baud. That would work. The default is 100 ms, ie 20 chars which is roughly what I see. Perhaps I set up a single virtual port and use these controls?
Worth a shot.
Hummm … lowest baud is 9600 in this case.
N1 and T1 are the interesting parameters.
Close but perhaps not close enough.
Humm… ADL_User_Guide p426 Open UART Interface. “Direct access to the Wireless CPU UART Service Providers” what ever they are, but sounds promising.
p431 talks about fd_cap - fifo depth capability
min_dur_rx
p439 talks about UART_FD_BOTH_OFF to turn off UART buffers and the rx_size “the UART service provider’s reception trigger level”
all sounds good but its not obvious to me how its all used. Any one using Open UART interface? So far I have used FCM only.
