I was tasked with writing some code for a PTZ-head using the Pelco-D protocol, which uses RS485 (2-wire). The code is intended to run on a Raspi, so I first figured out how to get that going. Once I was satisfied that I could exchange data between the Pi and the PTZ, I sat down at my laptop to write some actual code and hooked the PTZ up to it via the Ex-1333V usb to serial adapter which we aquired for this purpose. It can do RS232, 422 and 485. It apeared to work well enough with just the standard Ubuntu drivers, at least both its ports were properly recognised.
But I was unable to send data to the head. The transfer indicator on the adaptor lit up, but the head didn't move. For diagnosis, I connected my laptop to the Pi instead. Again the indicator lit up, but the pi didn't receive anything. So I tried the other way around, sending from the Pi and receiving on the laptop. That worked without issue. I started to fiddle around with configuration, and eventually realised that the pi was getting a signal when the adapter was set to RS232. The data was garbled, of course, but at least something was getting through.
So I started thinking about that driver CD provided with the adapter. Might be the driver converts the data before sending it through the USB, instead of converting it on the adapter? This would of course not be handled by the standard drivers. That's the assumption I'm working under currently in any case.
So I got the linux drivers on the cd, which turned out to be a tar containing a c-file, a header file and a makefile. I'm not very familiar with low-level linux stuff, so I was a bit confused. Sure, I could build it, but then what? Turning to the adapters poor excuse for a manual, the only thing I could find was the nice suggestion to "please follow the instructions for installing USB port drivers on your particular linux distribution". So I went looking for that, and found... nothing.
Which brings me here. I'll freely admit that this is the first time I'm working with serial, so there might be other things I'm not understanding here, and you should free to point them out. But for the moment I think those drivers are my best bet, so could somebody explain to me how to install them?
I wrote above that I assumed I could build the C project easily enough, but I didn't actually try. Saw no point in it without knowing what to do afterwards. I assumed wrong it turns out, as building produces an error. Here's the make output:
gcc -Wall -D__KERNEL__ -DMODULE -I/lib/modules/4.13.0-37-generic/build/include -D__SMP__ -DSMP -I/usr/src/linux-4.13.0-37-generic/drivers/usb/serial/ -O -c -o ftdi_sio.o ftdi_sio.c In file included from /lib/modules/4.13.0-37-generic/build/include/linux/kernel.h:6:0, from ftdi_sio.c:251: /lib/modules/4.13.0-37-generic/build/include/linux/linkage.h:7:10: fatal error: asm/linkage.h: No such file or directory #include <asm/linkage.h>
I've googled for the error, but couldn't quite pin down what to do. Apparently there should be a symlink to some system headers in this place, but isn't, but I can't figure out what header the link should point to exactly. If I interpret the makefile right (really not familiar with makefile, never went beyond "make this-project-i-downloaded", which usually worked), it's just attempting to build an object (.o) file:
# This Makefile has been simplified as much as possible, by putting all # generic material, independent of this specific directory, into # ../Rules.make. Read that file for details # The usb serial headers INCLUDEUSBSER := $(shell echo "/usr/src/linux-`uname -r`/drivers/usb/serial/") TOPDIR := $(shell pwd) #TOPDIR = . include $(TOPDIR)/Rules.make CFLAGS += -I$(INCLUDEUSBSER) -O OBJS = ftdi.o all: $(OBJS) ftdi.o: ftdi_sio.o $(LD) -r $^ -o $@ install: install -d $(INSTALLDIR) install -c $(OBJS) $(INSTALLDIR) clean: rm -f *.o *~ core
There's also a rather long rules file, but I doubt it will help a lot if I post the whole thing. It seems to be taken and modified from a book, as per its header:
# This file is part of the sample code for the book "Linux Device Drivers", # second edition. It is meant to be generic and is designed to be recycled # by other drivers. The comments should be clear enough. # It partly comes from Linux Makefile, and needs GNU make.
So maybe somebody already knows how it looks.