Adventures in TinyAVR 1-Series

276 posts / 0 new
Last post
thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Yeah lol, a few moments after I ordered, I also wanted a buck IC, some 9000 in stock in the morning, then zero in the afternoon when I placed my order, plenty of other ICs have poor availability too.

They’re also gone from Farnell.

JaredM
JaredM's picture
Offline
Last seen: 5 hours 49 min ago
Joined: 10/31/2011 - 13:33
Posts: 2229
Location: Pittsburgh, Pennsylvania

I had 2 in my cart along with a few odds and ends and saw this this morning when I finally was ready to checkout.

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Gchart, do you have an example hwdef file with TCD ?

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Sorry, I haven’t used TCD with Anduril yet. But I do have a fairly bare bones TCD 10-bit PWM test code here:

http://www.ghart.com/blf/firmware/Tests/pwm_tcd_led.c

It’s been a while since I’ve played with the TCD, I should do that again. Let me know if you run into issues and I might be able to provide some pointers or run some tests on the Xplained Mini dev board.

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Oh… for now I’ve just been copy pasting code from other files so that’s a bit problematic Blushing

I tested with test code, it worked.

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

This is where I'm at for my boost driver.

hwdef file : (removed since it was a bit long)

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Oh actually, maybe the ramp could just be like this, with only one PWM (example with ramp lenght of 10)

PWM1_LEVELS 2, 500, 1023, 2, 20, 50, 100, 200, 500, 1023

With the mosfet for the high current range enabled from level 4 to 10.

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

I hate to break it to you, but it looks like Anduril will need some (hopefully minor?) updates/customizations to make TCD work. If you check out page 250 of the datasheet you’ll see how the TCD works with CMPxSET and CMPxCLR. It’s opposite of how we normally think of PWM. If you set CMPxSET to 0, the LED would be fully on. If you set it to 255 (8-bit) or 1023 (10-bit), then the LED will be fully off. You’ll notice that in my test code, I subtracted the desired PWM value from the period to get the inverse.

Also… you need to tell the TCD to synchronize any time you make a CMPxSET (or CMPxCLR) update. That’s the “TCD0.CTRLE |= TCD_SYNCEOC_bm;” line in my test code.

Pretty much anywhere PWMx_LVL is used, it’ll require a small update. After grepping around, it looks like most of the changes are going to be in fsm-ramping.c. There are also a couple lines in fsm-main.c and spaghetti-monster.h. None of the changes should be too terrible. If you want, I could make the changes if you’d like to test them.

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Page 250 you mean ?
Honestly I’m not understanding much of what I read, so yeah, any help would be greatly appreciated
I knew I should have used PA4 or PA5 since they can be used with TCA, but tracing was easier with the opposite pins…

Edit : maybe, if you’re interested in this boost driver, I could send you one.

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Yeah, I meant 250… oops.

Now that I think about it, the easiest thing to do might be to mimic some of what the Noctigon K9.3 is doing. It has an override for the set_level function defined specifically for it, all controlled in cfg files. Note how the top of the cfg-noctigon-k9.3.h file says:

// this model requires some special code
#define OVERRIDES_FILE cfg-noctigon-k9.3.c
#define OVERRIDE_SET_LEVEL
#define OVERRIDE_GRADUAL_TICK
inline void set_level_override(uint8_t level);

and then there’s a specific “c” file to contain those override functions. We’ll probably want to do the same thing. Then you can set things like “when level == 0 set the PWMx_LVL = PERIOD” and “PWMxLVL = PERIODPWM_GET(x,y)” as well as being able to say when to turn on and off those specific current set resistor channels.
thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Hmm yes maybe, though as long as I don’t know much about programming I think I won’t be able to do much here, I did try to learn in the past but got discouraged pretty quickly, I picked up again a book on C a couple of days ago but honestly I’d rather focus on the hardware if possible, as I have other driver projects, which I think people will find interesting too.
I messaged Toykeeper about this but she won’t be able to help at the moment.

Regarding TCD, I can make a new hardware revision, using PA4 (WO4) or PA5 (WO5), this way it’ll work with TCA and keeping the option for TCD in the future. Or maybe I could wire to both PBO (WO0) or PC3 and PC0 (WOC), that would mean less change to the layout for this driver.

For the high dynamic range though, it’s kind of one of the main feature, but the driver can still works without it.

So for now I put an airwire to PB0 to test the basic functionalities, I ran into errors when building Anduril though, but maybe I missed some steps. Using Microship studio 7 (it seems that atmel studio is integrated into microchip studio now, or something like that) I :

  • created a GCC C executable project
  • copied all the files from toykeeper, spaghetti-monster and anduril in the project folder next to main.c, deleted that one.
  • right clicked on ’project name’ add existing file, and added all files so they appear in the solution wiener.
  • built ’project name’

