Bring Up and Testing
Phase 1: Load Arduino Bootloader
Nick Gammon's "Atmega Chip Programmer" was used to load the Arduino bootloader into the 2560 using an Arduino Uno. 5V power to the board came from the Uno.
Phase 2: Hardware bringup using onboard DC supplies
Upon attempting to power up with the board's 3.3V and 5V native supplies, it was discovered they would not turn on properly. Disabling the 3.3V regulator showed that the 5V would not even turn on standalone. It was guessed that the loading on the regulators at power-on prevented proper ramp up. A FET controlled by a 2 transistor timer that delayed connection of 5V to the 2560 by 50mS or so solved the 5V problem. Turn on of the 3.3V was changed from hardwired enable to software program control by tying the enable pin of the TI 2735 to the 2560 (a resistive divider was required for level matching). Once the Arduino is running, the 3.3V regulator is turned on.
Phase 3: USB Connection
With the board now able to power up, it was connected to a PC. The FT232RL was recognized, and the appropriate driver loaded. The blink example program included in the Arduino IDE was successfully downloaded.
Phase 4: LCD, Touchscreen and SDcard testing
The Arduino example programs from Henning Karlsen, modified to have the correct I/O pins of this custom board, were used to test the LCD, touchscreen, and SDcard. A simple SPI send routine was used in conjunction with an oscilloscope to verify that SPI signals were being properly sent, and level shifted to the RFM12B.
Phase 5: RF Testing
Once the above basic functions of the remote were debugged, the remote was paired with a Jeenode (info here) through RF links. A set of software libraries from the Open Energy Monitor project ("RFM_Simple_TX" and "RFM_Simple_RX") were used to verify data could be reliably transmitted and received. A software fix was needed - the internal pullup for the Arduino MISO line had not been set and random data was being "received". Having set the pullup, the RFM12B worked perfectly.
Phase 4: Remote Control Software Testing
To test the remote control software required that there be a preamplifier for it to pair with. A subset of the preamplifier Arduino program (in development in parallel) was used on a Jeenode to emulate the preamplifier. After several iterations of the screen bitmap in Photoshop (change pixel size, move a few pixels here and there, save as new .jpeg file, run through Henning Karlsen ImageConverter565, put on SDcard, test ... and then do it again) the configuration for all buttons and displays was completed. Final "touch zone" coordinates" were inserted into the program. And it looked like the job was done!
Phase 5: Fixing Intermittent Hang
One final fix was required, however. In normal operation, the remote would hang periodically. It was always during a screen refresh or screen draw.
Nick Gammon's "Atmega Chip Programmer" was used to load the Arduino bootloader into the 2560 using an Arduino Uno. 5V power to the board came from the Uno.
- First attempts failed - the level shifter buffer for the MISO line from the SDcard and RFM12B (a 74HC125 to be enabled by the 2560 when running the remote control program) was interfering with the bootloader's use of the MISO line.
- After removing power to that buffer, the bootloader still failed to load. Slowing the ISP transfer speed down by a factor of 128,and using a simple 6-jumper connection between the UNO and the remote control board worked, however.
- A 0 Ohm resistor connecting Vcc to the power pin of the 74HC125 has subsequently been designed into the board to allow burning of the bootloader, and then manually soldering the 0 Ohm resistor to provide Vcc to the buffer.
- Once the nuances of this custom board were accounted for, Nick Gammon's program made bootloader installation simple.
Phase 2: Hardware bringup using onboard DC supplies
Upon attempting to power up with the board's 3.3V and 5V native supplies, it was discovered they would not turn on properly. Disabling the 3.3V regulator showed that the 5V would not even turn on standalone. It was guessed that the loading on the regulators at power-on prevented proper ramp up. A FET controlled by a 2 transistor timer that delayed connection of 5V to the 2560 by 50mS or so solved the 5V problem. Turn on of the 3.3V was changed from hardwired enable to software program control by tying the enable pin of the TI 2735 to the 2560 (a resistive divider was required for level matching). Once the Arduino is running, the 3.3V regulator is turned on.
Phase 3: USB Connection
With the board now able to power up, it was connected to a PC. The FT232RL was recognized, and the appropriate driver loaded. The blink example program included in the Arduino IDE was successfully downloaded.
Phase 4: LCD, Touchscreen and SDcard testing
The Arduino example programs from Henning Karlsen, modified to have the correct I/O pins of this custom board, were used to test the LCD, touchscreen, and SDcard. A simple SPI send routine was used in conjunction with an oscilloscope to verify that SPI signals were being properly sent, and level shifted to the RFM12B.
Phase 5: RF Testing
Once the above basic functions of the remote were debugged, the remote was paired with a Jeenode (info here) through RF links. A set of software libraries from the Open Energy Monitor project ("RFM_Simple_TX" and "RFM_Simple_RX") were used to verify data could be reliably transmitted and received. A software fix was needed - the internal pullup for the Arduino MISO line had not been set and random data was being "received". Having set the pullup, the RFM12B worked perfectly.
Phase 4: Remote Control Software Testing
To test the remote control software required that there be a preamplifier for it to pair with. A subset of the preamplifier Arduino program (in development in parallel) was used on a Jeenode to emulate the preamplifier. After several iterations of the screen bitmap in Photoshop (change pixel size, move a few pixels here and there, save as new .jpeg file, run through Henning Karlsen ImageConverter565, put on SDcard, test ... and then do it again) the configuration for all buttons and displays was completed. Final "touch zone" coordinates" were inserted into the program. And it looked like the job was done!
Phase 5: Fixing Intermittent Hang
One final fix was required, however. In normal operation, the remote would hang periodically. It was always during a screen refresh or screen draw.
- One culprit was guessed to be a flaky power supply - when the SDcard (from which all bitmaps are loaded) is in use, it draws significant power. But some DMM and scope work proved this was not the cause.
- Another culprit considered was the SDcard communication speed. If the card read fails, the card will likely hang the program. The transfer speed from the card was set to "VERYHIGH" to maximize speed of screen refresh and it was hypothesized this was too fast. This also turned out to be a false path.
- The third suspected culprit was the problem - because the RFM12B uses public spectrum, there are other devices broadcasting on the same 433MHz wavelength. These external broadcasts were causing the RFM12B to trigger an interrupt that somehow hung the processor. By disabling interrupts before any screen drawing, and re-enabling them when bitmap load was complete, the problem was solved. This fix works because while the remote is drawing the screen, no new communications should be coming from the preamplifier so any interrupt can be ignored.