Light at the end of the tunnel

I finished coding most of the main controller today.  Reducing the user interface to something more manageable really helped.



I reused code for a 4-bit LCD display interface from winavr.scienceprog.com/, which required only minor adjustments to retarget it to my system, but ended up taking half of an evening.  It was nicely modular code, with all the LCD commands implemented, and a 4-bit handshake, but I found a few bugs. 

1. The handshake was slow. _delay_ms(1) on every handshake edge  when _delay_us(1) would work.  Painting a 4x20 was going to take 1/3 of a second.  Now it should take more like 5ms to paint the whole screen.  
2. The code was not checking the busy flag nor allowing time for commands to complete.  I think the 1ms handshake delays were a kludge that happened to fix this.
3. The code was writing 8 bits to an AVR port, even though the code is written for driving a 4-bit LCD interface.  I'm using those other bits for other functions!
   

Never trust code you download.

For the Atmel Qtouch controller code, I had planned to "reuse" code from an Atmel app note.  The .pdf containing the code was copy protected, so I couldn't copy / paste the code, which covered 6 pages.  Too much to hand copy.  A note to Atmel support got me plain text in less than a day.

Once I really sat down to study the code, I realized it was a useful example of controlling a Qtouch interface, but it made no attempt to be a driver library. I had to create functions to implement all of the driver features I need.  I took some shortcuts so it isn't a reusable library, but it is a lot closer than what I started with.  The I2C code contained in the app note I was able to use nearly unchanged.  That's a big help, although there are other I2C libraries out there.  I hope I don't get burned by bugs in that code.  I don't relish debugging a I2C handshake.

The one major block I need to work on is the RF interface.  Atmel Smart RF devices use SPI, so I can use library code for the interface.  If I go with a complete radio, such as Zigbee, it will be UART library code.  Either way, coding shouldn't take too long.  Debug may be another matter.

Only eight days left.  Still lots to do.  A "day" is about 4 hours that I can steal from my sleep schedule.  My estimate is:

• Choose RF solution. 1/2 day
  
• Write interface to RF. 1 day
  
• Write sensor module code. This will be simple code, under 1 page. 1 day
  
• Get code compilable without errors. 2 days
  
• Analyze system power and cost. 1 day
• Package it up and send it in. 1/2 day

Which leaves me 1 day of slack in the schedule.  I'll take a look at my RF options tomorrow.