The OWOWOD Library

OWOWOD is One Wire / One Way Output for Debugging library. It allows you to output text from the Tinusaur (ATtiny85 microcontroller or other similar), though USB-to-Serial or TTL converter (based on PL2303, CH340G or similar) and to the computer screen using COM port monitoring tool.

Why one would need something like that?

I would’ve been nice if it was possible to write something li this …

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

… and see the output on a computer. Great for debugging and other things.

Unfortunately there is no easy way of doing that – 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 (ex.: USBasp) do not offer that kind of communication between the micro-controller and the computer, i.e. there is no 2-way communication.

USB to Serial TTL

There are some solution and the OWOWOD library is just one of them. It uses an additional hardware component – USB-to-Serial converter also known as USB TTL Converter. They are very inexpensive, easy to find and work with.

The OWOWOD Library could do that.

Tinusaur connected to USB-to-Serial PL2303 using OWOWODFor this to work we need …

  • Micro-controller
  • USB-to-Serial converter
  • Computer

The Library works like this …

  • When you use a library function like owowod_print_char(‘U’) it will start sending sending the bits of the ‘U’ byte (hex: 0x55, bin: 01010101) in series, i.e. one bit after another, through one of the microcontroller pins – for instance PB3.
  • At the other end of the wire there is USB-to-Serial converter that will take the individual 01010101 bits and re-compose them back into one byte as 0x55.
  • Then the USB-to-Serial converter will send that ‘U’ byte (0x55) to the computer USB port.
  • The computer sees the USB-to-Serial as a Serial COM Port port, so it reads that ‘U’ byte.
  • Using another program on the computer we get that ‘U’ byte and show it on the screen.

It works similarly for whole strings and other data.

Let’s take a look at some usage examples:

#include <stdlib.h>
#include <avr/io.h>
#define OWOWOD_PORT PB3
#include "../owowod/owowod.h"
int main(void) {
    owowod_init();
    owowod_print_char('U');
    owowod_print_string("Hello!\r\n");
    owowod_print_numdec(1);
    owowod_print_numdecp(2);
    owowod_print_numdecu(123);
    owowod_print_numdecup(456);
    return 0;
}

Always initialize with owowod_init() function.

You can print char, string but also decimal signed and unsigned integer numbers.

The decimal numbers are 16-bit integers.

The owowod_print_numdecp() and owowod_print_numdecup() functions print left padded numbers – that means there will be some spaces on the left as if the numbers are right aligned. Like this …

    12
   345
 67890
    -2
   -34
-56789

Because this would be used for debugging in most of the cases there are some helpful definitions for that purpose in the “debugging.h” file.

Here is an example of how to use it …

#define F_CPU 1000000UL
#include <stdint.h>
#include <avr/io.h>
#define OWOWOD_PORT PB3
#include "../owowod/owowod.h"
#include "../owowod/debugging.h"
int main(void) {
    DEBUGGING_INIT();
    DEBUGGING_NUMDEC(-123);
    DEBUGGING_NUMDECP(-4567);
    DEBUGGING_NUMDECU(123);
    DEBUGGING_NUMDECUP(4567);
    DEBUGGING_STRING("Hello!");
    DEBUGGING_STRINGLN("Hi!");
    DEBUGGING_VAR("X", 1);
    DEBUGGING_VARU("Y", 23);
    DEBUGGING_ERROR(4, "Connect");
    return 0;
}

DEBUGGING_STRINGLN adds CRLF new line at the end.

DEBUGGING_VAR and DEBUGGING_VARU print variable name and then the value.

DEBUGGING_ERROR prints the error code then the message.

hercules setup serial

To see the results we need a program that will run on a computer and show on the screen the information that comes through the serial port. There are many programs that could do that. One particularly simple to use is the Hercules Setup utility by HW group – it is just one EXE file that you run – that’s it.

The OWOWOD has its own page, it is at:
https://tinusaur.org/projects/owowod/

This library was developed with and tested on the following microcontrollers: ATtiny85, ATtiny45, ATtiny25 but should also work on other tinyAVR chips.

The library was tested to work with following USB-to-Serial converters: PL2303, CH340G.

Source code is available at https://bitbucket.org/tinusaur/owowod.

References

There are many project in the Internet that solve the same or similar problems and this article http://www.ernstc.dk/arduino/tinycom.html that points to some of them:

On eBay: USB to Serial TTL converter – to transfer the debugging output from the ATtiny micro-controller to the computer.

Here are links to some of the posts related to this library:

 

Tutorial 003: Making Sounds with Buzzer

Electromagnetic BuzzerSo far we’ve used a LED as output to produce light of different colors and intensity (Tutorial 001 and Tutorial 002) but we haven’t generated any sound yet.

In fact that isn’t very difficult to do.

We will use a buzzer for output.

