Flashlight Firmware Repository

I use Atmel Studio 7 to compile, and avrdude to flash.

I just copy/paste the commands from a txt file, so if I need different ones for the 25 can somebody help with those.

Tom, that would be great. I am totally clueless on how to use the header and bat files.

I haven’t even looked at the code for bistro, I’m hoping it’s still easy to remove things. I like simplicity, but I just noticed LVP is nonfunctional on the modified version of blf-a6

But really step by step would be great. Like currently I do this:

  1. pull open c file in wordpad
  2. alter mode groups/turbo timer (by comparing to similar lights I have that had good levels)
  3. copy code to new project in Atmel7
  4. compile to hex
  5. copy command line to avrdude
  6. flash

Hey guys. I hate to barge in but I see your active conversation and I’m in a bind.

I am getting error message:
program enable: target doesn’t answer. 1
Initialization failed, rc=–1
Double check connections and try again, or use -F to override this check.

I’m trying to flash Bistro onto pds triple stack but I get the this error. I think it might be related to using a different attiny25 than I was using before, but I’m unsure. Any help?

This is the chip I am using:
AVR AVR® ATtiny Microcontroller IC 8-Bit 20MHz 2KB (1K x 16) FLASH 8-SOIC

ToyKeeper, a couple of questions about the Bistro-mini firmware.

  1. Do you have Bistro-mini project for AVR Studio?
  2. What a piece of code responsible for the brightness in the Moonlight and the low mode?
  3. Will LED glow in the Moonlight if we take the driver for 1050 & 1400 mA?
  4. I tried to open your C-file in AVR Studio but received entirely errors at compile time. In what program it is made?
    Thanks

I use avr studio and it works with her file. There are a number of other files that it needs to compile. Such as tkvoltage.h and others. To adjust moon mode change the value of the first entry for the 7135 in the ramping table

I change the first value in all columns to 0. Then I have an “off” mode for silent switch activation

Hhmm, that's not a real part#, I think?? It should say TINY25 or TINY25V right on the top of it - pretty sure. Those specs are correct though, for a 25.

You are checking for a 25 device though, not a 13A - guess so if you've done 25's before...

Is that the only new 25 you have? If you have more, try "air" clipping one and see if it works. If you have a grnd/short on any of the traces/connections connected to the MCU pins, it causes problems. I've done "air" clipping before, and it always works.

Serp - you need all the required header files to compile it. I didn't try yet, but not sure where they are all at in the repository.

TK works in unix/linux only, last I understood, so doesn't use ATMEL Studio.

Luddite question: if I don’t want to use the .h file, can I just add all the “defines” back into the main bistro .c ?

hmm. yesterday i reflowed three boards. one texas advenger and two triple stacks. i used one chip from the old batch and two from the new. All three give me the same error. this would make me think its the connections, but i tested two boards that i built last week with the same old chips and they all register fine. Man this stuff is confusion. ill start checking for solder bridges and stuff, but all three from yesterday? Maybe i used too hot of a reflow temperature and burned the chips. Also, i have one new chip left. i will dig that out and try the air clipping.

Of course! I thought bout that, actually, but I work/edit right in the Studio environment - works just like Microsoft Visual Studio, which I use every day @work, because it actually is Microsoft Visual Studio btw. So, I just add the header files to the project and they are very easy to work with inside the editing environment.

If you use my solution/project files as-is, that's what you would get.

oh ya. i am using the tiny25. Air clipping my last unprogramed chip gave me the same error. So i am getting the error on all unprogrammed chips and not on any that i have already programmed. i guess it has to be my programmer then. i will try and rewire it now.

Btw, where is bistro TripleDown? Didn’t see it in the bistro folder?

Tripledown
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/files/head:/ToyKeeper/bistro/

It’s under the tiny25 directory. Kind of confusing

It is confusing getting around in that repo, it is in the tiny25 section: http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/tiny25/files/head:/ToyKeeper/bistro/

EDIT: LR beat me to it.

LightRider, Tom E thanks. I will try to find the necessary files. But for me it is very unclear done this Page Flashlight Firmware Repository in Launchpad
Can I ask you to make an archive of the project for AVR Studio 4, or 5, or any other. With the right file … :frowning:

PS Is this what I need? http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/convoy/files/219/ToyKeeper

After everything… All I needed was a computer restart. As a longtime windows user I should have known better. :person_facepalming:

serp: I’m not very knowledgeable with this stuff so I cant give you a step by step. how far have you gotten. have you ever flashed custom firmware prior to this?

the bistro mini .c file should be ready to go as is except you need to alter the directory of the files called for in all of the “include” commands that use “example file”. the include commands that use < and > do not need to be addressed.

I’m not confident with this stuff but maybe it will help some?

Only Studio 7 - that's all I have/use. I try to keep current with the latest version on it. I find it confusing as well.

Well, what I should do is make a working/tested bistro and bistro-mini Studio 7 solution, so two complete working ones (I believe I have the bistro done already).

I looked at the "mini" source quickly this morn and wasn't sure bout the bistro-mini.c and tk-attiny.h combination, because the mini source has the #define for "ATTINY 13" commented out, so looks like F_CPU never gets set. Ultimate test though is to compile/link and see if it works. Looks like guys have already built it successfully, so it must work, I would think.

Also not sure of her technique on detecting long/short presses, without an OTC, but maybe she doesn't detect that? Not sure how the UI works again.... My fault... Not sure if the mini version uses ON time memory or OFF time memory...

I myself rewriting firmware for the flashlight. Few understand this. Maybe Monday will try to deal better with this new firmware.
On fonarevka.ru I mostly used Tamagotchi
bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/view/head:/Tamagotchi/7135x8v2/README
http://bazaar.launchpad.net/~toykeeper/flashlight-firmware/trunk/download/head:/readme-20150406202629-xmo8czit612270ff-1/README

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. :frowning:

  1. I don’t have anything for AVRstudio unless a project’s author includes those files.
  2. 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.
  3. No.
  4. 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.

Okay. All pending updates to bistro, bistro-tripledown, and bistro-mini (biscotti) are merged into trunk. And I marked the tiny25 branch as merged (and thus not shown by default) since it’s merged and no longer in active development. Now the only branches visible by default are trunk, sandbox, and three stable releases for specific products.

Hopefully that’ll help make things a bit simpler and easier. :slight_smile:

Of course, there are a bunch of other things to catch up on too…