Attiny25/45/85 FW Development Thread

1901 posts / 0 new
Last post
ToyKeeper
ToyKeeper's picture
Offline
Last seen: 52 min 5 sec ago
Joined: 01/12/2013 - 14:40
Posts: 4884
Location: (469219) 2016 HO3

What hardware and firmware did you measure there?

On some lights I can measure PWM speed by using the photoacoustic effect, shining the light at black fabric and holding a mic to it. I haven’t measured inner components though, and high frequencies are hard to separate from background noise.

Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

ImA4Wheelr wrote:
... It seems your  fuse values in 52 are valid.  Is your programmer set to 5 volts?

What specific FW are you using for the DD+7135?  I'd like to check it out.

Yes - 5 volts. Though after several attempts, I did try 3.3v but nothing worked.

Ohh - I'm using my latest eswitch.c. I could post it somewhere for you - I'm @work now though, another 10 hrs or so. You probably have an older version of mine.

How did this thread get so into PWM hums? It's got me hearing all the hums and buzz's here @work coming from all types of equipment Smile.

 

Diode663
Offline
Last seen: 5 months 2 weeks ago
Joined: 05/26/2015 - 22:24
Posts: 27
Location: United States

I used a qlite with two extra 7135s and guppydrv. The noise was clearly being emitted near the head where the driver is. I held it up to the mic on the smartphone. The peak was very visable on the app i used. There might have been more peaks higher up in the range that i wasnt able to measure due to the limitations of the smart phone. And i have to say i have never heard of the photoacoustic effect. Thats pretty neat.

Diode663
Offline
Last seen: 5 months 2 weeks ago
Joined: 05/26/2015 - 22:24
Posts: 27
Location: United States

As for how we got here i believe it went: what core freq to run, then 6 mhz because that allows you to get 19khz pwm to keep it inaudable and then to 19khz or not we call can hear it. And i really have nothing to add to this thread other then all the fuse setting was why I was thinking of going arduino on a tiny 85.

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 12 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7236
Location: SC

^ You've already contributed much value to the thread.  I'm not going to pretend I understand everything you, led4power, RMM, and ToyKeeper (alphabetical order) are saying, but the hum issue is one of the vexing challenges that we have to deal with in this hobby.   So any discussion that may deepen our understanding is all good.

Tom E,

Much appreciated.  I will PM my email address to you.  I don't have much in programming skills, but I will do my best to read the data sheet and look at the alternate pwm feed portions.

I should note that I don't recall where I read that one pwm channel is for fast and the other for phase.  I skimmed the data sheet and didn't see anything like that.  So maybe what I read was not correct or I misunderstood it.

Diode663
Offline
Last seen: 5 months 2 weeks ago
Joined: 05/26/2015 - 22:24
Posts: 27
Location: United States

Well think about all of the constant current pwmless drivers out there with a pic controling a mosfet. They are all silent but i suspect its because they are running pwm in the mhz range so that by the time all of the harmonics filter down they have no energy left to be heard. I could be wrong but i highly doubt the are changing the enhancement on the gate to vary the current flow. Which wouldnt make sense because the inductor relies upon expanding and colapsing magnetic fields to generate the current and voltage levels so i would think it needs to be an on off afair. I think the real leap in blf driver design will come when we can figure out how to use the micro as constant current switch mode controller.
It seems like pics are exclusively used for this but i dont see why we couldnt do it with an attiny.

Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

We need a PWM-less thread to discuss getting these MCU's working Tongue Out.

Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

Well current progress:

  • I reflowed a replacement 45, and back to working Smile
  • turbo timeout works, and it's dead-on accurate for 2 mins, better than I've seen on 13A's Smile
  • timing with the e-switch firmware is great - clicks vs. click/hold works perfect Smile
  • strobe works great Smile
  • mode changing is working flawlessly so far on one FET channel Smile
  • just can't get the alternate PWM channel working with the 7135 - tried FAST PWM on all modes and get no output at all Frown
  • tried LVP and doesn't seem to work with a cell even at 2.8v, maybe even 2.7v. It's a 22 wight FET+1 driver so I'm using a 22K resistor. Haven't experimented with values yet, but suspect something basic is not working Undecided.
  • did not confirm low power sleep mode yet - would be nice to know it's working with a low parasitic drain Undecided

 Wish I could get a better handle on exactly how these MCU's differ from the 13A. Thought there was some differences in clocks, ports, etc., just cant' find it.

Update: Ok, I got LVP working now as well. Looked at the ADC support, and with the added features in this area (temp sensor, etc.), setting the 1.1v reference is now a different bit in the ADMUX register. I had a weak cell at about 2.7v, and sure enough, the firmware backed down output in steps til output dropped altogether - just what it supposed to do!

