Those people who write this bazaar wiki seem to think everyone is an expert programmer and know all the basics
with your link I get this error
Please
all I am asking is a zip or similar container with a working Anduril build for AS7
.
I am wasting again now almost 4 hours on this and can’t build drivers in that time for the community and I have not much time at all right now for weeks and its not looking better this year
I am close to quit Anduril with a March build like I did with NarsilM v1.2 and support no newer versions anymore
Add -fwhole-program to the CFLAGS in build.sh, and comment out #define USE_VERSION_CHECK from anduril.c (or USE_BIKE_FLASHER_MODE or another mode if you really need the version check)
disable 2 strobe modes works as well 99.7% full now
I got absolutely no idea how to do that, that file is not even on the dependencies list in my project
This is the code when open in my Editor
I use a simple build “Anduril” project button with my mouse
I use no scripts or make file or other stuff the programmers are always talking of to build 20 versions at once with different settings in them
My bad, I should have realized using Atmel Studio doesn’t use that build.sh. You might be able to get back some space by adding the -fwhole-program flag to the miscellaneous flags here:
But I haven’t tried it. I’m not set up to compile for AVR.
Right click on the project in the solution explorer at the right, and choose Properties, to find the menu I showed. Then add the -fwhole-program to that huge list of flags in Miscellaneous (or maybe to the shorter list in Optimization). The flags are separated by spaces, and are what get passed to the compiler I use on the command line instead.
If it still gives you trouble, and you’re willing to wait a few days, I can try to set up Atmel Studio for AVR myself and give it a try.
Oh, er, the “ramping-ui” firmware was never shipped on the D4. I think you’re probably looking for RampingIOS. V2 is under the Tom_E directory, and V3 is in the spaghetti-monster directory.
It’s configured in cfg-mateminco-mf01-mini.h, but it’s in the fsm branch along with all the other recent development. The trunk branch is only updated occasionally.
That’s really interesting. I’ve heard a couple other reports of similar things too. I didn’t make a D1 tiny1634 build target, so it’s probably using a D4 V2 driver.
That should work okay, I suppose. Not much is different between the two configurations. But the thermal regulation might act a little weird, pulling the output down faster than necessary. I haven’t tried a D4 V2 firmware build in a D1, so I’m not sure if the thermal response is okay.
Hi, sorry about that. I forgot to add the FETless FW3A build target…
… until you reminded me just now.
It’s now included in the repository as cfg-fw3a-nofet.h.
Pretty much, yes. It needs to be in its native build environment unless you really know what you’re doing.
To set that up in Windows, step 1 is to install WSL. Either the Debian flavor or Ubuntu flavor should work.
From there, it’s mostly a matter of following the README in the code repository. There are a few commands to run to install other tools, and then the “make” tool should work.
Technically, it can be compiled in Atmel Studio, but it’s not easy and, as shown earlier on this page, people run into a lot of problems trying to do it that way. It’s not supported or recommended, and is an easy way to get headaches or bugs.
Hi, sorry about the delay in responding. There has been a lot to do… any help with thermal regulation would be really appreciated though.
It’s the part of the code I’ve struggled the most with, and a rewrite is definitely not a bad idea. The abstractions used make it a harder problem than it probably should be, but I haven’t found any good alternatives which still allow the UI and hardware abstractions the system is based on. In particular, keeping it portable across lots of different hardware. A fresh pair of eyes looking at it would be really helpful.
How do you feel about C? I know it’s controversial. constexpr math would allow the compiler to create ramps, so no external script would be needed. Also, templates would allow a more abstract PID to be adapted to specific hardware.
I’ve done C on embedded systems a couple times. It’s definitely possible. I don’t think it would help anything in this case though. Ramp creation and per-hardware code selection haven’t really been issues. Switching has costs though, at least in terms of time but also potentially in terms of code size. Some build targets are already at 99.8% full, and a change of language could easily push them over the limit.
There’s certainly an argument to be made for moving the ramp shape calculations from a table to an onboard formula, since working in units of linear power instead of perceptual brightness would probably make the thermal code a lot more reliable. But that’s unrelated to the language the code is written in.
I think treellama meant that the compiler will calculate the ramps.
Btw. a user at TLF (and who already contacted you here) wrote a new regulation that is absolutely amazing (at least in the simulation). Just not implemented in Anduril.
Yeah, that’s what I was assuming too. But there are reasons why it doesn’t calculate the ramp values on the fly, either at compile time or at run time. The ramp generally needs very careful fine-tuning to make it work well, and often even needs the calculated values modified by hand. The ramp calculator is a good start, but it doesn’t get us 100% of the way to the values the program needs.
Yeah, it sounds really promising! It sounds like things are waiting on shipping at the moment.
I suppose I hadn’t considered the need to hand-tune ramps. I’ve been replacing table generation scripts with compile-time generation and it seemed like the ramp would be a good candidate for that. An abstract perceptual-to-linear interface would also make it easier to do things like interpolate between ramp values for smoother ramps on small firmware.
Yes, but my D4V2s arrived yesterday, the Reflashing kit is still on its way. The firmware revision on my D4V2s is <= 450. The temperature target is set to 45 °C and the temperature sensor is properly calibrated.
