För närvarande utvecklar jag ett grafiskt LCD-system för att visa temperaturer, flöden, spänningar, effekt och energi i ett värmepumpsystem. Användningen av en grafisk LCD betyder att hälften av min SRAM och ~ 75% av min blixt har använts av en skärmbuffert och strängar.
Jag visar för närvarande min / max / genomsnittliga siffror för energi At midnatt när den dagliga siffran återställs, kontrollerar systemet om konsumtionen för dagen är över eller under det tidigare lägsta eller högsta och lagrar värdet. Genomsnittet beräknas genom att dividera den kumulativa energiförbrukningen med antalet dagar.
Jag skulle vilja visa det dagliga genomsnittet under den senaste veckan och månaden (4 veckor för enkelhetens skull) dvs. ett rullande genomsnitt. För närvarande handlar det om att upprätthålla en uppsättning värden under de senaste 28 dagarna och beräkna ett genomsnitt över hela matrisen för månadsvis och de sista 7 dagarna för veckovisa. energi är i formen "12.12kWh"), men detta använde 28 * 4 byte = 112 byte (5,4% av SRAM). Jag har inte något emot att bara ha en enda decimalpunkt för upplösning, så jag bytte till att använda uint16_t och multiplicera siffran med 100. Detta innebär att 12.12 representeras som 1212, och jag delar med 100 för visningsändamål.
Storleken på matrisen är nu nere till 56 byte (mycket bättre!).
Det finns inget trivialt sätt att minska siffran till en uint8_t som jag kan se. Jag kunde tolerera förlusten av en decimal ("12.1kWh" istället för "12.12kWh"), men förbrukningen är ofta högre än 25,5kWh (255 är det högsta värdet som representeras av ett 8-bitars osignerat heltal). Förbrukningen har aldrig varit under 10,0 kWh eller över 35,0 kWh, så tänkbart skulle jag kunna subtrahera 10 från de lagrade siffrorna, men jag vet att vi en dag kommer att överskrida dessa gränser.
Jag testade sedan kod för att packa 9-bitars värden i en matris. Detta ger ett intervall på 0-51.2kWh och använder totalt 32 byte. Att komma åt en sådan matris är dock ganska långsam, speciellt när du måste iterera över alla värden för att beräkna ett genomsnitt.
Så min fråga är - finns det ett mer effektivt sätt att beräkna ett glidande medelvärde med tre windows - livstid, 28 dagar och 7 dagar? Effektivitet betyder mindre när det gäller SRAM-användning, men utan att betala för enorm kod. Kan jag undvika att lagra alla värden?