LumiNet (based on attiny84)

since your using a soft serial in this, is it safe to assume that there might be serial functions in future releases ?

Very good question, Osgeld. I have a few ideas on how to address Serial on tinies that don't have hardware support. I'm hoping there's some dicussion around the ideas. Would you mind if we move to a more appropriate section like Hardware / Development?

Here is the alpha bootloader
http://85.12.32.240/~superkoe/arduino/attiny84loader.rar

The bootloader works on the first upload with the IDE
Second time upload the chip goes to the bootloader, but fails halfway uploading.

Everything is in ASM so its very hard to debug, this project is on a dead end for me.

I will look to the optiboot, and see if I am more successful.

About serial support, its not very hard to implement. There already some nice soft serials library around, it just has to be changed for the attiny84.

The serial used for the bootloader works aswell, but it doesn't have buffers etc, so you can miss incoming characters.

edit
I just see optiboot already is made support for the attiny84
Lets see if it works 2 :slight_smile:

Let's open a new googlecode project for all attiny cores

Done...
http://code.google.com/p/arduino-tiny

I'll try to get the '84 core source files uploaded this week.

But I also want to make sure that the modified LumiNet IDEs can be found there, because attiny support and LumiNet belong together.

Is this the latest modified Windows IDE...
http://hci.rwth-aachen.de/tiki-download_wiki_attachment.php?attId=759&page=luminet

Which version of the IDE is it based on?

Does the ZIP file contain a complete IDE or just the things that you modified?

should it be possible to have the core given in this link :
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.ArduinoATtiny4585
added on the google project ??

should it be possible to have the core given in this link :
http://hlt.media.mit.edu/wiki/pmwiki.php?n=Main.ArduinoATtiny4585
added on the google project ??

Yes.

My goals are...

  1. Get the Google Code site started (done)

  2. Make SuperCow's ATtiny84 Core as similar as possible to the Arduino 0019 Core (minus Serial). This should provide a Tiny Core that has almost identical performance and functionality as the 0019 core.

  3. Integrate the ATtiny85 Core (from the link you posted) with the ATtiny84 Core. The end result will be a single Tiny Core that supports 84 and 85 processors.

  4. Integrate René Bohne's ATtiny2313 Core with the Tiny Core. The end result will be a single Tiny Core that supports 2313, 84, and 85 processors.

  5. Branch the Tiny Core so performance and memory optimizations (like digital*Fast and tone-to-pin output) can be applied.

Any participation (including testing) is welcome!

My tinyport was based on Bohne's luminet, but with clean core files from 0017. Later i ported it to 0018.
Now we have 0019, and I would have ported it to 0019.

Few month ago i put in a alot of time making a bootloader for it.
I have started again with the bootloader, using optiboot, or using mine with some tricks from optiboot.

Few month ago i put in a alot of time making a bootloader for it.
I have started again with the bootloader, using optiboot, or using mine with some tricks from optiboot.

I'm curious. Obviously, René Bohne needs a bootloader for his work. Does anyone else? Are there people who want to program a Tiny who don't already have an Arduino or an ICSP?

I have always used my arduino to program the tiny, but! if I were to sit down and make an arduino like board that would sit on my desk and be used for more for daily experments I would like to use one, less clutter and fragile connections

but on the other hand that is why I have an arduino, and most of my stuff is hashed out on it first, and then brought over to the tiny when my application calls for such a thing

or in other words 50/50

I do appreciate everyone's hard work on these chips, the tiny 84 is great for many applications where the 168/328 is overkill and physically too large, it fills a nice space

re the bootloader:
I have and use ICSP programmers for the tinies I develop but, especially when breadboarding , I include a 6 pin straight header for hooking up a USB-ttl serial cable. This is great for debugging.

Presumably, to be arduino-like, a boot loader could be automatically grafted on to the sketch(like init) and get a shot at the serial before the application started.

I think that would be convenient. I also imagine it would be trouble-prone but I guess that would depend on the implementation.

I have and use ICSP programmers for the tinies I develop but, especially when breadboarding , I include a 6 pin straight header for hooking up a USB-ttl serial cable. This is great for debugging.

Which software do you use on the 84? NewSoftSerial? SoftwareSerial? Something else?

Presumably, to be arduino-like, a boot loader could be automatically grafted on to the sketch(like init) and get a shot at the serial before the application started.

That would be nice. The biggest issue is the bootloader code overwriting itself. There are two potential solutions...

  1. Always place the bootloader code at a fixed location in the executable image. This may not be possible.

  2. Make the bootloader so it moves itself to one end of the Flash while the other end is programmed. This would double the wear on parts of the Flash and would be a bit complicated but would very likely work.

