Preface: As I am not an native english speaker, you are more than welcome, to fix any mistakes in grammar or spelling. It will help me, improving my foreign language skills. This page is meant, as an first overview over all digispark related hardware-programming methods. Its meant as a kind of landing page, where users can link from the forums.

There are three ways, how you can write program code: ISP, HVSP, and Self-Programming. When you start playing around with an digispark, you are using the self-programming feature of the Attiny.

To enable that feature, you need to use one of the other two methods before, to get a piece of code on the attiny, which than would allow you, to pull additional code into the attiny or changing the additional code. Uploading that initial code is one of the tasks in the digispark-production.

The code making this possible, is the bootloader micronucleus, written and maintained by the board-member bluebie.

This bootloader resides in the first 2k of the 8k memory of the attiny, and allows you, to use the remaing 6k for your programs. The big benefit of that piece of smart code ist that fact, that you need to other hardware tool for programming a digispark, like for the other two methods. It will even go one step ahead, and making it possible, that you can use the digispark, programming other core attinys in two (or lets say one and a half way).

For that purpose micronucleus emulates USB hardware, as the attiny has no on-board USB device. Communication is done with an host component, even called micronucleus, on Windows systems its for example micronucleus.exe.

To hide this special way programming the digispark, digistump has patched the IDE adding a own version of avrdude (that program, which is mostly used in the arduino-world). The avrdude of digistump is an wrapper, deciding to call either the original avrdude (for everything, which is not an digispark) or micronucleus in case of the digispark. There are however some drawbacks:

The emulation of an USB-interface has influence to 2 of the six pins of the attiny: Both are regulated with a Zener-diode, which limits the voltage on those two pins to a max of 3.6V, influencing some use cases like analogRead() or high-levels for digitalWrite(). One of those two pins has also an pullup-resistor connected, creating even more problems to this kind of usage.

The advantage of this solution is, that this way of programming the Attiny, makes the use of one more GPIO-pins possible, the pin PB5. This pin is used otherwise as reset, which is needed for programming the chip with one of the simple external ISP-programmers.

You need to be very careful, when it comes to PIN names on the AVR microcontrollers. There are plenty of names around, depending of functions or locations. Further enumeration depends, if that is done logical or physical.

There are the pin numbers of the core chip, starting with one at the special marked pin gping counter-clockwise around the chip. Than there are the numbers of GPIO-pins, AVR groups those to internal ports, where up to 8 pins can be aggregated. Those ports are named with letters (A, B, ..). Unfortunately the attiny85 is missing the port A, so the GPIO pins are called PB0 to PB5. And as you see, in the logical enumeration they start with 0, and there is no match to the physical pin number. When it now comes down to the digispark itself, those 6 pins are named P0 to P5 on the PCB; however in the schematics enumeration starts with 1.

There are a lot of other names, depending of functions for special protocols or chip-functions, like SCK, MISO, MOSI. Those additional functions are even not related to corresponding GPIO-pins. On the attiny85 SCK is together with PB2 on physical pin7. On the attiny167 fo example SCK resides with PA5 on physical pin 8. So pay allways attention to documentation before making assumptions!

Its not much more to say, about the internal programming, as that is the out-of-the box behaviour.  

ISP was developed, to allow manufacturers programming of the chip, even when it is soldered on the final PCB.

That is meant to have a cheap way, updating code to fix bugs or extend capabilities without unsoldering the chip. There are however as well some restrictions to this mode too: SCK uses MISO, MOSI and SCK, and there is no influence on those three pins allowed. AVR recommends using resistors between the pin and the shared resource. In general its a good recommendation, to read design considerations:

As IS-Programming needs the enabled RESET function (and therefore disabled GPIO function of the shared physical pin), there is no way, to program an out-of-shelf digispark with any ISP device, because the digispark has disabled the reset function.

