Hello!


I need to do a program that reads and processes data coming from an USB(or COM) port using some kind of device that, in a perfect world, I would have physical access to it.
As I don't have the device while I am doing the program I want to emulate/simulate it so that the "faked device" can generate arbitrary data. That data would then be read and processed by the program.
The format of the data is not relevant at this time, all that I need is to simulate the device and throw bytes (or whatever it comes out of the ports).
I have done some search and could not find anything suitable to do the job.

Is anything out there that can do this for me?

Thanks in advance.

MM

If your plan is to access the USB or COM device through it's '/dev' file pseudo device, then you could create a virtual device using a virtual filesystem. The fuse (filesystem in userspace) system can be used to do this. Using fuse, you create a virtual filesystem, which is simply a defined set of callbacks that implement the services performed by all of the usual filesystem functions: open, read, write, close, seek, stat, ioctl, etc. In your case, most of these will be empty stubs that just return success status codes. The read(), write(), and perhaps ioctl() services will do most or all of the work, simply swallowing written data (maybe examining and storing it), and producing your fake data in response to read() requests. The emulation of character devices using this block oriented filesystem approach may be sub-optimal, with respect to such things as timing issues, device configuration (eg baud, parity, etc.).
I don't know of any standard virtual character device.
I believe I understand your overall intent, and now I will tell you my story, which I include mainly to provoke some thought, but not saying this is how you should proceed.
I once tried to create a virtual instrument that talked on RS-232. My code was intended to to be a general implementation that could emulate almost any instrument by receiving character data on a serial port, and responding with appropriate actions or replies. My approach used a configuration file that defined a set of instrument 'emulations'. An emulation was a set of 'behaviors', which are simply regular expressions that are matched on the input stream, and an associated set of actions performed in response. Each behavior has a set of three potential actions that can be performed. One action is to echo something to the console; could be a constant/literal string, or it could have some component(s) of the incoming matched data. The second potential action would be to define a format string for any possible reply to be emitted. This string would be a 'printf()' compatible format string, with '%' placeholders for reply data. The last possible action would be a list of 'things to do with the data'. This could be to store the data or some part of the data in a named 'register', manipulate the data arithmetically, or 'emit' something (send response data out the serial port). The tool was developed, never documented or fully debugged, and because it never got finished in time for the intended purpose, abandoned. Much of the work was done using lex and yacc, and some features never did work as I intended. I include a sample configuration file, as an example of some emulations and their respective behaviors. These emulations actually worked to emulate a high voltage power supply, the exact description of which I forget.
Suffice to say, I will be watching with interest to see what other people have done in this area. I hope my ramblings are not too far out in left field.
--- rod.

Wouldn't it just be easier to get a usb flash drive and plug it in? Just a thought.

Easier, yes. But how would it serve the purpose or emulating or simulating anything?
--- rod.

Thanks for you help theNbomr I think I can do something with that info
What I am trying to achieve is a virtual device for only emitting data it doesn't have to worry about some kind of input data.
I will see what I can do!
Thanks again.