millis() on RTC?

[ObviousInRetrospect]

On MegaTinyCore you can run millis() on the RTC which keeps time while asleep. It also can be made more accurate with a crystal.

It seems like this isn't supported on DxCore?

TCB2.CTRLA |= 1<<TCB_RUNSTDBY_bp îs a workaround but draws more power and is less accurate.

[SpenceKonde]

That is correct, and if It wouldn't be yanking away a feature people were using on megaTinyCore, I would remove it there as well. It was not implemented intelligently and breaks many libraries.

But take heart, there is a solution planned in the form of a power management and sleep library that will work with both megaTinyCore and DxCore.

This library will let you have your cake and eat it too:: A normal full speed timer will be used while the chip is awake, allowing such useful features as micros() - but it will also provide an intelligent wrapper around sleep_cpu() which will: Stop the millis timer, recording it's time, and fire up the RTC, and use that to keep time until a valid wakeup conditition is met (ie, not just the timer rolling over, which will cause it to just go back to sleep). At that point, it will read the RTC, stop it, correct the millis count and micros count (note: the latter may or may not end up working when a non type b timer is used, but will definitely work if a TCB is used for millis.

Another cool feature to look forward to from SleepLib (or whatever I end up naming it) is a SleepFor(unsigned long ms) which will do, uh, exactly what it sounds like - sleep for a given number of milliseconds.

It will use standby sleep, too, so at your option, you can sacrifice some power savings in exchange for more wakeup options. I may even attempt to get USART start of frame wakeup source to work (it's got an errata section several paragraphs long >.>, and isn't clear on which parts it's broken. It has been added to and then removed from some tinyAVRs. Without a die rev or anything, just removed from the list of errata. Does Not engender faith in their docs group, yaknow? (But does anyone have faith in the documentation group of anything anywhere? Those who can, do. Those who cannot do, answer the phones and email in support, and those who can neither do nor provide what passes for tech support.... they copy-paste documentation together and when it reaches a length of over 500 pages, they call it a datasheet. (not just at microchip, this is universal!)

[ObviousInRetrospect]

Thanks for the detailed reply. So far I have been happy with millis() on RTC. I haven't looked at how it was implemented but using an RTC to track the passage of time doesn't seem like a bad idea.

Please make any sleeplib RTC stoppage on wakeup optional. The RTC draws very little power and is rather useful (PIT).

On the 64DB32 I have had no luck with USART wakeup. One application I am working on cycles a GPS on and off occasionally and switches to using SLEEP_MODE_IDLE when running the GPS as I was having serial corruption trying to do UART wakeup. Besides, with the gps module running IDLE vs STANDBY is close to noise (and leaving the GPS on longer than necessary more than cancels any savings).

[SpenceKonde]

Did you read the errata about USART SFD interrupt?

Basically, it's supposed to trigger only in sleep. But in fact, any falling edge it sees while enabled triggers it, causing it to lose sync with the frame (it thjinks that's the start bit when it fires) and corrupt the received data. So you need to turn it on only immediately before sleep after making sure you're not about to be re=awoken by a partially complete message, and the first thing you need to to on wake is turn it off. An unpredictable protocol can make it unusable as noted in the errata.

The modern AVRs have a table of contents for the errata section longer than the entire errata section of a classic AVR. There was clearly intense time pressure. My suspicion is that they bet the (AVR) house on XMega. Ever read the xmega programming manual (or an xmega programmming manual?) Don't worry if you haven't - you won't come away learning anything other than that despite the same 8-bit instruction set and 16-bit address space, they were as intricate as they were insane. As if a swiss watch maker had changed careers to chip design... except that he had a drug problem. Some druggies spike their coffee with speed, judging by the design, the xmega people spiked thir morning coffee with a generous helping of LSD.

Then to name the features he added, marketing spilled a bowl of alphabet soup over the plans.

The result was a learning curve at least as tough as ARM.... targeting the same market space with a much weaker CPU core, and no 5v tolerance. How well do you think that went over? I don't know if thy were a bigger hit in industry, but I certainly never heard about people doing anything with them.

Eventually after their classic AVR pipeline was dry, they realized they had screwed up and nobody wanted xmega, they wanted the power of 5v I/O, and peripherals that you could use without months of study. They started a refresh cycle, the ATmega PB's, but and made 4 experimental tinyAVRs - the 841/441 (the best classic tiny imho) the 1634 (love dat flash and ram but looked like tehy ran out of time for everything else, and the 828, which was supposed to have a differential ADC.... only at the last minute someone hastily scrubbed all references to it from the datasheet. Presumably it was hosed bad, engineering asked for a respin, and management told them to to shut up and release it. They realized at that point that this was too little, too late: they needed better peripherals, the instruction set timing sucked, and they took every engineer on AVR off of what they were doing and tasked them with making it so.

The results started coming out in 2016 with the tinyAVR 0/1-series and megaAVR 0-series, right as microchip rode in and took over the joint. I call this change the 2016 revolution. And if you think about world revolutions.... some group always gets purged. One assumes that it the entire QA department was lined up and shot, seeing as post 2016 AVRs have dozens of items on the errata list. (exception: 2-series tiny is pretty good about that. I think the 32DA incident (product was shipping to customers including people buying from digikey. Half of the interrupts didn't work due to a hardware defect). I still have some of the bad 32DA28's) jolted them into taking quality a bit more seriously. They recalled the bad parts, and never mentioned it anywhere except in posts by an senior engineer on avrfreaks telling people to contact support for replacements. The only way that poor engineer would deserve to have to be the one to tell folks that is if it was his error. No clue if it was.his mistake, but if it wasnt he got a really raw deal having to post that, with a pic of him kneeling in submission. buck gotta stop somewherer

[SpenceKonde]

close because duplicate