Go Down

Topic: LumiNet (based on attiny84) (Read 66284 times) previous topic - next topic

Osgeld

#255
Sep 19, 2010, 07:25 am Last Edit: Sep 19, 2010, 07:27 am by Osgeld Reason: 1
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
http://arduino.cc/forum/index.php?action=unread;boards=2,3,4,5,67,6,7,8,9,10,11,66,12,13,15,14,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30,86,87,89,1;ALL

bill2009

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.

Coding Badly

Quote
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?

Quote
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.

bill2009

Quote
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.

Quote
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?

bill2009

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.

Coding Badly

Quote
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.

Quote
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.

Quote
By the way, the core seems fine

Glad to hear!

Quote
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.

Quote
crossloading it thru avr studio and my dragon works fine

That might get tedious!

Quote
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.

Quote
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!

bill2009

Quote

Quote

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.

Coding Badly

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

AWOL and Grumpy Mike would scold you for that!   ;)

Quote
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?

bill2009

Quote
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.  

mellis

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: http://github.com/cmaglie/Arduino/.  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.

bill2009

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

bohne

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.
http://www.dorkbot.de
http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1236434254
http://www.luminet.cc

macsimski

nice one mellis! do you by chance know the ide searches for includes? i am still stuck with the attiny85 port regarding adapting libraries. i can adapt a library, but i have no idea if it its possible to have the ide search in the hardware dir of the specific processor. i can see a dir layout like

boards.txt
bootloaders/
cores/
programmers.txt
libraries/
--
"We're all in this together..."

bHogan

I couldn't tell from this thread if I2C was supported or not. However, since the ATtiny uses USI (Universal Serial Interface) for I2C and SPI, I didn't think so.

So I dug around and found some code for a USI I2C Master and adapted it for the Arduino IDE.

You can download it here . . .
http://dl.dropbox.com/u/3572198/USI_TWI_Master.zip

Put it in Libraries folder under your Sketchbook.
It relies on the the ATtiny core files from here.

I have included an example in the "examples" folder with an ATtiny85 reading the temperature from a DS1621. It's working fine for me. There is also setup info in the example header.

I'm sure improvements can be made, however you may want to wait a bit. Soon I will post USI I2C Slave code, and it would be nice if the two libs were combined.
"Data is not information, information is not knowledge, knowledge is not understanding, understanding is not wisdom."
~ Clifford Stoll

moustic

your link doesn't work anymore. can you post it again ?

Go Up