Posts Tagged ‘atmel’
I become interested in Nixie tubes after I bought a Netduino and tried out the ArduiNIX. From that I decided to make my own Nixie Tube clock. My clock, besides showing the time, also shows the date, year, temperature, has an alarm, and can communicate with a PC via USART.
The clock is built on two PCB boards connected by two 10 pin IDC cables. I use stand-offs to screw the two boards together, doing that makes the clock free standing and eliminates the need to build a separate case or stand. I would have done it on one giant board but that was not feasible due to size limitations in Eagle freeware. The boards were manufactured through OSHPark.
I use four IN-17 Nixe tubes for the display. Although they are small, IN-17 tubes are cheap and easy to source through Ebay. Also I had several left over from my ArduiNIX experiment.
The tubes are multiplexed through 2 SN74141 BCD to decimal drivers. I built a version with one driver per tube but that seemed wasteful which is why I decided to multiplex them. I also tried a version where I drove the tubes with individual transistors but the switching was slow resulting in much ghosting.
The SN74141 drivers interface to the microcontroller through TLP-627 optoisolators. I chose an optoisolator to isolate the microcontroller from the tube high voltage. In theory it is cheaper to replace a $1.30 optoisolator than a $8 micro. In my case the optoisolator did not isolate enough and I ended up ruining a MCU in a high voltage probing accident.
The microcontroller is an ATMega32. It is run at 8MHz with the JTAG fuse bit disabled. I originally selected the ATMega32 because it has enough pins to drive four SN74141 tubes and perform serial I/O. In hindsight, for the two drivers I ended up with, I could have gone to a lower pin-count MCU like the ATMega328 and saved some board space. The code only uses 10% of the available 32KB of flash. It is nice to not have to worry about IOs or having to optimize the code to eke out every iota of performance and it leaves room for expansion.
The power-supply is based on the one in the ArduiNIX that I write about here.
The time, date, alarm, and temperature come from the DS3231 RTC chip on my RTC breakout board documented here. I wired up a buzzer for the alarm but I didn’t read the datasheet correctly and wired one of its pins to the input voltage. This leads to a high DC voltage across the buzzer which the datasheet warns again. I’ve fixed this in the Eagle files so it will work when order another set of boards.
The user interface is through three push-buttons on the Nixie tube board. One button is used to switch between the modes and the other two are used to increment the left and right sides.
In addition, I brought out the TX and RX pins for serial communication. I used Dean Camera’s Interrupt Driven USART guide to get the interface up and running but I haven’t done much with it since. It would be interesting to show stock prices and other numerical data from the internet on the display. There are three LEDs available for debug, alarm, and to show seconds.
The code is based around an overflow interrupt on Timer0. The interrupt calls the RTC to get the current time. From that the input pushbuttons, the alarm, and LEDs are toggled once per second.
The display() function drives the digits and uses a state machine to multiplex between them. This avoids wasting cycles in a delay loop to implement a delay between switching displays to avoid ghosting.
UpdateLeftRight() updates the variables that hold the values to write to the tubes with the correct value based on the selected mode. update_time() updates the time, date, day, and alarm based on the mode and which increment button the user is pushing. The RTC data is read through the GetTimeDateAlarmDataFromRTC() function.
I didn’t wire the outputs of the SN74141 to the correct leads on the nixie tubes, Instead I wired them based on ease of routing. remap() remaps the input to the driver to the correct value that should be written to the driver.
In addition, I have ‘anti_flashy‘ code to toggle the digits once per second through all their values per minute. This is done to avoid cathode poisoning that will eventually dim the tubes and also as a way to count the first 9 seconds of each minute. It is a nice effect. And since I don’t have the buzzer wired up, I toggle the debug LED on pin D6 when the time hour and minutes match the alarm.
Things I Learned
Be careful with the high voltage output. I’ve shocked myself a few times by touching the board accidentally in a high voltage area.
Don’t probe around the board with wires hooked up to 170V. I had a case where one of my tubes were not working and I tried powering them directly using very sloppy techniques. Something shorted out and I ended up damaging the neighboring tube, shorting the optoisolator, and burning out the microcontroller!
Use IC sockets as much as possible. Using a socket meant I could quickly replace a burnt out ATMega without having to rebuild a whole board. Not using a socket for my tubes meant I had to re-do the entire display board when I fried one of the tubes.
Read the datasheets and then read them one more time. Not reading the buzzer datasheet and just going off information from the internet meant that I wasn’t able to use the buzzer in my project.
Check your header directions and orientations of the components. Print out a paper copy of your board, place your components on them, and check the pin orientation. I put the tubes on the back of the board in one iteration of the design which meant that I had to re-do the board.
Always have a current limiting resistor in place. Testing my tubes with high vcc and no limiting resistor resulted in them flickering and glowing when off.
There is some optimization possible on the board and in the software.
For the hardware, I’ve added a switch to the board to turn off the clock at the input supply for when I’m away and of course fixed the buzzer. There are enough I/O pins open to drive a LCD display to show additional information. This with the serial I/O can give us a nice PC connected display. The MCU is only running at 8MHz but can be clocked at up to 16MHz so there are plenty of spare cycles available.
The timings for reading the RTC and driving the display can be optimized further. Initially I used delays to wait between turning off a tube and turning on its neighbor – you can see this in the commented out code in the display() function. I later took out the delays but did not check to see if I can read the RTC or multiplex the tubes less often. This will save power and free up cycles for additional features and effects.
Additional effects are possible with the tubes. Things like flickering, scrolling, fading in, fading out e.t.c
For the original inspiration and for sharing their designs:
For inspiration and samples of code for driving the DS3231 RTC chip:
All code and files are released as ‘Do what you want with it. I am not responsible for anything that happens.’
CPU board schematic:
Tube board schematic:
Adafruit sells a really nice 16×2 OLED display and they even have an Arduino library for it. However I only have a Atmega32 and Arduino does not run on the Atmega32. Rather than spending $20 or so for an Arduino, I decided to port their library to AVR. It wasn’t too difficult since Arduino is just AVR C++ behind the scenes.
Re-writing the Adafruit library was straightforward. I hardcoded PORTA as the I/O port but some additional code could make that generic. I had to re-write the digitalRead and digitalWrite functions to read and write out of PORTA instead of the Arduino pins. The delayMicroseconds command is replaced by the AVR _delay_ms() macro.
The trickiest part was figuring out how to implement the print function. After some digging around I found it in the Arduino code at \hardware\arduino\cores\arduino\Print.cpp. The print function calls a write function that iterates through the character string which then calls our native OLED write on each character. This seems seems a little roundabout but I guess that is how they chose to implement it.
My No-Arduino code:
Adafruit Arduino library:
While working on a ATtiny13 development board I noticed that my board only worked when the PB5 pin was high.
If you have a non-functional or erratic ATtiny13 or similar Atmel MCU that shares RESET with a IO pin, try setting the IO pin that is shared with RESET to a logic high. It is possible that the RESET pin is being pulled low and this is keeping your code from running. This happens because instead of allowing for a software switch, Atmel uses the RSTDISBL fuse to control the switching between RESET and IO pin use.
One caveat in setting the RSTDISBL fuse is that the AVR can no longer be programmed via ISP mode, the fuse can only be reset with a high voltage programmer. I don’t understand why Atmel chose to do this, Atmel should have allowed users to toggle the RESET pin via software – maybe they wanted to give a large customer
the ability to lock out the ability to reprogram the microcontroller!
It has been a while since I worked on the Atmel AVR line of microcontrollers. Things have changed since I last played around with them. I did some digging to figure out how to start up again so here is a quick guide for those that are looking.
Pick a Atmel AVR MCU that fits your requirements. I’m doing a simple project so I picked the ATtiny26.
Buy, beg, borrow, or steal a AVR ISP a.k.a as the AVR In-System Programmer. There are schematics for home made programmers out there, I’ve had problems with bad solder joints and messed up connections with home made programmers so I avoid them. Debugging is hard enough, a bad programmer is a problem you really don’t want to debug.
Wire up your AVR processor to the AVR ISP using the documentation provided with the ISP. It is a matter of wiring up the MISO, MOSI, SCK, Reset, Vcc, and Ground pins and should take only a few minutes on a breadboard.
Now, on to the software. Download and install WinAVR. WinAVR is a set of utilities that includes a port of GCC to the AVR family, AVR-GCC, and several helpful Unix utilities.
The last step is to to download and install AVR Studio 4. Get the latest version. AVR Studio 4 has been updated to integrate with AVR GCC, you type your code in using C. It generates the makefile needed to compile your code with AVR GCC and, if you are using the AVR ISP, will let you upload your code directly to your microcontroller.
To get started, start up AVR Studio and select ‘New Project.’ Select ‘AVR GCC’ as the project type and click Next.
Then, select your microcontroller and the debug platform.
The debugger is pretty cool, besides stepping through the code, you can also view register states and modify variables on the fly.