Attiny25/45/85 FW Development Thread

1901 posts / 0 new
Last post
DavidEF
DavidEF's picture
Offline
Last seen: 2 hours 40 min ago
Joined: 06/05/2014 - 06:00
Posts: 4988
Location: Salisbury, North Carolina, USA
ImA4Wheelr wrote:
Perhaps a hidden mode that lets the user click when the light gets too hot.  That way, no calibration is needed.  The loop switching from LVP to Temp would be by-passed and just ADC4 would be active during the user :“calibration”.  Boy, it seems that extra 1K of memory can get used up fast with new code like this.

It’s already possible to have that functionality with a turbo timer – without a temp sensor. If using the temp sensor, it should be easier than this (for the end user).

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 9 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7393
Location: SC

^ Great.  So some code already is available to start out with.  Good to hear.

I think the FW could have a default setting that would have margin for the -+10 degrees C and thermal lag for heat to get to a typical MCU.  That way there is some safety measure in place in case the user doesn't calibrate.  I think user calibration is pretty critical as each light is so different and as each person will have their own level of heat tolerance they are comfortable with.

". . . You realize that wasn't really a loss for me in Africa — it was a gain that I didn't appreciate."

- George Foreman 2017

DavidEF
DavidEF's picture
Offline
Last seen: 2 hours 40 min ago
Joined: 06/05/2014 - 06:00
Posts: 4988
Location: Salisbury, North Carolina, USA

ImA4Wheelr wrote:

^ Great.  So some code already is available to start out with.  Good to hear.

I think the FW could have a default setting that would have margin for the -+10 degrees C and thermal lag for heat to get to a typical MCU.  That way there is some safety measure in place in case the user doesn’t calibrate.  I think user calibration is pretty critical as each light is so different and as each person will have their own level of heat tolerance they are comfortable with.


Yeah, but my point is that if you are doing a user calibration, you don’t need the temp sensor at all, because a turbo timer will do fine. Well, I could understand user calibration of a temp sensor if the user had multiple different cells that they might use with that light. One cell gets it hot at 2 minutes, but a different cell takes 4 minutes to get it to the same temp, etc.

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

Well I'm think'n/hoping someone could chime in on the best way to get a somewhat accurate temp measurement. I'll ask my EE buddy here today. Think Richard has a pretty good external temp sensor working. led4power would probably have good ideas too. Ideally having the calib built-in to the firmware. Wait.. I know someone did this already. HHmm.... Maybe Everett, or led4power? Dunno, but I would think the calib would be fairly consistent in the same design driver. Of course the effect on the temp of the MCU will vary greatly from a light's design I would suspect. MCU temp of course is important, but so is LED temp. Still like the idea proposed to build a MCPCB with a thermal sensor mounting spot next to the LED.

 

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 9 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7393
Location: SC

^ The problem with calibrating is that it will require every chip to be calibrated while there are bigger issues such as how long the heat takes to get to the MCU in any particular light.  Another issue is each user will have different heat tolerance levels.  I think UI adjustable is the way to go.

I like the idea of temp sensing at the LED too, but that uses up a MCU pin and requires a new driver board from the ones we are using.

". . . You realize that wasn't really a loss for me in Africa — it was a gain that I didn't appreciate."

- George Foreman 2017

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 9 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7393
Location: SC

DavidEF wrote:

Yeah, but my point is that if you are doing a user calibration, you don’t need the temp sensor at all, because a turbo timer will do fine. Well, I could understand user calibration of a temp sensor if the user had multiple different cells that they might use with that light. One cell gets it hot at 2 minutes, but a different cell takes 4 minutes to get it to the same temp, etc.

Turbo time out is a make shift solution.  Things like environmental temperature changes, how hot the light is already from usage, whether the light is in hand or accidentally turned on in a container all are factors turbo timeout doesn't really address.

". . . You realize that wasn't really a loss for me in Africa — it was a gain that I didn't appreciate."

- George Foreman 2017

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

