OWOWOD – One Wire / One Way Output for Debugging the Tinusaur (Part 1)

I always wanted to be able to write something like this in my code

 debugging_print("working, x=%i", x); 

… have that running on the micro-controller and see the debugging output on my computer.

The Problem

Unfortunately that is not easy – in fact not possible with the standard tools used to work with the ATtiny85. The problem is this: (1) those micro-controllers have too few I/O ports; and (2) most of the programmers (the one I’m using is USBasp) do not offer that kind of communication between the micro-controller and the computer, i.e. there is no 2-way communication.

There are many solutions to that problem and while looking on Internet I found this article http://www.ernstc.dk/arduino/tinycom.html that points to some of them:

Since the purpose of The Tinusaur Project is learning I decided to write my own.

USB to Serial TTL
USB to Serial TTL Converter

To do that I needed:

The USB-to-Serial TTL is a device that when connected to the USB port of the computer will look to the operating system like a Serial COM Port. Writing data to that COM port will result in transferring that data through the converter and out to the output pin called TxD – in serial form. It work similarly when receiving data from an external source of signal connected to the RxD pin.

I connected the PB0 of the ATtiny85 to the RxD of the USB-to-Serial TTL and did some experiments. Soon I realized that the timing of the signals was critical for this to work and I needed better way to compose the serial data.

Reference Character Generator

First thing – a serial data character generator that I can use as reference – and what could be better than an original USB-to-Serial converter.

I also needed a software that will generate sequence of test characters that I would use as a test signal. First I though of writing a simple Java program that will send the data to the COM port but then I found an application on Internet that does that already – COMStressTest from AGG Software at http://www.aggsoft.com/com-port-stress-test.htm.

COM Stress Test

I specified my testing data in the “Data source” tab as an external file.

The best testing sequence in this case would be string of “U” characters. This is because the generated signal will consist of equal LOW and HI intervals known also as square wave signal.

 ASCII "U" = 0x55 = 01010101 

To look more precisely at the signal form and parameters I used an oscilloscope – mine is DSO Quad from Seeedstudio at http://www.seeedstudio.com/depot/DSO-Quad-4-Channel-Digital-Storage-Oscilloscope-p-736.html.

The signal should look like this …

Oscilloscope Serial Signal

That’s all for now.

The next step will be to write some code for the ATtiny that will generate the same sequence – all “U” character and try to make it exactly the same as the reference one.

IMPORTANT: All the tests were done with the default settings for the serial COM port which are 9600 bps, 8 bits of data, no parity check and 1 stop bit. This is sometimes denoted as 9600 / 8-N-1 configuration.

NEXT PART: OWOWOD – One Wire / One Way Output for Debugging the Tinusaur (Part 2)

 

All the OWOWOD source code is available at https://bitbucket.org/tinusaur/owowod/src.

 

The Tinusaur Plays Conway’s Game of Life

MAX7219 LED 8x8 ATtiny Tinusaur Conway’s Game of Life

I was playing with the MAX7219LED8x8 library and writing some code for how to use a simple scheduler to automate the task of outputting the buffer to the LED 8×8 matrix. So I was thinking … may be writing a simple game will illustrate the use of those libraries very well. Because just few days earlier I was looking at some Arduino projects implementing the Conway’s Game of Life I decided to write it for ATtiny85 and MAX7219/LED 8×8.

The Game of Life is a classical computer game and a cellular automaton created by the British mathematician John Horton Conway in 1970. This is a zero-player game which means that once it starts no input from user is required to play the game’s turns – it goes by itself.

Its simple rules (outlined below) allow to be implemented on very simple microprocessor systems and Tinusaur (and ATtiny systems in general) could be perfect platform for that.

Hardware

One Tinusaur Board connected to LED matrix 8×8 controlled by MAX7219.

Drivers

The MAX7219Led8x8 library is used to output the pixels to the LED 8×8 matrix.

MAX7219 LED 8x8 Conway’s Game of LifeThe Rules

