It was all getting too awkward. A bit of short sighted design on my part had the Nokia LCD sharing an SPI port with the motor encoders. This meant that I had to turn off the encoders to write to the LCD. While no motion information would be lost by doing this, it effectively meant that I could not, for example, have the mouse hold position while updating the display. In the end I took it all apart and patched the circuit board so that the LCD is now driven from the SPI1 port and the encoders are on the SPI2 port.
It only needed two wires as the LCD needs just the SCK and SDO lines form the port. The SDO1 line is shared with the UART1 serial port TXD line. This should not cause any trouble since it is un;likely that I would want to talk to the LCD and the serial port simultaneously. In fact, I rarely use the serial port on the mouse for anything. It is used if ever I want to upload the map from the micromouse to a PC or if I want to dump serial data. In either case, it will not be much fuss (I think) to switch the port pin from SPI to UART.
If I had just thought this out a bit in advance, the dsPIC30F6015 has enough ports that I need not share any. Perhaps on the next mouse….
Soldering in the patches was not too bad. the SCK1 pin was unused and I managed to solder directly to it with a length of polyurethane insulated copper wire. I give thanks to the elm-chan site for showing that this was not only possible but can be raised to a high art. Conveniently, the lines in question went through vias giving an ideal connection point. On the other side, it was easy enough to patch onto the serial port TXD line.
//it effectively meant that I could not, for example, have the mouse hold position while updating the display.
Because they were both using the same SPI port and the LCD software was asynchronous with the control loop. Thus, every millisecond, the controller expects to be able to have unfettered access to the SPI port.
Access to the LCD was at a higher lever and I didn’t want to go to the trouble of writing a driver that would cooperate with the position controller.
I could have done it by doing block writes to the LCD in the control loop with an off-screen buffer but that would have used up more RAM than I wanted to.
Hmm, but all that is only if you want to read the LCD while the mouse is still moving.
What I think I will do is get the mouse to execute all the instructions first and then finally, when it comes to a stop, dump everything to the lcd. That might take up some RAM, but then again, it’s not practical to read the LCD while the mouse is in motion.
That is why I mentioned position holding in particular. Even so, it is useful to be able to update the display in motion. When testing I can have the mouse up on a stand, pretending to run the maze while I see continual readouts of speed, steering data, sensors readings….
Oh,yes. That should have occured to me.