ATMega88 Bootloader

ATMega88/168 Bootloader - in progress

*ATmega88/168
*internal 8Mhz (crystal recommended for reliable communications)
*38,400 baud
*intel hex text upload
*runs in upper 2k of bootloader section
*boot reset fuse programmed

Update- 1/2/2007
*changed look of rebol program a little
*have been running bootloader and Rebol program for a couple weeks- no problems, no errors
*I leave Rebol program open with hex file selected, compile with winavr, then click reset,power up mcu, press erase, press program, press go
*still need to make command line options for program
*running tera term is just as fast, as very easy also- hold esc key down, power up mcu, ! to erase, drag & drop hex file, g to go

Update-
*added '168, needed to add option to force rcall's instead of using call's to save space, a few minor changes needed like pagefile size, help message, flash size
*newer 'help' message, erase commnd changed to ! (requires shift key, makes a little harder to accidentally erase), read changed to R
*Go command added, if address 0x0000 is not 0xFF, will ijmp to 0x0000
*command prompt reduced to E> or F>

*Fuse values added to (flash) read command, to display fuse values

*trying to make a Rebol program to upload hex files (not required, but will hopefully be able to automate the upload)
*will make it command line parameter friendly
*serial port programming for the pc with Rebol is relatively easy, but is still not 100% reliable (yet)- I must be doing something wrong

*first- click reset button to 'press escape' and wait for '88/168 power up
*flash/eeprom button will toggle between modes, bottom 'info' button will show which mcu connected '88 or '168, the 'info' button above that just shows number
of rx characters (to show activity on rx)
*after selecting the hex or ee 'file', 'erase', then 'prog' (file extension will determine if flash or eeprom, and will change mode accordingly)
*'read' button will show memory map display, any 0xFF will remain black (map sized for '168, green mark shows '88 size)
*'read' command also saves read output to a 'read.txt' file (could also make it save as an intel hex file for backup purposes)
*error lights will show any errors

*more work to do- more error checking, command line options, etc (it never ends)

*To enter bootloader, open terminal program, set to 38400baud, 8n1, no local echo, incoming cr=cr+lf, transmit line delay 17msec
*press ESC key, power up atmega88
*bootloader will have 1/2 second to see the ESC key
*help menu will appear, and you will be at the command prompt
*the command prompt will show which write mode you are currently in, either Flash or EEprom

*Here the flash is erased, showing the flash addresses erased, and is verified to be empty
*Then a switch to EEprom mode is made, and all eeprom is erased (0xFF)

*EEprom read

*EEprom address 0x0000 programmed at command line with value 0x02
*:01 = 1 byte of data , 0000 = address of eeprom, 00 = record type is data, 02 = data byte, FD = checksum , sum of all bytes (ascii pair as hex) is 0.
*The command was typed in, and was echoed back as the command was typed, the command line was processed when enter key pressed
*OK means the data was valid and was programmed
*The EEprom read shows that it actually worked

*Switched to Flash write mode
*A simple program was sent to be programmed, in this case the intel hex file was open in a text editor, CTRL+A to copy text, then right click on the
terminal window, each line was entered just as if it was typed
*When end-of-file record received, a message is sent indicating so, but has no effect on anything, just informational

*Flash read command shows programming worked
*The flash readout is in bytes and addressed in bytes, as is the intel hex file, so any words you may want to find are reversed. For example the first
instruction in this little program is 0xC019 which is a rjmp instruction (a word size). C0 is the high byte, 19 is the low byte. Since both the intel hex
and the flash readout are byte addresses- byte address 0x0000 is referring to the low byte of word 0x0000, which is 0x19, byte address 0x0001 is
referring to the high byte in word 0x0000, which is 0xC0. If the flash readout was in words instead of bytes, the words would not be reversed, but
any byte data you want to see would be reversed. Pick your poison.
*So, this is what I think (and I could be wrong, because I've had to revisit the byte reversal thing several times even when I think I understand it)- if you
see a intel hex file/lss file/disassembler file (only talking about atmega88- don't know about others)- if its using byte addressing, any word data will be
reversed (lss file), if using word addressing, the bytes will be reversed (disassembler).

*CRC-16 is calculated on a flash read command
*Notice here that if you press the enter key at the command line, you just get another command prompt, a quick way to see if still communicating

ATTiny2313 4-Line Phone Status
My ATTiny2313 project
Displays status of 4 phone lines, whether ringing, outgoing or incoming call in progress. Also shows time line is offf-hook and whether
it is an incoming or outgoing call.