Let’s see…
It’s probably easiest to copy the .h files into the same directory as the .c file, as already mentioned. Or copy the whole repository and add “…” and “…/…” to the include path, wherever AVRstudio sets that option.
You’ll probably want to modify tk-calibration.h with values specific to your driver. This is basically voltage and OTC readings, as measured by the tools in the battcheck/ directory. Once you have the right values for your driver, it’s a good idea to keep a copy of that file somewhere for later use.
You may also want to calculate a new output ramp. The command line for this should be in a comment just above the current ramp, for easy reference.
As for getting everything built in Windows, I really don’t know. I haven’t used Windows since the 1990s. It sounds like others here have already answered a lot of that though.
It’s possible that could be caused by calibration values instead of actual logic bugs. Each person’s drivers seem to need slightly different values. The battcheck/README file should explain how to get the numbers it needs.
The “double check connections” bit is probably correct. That error only happens when the MCU doesn’t respond, meaning that there’s probably a physical connection issue. It could have a pin shorted, could be rotated 180 degrees, could have a pin not making contact, etc. There could even be solder hiding under the MCU where it’s not visible.
Or it could also mean the chips were severely under-clocked at some point and aren’t running fast enough to respond at the expected rate. I did that once, before I knew it would effectively brick the chip.
- I don’t have anything for AVRstudio unless a project’s author includes those files.
- The brightness is controlled by a ramp. IIRC, it’s called RAMP_FET in bistro-mini. Normally this would be a long list of 64 values per channel, but to save space it’s only 7 now.
- No.
- It doesn’t matter what program made it; it’s using the C99 language standard and avr-gcc tools+libraries.
You could replace each “include” line with the contents of the file it points at, and it would be literally the same as what the compiler does. But it’s usually easier to just copy the header files into the same directory as the C file.
Sorry about that. I normally don’t merge things into trunk until they’re fairly stable, and nobody except me had tested bistro-tripledown last time I touched it. But it can probably merge into trunk now that it has been used by more than just me.
The non-trunk branches are usually for development. Like, branch from trunk to a dev branch, make new features there for as long as it takes, then merge back into trunk after it’s all tested and working. Bistro-tripledown never quite got that final step.
The exception is a few project-specific stable maintenance branches, like blf-a6-final, which is frozen at the time the product released and only receives updates if/when the actual product is updated. Those are basically “stable releases”.
I’ve been leaving those in for reference, but commented out by default. This is because the build script sets that variable, allowing a single source file to compile perfectly on multiple MCUs with no changes. Here are the relevant parts of bin/build.sh:
...
export ATTINY=13
export MCU=attiny$ATTINY
...
export CFLAGS="-Wall -g -Os -mmcu=$MCU -c -std=gnu99 -DATTINY=$ATTINY -I.. -I../.. -I../../.."
...
run $CC $CFLAGS -o $PROGRAM.o -c $PROGRAM.c
...
run avr-size -C --mcu=$MCU $PROGRAM.elf | grep Full
So, if I use “build.sh” it compiles for attiny13, if I use “build-25.sh” it compiles for attiny25, and similar for “build-45.sh” and “build-85.sh” and any other MCUs we end up adding. No need to change the source for each MCU.
It uses the SRAM decay “noinit” trick to measure offtime, since the Convoy drivers have no OTC.