Now, still got dual channel support to figure out, with the PB0, pin #5 7135 output.

RMM
RMM's picture
Offline
Last seen: 5 hours 6 min ago
Joined: 07/23/2013 - 13:47
Posts: 3852
Location: USA

Great work Tom!  I'm planning on working on this some more early next week.  Want to get that temperature sensor going.  

Mountain Electronics : batteries, Noctigon, and much more! What's new? 

Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

Hhmm. It all seems to be working now. Even the Phase Correction on 7135. All tests seem to be correct - amps indicate is truly working off the 7135 in the 1st 3 modes. Dunno what was wrong before - didn't "fix" anything, I don't think... Weird, but this is really nice!! Now I can do some serious programming with a whole nother 1K bytes (Tiny25) of code space SmileSmile!

Yes - the temp sensor would be huge as well, for sure.

Update: ZIP files of project/source code and BAT files are shared here: drive.google.com-244585. Hope this link works. You may have to sign in to Google in order to download, not sure...

This is for a wight style FET+1 driver with default 5 modes, first 3 on the 7135. It has a turbo timeout set to two minutes. I've only tested it on a ATTiny45 which should be running at 8 Mhz. It's not taking advantage of the 45's extended capabilities yet: temp sensor, extended available memory, etc.

 

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 12 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7236
Location: SC

Way to go Tom.  You are the man!  I finally got a 22mm board working and tested the UI of the FW you sent me earlier today.  Same results as you reported.  It worked great except for the Alt PWM channel.  I started examining the code and came back to report and call it a night.  My gosh, you got a lot done tonight. 

 Tom E just opened up the hobby to a whole new level!

EDIT: Status in OP updated.

DavidEF
DavidEF's picture
Offline
Last seen: 13 hours 44 min ago
Joined: 06/05/2014 - 06:00
Posts: 4163
Location: Salisbury, North Carolina, USA

ImA4Wheelr wrote:

Way to go Tom.  You are the man!  I finally got a 22mm board working and tested the UI of the FW you sent me earlier today.  Same results as you reported.  It worked great except for the Alt PWM channel.  I started examining the code and came back to report and call it a night.  My gosh, you got a lot done tonight. 

 Tom E just opened up the hobby to a whole new level!

EDIT: Status in OP updated.


Wow, guys, this is awesome! What I’d like to see is a guppydrv style mode group selection but using more advanced mode groups like we have on the BLF-A6 FW.

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

Funny, I was think'n the same exact thing - guppy style mode group availability w/advanced mode nav, w/all the bells and whistles of LVP, OFF time detection using a cap or brownout detection, temp sensing based output limiting, full e-switch and/or power switch support. And, of course, it should all be done in one firmware version.

 This opens the door to a whole lot more versatility.

 My first step (for me) is to get back to adding full power switch support w/OFF time detection to the e-switch firmware, so lights that have both can have it both ways - lights like the X6R, Yezl Y3, L4, and many others. I ran out of program space when a I tried this before. Could also be used for e-switch lights with a lock-out feature, so you have the effectiveness of a twisty, still with full e-switch support.

DavidEF
DavidEF's picture
Offline
Last seen: 13 hours 44 min ago
Joined: 06/05/2014 - 06:00
Posts: 4163
Location: Salisbury, North Carolina, USA

Tom E wrote:

Funny, I was think’n the same exact thing – guppy style mode group availability w/advanced mode nav, w/all the bells and whistles of LVP, OFF time detection using a cap or brownout detection, temp sensing based output limiting, full e-switch and/or power switch support. And, of course, it should all be done in one firmware version.


 This opens the door to a whole lot more versatility.


 My first step (for me) is to get back to adding full power switch support w/OFF time detection to the e-switch firmware, so lights that have both can have it both ways – lights like the X6R, Yezl Y3, L4, and many others. I ran out of program space when a I tried this before. Could also be used for e-switch lights with a lock-out feature, so you have the effectiveness of a twisty, still with full e-switch support.


So, you’re saying that the firmware will have all the fancy mode groups and UI controls available to either e-switch or clicky, or even both in the same light – all supported in one firmware to rule them all? And, it would be cool to have both tighten-for-on (the standard twisty UI) and tighten-for-off (not very common, but better, IMHO) capabilities in the same firmware. Oh, and to complete the laundry list – both forward and reverse clicky support optimized. All of this should be user-programmable (or rather user selectable ) through the UI. Am I asking too much? 0:)

Reason is not automatic. Those who deny it cannot be conquered by it. Do not count on them. Leave them alone.
-Ayn Rand

Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

