-
Upcoming Events
-
Feb6Mon
-
Apr14Sat
-
Tag Archives: nokia
Decimus hardware fix
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.
SPI data transfers
I use SPI on my micromouse both to talk to the Nokia graphical LCD and to talk to the LS7366 quadrature encoders. A large number of devices can be connected to the SPI data lines, MOSI and MISO. Each device needs its own select line. This all appear very simple and friendly. There is, however a potential problem due to the flexibility of the SPI configuration.
Aside from the device select line, three wires are used to transfer data between a a master and a slave. MOSI is the Master-Out-Slave-In line while MISO is the Master-In-Slave-Out. There is also a clock signal SCK. Data transfers occur simultaneously on the data lines and the clock edges are used to shift and latch the data at each device. Now rather than have a single standard for which clock edges do what, there are four possibilities:
Mode 0:
The clock is active high, data latched on the rising edge, data clocked out on the falling edge.
Mode 1:
The clock is active high, data latched on the falling edge, data clocked out on the rising edge.
Mode 2:
The clock is active low, data latched on the falling edge, data clocked out on the rising edge.
Mode 3:
The clock is active low, data latched on the rising edge, data clocked out on the falling edge.
Note that some microcontrollers may not be able to set up their SPI peripheral in all of these modes and may be limited to just one – probably Mode 0
Confused yet? So am I.
Let’s have a look at the data sheet for the LS7366. On the very first page it says
Received bytes are shifted in [latched] on MOSI with the leading edges (high transition) of SCK. Output data is shifted out on MISO with the trailing edges of the SCK clocks.
Figure 2 of the datasheet has a timing diagram and the statement that SCK is idle low. This then is operating in Mode 0.
In itself, this is not a big deal but if you have other devices using the same SPI port, it will be important to know if they also use Mode 0 or will require reconfiguration of the port for use with each device.
The Nokia display uses the same protocol as the PCD8544 chip on the Nokia 3310 displays. The data sheet for this says, at the beginning of section 8, ‘SDIN is sampled at the positive edge of SCLK’ . So far then, it could be either Mode 0 or Mode 3. Fortunately, Figure 12:
Makes it reasonably clear we are dealing with Mode 0 again. Note that the Nokia display only accepts data and cannot communicate back to the master device.
Having both devices use Mode 0 will make it all that bit easier to talk to them.
Find out more here:
Introduction to Serial Peripheral Interface [embedded.com]
SPI – Serial Peripheral Interface [mct.net]
LCD testing for Decimus
Having installed the LCD, it was time to get the code working for it. First I realised that it may not have been so clever to put the LCD on the same SPI port as the encoders. This will mean that I have to take care that the encoders are not being read when the LCD is active. Since the encoders are sampled every interrupt, it means turning them off while writing to the screen. That, in turn, means not writing to the screen while moving, or holding position. I may end up having to patch the board to put the LCD on the other SPI port. In fact, I wish I had done that in the first place as it would just share lines with the UART and I could easily switch between the UART and the SPI for writing debugging messages. Ah well, live and learn.Turns out I wired up the LCD module incorrectly and destroyed it. Fortunately I had several spares so I built up another. These things are cheaper than text displays so it is no great loss. Attaching wires to the LCD display is easier than you might think. As supplied, the Nokia 3410 LCD display comes as part of a replacement panel that looks like this:
Prise off the aluminium surround and the actual display element will come free. It is attached with a small amount of adhesive or double-sided tape. Sprung contacts serve to make the connection between the display and the phone main board. These too are attached with adhesive and can be removed to reveal a row of small pads to which you can solder wires. [See warning in comment below before removing this connector]. I used polyurethane coated copper wire from a Verowire pen (about 0.15mm diameter). The ends of the wires are stripped by simply heating with the soldering iron set to about 400 degrees Fahrenheit:
These wires are then taken to pin headers on a matrix board so that the entire assembly can be plugged into the mouse when needed. once the connections have been tested, the LCD is held onto the carrier with some double-sided foam adhesive pads.
It does not weigh much and could probably be left in place when running. The mouse looks a lot better with it off though. For now, a simple ‘hello’ is enough to show that it works.
LCD screen for Decimus
Probably the last part to be added to Decimus will be the Nokia 3410 LCD screen. Nearly all of my mice have these either permanently fitted or attached by a simple socket so they can be removed. With a resolution of 96×64 pixels, this screen is an ideal debugging aid. The display is relatively simple to drive if you have an SPI port available. The more commonly available 3310 screen has a lower resolution and cannot easily display a picture of the entire maze. With the 3410 model, it is possible to either show the maze or to have 8 lines of 16 characters of data displayed.
Because Decimus is the most compact micromouse I have yet built, the display sits on a couple of small riser boards, made from veroboard, to allow it to clear the motors and batteries. Not only is the graphical LCD smaller than the more common 16×2 text display, it is cheaper and lighter. With a bit of care, the display can replace many, if not all, the practical functions of a real-time debugger.
Adding a timer and the graphical LCD
This is a fairly big jump. With the LEDs and buttons tested, it is time to add the main graphical display, made from a Nokia cellphone display. Also, there is the main system timer event.
The simple user IO is working, and it is time to add a system timer. This will generate an interrupt every millisecond. In the final mouse a lot of work will be done in here – processing buttons, driving the LEDs, reading sensors and calculating drive signals for the motors.While that may seem a lot in a millisecond, the dsPIC used in primus can execute about 16,000 instructions in that tme and we should only need a small proportion of that time.Another function of the timer will be to maintain an internal clock so that the main program can time events and produce more reliable delays without holding up everything else. We shall continue to use the already present delay functions when it is acceptable for delays to be a bit rough, very short (less than 100us) or when the blocking behaviour is not going to cause any problems. The interrupts from the system clock will make the software delay functions run slow – possibly very slow so they can no longer be relied upon for anything but the simplest, non-demanding tasks.The system timer interrupts come from a 16 bit timer which will run continuously as long as the mouse is turned on. Since actually configuring the timer is pretty simple, this example will make use of the timer to debounce button presses, flash the LEDs and produce tones from the speaker. Trivial really.As with the other examples, the timer has its own source code module and header. Unlike the others, it is a relatively high-level module and must be able to call functions defined for the LEDs and buttons, and later for the sensors and motors.While we are at it, the nokia LCD is working. The test code should display a start up message followed by the Primus splash screen when you press a button. After that, pressing buttons will change the picture. This is just to show off the fact that it works. The LCD will become an essential tool in debugging and setting up so don’t leave it out.While the demo code displays pictures, these take up quite a bit of flash memory – about 760 bytes each – and they are not really needed. I like to put a splash screen up after a restart – just because I can. The images are a bit of a fiddle to create. I make a 2 colour image in PaintShop and save it as a RAW image file. A utility I have will read that file and convert it into the C definition you see in the source code.Remember that the display I have has 96×65 pixels. Try to get the right one if you are to avoid re-writing some of the driver code. Actually, the text stuff will work fine but you get shorter lines and fewer of them so take care.The complete project for MPLAB contains all the source code, the object files and som HTML documentation generated by Doxygen.Primus3.zip Continue reading
Add to Google