Go Down

Topic: LumiNet (based on attiny84) (Read 61 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

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.

Go Up