Attiny25/45/85 FW Development Thread

1911 posts / 0 new
Last post
Tom E
Tom E's picture
Offline
Last seen: 2 hours 59 min ago
Joined: 08/19/2012 - 08:23
Posts: 12533
Location: LI NY

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

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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

nofear87
Offline
Last seen: 3 weeks 6 days ago
Joined: 03/07/2015 - 05:40
Posts: 114

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!

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

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.

 

EasyB
Offline
Last seen: 2 hours 57 min ago
Joined: 03/09/2016 - 15:24
Posts: 1826
Location: Ohio

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.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 13 hours 23 min ago
Joined: 03/24/2016 - 07:44
Posts: 8651
Location: Everything is brighter in Texas

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

EasyB
Offline
Last seen: 2 hours 57 min ago
Joined: 03/09/2016 - 15:24
Posts: 1826
Location: Ohio

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

Tom E
Tom E's picture
Offline
Last seen: 2 hours 59 min ago
Joined: 08/19/2012 - 08:23
Posts: 12533
Location: LI NY

EasyB wrote:
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.

EasyB
Offline
Last seen: 2 hours 57 min ago
Joined: 03/09/2016 - 15:24
Posts: 1826
Location: Ohio
Tom E wrote:

EasyB wrote:
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.

Tom E
Tom E's picture
Offline
Last seen: 2 hours 59 min ago
Joined: 08/19/2012 - 08:23
Posts: 12533
Location: LI NY

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.

Justintoxicated
Justintoxicated's picture
Offline
Last seen: 1 year 3 months ago
Joined: 12/28/2016 - 19:36
Posts: 79
Location: California

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"
Tom E
Tom E's picture
Offline
Last seen: 2 hours 59 min ago
Joined: 08/19/2012 - 08:23
Posts: 12533
Location: LI NY

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.

 

Justintoxicated
Justintoxicated's picture
Offline
Last seen: 1 year 3 months ago
Joined: 12/28/2016 - 19:36
Posts: 79
Location: California

Tom E wrote:

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 Sad  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 Smile  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!

Flashy Mike
Flashy Mike's picture
Offline
Last seen: 6 hours 15 min ago
Joined: 01/14/2016 - 16:38
Posts: 1204
Location: Germany

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

Justintoxicated
Justintoxicated's picture
Offline
Last seen: 1 year 3 months ago
Joined: 12/28/2016 - 19:36
Posts: 79
Location: California

yea

Tom E
Tom E's picture
Offline
Last seen: 2 hours 59 min ago
Joined: 08/19/2012 - 08:23
Posts: 12533
Location: LI NY

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. smile

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 13 hours 23 min ago
Joined: 03/24/2016 - 07:44
Posts: 8651
Location: Everything is brighter in Texas

Ok, getting closer to releasing the newest driver. DEL got a chance to test out the first prototype and it works! Just needs some minor changes to perfect some things and it is ready for round 2.

A few notes for the firmware side of things.

With the new design we can drop C1 down to a ~2.2uf cap which should improve power off times.

I was also able to cram a tiny85 onto it so we now have a lot more space to place with!

1206 C2 pads were able to be used

It includes a bleeder resistor so the voltage divider can be whatever is ideal in other aspects.

Hopefully with a bit more tweaking it will be ready for release.

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

EasyB wrote:
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.

 

I'll post my new version up is a few hours got it zipped and documented now, just no time this moment.  It's a BIG overhaul and includes much easier pin assignments and cleaner configuration, along with a bunch of new features. It will remerge the divergent standard bistro, triple-down, TA, etc, and a bunch of new possibilities.

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544
Tom E
Tom E's picture
Offline
Last seen: 2 hours 59 min ago
Joined: 08/19/2012 - 08:23
Posts: 12533
Location: LI NY

Texas_Ace wrote:
Ok, getting closer to releasing the newest driver....

Also look'n great! Congrats!!

ImA4Wheelr
Offline
Last seen: 3 weeks 1 day ago
Joined: 02/03/2013 - 14:51
Posts: 7925
Location: SC

Added a link in the OP to Flintrock's bistro-HD thread.  If there is anything else that should be linked or anything that should be changed in the OP.  Please let me know via PM.  This thread is belongs to the programmers and I will do my best to make the OP meet their needs.

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Well regarding references, I've had a mind to try to write up as much as I can about everything that was learned and dreamed up about OTSM from all the discussion and testing here, (nobody can read all that), but I'm afraid I probably won't get to it.

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

At easyb I might not fully understand your question about Fet+1.  But one thing  BHD attempts to do is bring the tripple, quadruple, double(or single) channel bistro versions back together with preprocessor configs that work again.  You can select any combination of PWM channels you want in the fr-tk-attiny.h.  Select the corresponding layout in bistro.c  Define the corresponding "ramps" any way you wish in modegroups.h.  For moon modes you're best to stick to PWM and PWM2 channels, because they run on timer0.  It seems to be just very difficult to get good control at low levels on timer1, although I did get a pretty good moon out of channel 4 by setting it to 0 PWM (not zero mode, mode zero shuts off PWM4 entirely, the only way I found to get full off, so just would want 0 in the ramp table for PWM4) .  PWM3 works differently than 4, and is maybe ok too.

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

So I made little excel calculation for off-time, including power consumed while waiting to detect the pin fall, just using RC and threshold voltage etc.  Everything matches up reasonably well with what I saw.  It looks like tweaking a few things should get it well up over 3s with only a 3.0V battery, including going from 30uF to 47, but also getting the better diode, going to a V-chip, and lowering the pin voltage by 25%.  It should work like this with a bit higher resistor values too, so that's good (I'm going to try 500 R1, 1500 R2 and no bleeder).  I have the v-chip but I'd forgotten to get the diode and resistors, so still waiting to put it together.  The Ta cap shouldn't be very temperature sensitive and neither should the reverse leakage on this new diode, so I'm hoping the numbers stick when hot.  I think this will likely work well.

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

 Oh and of the chips I've seen,

