Attiny25/45/85 FW Development Thread

1922 posts / 0 new
Last post
Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

 

Oh regarding the 1.1V, no that won't work with this bistro OTSM implementation, unless you want to make a separate pin for power-off detection and voltage divider.  Presently the divider voltage needs to be logic high. For 1S the only practical way to make that work with constraints on the ADC is to use Vcc "reading" , and then for 2S use  Vcc/LDO-referenced (not 1.1 or 2.56) reading of the divider.  It will just be a define to switch.

 

It's certainly possible to make a purely ADC-based implementation. It's a rewrite of bistro's adc system, not just changing a couple of initialization registers or the name of an interrupt. It won't perform quite as well either, maybe a little because the ADC uses a little more power on these BODS scales, but even more because you lose the possibility to wake on the power-on signal. Instead you only wake on the watchdog timer, which, to save power in BODS, is presently set to 0.25s intervals and is thus too un-responsive. You'd need to lower it to 0.125s at least, requiring maybe 50% more power draw in the sleep loop and still being I think noticeably less responsive (based on my non-thorough observations of that setup). So I'm not really seeing that as the direction to go in, but it could be something to try.

 

I'm not sure how well the 3.3V 1-S Op-amp OTSM will work though. It's all going to depend on the quality of caps we can find.  There seem to be options in things other than ceramic, but anyway, it just needs searching and testing.  Specifically leakage should be less than 1<uA, and that doesn't really fit with specs on Ta Ta-Polymer, NbO, but comments I find are that real world results are much better than spec.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

Worst case a 5V LDO could be used in the higher voltage drivers, it would remove a lot of the point of having these mass produced though if that was to happen. The sales pitch for someone to mass produce these is that they would be the one size fits all driver for anything.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Good news is I've saved a TON of space (by attrition mostly).  This is presently looking like it will be even smaller than the last version.  The bad news is I'm presently noticing that it's not working well (or maybe at all) on high modes.  I'm not certain if that's something new, or just something I hadn't noticed.  Hmmm... something to try to understand still. Obviously that would be no good. 

 

well.. ok, not smaller than the last one, but still 140 bytes left over for now.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

very nice, the more space the better, we will always find a way to use it!

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Yep.. Anyway, high is working, just not well. hmm, hoping it's a pin setting thing.  Not sure.  Mostly I haven't used turbo because the star isn't heat sinked.  So will have to figure this out.  The led shouldn't be able to drain C2, and if anything should help.  Well I've got at least one idea to check so we'll see.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

I don't know the cause of the high mode thing yet.  Haven't had a chance to do any testing.  I realize that one thing my power measurements missed, well that's the wrong word... they measured the mcu power draw.  But there can also be a reverse current through the diode (I was feeding power forward through the diode so didn't measure that).  I checked the specs on the diode in your digikey basket (likely the one I'm using, but I'm not sure) and it's not very good:

 

http://www.diodes.com/_files/datasheets/ZLLS410.pdf

 

At 25C it's around 1uA or less but at 85C it's around 80uA maybe.  I wouldn't think my board is getting this hot (not sure, it's hanging in the air without a case to heat sink too, but it also has no led to heat it up), but it would only have to be 5ua to have the kind of effect I'm seeing.  It's another case where I don't know how conservative the specs are. If it causes this issue or not though it's probably not ideal anyway.  This would be a better choice I think:

 

http://www.onsemi.com/pub_link/Collateral/RB751V40T1-D.PDF

 

With the graphs indicating around 1uA at 85C.  That diode is a bit fragile in comparison but should do the trick (with an R5 installed to protect it).

 

Of course all this brings the question, how good is the LDO at reverse current blockage?  I lost the link to your new LDO.  uA are small.  Can it really work without an inline diode?

 

Joshk
Joshk's picture
Offline
Last seen: 1 week 4 days ago
Joined: 09/09/2015 - 12:12
Posts: 2697
Location: USA

Psst…
Debug>>Properties>>Toolchain>>Optimization

