Paul,
Adding all that would not be simple, partly because the ATMega162 is limited not only by flash (not such an issue), but also by RAM. I'm using roughly 85% of the RAM for variables and stuff. The other issue is that when operating there are many interrupts firing to drive the motors which means there is very little time for anything else to run on the CPU - in fact the Synta interface takes up pretty much all of what is left. There is practically no time when the CPU is idle.
However, you got me thinking, which is always a dangerous thing
. I have another idea which could be workable, and would actually open up AstroEQ quite nicely. Rather than trying to run everything on the one ATMega, what if there were a way to talk Synta. In essence have a CPU such as the one on the Arduino Uno (ATMega328P) which talks via serial to the AstroEQ using the Synta protocol - meaning it talks in exactly the same way as EQMOD does.
The idea would involve having a select switch to determine between EQMOD mode in which the ST4 port would be used as it currently is (for ST4) and a hand controller mode in which the ST4 port would be converted to a serial interface on to which a hand controller could be attached. This would not only allow various DIY hand controllers to be designed (I'd make the APIs for the synta protocol, and others can then customise to their needs), but would also allow future expansion to more intensive control such as go-to movements. The downsides to this are it would require slightly more than just a couple of push buttons, and is less likely to "just work" - the hand controller would have to communicate with a much more complex method (synta) rather than directly changing IO lines. But it would allow better customisability. An ST4 port could be added to the hand controller which would essentially perform pulse guiding via serial as EQMOD does with PHD.
I think there are two options really, (1) stick with the very simplistic stand alone mode I proposed earlier, or (2) go whole hog and make a full Synta interface hand controller.
While you are free to customise the AstroEQ source code (in fact I encourage you to try things out!), I think trying to hack on an LCD to the existing firmware which most people wouldn't use isn't viable. It's basically go all in, or stick with what is in the beta firmware.
As always, I await your feedback.
Grr, just realised I used the second UART port on the ATMega162 as GPIO for the mode select pins. I so regret doing that! Well, if I was going to do option 2, it would have to be some form of SPI based communication instead of serial. Not completely a game changer, but somewhat annoying!
Edit: I've had a think about that and SPI would be possible, though the AstroEQ board would have to be the master and the handcontroller the slave. Not such an issue really.
I've also been thinking if it is possible to get the best of both worlds, and I think it might be possible to have both the advanced SPI based hand controller and also the basic push button controller all using the same ST4 connector and without much in the way of additional code!
Edit 2: Nope, SPI is also not possible, for the same reason I can't use the second UART. The SS pin is one of the mode select pins. In itself this isn't am issue as the AstroEQ could be the master, *but* just to make me regret pin assignments again, it happens to be MS1 which for the DRV8834 boards can either be an output or an input (floating) - if it is an input, it disables the SPI controller!! Now I could say that the 8834 is only supported with modification to the driver board (basically reassign MS1 on the driver board to be MS3) which would allow it to work, but not sure at this moment.