25's were revision G (good)  

25V: revision F (still good),  

45V: revision G (good),

85: revision B (bad/no bods).

 

So the situation with attiny85 seems bad for BODS.

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

 Hmm... so good and bad.  At 3.0V input, the new setup  (v chip, Ta cap, low leakage diode, tuned voltage divider) is able to measure off-clicks over 3s in length, (I'm pretty I measured it closer to 4 once, but haven't tried to reproduce that) using only 47uF of capacitance, and does it even with high overall bleed resistance (4.3kOhm).  At that voltage and bleed value, that's as good as I would have dared hoped for.

 

The bad, for some reason it can only do that on low modes. I've done a ton of measurements.  Off-time power consumption has nothing to do with what mode it was in before it turns off, because I always shut down PWM before sleeping.  mcu power consumption while it detects shutdown does impact it though.  LED consumption does not, because it's isolated by the diode from the MCU off-time cap, C2.  If anything high LED current should drain C1 faster and result in quicker off-time detection before the mcu eats up its reserves.

 

Ok, so I measured mcu current draw in all modes (again).  It doesn't vary much.  With my powersaving trick enabled it's about 2.1mA for 1 7135 or the fet.  It's closer to to 3mA for all 7135s (the difference actually being in-line with the spec sheet drive current for the 7135s, although it's interesting that these are technically still on when the FET is running, and yet the drain goes back down to 2.1 when the FET is on).  As it turns out, I can get about 1.5 seconds of off time on the FET on full power if I  add back a 500ohm bleeder, but I can barely get any off-time at all from the all 7135 channel.  For the single 7135, again on low, it gets very long times.  On full throttle at 3.0V it can squeeze out over 0.75 s, getting close to 2s by 3.5V, all  with the bleeder, so bit worse than the FET.  This seems to indicate it's not about total LED current.  But I'm at a bit of a loss what it is about.  

 

It's very possible that I just missed this in the first build.  I was mostly testing on low or turbo, and didn't even have the backside 7135s installed on that build.

 

The extra 0.8 or so mA of the all 7135s does not seem to add up to anywhere near enough too explain this, from the math or experience (I did some work to get it down from 4mA in the first place, and yes it helped, but no where near this drastic).  The math from all the measurements actually adds up pretty well in line with the 3s+ I'm getting on the low mode.

 

hmm...

 

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Oh this is probably not a heat thing.  It's still on the bench and separated from the LED. Of course the whole point of this particular diode and the Ta cap are that both should be pretty immune to heat, but that's not proven yet.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 13 hours 23 min ago
Joined: 03/24/2016 - 07:44
Posts: 8651
Location: Everything is brighter in Texas

very strange that the channel effects the total time.

Reminds me, I need to put together a final release for the Texas Commander driver. It works fine, just sadly limited to either low currents in regulated mode or to last gen LED’s with higher Vf or it will overheat.

Works great with last gen LED’s though and if you stuffed the driver with thermal cubes it should help it as well.

Flintrock
Offline
Last seen: 2 years 1 month ago
Joined: 09/10/2016 - 20:29
Posts: 1544

I see, it seems we're both a bit stuck.  Yes, I was not expecting this bug.  I don't think this is a fundamental problem with the methods, and maybe I'll figure it out eventually, but it's a puzzle.  I'm starting to wonder if the PWM is interferring with pin change detection and I'm half tempted to desolder the 7135s to see if it still happens if they're not hooked up.  My first guess was higher mcu drain due to drive current, but I couldn't make the math work out this bad without pretty crazy numbers, and then measurements show no crazy values.  About the only other thing electronically is somehow increasing the effective C1, but at 1uF that seems pretty far fetched too.  I guess the diode could be leaking, but why then?   It's strange, and strange is the realm of the mcu so I'm started to suspect something going on with the off detection. 

 

I'm a bit surprised about your driver too.  We dump these levels of heat in 7135s all the time right?  I guess they're pretty spread out though.  

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 13 hours 23 min ago
Joined: 03/24/2016 - 07:44
Posts: 8651
Location: Everything is brighter in Texas
Flintrock wrote:

I’m a bit surprised about your driver too.  We dump these levels of heat in 7135s all the time right?  I guess they’re pretty spread out though.  

The driver still gets pretty warm with the 7135’s, the key difference is that the 7135’s have a thermal regulation circuit built in that turns down the power if they get too hot automatically. This happens a lot but no one notices due to the fact the human eye doesn’t notice the rather small changes in output.

The other big factor is that the 7135 heat sinks directly to the ground ring and thus it able to dump the power into the host.

Lastly the 7135’s are indeed more spread out which helps as well.

From our testing we came to basically the same conclusions as the LD-3. It can dissipate around 1.5-2W of heat max if connected to the host well. You might be able to push that a bit higher if you fill the cavity with thermal cubes.

This is fine for the last gen emitters with high Vf as they max out around ~1.5-2W of heat. The latest 219C 90 CRI on the other hand could need as much as 3W+ for a single LED. Same for the L2 and other new LED’s.

The option to fix this would be to make a custom mcpcb that puts the FET directly on the mcpcb do it can easily dissipate the heat. Then it would in theroy be able to handle basically LED setup. This would need a custom mcpcb though which would be costly.

This is the only option I see going forward with regulated compact drivers, although it would be hard to fit the FET onto a 16mm star.

That is unless we can figure out a compact buck driver.

Luckily the Texas commander has a direct drive turbo mode that uses the normal PWM and can handle tons of power but the regulated modes are still limited.

Pages