Edit: Hmm. I guess I was reading an old post when I saw Texas_Ace was using a Linux virtual machine to compile with optimization.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

Interesting points on the diode reverse voltage. If you find a better one that is obviously easy enough to change out. Although the LDO would be better if it works.

The latest LDO we have found is the LT3009, the real issue with it is the rather scarce availability compared to other options.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

Joshk wrote:
Psst…
Debug>>Properties>>Toolchain>>Optimization

Edit: Hmm. I guess I was reading an old post when I saw Texas_Ace was using a Linux virtual machine to compile with optimization.

It must have been an old post. I do use Linux now (in a virtual machine simply because I don’t like having to walk over and use the Linux box lol).

Atmel complained constantly about things, Linux uses the same exact files and compiles it without any issues and the final size is smaller too boot. So I now just use that.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Yes, I know the -Os option.  I'm well past that level of tricks now I hope, but it's a good tip thanks.  

 

So, I took some measurements.  At 3.3 V I'm at 8uA in sleep measured through the usual power chain, so the same as my much older tests in similar configuration. But I before I measured that I happened to be measureing at 4.2V which put me at 10uA, ok fine.  But if instead I connected direct to Vcc, powering C2 directly with 500 ohms bleeder to ground upstream of the diode (the amount of resistance there really doesn't matter for diode reverse current since all the voltage will still be across the diode) then I got about 11.5uA.  Ok, no big deal, seems like maybe there's 1.5uA of reverse leakage through the diode.

 

But I had taped a thermocouple to the diode body, and heated everything up (starting at 22C).  By 55C it was 20 uA and by 70C it was at 33.  Actually I stabilized at about 75 and took those numbers as it cooled because that seemed more stable than while blowing hot air on things.  One time I cranked it up to 85 because the spec sheet has a line there, looks like aroun 70uA maybe on the spec sheet, and sure enough, it went off scale, somewhere pegged past 50uA.  So it follows the specs pretty closely actually.

 

I'll look up your LDO, but this could be a real issue. I'll also try to see how warm things were getting on my high mode because I'm not sure yet that these are related issues.  It's all I came up with so far though and it kind of checks out so far.  

 

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Oh, and I ran the same test powering it with forward current through the diode (with the bleeder removed), the normal way, and heating it, and the current did not go up past 12uA.  Actually it  dropped a little a few times, but came back to the same point.  So I think that's pretty conclusive.

 

This backside powering is actually pretty handy because you can pull the wake pin up and down and trigger the interrupts at will while watching current.  It's easy to setup too because you just power it through the Vcc pin on the programming clip.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

I am not sure I am following exactly.

So the diode is leaking a lot more then expected but it doesn’t seem to actually effect the driver in real world use as you only get 12ua?

What is the new powering approach exactly, you are powering the MCU after the diode?

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

"real world" is still unknown.  The diode is leaking as much as the spec sheet says it does, which is quite a lot at high temperature.  Powering the mcu from downstream of the diode allows me to measure the effect.  Powering it from upstream does not, because my power is going through the diode anyway. The fact that I see it one way and not the other, just confirms that the temp effect is the diode and not something else.   However during sleep, the mcu is powered from downstream of the diode and the leakage will be a problem if it's hot. So yeah, that could definitely be a real world issue, and at those current levels, a pretty big one.  I don't think 55C is unreasonable to expect and that's already going from 12 to 20 uA so that would impact turbo performance on this diode.  I suspect your LDO is worse.

 

However, I just teste this setup on turbo (2A limited though), and it rises a degree or two just if I set the board near the star, and leave it a minute or so (which is as long as I dare anyway without a heat sink).  So I don't think that's the issue affecting high modes at the moment.  I suspect it could be a pin state thing, but I don't really know yet.

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

Ah, ok that makes more sense.

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

I've finished up the features, testing, and so-on for the next NarsilTriple release. This is v1.3 now, and includes a full NarsilTriple v1.3 manual, listing all the features, configuration settings and modes. I also made a pass through the source code, and a "notes.txt" file included to update the comments and descriptions accordingly.