The universe of the Game of Life is an infinite two-dimensional orthogonal grid of square cells, each of which is in one of two possible states, alive or dead. Every cell interacts with its eight neighbours, which are the cells that are horizontally, vertically, or diagonally adjacent. At each step in time, the following transitions occur:

  1. Any live cell with fewer than two live neighbours dies, as if caused by under-population.
  2. Any live cell with two or three live neighbours lives on to the next generation.
  3. Any live cell with more than three live neighbours dies, as if by overcrowding.
  4. Any dead cell with exactly three live neighbours becomes a live cell, as if by reproduction.

The initial pattern constitutes the seed of the system. The first generation is created by applying the above rules simultaneously to every cell in the seed—births and deaths occur simultaneously, and the discrete moment at which this happens is sometimes called atick (in other words, each generation is a pure function of the preceding one). The rules continue to be applied repeatedly to create further generations.

(ref: Wikipedia/Conway’s_Game_of_Life)

The Program

The board is defined as a short byte array:

typedef uint8_t life_board[8];

An initial board is specified by the bits in that array:

life_board life_oscillators_blinkers = {
    0b00000000,
    0b00000000,
    0b01110000,
    0b00000000,
    0b00000100,
    0b00000100,
    0b00000100,
    0b00000000
};

Here are the most important functions that are implemented:

void life_board_init(life_board buffer);
void life_board_out(void);
uint8_t life_cell_count(uint8_t cx, uint8_t cy);
void life_board_turn(void);
void life_board2_copy(void);

The life_board_init function initializes the board with preset values and life_board_out outputs the content of the boards to the LED 8×8 matrix.

The life_cell_count function counts how many neighbors the specified cell has.

The life_board_turn performs one turn of the game based on the rules described above. It reads the data from the main buffer life_board_buffer array and stores the result in the life_board_buffer2 array. After that life_board2_copy copies the new data to the main buffer which then is outputted to the LED 8×8 matrix.

Here is the source code of the most important function – life_board_turn:

void life_board_turn(void) {
    for (uint8_t y = 0; y <= 7; y++) {
        for (uint8_t x = 0; x <= 7; x++) {
            uint8_t count = life_cell_count(x, y);
            if (LIFE_CELL_ISSET(x, y)) {
                if (count < 2)
                    LIFE_CELL_CLR(x, y);
                else if (count == 2 || count == 3)
                    LIFE_CELL_SET(x, y);
                else if (count > 3)
                    LIFE_CELL_CLR(x, y);
            } else {
                if (count == 3)
                    LIFE_CELL_SET(x, y);
                else
                    LIFE_CELL_CLR(x, y);
            }
        }
    }
}

This function implements the rules of the Game of Life.

That’s it.

In the program there is some more code that shows about 10 well know and interesting shapes such as blinker, toad, beacon, glider, etc.

The source code is part of the MAX7219LED8x8 library and it is available at https://bitbucket.org/tinusaur/max7219led8x8.

 

 

This article was permanently put at Conway’s Game of Life page.

UPDATE: MAX7219LED8x8 uses simple scheduler

max7219 LED 8x8 Tinusaur ATtiny85

The MAX7219LED8x8 library uses now simple scheduler to automate the task of outputting the buffer to the LED 8×8 matrix. This is not like a real task scheduler (in a real operating system) but it uses the ATtiny85 microcontroller‘s timer and its interrupt to do certain things on regular intervals.

So this is how I’ve got the idea …

While I was working on some code that uses the MAX7219LED8x8 library I figured out that the task of writing the content of the memory buffer to the MAX7219 could be automated by hooking some code to the ATtiny85 timer.

The modification and additions could be broken down into 2 parts:

First, the scheduling part that initializes the ATtiny85 timer, starts it and handles the hardware interrupt.

Second, the MAX7219LED8x8 library functions for setting/clearing pixels and outputting the buffer that now should work with the scheduler.

There are only 3 functions to handle the scheduling:

void scheduler_init(void);
void scheduler_start(uint8_t max);
void scheduler_userfunc(void);

The scheduler_init function initializes the timer and the scheduler_start starts the timer task to be executed on equal interval defined by the max parameter.

The scheduler_userfunc function should be implemented in the application so it could be called on regular intervals.

There is not “stop” function at the moment since it was not needed in this particular case.

The code for initializing and starting the ATtiny85 timer is very simple:

