Attiny25/45/85 FW Development Thread

I didn’t care much about it. On the other hand I don’t recall getting such wild variations, but since I haven’t touched the 85 in ages my brain has purged most of that stuff. I’m sitting with my ATtiny1634 drivers right now so I just tested: 20°C at 2.6V and 22°C at 4.4V, nothing for me to worry about.

Do you use Noise Reduction Sleep Mode for temperature readings? I don’t do this currently but might give it a try.

No I don’t. Have you allowed a settling time when switching between voltage and temperature readings? At least on the 1634 it’s important if you are reading voltage by connecting internal voltage reference to the ADC and using MCU voltage as reference. I read voltage on 1S lights this way and if I don’t have a delay I’d get funky results. 1634 datasheet specifies 1ms settling time, I have a 2ms delay just to be sure. I’m not in a hurry.

This will probably not help if the results you posted are always consistent but at the moment I can’t think of anything else.

Yes, I have this 1 ms delay in my code. Anyway -

I have to apologize for crying wolf.

After some more research - including the noise reduction sleep mode - I checked the temperature readings again in my battery driven final light setup and the readings turned out normal (without noise reduction), without much deviation at different voltage levels. But the wrong readings are still there in my test setup on breadboard. So the reason must be somewhere in this test setup, don’t know yet if its the test setup itself or if its the USBASP connected to the breadboard which is causing the noise. And it must be noise causing the weird readings since they are normal even in my test setup when I use the noise reduction sleep mode.

Thanks for your help, Mike!

Actually I do this delay only when measuring voltage internally since Atmel says in the specs it is required when measuring Vbg against Vcc. As I understand the specs this delay is not required for measuring temperature against Vbg. (I’m refering to Attiny85 specs).

Glad it’s sorted. You’re right about the delay, according to the datasheet it’s only required when switch to internal voltage reference, it says nothing about from. For me it doesn’t matter though, I have 2ms to spend after each conversion regardless if I’m reading voltage or temperature.

Anyone ever release a candle flicker mode for a clicky firmware? Or just Anduril at this point?

If not, how easy would it be to port Anduril code to Bistro (HD) nothing fancy just the flickery output

It shouldn’t be too hard, assuming there’s space in the ROM. Basically just take code from the candle mode’s EV_tick handler, put it in a loop, and add a 16ms delay between frames.

This, um, also assumes some other things though… like the existence of a function to set the output level in ~150 visually-linear steps, without the caller having to worry about how that’s actually implemented in the hardware.

Thank you for direction. Hopefully I’ll get it :smiley:

Hey you atmel wizards. I want to reduce the PWM frequency of the 7135 channel of a D4 driver.

From doing a bit of reading in this thread I gather that doing this might involve using a divider with the clock frequency. On the engbedded page if I check the divider of 8 checkbox it changes the low fuse to 0x62. Would that work? Would that change the frequency for both channels, and if so is there a way to just change the 7135 channel?

If I understand correctly that would lower the frequency to around 2 kHz, which would work for my application. But is there a way to adjust the frequency more finely, rather than by a factor of 8?

Thanks.

Making them run at separate speeds may be do-able but would take some coding. Essentially instead of running the FET from OCR0B (Timer/Counter0, Match B Output), you’d need to set it up to run on OC1A (Timer/Counter1, Match A Output). Running them on separate counters would then give you the ability to set a prescaler for each timer separately.

If this is for Anduril, most of the relevant bits are in fsm-main.c in the hw_setup() function. We’re setting TCCR0B to 0x01 which is to use the main clock, no prescaler. The smallest prescaler is 8x. Setting TCCR0B to 0x02 would use the 8x prescaler. You’d then need to set up Timer/Counter1 for the FET channel. I’ve never done this with the t85, but it should be do-able. God-speed my friend!

Or, if you’re not hung up on running the FET and 7135 PWM channels at separate speeds, I’d just set that TCCR0B to 0x02 to use the 8x prescaler for both and then just leave everything else alone. Don’t even need to jack with fuses, which would affect the clock speeds for everything. In doing that, you’d need to update tk-attiny.h otherwise everything will be running in 8x slow motion!

