Attiny25/45/85 FW Development Thread

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.

[quote=Tom E]

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.

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

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.

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! :smiley:

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

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

If you want some logic for the temperature sensor check out JonnyC's MTN_Momentary temperature in his repository. It works great. Even though we can use an active external temperature sensor (my choice, where there is room) or a thermistor (cheap and small), on-MCU temperature sensor would work good enough for a lot of lights. You might as well be able to have it as an option if we're going to step up to the bigger MCUs.

Very good info. The code should be a great starting point. Probaby just need to change to ADCx to ADC4 for the internal sensor (haven't looked at the code yet). Although external would allow a higher quality sensor and faster feedback, it does cost a MCU pin.

Thank you RMM for an awesome tip. :)

I ordered these:

ATtiny25V-10SSU (from Mouser, qty 10 for $19.50, total order: $32.64, total payment: $39.63)

Just doing a search on the SSU part # on AliExpress found qty 10 for like $13-$14 which is a pretty good deal, just hope these haven't been pre-programmed with the reset bit set as an I/O pin - this happened to me for a qty 10 order of 13A's on eBay.

I'll look at that temp sensing code. Still tied up with the dive lights, but they are coming along. The Dx4S seems to be an awesome deal. One I modded does little over 3000 lumens with an R120 resistor mod, replaced 4 cool white XM-L2's with T6 4C's, 4.5A tail on 2 26650 protected cells. Wish I could do a driver swap, but they use the mag sensor. Might be worth looking into though to get one of those working on an I/O pin. The Dx4S is two cells with the LED's wired 2S2P, so perfect for a Zener LDO driver.

^ That Mouser price is a good deal for the 25SSU. I need to figure out what all I need so that I can spread out the shipping cost.

Sounds like a sweet mod. I need to look up what this Dx4S is. You have a thread on that Tom E?

Can you point me to this Zener LDO driver? There are some nice LDO drivers out there (RMM has some), but I don't know any LDO drivers using zeners.

EDIT: This must be the light you are referring to. Is the "S" a new model?

Well, you wouldn't use a zener and an LDO together. The whole point of the LDO is so that you don't have to use the zener. The zener is a cheap way to regulate voltage and it works great in clicky lights; but in momentary lights, the drain when nothing is running is too high to consider for long-term use.

Ooops, yes, LDO instead of zener, of course. Haven't done a LDO driver yet, though I'd like to with a Y3 as well.

That's the old style Dx4, the Dx4S is at BG ($44) and GB ($37), cheaper at GB but I bought qty 3 at BG and express DHL shipping for under $1.The Dx4S is re-styled, different switch mechanism. BG honored a price match request to GB before for me. GB has given me fits lately. BG seems soo much better, from their well managed, feature rich order history to their customer service, BLF 8% discount code, etc. Right now GB is a bit cheaper though, mostly. they got a MAXY 5% code, but don't work on discounted items.

This Win10 IE (Edge) is driving me nuts! Gotta install a decent browser. With Edge, can't right click, it pastes weird formatting in BLF, PIA...

This topic has gotten a little strewn about (mostly my fault I think), but, since I feel comfortable with what I have working, and seen it work on a 25, 45, and 85, I started looking into the temp sensor support. Post #1186 here: https://budgetlightforum.com/t/-/25032 (STAR firmware thread) has the latest.

Found the Atmel doc http://www.atmel.com/Images/doc8108.pdf, and one fairly good ref for sample code http://andrey.mikhalchuk.com/2011/06/20/reading-attiny854525-internal-temperature-sensor.html.

This is a variant implemented for the 84: https://harizanov.com/2012/07/using-attiny-84s-internal-temperature-sensor/. It has a link to a github repository for the source code.

This one has a plot showing readings, bit for another Atmel AVR MCU, guess it's at room temp: http://www.narkidae.com/research/atmega-core-temperature-sensor/

With reference to the above posts, I have modified JohnnyC’s MTN_momentary_temp.c for Attiny25, the sensor at pin3 PB4 was moved to pin2 PB3 and the switch at pin2 was moved to pin3.
I am not good at writing codes, would the experts here please check if I am modifying the codes correctly. Thanks,

Looked at it quickly. Interesting, this uses the rule of 4 readings in a row, no averaging at all, so one bad reading of a low value will cause a hi temp to not trigger dropping modes. Now this might be ok, not good, or may work flawlessly - I don't know enough at this point. The sample code though uses averaging, and I believe with tossing out outliers (way off readings).

This code may be fine for a more reliable, robust external sensor, but may not be good for an internal sensor. It also doesn't address the issue of calibration, so the two threshholds of 100 for low, 120 for high would have to be calibrated for the internal sensor.

It could be a good starting point however - just dunno enough yet to say.

About the code for addressing ADC4 for the temp sensor, not sure if ADMUX is set correctly. For ADC4 (Channel 4), the code for the variable named: adc_channel has it set to 0x03 - doesn't make sense - ADC4 is a special state of 0B1111 in the 4 lower bits of the register. Can't follow it all, but it doesn't seem correct, not sure... Refer to pg 135 of the 25/45/85 datasheet (http://www.atmel.com/Images/atmel-2586-avr-8-bit-microcontroller-attiny25-attiny45-attiny85_datasheet.pdf).

You are the man Tom. No one else has fully functional 25 FW out. So you get to strewn this thread all you want. I loaded your latest released version onto a chip last night. I should get it installed (another air-wire light) wired into a light tonight.

Hi Microa. I don't have much time and am not fully fluent in C yet. I don't see anything beyond what Tom said. The comment at line 21 specifies high fuse 0xff. That fuse setting bricked out a couple of my MCU's when I had 0x62 and 0x75 as the low fuses. Not sure if it's a problem when combined with 0xe2 like you have.

If the temperature sensor is anything like the voltage sensor, I’d definitely average a few values. Voltage is really noisy and I don’t get a stable result unless I average 8 or more samples with a delay between.