Ohh - +1. I wasn't thinking/understanding - if you do a UI calibration then you are right - turn the light ON hi til the heat gets uncomfortable for the user, click, then record whatever the A-D reading is at that time, and use that value as your trigger point.

There's no need to know what the temperature is. It's not perfect of course, because under cooler air conditions, maybe the MCU hits the trigger point before the head gets hot, or in the calibration process, the MCU may not be heating up as fast as the outer body, so the trigger point might get set lower than you'd like in other conditions. But whatever the downsides are, definitely worth experimenting with, and should still be better than a turbo timeout. This all sounds familiar - someone did this already - Richard, Dr. Jones, someone... Wish I could recall where I saw this posted - maybe it was only discussed and not implemented, not sure.

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 9 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7393
Location: SC

^ You got it.  And it would be great if the current could continue to step down if the light continues to not adequately cool down.  That would be great for situations were a high power light turns on in a gym bag.  If the light is insulated, it may still continue to escalate in temp even on the next mode down from High.  That would make is much better than turbo timeout.

I agree about not being perfect, but it's progress.  The better the user thermally connects the MCU to the host, the better it will work.  I'm hoping that the OSH Park board I'm trying to design will help some with that.

". . . You realize that wasn't really a loss for me in Africa — it was a gain that I didn't appreciate."

- George Foreman 2017

DavidEF
DavidEF's picture
Offline
Last seen: 2 hours 40 min ago
Joined: 06/05/2014 - 06:00
Posts: 4988
Location: Salisbury, North Carolina, USA

ImA4Wheelr wrote:

^ You got it.  And it would be great if the current could continue to step down if the light continues to not adequately cool down.  That would be great for situations were a high power light turns on in a gym bag.  If the light is insulated, it may still continue to escalate in temp even on the next mode down from High.  That would make is much better than turbo timeout.

I agree about not being perfect, but it’s progress.  The better the user thermally connects the MCU to the host, the better it will work.  I’m hoping that the OSH Park board I’m trying to design will help some with that.


Now I understand better. I wasn’t accounting for all potential high-heat situations. I’m really looking forward to what you guys come up with! :bigsmile:

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

I'm interested in trying to get the temp sensor to work - I'll work on it this weekend. I'll attempt to add a UI into the eswitch firmware to support the calibration. I didn't swap 45's yet - 2nd one is dead now. Wonder if something flaky about my setup - dunno what's causing the bricking of the 45's. I have 25's and 85's on the way from Mouser, so I'll see if they are any different.

bugsy36
bugsy36's picture
Offline
Last seen: 9 months 3 weeks ago
Joined: 07/11/2014 - 18:15
Posts: 2475
Location: Florida USA

If I may....and feel free to tell me to shut up. An auto sensing temp monitor is great...and welcomed..BUT..just making this thing work and having all that extra space available is great thing. If you guys feel the same functionality of the 13 is already there...hell..rock and roll. Smile

It's the simple things that we take for granted that cost us the most

Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 9 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7393
Location: SC

^  Yes, Tom E has already got his version of Star Momentary to full 13a functionality plus new features his previous version didn't have.

I personally think temp sensing is way overdue.  We are building beasts these days that can be dangerous at times.  This MCU with some programming talent won't make them completely safe, but it will make them a bit safer.  Users will still have to exercise caution when using these lights, but at least a lapse in focus at the wrong time might be compensated by better thermal protection.

Tom E wrote:

I'm interested in trying to get the temp sensor to work - I'll work on it this weekend. I'll attempt to add a UI into the eswitch firmware to support the calibration.

This sounds like a very big challenge to do.  Seems it will take the FW to a new level of complexity.  Best wishes on the endeavor.  I wish I had the skill to assist.  I have a vague idea on the logic I would want, but turning that into code is another story.  I can help with testing when you get to that point.

". . . You realize that wasn't really a loss for me in Africa — it was a gain that I didn't appreciate."

- George Foreman 2017

led4power
led4power's picture
Offline
Last seen: 7 hours 3 min ago
Joined: 12/29/2012 - 09:48
Posts: 609
Location: Croatia,EU

