This hardware uses an attiny84 mcu and has an ultra bright rgb LED onboard.

We call this an organic, interactive illumination network. Because the main task is illumination (on clothes or on walls for example), it uses a network topology, it is bio-inspired (or organic) and should interact with humans and the environment.

For this project, I wrote a new Arduino core for the attiny84 chip. And the Arduino IDE was extended in order to support attiny chips. The current implementation is based on Arduino0013.

For example, the jacket you see on our website has 80 luminet nodes attached and you can upload different sketches to it. The sketches are uploaded by a PC running the Arduino software or by using special nodes, the so called vector nodes. The sketch infects the network like a virus, we call this programming by infection. So the same sketch runs on each node and each node has it's own micorcontroller and rgb LED and communicates with four neighbors.

As you can see, the attiny84 (the black square on the right device) is smaller than the atmega168 that is used by the LilyPad Arduino. The white box on the LumiNet node is the ultra bright rgb-LED. You can also see 4 pins in each direction. They are used to connect LumiNet nodes with each other. One of the four pins is Vcc and one pin is GND. The remaining two pins are used for communication.

The three (diagonal) pins on the lower left corner and the three pins on the upper right corner are used for ISP programming when needed. If the jumper is removed, the three pins on the lower left corner can also be used as I/O pins. So LumiNet has 8+3 = 11 I/O pins.

In order to get the attiny84 chip running with the Arduino IDE, some modifications must be made to the source code of the IDE. After this, the IDE has to be recompiled of course.

Based on revision 557 (from March 7th, 2009 - which is Arduino0014), I created a patch that contains the following changes:* Compile .S assembler files in the target directory. Should also work with assembler files in the sketch directory, but this was not tested. Important: use a capital S as your file extension!(Changes in Complier.Java and Target.java)* Burn bootloader using STRG+B shortcut. Select the ISP programmer in the Tools->Burn Bootloader menu and this programmer will be remembered until you change it. (Changes in Editor.java)* Sketches for cores that are based on attiny chips will get uploaded (Changes in AvrdudeUploader.java)* Programming by infection - the upload mechanism using the LumiNet bootloader - is supported (Changes in AvrdudeUplioader.java and new source: LuminetUploader.java)* youboardname.upload.protocol=stk500v2 in boards.txt made some trouble here with an original stk500v2 board, fixed this issue (AvrdudeUploader.java)

1) yes the IDE will be released soon. And I hope to get the LumiNet patches included into the official Arduino release, so you don't need to have two IDEs installed. I will explain all instructions to you, what do you need to know?

2) There are some restrictions I guess. The attiny84 has less pins and no hardware UART for example. But all simple examples can be used. All libraries will be available. At the moment some libraries use code that only compiles on the Arduino atmega chips. Some problems with the Ethernet, Wire and Stepper libraries are still open.

3) The LumiNet nodes have their own bootloader. So every node comes with a preprogrammed bootloader (that supports programming by infection). Burning the bootloader via BitBang was not tested, but if it is possible with the Arduino then I see no reason why it shouldn't work with LumiNet. All ISP pins are available and can be used by any ISP programmer.

1) Well I guess I wasn't completely clear. I do understand most of the instructions and could probably edit the IDE on my own with a little trial and error and research (I've never had to recompile the Arduino IDE before but I assume this wouldn't be any more different than any other programming project I have worked on). However, most of what I do with the Arduino is teaching and kit development, and I'd want something I can give my students that they can then find later without much effort. I think learning how to recompile the IDE is out of the scope of what I am trying to do with them (mostly high school kids). Having the LumiNet patches merge the LumiNet and Arduino branches together is exactly what I need. I'll probably wait till this happens before I start actively working with this.

2) I am glad most of the libraries will be supported. I was aware there would be restrictions, but I am glad they aren't as drastic as I thought they would be.

3) What is programming by infection? Also how can the LumiNet be bootloaded by bit-banging without a UART?

And a few more questions

1) Is the power saving drastically better than the Atmega? I seem to be losing power way too quickly for battery powered applications on my Atmega based solutions even on sleep mode.

2) I don't see I2C capabilites on teh Attiny85 data sheets. is it possible to work with I2C and OneWire?

1) Good to hear that someone actually needs my modifications I really hope that most of my patches qualify for a future release of the Arduino IDE. But there will be a release of my IDE within the next 6 weeks.

3) programming by infection is a multi-hop reprogramming method we created for LumiNet. The idea behind LumiNet is that you don't have a single controller (like in most Arduino projects) but many (hundreds) of nodes with their own microcontroller. You could disassemble the network and reprogram every node via isp or UART. But what we do is different: a special node (called vector node) gets programmed via (software) UART and it stores the program code. Then this (vector) node is connected to the network and the payload propagates from one node to all its neighbors... like a virus. In that way the network remains unchanged and new program code can be uploaded to all nodes in a single step. This is especially handy for mobile applications (e.g. wearable computing) when you don't have a PC around you but you have 10 preprogrammed nodes with different payload. So programmin by infection is a combination of a program code dissemination protocol and a bootloader.

