I don’t get why all this stuff with .h header files. Don’t people use simple one C file solutions? I do, it makes all this stuff so much easier to manage.
Anyhow, try this… found out where string.h is in your avr studio folder (if you are using avr studio) and copy all tk-*.h files to that folder. I use AVR Studio 7, and in my case the folder is:
C:\Program Files\AVRStudio7\7.0\toolchain\avr8\avr8-gnu-toolchain\avr\include\
This is the default include folder, all “default” header files that are included are refering to this folder. Includes that have avr\ in front are in the avr sub-folder.
If you have previously complied firmware which uses included files (such as eeprom.h) successfully, this should work.
Speaking only for myself, this C stuff is Greek to me, last time I tried to compile a program was in Assembly on a machine running CP/M, which was was before DOS was even a thing :–0
@Mike C, any chance we’ll get a try a version of your “UI #3 off switch ramping” for Attiny13 based drivers? Looks dandy.
i had to find and add a .h file to the folder mike.c specified (nice one tyty)
next question, i can either have memory mode or battery check, for a
battcheck, Program Memory Usage : 812 bytes 79.3 % Full
Data Memory Usage : 10 bytes 15.6 % Full
or memery mode Program Memory Usage : 842 bytes 82.2 % Full
Data Memory Usage : 12 bytes 18.8 % Full
the question being, how much memory needs to be ‘free’?
i know from the 3D printer boards/quadcopter boards and atmel chips they need up to 50% free memory or they start to choke a bit.
by enabling/disabling here for a compile that succeeds.(memory 250 and battcheck 251)
// 255 is the default eeprom state, don’t use
// (actually, no longer applies… using a different algorithm now)
// (previously tried to store mode type plus ramp level in a single byte
// for mode memory purposes, but it was a bad idea) #define DONOTUSE 255
// Modes start at 255 and count down #define TURBO 254 #define RAMP 253 #define STEADY 252
//#define BATTCHECK 251 #define MEMORY 250
//#define MEMTOGGLE 249 // Extra mode to (en/dis)able memory (requires MEMORY)
//#define TEMP_CAL_MODE 248 FIXME: NOT IMPLEMENTED YET
//#define BIKING_MODE 247 // steady on with pulses at 1Hz
Sorry, I can’t go back to doing anything in the 13a. I don’t have any around so I can’t even test, and with 16kb I’ve written everything freely. To fit anything on the 13a I would have to do some serious byte hunting. I won’t touch the 85 anymore either, I have too many projects in line to dust off any code that has to do with them.
I don’t know anything about 3D printer and quadcopter boards, but with our flashlight firmware the program memory doesn’t need anything free. Data memory usage is a different matter, I guess it depends on programming, but program memory (which is actual firmware size) can be filled all the way up.
thank you, with the printers n quads I think its as you’ve said the data usage, theyre using quite a bit more processing than the flashlight ui’s. In the case of the flight controllers, they have 4 motors continualy updating in 16bit hundred of times a second, a gyro, accelerometer etc etc all doing the same thing hundreds of times a second and all cordinating.
nar i have to sort the de soldering of the pill to get to the C8 driver out lol…yes i tried it in situe, as yu do just incase.
Hopefully the attiny chip will just accept the program …dum dum dummmm…drum roll lol.
I didn’t see this thread until today, but some people have reported that, instead of using AVR Studio, it’s easier to get things working using the Linux subsystem for Windows 10. I’m not sure exactly what one must do to install that, but once it’s there, it becomes a lot easier to make things “just work” by typing in a few short commands.
This probably isn’t very helpful, but a few people have found it easier than converting projects to Atmel’s build system so it might be worth a look.
most things on the the net are linux based, and ‘C skinned’ for windows, probably why more things are easier to do, alas, it’s only second hand knowledge.
i dont supose you could knock up a dimmer only with memory/memory off and lvp?.. (with little crawlies and pleasums…lol)
i’m newb, but i found some C command’s for ramping that i cant find now, was only a few lines but on par with the old printf 1-100 unless interupted…do you think its posable a simple ramp up or down could be implomented easily for clickies? may reduce the size of the UI enough to get the lvp etc to fit onto the attiny 13’s. just a thought.
For individual projects, yes. When multiple projects share the same code though, including a shared file is generally easier than keeping multiple in-line copies in sync.
Normally I’d have a set of .c/.h files for each logical group of functions, all compiled separately into .o files and then linked together into a single binary. That complicates the build system though, and for such small projects I doubt it’s really necessary.
I’ve used a similar approach in FSM though, just without the linker step, because the whole point of that project is to abstract out the hardware implementation details so the main program can be written with simpler more intuitive language. For example, this is a working clone of the Olight Baton UI, using FSM. It’s 5810 bytes of source code and includes basically everything except the self-timer mode. And for comparison, this is another Baton clone written using a single-file model. It’s 18211 bytes, includes significantly fewer features, has more bugs, and is harder to read.
That’s only one small data point in a sea of code… but it still demonstrates fairly common patterns which often result from different approaches to code organization.
I certainly agree that with complex projects it makes sense, but for flashlight firmware I would just use copy and paste if I had multiple firmware files. I don’t have multiple files myself, I have them all in one and decide which one to compile with #defines. Makes backup real easy… a single file… One file to rule them all.
I’ve been meaning to add tiny841 and tiny1634 support to FSM, both to enable more hardware features and to make the supported UIs portable across a wider range of hardware. It’s sort of a cross between a UI toolkit and an OS kernel, but it currently only supports tiny25/tiny45/tiny85. So I’m trying to help enable new hardware designs by supporting new hardware.
If you’ve already gotten things working on either of both of those, is there any chance of sharing the code you created to bootstrap the chip and get PWM going? It doesn’t even have to be shared publicly; I’m mostly just looking for working examples to use as a reference.
am i right in thinking the attiney 13/13A’s can be ‘directly replaced’ with the attiney 25/45/85 chips? the 13A has a working voltage from 1.8-5.5v and the 25/45/85 a working voltage of 2.7-5.5v ?
could fit bigger programs onto standard 13A sized drivers then
In most cases, yes, the attiny13a can be directly replaced with attiny25v. However, tiny13 can tank a lot of electrical noise and operate pretty far out of spec, while the tiny25 cannot. So in some cases, tiny13 might work while a tiny25 would end up rebooting a lot due to voltage spikes. It depends on how well the driver insulates the MCU from the LED power.
Tiny45 and tiny85 are slightly bigger, and don’t easily fit onto the same layouts. However, they typically still fit after bending the legs underneath.
Crescendo is primarily meant for FET+1 or FET+N+1 drivers with a tiny25, though it can also work on 13, 45, and 85, or with just one power channel.