Can I call the same usb port twice with two different drivers or would I have to combine the drivers and protocol into a custom one for this to work with indi?
I've had the problem of "cheapduino" usb ID overlap for a very long time and saw an opportunity to kill 2 problems at once when my filter wheel arduino died last week(as if the cameras fighting wasn't enough -.-)
I had the crazy idea of combining the code from my focuser(moonlite protocol) and my filter wheel(Xagyl protocol) into one unit to reduce cables and ports as well as solving the udev duplicate ID problem.
AFAIK, if the USB interface is always claimed then no. You can write a custom protocol to make your arduino the "front-end" for both the focuser and filter wheel devices.
Yeah, I agree. I think once opened the system locks the device port so combining drivers would also be needed.
Along the same lines, it might be an interesting project to make an all in one accessory unit. An arduino with a motor shield could be programmed to do focuser, filter wheel, a flip cover, a rotator, and even expandable switched i/o, because those low current low priority devices rarely even run at the same time. Or how bout a motor shield for the RPI3? and moving that up there!
My brain is being more ambitious than my body or available time these days... Fun to think about though.
I'll probably just fix the filter wheel.
Tanks,
Ray
Blueshawk,
The issue is that when you open a serial port and leave it open it locks out other devices.
I suggest you keep them as two separate devices that way a fault with one does not stop both from working.
Paul
@Maxer: Thank's I'll check it out.
@PHOMER60: Good point about keeping them separate to isolate issues from a serial standpoint. I'll have to consider that if I try to do an larger combined rpi3 project.
For my own gear, I took a bit of time to research it and decided to use the Teensy 3.2 I had on hand to put the existing wheel back together for now. It only took about an hour to move wires and update the IDE to handle downloading to the teensy. I was able to use the same i/o mapping, and it looks like it may go right away. The change from cheapduino should clear up my current udev rule issue and make getting the system online easier and faster.
edit: [ Read through and recognized the link from last year's build - when I first realized the issue. I tried using the script method but it borks indi handshaking. I also tested for an eprom in the chip and got no response.] thanks for helping