I've been testing it on a Lumintop SD26, which came out pretty nice, using the green LED's mounted on the switch PCB for the Indicator LED function of Narsil. Been using it with a 4.7K resistor to reduce the standby power when the LED's are on.

I really could write up a 2nd doc just for tweaking settings in the source code - there's a ton of them.

Link for full source (fully set up for Atmel Studio 7.0) and manual in docx and pdf formats:

My Google Drive Share for NarsilTriple

 

Brief summary of V1.2 to V1.3 changes

  • New Features: add code from DEL's test driver for doing voltage reading from the internal 1.1V reference, and use temperature sensor readings
  • config UI changes, and add a mode to blink out the temperature (calibration done in constants in the firmware code)
  • tweaks to ramping tables: seems to work well now!!
  • New Feature: for ramping, blink the ind. LED to indicate what channel the output is on
  • add compile switch to use only ind. LED for several usages: power-on blinks, config blinks 

Summary Of Features

  • Ramping – smooth 150 level ramping, simple click&hold ramps, 1 click ON to last level, 1 click OFF, direction of ramping will toggle unless you remain at a level more than 1.2 seconds
  • Mode Sets - Simple 1 click ON, 1 click OFF, navigate to next and previous modes
  • 8 mode sets to choose from, 1 to 7 modes/output levels can be configured, and then saved
  • Modes can be arranged for low to hi, or hi to low
  • Multiple strobe and beacon modes can be accessed, total of 5 special modes (16 Hz strobe, police strobe, bike strobe, 2 sec beacon, and 10 sec beacon)
  • Low Voltage Protection (LVP) – output is decreased starting at ~3.2V, shut off at ~3.0v, both with blink warnings
  • Temperature Regulation: drops output at high temps, with blink warnings, blink out temperature in C
  • Turbo timeout can be enabled/disabled, and the time be set (works for high output levels in Ramping too)
  • When power is applied, 2 blinks indicate it’s ready
  • An Indicator LED (SMD LED) is supported as a locator LED and low voltage indicator
  • Battery Check – blink out the voltage level (ex: 3.7V would be 3 blinks, pause, then 7 blinks)
  • Very low standby power (parasitic drain) without Indicator LED on
  • Lock-out feature for the side switch – enabled and disable by a special click sequence
  • 20 second button press safety lock-out feature (engages lock-out after 20 secs being held)
  • Mode memory can be enabled to quickly restore the last used mode setting, but not recommended
  • A power tail switch can be used to change modes w/memory
MRsDNF
MRsDNF's picture
Offline
Last seen: 3 months 3 weeks ago
Joined: 12/22/2011 - 21:18
Posts: 13473
Location: A light beam away from the missus in the land of Aus.

Amazing effort Tom that we all appreciate. Thanks.

 

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

                      "My man mousehole needs one too"

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.

 

Texas_Ace
Texas_Ace's picture
Offline
Last seen: 1 week 3 days ago
Joined: 03/24/2016 - 07:44
Posts: 9036
Location: Everything is brighter in Texas

Very nice, I will have to give it a try if I build anymore e-switch lights.

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

Thanks All! But ... Found a couple of minor issues with the v1.3 posted. I updated the source and resulting files. It's all updated now. The changes, as noted in the source code header are:

  • bug fix: error in modeSetCnts for Mode #8: would not have worked
  • reduced timeout from OFF to standby/sleep from 10+ secs to 5 secs
  • change default of twoDigLedOnly from enabled to disabled (Batt/Temp/Vers Ind. LED Only)

I posted a ZIP file of the HEX only, but it has limited use because there are so many compile time settings.

Updated in the same location as linked to before: My Google Drive Share for NarsilTriple. Please note the ZIP files are todays date, time of 5:45 PM (not sure how that works across time zones).

 

LightRider
LightRider's picture
Offline
Last seen: 3 years 8 hours ago
Joined: 08/05/2015 - 09:52
Posts: 2007
Location: U.P. MI, USA

