Adventures in TinyAVR 1-Series

Flashlight Modding and DIY Parts
149

I do believe it’s 5 MHz with Fast PWM. I haven’t noticed any unusual things with PWM, but I also don’t have a ’scope to do a deep dive. Is there anything I can do with “normal” tools to check to see if the old Fast PWM problems are being exhibited?

With some back-of-the-napkin math / guesstimates based on LED vF and resistor values, I’d say the high channel is around 1.5 amps and the low channel is around 0.7 mA. So 1/255 of 1.5 amps is around 6 mA, much higher than the highest low channel value. The best option would probably be to replace that 4.7 kOhm resistor with a smaller value… oh well.

You’re right, I don’t think the t1616 resets eeprom when flashing. When needed (like when moving from Anduril1 to Anduril2), I’ve just done a factory reset. Speaking of that, one thing that LoneOceans did with the Lume series drivers was to prevent thermal calibration during a factory reset since he used a pre-calibrated temperature sensor. These 1-Series chips are also pre-calibrated, so there’s no need to auto-calibrate on reset. I didn’t check to see how to prevent this.

Fuses… thankfully I’ve seen absolutely no need to change fuse settings on the 1-Series. Most things we used to do in fuses can now be set at run-time (clock settings, brown-out settings, etc).

150

Sorry it’s me again, never mind my previous post, that was just a bad solder joint on my test board :FACEPALM: , compiling and flashing works fine. I did further testing on my driver and the problem comes from the boost enable pin, it’s floating at ~0.8V whether it’s off or on, I also assigned it to others pins (PB1, PB4, normally it’s PB3, for testing I enabled pull-up on PB3, which for some strange reason is at 2.2V instead of 2.8V) same result, then I assigned it to PA5 and it works : 0V when off, 2.8V when on. How does that make sense ?

#define LED_ENABLE_PIN PIN3_bp 
#define LED_ENABLE_PORT PORTB_OUT

Set as output :

VPORTB.DIR = PIN3_bm;

151

Hmm, I wish I had a good answer for that. Is it possible that it has something to do with the driver design? Not saying it’s wrong or bad, just something specific to hire it’s laid out?

152

Maybe bad tracing on PCB. Is the enable pin have direct connection to MCU or there is some pullup resistors?

153

Only one difference i see is that PA5 is port A ;))

154

I replaced the 416 with a 1616 on the xplained board, breadboarded the SP10S layout, with the LED enable assigned to PA1 (original) no problem, assigned to PB1 or PB2, doesn’t work, assigned to PC1, works.

LED enable just doesn’t work on B pins.

155

Huh, that’s really quite strange.

156

Some other tests

PB0 PWM
PA5 led enable
PB2 R
PB1 G
PB4 B

No PWM

PB0 PWM1
PA5 led enable

OK

PB0 PWM
PA5 led enable
PC0 R
PC1 G
PC2 B

OK

PB0 PWM
PC3 led enable
PC0 R
PC1 G
PC2 B

No led enable

I wanted to also test PWM on PA3 (WO3) but I don’t know what to put in hwdef for that.

157

That’s really weird. You might have to check in over at avrfreaks to see if they have any ideas about the PortC behavior. You’re just using it as a basic IO pin and setting it high and low, right? Do you have a pull-down resistor on your LED enable channel? If so, what value? Maybe PortC output is very weak or something?

You’ll need to enable Split mode. I haven’t tried that yet myself, but I see the very knowledgable El Tangas has examples here

158

The output pins are connected to LEDs with current limiting resistors to test the pins behavior.

Moving the RGB LEDs to port A :

PB0 PWM
PC3 led enable
PA1 R
PA2 G
PA3 B

OK

It looks to me that different stuff can’t be on the same port.

159

Ohhh, I think you’re onto something! Worth noting, each “pin group” has a maximum combined source/sink current. According to Table 36-10, that appears to be 100 mA. That sounds like plenty, but very well could be what you’re running into. I’m pretty sure for these chips, “pin group” is synonymous with “port” (eg, Port A, Port B, and Port C).

160

Hmm, I put 100Ω on the RGB leds and PWM LED, 10K on the LED enable LED, I’ll try with more resistance on the two former, but it mirrors the issues on my driver, on which the load is on the uA order.

161

Testing with 10K resistors on the status leds, same result.
Moving led enable to PA5

PB0 PWM
PA5 led enable
PA1 R
PA2 G
PA3 B

No led enable.

Circuit on the breadboard :

I also checked with a voltmeter instead of status leds (i.e. the pins are only connected to the voltmeter), same result, I just used leds because it’s quicker for checking the pins status.

hwdef

So at this point I’m eliminating any issues with the circuit, it must be in the code.

In the present state if I want to use the attiny1616 with my driver I must wire the PWM, led enable and RBG on different ports, which is possible of course, just not as convenient as using any pins. But if there is functionality added for the current sense resistor selection, then that’ll possibly means it’ll have to be on another (nonexistant) port. (Toykeeper said she has an unfinished branch that might have functionality for this).

162

Ohhh, I think I finally noticed it. At least I hope so. When you set the DIR for those RGB, each write is wiping out the entire VPORTA.DIR contents.

Replace this:

    VPORTA.DIR = PIN5_bm;  //enable
    VPORTB.DIR = PIN0_bm;   // PWM
    VPORTA.DIR = PIN1_bm; //R
    VPORTA.DIR = PIN2_bm; //G
    VPORTA.DIR = PIN3_bm; //B

With this:

    VPORTA.DIR = PIN5_bm | PIN3_bm | PIN2_bm | PIN1_bm;  //enable, R, G, B
    VPORTB.DIR = PIN0_bm;   // PWM

Or perhaps (note the added pipes):

    VPORTA.DIR |= PIN5_bm;  //enable
    VPORTB.DIR |= PIN0_bm;   // PWM
    VPORTA.DIR |= PIN1_bm; //R
    VPORTA.DIR |= PIN2_bm; //G
    VPORTA.DIR |= PIN3_bm; //B

BTW, SpenceKonde has a nice write up on AVR’s bit manipulation with the PORT & VPORT registers here

163

Yes it works, of course I should have properly copied the syntax from your hwdef files… sorry for having the stupid.

Thank you :+1: :+1:

164

Great!! You’re welcome

165

At 1023/1023 it’s not fully on, it’s off the same amount of time it’s on at 1/1023, 200ns so 1 cycle.

166

Is that with TCA? Does it act the same way in 8-bit? And does 0/1023 go fully off?

167

Yes and yes.

Edit : for the 3rd question I’m guessing no, anduril apparently turns the flashligh off (led enable goes off) when putting 0 as the floor so it’s not obvious, but shortly before that the level just stops at 1/1023 for like half a second, instead of smoothly going to 0.

168

Looking with the scope, it seems that having the PWM pin (e.g. PB0) connected to a floating pin (e.g. PC0), doesn’t affect the waveform. The difference in current draw with the floating pin is about 50~100uA. I might do that, that way the hardware would be compatible with both TCA and TCD.