void scheduler_init(void) {
    // Setup Timer
    TCCR0A |= (1 << WGM01); // set timer in CTC mode
    TIMSK |= (1 << OCIE0A); // set Bit 4 – OCIE0A:
    // ... Timer/Counter0 Output Compare Match A Interrupt Enable
}

void scheduler_start(uint8_t max) {
    // IMPORTANT: Requires TIMER0_COMPA_vect to be setup.
    sei(); //  Enable global interrupts
    OCR0A = max;    // set value for OCR0A - Output Compare Register A
    // Prescale and start timer: 1/1024-th
    TCCR0B |= (1 << CS02) | (0 << CS01) | (1 << CS00);
}

// Define interrupt vector
ISR(TIMER0_COMPA_vect)
{
    scheduler_userfunc();
    // Note: No need to clear flags in TIFR - done automatically
}

On the MAX7219LED8x8 side there are only 3 functions currently implemented:

void max7219s_init(void);
void max7219s_start(void);
void max7219s_buffer_out(void);

The max7219s_buffer_out function is the one called within the scheduler_userfunc timer handler.

Everything else remains the same – we use MAX7219_buffer_set(x, y) to set pixel and MAX7219_buffer_clr(x, y) to clear pixel.

What could be improved and optimized: output the buffer only when it is changed.

More information is available at the MAX7219LED8x8 library page.

The source code of the MAX7219LED8x8 library, the scheduler and everything else is available at https://bitbucket.org/tinusaur/max7219led8x8.

 

MAX7219 driver for LED Matrix 8×8

MAX7219LED8x8 is a C library for working with the MAX7219 display driver to control 8×8 LED matrix. It is intended to be used with the Tinusaur board but should also work with any other board based on Atmel ATtiny85 or similar microcontroller.

MAX7219 with LED matrix 8x8

 

The MAX7219 is manufactured by Maxim Integrated is compact, serial input display driver that could interface microcontrollers to 64 individual LEDs such as 8×8 LED matrix. Only one external resistor is required to set the segment current for all LEDs.

MAX7219 Timing Diagram

To put that in simpler words – with the MAX7219 driver it is possible to control 8×8 LED matrix using just 2 wires serial interface – one for the sync clock and one for the data. There is another wire that could be used to enable/disable the communication with the chip. The maximum frequency for the serial interface is 10MHz.

The LED matrix 8×8 is connected almost diretcly to the MAX7219 driver – only few external components are required.

Working with MAX7219 is very simple – turning on and off individual LEDs is done by sending 2-bytes command to the driver containing the row and the byte which bits define which LED value to set.

There are also few other command that are needed during the initialization process.

The library supports short buffer – only 8 bytes in size – to keep the values before sending them to the driver.

MAX7219LED8x8 is written in plain C and does not require any additional libraries to function except those that come with the WinAVR SDK.

Using it is very simple …

    MAX7219_init();
    MAX7219_buffer_set(2, 3); // Set pixel
    MAX7219_buffer_clr(4, 5); // Clear pixel
    MAX7219_buffer_out(); // Output the buffer

Please continue to MAX7219LED8x8 page to see full source code the rest of the article.

External Resources

The source code of the MAX7219LED8x8 library is available at https://bitbucket.org/tinusaur/max7219led8x8

MAX7219 specification and datasheet:

 

TinuDHT – ATtiny Library for DHT11

Ever wanted to do a project with that cheap DHT11 temperature/humidity sensor and did not want to go the Arduino way but with a simple ATtiny85? You probably know already about  the issues with the existing Arduino based libraries running on the ATtiny microcontrollers, but can’t deal with them. TinuDHT is our answer to this.

TinuDHT is a C library for working with the DHT11 temperature/humidity sensor intended to be used with the Tinusaur but should also work with any other board based on ATtiny85 or similar microcontroller.

DHT11The DHT11 is very basic, low-cost digital temperature and humidity sensor. It uses a capacitive humidity sensor and a thermistor for measurements, and sends out the info to the data pin. It is relatively simple to use it, but requires precise timing to retrieve the data correctly. One disadvantage of this sensor is that you can get new data from it no more often than once every 1 or 2 seconds.