Probably short answer is yes - you are asking too much, or dreaming like me Smile. Besides, “There is only one Lord of the Firmware, only one who can bend it to his will. And he does not share power.”

However, “That there’s some good in this world, Mr. Frito… and it’s worth fighting for.”

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 12 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7236
Location: SC

Ran Tom E's FW through some paces and it did great.  UI is solid and reliable.  Strobe is great.  I think Turbo timed out at 2min 6sec.  Could not get it to exhibit any glitches.  Very nice. 

I tried working the LVP, but fried an emitter due to a careless turn of the bench top voltage dial.  I never get reliable results trying to test LVP with my bench top power supply anyway.  Don't have time to try testing with cells tonight.

It's a winner in my book.  I'm going to go work on designing the OSH Park boards I discussed in the OP.  Want to get those available and also place an order since they can have long lead times.

Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

I did the bench PS testing, and it trips at 3.1v, so the ADC_LOW should be set at 120, and ADC_CRIT at 110 to get 3.0v and 2.8v, respectively.

 Darn - just bricked another 45 MCU (can't verify the dnld). It doesn't work after this occurs, so something must be goin wrong in the AVRDude dnld process. I was able to do quite a few dnlds though before it happened again.

Diode663
Offline
Last seen: 5 months 2 weeks ago
Joined: 05/26/2015 - 22:24
Posts: 27
Location: United States

I know this is a little late but it has an interesting tidbit on the programing. Atmel for whatever reason chose to change the instruction set between the 13 and higher models.

Although it appears that the ATtiny x5 parts are a superset of the ATtiny13 parts, they are not code compatible – not even source code compatible, since not just the register addresses, but the bit locations in them are different.

http://avrprogrammers.com/articles/attiny13-vs-attiny85

MRsDNF
MRsDNF's picture
Offline
Last seen: 3 hours 53 min ago
Joined: 12/22/2011 - 21:18
Posts: 10538
Location: A light beam away from the missus in the land of Aus.

Love your work Tom E not that I really understand it. I'd suggest at the end of the day we will all win with the work your doing. Thanks.

My current and or voltage measurements are only relevent to anything that I measure.

Budget light hobby proudly sponsored by my Mastercard and unknowingly paid for by a hard working wife. 

djozz said "it came with chinese lettering that is chinese to me".

old4570 said "I'm not an expert , so don't suffer from any such technical restrictions".

Old-Lumens. Highly admired and cherished member of Budget Light Forum. 11.5.2011 - 20.12.16. RIP.

 

Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

Diode663 wrote:
I know this is a little late but it has an interesting tidbit on the programing. Atmel for whatever reason chose to change the instruction set between the 13 and higher models. Although it appears that the ATtiny x5 parts are a superset of the ATtiny13 parts, they are not code compatible - not even source code compatible, since not just the register addresses, but the bit locations in them are different. http://avrprogrammers.com/articles/attiny13-vs-attiny85

The author sounds like he really did not attempt a port, I'd say, very little actual programming experience. Technically, the instruction set is the same between the 13 and the higher end MCU's, with minor enhancements to support the added functionality. I could not find one example of them making a change, in a register layout for example, where the functionality of the register stayed the same. In fact I'd say they went out of their way to keep it the same. I think it was 3 to 4 lines of code we had to change, out of 500 or so. There was only one line of code that wouldn't compile. His page is a great exaggeration, and the list of differences shown has very little to do with code changes. I've done tons of porting code projects over the years, from asm to C, C to C with MCU changes, C to C#, and many others, and this port was much easier than most. Porting is actually a specialty of mine, I got a rep for that, and I've gotten contract jobs with only that one goal in mind. The development tools stayed the same, and the compiler is actually the same, it's just that some pre-defined libraries and constants that are MCU specific had minor changes. Also our flashlight driver firmware versions don't use all the features the MCU offers, so it's not like we had to delve into every register, so it's simpler than what it could be.

 For me with this project, testing is a challenge because I'm used to having more advanced tools available, such as simulators, and interactive debuggers.

bugsy36
bugsy36's picture
Offline
Last seen: 4 months 3 weeks ago
Joined: 07/11/2014 - 18:15
Posts: 2466
Location: Florida USA

All I have to say is WOW!!

Great work everybody!

It's the simple things that we take for granted that cost us the most

Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs

Lothar
Offline
Last seen: 10 hours 45 min ago
Joined: 10/26/2011 - 11:22
Posts: 386
Location: Stellenbosch, South Africa

Awesome work guys! Thanks for putting in the hard miles!

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 12 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7236
Location: SC

Thanks for the kind words guys.  Not having C programming experience/knowledge, I spent a heck of a lot of time in proportion to my output.  I learned a ton, but still feel like I hardly know anything.  Thank goodness Tom E came on board.  He catapulted this project forward.  I would still be trying to work out the bugs in my version if I was still alone on it.  In a way, it would have been good for my development to not have his assistance, but I have to admit that I much rather be working on lights than learning C and creating code.

Thanks to Tom, we have a fully functional FW for the 25 already.  It sounds like he has much bigger ambitions though. 

Before taking the plunge and purchasing the MCU's, I debated going with one of the PIC MCU's.  Pin compatibility with the vast majority of drivers currently used by us was the biggest deciding factor in favor of the 25.  Then when I got the chips and ported an older version of Tom E's FW, I was really glad I decided to go with the 25.

I'm off to read a bit about the thermal sensor in this MCU since I'm not allowed to install Eagle on my computer at work.

EDIT: I agree with Tom E's assessment of that article Diode663 linked to above.  I had read that at some point back in time.  Comments from others here at BLF and that article kept me from taking the plunge on the 25 for almost a year.

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 12 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7236
Location: SC

Some data sheet excerpts regarding the temperature sensor:

17.12 Temperature Measurement
The temperature measurement is based on an on-chip temperature sensor that is coupled to a single ended ADC4 channel. Selecting the ADC4 channel by writing the MUX[3:0] bits in ADMUX register to “1111” enables the temperature sensor. The internal 1.1V reference must also be selected for the ADC reference source in the temperature sensor measurement. When the temperature sensor is enabled, the ADC converter can be used in single conversion mode to measure the voltage over the temperature sensor.
The measured voltage has a linear relationship to the temperature as described in Table 17-2.  The sensitivity is approximately 1 LSB / degree C and the accuracy depends on the method of user calibration. Typically, the measurement accuracy after a single temperature calibration is ±10degreeC, assuming calibration at room temperature. Better accuracies are achieved by using two temperature points for calibration. 

Table 17-2. Temperature vs. Sensor Output Voltage (Typical Case)
Temperature   -40C    +25C     +85C
ADC              230 LSB   300 LSB   370 LSB

The values described in Table 17-2 are typical values. However, due to process variation the temperature sensor output voltage varies from one chip to another.

There is some more info and reference tables on pages 134 - 137 that will be needed to make the Thermal Protection Code ("TPC").

Elsewhere, this is written:

The ADC is enabled by setting the ADC Enable bit, ADEN in ADCSRA. Voltage reference and input channel selections will not go into effect until ADEN is set. The ADC does not consume power when ADEN is cleared, so it is recommended to switch off the ADC before entering power saving sleep modes.
The ADC generates a 10-bit result which is presented in the ADC Data Registers, ADCH and ADCL. By default, the result is presented right adjusted, but can optionally be presented left adjusted by setting the ADLAR bit in ADMUX.
If the result is left adjusted and no more than 8-bit precision is required, it is sufficient to read ADCH. . . . When ADCH is read, ADC access to the ADCH and ADCL Registers is re-enabled.
The ADC has its own interrupt which can be triggered when a conversion completes. When ADC access to the data registers is prohibited between reading of ADCH and ADCL, the interrupt will trigger even if the result is lost.

bugsy36
bugsy36's picture
Offline
Last seen: 4 months 3 weeks ago
Joined: 07/11/2014 - 18:15
Posts: 2466
Location: Florida USA

This is an English speaking forum Tongue Out

BTW....ALL of you are making huge inroads!! I just think about what can been done with double the space. We aren't talking guppies anymore, we are looking at whales if not actual sharks LOL

It's the simple things that we take for granted that cost us the most

Ευκαιρία λέει πιάσε με από το μέτωπο γιατί μόλις έχω περάσει δεν θα με πιάσειs

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 12 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7236
Location: SC

^ I hear you brother.  It sounds like Greek to me for the most part too.

So Programming Gurus, if I may pick you brains (yum, brains.  Oh, don't tell the BLF Zombie Slayanator I said that).  Please learn me something here. 

Base on the data sheet, it appears that much of the code for LVP can be adapted for the temp sensing.  For example:

  • Bit ADEN appears to already turned on as needed by the existing code.
  • ADC feeds are left adjusted in the code by turning ADLAR on (= 1).
  • We only need to read register ADCH because we don't need more than 8 bits of resolution.  So the existing code read seem appropriate.
  • The If, Then, Else loop for LVP just need to be copied and modified for temp sensing purposes.


So, I have 2 questions as follows:

  • Can we not have LVP and Temp Sensing at the same time as both feed ADC feeds dump in Register ADCH?
  • I appears we need 1111 in the 4 MUX# bits.  Can we just insert the following for the first line and then squeeze the second bullet text below into the code below "inline void ADC_on()" in the existing code?:
    • #define ADMUX ob00001111
    • ADMUX  = (1 << REFS1) |

EDIT: If the answer to my first bullet is "yes", than can we some how use one of the various memory capabilities of the 25 to collect and report one of the ADC feeds?

EDIT2: Or maybe a loop that, clears ADCH, turns ADC1, waits for feed to populate ADCH,, reads ADCH, turns off ADC1, clears ADCH, turns on ADC4 (temp sensor), waits for feed to populate to ADCH, reads ADCH, steps down if needed, turns off ADC4, rinse and repeat

Sorry for asking the above without researching more, but I want to get the OSH Park Attiny 13/25/45/85 piggyback PCB designed and published.

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 52 min 5 sec ago
Joined: 01/12/2013 - 14:40
Posts: 4884
Location: (469219) 2016 HO3

Tom E wrote:
I’ve done tons of porting code projects over the years … and this port was much easier than most.

I was rather surprised to hear that one of my projects compiled and worked on the attiny25, with no modifications!

So, it sounds like we already have a few firmwares which work (or almost work) on nicer hardware, and it’s time to get the hardware out there to more people. Smile

ToyKeeper
ToyKeeper's picture
Offline
Last seen: 52 min 5 sec ago
Joined: 01/12/2013 - 14:40
Posts: 4884
Location: (469219) 2016 HO3

ImA4Wheelr wrote:
it appears that much of the code for LVP can be adapted for the temp sensing. …

If I understand correctly, it should be fairly straightforward. Just toggle back and forth between voltage and temperature every other cycle, with different code to handle each. I think the MCU can only measure one at a time, but it’s not hard to swap between the two fast enough for it to be useful.
Tom E
Tom E's picture
Offline
Last seen: 6 hours 32 min ago
Joined: 08/19/2012 - 08:23
Posts: 9223
Location: LI NY

+1, I read it the same - only one at a time, based on the MUX bit definitions (allows only one channel to be selected), and the description of free running mode, which states one conversion at a time, then auto starts the next conversion. But certainly/definitely the firmware can be written to support LVP A-D conversions and temp sensor A-D conversions.

 The accuracy doesn't sound too great though for the temp sensor. Even after a single cal point at room temp, the accuracy is only within +/- 10C. I would think we would want better? Better to get two points, but I'm not sure how to best create then measure a 2nd point. Guess I could use a heat/hot air gun, but not sure how to accurately measure the temp of the chip. I wouldn't trust my cheap IR thermometer. Dunno if my Chinese $15-$20 meter is any good, or would the Fluke or Extech units be that much better in the $70-$80 range? Or is an IR meter the right tool?

ImA4Wheelr
ImA4Wheelr's picture
Offline
Last seen: 12 hours 34 min ago
Joined: 02/03/2013 - 14:51
Posts: 7236
Location: SC

TK wrote:

. . .  Just toggle back and forth between voltage and temperature every other cycle, with different code to handle each. I think the MCU can only measure one at a time, but it’s not hard to swap between the two fast enough for it to be useful.

Cool. Thanks.  So my EDIT2 idea should work.   You conveyed the idea much more eloquently than I did.

 

TK wrote:

I was rather surprised to hear that one of my projects compiled and worked on the attiny25, with no modifications!

So, it sounds like we already have a few firmwares which work (or almost work) on nicer hardware, and it’s time to get the hardware out there to more people. Smile

I would stress "almost work".  In that example you cite, I believe said he reported LVP didn't work.  Although Atmel only changed a few Memory Names, they did change the Addresses a good bit.  Also, some bits changed.  So a full port is really needed for all FW one wishes to install on the 25.

 

Tom E wrote:

The accuracy doesn't sound too great though for the temp sensor. Even after a single cal point at room temp, the accuracy is only within +/- 10C. I would think we would want better? Better to get two points, but I'm not sure how to best create then measure a 2nd point. Guess I could use a heat/hot air gun, but not sure how to accurately measure the temp of the chip. I wouldn't trust my cheap IR thermometer. Dunno if my Chinese $15-$20 meter is any good, or would the Fluke or Extech units be that much better in the $70-$80 range? Or is an IR meter the right tool?

Perhaps a hidden mode that lets the user click when the light gets too hot.  That way, no calibration is needed.  The loop switching from LVP to Temp would be by-passed and just ADC4 would be active during the user :"calibration".  Boy, it seems that extra 1K of memory can get used up fast with new code like this.

Pages