Some time has passed and I found time to work some more on the CNC controller which is now called Pandora. The first thing I looked into was getting a graphics framework to run that I could use to create the new UI. Initially, I was considering Qt, but I was not able to get it to compile statically let alone at all for this specific platform. The next thought was SDL 2.0 with DirectFB, which compiled, but was just not fast enough and I finally switched to SDL 1.2 which can draw to the framebuffer device directly by itself. A stripped down and statically compiled version of SDL 1.2 turned out to work very well. The next thing I did is start to create a UI framework and built a tiny test application to test displaying images and text rendered with TTF fonts
The makefile I made also does support cross-compilation. This will create a statically linked and stripped binary for the controller that loads and operates just fine.
The biggest challenge is reverse-engineering the software the controller originally came with. No source code is available to me and all I can do is to use disassembly tools and try to rewrite parts of that source code by hand. Of course if you happen to have the source code for either motiondev.c or even the actual application I would be very thankful! We are not trying to steal any profit from you, we are not planning to upgrade axis for free or anything releated. All we want is to improve the firmware and fix bugs and issues and add features where we missed them. If you don't like the code being open, I will not release it. All we need is a small executable that we can interface with with our custom user interface. Even sending G-Code to it would be enough.
Back to the story. A while later I managed to find a development kit for the CPU that was used. It was not really that cheap, costing me about 120€ including taxes and shipping. However it came with a broad selection of software that has since made my life a lot easier. Eventually, I was able to figure out, how to reprogram the controller, change the splash screen and swap out the kernel. For this, you will need a (micro) USB breakout or the USB-A side of a cut-off USB cable. First, we need to connect the pin on the white debug header inside the controller, marked GND to either the GND of the adapter or the black wire of the USB cable. Next, VCC of the USB breakout, or the red wire of the USB cable, need to be connected to the VBUS pin on the debug connector. Now, the data signals need to be connected. Here, UD+ from the connector needs to connect to D+ of the breakout or the green wire of the cable and UD- from the connector goes to D- or to the white wire of the cable.
This is how my setup looked like
Now, the pin header R91 needs to be bridged with a jumper or a cable and afterwards the USB cable is plugged into a computer running Windows XP or Windows 7. Then the controller is powered up. If everything went right, you should see the following device in your device manager
The device will disappear again after a few seconds and there is nothing you can do about it. If you monitor the UART on the same debug header, you will see that no USB connection could be established. However, I was able to connect to it using TurboWriter that was included with my copy of the development kit.
Unfortunately during my experimentation, I broke the internal USB port of my controller. It showed up once in the flash tool, but I wasn't able to take a screenshot at that moment. Doh!