Thanks, gchart. I am ok with the two channels running at the same frequency, but I’ll be using rampingIOS FW. I guess I would change something in this area?

This is for a mod I’m doing with the CN5710 linear regulator which wants lower PWM frequency.

Ahh yeah, excellent work on that EasyB! I’ve used the CN5710’s with RampingIOS as well, but with an attiny412 (custom 5-amp linear driver for the D1S and also on my OL7 and OL8 contest builds).

Same basic change is needed to TCCR0B. In int main() you’ll find:

// Set timer to do PWM for correct output pin and set prescaler timing
TCCR0B = 0x01;  // pre-scaler for timer (1 => 1, 2 => 8, 3 => 64...)

You’ll want to change that to this for the 8x prescaler on the PWMs

// Set timer to do PWM for correct output pin and set prescaler timing
TCCR0B = 0x02;  // pre-scaler for timer (1 => 1, 2 => 8, 3 => 64...)

Thanks again, I found it.

Those are some really nice elegant looking linear drivers you’ve designed. It makes me think over my collection to see if I can use one somewhere. :slight_smile:

There seems to be a problem caused in anduril when the TCCR0B is set to 0x02. It ramps fine, but when I click to turn it off it sometimes goes into some kind of “glitch”. Instead of turning off it does nothing or goes to a slightly higher brightness. Repeated presses eventually turn it off. It’s hard to explain; it seems to be unpredictable and intermittent, but most of the time it glitches.

I originally loaded it onto the D4 V1 driver I modded with a 5710 chip. Then I loaded the same hex file onto an unmodded D1S driver (same FET+1 layout) and it did the same glitching. I then recompiled the program only changing the TCCR0B back to 0x01, and it worked fine. Any idea what is causing the issue, and if there is a fix while keeping the lower PWM frequency?

Also, I had used the lower PWM frequency with rampingIOS and it worked fine with no glitches.

Anyone have any ideas on why lower PWM frequency would mess up basic operation in Anduril? I would use rampingIOS but I really want the click-hold for decreasing brightness functionality.

Perhaps I’ll try rampingIOS v3 which has that functionality.

I’ve tried racking my brain on why it would act that way and I can’t think of anything. I’ve done a lot of grep’ing around and haven’t run across anything that I think might cause that behavior. RampingIOS V3 uses the same FSM base as Anduril, so it might have the same issue but it’s worth a shot.

I was going to say “but RampingIOS does have click-hold for decreasing brightness!” but after trying out one of my lights with it, I realized that I’ve actually trained myself to do a very fast hold-hold for decreasing brightness. It works well for me, but it’s not quite the same.

Thanks anyway gchart. I like the click-hold to decrease because without it you don’t know which direction it will go. It always goes up after you turn it on, but if you have it on for a while and forget which way you ramped last it is like a gamble. I am also using a hybrid ramp which includes stepped modes, so I don’t know whether it’s going up or down initially; I have to wait until it goes to the next mode before I know I’m going the wrong direction.

A couple more clues/details I noticed with this issue:
When turning on, the LED blinks at a very low brightness as you press the button then goes to the memorized level when you release the button. Whereas during proper operation the LED stays off until you release the button.

Sometimes when attempting to turn the light off it will instead go to the max 7135 channel level. But some part of the MCU thinks it is in fact off, because the next button click will go to the previously memorized mode as if it was just turning on. It really does seem random whether the light turns off or goes to the max 7135 channel level. But the probability of it malfunctioning goes up with the PWM duty cycle. If I’m low in the 7135 channel duty cycle it usually turns off as it should, but if I’m high up in the 7135 channel duty cycle it usually malfunctions and goes to 7135 channel max level.

RampingIOS v3 does have the same problem.

That’s a head scratcher. And a stock D1S driver does the exact same thing, huh? It might be worthwhile to post about it in the FSM/Anduril thread and see if anyone there has run into something similar.

Yep, stock d1s driver in a different light did the same thing.

Ok, I’ll ask over in that thread.