I want the ATMEGA8 to send text messages to my I2C lcd display. (LCD03) This does not work. If I flash EXACTLY THE SAME program to my ATMEGA32 (which is on the same bus) it works fine. Obviously, I checked the SDA and SCL connections. I can program the ATMEGA8 with my stk200 cable. The 4k7 pullup resistors are in place. Frankly, I'm clueless.
A bootloader is a piece of software, that is located in a special part of a microprocessors flash memory. It is able to communicate with the outside world via the pins of the processor (e.g. Via RS232, SPI, I2C etc.). And it is able to change the content of the main part of the flash content. Feb 25, 2013 The best solution for AVR I2C with ChibiOS would be to use I2C library I include with Nil RTOS. I intend to provide it with a future version of ChibiOS. It requires NilTwiWaitSignal.cpp to be modified for ChibiOS. This library is RTOS friendly and the calling task sleeps while I2C transfers occur. IIC For AVR Series.Code linkhttps://github.com/skjha51/ATMEGA8-TWI.
Introduction
The I2C protocol is used for communication between different parts (up to 127 participants) of a system using only two wires. I will show a very simple example with two ATMEGA8 microcontrollers that communicate via this protocol. Atmel calles this not I2C, but TWI (two wire interface). A detailed description is on page 157 of the ATMEGA8 datasheet. It is quite long and there are many ways of using the TWI interface. It takes a bit of time reading the section and understand what is going on. The example here can be used as a 'quickstart' guide into this protocol and to get some working code as a starting point for own implementations.
The following picture shows the topology of a TWI network: all participants are connected to two wires that are held at VCC potential by two pull-up resistors. There is a clock line (SCL) and a data line (SDA). Communication happens always between exactly two participants at one time (with the exception of a general call, but I'll not describe that). The participant that initiates the communication is called 'master' and adresses another participant which is called 'slave'. As part of each transmission, the master has to sent the address of the slave. All slaves are continuously monitoring their TWI lines and have to react if their address is called.
| modified picture from the ATMEGA8 datasheet, showing the layout of my small example with one master and one slave, indicated in red |
I will use the TWI in connection with interrupts, so some basic knowledge of interrupt mechanisms is needed to understand this example.
The following picture shows a schematic drawing of my setup. I didn't draw the connections to the ISP programmer. Note that the two devices really are only connected by the power lines and the two TWI wires (in blue). I used ADC3 input to connect a variable voltage divider. To keep things simple, I only transmit a single byte over the TWI interface. The two least significant bits from the 10-bit ADC value are truncated and only the 8 most significant bits are transferred. The reset pins of both controllers are connected to ensure that both start working at the same time.
The implementation on a bread board looks like this:
Relevant TWI Registers
The TWI subsystem in the ATMEGA8 is controlled by some registers. These are described on pages 165-167 of the datasheet.The TWI Bit Rate Register (TWBR) contains a divisor for the clock frequency and determines the TWI clock speed. I leave that register untouched, which will result in a TWI clock speed that is 1/16 of the CPU clock speed.
The TWI Control Register (TWCR) is used to enable the TWI hardware (set TWEA bit to 1) and is also used to interact with the hardware between transmission actions (via the TWINT bit). In TWI tranmissions, the control is passed back and forth between the user application program and the TWI hardware on the chip. The application code has to set some bits in that register according to what the next TWI action should be. After setting the TWINT bit, the TWI hardware starts working again - independent from the application code. It will first clear the TWINT bit. Whenever the TWI hardware is done with its actions, it sets the TWINT bit again. The application code can either poll that bit to check when the TWI hardware is done, or it can request an interrupt that is triggered by the TWI hardware. In this example I've chosen the latter possibility.
If the application code is notified by the TWINT bit in the TWCR register, it can obtain the status of the TWI hardware from the TWS[3:7] bits in the TWI Status Register (TWSR).
For all four operation modes of the TWI interface (master transmit, master receive, slave transmit, slave receive) the application code has a finite number of options. All of them are listed in the ATMEGA8 datasheet in tables.
After the TWINT bit was set (and an interrupt was triggered) the application code might find the number 0xA8 in the TWS[3:7] bits. The table lists all the possible options, which are chosen by setting or clearing certain combination of bits in the TWSTA, TWSTO and TWEA bits in the TWCR register. After setting the desired action, the TWI hardware is activated again by setting the TWINT bit again. Given the tables for all four communication modes, there are many many ways of realizing communication between two TWI devices. Often, the slave will be a given part (e.g. a sensor with I2C interface) and its behavior will be documented in its datasheet. Using an ATMEGA8 to read such a sensor requires to implement the correct a master behavior. In this demonstration example, both devices will be ATMEGA8. I have implemented a very simple (might be the simplest possible) slave behavior in the following code.
Slave Transmitter Program
When the TWI was addressed, the interrupt routine ISR(TWI_vect) is called, and the switch statement will go to the first case. The transmission data is loaded into the TWI Data Register (TWDR) and the first row of the above table is chosen, i.e. indicating the last data byte. In the case of only one data byte, the first byte is also the last.After sending the byte, the TWI hardware will get the acknowledge signal from the master. Then, the TWEA bit has to be set again which tells the TWI hardware to monitor the address line and trigger another interrupt if its address is called. The transferred data is generated by the ADC, using only the 8 most significant bits of the 10-bit ADC value.
Master Receiver Program
Bus Action
Start and stop conditions are indicated by a SDA change while SCL is high. During address and data transmissions, the SCL line goes high when the transmitter has a stable voltage level on the SDA line so that the receiver can sample the voltage level. The first burst of 9 clock pulses is during the 7-bit address transmission (plus read bit and acknowledge bit) from the master to all TWI participants. The second burst of clock pulses is the transmission and acknowledge of the data byte.
More
This page was last changed on 21.04.2005 |
A bootloader for theATmega8 AVR microprocessor
Version 2.1 is nowavailable for download
What is a bootloader?
Abootloader is a piece of software that is located in a special part of amicroprocessors flash memory. It is able to communicate with the outside worldvia the pins of the micro (e.g. via RS232, SPI, I2C etc.). And it is able tochange the content of the main part of the flash content.
Whatis it good for?
Normally a specialdevice is needed to put new software into a microprocessor. A so called 'programmer' is connected to the microon one side, and to a PC on the other side. It transfers the new software fromthe PC to the micro. On the PC side there is an Windows application that sendsthe information to the programmer. A bootloader makes it possible to connect themicro to the PC application directly (e.g. via RS232), read the new softwarefrom the PC and put it into the main part of the flash, the so calledapplication section.
What is the mainbenefit of a boot loader?
Since thebootloader can be written in many different ways, it can be adapted to the needsof the specific application it is used in. The bootloader can even contain adecryption algorithm, so the software can be given to the end-user forindividual software upgrades, without the risk of reverse engineering or hackedfirmware.
Who does need a bootloader?
Avery common field of usage for a bootloader is portable consumer electronicslike cell phones, personal digital organizers (PDAs), handheld GPS receivers,etc. New software updates are usually distributed via the internet. It is in themanufacturers interest that the user can upload the software easily to thedevice without needing a special programmer hardware. But the user should notbe able to disassemble or manipulate the software.
Theprocedure would be like this: The user downloads an encrypted software for hismobile phone from the internet. He connects the phone to his PC via his standardRS232cable. The bootloader in the telephone establishes a connection to the PC, readsthe software, does the decryption and puts the software in application sectionof the phones flash memory.
What was themotivation for creating the bootloader that is published here?
Thisbootloader will be used at the amateur radio relay station in Nennslingen,Germany. It is part of the receiver, which does all the controlling within therelay station. Since there is a PC available with remote access at thatlocation, there will be a permanent RS232 connection between the receiver andthe PC. If the need for an software adaptation arises (e.g. due to interferenceproblems), it can be done remotely, without the need to be on side for uploadingthe software. The used processor is the Atmel ATmega8, which supports thebootloader functionality.
What is thehistory behind this piece of software?
Atmelhas published a bootloader written in C language in their application noteAVR109. It is written using the IAR C compiler which is not free, so it is notavailable to everyone. The application note itself is well written and worthreading. It can be found at www.atmel.com.
Onwww.avrfreaks.net there is design note(#32) which describes a bootloader written in assembly for the ATmega163. Iteven has an counter implemented in the devices EEPROM to count the number offlash erases. However this software is not directly applicable to the mostwidely used AVR processor, the ATmega8. This software was used as a basis for thebootloader that is published here. The main advances are:
- check implemented to access the flash only after the last task was completed
- re-enabling the application section after it was reprogrammed by the bootloader
- interface sync-losses between AVRProg1.37 and the bootloader solved by implementing required commands that were missing
- startup code section that waits for 8 seconds for bootloader commands and starts the application if no commands are received (this makes it possible to use solely RXD and TXD lines on the RS232 for software upload, no further lines are required)
- Usage of 'universal command' by AVRProg1.37 with regard to fuse/lock bit reading conquered to make things work
- code is well documented now, every block and every line is exactly explained (this simplifies adaptations to individual requirements)
What do I have to know about hehardware configuration?
Well, not a lot. All you have to have is a RS232level shifter (like a MAX232 or similar) that connects the UART input (RXD) andoutput (TXD) to your PC. You might want to connect a LED to I/O pin PB1 (activelow, i.e. between Vcc and PB1). This LED shows you the state of the bootloader,as described below.
The AVRProg1.37 uses a fixed Baud rate of19.2kB/s, this is achieved by using a 7.3728MHz crystal. Other crystals can beused but the UBR parameter has to be adapted then.
How can the bootloader be used?
Very simple. Use your traditional programmer toset the fuse bits for a 512 words (=1kByte) bootloader section size. Load thebootloader into the mega8 with a traditional programmer. It will automaticallybe place within the last 1kByte of the flash. Set the BOOTRESET fuse bit usingyour programmer. This will cause the processor to start with the bootloadersection from now on, rather than hitting the ground at address 0x00 afterpower-on.
From now on, you don't need a programmer anymore. After power-on, the bootloader will wait for an ESC (=ASCII 27) via theRS232 interface [the LED flashes]. If that ESC does come (e.g. sent from a terminalprogram running on the PC), the bootloader code will be activated [the LEDstays on permanently] and the PC will be able to communicate to the processor asif there was a programmer connected. So simply start AVRProg1.37 and downloadyour application software. Then close the AVRProg, start a terminal again, press'E' and the bootloader software will terminate itself [LED will turn off] andstart the application software.
If no ESC is received within 8 seconds afterpower on, the application program will start automatically. If there is noapplication software loaded, the bootloader will wait forever for an ESC.
Are there any open issues?
Atmega8 Software I2c Software
There are no known issues at this point in time.It should be noted that the write fuse bit button in the advanced window willnot have any effect. AVRProg1.37 uses the '.' command for setting the fuse bits.This is intentially ignored to avoid the risk of locking oneself out. Also theregular commands for setting lock/fuse bits are intentionally ignored.
Download the bootloaderversion 2.1 here.
How does is look like when I use thebootloader?
Atmega8 Software I2c Login
Well, it looks just like if you were using anexternal programmer. The only difference is that the ATmega8 is the only devicetype that is offered to the user by AVRProg.
Atmega8 Software I2c File
When you press the advance button, AVRProg showsyou the state of the lock and fuse bits, the device signature, the identifier ofthe bootloader and the bootloader software revision. The calibration byte willalways read 0x00, its readout is not supported by the bootloader.