Forum > General

Receiving serial string with 5DPO

<< < (2/3) > >>

Getting fine level control of serial comms on modern PCs is pretty hard, because there is now so much OS in the way. Trying to read bytes one at a time will not be any more reliable than reading chunks, and generally just uses up CPU.

A ReceiveString function will never return whole packets, because it doesn't know the packet format.

I think it is best to handle the data arriving in chunks, and accept the fact that chunks will come in every combination possible, i.e. start, middle, end, plus mixed with last/next packets and also errors or other junk.

However, if you write the code with a routine called process_rx_byte, which handles bytes one at a time, identifies whole packets, and discards faulty ones, all of which you have to do anyway, then you can call the same routine from an OnCharReceived event or an OnStringReceived.

Receiving data as bytes or string is functionally equivalent.

Thanks all for the replies.
My baudrate is 38400 which is low and will improve reliability.

I'm using this control now :

This control has also an OnPackage event which is great for my application.

The Elektor lib is somethin g to keep in mind. I've worked with VB in the past and know the port can be configured to fired an interrupt everytime a byte is received.
I'm assuming it's got the same functionality.

38400 is low? Well, that depends. If you insist on events per char, then your application must be able to handle about 3840 events per second.... be aware that events are not the same as hardware interrupts.

AFAIK in Windows the com.drv talks to the UART. And again AFAIK, those components that provide events for serial input on a per character base simply receive strings from the com.drv and cut them to characters, thereby generating events for each character.


John, you're right. I didn't think of it like that.
When writing software for microcontrollers this is never an issue.
I was thinking in the same way to write PC software assuming the speed wouldn't be a problem.....

So : a small 8 bit microcontroller clocked at 4MHz does this task beter then a Pentium 4 clocked at 2.8GHz ...  :)


--- Quote ---So : a small 8 bit microcontroller clocked at 4MHz does this task beter then a Pentium 4 clocked at 2.8GHz ...
--- End quote ---

Well, this comparison isn't fair...  like bobc said: there is so much OS between the physical port and your event. + competing for cpu-time...

If you want to reduce the risc of missing packets, setup the onreceive events in a separate thread and write the accepted strings into a ring-buffer. The mainprogram now only has to act on )process) new strings in the ring-buffer.

If milliseconds-fast responses (from pc to other device) are required, I think you have to descend to as close to the hardwre you can get, e.g. write your own com.drv...



[0] Message Index

[#] Next page

[*] Previous page

Go to full version