In the last entry for the Timed LED Lighting Controller, I realised that there are no working examples of an I²C driver for the ATtiny20. I then had to work through the data sheet to implement my own. With that done, I could then start on the application firmware and get the board really working. So this is where my proof of concept becomes the prototype.
Since the last entry I have received a new version of the board that corrects the issues that I discovered in the first
- Regulator Pin-out
- 5V programming voltage
The new board also showcases a programmer connector I had discovered during my visit of the Nuremberg Embedded World.
Programming in 5V
I had discovered the hard way that the ATTiny20 is only programmable in 5V although is capable of operating at lower voltages. My intention was to run this device on 3.3V and I don’t want to change this so that this device can be compatible with the Raspberry Pi – the intended host. I needed to introduce 5V onto the board some how. I had considered ideas such as diodes to block out the 3.3V when connected, but ended for a simpler option of a jumper.
|To help out with the programming in this case (I only have one lab supply) I decided to put together a quick 5V supply that I could use. This turned out to be a small personal challenge to see how quickly I could get the design done and to OSH Park and assembled (The time taken by OSH Park does not count). Admittedly, the board is very simple, but still I was pleased not to have any bodging or re-spins for the board.|
The idea behind the jumper pints is so that when I need to program the device, I would switch the Jumper over to PRG mode and connect the 5V to the ISP pin header. On the new version of the board, this has worked very well. Since I actually did the development and testing of the firmware on the first revision of the board, I did not need to program the device more than a few times in the latest round of testing.
On the subject of programming, I encountered a connector I had not seen before. I had actually seen the connector footprint before but thought that was for some automated on-board programming system. What I am referring to is the In-Circuit Programming System from Tag-Connect. I was keen to try this out and was able to easily obtain a cable for my AVR ISP MkII. The version showed here is the “Legged” version and hence the larder mounting holes. There is a “No-Legs” version that does not require the four larger holes.
The saving comes from not having to solder (or purchase) pin headers or bulky ISP connectors. Essentially, this from of header does not cost anything since it is only a set of pads. However, for my uses, It will be a long while before I recoup the cost of the cable based on the volume of boards I do. But there is a factor of neatness that means I will be happy to continue to use this mechanism for In System Programming.
The Application Firmware
Once I had the I²C working, which was a huge milestone, I then had to consider the actual application. I was already at 65% of the flash. Since the device has a limited amount of flash (2K) and the behaviour is also fixed, I decided not to keep the I²C driver as a general module this time but to integrate the device registers into the driver as well. This meant I could implement pretty much all the features within now 90%. This is getting a little higher than I would like.
The features of the device are a set of registers to help to configure the behaviour and to read its status. By behaviour, basically on the receipt of a signal from a motion detector, a LED bank should light up for a pre-determined number of seconds. So I needed a way to enable/disable a “zone” and set the “on-time”. In the current implementation, I have a switch to set the LED bank on all the time for testing. This feature is also supported. In the design, I came up with the following set of registers. The full description of the registers can be found in the data-sheet.
Connecting to the Raspberry Pi
Connecting to the Raspberry PI was very straight forward and since I had all the testing already done with a USB-I2C device so I knew the infrastructure was there. I was able to use the i2cdetect, i2cget and i2cset commands to verify the behaviour. Basically, there is only one bus on the Raspberry Pi 3 that I am aware of. So the command to find my device was
i2cdetect -y 1
In the mean time, I had been working on a set of web pages using Django and BootStrap. This part of the project is still work in project but I now have a basic mechanism to communicate with the Timed LED Lighting controller via the website running on the Raspberry Pi.
Rather than go into the ins-and-outs of that part of the project, I have created a small video to demonstrate the progress to date.
The demonstration shows that the relay board has yet to be assembled properly. For that, I am waiting on the next revision that will have the correct size holes for the relays! Further work is needed on the web pages. There is one outstanding feature that may have a significant impact on the firmware… Since this is going back to a user interface, this may be an opportunity to implement some type of interrupt for from the device to the Raspberry Pi. There are other reasons for doing this other than just updating status of the lights. i.e. the configuration of the device as intruder detection – which was always on the list. Hardware wise, there are no real changes. I had broken out all spare GPIO pins to pin headers. The challenge is #1 knowing if I have enough capacity in the Flash to add the handling for the interrupt and #2 learning how to implement an interrupt on the Raspberry Pi.