Text LCDs and the Raspberry Pi - continued
Over the weekend I spent some time on the LCD text display using the LiquidCrystalFast library. There's still work to do, but the core hardware is working. When I've finished the hardware and software I'll post the details but first I thought I'd document the mistakes I made and the processes I followed to troubleshoot the project and get it back on the rails.
My normal workflow for a new hardware design takes things in small steps, with lots of testing as I go. I start with a rough design, which may be on paper or in my head, and then I breadboard and test.
Once the breadboarded version is working I transfer the design to stripboard or to one of Adafruit's wonderful PermaProto boards, and test again.
If appropriate, I then design a board and send the files off to a PCB fab shop to make the first PCB version, which may need further testing and revision.
I've built a dozen or so Arduino clones on stripboard, and several LCD display drivers, so I thought it was safe to go straight to a stripboard layout. I decided to use my old Veroduino design as a template, and checked it against a couple of reference sources.
I didn't know it, but I was already in trouble. I forgot that I had made a mistake in the original layout of the Verduino which I fixed in version 2. I'd corrected the schematic but forgot about that too. I did the new layout by carefully copying the (incorrect) connections on the Version 1 board.
I spotted a few other slips I made as I prepared the stripboard but managed to repair them, and after an hour or two had the board ready for testing.
The next step was to insert an ATMega328 chip that I'd programmed with with a bootloader and check that I could download sketches from the Arduin IDE.
It didn't work.
I got an error message stating that the programmer was not responding, but that didn't tell me anything about what I'd done wrong.
Ouch!
I swapped the chip back to my new board and tried again. Sill no success.
I did a visual check of the soldering, and re-did my continuity test, but could not see anything. That left two possibilities: a gross error in the layout, or a mistake in the links to the FTDI header.
To distinguish between them I soldered in a 5 volt LED to see if the blink program was running as expected.
No joy.
By now it was clear that the chip was just not starting up; that meant a problem with the reset line, the power supply or the oscillator components. I looked and looked and could see nothing, so I decided to build a copy using a breadboard to verify that would work as expected.
I set up the breadboard design from the chip pinout diagram instead of blindly following the Veroduino layout. Within a couple of minutes I'd found the fault.
Version 1 of the Veroduino had AREF (pin 19) wrongly connected to the positive supply, along with a hard-to-see but correct link to pin 20. I spotted the connection to Pin 19, but not the link to pin 20, and assumed that the Vcc pin on that side of the chip was pin 19.
I rewired the power lines on the stripboard, and applied power. The LED blinked as expected. Progress!
Next I tried to download the LiquidCrystalFast sketch which I'd modified to match the pin assignments used in my layout.
Back to the board layout. I'd felt a bit uneasy about the connections to the FTDI chip. These link the serial port on the computer running the IDE to the serial pins (TX/RX) on the Arduino chip, so that the bootloader can work its magic. After a little checking I realised that I'd made a silly mistake, connecting the pin called RXD on the FTDI cable to the RX pin on the chip.
That's wrong: RXD should be connected to TX, and TXD should be connected to RX. It's confusing, but it makes sense if you think about it; the Receive pin on the FTDI cable is receiving data from the point of view of the computer it's connected to, and the pin it should be connected to is the one that is transmitting from the point of view of the chip.
To put it another way: your computer receives what the Arduino transmits, and the Arduino receives what your computer transmits.
Once I'd swapped over the RX and TX connections the Arduino IDE reported that it had downloaded my sketch successfully.
Time to plug in the LCD.
Nothing happened!
Inserting the LCD was somehow causing the chip to malfunction.
I inspected the soldering around the part of the board that supplies power to the LCD and found a hairline bridge of solder between the 5v supply and ground.
When I removed the solder bridge with a craft knife the LCD worked perfectly; it's run correctly for about a day, and I'm happy that the board is correct.
I need to catch up with some admin over the next few days, but I'll publish the board design and code once I've had a chance to add the I2C connector and finish the controller code.
My normal workflow for a new hardware design takes things in small steps, with lots of testing as I go. I start with a rough design, which may be on paper or in my head, and then I breadboard and test.
Once the breadboarded version is working I transfer the design to stripboard or to one of Adafruit's wonderful PermaProto boards, and test again.
If appropriate, I then design a board and send the files off to a PCB fab shop to make the first PCB version, which may need further testing and revision.
My First Mistake
This time I took a short cut.I've built a dozen or so Arduino clones on stripboard, and several LCD display drivers, so I thought it was safe to go straight to a stripboard layout. I decided to use my old Veroduino design as a template, and checked it against a couple of reference sources.
I didn't know it, but I was already in trouble. I forgot that I had made a mistake in the original layout of the Verduino which I fixed in version 2. I'd corrected the schematic but forgot about that too. I did the new layout by carefully copying the (incorrect) connections on the Version 1 board.
I spotted a few other slips I made as I prepared the stripboard but managed to repair them, and after an hour or two had the board ready for testing.
Fist signs of trouble
I always start with a crude continuity check using a voltmeter. I made sure that I hadn't shorted out adjacent pins on the IC sockets and that the ground and Vcc connections were as I thought they should be.The next step was to insert an ATMega328 chip that I'd programmed with with a bootloader and check that I could download sketches from the Arduin IDE.
It didn't work.
I got an error message stating that the programmer was not responding, but that didn't tell me anything about what I'd done wrong.
Ouch!
Debugging the board
I checked to see that the chip had a working bootloader by swapping it into the original Veroduino Mk 1. The IDE recognised the chip and I uploaded the basic blink program, which worked fine on the Veroduino version. So that told me that the chip was undamaged and had a valid bootloader.I swapped the chip back to my new board and tried again. Sill no success.
I did a visual check of the soldering, and re-did my continuity test, but could not see anything. That left two possibilities: a gross error in the layout, or a mistake in the links to the FTDI header.
To distinguish between them I soldered in a 5 volt LED to see if the blink program was running as expected.
No joy.
By now it was clear that the chip was just not starting up; that meant a problem with the reset line, the power supply or the oscillator components. I looked and looked and could see nothing, so I decided to build a copy using a breadboard to verify that would work as expected.
I set up the breadboard design from the chip pinout diagram instead of blindly following the Veroduino layout. Within a couple of minutes I'd found the fault.
Version 1 of the Veroduino had AREF (pin 19) wrongly connected to the positive supply, along with a hard-to-see but correct link to pin 20. I spotted the connection to Pin 19, but not the link to pin 20, and assumed that the Vcc pin on that side of the chip was pin 19.
Progess...
I rewired the power lines on the stripboard, and applied power. The LED blinked as expected. Progress!
Next I tried to download the LiquidCrystalFast sketch which I'd modified to match the pin assignments used in my layout.
...and another problem
Once again I got an error.Back to the board layout. I'd felt a bit uneasy about the connections to the FTDI chip. These link the serial port on the computer running the IDE to the serial pins (TX/RX) on the Arduino chip, so that the bootloader can work its magic. After a little checking I realised that I'd made a silly mistake, connecting the pin called RXD on the FTDI cable to the RX pin on the chip.
That's wrong: RXD should be connected to TX, and TXD should be connected to RX. It's confusing, but it makes sense if you think about it; the Receive pin on the FTDI cable is receiving data from the point of view of the computer it's connected to, and the pin it should be connected to is the one that is transmitting from the point of view of the chip.
To put it another way: your computer receives what the Arduino transmits, and the Arduino receives what your computer transmits.
Once I'd swapped over the RX and TX connections the Arduino IDE reported that it had downloaded my sketch successfully.
Time to plug in the LCD.
Nothing happened!
The final hurdle
I removed the LCD, downloaded the blink sketch, inserted the LCD and restored power. The LED didn't blink.Inserting the LCD was somehow causing the chip to malfunction.
I inspected the soldering around the part of the board that supplies power to the LCD and found a hairline bridge of solder between the 5v supply and ground.
When I removed the solder bridge with a craft knife the LCD worked perfectly; it's run correctly for about a day, and I'm happy that the board is correct.
Lessons learnt
- Even old hands still make beginner's mistakes sometimes.
- It's a good idea to try circuits out on a breadboard even if you feel sure you know how they should work
- If possible, start with a simple working version, adding one new feature at a time.
- If you've made a defective version of a design, throw it away or label is as defective!
I need to catch up with some admin over the next few days, but I'll publish the board design and code once I've had a chance to add the I2C connector and finish the controller code.
Comments
Post a Comment