I have a Digital MultiMeter GDM-8342. The multimeter is connected via the USB port, but in OS it should appear as virtual com port. I need to get measurements from the multimeter.
Can you tell me, I should write driver for multimetr or standard means can be used, for example, driver devc-serusb?
Is this a requirement (your being asked to make it appear as a virtual com port)? Or is this what you think should happen based on reading the documentation for how it works under Windows/Linux?
devc-serusb is for serial to USB converter devices. You have a multimeter. You are going to have to write your own driver. Hopefully the company has a Linux driver you can get the code for so you can see the USB command structure.
I think should happen based on reading the documentation of multimeter.
“The USB device port on the rear panel is used for remote control. The USB port on the DMM will appear as a virtual COM port to a connected PC. Any terminal program that can communicate via a serial port can be used for remote control.”
On windows multimeter works similarly. I have driver for Windows (without source codes).
No Linux driver for multimeter. I saw similar usb-serial driver for Linux. elixir.free-electrons.com/linux/ … l/sierra.c But in QNX no similar code. In QNX no structures usb_serial, usb_serial_port and etc.
I present the driver work so. After downloading of driver, a it appears file “ttyUSB1” (for example) in the “/ dev” folder. Then i can open this file and write / read data as from a normal com- port.
Does anyone have any idea how to implement a “virtual” com port? I will be glad to examples of source codes.
Correct. That is how it should appear in QNX as /dev/myMultimeter then you can read/write to it with the normal open/close/read/write commands.
There are examples you should be able to google. Usually they are found under samples for resource managers. That will let you implement the open/close/read/write part that is the virtual com port.
The problem is going to be doing the USB communication to the multimeter. You must get the source code from the manufacturer or else you will not be able to communicate with the device because you don’t know the USB commands to send to the device. You should write to the manufacturer and see if they will help you. Otherwise you’ll have to get a USB sniffer in Windows and sniff the packets being send/received on the USB bus and reverse engineer it which is usually messy.
You want to run the “usb -vv” command to see what the device looks like. Some devices will conform to a “class” definition in which case there may be a QNX driver that will work with the device. If not, Tim is correct, you will have to write a driver.
There are a fair number of devices that use an FTDI USB/Serial chip as part of the interface. Using the QNX USB serial driver may work.
In one case a few years ago, the only thing keeping the driver from working was that the VID:DID wasn’t on the drivers list of supported devices, and merely by zapping the table in the driver I was able to get it to work.
If reading the device this way works, you still have to understand the format of what you are reading.
I entered the “manager resources resource qnx” in Google and received a link to a similar question from this forum, which did not receive an answer. viewtopic.php?f=19&t=4827
I have a list of the commands that need to be sent to the multimeter to get the result.
I’m interested in the driver’s read and write functions. I have no idea how to connect these functions and the com-port.
I saw a driver for the KHK for USB devices, but without the implementation of usbserial. For example, here is qnx.org.ru/forum/index.php?topic=1588.30
My device will conforms to a “class” definition.
I typed “ftdi qnx driver” into Google, but did not find the source codes for the driver.
I will be grateful if at least a portion of the driver code relating to the USB connection and virtual com port
thanks in advance
If your device conforms to a class driver specification, which one, and is there are QNX class driver for this device? If so, you are done, the driver exists. The “usb -vv” command will answer the first question. I don’t think the FDTI driver source is public, though like many things, it can be obtained if you go through the right channels.
I may have an example USB driver I can post. I’ll have a chance to look on Tuesday.
Thanks for mentioning the QNX link. It was fascinating for me to read. I provided a custom QNX driver for the Iomega Zip drive, both the parallel port and SCSI version for QNX 2. QNX never disclosed the QNX 4 Fsys interface, nor the QNX 6 Fsys interface. The EIDE version worked with the standard QNX drivers. I would have thought the same would have been true of the USB version as it should have worked with the devb-umass. What’s fascinating to me is that no one ever contacted me about this seeing as I had lots of experience with Zip drives as well as technical connections with Iomega at the time.
On the screenshot in the attachment, the output of the command “usb -vv” for my multimeter.
I will be happy to look at your driver.
You have a huge experience in working with QNX! I am familiar only with QNX6.))
If interested, there is a presentation in Russian, which describes a little more detail, how to write ordinary USB driver (not usbserial).
myshared.ru/slide/612174/ you can see here
imgur.com/5QoTxvY/embed download like here
You will notice under “Class:” it says “Vendor Specific”. This tells you that this is not a Class device, so only a custom driver will work.
This link shows how to write a resource manager. It includes sample code for handing read/write commands to your manager (handling IO_READ and handling IO_WRITE sections).
The sample code there will let you create a simple resource manager that will function as a virtual com port to handle read/write commands. Also Masochen has posted simple resource manager code here before and he may post his code again if you ask him for it.
However you still have to communicate with the multimeter over USB. That’s the hard part where you will need the vendor to tell you or give you sample code of what commands the device expects and what format they are in. At this point you are going to have to contact the vendor. The alternative is to get a USB sniffer (Wireshark I think does USB or there is an equivalent to Wireshark for USB) and examine the raw packets and reverse enginner it (which will be time consuming).
I started writing my driver a long time ago.
I’ve read Robert Kretten’s book earlier. Very similar on this book support7.qnx.com/download/downlo … o_RTOS.pdf
It says the same thing as your link)
On your link I did not find a line about the virtual com-port
I read that there are source codes for the devc-ser8250 for those who have Driver Development Kits (DDKs). qnx.com/developers/docs/6.5. … r8250.html
Can someone post the source code?
What do you think a virtual com port is? What are you expecting it to do?
Roberts book and that link provides a way for you to create a /dev/ entry (you can call it /dev/ser3 if you want). It then shows how to handle read/write operations. So any other program in QNX can use read/write commands to send or receive data from your driver. That’s exactly how devc-ser8250 works.
The heart of devc-ser8250 which is talking to the hardware (a UART in devc-ser8250’s case and a multimeter in your case) is the real work you have to do. Even if you get the source code for devc-ser8250 there will be nothing in there that you can use because talking to a UART via interrupts has nothing in common with talking to a multimeter via USB.
By the method of the link, you can write a normal driver. I expect that the driver will be able to communicate over the serial port protocol (for example, Modbus), with baudrate, start and stop bits, parity, and so on.
According to this
qnx.com/developers/docs/6.5. … r8250.html
the source to devc-ser8250 is in the character DDK which you can download here (6.3 source but should be OK)
assuming you have a licensed version of QNX Momentics.
Then you can emulate the baudrate/start/stop bits/parity etc in your driver (they will just be dummy calls since they won’t actually do anything because your communicating over USB) in the same way pterm does. Note that I say ‘emulate’ because your not actually going to do anything with those settings because USB doesn’t have baudrate/start/stop bits/parity etc.
I would suggest getting the USB DDK as well if you haven’t developed a USB driver before since you have to do USB communication to your multimeter.
I just checked their website here looking for driver code (which you MUST get to be able to talk over USB)
gwinstek.com/en-global/Suppo … ord=driver
Everything is a DLL. No source code or Linux mentioned. You will have to contact them directly a then hope they give you source code. But it doesn’t look promising because most companies offer Linux sample code.