Tom, I am very appreciative of your efforts! This is an exciting firmware and will be implemented right away. You’ve thought through so many things and it allows someone like me to have something to keep my mind engaged. My mind needs to learn complicated things yet I am unable to learn as I once could learn which means I need these complicated to be easy complicated things. Wink Sounds like it doesn’t make sense but to me it is a big deal.

So a big thank you to all you guys involved in helping me interact with these exciting and mind stretching projects!!!

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Looks like some great work.  I haven't really looked much into narsil honestly, but I can appreciate the work anyway.

I played a little with a genaralized function to interpolate sparse tables.  A straight forward implementation added about 180 bytes vs the full lookup table, and that was after probably saving about 30 in the table itself. Some hacking up a division algorithm brought that down by 30 bytes, but also added more constraints (no gaps greater than 31 in ADC channel, with 8 step intergap resolution). You'd need really several tables before this wins.  

 

There are probably better ways to just make a single simple straight line (or more tailored implementations of the same way possibly). These machines can multiply, they just can't divide, but 8 bits makes everything tricky (you can't multiply anything bigger than  15*16 without going to 16 bit).

 

So these things are heavy I'm afraid, as gchart also found.

 

I'm polishing off a few little adc stability things that Vcc and some OTSM related powersaving caused. Then I'll probably put this out for others to test.

 

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Speaking of narsil though,  I just realized that this bistro OTSM code, possibly with as little as one preprocessor define to change the pin ID, would turn bistro into an e-switch firmware (if that doesn't already exist somewhere, not sure).   OTSM is essentially just an eswitch anyway, just that it measures how long the switch was pressed.  It would just need a check to prevent the counter overflow, and at the same time probably switch over to longer watchdog times after a couple or few seconds of wakes. Why wouldn't that all work?

...

Oh, yeah.. just remembered, the e-switches are momentary? Just a push to make switch?  So it would need a little extra for the toggle.  How do these e-switch softwares work, long press for off? Short press/medium for controls then?

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

I was wondering bout that. I might not fully understand what OTSM is exactly and how it works, but think'n it just might convert a power switch into an e-switch. Bistro certainly is not designed that way. Power switching and e-switching are two different architects. e-switch firmware requires somewhat precise measurement of button press's. The common implementation is the 16 msec timer being used to poll for button presses and releases, with simple debounce logic. Having the capabilities of Bistro and adding e-switch support would normally add a considerable amount of code. Big reason why I went to the 85.

In Narsil, the critical stuff is done in the watchdog timer because it's so sensitive in acting on switch state transitions, mode based. The main loop acts on events detected by the timer. You can easily get caught up in trying to do everything in the timer, but that's a mistake - the timer should simply schedule things for the main loop to execute, such as controlling the LED output, doing the low batt signals, acting on over temp conditions, blinking out statuses, etc. If you keep to the rules, generally things will work fine. I mostly get into trouble when I break those rules, and then get into conflicts/time sync issues between the timer and the main loop.

For Bistro, it's actually much simpler, single threaded, one main loop. More like a straight sequential programming model.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Yeah, I've been struggling with exactly those model differences.  I was almost going toward having the main loop process interrupts, and adding a global timer, and having adc multiplexing in background between thermal, Vcc and whatver.  But in the end I did things differently.  There's an interrupt that senses the switch go down, and puts it into a watchdog loop, counting times on wakes.  A final pin high interrupt wakes it the last time where the real trick happens (I'll get there).  For eswtich instead could just use a faster watchdog at first, and slow it down later, but I need a slow(1/4s) watchdog to save power for OTSM so the extra pin wake makes it respond faster.  This is all a very nested/re-entrant web of interrupts that's very non-recommended, but works great anyway, and all to avoid the recommended way of setting a flag and handling the interrupt in the main loop.  As you say bistro just isn't designed for that.  I went through seeing what that would take, and it's possible of course, not even terrible probably, but definitely more work, less incremental, and more chance to create more problems.

 

