So your problem is that you are trying to write some code to run on, say, an ATtiny85 that is acting as an I2C slave - perhaps to control a servo or some NeoPixels. Without the cost of JTAG how do you debug the code?

We came up with the following solution - not 'rocket science' and 'obvious maybe' when you think about it.

Our problem was to write code for an ATTiny85 which would listen on the I2C bus and control a string of high power LEDs. The ATtiny85 only has a USI - not a proper UART-  so its hard to dump any debug messages plus its easy to bloat the code and run out of space on this small chip. So how to do it?

1. Use a bigger board which has various 'on board' gadgets or multiple UARTs like the Axon or, better, the Axon II.
2. Split the resources of the board in half (mentally - not with a hacksaw!).
3. One half (acting as the Master) is connected to your favourite computer terminal software to accept keyboard commands and send back messages to be displayed. It also uses two pins to define a software I2C bus.
4. The other half (acting as the Slave) has the hardware I2C bus, the IO pins to talk to the LEDs, and either another UART for sending debug messages or the 8 Segment LED built onto the Axon II board.
5. Now all we need to do is to connect the two I2C ports together as if they were seperate boards - you will need to add pullups from both the SDA and SCL lines to 5v using, say, 4k7 resistors.
6. Create your project with each of these options set up. Your main loop should then have the code for both the master and the slave.
7. Test and debug all one board !
8. Once you've got it working. Create a new project for the ATtiny85 and only add the LED devices. Copy and paste the slave code in and remove any debugging stuff. 
9. Create a new project for the Axon and only add the devices used by the master. Copy and paste the master code in.
10. Change the two I2C wires so that they connect the I2Cpins on the different boards. You will either need to continue using the external pullups or, alternatively, the master can now use the hardware I2C in which case Studio will tell you whether you need the external pullups or not.

And there you go.

WebbotLib Studio makes it so easy due to the fact that it generates and uses the correct code (believe me - it is different) for the ATtiny85 once moved off the Axon. No need to rewrite anything.

New documentation is being released for WebbotLib Studio.This is now based around DoxyGen.

Why?

1. The implementation of WebbotLib has been modified compared with previous releases. A (work in progress - very early) version of the WebbotLib for Studio documentation is available here.

2. Other members of the WebbotLib community (it could be you!) can publish work to be shared within the community. Obviously the contributors, not me!, need to produce any documentation as part of that publishing process. DoxyGen seems like a 'recognised' ie familiar way of doing this. But that's the next step - and I need to document how other contributors can document...

 Version 1.08 has been released with the following changes:-

• Board Designer allows you to set the default programmer to use for each board. The settings are then used by, or can be overriden by, individual projects, The settings are then remembered and re-used each time you flash your project.
• A few improvements, fixes, and extra logging when trying to create your own upload site for publishing your work
• The memory bars showing how much space has been used by your project now use a different background colour to make it easier to see the percentage used
• Shaved some extra bytes from the project size by only including timer definitions if you, as an advanced user, start modifying timers and compare channels on the fly.
• Some re-working of the I2C slave code for the ATtiny85

The Atmel AVRISP MKII programmer support is now more robust.

Reworked the 'Color' library to avoid bringing in the floating point library when it wasn't needed.

Version 1.06 has been released and includes:-

• Chip programming via AVRISP MKII, FBoot and my own bootloader WLSBoot
• Fixed a memory leak when reading executable (ELF) files to show the amount of Flash, Data, EEPROM memory required

Note that using the AVRISP MKII comes in two different flavours:-

1. If you are on Windows and have a working copy of AvrStudio 6 running then you should see an option for "AVRISP MKII (Atmel AVR Studio 6.0)" when trying to flash. Any errors when using this option probably mean that AvrStudio or the Jungo USB drivers it uses are not properly configured.
2. You should always see an option for "AVRISP MKII (avrdude)" regardless of what operating system you are using. Unix users may need to make sure avrdude is loaded by running "sudo apt-get install avrdude". If programming fails with a message like 'usbdev_open(): did not find any USB device "usb"' then avrdude cannot see your AVRISP MKII. On Windows you can install a usb filter by downloading 'libusb-win32-bin-1.2.6.0.zip' from the sourceforge libusb-win32 project - unzip the file - and run the file 'bin\inf-wizard.exe' with your AVRISP MKII plugged in. This should find your programmer and create a Windows INF file to install a driver for it. avrdude should then be happy. Word of caution: if you have AvrStudio installed as well then libusb may kill the Jungo drivers meaning AvrStudio no longer works! Bah - why did Atmel choose to buy those stupid Jungo drivers when libusb is free ! You can uninstall libusb and get the Jungo drivers running again but best practice is: if you have AvrStudio installed then use "AVRISP MKII (Atmel AVR Studio 6.0)" otherwise install libusb and then use "AVRISP MKII (avrdude)"

A new version of Downloader has been made.

This fixes a problem on non-Windows machines where the 'Run' button failed to launch some applications. (Tested on Ubuntu and Debian).

It also contains a link for WebbotLib Studio