I have an issue getting an arduino based hacked-board to sleep whilst performing ir remote commands properly.
What am i hacking?
tl;dr it's a 4 in 1 out audio selector with motorised volume pot controllable by an IR remote. But it's got a lot of issues so i've enjoyed hacking it. I will release full details maybe with a re-done PCB layout should people wish to grab a board / diy kit, but at the moment it looks like this:
Why am i hacking it?
As is, it's closed hardware and closed software, the MCU itself is an STC15W408AS which prides itself on not being able to have its flash memory read, and believe me it does it's job well; I've clearly removed it and pulled out the SOP20 footprint to another pcb that can talk to either the original IC, or an arduino nano. the volume pot as well is too slow and requires tapping to change, the relays are not latching so consume a lot of power, the whole unit consumes too much power, and i've more of less changed the majority of the components and layout.
So what's the issue?
I got to a point where i've got quite a nice setup in terms of design, it's more of less exactly how i want it and how an audio component should perform, transparently. This is why i'm now optimising the code, with a strong emphasis on lowering the idle power consumption, given it's an always on device.
The original code can be viewed here:
I've already got it down from 150mA to ~65mA by lowing the clock to 8MHz, removing the regulator, LEDs and everything else that's unnecessary, and have disabled a few modules on the ATmega328 itself, as seen on line 88.
The aim is to have it sleep when it's not being used, but i had a few set-backs since with the intention vs implementation, when it came to the ir demodulator.
A post by Nick Gammon discussed how to put the board to sleep when it's been inactive for more than two seconds whilst using IRLib1.
So i went along and ported that code to IRLib2 shown here, then retrofitted it with my original code, essentially putting the bulk of my IR response code in the 'storeCode' function (shown in the forum post, of course i refactored to more appropriate names).
The code itself works well, but it 'soft-bricks' at rather random intervals (system freezes until manual reset), usually after a few button presses, and almost at every repeat code, [The original code behaves as intended] (i do use repeat codes to allow the user to hold a volume up/down button to continuously change it, i haven't yet ported that functionality to the new sleeping code since it sleeps after 2 seconds of holding, but have begun playing with an idea seen on line 173.
I can see the current draw with the new code is low, at about 10mA for the entire board which is more than ten times lower than before, so i'll be really happy if anyone can point me in the right direction.