I have to compare power consumption. I will provide information about that in the next days.

LumiNet uses the attiny84 chip. This chip has limited I2C capabilities (the same is true for the attiny85).But if you look in the datasheet in 14.3.4 Two-wire Mode you can see, that the USI of the attiny can do I2C (TWI) in hardware. How important is I2C to your projects? Do you need I2C master or a slave functionality?

I did not test OneWire yet because I have no such devices. But I downloaded the lib from here:http://www.arduino.cc/playground/Learning/OneWireand the example compiles without problems. A short look in the sources tells me: this should work without any problems with LumiNet.

Oh I forgot the bit bang question... the attiny84 has no hardware UART. But for ISP you don't need a hardware UART. What you need is a ISP interface. And the six ISP pins are available (the diagonal pins you can see on the photo) so you can connect any ISP programmer to them, even a bit bang device that can be a FTDI chip like the one that is used on the Arduino. So you can use the Arduino as an ISP for LumiNet in theory. I have never tried this but it should work just as fine as with an Arduino. Just to make sure we are talking about the same thing, here is a link:

http://www.geocities.jp/arduino_diecimila/bootloader/index_en.html

The picture (of the circuit) at the bottom of the page shows how to connect the 4 pins of the X3 connector of the Arduino in Order to convert the FTDI chip into a bit bang ISP programmer (that can be used with LumiNet nodes)

With this ISP programmer you can upload the bootloader to the LumiNet node. If requested I could modify the IDE so that the sketch can be uploaded via ISP (I use this for tests here but it will get removed with the official release because programming by infection is the way sketches should be uploaded)

Doesn't the first node have to be bootloaded to enable software UART? Don't you have to program something like the software serial library first into the node? Wouldn't you have to use ICSP?

Also, the diagram you linked to is exactly what I am talking about. I would be very interested in programming the device this way. Also, by programming by infection, all the nodes have the same code right? Are the nodes self aware of each other?

Programming by infection is an interesting concept, but I don't think it will suit my kit development purposes (though I have an idea for halloween where this could be quite interesting).

I2C compatibility would be nice, however I understand the limitations. I was mostly looking for Master capability.

I'm glad this project is going so well. I've wanted to use the Attiny for some time with the Arduino IDE.

All nodes once have to be programmed by ISP just like any Arduino because a bootloader has to be present on each device. The bootloader for the attiny84 will be published together with the IDE. We use AVR dragon and stk500 ISP programmers but I will test the FTDI bit bang in the next weeks as well.

I wrote a software UART based on an Atmel Application node that allows serial communication in all four directions. This software UART is also used by the programming by infection loader. Of course this assembler routines are wrapped to C and C++ and this is the reason why I added assembler support to the Arduino IDE.

Programming by infection uploads the same code to all nodes. There is one exception: Sensor nodes. These nodes have to be programmed by hand since they read sensor hardware and propagate the values into the network. Overwriting the program code of sensor nodes would destroy them

The nodes are not self aware of each other. They only know in which direction they have a direct neighbor. But it is possible to use dynamic addresses at the application layer. This is a task the application designer has to handle. I will add support if needed but the basic idea is to use bio-inspired algorithms. I am not sure if a cell in the arm of our body is aware of a cell in the finger of our body... one might think of LumiNet as a neural network but of course the hardware is not limited to that idea.

An I2C master is not a problem with LumiNet. The software UART is running great and this is the more demanding protocol. I guess I will write a I2C library that can be called from C and C++ when the project is finished. Or you can look out for exisiting software I2C libs, they should work on LumiNet or can be easily ported.

Can you explain what your main interest in my IDE patches is? Do you only need the attiny support or are there also other parts that you find interesting?

Yeah I thought that each cip would have to be bootloaded first, I just wanted to confirm that. Thx for taking a look at the bit bang technique for me, this is how I would like to program the chip

I'm glad you got the software serial working out fine , and that I2C will not be a problem.

In terms of my use for this project, the attiny support is the most attractive feature for me. I've wanted to use them to teach simple stuff to kids due to their smaller form factor and lower power consumption

A neural netowrk seems interesting and I would love to work with something lie that, but I don't think I can afford to! However, if I can successfully get working with the Attiny and get fairly comfortable with it I do have a plan to develop a halloween constume kit with it.

I guess the FTDI chip of the Diecimila consumes about 8,5mA and I don't know how to set this chip to sleep mode...

LumiNet can't run at 16MHz so there are no 16MHz values for LumiNet and it is hard to compare the 16MHz Arduino values with the 8MHz LumiNet values. But what I can say is that operating at 3.6V at 1MHz is a good choice for battery powered applications