I get a few error: unknown type name ’…’ with beacon-mode.h with battcheck-mode.h
And error: CONFIGFILE: No such file or directory in anduril.c
And 2 warnings.

Do you know what could be the cause ?

Agro
Agro's picture
Online
Last seen: 2 min 46 sec ago
Joined: 05/14/2017 - 11:16
Posts: 6811
Location: Ślōnsk

There was a working Atmel Studio project some time ago, but it was not maintained.
I suggest that you install bash or another Linux shell on your windows and use the regular build method.

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

While I’ve used Atmel Studio (on Windows) for firmware before, I’ve never used it for Anduril. You might try following this guide.

Also, don’t forget that you’ll want to use the version of Anduril found at my branch because it’s likely the only one out there that has AVR 1-Series support.

I can try helping with the hwdef and cfg files, but it’s gonna take me a bit.

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Yep that’s the guide I saw, but I followed Agro’s advice Wink , I installed an Ubuntu VM, followed Toykeeper’s instructions , and compiled her branch to check that the basic stuff works fine, all very straightforward.

Then for your branch (yes it’s the one I was using Wink ) I got the extracted DFP, put its path in your build script, changed 412 to 1616 in it and put the build script in the anduril folder.
Is there something more to do ? (like specify somewhere to use your build script )

I used the make command and it compiled all files without issue, mine too.

Then in atmel/microchip studio I used device programing, put the hex file in memories/flash and then hit program.

The driver turns on and off on the lowest output and that’s all, no ramping, so I must have an issue somewhere in my hwdef or cfg files, or maybe elsewhere.

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

Ok, you’ve got it compiling and flashed, that’s great progress!

Do you still have it wired up to use TCD? No air-wires or other things for testing? Could you upload your hwdef and config files, perhaps to PasteBin so-as not to overwhelm this thread?

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Hwdef
Cfg

I should have put less stuff in it for basic testing though.

Edit : airwire from PB0 to PC0 (and PC1 since they’re connected on pcb), I tried with and without pull-up on PC0 and PC1 in the bottom of hwdef, but maybe I should cut the traces ? It worked fine with your test_tcd code even though pc0 and pc1 were connected together.

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

A few thoughts:

  • In hwdef for the Aux, you don’t need the separate AUXLED_x_PORT definitions, just the single AUXLED_RGB_PORT that you already have. AUXLED_RGB_DDR and AUXLED_RGB_PUE can be removed
  • In cfg I’m not sure about starting the ramp at 0, usually you’d want it at 1 or higher.
  • If you’re going to try with the airwire from PB0, I definitely wouldn’t set the pullups on PC0 and PC1. By pulling those pins high, that could/will interfere with your PWM signal.
  • Don’t forget to set PA6 as output. You might try setting it high to see if you can get the higher current range to activate, though I’m not sure that would actually tell you anything. Just a thought.

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Thanks for having taken a look

  • OK, but if one is on another ”port” (e.g red on PAx and R, G on PBx) then I would need to put separate AUXLED_x_PORT definitions ?
  • yep, not sure why I did that
  • makes sense
  • PB0 too, I forgot Facepalm

But, it’s not working anymore (no initial flash), I’ll resume tomorrow with a fresh mind, it’s getting late.

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

I’m a bit confused with the instructions for Linux on the first page, after putting the DFP path into your build script, what do I do with it ? Does it just need to be in the anduril folder? with or without it in it using the command ”make” compile everything without errors, isn’t this strange ?

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

All you should need to do is update the DFP line in the build script with your directory for those files. It’s strange that it would build successfully without them. If you run the following commands, what versions does it say you have?

apt-cache policy avr-libc
apt-cache policy gcc-avr

I’m on avr-libc version 2.0.0 and gcc-avr version 5.4.0. I’ve heard there are other (development) versions available that might have the device packs baked-in.
thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

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

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

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.

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

There should be one here that you can try out: http://www.ghart.com/blf/firmware/hex_files/

If I remember correctly, it’s using this layout: https://budgetlightforum.com/comment/1737825#comment-1737825

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

Thank you, I’ll test that tomorrow.

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

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.

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

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!

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

gchart wrote:
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.

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

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

thefreeman
thefreeman's picture
Online
Last seen: 7 min 20 sec ago
Joined: 01/06/2020 - 09:56
Posts: 871
Location: France

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;

 

 

 

gchart
gchart's picture
Offline
Last seen: 12 hours 52 min ago
Joined: 03/19/2016 - 11:57
Posts: 3158
Location: Central IL

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?

Pages