I figured I'd try to use Webbotlib and its tools to play with the handful of ATtiny85 MCUs that I got for side projects.

The initial step is to add this MCU to BoardDesigner's options. I dove into the documentation for the ATtiny85 and also for the Atmega32 as a point of reference. It took me a while, but I have a (mostly) complete .mcu file. The catch is that the ATtiny85 does not have a UART, so my UARTS section in the .mcu file is empty. Board Designer complains about this. Removing the UARTS section altogether doesn't work either, unsurprisingly.

I imagine I might be able to put a fake placeholder UART in there (though I'm skeptical I'd be able to compile any generated code), but should Board Designer perhaps be modified to accommodate MCUs with no UARTs?

One of the next steps once I get past this will be to create a libWebbot-attiny85.a library file... I'll figure that out, but anything I should know that's going to give me particular trouble?

I've included my .mcu file contents below. The part I'm least certain about is Timer1's C compare channel; it's different from A and B, and from anything that the Atmega32 .mcu file defines. (I've not looked at other .mcu files yet)

Quick answer is that WebbotLib has never supported ATtinys. With only 8k flash the ATtiny85 may struggle to fit your runtime unless its very small - since WebbotLib does add some code overhead. For the same reason I've always maintained that the ATMega8 is also borderline.

Its not recommended that you hand write your own mcu files!!! I have my own app that generates them from buggy files provided by ATmel. This app also makes sure that the mcu obeys certain assumptions made within WebbotLib itself and if you code the file by hand these checks are bypassed. For example: WebbotLib assumes the timer prescalers are 3 bit but when I run the ATtiny85 thru my app then it reports it timer1 as 4 bit (which the datasheet confirms). So even if you get it to work in the Designers and compile then you will get strange results.

If you try to compile WebbotLib for ATtiny85 you will also find other files that fall over. For example: the I2C code needs #defines to say which pins are used; and there are others.

Before I spend too much time on this then you may like to compile your code as if you were using an ATMega8 - just to see if the code would actually fit on an 8k device. If its way too big then I'd be wasting my time on changing the Designers and WebbotLib and WebbotLib Studio.

Quick answer is that WebbotLib has never supported ATtinys. With only 8k flash the ATtiny85 may struggle to fit your runtime unless its very small - since WebbotLib does add some code overhead. For the same reason I've always maintained that the ATMega8 is also borderline.

*snip*

Before I spend too much time on this then you may like to compile your code as if you were using an ATMega8 - just to see if the code would actually fit on an 8k device. If its way too big then I'd be wasting my time on changing the Designers and WebbotLib and WebbotLib Studio.

I don't currently have specific code set to go (in part because I typically start from Webbotlib's pregenerated stuff, of course ), but an empty project compiles to 13% usage with the Atmega8, so I figure the simple stuff I'm considering would fit fine.

Quote

Its not recommended that you hand write your own mcu files!!! I have my own app that generates them from buggy files provided by ATmel. This app also makes sure that the mcu obeys certain assumptions made within WebbotLib itself and if you code the file by hand these checks are bypassed. For example: WebbotLib assumes the timer prescalers are 3 bit but when I run the ATtiny85 thru my app then it reports it timer1 as 4 bit (which the datasheet confirms). So even if you get it to work in the Designers and compile then you will get strange results.

It was still a good way to force myself to dig into the MCU docs more I definitely noticed differences between the Attiny and Atmega lines...

Quote

If you try to compile WebbotLib for ATtiny85 you will also find other files that fall over. For example: the I2C code needs #defines to say which pins are used; and there are others.

Yeah... maybe I'll finally install the Arduino environ instead (so I can refer to various existing, functioning code), before moving on to a more from-scratch approach. Bleh

I've played with the updated Webbotlib this weekend and last. Currently I have a blinking LED setup, whoo! Much learning along the way; fuses, avrdude, external oscillator, board designer, etc. I am using the Tiny AVR Programmer from Sparkfun.

Currently I'm using a 16 MHz crystal, and it looks like software thinks I'm running at 1 MHz. Haven't looked beyond calculating that ratio (I calculated very crudely, 15 as my ratio; was too lazy to hook up the Saleae Logic).

So to update, I did in fact do something back in October; specifically, a tiny infinity mirror. The biggest hangup was my own fault; decrementing an unsigned int so that it looped around and my LEDs didn't behave.

I used a small convex bike mirror, so it was not a true infinity mirror. To do tinting, I used two layers of antistatic bagging from a motherboard's packing materials... The glass and bezel came from a small clock (which conveniently fell to its death a few months prior). The pumpkin required my going outside to acquire...

Oh, and a cruddy video from before I found the unsigned int overflow bug; I had 12 LEDs before I acquired an extra one (these were all free from a generous coworker), and candles behind the LEDs for awesome effect!: