Is an 7135+FET with Attiny13 large enough to fit a simple 4 mode UI on it with LVP, Temp Protection, and perhaps a candle mode or am I just wasting my time at this point?
Attiny13A does not have internal temperature sensor and voltage measurement, so you need 2 external ports and some additional components for this options. Software should fit.
Looks like im replacing my BLF A6 driver with a mtn17ddm with an ATtiny85 to use as a clicky test bed.
Since ill have the space, im going to aim for crescendo with an added candle mode, thats going to be one heck of a challenge.
Its telling me
k-attiny.h:61:10: fatal error: avr/interrupt.h: No such file or directory
#include < avr/interrupt.h>
I was under the impression that avr/interrupt.h is something I should have
Yes, you need a bunch of extra files to compile Anduril, It is best to copy the whole repository IMO to make sure you have all the files. It would not work until I did that.
2nded.
apt-get install bzr
bzr branch lp:flashlight-firmware
Do everything in the structure that makes. Modify Anduril there, alter cfg and hwdefs there, and just use the build-all.sh located in the fsm\ToyKeeper\spaghetti-monster\anduril folder.
Are you using the Makefile?
If not, try make instead of cc.
I have Anduril working on an MT09R / GT70 style driver but I found a really strange bug with the thermal regulation.
If I let it get hot so that it starts regulation and then double click to go back to turbo, the regulation seems to go into a âloopâ.
It will once again slowly start turning the power down again after a few seconds delay as expected but after it regulates down to a fairly low level (although I donât think down to the âstop panic pointâ) it will suddenly start going up in power again until it goes back to full turbo.
At which point the process keeps repeating, ramp down then up then down then up ect. I turned it off and put it back into turbo and it did the same thing.
I turned off the light once it reached 75c.
I am waiting for it to cool down and will try it again without going back into turbo to see if that changes anything.
Any ideas why this would happen?
I also realized something else when testing this thermal control. Anduril is not giving me 100% turbo?
If I ramp it all the way up I get ~5k lumens, if I double click I get ~8k lumens but with Narsil in the same light the turbo power is over 13k lumens with the same ramp.
This ramp works good in my testing for this light, the low mode where it changes the MCU speed are not causing any noticeable inconsistency with the ramp that I can see and I am very picky about such things but then an FET reacts differently then a 7135 to such a change, so this is not unexpected.
This is the cfg file for this driver, the only change I have made otherwise is commenting out the ramp length in anduril.c so that it would not get an error.
I cannot confirm your problem, but I flashed your config onto my eval board and did a few oscilloscope captures.
Yellow = CH1
Blue = CH2
Moonlight mode:
Some random low-ish mode:
Some random high-ish mode:
Max. ramping
Double-click turbo:
If you send me your NarsilM hex, I can give you a few pictures to compare what NarsilM does different.
Maybe Ch1 is a bank of 7135s and they are also on?
Hmm, very interesting, Thanks for the testing!
I assume you also commented out the ramp_length in the anduril.c file?
Oh, I was also checking the Anduril file and realized I also changed the blinks while ramping options a bit as I want these to be the defaults in most cases, although it should not effect this issue.
// short blips while ramping
//#define BLINK_AT_CHANNEL_BOUNDARIES
#define BLINK_AT_RAMP_FLOOR
#define BLINK_AT_RAMP_CEILING
//#define BLINK_AT_STEPS // whenever a discrete ramp mode is passed in smooth mode
here is the NarsilM version of this firmware
I will try compiling Anduril again and flashing it again, maybe it was a bad flash. It is a very strange issue, the hardware works perfectly with Narsil, so it should work with Anduril.
Ok, I re-compiled and re-flashed the driver. I can not get turbo with ~13k lumens, although strangly it seems to be doing a bit less lumens with anduril then Narsil (~12.5k vs 13.5K). I have no idea how that is even possible since your scope shows the FET is running at 100%.
The other thing I realized is that I might not understand how Anduril works, if I double click from off it appears to go to the top of the ramp but if I double click after the light is on, then it goes to turbo.
Is this how it is supposed to work? Canât say it is a bad setup, just not used to it. Although on the old flash, it did not matter how many times I double clicked, it would max at ~8k lumens (which is now the top of the ramp).
I am testing the thermal regulation again nowâŚâŚ
No, I did not uncomment it as the newest version uses the following code in anduril.c
Looks like NarsilM behaves simmilar.
Interestingly, PB4 is sometimes active and Iâm not really sure what that channel would do.
Low-ish:
Mid:
Max. ramp:
Turbo:
Yeah, itâs supposed to work like that.
Although you can change it, just not that easyâŚ
Easiest way would be to remove the following code from the EV_enter_state of steady_state:
nearest_level(arg) caps the output when entering the mode at max. ceil level.
There may be side effects when disabling that, but for now it seems as it would work.
Maybe with stepped ramping there could be a small glitch.
Off + double click = Ramp Ceil
On + double click = Turbo
Thanks again.
I wounder if TK updated the code? In my version it gives a compile error if I do not comment out the ramp in anduril.
PB4 is the AUXled channel (aka, the switch LED).
Great, good to know.
Ok, with the newly compiled firmware I tested the thermal regulation again and it did basically the same thing.
I turned the light on turbo and then put it on my sphere and watched the lumen output and temp.
First it climbed up to ~43c and then started down regulating perfectly. It dropped down to ~2k lumens or so and the temp stabilized for a little bit.
After a minute or so it started ramping up again, it went up to around 8k lumens and then ramped back down to the minimum level of around ~1k lumens.
It then went into the same âloopâ or âwaveâ pattern where it would ramp up and back down, each time getting hotter. I left it for a little bit and when I came back it was 102c.
Needless to say I donât think that is supposed to happen.
I have positively no idea what would be causing it but it seems like some tuning of the thermal regulation settings could help it a lot. There are not many defines for this though that I can find.
If there are any other settings that can be tweaked to help tune the thermal regulation I would love to know what the defines are so I can add them to the âbase config fileâ.
Yeah, TK updated the code.
https://code.launchpad.net/~toykeeper/flashlight-firmware/fsm
It was done in revision 385
Also currently in the pipeline: Hold while booting to reset and calibrate the temperature sensor to 20°C
Thermal regulation is a big area which would need a big rewrite but thatâs still a to-do.
Good to know, there very well might be a case where I would want to disable that, it would be cool if I could use a define in the config file for this purpose but that goes over my coding abilities right now.
Basically comment out that line and it should act like Narsil with double click going directly to full turbo no matter the starting state?
I think I will try it as TK has it setup for now and see how it is once I get used to it. It is not a bad idea.
What I would like to change is the delay as the firmware waits to see if you will double click before it does anything (aka, you press the button to turn the light off but it waits half a second before turning off). That bothers me more then I want to admit lol. I personally prefer the light turning off for a moment before going to turbo if you do double click.