That’s not how software projects work. Each project has its own build system, its own instructions for turning the sources into an executable. If you don’t follow those instructions, you’re choosing to make things difficult for yourself.
I’m not going to de-organize the project and rewrite all its internal infrastructure just to make it easier to build with proprietary tools it was never intended to be built with.
In Windows, there are two easy ways to compile it: WSL or Docker. Pick one.
It already does. One of the first steps in setting up the build environment is to download and install DFPs directly from Atmel, which make dfp helpfully does for you.
Git doesn’t have revision numbers like r817. It has commit IDs, like bc0b4625a1618d9322ea6a5f0bb402f8ddc0aad6 (or bc0b462 for short). I’m not super happy about it either, but it’s what people use. Regardless, the repo currently has 1178 commits in it, and a lot has changed since the last bzr version.
To do things in a more git-like manner, the version string is instead derived from the most recent release tag… potentially with extra info at the end to indicate how many commits since the tag and whether the repository is in a clean or dirty state. Like, yesterday’s release was tagged r2023-12-03, but if I were to add 158 commits and build in a dirty repo with uncommitted changes, the git describe tool would report the version as r2023-12-03-158-g0abcdef-dirty. This is then shortened somewhat to produce the version string used by Version Check mode: 2023-12-03+158#1. I’m still undecided whether it should include the rev short-hash in builds like that, but at the moment it omits that part. Official releases have a tag though, so it’s just the date with no +N or #1.
Anyway, the short revision numbers are gone because Linus Torvalds was feeling spiteful and contrarian in 2006 when he created Git.
Compiling is one thing and another thing then trying to code. Before “r817” all we had to do to update Atmel project was to drop new version files on top of old… . Now in Github style You added directory patches inside files like “fsm/ramping.h” before was just “ramping.h” and then all files are in same directory … now I have to rewrite every f single files patches… and i did and it does not compile anyway :DD
I recall you putting everything into one directory and then updating individual files one at a time… but that was never a supported way to build the code and it’s not how most software projects work.
Weren’t you doing that just because Launchpad’s tarball feature was broken and bzr didn’t work very well in Windows? Git has much better Windows support. All you have to do to update your local copy is git pull origin trunk or click the “pull” button in an IDE. Most of them have Git support these days.
Regardless, it’s not going to work with everything in one directory. Half the files have the same file names but in different directories. The directory structure is a semantically important part of the build.
So… install the latest debian or ubuntu in WSL. Run a couple apt commands to get build dependencies. Git clone the repo. Run make dfp. Then run make. That’s how to build it in Windows. That’s also basically how GitHub’s Continuous Integration system builds the code after each commit, so you can be pretty confident it’ll actually work.
The release file will include all the various hex files, unzip it on your phone and then use ZFlasher to select the one you want to flash to a particular light.
There may be a simpler way, but I’m not the dude who can tell you what it is!
This would clarify another regular question on reddit, so the only challenge remaining is to try to get reddit to RTFM… (and stop posting links to out of date resources).
I find the manual is about the only source worth using anymore… Not knocking the work people put in making the diagrams, but with the continual evolution of A2 it’s gotten much harder to find the current one.
It took me a month to figure out what I was doing just locating the hex files on GitHub - I’m way out of those loops anymore, but it’s not too difficult.
Its s hefty light with good heat sinking. No matter what I do I can’t seem to get the temperature sensor working right. No matter what I set it do what i get is “30 seconds” before the sensor kicks on and output drops.
Programming behavior seems normal.
The ambient temp in my shop is 26C (80F) so when enter the temp window (the light flashes quickly) I can do 26 clicks. I wait, get 2 slower flashes, then a fast flashlight again where I enter the 30, or even 40 clicks. Then wait, and it exits back to temp check (or whatever) Changing the max from 10 clicks to 30, or even 40 (the 70C max) has no effect.
The only way that I seem to be able to get past the 30 second mark is if instead of accurately setting calibration to 26C, I set it to 1C. Then I got clear out to a minute, but the light is in no way hot by then. It just barely warm around the neck.
Has anyone experienced this behavior before?
Is there a know defect with the convoy drivers?
It sort of acts like maybe its not actually changing the max temp from the default of 45C.
Using a newer version of the firmware might help. The thermal regulation has been modified several times since that ancient version Convoy used. It was already long out of date when the driver was first produced.
It might also help to use firmware which was calibrated for the light it’s being used in, instead of using whatever mismatched build Convoy had. A light which heats up slower may need different parameters for the thermal regulation algorithm. Convoy probably just copied the firmware from an original Emisar D4, like some other brands have done… and the D4 was tuned to regulate down quickly because it was massively overpowered and could start fires in like 5 seconds.
Could also help to improve the thermal path from LEDs to the host. There’s a significant chance the inside is hot even when the outside isn’t, and it’s the inside which gets measured.
Is there a know defect with the convoy drivers?
Yes. The driver uses very inefficient power circuitry and ancient firmware which was never intended to be used on this hardware. To make a proper Anduril driver, it’s important to go through a hardware enablement process, to create a new firmware build target specially tuned to fit the hardware… but in Convoy’s case, that didn’t happen. So it doesn’t fit, and doesn’t work well.
It’s also strongly recommended to ensure the driver circuit has easily-accessed pads for flashing firmware, so users can update when new versions come out, or customize it to fit their needs. But I don’t think that happened either. So… it’s one of the worst Anduril drivers money can buy, and is not a supported build target in the repository.
I wish I would have know that before I engineered this into a project and ordered 200pc of that circuit. I cant believe I didn’t catch that sensor issue until now.
You did an amazing work with all your coding knowledge and knowledge about flashlights wherever you you put you make the best and right decision for your work