According to Wikipedia … the buzzer or beeper is an audio signalling device, which may be mechanical, electromechanical, or piezoelectric. Typical uses of buzzers and beepers include alarm devices, timers and confirmation of user input such as a mouse click or keystroke.

Tinusaur BuzzerWe will use electromechanical buzzer. When voltage is applied to it its membrane moves up (or down, depending on the particular device) and respectively when there is no voltage the membrane goes back to its normal position. Applying constantly changing voltage will generate audio waves perceived by us as a sound.

Let’s connect the buzzer to the PB2 of the ATtiny85 on the Tinusaur board.

The program should look very much like the one for blinking LED except that the delay between switching the port should be very short.

In the example below we have a delay 500 and since we’re using the _delay_us() function that means the delay is 500 uS (microseconds). That means the period of the signal will be 2 x 500 uS = 1000 uS (or 0.0001 sec.) and then the frequency is 1 / 0.0001 S = 10000. That means the sound will have frequency of 10 KHz.

Here is the source code:

#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>
#define BUZZER_PORT     PB2     // Buzzer I/O Port
#define BUZZER_DELAY    500     // Delay for each tick
int main(void)
{
    DDRB |= (1 << BUZZER_PORT); // Set port as output
    while (1) {
        PORTB |= (1 << BUZZER_PORT);
        _delay_us(BUZZER_DELAY);
        PORTB &= ~(1 << BUZZER_PORT);
        _delay_us(BUZZER_DELAY);
    }
    return (0);
}

Full source code with more comments and the other necessary files such as Makefile is available at https://bitbucket.org/tinusaur/tutorials/src/default/tut003_buzzer/

Build the program:

$ make

Upload the code to the controller:

$ avrdude -c usbasp -p t85 -U flash:w:"main.hex":a

The buzzer should start making sound immediately.

Let’s do some more experiments.

Let’s make the delay between the buzzer ticks change over time and see what sound it will produce.

This time instead of _delay_us() we will use the _delay_loop_2() function. According to the _delay_loop_2(int) documentation it produces 4 empty CPU cycles per iteration – in other words with parameter 100 it will produce delay of 400 CPU cycles. That tells us that the maximum is 65536 x 4 = 262252 cycles. That, at 1MHz CPU clock, is approximately 262 mS (milliseconds) maximum delay, … or about 3.8 Hz minimum frequency – perfect for our experiments.

Below is the source code:

#include <stdint.h>
#include <avr/io.h>
#include <util/delay.h>
#define BUZZER_PORT     PB2     // Buzzer I/O Port
#define BUZZER_DELAY    200     // Delay for each tick
int main(void)
{
    DDRB |= (1 << BUZZER_PORT); // Set port as output
    int delay = 0;
    while (1) {
        if (delay < 1) delay = BUZZER_DELAY;
        PORTB |= (1 << BUZZER_PORT);
        _delay_loop_2(delay);
        PORTB &= ~(1 << BUZZER_PORT);
        _delay_loop_2(delay);
        delay--;
    }
    return (0);
}

After building and uploading this should start making sound like of a car alarm.

With similar techniques a lot more complex sounds could be generated.

This post will eventually become Tutorial 003.

 

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.

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

Tutorial 002: Fading LED x1

Another beginners tutorial is on the way – this time about a fading in and out LED.

This is simple tutorial that shows how to connect a LED to the ATtiny85 based Tinusaur board and write a program that makes the LED to fade in and out using PWM (pulse-width-modulation) technique.

PWM Diagram

Note: The code in this tutorial does not use the built-in PWM capabilities of the ATtiny microcontrollers, instead it uses direct bit manipulation since this un easier way to understand how it works. Another tutorial should cover the PWM functionality that is built into the microcontroller.

Tinusaur Board with LEDThe Tinusaur board is a standard ATtiny breakout board so this could be applied to almost any other board that has ATtiny microcontroller on it. The code was tested to work with ATtiny13, ATtiny25, ATtiny45 and ATtiny85 but will probably work on any other ATtiny microcontrollers as well.

Please go to Tutorial 002: Fading LED x1 to see the full document.

You can also check the Tinusaur Board – Assembling Guide and the WinAVR – Setup Guide.

 

February: Quick update

Tinusaur Project Milestones

This is quick update for what is happening in the lab.

Tinusaur Proto

And by the way, our project was featured on OSHPark Blog, here’s the link … http://blog.oshpark.com/2014/02/staff-picks-for-the-week-of-2-february-2014/. Very glad to see that people are interested in this project.

As follow up to our first Tutorial 001 we are planing to put another one – Tutorial 002, probably about how to connect a push-button to the board and receive input from it.

Tutorial 001: Blinking LED

Tinusaur Tutorial 001: Blinking LED

UPDATE: New version of this tutorial is available at the Tutorial 001: Blinking LED x1 page.

Tinusaur Tutorial 001: Blinking LEDThis is very simple tutorial how to make a LED blinking.

