Attiny25/45/85 FW Development Thread

I can vouch for that, for sure.... Was gonna ask bout the S optimize setting, but thought that was little insulting . Anything one could get wrong, I've done, I'm sure. All a matter of how fast you can figure it out. Many times I come in the next morning and it's obvious, staring me in the face.

So here's a new one. Vcc ADC reading seems to mess with the light a bit.

I did of bunch of recent changes without testing, just getting the code organized, surprised things mostly work still, but they seem to. Except the light had a pule, a heartbeat. After burning through another 20 flashes on this poor attiny's life it boiled down to the adc being on and set to the Vcc reference, and having changed the timing of things I noticed now when not before. In fact I intentionally was cycling the ADC on longer between voltage and thermal mode to stabilize readings, but that's the heartbeat. Of course ADC_on was the last thing I suspected. It seems that an adc reference on the Vcc pin is disturbing the electronics and dims (we don't want dim) the light a little.

It's a full single 7135 mode, no PWM. Being a regulator I'd hope it wouldn't be too sensitive to a little voltage fluctuation. I have found these things are pretty finicky,very easy to break entirely. Maybe I should replace the 7135 and see what happens.

Sorry if I missed something, but if the opamp gives use true regulation, why do we need a 7135? Couldn't the FET give use everything we need?

The opamp driver is not released yet, DEL has not been able to look at it to see if it is even ready for release.

He is dealing with the normal Avenger driver.

Oops! Yea, I'm getting things confused...

Well, just bugs.. just crammed too much new stuff in here all at once.

I hope that I’am in the right thread. Does anybody get the lvp working for 6V configuration with 36k/4,7k Resistors? For example with blf-a6 firmware. I would be glad to see the code. Thank you guys!

So the fun part with 4 channels was it wouldn't go full off. Actually there's a note about that problem already for the 3rd channel (runs off the same PWM clock), but I didn't understand it until now. Ok, so only phase mode goes full off and timer 1 doesn't do phase mode. The 3rd channel historically drives the FET though and isn't used for moonlight on tripples, so probably just never noticed. Also it's likely significantly worse using interrupts to bit bang the pin. The simulator shows about a 6 pwm-tick delay between the two interrupts handlers running, which could just be from the interrupt handling itself. The first interrupt already starts 3 ticks after the match, so maybe that adds up. I doubt the wave form generator is that bad. I think it's supposed to be a 1 tick spike. Anyway, I'm using the interrupts for my idle sleep clock but I sent a control bit to the on intterrupt to just shut it off on level zero and it behaves. Whoo. I haven't done the same for channel 3, but probably should for potential RGB use.

TK had a note awhile back about not knowing how to slow down timer1 (the channel3/4 timer) below 31 khz. In principle that helps some with this issue and generally with low modes. I'm not sure why she said that though. Actually before I read that, I thought I'd slowed mine down by half. It has a prescaler (TCCR1 CSx), which I thought I adjusted, but now I'm wondering if it doesn't work, or if I was confused. All my blink timings are based on that clock when the 4th channel is engaged so I'll just play with it and see how the blinks go and find out.

E-switch works, but there are many configuration possibilities with slightly different code paths, and the one I tested is maybe not even very normal (ok, tested that one too, it works!), so a little more to test still. Well, there probably is more testing to do, but I'll probably go and and put it out in the next day or so anyway.

Hi, I have a help/knowledge request. I want to alter Toykeeper’s ramping_table_UI FW to work with FET+1, in order to get a lower moonlight mode.

My hope is that this won’t be too difficult to do. A new mode list will have to be made, but the attiny13a should still be capable of running it.

Before I go fiddling around trying to do this I thought I would see if there was some concise wisdom someone could give me regarding this. For example, I see in FET+1 FW codes where the pwm levels are defined for each channel for each mode, but I can’t find where these channels are assigned to the specific pins of the chip.

If I succeed I would like to share the code if that is appropriate. I really like this UI, and I think it would be perfect for me if it had that moonlight capability.

Why not simply use Narsil? It is based on TK’s ramping firmware and already setup for FET+1 or even FET+1+more

I may just do that. I like the simplicity of TK’s FW, but I will look into narsil and the attiny85.

Can someone tell me where to get TK's ramping firmware and what are the requirements (13A, 25, etc.)? I've heard it mentioned many times but can't find it.

The one I’m talking about is, in the FW repository:
Toykeeper/Ferrero_rocher/Ramping_UI_table.c

It works on the attiny13a. I had to comment out the section about the red and green voltage indicator lights to get it to work on my normal FET driver from mtn.

Ahh, ok - thanx! Didn't realize it was there. Interesting... Sounds the same way Narsil ramping works, accept mine is over a FET+1 which can get tricky.

I'm trying to compile the default bistro code in AtmelStudio 7. I have added in the winAVR flavor but cannot generate the hex file. This sure is frustrating to not be able to compile known good code.

"Severity Code Description Project File Line Source
Error recipe for target 'main.o' failed Bistro C:\bazaar\Atmel\toykeeper\Bistro\Bistro\Bistro\Release\Makefile 98 Build"

Where line 98 is:

$(OUTPUT_FILE_PATH): $(OBJS) $(USER_OBJS) $(OUTPUT_FILE_DEP) $(LIB_DEP) $(LINKER_SCRIPT_DEP)
 @echo Building target: $@
 @echo Invoking: AVR/GNU Linker : 0.0.0
 $(QUOTE)C:\WinAVR-20100110\avr-gcc.exe$(QUOTE) -o$(OUTPUT_FILE_PATH_AS_ARGS) $(OBJS_AS_ARGS) $(USER_OBJS) $(LIBS) -Wl,-Map="Bistro.map" -Wl,--start-group -Wl,-liberty -Wl,-litclstub32 -Wl,-litkstub32 -Wl,-lsimulavr -Wl,-lsimulavr.la -Wl,-ltcl84 -Wl,-ltclstub84 -Wl,-ltk84 -Wl,-ltkstub84 -Wl,-lgcc -Wl,-lgcov -Wl,-lcrtbegin.o -Wl,-lcrtbeginS.o -Wl,-lcrtend.o -Wl,-lcrtendS.o -Wl,-lcrti.o -Wl,-lcrtn.o -Wl,-lstdc++ -Wl,-lstdc++.la -Wl,-lsupc++ -Wl,-lsupc++.la -Wl,-lsta43464 -Wl,-ltclConfig.sh -Wl,-ltkConfig.sh -Wl,-lcrt86401.o -Wl,-lcrtc8534.o -Wl,-lcrts1200.o -Wl,-lcrts2313.o -Wl,-lcrts2323.o -Wl,-lcrts2333.o -Wl,-lcrts2343.o -Wl,-lcrts4414.o -Wl,-lcrts4433.o -Wl,-lcrts4434.o -Wl,-lcrts8515.o -Wl,-lcrts8535.o -Wl,-lcrttn11.o -Wl,-lcrttn12.o -Wl,-lcrttn13.o -Wl,-lcrttn15.o -Wl,-lcrttn22.o -Wl,-lcrttn24.o -Wl,-lcrttn25.o -Wl,-lcrttn26.o -Wl,-lcrttn28.o -Wl,-lcrttn44.o -Wl,-lcrttn45.o -Wl,-lcrttn84.o -Wl,-lcrttn85.o -Wl,-lcrttn261.o -Wl,-lcrttn461.o -Wl,-lcrttn861.o -Wl,-lcrttn2313.o -Wl,-lc -Wl,-lm -Wl,-lobjc -Wl,-lobjc.la -Wl,-lprintf_flt -Wl,-lprintf_min -Wl,-lscanf_flt -Wl,-lscanf_min -Wl,--end-group -Wl,-L"C:\WinAVR-20100110\lib" -Wl,-L"C:\WinAVR-20100110\lib\gcc\avr\4.3.3\avr25" -Wl,-L"C:\WinAVR-20100110\lib\gcc\avr32\4.3.2" -Wl,-L"C:\WinAVR-20100110\lib\gcc\avr\4.3.3" -Wl,-L"C:\WinAVR-20100110\avr\lib" -Wl,--gc-sections -mmcu=attiny25 
 @echo Finished building target: $@
 "C:\WinAVR-20100110\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "Bistro.elf" "Bistro.hex"
 "C:\WinAVR-20100110\avr-size.exe" "Bistro.elf"

Been compiling/linking Bistro fine in AtmelStudio 7.0 for a long time now, just built in under Win10. Here's a complete Bistro ZIP file, with the 7.0 solution and project file all complete. Simply unzip into an appropriate named folder (like Bistro), and open the solution file (bistro.atsln) in 7.0, and should work fine.

On my Google share: drive.google.com - Bistro

I might have some tweaks in the source code, but minor if any functional change at all.

Thank you I will take a look at this now. I finally figured out what i was doing wrong. (I'm not a C guy and have never used visual studio). I thought I was viewing the output window, but realized it was displaying then disappearing after 1/2 a second. once I could see the real output... Well Damn the problem was obvious. I ended up creating a new project again and moving over the bistro files. But when it compiles I get a Memory Overflow :( 117.8% full.

Really I'm just trying to learn how to use this thing so I can make some minor tweaks to the UI. But out of the box it has memory overflow? Seems odd to me.

I will try to import your project now.

edit: OMG thanks so much! your version compiled first try. I see allot of chages vs what is in the repo. Voltage monitor has a different delay set. fastpress setting is set inside the "if" instead of outside. Faster battery check :) Removal of unused SOS code, some changes to the strobe that I don't fully understand. Some changes to CAP_PIN (whatever that is)...lots of other stuff removed that I don't understand at all.

I'm such a newb at this, but I guess it is expected we will modify the code to fit on the MCU? Or are these typically flashable out of the box? I can see some of it was safe to remove as it did not look like it was being used, but allot of the other parts that were changed I cannot really understand what they do or the reason for the changes.

I guess I will have to base my changes on your working code instead.

Thanks!

Regarding the memory:
Did you change “Debug”-setting to “Release” when using original Bistro?

yea

The CAP_PIN change was only to remove the compile switch - function is the same. Think most changes are like that, except removing SOS, etc.