Adventures in TinyAVR 1-Series

avr-libc:
Installed: 1:2.0.0+Atmel3.6.1-2
Candidate: 1:2.0.0+Atmel3.6.1-2
Version table:
*** 1:2.0.0+Atmel3.6.1-2 500

gcc-avr:
Installed: 1:5.4.0+Atmel3.6.1-2build1
Candidate: 1:5.4.0+Atmel3.6.1-2build1
Version table:
*** 1:5.4.0+Atmel3.6.1-2build1 500

I made a test board with one 7135 and the same pinout as your BLF_Q8_T1616 so I don’t have to touch anything, it doesn’t work, so there is something wrong either with the building or flashing.

Could you send me an hex file for the BLF_Q8_T1616 ?

edit : never mind that was a bad solder joint, building and flashing is ok.

There should be one here that you can try out: Index of /blf/firmware/hex_files

If I remember correctly, it’s using this layout: What did you mod today? - #9719 by gchart

Thank you, I’ll test that tomorrow.

Hi, I’m merging the code into my anduril2 branch. Overall it looks really good, clean and clear, but I have some questions…

In MODELS it adds a few entries, and I’m wondering which ones use factory hardware and which ones require custom driver hardware:

0622    sofirn-sp10s
0631    blf-q8-t1616
0632    sofirn-sp36-t1616
0633    blf-lantern-t1616 
1618    gchart-fet1-t16

If any of the “06” (Sofirn) builds require custom hardware, I’ll re-number them under the “16” brand.

In fsm-adc.c, why does the temperature shift right 8 and then left 6, instead of just shifting right 2 bits? It seems like this throws out some potential extra precision. Also, it uses 32-bit math to avoid 2 bits of potential overflow, but then sheds 6 bits, so I’m wondering if that might be avoidable. Not sure how many clock cycles it takes for the 32-bit operation on this MCU, but I’m trying to keep interrupt handler timing as short as possible.

In tk-attiny.h, it sets the base clock speed to 5 MHz, but could have also used 10 MHz. I can see reasons for either one to be used, but I’m wondering how the PWM speed and power usage look in both configurations. Have you measured this?

The SP10S build has pretty unusual ramp values and looks like the low channel is very low. Would it benefit from some extra sub-ramping on the low channel during the bottom portion of the high channel’s ramp? Not sure if that could provide extra resolution or not, especially with dual voltage.

Sorry about how messy it is to add a new MCU. I’ve been thinking about ways to make this process easier and cleaner, but I’m not sure what the best approach is or when it’ll happen.

Hey TK, good to see you around!

  • The 06xx builds for t1616: Sofirn approached me about working with them to convert these models to use the t1616. So these are pre-production builds, but could hopefully one day (soon?) be actual Sofirn lights. Feel free to number them however you see fit!
  • The “shift right 8 bits” was part of code I copied right from Atmel (attiny1616 manual page 435). Then I saw you left aligned things. I didn’t combine the two, but it looks like that could be done. In general though, that chunk of code was just a copy & paste from Atmel. I didn’t bother trying to optimize it for our use case.
  • The power usage between 5 MHz and 10 MHz is minimal unless we’re trying to really stretch runtime on low modes. You can see some test results here
  • I agree, the SP10S ramp is a bit unusual. And yes, that’s because the low channel is very low. But the lowest setting of the big channel is appreciably higher. I think the high channel is a straight 3.13V feed while the low side adds a 4.7 kOhm resistor. I’m not that great with customizing the ramps, and flashing new builds meant tearing the light apart again, so I rolled with a “yeah, that’ll work” ramp. I’d be up for trying something new though!

Oh, nice. If they’re pre-production builds for things people will eventually be able to buy, they can keep the Sofirn manufacturer ID. I’ve been so out of touch I didn’t know those were in progress.

About shifting bits around, it probably doesn’t matter. It works now, and can maybe be optimized later if necessary, but there’s not really any need yet.

For 5/10 MHz, I just measured the PWM speed and got 19.22 kHz… which suggests it’s either fast PWM at 5 MHz or phase-correct at 10 MHz. Looking at the code, it appears to be 5 MHz with fast PWM. I haven’t measured that before on this MCU, but older models had issues with fast PWM at low levels and at full output, since each pulse would turn on and off at least for one cycle regardless of the target value… so 0/255 wasn’t fully off and 255/255 wasn’t fully on. So it may be worth some investigation to see if that’s still the case, and maybe switch to phase-correct 10MHz. But that’s just a minor potential optimization for later.

If the SP10S is a pain to reflash, it would definitely be a pain to do fine adjustments of the ramp. Sometimes it’s possible to improve low-end resolution by treating the low channel as extra “bits” for the high channel, but only if the power levels of each are well-balanced and stable at different voltages. If that’s not the case, or if it’s not feasible to do the testing involved, it’s better to just leave it as-is.

Also, I noticed the t1616 doesn’t seem to reset eeprom while flashing. Not really a big deal, since factory reset exists… but the flashing script also doesn’t set any fuse values. Does it ever need fuse values set?

Anyway, the 1-Series branch is merged into my anduril2 branch, and will likely also get merged soon-ish into the fsm branch and trunk. I also added some new builds. I hope this will make things a bit easier for everyone.

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

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;

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?

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

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

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.

Huh, that’s really quite strange.

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.

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

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.

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

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.

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