preview serial buffer

[Valarauca]

Is their a way to preview a serial buffer? So that I can read its contents without flushing/clearing the buffer?

[crossrulz]

Not really.  What exactly are you trying to do?  There is likely a better way to do this.

[Valarauca]

I have serveral hardware devices connected on an RS485 bus, I need to test software that will communicate with these devices. So I need a way of simulating 3 devices sharing an RS485 bus.

I don't have the hardware either, thus why I'm doing it in software.

[Dennis_Knutson]

What does that have to do with your original question? Do you at least have a couple of the RS485 converters? Fully simulating an external instrument would be fairly time consuming but could be done by looping back the serial connection and writing another program that reads and writes back.

[Valarauca]

The RS485 standard I'm using has addressing. A single device has a single address. If  I use multiple loop back hardware I'll have functinality for a single address, but not for the other 2 or 3.

The idea was a non-flushed read. I could preview the read. Check the address header, if valid flush the buffer, if not release the lock on the port, and release a semaphore to pass the port to the next simulated device.

Also I dont possess multiple RS485 converts at this moment.

Also even if I did create a single converter per program, and wired their busses together (just creating dummy instances of each controller). I'd need upwards of 20 controllers for 16 devices on 4 busses, and 20 USB ports 0.0

[crossrulz]

What you probably really want to do here is have one loop do nothing but read that serial data and then use queues to send the data to the simulated devices.  Each simulated device can do whatever it wants with the data from there.  This will at least check your logic, but not the hardware (which you don't have anyways).

[Valarauca]

That's basically what I'm doing, but with Data sockets. SIngle master program (per serial port) hosts data it recieves form a simulated com0com port (basically an simulated null modem cable).

The goal isn't to ensure hardware compatability, but to check the logic of the primary application. I've had a few strange bugs crop up that need the whole thing master program be debugged as a whole.