Tag Archive: ATMEGA32U4

So the adventures with my Teensy 2.0 continue. I wasn’t really pleased with the DS18B20 library I found. Too simple, no support for multiple sensors, and it just didn’t work when the CPU was clocked at 16 MHz. Therefore I went to look for other libraries. I’ve found a library that seems more complete. Support for multiple sensors, reading their serial numbers, determining how they are powered, etc. The complete list. It can be found here.

As expected, the specific ATMEGA32U4 I have, was not supported out of the box. This Teensy 2.0, is it using such a rare chip no projects I encounter have support for it. So, again, the issue was the UART. I tried modding the defines in the UART library in their example project, but I gave up on that route, and decide to add the UART library I already got working to the project, and compensate for the API differences. Which resulted in a project running, capable of reading out multiple sensors connected. Tres bien. If I only knew where I put the waterproof sensor after moving… but for now, I can do experiments with the TO-92 versions.

Next thing to look at is some Real Time Clock. I’ve got two of those laying around, a PCF8563 and a DS1307. Looking at the capabilities, the PCF8563 also has timers and alarms, which could be rather useful in this setting: making measurements at regular intervals, preferably aligned with the clock time. The DS1307, it’s good if you just need to know the time. Back when I ordered them, that was the idea, to add an RTC to a Raspberry Pi. I bought two different models to evaluate them and see the differences. These RTCs have been laying around for years, and the batteries are completely depleted (0,4 Volt remaining in a 3,0 Volt battery) . Perhaps I should replace them. But for now, let’s see if we can communicate with the PCF8563.

I’ve found a library here and it seems to work as-is. No changed needed, it just works. At least, as far as reading the current time, which, the RTC thinks is 1900, due the empty battery.

Okay, so, we can have the PCF8563 generate a signal on the interrupt pin. How to handle that on the ATMEGA32U4. It seems, it has four interrupt pins, but those are in use by the UART and I²C bus. The ATMEGA32U4 also has “pin change interrupts”, which are all mapped to pins on Port B. The interrupt pin from the PCF8563 required a pull up resistor. I am using the internal pull up resistor in the ATMEGA32U4.

ISR (PCINT0_vect){
   // When PIN 7 on Port B is low
   if (!(PINB & 1<<7)) {
        uint8_t flags = PCF_GetAndClearFlags();

void setup_pb7_int(){
        DDRB &= ~(1  << PB7); /* Set PB7 as input */
        PORTB |= (1 << PB7); /* Activate PULL UP resistor */
        PCMSK0 |= (1 << PCINT7); /* Enable PCINT0 */
        PCICR |= (1 << PCIE0); /* Activate interrupt on enabled PCINT7-0 */
        sei (); /* Enables interrupt */

Quite a while ago, I believe it was back in January 2013, I ordered some Teensy microcontrollers. I ordered a Teensy 2.0, a Teensy++ 2.0 and a Teensy 3.0. Now, three and a half year, I finally started to play around with them. Yesterday I started with the Teensy 2.0. This is an Atmel ATMEGA32U4 micro controller.

The project, an idea that is almost as old as my microcontrollers, is basically a temperature logger. Log the temperature measured using a DS18B20 to an SD card. However, that’s the final goal. My first idea was to interface with an LCD screen. I’ve got a model 128×64 pixels, which appears to be ST7920 based. These can be addressed in parallel or serial mode.

IMG_20160716_171341I’ve found a library to control LCD displays on microcontrollers: u8glib. This library has support for many LCD displays. So it would make switching to a different type of display as simple as changing one line of code, and everything works again.

However…. I didn’t get this thing to work. Basically, what I am trying to do is to compile the ATMEGA “Hello World” example. I have changed the Makefile to reflect that I am using an ATMEGA32U4, and added the initialisation code for a 128×64 pixel ST7920. However, nothing appeared on my screen.

I have tried to address both parallel and serial mode. Note that my display was hard wired to parallel mode using a solder bridge. Well, that’s easily fixed, but still nothing appears on the screen. There is a pot meter on the back to set the contrast, but spinning that thing around doesn’t help either.

Well… the purpose was getting some output. Next thing, the UART. I googled around and found a simple uart with avr libc. However, after adjusting the Makefile to reflect I am using an ATMEGA32U4, the thing doesn’t compile. It seems, the ATMEGA32U4 only has an UART1 and no UART0. After changing the numbers, the code compiles just fine.

Now, trying the make upload fails. It turns out, the Teensy uses a bootloader not supported by avrdude. The Teensy comes preprogrammed with the HalfKay bootloader. The code is closed and proprietary. (Some info about bootloaders) For now, I use the flashing tool supplied by PJRC. A precompiled binary, which required me to install an old version of libpng.

Nevertheless, I can upload the compiled hex file to the microcontroller, and attach an USB TTL serial device. But at his point, all I got was mojibake. At least something shows up. IMG_20160717_005547Well…. mojibake on a serial connection usually means the incorrect bitrate has been used. After tweaking around in the code, I got readable output when loading the program from the bootloader, but when I powercycled, the output was mojibake again.

What’s going on? I made incorrect assumptions on the CPU speed of this device. As the device specs say 16 MHz, I assumed it was running at 16 MHz. However, it turns out, the device is configured to boot at 2 MHz. This solved a lot of mysteries. This also made me check the LCD code, but the hello world example did configure the clock speed so it wouldn’t have suffered from incorrect timing due this fact.

So, after having established serial communication, the DS18B20 sensor is to be added. Please be carefull when wiring it up. The middle pin is the data pin, for sure, but the outer pins, when looking at the datasheet, it has bottom view, so it’s quite easy to make the mistake to swap them around. The thing gets HOT when you swap them, but it seems, the part survived it. A library to communicate with this sensor can be found here. I changed the connection setup in the header file and compiled the code. At first, I could only get a readout of a constant -0.063. In one of the comments someone mentioned clocking down to 1 MHz solves the problem, and indeed it does. So, this looks like some sort of timing bug. I suppose I don’t need 16 MHz for this project anyways, so, for the time being, let it run at 1 MHz. There are other modifications I would like to make to this library as well, such as support for multiple sensors on the bus.

IMG_20160717_005552Next thing, adding an SD card. Now, one thing to keep in mind. SD cards require 3.3 Volt I/O. The Teensy 2.0 comes with a default configuration of 5 Volt. (The microcontroller can run at 3.3 Volt, but is speed limited to 8 MHz in that case). So, for the purpose of interfacing with an SD card, I use a level shifter. At this moment I don’t have a 3.3 Volt regulator I can solder to my board. Furthermore, I intend to interface with that LCD display I mentioned before, which requires 5 Volt I/O. Either way I would require such a level shifter.

So, looking around for SD support on ATMEL microcontrollers, by first hit was SdFat. However, this required the Arduino libraries and is written in C++. I don’t intent to use C++ on a microcontroller. On a microcontroller I want plain flat C. On a microcontroller speed and size are limited, so I wouldn’t want to write C++ code for a microcontroller. So, the search continues, and gives me sd-reader. This implementation looks better suited for my purposes. However, it has no support for the specific microcontroller I have. First of all, the mentioned UART1 in stead of UART0, and probably some other register changes. There is a patch available against an old version of this code. I suppose I should analyse the changes and apply them to the latest code. However, with the patch, the example code runs and is able to read and write to my SD card.