One of the things I am going to need is high speed UART. What is the maximum speed for the UARTs? I thought I saw 10 mps. Also, I have been reading about interrupt handling in .net. It sounds like it will be way too slow. Is there a way to create my own handlers?
At such a high speed I think it’s better to read the serial port from a thread instead of waiting for an interrupt.
I agree completely. I am leery of that as well. I doubt the thread will keep up with a byte at a time. Perhaps I need to investigate the UART buffering, but I fear assembling bytes into messages in .net is going to be too slow. I have been messing around with USB and CAN, and I was hoping to create something along those lines - where I can gather up messages of my own definition and shove them up to the framework complete.
The right way to handle UART is by having a thread that always empties as much as it can from UART in an endless loop.
Have you an example Gus? I have been setting a four byte packet and waiting for the bytes coming in… sometimes 1 or 2 or 3 mainly 4… but unpredicable
Cheers Ian
I am looking for very high speed - how many bytes can be buffered if the thread does not get back around in time? And is 10 mps the upper limit on the speed?
Yes, your code shouldn’t rely on how many bytes come in and you shouldn’t read 4 bytes. You should have a large buffer, like 500 bytes and then you read as much as you can with timeout set to zero.
I do not have an example but this also depends on what are you doing with the data.
How high, you may not be able to keep up if you do not use handshaking.
You can use 10000mbps but that doesn’t mean you are sending that much data per second, so the baud-rate has northing to do with amount if data transfered, unless you are using 100% buss load.
Suppose we had a device sending continuous information at 1 mbs - do you think a .net thread which is accepting bytes and forming them into messages to be delivered to other parts of the program could keep up and not cause overruns in the uart subsystem?
I am looking closer at the SerialPort class and it would appear there is another issue. It says of the ReadTimeout "Gets or sets the number of milliseconds before a time-out occurs when a read operation does not finish. " Suppose I perform a read and ask for 100 bytes - does this imply that the Read will wait for either 100 bytes or until the timeout is satisfied? If that is the case, we cannot do a general read and sort things out. We must always be reading a known number of bytes to avoid unwanted timeouts.
maybe you can keep up if you are not doing anything else but I am assuming you need to do something with the data and so you will not be able to keep up
on any level, a 1mbps without handshaking is a bad idea.
The problem with a protocol is that every sender up the line must provide the same. I cannot control the information that is arriving, and there could be substantial bursts. So my issue becomes where to buffer the bytes as they arrive, and it seemed as if this must be done before .net. I have messed around with USB and he clearly has a buffer somewhere. I would like to implement an api like that for uart communications.
I am assuming you are EMX and so you have megabytes of memory. So you can take the UART data as fast as you can and then process them later if needed.
I am assuming it is not constant flow of data.
You really have to do some testing to see how much can you do before running into problems…it is all a factor of how much EMX is doing beside reading UART
There will be quite a number of threads operating. Every message that arrives on the uart must be moved to the pc. Incoming messages from the pc must be processed. There may be a number of different simultaneous channels. There can be large continuous bursts of data - I have one example of 100k bytes. I guess what you are saying is that if things don’t work out with a .net thread there are no alternatives?
Just curious, what’s the source of your high speed data and what are you trying to accomplish?
If it didn’t work then faster processor, ChipworkX or native code, RLP
Wouter - Sorry this is so late in coming. This project is subject to interruption. We are looking at using UART as a bridge to other devices. These will handle comm to the rest of our world. Need to be somewhat circumspect here - but there can be multiple sources pouring in information at pretty high speed. As with any such arrangement it comes down to who provides the buffering. Unfortunately, by the time we reach .Net it is too late, since he is the slow man in all this. I was hoping to add a layer - analogous to the GHI CAN layer - that would mediate all this. Sounds like it is possible - so I am marching along with proof-of-concept.
Thanks for your interest. I am catching on to this environment.
Well - I have constructed my UART handler. I keep a 20k buffer internally and attempt to empty whatever is in the port buffer with each read. I then take this apart and and load it into my messages for transmission to the PC. Then CAN class - which hands me messages - operates quite well at 250k. The NETMF code is able to keep up. The UART handler - where I get a stream of bytes - keeps up at 9600. As speeds rise it falls further and further behind until it begins to lose messages entirely. The buffer for the port appears to be 16k. I am pretty sure I will need something like the CAN class. Is this possible using RLP?
Might as well round this out in case someone is listening. The comparison between CAN and UART is not valid in my environment. Message bytes may arrive on CAN at 250K, but multiple messages are not flowing at that speed. It simply takes 5-10 ms to construct my internal carrier, load it, and send it off to the task that ships it up to the PC. Bursts of data via UART at higher speeds (actually 19200 and above) overwhelm the internal SerialPort buffer pretty quickly. In the end I think I will need more processor speed.
I currently working on the same problem. I have a blackbox that sends data to the FEZ Cobra at 19200 (is slow in terms of communicationspeed). Until now I always get lost bytes. The FEZ Cobra just can’t follow and I always get lost bytes due to a buffer overrun of the SerialPort…
See my answer to your original post. FEZ Cobra will never lose a byte. Especially you are using handshaking!
We have customers using UART it at 1mbps!