This is where I ran into issues. It would compile Star firmware fine but threw a fit of errors when I tried to compile anything from TK. Never could figure out the cause and gave up because it worked perfect in Linuix with TK’s scripts.
I would like to be able to compile it in atmel studio though, it is nice to be able to edit, compile and flash all from the same program (yes, you can setup atmel to automatically flash via AVRdude).
I drag and dropped the project file into my avrdude folder that is on the c: drive. This made it much more simple as I was continually saving the .hex files in the wrong place. All my .h files are there as well so they all have the same file path.
When I create a new executable project it asks me what mcu it is for. I don’t mind doing it every time because it’s literally three clicks and that’s the only setting I have to specify.
I have no idea what other files you are talking about Tom, I’ll try to send a screenshot when I get home today but with the 13’s I have never had anything other than .c’s and .hex’s.
I keep copies of all the .c files I have flashed so I can go back and see what values I used in each light. So I guess now I’ll have to have a folder for each light with the .c’s and .h’s in that folder.
To compile Bistro in Atmel Studio you have to do the following:
1.) Create a new “GCC C executable project” and choose Attiny25 as MPU,
2.) Change “Debug” to “Release”
You have a project with one file now: “main.c”.
3.) Open “main.c” in Atmel Studio, delete its previous content and paste the C-Code of Toykeepers “bistro.c”.
4.) Download Toykeepers header files (“tk-attiny.h”, “tk-calibration.h”, “tk-delay.h”, “tk-voltage.h” and “tk-random.h”) to the project directory (where also “main.c” is).
5.) Open “tk-attiny.h” in Atmel Studio and remove the leading “//” in line 26, you now have “#define ATTINY 25” in this line.
6.) Build the project.
I think this is the step I was missing.
I had that step actually, I missed that I had to have my headers in the Atmel directories instead of using my own directories. I also never switched from debug to release, but I don’t know how essential that step is.
Thanks Mike (and Tom, TK, TA, and anyone else I’m forgetting)
“Release” means “ready for distribution”.
“Debug” is for debugging. For this purpose the code is not optimized (e. g. for size) and additional code may be inserted in the hex-file - often too much for the little attinys. We don’t need this since for debugging the code in the mcu special programmers are needed anyway.
I got similar results by doing what you did - creating a new project from scratch, selecting the attiny25 for it, and got 58 bytes - 2.8% used. You got 50 bytes, 2.4% used.
In this case, I did not add any files or code. I don't understand exactly how you pasted code into the projects.
What you should do is work from the Solution Explorer - add files to the project that way. It's a hierarchy - Solution is the top level, then project. Right click on the project name, choose "Add", then choose "Existing Item...". Then be sure you delete the main.c they inserted into the project for you. I'm leaning now towards the point that maybe you did not delete main.c from the project - it explains exactly what you are getting.
It's normally important to choose Release. Usually "Release" defaults to full optimization settings, while "Debug" does not.
results:
Program Memory Usage : 1976 bytes 96.5 % Full
Data Memory Usage : 28 bytes 21.9 % Full
. K, it probably was the main.c then. Great! Mike did a much better job to walk you thru it!! I'm in too deep - work with this same Studio (it's actually Ms Visual Studio) for the last 3 years at a minimum, more than full-time.
Next question! :person_facepalming:
What are these for in TK calibration? Does 20 mean 2.0v and 44 mean 4.4v?
#define ADC_44 194
#define ADC_43 189
….
#define ADC_21 74
#define ADC_20 69
Yep, that's what they mean. Don't think bistro uses them all right now, but I do in Narsil, or any firmware that flash's out the voltage reading. I believe Dale was the one who took the original measurements. I got like 3 versions of those readings I've tested or set.
Depends if you use the voltage dividers before or after the diode, and if you use a 22K or 19.1K R1.
I figured I have to measure all of them if I want to use voltage readout in bistro
You don’t really have to measure each value. Just take one low value and one high value and the battcheck.py script can generate everything else. I try to measure close to 3.0V and close to 4.2V, but really anything is fine as long as they’re far enough apart. The measurement is so close to linear that it’s not worth measuring every point along the curve.
I usually measure each driver individually, and save the results in battcheck/readings/foo.volts, then use battcheck.py to generate the rest of the values whenever I need them. Also, I’ve found the results turn out better when I measure from an actual battery instead of a bench power supply.
Since it’s linear, the individual values shouldn’t really be needed… but it takes less space on the attiny to use a lookup table than it does to calculate points on a line. Of course, it takes even less space to do what DrJones does (assume exactly 5 ADC units per 0.1V), but that’s less accurate because it’s usually more like 4.5 ADC units, so it skews at one end or the other.
Anyway, sorry for all the AVR Studio weirdness. I’m kind Windows-illiterate.
Well I’m python illiterate, soooo
Then you’re in good company. See no evil, hear no evil, speak no evil. 
Ok, I went through and measured all my own values for LVP and OTC. I compiled and flashed without a hitch. The driver I’m testing on has a 3*7135’s on the bank.
Then I went to try it, and no bueno. So it boots up, but it goes into a 3-mode group that pulls 69ma, 305ma, and then the FET. Which as far as I can tell doesn’t correspond with what I’ve set. Then if I try to enter programming mode by tapping a whole bunch, it stops responding, but then never starts flashing out the programmin options.
Here is a more comprehensive zip of my files: LINK
Orrrrr
There’s always the old path of the 13a I could take if anybody would prefer to figure out why LVP doesn’t work right in this code…
If you didn’t change anything in bistro code apart from the voltage values the used program space should be more than 2040 bytes. Did you use the newest header files? And the correct fuse values?
Well these results:
Program Memory Usage : 1976 bytes 96.5 % Full
Data Memory Usage : 28 bytes 21.9 % Full
were an unmodified test. All I did was define Attiny25 and the rest was exactly how I downloaded it from the repository yesterday.
On the code I just posted more recently, I edited TK calibration and changed the mode groups and ramp tables in the .c.
Hey PD. Did you make sure to adjust the mode group pyramid so there are 8 entries for each group by adding the appropriate amount of “0” modes? I ask cause this happened to me last week and I was unable to enter config mode as a result. Otherwise I know less than you so…