Disabling the reset-function is something, you can do with either ISP or HVSP programming. A attiny-fuse has nothing to do, with fuses you know from electrical devices. Its one bit in a register of bits, which are stored independently in the attiny. Those registers control the behavior of the attiny, when the attiny starts. Some of those fuses and additional registers have an strong influence on the ways, to program an attiny or any other atmel device. There are three fuse bytes, which are controlling the behavior: The extended fuse byte, where bit number 0 controls, if self-programming is enabled or not. For the disgispark self-programming is disabled. The high fuse byte, where bit 7 controls, if external reset is disabled, bit 6 switches debug wire, bit 5 the capability of ISP The low fuse byte controls the clock settings. If the clock settings are not matching the expectation of preloaded bootloaders (like the micronucleus), the chip won’t start and therefore programming the core this way, is as well disabled. Important is also the lock byte, where two bits control, if ISP and HVSP are allowed to change and/or verify flash and eeprom. If one of the lockbits is set, the chip needs to be erased (which will automatically reset the lockbits) before further programming. Erasing can only be done using HVSP but will not change the three fuse bytes.

As the digispark cannot be programmed via ISP (at least not, without prior modification), the digispark itself however is allready and ISP programmer! All you need is the right connection between the digispark and the target device.

Staying in the digispark world, we assume as an programming target an attiny85 chip.

There is another open source project out there, the littlewire from Ihsan Kehriban, whom you can meet as well in the digispark forum, as both projects have more in common, as you will see very soon:

Compare the schematics of both projects, and you will see, that both implementations share the same basics: They have both the zeners and the pull-up resistor for USB communication. They are now both using micronucleus as boot loader.

The difference is only, that the digispark has an voltage-regulator on board, to drive additional devices and made all GPIO pins available on the breakout, while the littlewire makes only MISO, MOSI, SCK and RESET together with +5V and GND available on an AVR compatible layout.

The most simple way, to use the digispark as an ISP is: Take the digispark prototype shield kit and an 8 pin IC-socket.
Connect Vcc and GND to pin 8 and 4 of the socket, connect all other pins 1:1 (PB1 to PB1, PB2 to PB2, …) The reason, why you should connect all pins, will be explained later.
Here you see the front and backside from an prototype shield:

And so it looks, when the shield is connected to the digispark:

Your tiny IS-Programmer is ready to run!

Now go to bluebies Tutorial in the forum, where she explains, how you can install littlewire on your digispark.

Under Linux you will find it in ./DigisparkArduino-Linux32/Digispark-Arduino-1.0.4/hardware/tools/micronucleus
Under Windows usually in .\Digispark-Arduino-1.0.4\hardware\tools\avr\bin\micronucleus.exe

You can download the ready compiled binary from the littlewire webpage, currently it is v12

and start the micronucleus binary and give the full path to the micronucleus hex file as an parameter.
under Linux/Mac: /path/to/micronucleus /path/to/littlewire_v12.hex
under Windows: \path\to\micronucleus \path\to\littlewire_v12.hex
micronucleus will ask you, to plugin the digispark, as you will already know it from the arduino IDE.
You will see the usual dialog, when micronucleus is uploading the littlewire software. This way is necessary, as micronucleus.hex is not an arduino-sketch, but written directly in c.

Additional to the digispark driver Windows needs an libusb-driver. Under Linux/Mac libusb is part of the operating system, so this step is not necessary. If you have trouble with that driver (which is available from littlewire), you can go to the libusb-win32 project, where you find additional tips.

Ok, now we will adapt the Arduino-IDE, so that we can use our ISP programmer, to write programs to core attiny85 chips. This addition we can make in the boards.txt, which is located in the ./hardware/digispark subdirectory of the Arduino-IDE.

We add the following two sections:

attiny85-RESET-enabled.name=attiny85 with Reset enabled (5 Pin)
attiny85-RESET-enabled.upload.maximum_size=8192
attiny85-RESET-enabled.build.mcu=attiny85
attiny85-RESET-enabled.build.f_cpu=16000000L
attiny85-RESET-enabled.build.core=tiny
attiny85-RESET-enabled.upload.using=USBtinyISP
attiny85-RESET-enabled.bootloader.low_fuses=0xf1
attiny85-RESET-enabled.bootloader.high_fuses=0xdf
attiny85-RESET-enabled.bootloader.extended_fuses=0xfe
attiny85-RESET-enabled.bootloader.path=micronucleus
attiny85-RESET-enabled.bootloader.file=micronucleus-1.06-upgrade.hex

