Anduril runs the control chip at a lower speed when it’s on really low levels, so it uses less power. It’s like how a notebook computer may be able to run at 3.2 GHz while it’s busy, but it’ll slow down to maybe 0.8 GHz while there isn’t much happening, in order to extend battery life. The clock speed changes based on demand.
So… your flashlight has a cooperative multitasking operating system which includes demand-based dynamic underclocking. Fancy, no? 
May I ask why you don’t run on low clock speed all the time? PWM frequency?
PWM slower than 10 kHz is easily visible for me, so I want it at least that fast. Ideally around 20 kHz so it’s also not audible… but the best tradeoff I can get on attiny85 is about 16 kHz.
I wished temperature sensor integration would come I found for another project those digital temperature sensors
would it be simpler to implement those, no calibration or table needed, over an analog NTC?
TEMPERATURE DIGITAL OUTPUT
(Binary) DIGITAL OUTPUT
+125.°C 0000 0111 1101 0000 07D0h
+85.0°C 0000 0101 0101 0000 0550h
+25.1°C 0000 0001 1001 0001 0191h
+10.1°C 0000 0000 1010 0010 00A2h
+0.50°C 0000 0000 0000 1000 0008h
+0.00°C 0000 0000 0000 0000 0000h
–0.50°C 1111 1111 1111 1000 FFF8h
–55.0°C 1111 1100 1001 0000 FC90h
I found out that new Anduril has
#define BLINK_AT_RAMP_MIDDLE
added in the main.c
but the config files like GT do not have an update with undef that line very annoying
P.S. it was former known as Blink at channel boundaries, have no idea why this got renamed
I don’t know. I haven’t used anything like that and don’t know what would be involved in adding it.
Are you sure? Here the latest version. It appears to have the correct undef line:
Those changes all landed together so there was never a mismatched version. Even in the dev branch I was using, the changes happened in the same commit. Here are the details:
https://bazaar.launchpad.net/~toykeeper/flashlight-firmware/fsm/revision/408.1.3
“made mid-ramp blinks more configurable per build target (allows for 1 or 2 mid-ramp blinks, at arbitrary levels, but it defaults to the old behavior at power channel boundaries)”
More specifically, it changed because a project needed that part of the code to do something it wasn’t capable of… so I made it more flexible.
you added 5 modified cfg files recently, still lights like ROT66 where I added the undef refused to work and it took me quite a while figuring out why it does the stupid mid level blinks
Also Matemineco asked me why the last Weekend build hex files do that middle blink
I downloaded the Anduril.c and all 2019 changeed configsyesterday between 10:00 and 10:30
I downloaded first Anduril 10. Jan 2019 where it was not changed
then I downloaded yesterday all files that were on sever done in 2019
Q8 should not have that middle blink as well
It sounds like you should probably use bzr instead of downloading files one at a time. It really helps with a lot of things.
what is bzr?
its also annoying that a lot of changes have to be done to make it run on Atmel studio
Main.c
//#define FSM_BLF_GT_DRIVER
//#define FSM_BLF_MF01_BUCK_DRIVER
#define FSM_BLF_MF01_DD_DRIVER
//#define FSM_BLF_L6
//#define FSM_BLF_GT_MINI_DRIVER
//#define FSM_BLF_Q8_DRIVER
//#define FSM_EMISAR_D1_DRIVER
//#define FSM_EMISAR_D18_DRIVER
//#define FSM_EMISAR_D1S_DRIVER
//#define FSM_EMISAR_D4_DRIVER
//#define FSM_EMISAR_D4_219C_DRIVER
//#define FSM_EMISAR_D4S_DRIVER
//#define FSM_EMISAR_D4S_219C_DRIVER
//#define FSM_FF_ROT66_DRIVER
//#define FSM_FF_ROT66_219_DRIVER
//#define FSM_FW3A_DRIVER
//#define FSM_SOFIRN_SP36_DRIVER
/* specific settings for known driver types */
#include “tk.h”
#if defined(FSM_BLF_GT_DRIVER)
#include “cfg-blf-gt.h”
#elif defined(FSM_BLF_MF01_BUCK_DRIVER)
#include “cfg-blf-MF01-Buck.h”
#elif defined(FSM_BLF_MF01_DD_DRIVER)
#include “cfg-blf-MF01-Buck.h”
#elif defined(FSM_BLF_L6)
#include “cfg-blf-L6.h”
#elif defined(FSM_BLF_GT_MINI_DRIVER)
#include “cfg-blf-gt-mini.h”
#elif defined(FSM_BLF_Q8_DRIVER)
#include “cfg-blf-q8.h”
#elif defined(FSM_EMISAR_D1_DRIVER)
#include “cfg-emisar-d1.h”
#elif defined(FSM_EMISAR_D18_DRIVER)
#include “cfg-emisar-d18.h”
#elif defined(FSM_EMISAR_D1S_DRIVER)
#include “cfg-emisar-d1s.h”
#elif defined(FSM_EMISAR_D4_219C_DRIVER)
#include “cfg-emisar-d4-219c.h”
#elif defined(FSM_EMISAR_D4_DRIVER)
#include “cfg-emisar-d4.h”
#elif defined(FSM_EMISAR_D4S_219C_DRIVER)
#include “cfg-emisar-d4s-219c.h”
#elif defined(FSM_EMISAR_D4S_DRIVER)
#include “cfg-emisar-d4s.h”
#elif defined(FSM_FF_PL47_DRIVER)
#include “cfg-ff-pl47.h”
#elif defined(FSM_FF_ROT66_DRIVER)
#include “cfg-ff-rot66.h”
#elif defined(FSM_FF_ROT66_219_DRIVER)
#include “cfg-ff-rot66-219.h”
#elif defined(FSM_FW3A_DRIVER)
#include “cfg-fw3a.h”
#elif defined(FSM_SOFIRN_SP36_DRIVER)
#include “cfg-sofirn-sp36.h”
#endif
It’s kind of an important thing to know about if you’re working professionally with code in a bzr repository.
Those changes don’t actually need to be done to make it compile in Atmel Studio. I removed all that stuff because it’s not necessary. It only needs a single include, or a “-DCONFIGFILE=cfg-something.h” passed to the compiler on the command line, to pull in the bits which are specific to individual build targets.
you really want that non professional users use some sort of command line and remove the code that works with build solution button?
I know you are used to user some fancy software which uses a sort of libary and can handle different versions and all sort of stuff, but
normal BLF users
download Atmel Studio
download Anduril Project someone else made
or
have to download each file individually on ~toykeeper/flashlight-firmware/trunk : files for revision 250
put all the nessesary files together from various different folders
uncomment the config file name
may do some modifications in cfg file
hit F7 to build the hex
now 3 options
- AVR integrated flash tool
- use USBasp integrated in tools
I’m a normal BLF user, I think anyway.
I know nothing about coding. But I learned how to use basic BZR functions, because it’s much easier to download the whole directory to work with that way. Launchpad even puts the bzr command with the URL loaded into it at the top of the page, super useful.
Never could make atmel studio work properly, but I like the way TK has it set up without it 
Besides, she’s the one doing all the commits? Shrug
I don’t expect everyone to use a revision control tool, but not everyone is working with companies to mass-produce commercial items with my code. That type of work is going to involve some kind of source code revision control tool like Bzr or Git. Also a pretty healthy understanding of the GPL.
Imagine if I had spent the past few months modifying your PCBs, getting lights produced with them, and complaining about it… and then I mentioned that I’m editing the layouts with Notepad. So you tell me I really should be using Diptrace. And then without looking it up or reading the guide linked in your signature, I ask, “what is diptrace?” For an encore, I follow up with a comment about how it’s too fancy and normal people shouldn’t have to use fancy tools designed for the job I’m doing.
Hello, I need some help getting my FT03 working again! I tried to flash it to Anduril tonight, I thought the pin out might be the same as a GT_Mini driver because a comment from Tom but that wasnt the case.
I can get by modifying code but the setup part has always been over my head, I thought I had the registers figured out but it doesnt work at all now (it did light up with the GT_Mini build but never shut the LED off all the way cause of the conflict with the AUX LED pin and only one channel worked).
The FT03 driver pinout is as follows:
1x7135 is on pin 3 (PB4)
FET on pin 5 (PB0)
SW on pin 2 (PB3)
AUX LED on pin 7 (PB2)
I tried editing the Emisar D4 HWCFG file with these lines:
But that didnt do it, infact that broke it more than the stock GT_Mini file!
Could someone maybe make a HW config and HW Define file for the FT03 or atleast walk me through the process to get my (now dead) FT03 running?
Ahhh, I could not determine the pinouts so I wouldn't have stated it. Best thing to do is take the source code of NarsilM for this light from the link TA provided, and determine the pinouts from there - that should be the best most reliable way.
Ohh, here is TA's post with the link: https://budgetlightforum.com/t/-/54922/2219
After reading the post again, TA sure isn't certain it's what they used but I'm thinking it is.
Update: Ok, I looked it up myself. It looks like the FT03 uses the same pinout config as the S43 and S42, documented in NarsilM (RegisterSettings.h) as this:
/*
* ---
* Reset PB5 1 -| |- 8 VCC
* switch PB3 2 -| |- 7 PB2 Ind.LED
* 7135 PWM PB4 3 -| |- 6 PB1 Not Used
* GND 4 -| |- 5 PB0 FET PWM
* ---
*/So what's unique is using pin#3 for the 7135, then the Ind. LED goes to pin #7, with pin #5 for the FET.
The normal FET+1 pinouts are this:
/*
* ---
* Reset 1 -| |- 8 VCC
* switch 2 -| |- 7 Voltage ADC or spare
* Ind.LED 3 -| |- 6 FET PWM
* GND 4 -| |- 5 7135 PWM
* ---
*/
Now I didn't confirm this by tracing out the driver. How exactly are you programming the 85 on the FT03? Are you using some sort of pogo pin setup?
Just soldered short wires to the pads on the bottom of the driver.
So if I’m correct on the pinout what have I done wrong? If I’m reading the datasheet right I should be correct on the output compare registers too so why is there no light?
Ohhh, stupid me - just read your prev post in detail, so looks like you got the pinouts correct. Not sure if TK is supporting this combo though - there's some things that have to be done.... Not sure if she has all that flexibility built in. She would be best to answer - would take me time to research and/or test in Anduril.
Oh, direct soldering -- Ok, that's cool!
If you simply want to recover your FT03, then reload the stock firmware from TA's link. If this doesn't work, then Mateminco did make a hardware/firmware change we aren't aware of.
I don’t have any drivers like that so I can’t say for sure it’ll work, but I think the easiest method would be to tell it the light has three channels, and then put the PWM data out of order. More specifically:
Basically, PWM1 has the FET data, PWM2 is zero, and PWM3 has the 7135 chip data.
I’ll probably add proper support for this kind of layout eventually, but probably not until I have one to test on.
I had some discussion with Matemineco today
they seem to miss the blink at ramp floor
I did measurements with Oscilloscope and photodiode and could not spot the slightest hint of a blink
ideal would be a brighter blink like when doing battcheck so it is clearly noticeable
Maybe at the level the light was at the start of ramp-down? Or minimum(start level, some low but clearly visible level)?