Which software do you use on the 84? NewSoftSerial? SoftwareSerial? Something else?

I've been using the basic SoftwareSerial but since this fine new core supports NewSoftSerial I'm going to try that as soon as I get the hardware working.

That would be nice. The biggest issue is the bootloader code overwriting itself. There are two potential solutions...

  1. Always place the bootloader code at a fixed location in the executable image. This may not be possible.

  2. Make the bootloader so it moves itself to one end of the Flash while the other end is programmed. This would double the wear on parts of the Flash and would be a bit complicated but would very likely work.

I naively thought we could just tell the compiler the bootloader code was to be loaded at the end of the flash- there's usually an assembly construct for that kind of thing isn't there?

By the way, the core seems fine. Running my pololu programmer from the ide is giving me a content mismatch but i bet that's my fingers.

crossloading it thru avr studio and my dragon works fine.

see, the bootloader would be a blessing today!

There's actually something worth thinking about there: with our own bootloader we know exactly who's doing what. with an arbitrary icsp programming set up there's more variation at the user end and maybe more bits to get wrong.

I've been using the basic SoftwareSerial but since this fine new core supports NewSoftSerial I'm going to try that as soon as I get the hardware working.

I could not get SoftwareSerial to work. Even at 2400 baud it still sent a considerable amount of garbage. I suspect it's more sensitive to the clock frequency.

I naively thought we could just tell the compiler the bootloader code was to be loaded at the end of the flash- there's usually an assembly construct for that kind of thing isn't there?

Huh. I hadn't thought of that. I suspect you're right.

By the way, the core seems fine

Glad to hear!

Running my pololu programmer from the ide is giving me a content mismatch but i bet that's my fingers

I sometimes get a similar error when there's too much load on a pin (a piezo is my source of pain). Programming works. Verifying doesn't. I have no idea why one would work but not the other. If there's nothing else connected to the processor, my Pololu has been very reliable.

crossloading it thru avr studio and my dragon works fine

That might get tedious!

see, the bootloader would be a blessing today!

You're preaching to the choir! Unfortunately, it will be a considerable amount of time before I can get to it. I believe René Bohne and Peter Knight are trying to get Optiboot to work with the ATtiny84. They are far better equipped to build the bootloader than I am.

There's actually something worth thinking about there: with our own bootloader we know exactly who's doing what. with an arbitrary icsp programming set up there's more variation at the user end and maybe more bits to get wrong.

That definately seems to be true!

Running my pololu programmer from the ide is giving me a content mismatch but i bet that's my fingers

I sometimes get a similar error when there's too much load on a pin (a piezo is my source of pain). Programming works. Verifying doesn't. I have no idea why one would work but not the other. If there's nothing else connected to the processor, my Pololu has been very reliable.

My problem was simpler - the programmer ground wasn't connected!

The pololu is great except that it's not set up to power the target. I think for the most arduino-like experience you'd want a programmer that would at least optionally provide target power without a lot of fuss.

My problem was simpler - the programmer ground wasn't connected!

AWOL and Grumpy Mike would scold you for that! :wink:

The pololu is great except that it's not set up to power the target. I think for the most arduino-like experience you'd want a programmer that would at least optionally provide target power without a lot of fuss.

The one I have carries USB power out on the VBUS pin. I think there's a 350ma limit (probably the Pololu's power requirement from 500ma). Your's doesn't have that?

The one I have carries USB power out on the VBUS pin. I think there's a 350ma limit (probably the Pololu's power requirement from 500ma). Your's doesn't have that?

sure, so i had an initial hour of failure while I figured that out and now I have an extra clip-on lead carrying the power. I may jumper it at the programmer so the icsp does the whole job. It's moot for the smallest chps because you pretty well have to remove the icsp clip before running your program.

We're also trying to apply patches to the Arduino core that would make it portable across processors. Mark Sproul has written a bunch of them that Christian Maglie is helping me integrate. See: GitHub - cmaglie/Arduino: open-source electronics prototyping platform. If anyone can try these on the ATtiny45 and 84, that would be great. Eventually, we'd like to make it so you only have to write a single file (e.g. pins_arduino.c) to port the core to another processor.

i'd be happy to try it but it's not obvious how.

David, that sounds interesting! It is very hard to keep up with your changes.

I wanted to have support for LumiNet and attiny from the first day on. My changes never made it into the core and this thread was the only support for people who wanted to get their attiny running with the Arduino.

I did not have a look at the git (because I still use svn), but I want to find time for that soon.