The primary problem with the direct use of the Arduino libraries is that the ATtiny85 and Tinusaur in particular do not have enough resource to handle the send/receive process properly, i.e. not enough CPU power, in result of which the timing of the signals that are sent to the sensor and received from it become messed up. In addition those libraries use Arduino specific code and/or C++ specific syntax which makes them incompatible with the plain C language.

TinuDHT library is based on DHT11Lib code. It was adapted for ATtiny, removed Arduino dependencies and timing was adjusted to work well on ATtiny85 at 1 MHz. There are few other changes and optimizations for speed and size.

TinuDHT is written in plain C and does not require any additional libraries to function except those that come with the WinAVR SDK.

Please go to TinuDHT page to see the full document.

The source code of the TinuDHT library is available at https://bitbucket.org/tinusaur/tinudht.

Tinusaur Board DHT11 LCD Battery

Oscilloscope-like Circuit – Preview

This is a oscilloscope-like circuit for the Tinusaur, it is not a real oscilloscope but could be used as a base for one.

It is built on top of the Tinusaur board (Atmel AVR ATiny85) and Nokia 3310/5110 LCD (PCD8544 controller).

There is also simple preamplifier for the electret microphone connected to the ADC of the MCU.

The audio signal source is combination of my DSO Quad (it has built-in signal generator) and a speaker.

Tinusaur powers a tiny vibrating robot

Vibrating robot chassisHere it is – the first Tinusaur powered robot.

This is a vibrating robot that could turn left, right and move forward.

I decided to build that after watching a video on YouTube about the Kilobot project from Harvard University. Mine is much simpler and a lot less capable. But hey, that’s the first version only. 🙂

First I made a testing chassis for the vibrating motors. As it is seen on the picture they are wired (connected with thin copper cable) to a battery – this allowed me to make some experiments before deciding how to put them on the final version of the board. It turned out that they should be in angle. I decided to put them in 90 degree.

Vibrating robot chassisSo, I made another chassis with the 2 motors positioned in 90 degrees (2 x 40 degrees)

I used double-sided prototyping board and the motors’ contacts fitted nicely into the holes, no soldering was necessary – I just fixed them to the board with isolated wires.

On the top of the chassis I tied a shield-like board that connects motors to the MCU board. Later I may need to add some components on that shield board, like driver for motors, sensors, etc.

The Tinusaur – Prototype BoardFor the “brain” of this bug I used one of the prototype boards of the Tinusaur based on Atmel AVR ATtiny25, coupled with a 2xAAA package for batteries.

At the moment the motors are connected directly to the output pins of the MCU, there are no any drivers. It works fine for now but may need to change.

The code for this experimental build is very simple – it just turns on and off 2 output pins on the MCU.

#include <avr/io.h>
#include <util/delay.h>

#define MOTOR_PORT PB3
#define MOTOR_PORT PB4

int main(void)
{
  DDRB |= (1 << MOTOR_PORT);
  DDRB |= (1 << MOTOR_PORT);

  while (1) {
    PORTB |= (1 << MOTOR_PORT);
    PORTB &= ~(1 << MOTOR_PORT);
    _delay_ms(3000);

    PORTB &= ~(1 << MOTOR_PORT);
    PORTB |= (1 << MOTOR_PORT);
    _delay_ms(3000);

    PORTB |= (1 << MOTOR_PORT);
    PORTB |= (1 << MOTOR_PORT);
    _delay_ms(8000);
 }

  return (0);
}

Problems

The 2 vibrating motors, even though I bought them together, do not work the same way. That creates some difficulties controlling the direction of the bot – it turns well in one direction but not that well in the other. There are even bugger problems moving forward.

Tinusaur powered vibrating robotIn the next version I should definitely make changes in the vibrating motors – use some of those button-like ones and also change their angle. A friend of mine suggested that I should probably play more with the “legs” as they are crucial for the movements with which I agree.

The battery is too big, but button cell battery is not enough to power the MCU and the motors for a long time, so I should probably think of another power source.

There is a short video on YouTube that shows more photos of how I built this with some footage at the end of the robot moving around.

Any comments and suggestions are really appreciated.

🙂