attiny85-RESET-disabled.name=attiny85 with Reset disabled (6 Pin!)
attiny85-RESET-disabled.upload.maximum_size=8192
attiny85-RESET-disabled.build.mcu=attiny85
attiny85-RESET-disabled.build.f_cpu=16000000L
attiny85-RESET-disabled.build.core=tiny
attiny85-RESET-disabled.upload.using=USBtinyISP
attiny85-RESET-disabled.bootloader.low_fuses=0xf1
attiny85-RESET-disabled.bootloader.high_fuses=0x5f
attiny85-RESET-disabled.bootloader.extended_fuses=0xfe
attiny85-RESET-disabled.bootloader.path=micronucleus
attiny85-RESET-disabled.bootloader.file=micronucleus-1.06-upgrade.hex

After (Re-)start of the IDE we see under Tools/Board the additional devices. As long, as we use the 5-pin device, we can program each core attiny85 using our digispark-littlewire ISP.

Select under Tools→Board the attiny85 with Reset enabled (5 Pin) from above and under Tools→Programmer USBtinyISP

We are now able uploading programs to connected core attiny85 chips, with the only limitation, that we can’t use PB5, as we need RST for programming. However we are able to use up to 8192 bytes of memory.

As an first test, upload the digispark-start-sketch to the attiny, and because the pins are connected 1:1, the onboard-led of the digispark will start blinking, even when the code is running on the target controller, once you have uploaded the sketch!

We are also able, to make digispark compatible devices from an core attiny85: We still select the 5-pin version of the attiny, the USBtinyISP and select Tools→Burn Bootloader.
After that the bootloader is burned, the chip is an digispark, but still with enabled reset (and therefore disabled PB5).
To make it a full compatible digispark, choose now the 6-pin version of the board, and repeat uploading the boot loader. That step will reset the fuse settings, so reset is disabled.
It will not again upload the boot loader, as uploading the boot-loader is done in two steps by the IDE:
First the IDE sets the fuses according to the configuration, in the next step it will upload the bootloader. So when you choose from the beginning the six pin layout, the chip is unusable, as the reset function gets disabled, but you get no bootloader installed. Check the correct function of the bootloader first, before disabling RESET!

Further you need to be aware, that as soon, as you are uploading another arduino-sketch via USBtinyISP to that device, where you have before installed the micronucleus boot-loader, the bootloader is gone and replaced the the program, you uploaded after it!

To use this chip in the digispark way, you have two possibilities: You can create either an adapter with the zener-diodes and the three resistors as shown in the schematics or use an digispark and cut off the attiny with an sharp knife:

PICTURE here

If you use now the digispark prototype shield kit with the 8pin socket you created before, you can plug the prepared chip into that device, and upload sketches using the digispark-programmer.
After that you can take out the chip and place it in that application, where you need six pins of the attiny, without the influence of the zeners and the pullup resistor.
Once you have created your digispark, and plug it to your PC, you will realize, that it generates trouble with USB device recognition. This is caused by the fact, that there is only the bootloader installed and no program. The bootloader starts the chip, waits the usual 5 seconds for possible programming action and gives control to the non-existent program. That causes the digispark to run into reset. So you should upload a small sketch, like the start-sketch after installing the boot-loader.

The procedure to create an full compatible digispark is:

• Burn Bootloader with 5-pin option and using USBtinyISP as programmer
• Change the extension board with the target-chip to the digispark with removed chip
• Upload start-sketch with “Digispark tiny core” as board, and digispark as programmer (the digispark way)
• When the on-board LED is blinking, go back to the USBtinyISP device, select the 6-pin board and upload the bootloader again (which will not upload, as it changes the reset-function in first step)

Now comes the day, that you have accidently fused some chips with reset-disabled, before the bootloader was installed. Or you killed the bootloader, tried different clock-sources or whatever. In that case there is only one way:
The use of high-voltage programming. High voltage is 12Volt, so there is no risk. The problem is however, that the protocol used for this kind of programming differs from SPI and makes HVSP-programmers more complicated. But knowing, that you need HVSP only in cases, where you have locked the controller down, its again easy: The digispark is as well able, to unlock the doors. For that step follow the recipe of Fuse Resetting in the forum.
With this little extension to the digispark you are able to reset the fuses to values, where ISP and Self-programming is enabled again.