I noticed this has a newer version of optiboot. Is this an unofficial fork?
Here's where I've been going for the official optiboot release:
https://code.google.com/p/optiboot/
ralphd:
I noticed this has a newer version of optiboot. Is this an unofficial fork?
Looking more at the modified optiboot code, I notice it assumes the 167 is the only >8K part, when there is also the 1634. A better way to determine if a jmp instruction is required instead of rjmp would be to look at FLASHEND.
It is unofficial, I was playing around to see if I could get it to work, and so far it works quite well for attinyX4, attinyX5, attinyX61 and attinyX7. I have made a great deal of modifications to reduce the size considerably for soft UART/virtual partition devices, and also had to make it work for them in the first place (the official one that it was based on has many glitches in that department) - but then it wasn't designed for attinies.
The 1634 is not supported in any of the #defines in boot.h, nor was its support ever intended when I made the mods, so it was a bit of a hack checking the way I checked. However what you will find is that the whole file is littered with #ifdef statements for different processors as adding a new one is not simple, the attinies have such a wide range of differences from one another. The attiny167 is no exception, that one is really very weird and it took a lot of faffing around to get it to work.
Well, it's some nice work.
Why did you change uartDelay to 1/4 bit time from 1/2? Was it to support slower baud rates?
In putch you can save an instruction by removing the sec after the com because com sets carry.
I notice you have a version of the core with the millis timer stripped out.
A less drastic option that cuts the code size down considerably while still maintaining almost 100% compatibility is to change millis from long to int (along with the argument to delay()).
I reduced UART delay to 1/4 and added a couple of extras because it gives more reliable results if the chip starts reading the Serial data part way into the first bit (due to the delay in checking for a start bit). It seems to work quite well that way around. I did have to do a major rewrite of the getch and putch functions because the way they were before compiled to something completely different to what the original writer had intended. They were then optimised as you have noticed.
I've also converted these routines into an interrupt based (using comparator as a trigger) Software Serial library which is integrated into the core - if your chips has a hardware serial module, that will be used, otherwise the TinySoftwareSerial library will be switched in giving you the same Serial commands as if there were a hardware module (with the exception that data cannot be received at the same time as it is sent).
The core without the millis() was done to strip away any trace of messing with the timers in the situation where you want to write a program which requires access and control of all the timers (I've had a couple of projects that have needed this).
After looking more over the code, I think putch and getch can be cleaned up.
Instead of a fixed delay, it's better to have a variable delay like I did in my bitbang serial.
https://code.google.com/p/picoboot/source/browse/trunk/BBUart.S
The putch and getch core loops have different timing - putch is 9 cycles and getch is 8 cycles, so sometimes the best timing is with a different delay for each. Also the putch code has 1 cycle of jitter - a 0 bit is written 1 cycle sooner than a 1 bit. My bitbang uart is written to have no jitter.