For communication with devices which are not supported by VSM, i've made a (hardware) level-converter, to communicate with hardware in the real world.
I've used all lines, TX, RX, DSR, DTR, RTS, etc.
But for some reason frequenties injected at the hardware-side do not match with frequenties measured in VSM.
The other way shows the same, VSM-frequenties don't compare with the signal in real-world.
Both scopes (virtual and real) don't show equal square waves.
Can anybody shine some light on this ??
Thanks in advance.
Theo
Compim (mis)use
Compim (mis)use
In the beginning there was nothing...
And even that exploded....
And even that exploded....
-
- 3rd Party Developer
- Posts: 461
- Joined: Mon 2006-03-13 13:16
- Location: Atlanta, Georgia, USA
What are you converting? RS-232C levels to RS-422A? And are you doing it just at the physical level, or are you generating new data? If you are actually trying to measue frequency, that will be a function of BAUD rate, number of bits (data bits, stop bits, and parity), and the actual data being sent. Perhaps a more logical comparison would be input and output of your converter where you look at levels and duration. In this case, I would expect VSM to correspond very closely to that actually measured.
Dick Perin
Engineer
Turner Broadcasting System Inc.
Atlanta, GA, USA
Engineer
Turner Broadcasting System Inc.
Atlanta, GA, USA
Re: Compim (mis)use
galaxy wrote:For communication with devices which are not supported by VSM, i've made a (hardware) level-converter, to communicate with hardware in the real world.
I've used all lines, TX, RX, DSR, DTR, RTS, etc.
But for some reason frequenties injected at the hardware-side do not match with frequenties measured in VSM.
The other way shows the same, VSM-frequenties don't compare with the signal in real-world.
Both scopes (virtual and real) don't show equal square waves.
Can anybody shine some light on this ??
Thanks in advance.
Theo
I'm curiuos to know what you're doing with this. Could you please send me with schematic/code of your app. Have to admit I never delt with virtual/real world interactions and never thought it'd have been of some interest (VSM is a software simulator after all !), but this worths me to have a look at (perhaps ).
Kind regards,
Ettore Arena - Labcenter Electronics.
Ettore Arena - Labcenter Electronics.
-
- Professional User
- Posts: 37
- Joined: Thu 2006-03-09 23:04
AFAIK- VSMVDD project did just that- interaction between VSM and hardware.
Look at http://uk.geocities.com/vsmvdd/
Look at http://uk.geocities.com/vsmvdd/
As far as I understood 'galaxy' is doing something of more convoluted, I think.
Yes, I had a look at that guy's project, though, apart being it a singular excercise and nice example, I can't figure the use such of the stuff may have in professional field.
Yes, I had a look at that guy's project, though, apart being it a singular excercise and nice example, I can't figure the use such of the stuff may have in professional field.
Kind regards,
Ettore Arena - Labcenter Electronics.
Ettore Arena - Labcenter Electronics.
Re: Compim (mis)use
In theory the average long term frequency should be the same, (assuming the simulation is running in real-time,) though there is likely to be some significant jitter, which is likely why you are not seeing a nice periodic signal.galaxy wrote:For communication with devices which are not supported by VSM, i've made a (hardware) level-converter, to communicate with hardware in the real world.
I've used all lines, TX, RX, DSR, DTR, RTS, etc.
But for some reason frequenties injected at the hardware-side do not match with frequenties measured in VSM.
The other way shows the same, VSM-frequenties don't compare with the signal in real-world.
Both scopes (virtual and real) don't show equal square waves.
Can anybody shine some light on this ??
Thanks in advance.
Theo
The jitter comes from three places: the hardware itself performs buffering on the signals, in particular, RXD and TXD tend to have 16 or more words of buffer on modern hardware, though other signals are also buffered to keep correct pace/sequence with RXD and TXD; the operating system and its associated drivers also buffer the signals and do not time stamp when those signals changed; the operating system is multi-tasking and so VSM can only monitor the signals from the operating system in near real-time, which means that as there is no time stamping the best that COMPIM can do is maintain the order in which events took place. COMPIM itself buffers to allow for baud-rate translation, though this will likely have negligible or no effect, as COMPIM dispatches buffered data as soon as possible.
Kind regards,
John
Re: Compim (mis)use
Schematic is very simple: Compim, signal generator connected to RTS, and a counter connected to CTS. Thats all.Ettore wrote:
I'm curiuos to know what you're doing with this. Could you please send me with schematic/code of your app. Have to admit I never delt with virtual/real world interactions and never thought it'd have been of some interest (VSM is a software simulator after all !), but this worths me to have a look at (perhaps ).
As said, the purpose is to communicate with hardware components which are not supported by VSM.
Examples are:
- I want to read-out a TCN75 I²C T-sensor
- I Want to see how fast i can update a MM5450 displaydriver.
- How fast can i run my steppers under a certain load.
I can imagine that TX/RX may have some restrictions, but the other lines must be toggle-able, even at a relative high frequentie.
Theo
In the beginning there was nothing...
And even that exploded....
And even that exploded....