Severity Code Description Project File Line
Error MakeFileGenFailureException captured - Value cannot be null.
Parameter name: source GccApplication1 C:\Program Files (x86)\Atmel\Studio\7.0\Vs\Compiler.targets 5
any ideas?
Each type of driver has its own layout definition in tk-attiny.h. Unless, of course, the particular driver type isn’t in there. The file really is quite a mess…
To select one, put a “#define FOO_LAYOUT” in your .c file before the line which includes tk-attiny.h.
You may also need to “#define ATTINY 25” or similar too, if your build system doesn’t define that at compile time.
I still haven’t actually tried building any of this stuff in Windows though, so I don’t really know where to hit it to make it work.
In completely unrelated news, I have a new code foundation in progress for e-switch lights. It’s nowhere near ready yet, but I do at least have it running a momentary single-mode UI with low-voltage protection, as a simple first example.
It’s an event-driven stack-based finite state machine, basically, and each UI file only needs to implement a few relatively simple things to get a working firmware.
The first working example is here.
I haven’t really decided on a name yet. Originally it was going to be RoundTable, since it all would revolve around a big state transition table, but it turned out to be a better idea to use simplified code instead of a big table. I might go with something related to finite state machines instead… like FSM or SpaghettiMonster.
Anyway, the upshot of all this is… it makes e-switch UIs dramatically easier to write.
Sounds good! Always for new innovation.
For a less-trivial example, here’s something very similar to the Olight Baton UI, built using SpaghettiMonster (Er, RoundTable? Never let me name anything…). I have it running right now on one of my Emisar D4s:
http://toykeeper.net/torches/fsm/baton.c
It has 7 regular levels and 6 speeds of party strobe (freezes motion). The interface is, basically:
From off:
- Click: Turn on at memorized level.
- Hold: Turn on in moon mode. Keep holding to ramp up.
- Double-click: Turn on in turbo.
- Triple-click: Turn on in memorized strobe mode.
While in a normal output mode:
- Click: Turn off.
- Hold: Ramp up (wraps around from top to bottom like Olight UI does).
- Double click: Go to/from turbo.
- Triple click: Go to memorized strobe mode.
In strobe modes:
- Click: Turn off.
- Hold: Change strobe speed.
- Double-click: Go back to memorized normal mode.
On battery connect: Blink twice then turn off (standby mode).
… and just like a real Baton S-Mini/S1/S10, it has no LVP yet. 
(but at least it’s not hard to add)
Neither moon nor turbo is memorized unless you ramp to it.
The interesting thing about the code is that it reads very much like the list above. Writing a new UI isn’t much harder than writing a list like that — a definition of states, actions, and state changes. The code and the UI description are actually close enough that I could probably auto-generate UI descriptions or diagrams from the code.
Anyway, I’ll keep adding new UIs while I flesh out the rest of the base code. It probably won’t be long before I have an army of UI clones. And when it’s stable and robust enough, I’ll add it to the main repository.
I try to understand programming but trying to decipher a whole program is a bit much when your starting from zero. I love using Bistro but if I stare at the program long enough the last half turns into clutter and confusion.
How hard would it be to make a program like this modular? Have a couple really basic base files for one, two or three channels so newbs like me can get a light working, play around with a few parameters and understand the little bit of code that is there.
Then copy in voltage monitoring and figure that out. After that choose temp monitoring, strobe modes, ramping or whatever else you can squeeze in before running out of memory. If someone creates a piece of code for an indicator light they can add that module to the repository.
Ideally this wouldn’t be much extra effort or get people bombarding you with a bunch of questions.
That’s kinda what I just did. Code has a tendency to twist and turn in knots like spaghetti, so I tamed the spaghetti monster and put it on a leash to keep it from making a mess.
Does the code I posted a couple comments ago make sense?
- Example 1 (1-mode momentary UI): http://toykeeper.net/torches/fsm/momentary.c
- Example 2 (similar to Olight S series): http://toykeeper.net/torches/fsm/baton.c
That doesn’t help with compiling, since getting a “hello world” program to work can be a difficult step… and how to compile on Windows is by far the most common question… but once the toolchain is working I hope this new code will make it easy to do the rest.
It’s a lot easier to look at, I just need to find the attiny instruction set to understand the terms. I was afraid it was going to look a lot different when you were done,
I’ve played a bit with Atmel studio 7, trying to get everything to show up in the solution window is the hard part there. I found one of Tom E’s complete Bistro projects, opened it up, compiled it and flashed it to a bare 25.
The guide War-Hawk did helped, too bad photobucket killed all the pictures. Your pictures and shopping list for the clip made that part easy.
One day I’ll open up my arduino uno starter kit, type in a hello world program, write it to the mcu with arduino IDE and this stuff will all make sense. There is a way to program an attiny with the uno, but I don’t know where the hex comes from. If they are compiling it from the arduino environment it would make things a lot easier. It’s made for beginners and flashing with avrdude isn’t too bad.
I was looking at example 1 and it is indeed much simpler to look at.
One thing that always confuses me with code is when something just appears with no apparent attachment to anything else but yet it works.
For example: if (event == EV_click1_press)
Where did the “EV_click1_press” come from? I doubt that is a base command in C code, so where did it come from and how does the code know what to do with it? It appears no where else in the code.
I would expect to see it at least 1 other place in the code in order for that event to be defined as something.
This is generally where I put off learning code, when something that just doesn’t make sense pops up and that you can’t really search google for an answer to without taking an entire course on C code.
I generally learn best by doing it, which means learning as I come across problems and then learning how to fix them. In the case of code I can never seem to find the answers to the problems I encounter and thus have never really put a lot of effort into learning it.
Still, it is much simpler code and would be WAY easier to figure out.
The code only has one “include” line, which makes the symbols relatively easy (ish) to find. The EV_click1_press symbol is defined there. It has a whole table of event types with details about what each one means. The UI code doesn’t have to care about where those events come from though; it only needs to handle them when they happen.
The way this works is very similar to most GUI toolkits, only without the G.
In any case, I’m including a bunch of example UIs to help show how to do things.
I’m not sure if this approach will work for power-switch lights, but so far it at least works pretty well for e-switch lights. Power switches are harder to abstract away, since it will reboot at random times and persistent memory is very limited.
I guess the define is in another file, I have never been able to really “get” the multiple files for the code thing. It makes total sense but when you are stumbling your way through the code it makes it really hard to figure it out when you search for a command somewhere else in the code and nothing comes up and you have no idea where it might be.
I generally forget there are other files that tie in at all to be honest.
Would the TA board work like Pilotdog68's tripledown V2 by cutting a trace and controlling 2 xpl's on the fet+1 channel and 1 red xp-e2 separately on the +#7135's channel on a triple noctigon? Using bistro?
If so could it be done with an LDO OTSM board with bistrohd?
If not I'm just gonna use PD68's tripledown. I would just rather use the newer circuit and firmware if possible.
There was not enough room on the board to allow for a totally separate channel. It was simply too cramped.
The tripledown is your best bet in this case.
Thanks Texas_Ace. By the way I’ve had good results with your boards and the BitroHD and OTSM on the LDO boards works great!
Glad to hear that they are being put to use! I have not built a light in months myself, in fact the xhp70.2 mod for the GT will be the first one in quite some time. Simple but should be fun.
Can’t wait to see that in action!
TK, would it be difficult(how many times have you read a post start like this? 
) so I’ll reword that: TK, how hard would it be(never mind :person_facepalming: ) to incorporate both smooth ramping and mode sets into one UI? So, in your baton ui example above, when you say “ramping” it would truely mean smooth ramping. Nothing else different. Still click for on and off, hold for moon then ramp, and so on. When on, a click and hold would ramp up and another subsequent click and hold would ramp down. I could see the need for soft start here or a quick ramp up to the next mode set level. Otherwise it would be difficult to read wether or not the user is going to click or click and hold. Actually, after thinking while I’m typing I’m seeing there would be a number of conflicts to deal with. I had thought of this before and was reminded when I read your baton ui example above and it would be cool if it could be figured out. 
I’ll probably do smooth and discrete ramping in the same firmware eventually… I just haven’t yet.
I can at least say it won’t happen today. Today I’m busy testing out my new “flashdark”. It’s like a flashlight, only instead of making light in the darkness, it makes darkness in the daytime.
I added thermal regulation to SpaghettiMonster today. In my test host (an Emisar D4 head with the driver hanging out), with the threshold level set to 30 C, I can make it step down just by breathing on it.
Here’s the code I used for testing:
http://toykeeper.net/torches/fsm/baton.c
Oh, er, I also added LVP to the Baton UI. It only took 5 minutes to write the LVP code, flash the driver, and test it.