Since the Tinusaur board is a very standard ATtiny breakout board this could be applied to almost any such other board.

The code was tested to work with ATtiny13, ATtiny25, ATtiny45 and ATtiny85 but will probably work other chips too.

We assume that the Tinusaur board is already assembled, successfully; connected through the ISP programmer to the computer; and development environment . It is not the subject of this tutorial how to assemble the board or how to setup development environment.

The LED should be connected on pin 2 of the ATtiny – this is PB3 – through a resistor, and to the GND.

The LED, marked as D1, is just a standard light emitting diode.

The resistor, marked as R1,  is 270 to 330 ohm.

The most important fragment of the code is this:

	while (1) {
		PORTB |= (1 << LED_PORT);
		_delay_ms(200);
		PORTB &= ~(1 << LED_PORT);
		_delay_ms(400);
	}

What is does is this:

  1. Start an infinite loop.
  2. Set the LED wire signal to “1” – that will make it to light.
  3. Wait a little – 200 milliseconds.
  4. Clear the LED wire signal to “0” – that will turn it off.
  5. Wait a little -400 milliseconds.
  6. Do it again.

Here is the entire source code:

/**
 * The Tinusaur Project
 *
 * Tutorial 001: Blinking LED
 *
 * file: main.c
 * created: 2014-01-04
 *
 **/

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

// ====================================
//                ATtiny
//               25/45/85
//              +--------+
//            --+ o  Vcc +------------
//  LED - PB3 --+        +--
//            --+        +--
//  ------------+ GND    +--
//              +--------+
// ====================================

// Define the I/O port to be used for the LED.
// This a number between 0 and 7 that tells which bit to use.
#define LED_PORT PB3

int main(void) {

	// Set the LED port number as output.
	// The DDRB is the data direction for port B.
	// This ...
	//  - shifts the "1" on left to the desired position and ...
	//  - does bitwise "OR" with the value in the port register.
	DDRB |= (1 << LED_PORT);

	// Start infinite loop.
	// (this is how most programs work)
	while (1) {

		// Set the LED bit to "1" - LED will be "on".
		PORTB |= (1 << LED_PORT);

		// Wait a little.
		// The delay function simply does N-number of "empty" loops.
		_delay_ms(200);

		// Set the LED bit to "0" - LED will be "off".
		PORTB &= ~(1 << LED_PORT);

		// Wait a little.
		_delay_ms(400);

		// Do it again ...
	}

	// Return the mandatory for the "main" function value.
	return (0);
}

Copy the code above to your “main.c” file.

The source code could be also found on Bitbucket at this address: https://bitbucket.org/tinusaur/tutorials/src/1f61873ae382/tut001/src/main.c.

The circuit schematics, even though very simple, was drown on 123d.circuits.io and it is available at this address: http://123d.circuits.io/circuits/76781.

 

Oscilloscope-like Circuit – Preview

tinusaur oscilloscope on youtube

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 Proto v0.1 m1 – Prototyping and Design Considerations

The Tinusaur

I have finally managed to finish the first version of the schematics and PCB‘s and to order the first 3 pieces. This work is based on some previous experiments and designs.

20131108_proto_01sc580x380fx

Schematics

The schematics is nothing special – it is the well known minimal configuration for the ATtiny plus just few addition components – some of them optional.

The required components are the 2 capacitors between Vcc/GND and the 10K resistor on the RESET wire.

There is RESET push-button connected to the micro-controller.

The micro-controller connects to the outside world through 2 headers – H1 an H2. They are in two different sizes for number of rasons: first – to have more connections available for wires, and second – to make sure we won’t mistake H1 and H2.

Next to the headers there is 1×2 connector for external power source.

There is an optional battery for application where built-in power source is needed.

20131108_proto_02sc324x440fx

PCB

The PCB is a fork of my previous work on a simple header board.

There are 4 holes in the corners in case the board should be fixed to another object.

On each side of the IC there are 2-row headers – on 2×4 and the other 2×5.

External power source connector is put along with the H2 header.

The ISP connector is at the top of the board. Between it and the rest of the board there is 1×6 header-like probe – this could be used for testing as well as for easier cutting off the ISP part of the board in case is not (or no longer) needed.

The pads for the optional battery are on the bottom.

The size of the board is approximately 24×36 mm.

The schematics available on 123d.circuits.io website at this address: http://123d.circuits.io/circuits/58269.

The Tinusaur – What is it

The Tinusaur – What is it

Briefly, the Tinusaur is a minimal micro-controller hardware configuration based on Atmel AVR ATtiny family of products and more specifically those with DIP-8 case such as ATtiny25/ATtiny45/ATtiny85, ATtiny13 as well as their variations.

The goal of the Tinusaur project is to have a simple, cheap and accessible quick-start platform for everyone interested in learning and creating things.

There is more information on the About page.