Crescendo clicky firmware by TK

Yes.

The crescendo.c is the source C code file. The Crescendo.hex and Crescendo25.hex (for ATtiny25 based driver) are two compiled version. These can be customized and re-compiled/built following the instructions in crescendo.c file for driver specific differences of various driver.

thank you.

been trying to get the C file to build…hmmm

ok, it’s time to ask,

i keep getting

tk-attiny.h: No such file or directory
recipe for target ‘main.o’ failed

and after ferkin with this and that (like i have a clue lol)

the calibration library/directory then gets listed in the failed build as no such file or directory.
(i’ve added the directory/library files that come with the cresendo into the library folder in Atmel studio as advised on youtube by various peoples, right click library file, browse to the folder, select the directory files and ok, they then appear in the solutions part in the library folder).
The furthest i’ve got with this is to get all the directory files mentioned as no such file or directory in a failed build.

i’m using Atmel studio 7, and get the same results in Atmel studio 6.2.
the torch is a Convoy C8 with the red driver board that it came with . (i think i saw the BLF guy on you tube call it the driver the NanJG type but…erghh.)

i notice in the comments it said ’‘// Also, assign I/O pins in this file’’, what do i define as what? and where?

and i don’t see any cpu frequency setting, do i need to add that too?

also there’s a line above the ramp setting ’’ …/…/bin/level_calc.py 1 64 7135 4 0.25 1000’’ i assume this is paired with the ramp line #define RAMP_CH1 4,4,4,4,4,5,5,5…… after it, as in uncomment the line?
….just to get more fun out of it, ermm i see more than one ramp channel? ermmm? need i give up lol…

(bare in mind i’ve just got the blinky code working on a free standing 13A chip…)

basically i’m looking for ramping, no flash modes and memory,and moonlight, can any body help or point me to some proper reading?
where’s the error code list and explanations for Atmel studio? and there must be a good C language dictionary some where, the one’s i found all say things like ‘char… chars it in alien talk by folding nonigomo’bi directional oddey ferkums to the’ … and so on. I found some ramp/float code that looked like it was simple for ramping, can i find it on a google again, neeeee-ope.

(google really isnt your friend lol! it’s more like a Pinokio episode at some fun park, eee-ore…eeee-ore)

Carpmom43, I’m not a coder but I’m glad to share what I know and/or have figured out over time, lots of time.

The error is referring to a needed “include” file which in this case is “tk-attiny.h”. The compiler needs to know where that and any other support files are located. Many of the programs support files have their Paths declared as a part of the Amtel Studio’s configuration options. Others, particularly files unique to a user’s *.c files must be provided.

I personally place a copy of the referenced *.h includes (tk-attiny.h, tk-calibration.h… - located in TK’s main repository directory) in the same location as the main/crescendo.c file to make my life easier.

Some of the other parameters such as CPU frequeny, Pin assignments etc. are configured in the other referenced Include files based on the HW configuration that you declare such as “#define ATTINY 13” and “#define NANJG_LAYOUT”.

Earlier I recall some of the *.c files containing path prefixes with “…\.\” these simply point to directories two parent directories up; again, just change as needed to point to the actual locations on your computer.

I believe the red convoy driver is single channel so you will need to pick one ramp, which ramp will depend on smoothness, capability of the driver to light on lower levels, etc. and I don’t believe the …calc file is needed when using the suggested ramp levels.

I hope that helps a little.


Also, I think it’s been referenced before but it is certainly worth repeating. gChart’s compiled ramping_UI.hex for the Attiny13 is a simpler ramping without all the features but has worked for me straight out of the box.

yes that does help, thank you.

think i’ll admit defeat on this one, still cant get any .h files to ‘register’…must be summut i’m missing for all files to be unrecognised. ahhh well back to google punishment.

I’m starting flashing again after a long break so I’m refiguring this stuff out. When I was compiling crescendo today I had similar errors. In my case atmel was creating a folder within the main directory. The various .h files had to be in that folder in order for them to be found.

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.

ah-haaa, i shall give it go, thank you.

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

the .h file was from here (hwdef-FET_7135.h)

.h file

and just in case the web page vanish’s as they quite often do. (copy and past, save as whatever file and change the file exstention to .h.)

/* FET + 7135 driver layout
* ——
* Reset |1 8| VCC
* OTC |2 7| Voltage ADC
* Star 3 |3 6| PWM (FET)
* GND |4 5| PWM (1x7135)
* ——
*/

#define STAR2_PIN PB0 // If this pin isn’t used for ALT_PWM
#define STAR3_PIN PB4 // pin 3

#define CAP_PIN PB3 // pin 2, OTC
#define CAP_CHANNEL 0x03 // MUX 03 corresponds with PB3 (Star 4)
#define CAP_DIDR ADC3D // Digital input disable bit corresponding with PB3

#define PWM_PIN PB1 // pin 6, FET PWM
#define PWM_LVL OCR0B // OCR0B is the output compare register for PB1
#define ALT_PWM_PIN PB0 // pin 5, 1x7135 PWM
#define ALT_PWM_LVL OCR0A // OCR0A is the output compare register for PB0

#define VOLTAGE_PIN PB2 // pin 7, voltage ADC
#define ADC_CHANNEL 0x01 // MUX 01 corresponds with PB2
#define ADC_DIDR ADC1D // Digital input disable bit corresponding with PB2
#define ADC_PRSCL 0x06 // clk/64

//#define TEMP_DIDR ADC4D
#define TEMP_CHANNEL 0b00001111

#define FAST 0xA3 // fast PWM both channels
#define PHASE 0xA1 // phase-correct PWM both channels

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.

if i may ask what chips are you up too?

i second that.

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 already did… it’s called Crescendo. It fits onto attiny13 when the optional blinky modes are disabled at compile time.

ahhh, i see. ty ty.