Digistump Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
======Beginners Guide to Extended Programming Attinys with Digispark======

//**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 store binary program code into an AVR controller:  ISP, HVSP, and Self-Programming.  When you start playing around with an digispark, you are using the self-programming feature of the Attiny.
=====Self-Programming the Attiny – or the digispark way of life=====
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 [[https://github.com/Bluebie/micronucleus-t85|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 is that you need no other hardware tool to program a digispark as you would 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 facilitate this special way programming the digispark, digistump has patched the IDE by adding a custom version of avrdude (a program which is mostly used in the arduino world). The digistump's custom version of avrdude is an wrapper, deciding to call either the original avrdude (for everything, which is not a digispark) or micronucleus in case of the digispark.
There are however some drawbacks:

The emulation of a USB-interface affects the use of 2 I/O pins.  P3 (analog3) and P4 (analog2):  Both are regulated with a Zener-diode, which limits the voltage on those two pins to a max of 3.6V, affecting some uses like analogRead() or high-levels for digitalWrite().  P3 also has a 1.5K pullup-resistor, creating even more problems for this kind of usage.

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

====Small Introduction to pin-names====
//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.
 
=====In-System Programming – The way most other attinys are loaded=====
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 [[http://www.atmel.com/images/atmel-2521-avr-hardware-design-considerations_application-note_avr042.pdfAVRs | 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.

===Interjection: Fuses===
//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 [[http://littlewire.cc/|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 [[http://digistump.com/products/2|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:\\
{{:digispark:tutorials:backside-extension.jpg?300|Backside}}{{:digispark:tutorials:frontside-extension.jpg?300|Frontside}}\\
And so it looks, when the shield is connected to the digispark:\\
{{:digispark:tutorials:isp-02.jpg?300|}}{{:digispark:tutorials:isp-03.jpg?300|}}


Your tiny IS-Programmer is ready to run!

=====Using littlewire as USBtinyISP=====
Now go to [[http://digistump.com/board/index.php/topic,160.0.html|bluebies Tutorial in the forum]], where she explains, how you can install littlewire on your digispark.

====A short summary of the steps====
===Locate the micronucleus binary on your PC:===
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//
 
===Download the latest littlewire binary===
You can download the ready compiled binary from the [[http://littlewire.cc/resources/littlewire_v12.hex|littlewire webpage]], currently it is v12
===Open a command window===
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.
===Under Windows you need to install an libusb driver===
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 [[http://sourceforge.net/apps/trac/libusb-win32/wiki|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:
<file>
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
</file>
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!

====Creating Digispark Compatible Clones====
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 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 for example with an old USB-cable (following the schematics from littlewire or digispark)

{{ :digispark:tutorials:zener-adapter.jpg?300 |USB Adapter build from old mouse-cable}} 

or you use an digispark and cut off the attiny with an sharp knife (which is a wonderful second life for an digispark, where the controller is already dead):

{{ :digispark:tutorials:removed-attiny.jpg?300 |Digispark with removed attiny}}

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. That is the reason, why you should connect all six pins of the extension-shield, when you not are planning to build two of this kind of shields.


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.\\
One device with six lines connected and the attiny cut off on the digispark besides the digispark littlewire ISP

{{ :digispark:tutorials:both-devices.jpg?300 |}}

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)

====High Voltage Programming or how 12V rescue chips====
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 [[http://digistump.com/board/index.php/topic,1039.0.html|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.

{{ :digispark:tutorials:fuse-resetter.jpg?300 |}}
Digistump Wiki

User Tools

Site Tools

Page Tools