One important thing is driver's self heating,and it can course large errors.This is why LD-2 has external temp. sensor for flashlight temperature measurement and internal sensor is used for driver overheat protection.DD driver doesn't generate as much heat as linear(extra heat is generated in LED),but at for example at 10Amps(triple or similar setup),dissipated power in driver (let's say with 5mOhm resistance) would be 10^2*0.005=0.5Watts which is enough to increase driver PCB temperature by 10-15C in host without silicone cubes or similar stuff for better thermal conduction.

Useful document about internal temp. "indicator"(PIC but it's probably similar to atmel):

http://ww1.microchip.com/downloads/en/AppNotes/01333A.pdf

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 9 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7393
Location: SC

^ Very valid point led4power.

Been trying to design a OSH Park board that could be used to air wire an Attiny 13a, 25, 45, or 85 to an non-attiny based driver.  The main purposes of the board are as follows:

  • Make it easier to swap in an Attiny MCU via airwires.
  • Protect the MCU pins from breakage by securing to pcb board via solder
  • Facilitate future FW flashes by keeping wires off the MCU pins
  • Help build a thermal path to the flashlight body for faster thermal response

It's taking me a lot of time because I am not handy with using Eagle yet.  It still has a lot of problems.

The left picture is the top of the PCB with the Red areas representing were copper will be poured. The board will have a ground plane that covers the whole top of the board.  This is to help facilitate a better thermal path to the flight body  One could solder a copper strap or wire from the ground plane to the edge of the slaved driver. The copper strap could even go under the MCU for more effective contact.

The right picture below is the bottom of the board.  The Blue areas represent where copper will be poured.  The air wires can be attached all kinds of ways.  Generally, one would probably use the Blue pads and route all the wires downward off the board.  The vias can be used to help better mechanically secure the wires.  There are pads so that one could add LVP resistors (R1 & R2) and a pad for an OTC capacitor.

Here is kind of an example.  The airwired board in the below picture has an Attiny13a attached to the other side of it.

". . . You realize that wasn't really a loss for me in Africa — it was a gain that I didn't appreciate."

- George Foreman 2017

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

Is anyone else having the same problem I'm having, in re-programming the 45/85 - bricking them? I just tried an 85 and downloaded once fine, then tried the download immediately again, without reconnecting anything, and it's bricked now. The 45's lasted a while for a few downloads, and even worked fine with back to back downloads. I think what happens is the erasing works, and the programming fails, leaving the part useless.

This is becoming way too much a PIA - I can't get anything done. I'm looking into AVRDUDE now.

DEL
DEL's picture
Offline
Last seen: 13 hours 46 min ago
Joined: 06/28/2015 - 08:35
Posts: 534
Location: Canada
Tom E wrote:

Is anyone else having the same problem I’m having, in re-programming the 45/85 – bricking them? I just tried an 85 and downloaded once fine, then tried the download immediately again, without reconnecting anything, and it’s bricked now. The 45’s lasted a while for a few downloads, and even worked fine with back to back downloads. I think what happens is the erasing works, and the programming fails, leaving the part useless.

This is becoming way too much a PIA – I can’t get anything done. I’m looking into AVRDUDE now.

I am no expert by any means, but the -B option, set > 4, makes flashing stable for me when using an usbasp:

E.g.:

avrdude -c usbasp -p t13 -u -B 10 -Uflash:w:edc.hex -Ulfuse:w:0x79:m -Uhfuse:w:0xed:m
Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

Thanks! I'll try anything - very desperate. I'm gonna be out of the 18 MCU's I have, soon, at this rate.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 3 hours 51 min ago
Joined: 01/12/2013 - 14:40
Posts: 6057
Location: (469219) 2016 HO3

I need to get some FET+1 drivers with attiny25v/85v on them. I’m not sure I can swap the MCU on an existing board, but I have lots of ideas for better firmware on these better controllers.

DavidEF
DavidEF's picture
Offline
Last seen: 2 hours 40 min ago
Joined: 06/05/2014 - 06:00
Posts: 4988
Location: Salisbury, North Carolina, USA

ToyKeeper wrote:
I need to get some FET+1 drivers with attiny25v/85v on them. I’m not sure I can swap the MCU on an existing board, but I have lots of ideas for better firmware on these better controllers.

PLEASE! Somebody send TK a driver board! PLEASE! Party

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

TK - you need to order the proper P/N, but there is a 25V that match's the footprint precisely. The 45's and 85's are only available in a wider footprint, so you can bend or cut the legs. If done properly, they still can be programmed in place. Right now I have 45's, 25V's, and 85V's. I should post some pics. The wight 22mm FET+1 driver though fits the bigger footprint perfectly - it has extension pads for pins #1-4 and they match up perfect for the larger footprint.

The 25/45/85 Atmel datasheet has the info in sections 25 and 26. The "S8S1" package matches the 13A. And of course the "V" versions are the ones you want (10 Mhz max).

I'd send you some, but the download problems I'm having are a killer. Constantly removing/reflowing another MCU.... ugh. Gotta get this figured out.

Update: Hhmm, the 45's and 85v I thought I bricked I can actually still program. Just tried it with the -B 10 option, but also without the -B 10 option. I'm putting them in the clip bare. Wonder if there's a difference having them reflowed on a board? Maybe just bad contacts with the clip?

Helios-
Helios-'s picture
Offline
Last seen: 1 year 1 week ago
Joined: 01/18/2012 - 21:12
Posts: 2099

For testing purposes we could use a Fet + 1 7135 driver with a DIP-8 socket. Swap in attiny 13, 25, 85. If a particular chip is bricked or acting up just plug in a new one.

Anyone have a copy of a Fet + 1 7135 .brd? I’m tired / lazy at the moment.


Counterfeit 18650s, 2,<a href=“http://

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 9 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7393
Location: SC

Tom E wrote:

. . . Update: Hhmm, the 45's and 85v I thought I bricked I can actually still program. Just tried it with the -B 10 option, but also without the -B 10 option. I'm putting them in the clip bare. Wonder if there's a difference having them reflowed on a board? Maybe just bad contacts with the clip?

Other than the first 2 chips that I bricked immediately due to flashing bad fuses, I've been flashing the same chip.  I would guess I have flashed it at least 8 times.  I have had issues with getting good clip contact at times.  I think it is due to my clip having to be opened to near it's max position.  I didn't mention it earlier because it didn't sound like the same problem you were having. 

EDIT: I find putting a little flux on solder wick works real good to pull off excess solder from pins when a clip can't hold on.  The flux residue has to be scraped off the pins sometimes as it blocks contact.

". . . You realize that wasn't really a loss for me in Africa — it was a gain that I didn't appreciate."

- George Foreman 2017

texaspyro
Offline
Last seen: 1 year 3 weeks ago
Joined: 04/29/2011 - 12:43
Posts: 4593
Tom E]<P>[quote=Diode663 wrote:
I could not find one example of them making a change, in a register layout for example, where the functionality of the register stayed the same. In fact I’d say they went out of their way to keep it the same.

One thing to look out for is the bits that set the ADC reference voltage… they are different on the Tiny13 and Tiny85. Another thing is the RC oscillator runs at different frequencies (8 vs 9.6 MHz?)

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

texaspyro wrote:
Diode663 wrote:
I could not find one example of them making a change, in a register layout for example, where the functionality of the register stayed the same. In fact I'd say they went out of their way to keep it the same.
One thing to look out for is the bits that set the ADC reference voltage... they are different on the Tiny13 and Tiny85. Another thing is the RC oscillator runs at different frequencies (8 vs 9.6 MHz?)

Yes, the ADC bit change is one of the lines of code changed. Also the clock difference is one of the other lines of code changed -- that makes two, plus the one reference that didn't compile and had to be changed, 3 total  Smile.

I know these changes are in the source I posted  - post #68 has the detail on the ADC change, post#70 has the link to the working project/code. It should be real simple to port any of our firmware versions - changes below. The other PIA is targeting the 25, 45 or 85. You have to change the AVRDude commands, as well as the project property in Atmel Studio for the targeted MCU. I've been swapping between 25, 45, and 85 - little annoying but not too bad. At least no source code changes are needed.

Clock rate change:

old:   #define F_CPU 4800000UL

new: #define F_CPU 8000000UL

WatchDog Enable change:

old:   WDTCR = (1<<WDTIE);   // Enable interrupt every 16ms

new: WDTCR = (1<<WDIE);    // Enable interrupt every 16ms (was 1<<WDTIE)

ADC_on:

old:   ADMUX  = (1 << REFS0) | (1 << ADLAR) | ADC_CHANNEL; // 1.1v reference, left-adjust, ADC1/PB2

new: ADMUX  = (1 << REFS1) | (1 << ADLAR) | ADC_CHANNEL; // 1.1v reference, left-adjust, ADC1/PB2

 I think that's everything. Of course the fuses are different, but again, the BAT files with the fuse definitions are in the google docs link.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

Update: Sorry, didn't get a chance to try temp sensor support. But this eve, I did get brown out detection OFF time method working, and it's working in the eswitch version. So, I have firmware that is 1074 bytes running on a 45, about 26% code space used, and has a fully functioning power clicky switch support with mode memory and OFF time support, as well as full e-switch support! Best Of Both Smile. Dang, this is getting easy...

Using that Fuse calculator too, I am using these fuse values to enable this combo of features:

  -Ulfuse:w:0xE2:m -Uhfuse:w:0xdf:m -Uefuse:w:0xfe:m

Basically, I melded the STAR_NOINIT stuff into my eswitch version. This is where I ran out of code space before, and why I got into the 25/45/85's, specially since ImA4Wheelr got it basically up initially.

For the fuses, I analyzed what was done for the full brown-out detection, and made the same settings for the 45 family. With the Fuse Calculator, it was pretty easy to do.

texaspyro
Offline
Last seen: 1 year 3 weeks ago
Joined: 04/29/2011 - 12:43
Posts: 4593

My SRK driver firmware uses about 6K of Tiny85 code. I use the temperature sensor on the chip for thermal management. The sensor works well. The accuracy of each step in temperature vs ADC reading is very good. The absolute accuracy of the readings is not so good. They spec +/- 10C, but it seems to be a lot better than that. Mine were less than 3C off. Consistency between chips (at least from the same batch) was very good (<1C) I have a user calibration routine, but even uncalibrated it is quite usable.

Tom E
Tom E's picture
Offline
Last seen: 1 hour 8 min ago
Joined: 08/19/2012 - 08:23
Posts: 10331
Location: LI NY

Ohh - I didn't realize you had a full up working implementation, and with temp sensing. How did the firmware get so big? What all does it do?

DavidEF
DavidEF's picture
Offline
Last seen: 2 hours 40 min ago
Joined: 06/05/2014 - 06:00
Posts: 4988
Location: Salisbury, North Carolina, USA

Tom E wrote:

Ohh – I didn’t realize you had a full up working implementation, and with temp sensing. How did the firmware get so big? What all does it do?


Yes, yes… Inquiring minds want to know! Big Smile

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

pilotdog68
pilotdog68's picture
Offline
Last seen: 1 week 3 days ago
Joined: 05/30/2013 - 23:31
Posts: 6346
Location: Held against my will in IOWA, USA

So the 45 is the same footprint as the 13 or no?

My Favorite Modded Lights: X6R, S8 , X2R , M6, SP03

Major Projects:  Illuminated Tailcap, TripleDown/TripleStack Driver

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 9 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7393
Location: SC

^ Smallest you can get the 45 is SU package which is the same size as the Attiny13a SU.  We use the Attiny13a SSU on most of our drivers.  The SSU package is smaller than the SU package.  You can, however, bend the SU pins inward to fit the SSU pads.  Check out pictures in the OP.

". . . You realize that wasn't really a loss for me in Africa — it was a gain that I didn't appreciate."

- George Foreman 2017

Pages