Anyway at the wake, have to back up, the trick is that the main loop is not main() anymore.  main() just sets some default values for cold starts, and calls a function that is the main loop, run().  At the wake up I reset the stack pointer to RAMEND (very uncivilized but effective) and call  run(), restarting the program but bypassing initialization of main() thus keeping the wake counter and anything else I want.  So I've created a goto out of the interrupt back to the beginning. 

 

 

So I guess the light shouldn't go off during short clicks on e-switch.  Ok, so just replace sleep with delay until the few second threshold I described. I think it could work.

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

Ahh, ok. The change of frequency would be a complication I suppose, can be handled though. Also wondering bout the switches. True e-switches are generally made for that. The mechanical rev and fwd clickies are generally not designed for frequent use. I'm pretty fussy bout the feel of the switches on e-switch lights. I much prefer an easier engaged switch, which they seem to be going away from. Mechanical switches to use as an e-switch? Dunno, I'd have to check a few and see.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

By the way, the watchdog isn't the only useful timer.  I've also setup a TCNT0 timer that I'm using for idle-mode delay loops.  The rate in this case is constrained constrained by pwm configuration to 8 overflows per ms, but you I could see faster if I looked at the clock itself instead of overflows, and a 16bit overflow counter can still go out pretty long too if needed.  It seems more flexible to me than a watchdog for power-on use, but then you don't always need 1ms resolution.  I needed it to sneak idle sleeps into the strobe delays.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

Tom E wrote:

Ahh, ok. The change of frequency would be a complication I suppose, can be handled though. Also wondering bout the switches. True e-switches are generally made for that. The mechanical rev and fwd clickies are generally not designed for frequent use. I'm pretty fussy bout the feel of the switches on e-switch lights. I much prefer an easier engaged switch, which they seem to be going away from. Mechanical switches to use as an e-switch? Dunno, I'd have to check a few and see.

 

No, no.. I'm fine with bistro on clickies.  No negativity meant but I'm not sure I'd love the ramping of stuff of Narsil.   I'll try it once I have an eswitch light and who knows, may love it.  But I was just thinking of this for true e-switch lights, like having bistro for the Q8.

 

OH.. just got your point about frequency.. in the wake.  Yeah, no big deal.  I need a timeout after n seconds of wakes to do a couple of things for sure.  It's not required to change the frequency, just would help with drain some, but with BODS working, I'm already getting great drain at 1/4s, from an e-switch perspective.

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

Yea, in NarsilTriple I'm using the ADC complete interrupt for 1.1V ref LVP and temperature reading. DEL developed this code and I integrated it into NarsilTriple. What I like bout his LVP is it's algorithm based, no lookup table, and seems pretty accurate. Plan is to drop it into standard Narsil (2 channel) as well so we can have temp monitoring and lower standby drain in the BLF Q8.

For the Q8, we are already committed to the 2 channel driver design, so too late to convert. DEL has his own 2 channel SRK driver design as well, which I like the look of, but again, all too late for the Q8 project.

Wish I could combine the 2 Narsil source branches into one master - might look into that. Compile switching may get a bit crazy...

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

The algorithm definitely sounds nice.  For Vcc reading though, I just don't believe it will work for accurate battery checks (anything will work for just LVP, you just need to calculate one value and the compiler can do the calculation unless it's UI configurable).  Anyway, the Vcc ADC results end up very curved, mostly because of how it must be read.

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

Yea, under normal circumstances, I've found over a wide range it seems pretty accurate - pulled the cell and tested on a DMM. I'm think'n where it goes astray is under heat, or under load, or both, not sure. The other day thought I saw a reading of 2.n V when the cell actually was 3.2V when pulled.

Flintrock
Offline
Last seen: 3 years 3 months ago
Joined: 09/10/2016 - 20:29
Posts: 1544

A table won't do any better as far as those things.  If anything you could correct for heat with an algorithm, but that's going a bit overboard in my opinion. It's jut this Vcc curve that's pretty hard to calculate with a machine that can't really do math. In excel I calculated it real accurately, real easily. On attiny85 it could still be done though.  It just takes a bunch of bytes.  Math takes steps.  It's either built into the machine, or it needs instructions, and the attiny25 is stuck either way.

Pages