Tim,
There is a rolloff driver example at github.com/wotalota/indi-rolloffino.git
Might provide ideas on error handling and setting up the Ekos interface.
A couple of Arduino examples on sending back status and error information.
Driver is an edit from the Rolloff driver example.
/Tom
Thanks everyone.
I think I've got a good idea as to how to do it now. As I'm on standby for work this month with very little chance to get used I should have plenty of time to write the driver. All I then need is some clear skies. Haven't seen any for nearly a month !
All of this is making sense now and I'm ready to code. But for that I'll need debugging as no ones perfect
I've repeatedly gone through the video tutorials with which I've had two issues. 1) they are very very quick and when your not used to QTCreator I struggled to keep up ! 2) they are for an old version of QTCreator and whilst I think I've set everything up properly I can't get it to work properly.
To start with the breakpoints don't seem to get triggered everytime i run the code. Secondly when I use EKOS to disconnect from the indiserver and then stop the debugger I find in the linux system monitor that indiserver and my driver are still running. Sometimes I can kill them in the system monitor, on others I have to shut down QTCreator as well.
I've spent many hours on this and still cannot get it working. Again any advice would be gratefully received.
part ofhas always annoyed me and I do not use it anymore. I proposed an option to indiserver long ago (which got merged in) to accept paths to the drivers.
So in my build directory I run :
./indiserver ./some_driver
And that can be run directly from an IDE like QtCreator in debugging mode.
Drivers in the list without a path are the system-installed drivers, those with a ./ or some other relative path are for the drivers that I'm working on.
This is also convenient if you develop on another system.