BE SMARTER! Make, play and learn with the Tinusaur microcontroller boards.

tinyavr

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.

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.

For 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.

DEBUGGING_VAR and DEBUGGING_VARU print variable name and then the value.

DEBUGGING_ERROR prints the error code then the message.

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.

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.

We 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.

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.

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.

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.

Hardware

Drivers

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

The 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:

Any live cell with fewer than two live neighbours dies, as if caused by under-population.

Any live cell with two or three live neighbours lives on to the next generation.

Any live cell with more than three live neighbours dies, as if by overcrowding.

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.

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:

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 ATtinymicrocontrollers, 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.

The 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.

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.

The 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.

We have a shield-like proto board now, very preliminary design. It will allow you to solder some components on it and then put it on top of the Tinusaur Board – very much like any other shield-like board. It is available on OSHPark at this address: https://oshpark.com/shared_projects/2zuAJJGZ.

All the parts for the Tinusaur Starter kit were ordered from our suppliers. We hope everything to be in our office (most of them already arrived) by the end of the month. Will post more information about it here and on our Twitter/Facebook/etc.

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.

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.

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.

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.

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.