arduino nano beperkt geheugen?

Al die kant en klare Arduino libs zijn handig, maar niet altijd efficient geprogrammeerd. Je zou ook eens naar Bascom kunnen kijken, meestal een stuk kleinere code dan Arduino voor dezelfde functionaliteit is mijn ervaring.

uit mn hoofd 2 kb ram en 30 kb flash.

teksten kun je via progmem instructie naar flash verhuizen. ze verbruiken dan geen ram.

Op 30 april 2015 22:22:50 schreef Roland van Leusden:
Al die kant en klare Arduino libs zijn handig, maar niet altijd efficient geprogrammeerd. ...

mja, net ook gemerkt. leeg project gestart, en telkens een regel toevoegen en compileren.
zonder nog maar iets te doen neemt de TFT library zomaar 4300bytes weg (van de 30 720). er zijn er nog eens 1000 weg als je een tft scherm definieert.
nog eens 2K voor men 1602 scherm library en de Serial.print

dat is dan al bijna de helft van het geheugen die daar inzit. dan hoef ik me al minder zorgen te maken. het wil dus zeggen dat de overige 150regels slechts 10k gebruiken en dan kan ik nog eens zoveel functionaliteit kwijt voor het vol zit (de parkeersensoren zijn maar 2 variabelen en kleine code voor het geluidsignaal)

de GPS... dat wordt iets anders.
als ik dat grafische spul wil gebruiken, zal ik andere hardware moeten bij elkaar zoeken

Dat zaken als grafisch TFT, netwerk, sd card aansturen, usb veel geheugen gebruiken hoef je geen helderziende voor te zijn. 't Zijn nu eenmaal heel complexe zaken...
Zelfde geldt voor math libraries (zoals cos/sin, floating point, multiply/divide...)

Ja dat tft schermpje hakt er in als het een schermbuffer nodig heeft. Ik heb wel eens een vergelijkbaar project gedaan voor in mijn boot. Gps sensor, oled schermpje, fuel flow sensor, sd kaartje (om gps te loggen) servo om de snelheids naald te bewegen en temperatuur sensor. Uiteindelijk twee atmega's 328 gebruikt en die over seriële poort laten comuniceren met elkaar.

Nu zou ik gewoon een ATmega 1284p pakken. Die heeft echt bakken flash en ram, en kost maar een beetje meer. Dan een 328.

Dat plaatje waar je naar toe wilt... Als je nog een beetje framerate wilt hebben, zoals dat die wijzer een beetje vloeiend rond gaat, vrees ik dat je iets krachtigers moet hebben. Iets met een ARM ofzo, zoals de Arduino Due

[Bericht gewijzigd door Satoer op vrijdag 1 mei 2015 00:30:35 (19%)]

Voor zo'n meter heb je niet veel processorpower nodig. Je hoeft alleen de naald steeds opnieuw te tekenen...

Heeft niets met je geheugen te maken maar het valt op dat die Nano een 12 Mhz kristal heeft, normaal draaien die op 16 Mhz. Dus je kunt nog wel wat snelheidswinst halen door er een 16 Mhz op te zetten, dan kun je in ieder geval de TFT wat sneller inklokken.
Zie nu dat dit het kristal voor de serial/usb chip is. De ATmega heeft een smd resonator. Niets gezegd dus.

dat schermpje is eigenlijk wel snel beschreven.
in de setup wordt de hele layout gemaakt enkel zonder de getallen.

in de loop heb ik een functie/procedure/... gemaakt waarbij je de nieuwe waarde, de oude waarde, de X en Y positie en de RGB waardes doorgeeft.
het programma schrijft dan eerst de oude waarde in het zwart (de witte vorige tekst dus wegschrijven) en dan onmiddelijk de nieuwe waarde in het wit (of rood) erover.
indien oud en nieuw gelijk zijn, doet die zelf niks.

dit maakt het refreshen heeeeel snel (bij volledige clear en herschrijven, knippert het scherm, bij telkens alle waardes te herschrijven zag je ook van boven naar beneden een knipper in de cijfers. nu dat er slechts enkel gewijzigd worden, zie je het amper. leuk zou zijn als ik pixels kon aansturen en enkel de nodige pixels verander van kleur.

is er veel verschil tussen kristal en resonator? mijn 2de nano heeft 2 resonators op de pcb (1 voor atmega en 1 voor de usb). men 3de weet ik niet.

ik denk er namelijk over na om een uno te kopen voor dit project. is gemakkelijker enzo voor de stroom aan te sluiten en ik kan dan ook een shield maken met mijn kabels en onderdelen op (nu moet ik ook een print maken waar de nano op klikt

[Bericht gewijzigd door fcapri op vrijdag 1 mei 2015 08:25:04 (19%)]

Toch denk ik dat je er een aardige klus aan gaat krijgen om de frame rate acceptabel te houden. Als je alleen de naald wilt optekenen, zal je de vorige naald moeten weg tekenen met het achtergrond plaatje. Waarschijnlijk gebruik je nu een libary om het scherm af te handelen en ik heb nog geen libary's gezien die slechts een deel van plaatje optekenen. Alles is mogelijk, maar je zult het dan waarschijnlijk echt zelf moeten programmeren.

Je zit nu ook al krap in je flash, zo'n wijzerplaat zal ook al 128(pixels)x160(pixels)x3(R,G,B) 61kB in beslag gaan nemen. Je kan je geheugen vrij eenvoudig uitbreiden met een SD kaart om dit op te lossen. Let er wel op dat een SD kaart 3.3v is, dus je zult de signalen / voeding moeten converteren naar 3.3v (dit kan met een niet inverterende buffer "hex bufer"). Nadeel wel weer is dat data inlezen van SD trager zal zijn dan van interne flash.

Hoe dan ook, petje af als je het voor elkaar krijgt de wijzer een rondje te laten draaien met 10 fps. Als dit grafische beeld je einddoel is zou ik in ieder geval nu hier mee beginnen met testjes te maken.

Zelf 10k aan code schrijven is een hels werk. Als in: daar past je project 3x in. Je grote verbruikers zijn een aantal libraries die je meeneemt. Met een beetje mazzel heb je die nu meegenomen en hoef je niet nogmaals een andere grote library te gebruiken.

men broncode is 8K groot nu, kleine 213 regels met amper commentaar in.

er zit een hels programmeer werk in om uit een instabiele incorrecte benzinetankvlotter toch een stabiel en correct getal in liters brandstof uit te komen. ook de temperatuursensor was geen lachertje. vind er totaal geen gegevens van, dus heb niet anders kunnen doen dan de curve uit te tekenen (stuk hyperbool) en dan zelf de relatie tussen temperatuur en weerstand te bepalen.
bij benadering heb ik gevonden dat (1/(X+220))*29350 tamelijk correct volgt van 40-110°. onderaan zou ik bij de grafiek een 3° afwijking hebben (14°C wordt weergegeven als 11°). dat boeit me totaal niet. de maximale afwijking op de rest is max 1°C.
bijkomend probleem is ook dat de originele tellerunit een stroom door de vlotter stuurt, en ik de weerstand niet meer kan meten, maar een 'onbekende' spanning erover. het magische getal hier is 57,7.

14 regels Serial.print
16 regels LCD print
18+10 regels voor de TFT print

en de rest is rekenwerk. in een latere fase kan ik wel de LCD print eruit halen aangezien ik dat display niet meer gebruik nu.
heb een tijdje dubbel geschreven omdat ik te weinig plaats had op het scherm tijdens calibratie.

t is ook een heel werk geweest om de tankvlotter te calibreren in men software. tijdens mijn eerste run zo een fout gemaakt. op men kladpapier de sensor waarde 8,08 afgeschreven (benzinetank LEEG), maar tijdens het aanpassen van software 8,80 als 'lege' waarde ingevuld. (vol = 4,4V, leeg is 8,08V dus)
de volgende tankbeurt leegrijden stond ik al op 8,3V op het scherm toch heel kritisch te kijken naar men analoge brandstofnaald. de laatste keer dat ik zo laag zat, ben ik stilgevallen. het display gaf nogthans aan dat ik nog 6liter zou hebben.
toch maar gaan tanken en 51liter gekregen in men 50liter tank. toen ik die ene keer stil gevallen was, kreeg ik ook 51liter in de tank. ik zat dus op de laatste 100meter te rijden. gelukkig toch maar getankt.
zodus weet ik het absolute minimum 8,3V!!! als het display nu zegt dat er 1liter is, dan zit er ook maar 1liter meer in.

nu nog bijkomend probleem dat de 10V regelaar op men dashboard een heel slechte 10V regelaar is (ik hoop dat het komt door het ontbreken van condensatoren)
http://s884.photobucket.com/user/j-boogie253/media/Untitled-3.jpg.html
TCA700Y

Op 1 mei 2015 09:32:55 schreef fcapri:
men broncode is 8K groot nu, kleine 213 regels met amper commentaar in.

Commentaar kost geen extra flash geheugen, dit laat de compiler weg als hij het tot machine code omzet.

Welke libary gebruik je om je scherm aan te sturen? Ik heb ook wel eens libary gebruikt die alle ongebruikte schermconfiguraties ook gewoon mee compileerde. Ik kon deze vrij simpel uit de broncode van de libary weg gooien waardoor ik vrij veel geheugen vrij kreeg.

Omzetten waardes van temperatuur, liters in benzine tank of wat voor andere sensor dan ook kan vrij eenvoudig met de "map" functie in Arduino.
http://www.arduino.cc/en/Reference/Map

Als je een waarde hebt die lineair loopt, of het echt exact stap voor stap wilt calibreren, dan kan je de multimap functie gebruiken:
http://playground.arduino.cc/Main/MultiMap

Wat je ook nog zou kunnen doen is een OBD adapter kopen en op die manier alle voertuiggegevens pikken:
http://arduinodev.com/hardware/obd-kit/
Ligt er wel een beetje aan hoe oud de auto is.

mijn auto is een volledig mechanische diesel van 27jaar oud. OBD... niet aanwezig

ik weet ook dat commentaar niet meespeelt bij de compiler, ik wil gewoon maar aantonen dat die 213 regels ook bijna allemaal code zijn. vele programmas die ik vind krijgen al 20regels bovenaan met uitleg, en dan midden in de code zit er elke 5lijnen nog wel eens 2-3lijnen commentaar (mijn commentaar staat op dezelfde regel achter de code)

met die map kan ik exact 1 regel vervangen
dit:

 int liters =   ( (10 - fuelavg)  * 10 ) - (2 * fuelavg) ;    //calculate liters
 

door dit:

int liters = map(fuelavg*10, 41, 83, 51, 0)

het ding werkt werl niet met decimale getallen terwijl mijn eerste code met floats werkt. de benzinetankvlotter levert namelijk een spanning tussen 4,1 en 8,3V. bijkomend is dan ook nog dat 4,10 en 4,19 hetzelfde resultaat geven bij de map (neemt geen komma getallen aan. of ik zou alles x100 moeten doen.
bij de temperatuur heb ik 1 formule die de hyperbool beschrijft. in die multimap zijn dat al minimum 3regels. t is wel heel handig als ik die hyperbool nog niet had berekent, maar nu is mijn formule wel korter.

in ieder geval lijkt het mij wel intressante software voor later. het iets aanpassen is wel kinderspel (stel bv dat het 0liter punt 8,5V ipv 8,3V is, ik moet mijn hele formule aanpassen, bij de map slechts 1 getal)

de grootste code zit achter het uitmiddelen van de vlotter.
als je optrekt, gaat de benzine naar achteren en stijgt de brandstofmeter. als je afremt het tegendeel.
bij een bocht naar links stijgt het brandstof niveau, bij een bocht naar rechts zakt het.
op mijn analoge teller kan die in deze situaties tot 1/4de van de tank op en neer gaan (25liter). dit is er allemaal uit in mijn digitalisering.
bijkomt ook geeft de analoge meter gewoon vol aan vanaf een 45 tot 51liter. mijn digitale teller is in staat 446,47,48 of 49liter weer te geven

[Bericht gewijzigd door fcapri op vrijdag 1 mei 2015 20:03:02 (13%)]

Da's juist het voordeel van een analoge meter. Een goede reageert heel traag, dus middelt uitstekend. (de mijne doet echt niks in bochten)
Hangt ook veel van de vlotter af of de zaak nauwkeurig is. Vaak raakt die de bodem al als er nog een liter (of meer) in zit...

Ik zou wel een goede kwaliteit display nemen. In het dashboard is een temperatuur van 60 graden niks bijzonders, goedkope eBay displays gaan dat denk ik niet fijn vinden...

Het is een goede eigenschap om het gebruik van floats zoveel mogelijk te vermijden. Het uitrekenen van floating point kost de arduino namelijk erg veel rekenkracht. voor de duidelijkheid van je code zou dit goed kunnen oplossen door een variabel "millivolts" te noemen ipv "volts".

Voor je brandstof niveau probleem, zou je elke seconde het niveau kunnen uitlezen en toevoegen aan een variabel. Dan deel je na 10 seconde deze waarde door 10 (en zet je de optel variabel op 0) en heb je elke 10 seconde een nieuwe gemiddelde waarde van je brandstof niveau. Desnoods doe je dit over 60 seconde om een nog stabielere waarde te krijgen.

Wil je een snellere verversing, dan moet je een tabel (array) maken en een pointer variabel die elke meting een tabel adres verder gaat om de data op dat punt te overschrijven (of de pointer terug laat gaan naar het begin van het tabel indien het einde bereikt is). Nu kan je met dit tabel op elk moment een nieuwe gemiddelde waarde berekenen. Ik denk echter dat dit een beetje onzinnig is, als je auto zo onzuinig is dat je zo'n snelle verversing nodig hebt dan zit er waarschijnlijk een gat in je tank. Daarbij kost dit meer ram en processorkracht.

Om te kijken of er een seconde verstreken is, moet je de millis() functie gebruiken. Zie het blink without delay voorbeeld.

dat is ongeveer wat ik doe.
ik laat de arduino een 10tal metingen doen. dit om de 'foute' metingen van de arduino eruit te halen. die meet soms teveel en soms teweinig, maar gemiddeld zit die redelijk goed. hier komt waarde fuelvoltinst (fuel voltage instant) uit.
deze waarde ga ik 20keer met zichzelf optellen en daar ook een gemiddelde uitnemen. deze noemt fuelvoltavg (fuel voltage average).

na 20 van deze optellingen zal die gemiddelde bijtellen bij het vorige gemiddelde. en daar weer een gemiddelde van.
zodoende kan mijn benzinetank slechts met de helft van de verandering verhogen/verlagen.
stel bv dat de fuelavg nu 4,35V is, en na 20metingen heb ik een 4,43. dan zal er gemiddeld 4,39 uitkomen. deze wijziging is te weinig om mijn getal in liters aan te passen, dus die blijft stabiel.
na een paar 100 van deze veranderingen zal pas 1 liter eraf gaan. als je dus eens bergop of bergaf rijd, dan wordt die er in gemiddeldes zowat altijd uitgehaald, en bij een hele lange bergop zal het getal wel oplopen maar niet genoeg om de liters aan te passen.
nadeel is wel dat het vullen van de tank immens traag gaat, omdat die telkens met de helft pas opteld (beetje de grafiek voor het opladen van een condensator). nu trek ik ff de spanning los zodat die na een tankbeurt volledig opnieuw herbegint

Persoonlijk vind ik de AD converter in de Arduino erg nauwkeurig. Die ‘foute’ metingen worden hoogst waarschijnlijk veroorzaakt door de vlotter.

Ik denk dat je code een beetje nodeloos ingewikkeld geworden is. En ik snap het wel, want je begint zo’n project gewoon door wat code te kloppen, en dat bouw je steeds meer uit, pas je aan, en voeg weer code toe . Maar uiteindelijk krijg je hier door gecompliceerde code door.

In dit geval meet je dus 10 keer, en daar reken je een gemiddelde van en vervolgens herhaal je dit 20 keer (ik neem aan in een bepaald tijdsverloop) om van deze gecombineerde waarde ook het gemiddelde van uit te rekenen.

Een eenvoudigere oplossing en wat exact de zelfde waarde geeft is om gewoon 200 (10 x 20 = 200) keer te meten (in het zelfde tijdsverloop) en van die waarde het gemiddelde te nemen.

Wat je ook doet is 200 keer een waarde omrekenen naar een float, 200 float optellingen, 11 float delingen (20+1). In totaal 411 float bewerkingen om 1 uitkomst te krijgen.

Het beste is om de waarde wat je krijgt van analogRead helemaal niet om te rekenen, en intern gewoon hier mee te werken. En deze waarde pas bij uitvoer naar scherm om te zetten in volts of andere floating point waarde.

Stel dat je elke 20 seconde een nieuwe waarde wilt hebben:

• Maak een routine die elke 100 milliseconde activeert (100 milliseconde x 200 readings = 20 sec)
• In deze seconde voeg je de waarde wat je van analogRead krijgt aan een variabel toe. Let er op dat deze variabel van het type “long” is en niet “int” een int gaat namelijk maar tot 32768 en 20x1024=204800.
• Laat in deze routine ook een teller meelopen.
• Staat deze teller op 200, dan is 20 sec verstreken en heb je 200 waardes opgeteld.
• Deel deze waarde door 200 (=gemiddelde) en zet om naar volts.
• Reset de teller en de variabel die je vol gooit met gelezen waardes.

Op deze manier krijg je dezelfde uitkomst met slechts maar 1 floating point berekening.

Als dit het enige is wat je doet met de microcontroller, dan maakt het geen ruk uit om te optimaliseren. Als jouw code snel genoeg is, dan is het prima. Maar in jouw geval wil je nog veel meer sensors uitlezen, en een scherm aansturen. En dan is elk beetje optimalisatie meegenomen. Daarbij is eenvoudigere code makkelijker weer voor jezelf te begrijpen als je over een jaar er nog eens naar kijkt.

Wat je overigens ook gewoon kan doen is het analoog op te lossen. Pak een elco condensator met een weerstand er over (om de condensator ook weer te ontladen) en zet de + van de elco op de poort waar je de sensor van inleest en de – op de GND. Op deze manier krijg je ook gewoon een gemiddelde.

mijn code is op een manier geschreven dat elk deeltje code 1 precies ding doet.
mijn programma zelf doet maar dit:

void loop()
{
  readInput();
  calculateNumbers();
  printSerial();
  printTFT();
  
  //put new values in old varialble to delete from screen next time
  batteryold = battery;
  tempvoltold = tempvolt;
  tempold=temp;
  fuelinstold = fuelinst;
  fuelavgold = fuelavg;
  litersold=liters;
  litersmapold = litersmap;
  distanceold=distance;
  sample_count = 0;
  s1 = s2 = s3 = 0;
}

het deeltje readinput gaat eigenlijk 10keer meten en geeft mij dan een gemiddelde (elke meting iets meer dan 1seconde):

void readInput(){
    while (sample_count < NUM_SAMPLES) {
        s1 += analogRead(inputVolt);
        s2 += analogRead(inputTemp);
        s3 += analogRead(inputFuel);
        sample_count++;
        delay(10);
    }
    sp1 = ((float)s1 / (float)NUM_SAMPLES * refVoltage) / 1024.0; 
    sp2 = ((float)s2 / (float)NUM_SAMPLES * refVoltage) / 1024.0; 
    sp3 = ((float)s3 / (float)NUM_SAMPLES * refVoltage) / 1024.0; 
    delay(1000);
}

bij calculateNumbers ga ik deze waardes omrekenen en op het display zetten. het is dus nutteloos om deze loop 200keer.
na 10keer zet ik namelijk de spanning van de accu op het scherm, alsook de temperatuur van de motor (die loopt namelijk niet zo snel op, van starten tot warm rijden gaat die elke 3sec een graad omhoog en ik wil dit zou houden. niet elke 20sec dat die 6° stijgt). en daarbij komt de instant gemeten waarde van de benzinetank op het scherm (voor verdere analyse wil ik deze waardes nog elke seconde kunnen inlezen)

in calculateNumers ga ik ook men fuelvoltaverage waarde genereren door 20keer deze loop te draaien en de fuelvoltinstant telkens op te tellen.
elke 20keer komt er dus 1 floatdeling bij.

het probleem in u geval is dat je dus 200metingen op 20seconden doen. maar je kan makkelijk zat een oprit van een autosnelweg nemen en daar 20seconden in een bocht zitten. uw brandstofniveau gaat door de foute meting van de vlotter ineens 10liter of meer inzakken.

ik denk dat mijn code tamelijk vlot leesbaar is doordat ik elk gedeelte in een subroutine/procedure/functie gooi. wil ik iets aan het display veranderen, dan gooi ik printTFT(); eruit en herschrijf ik dat deel. ik moet niet in mijn code elk regeltje gaan opzoeken wanneer ik een scherm aanstuur. vroeger had ik printLCD() ook staan (16x2LCD scherm). ik heb dan printTFT toegevoegd en eens dat alles werkte, gewoon de functie/procedure/subroutine printLCD() verwijderd. (alweer niet de hele broncode doorzoeken om elk regeltje te gaan deleten).
ik gebruik ook veel "overloading" van een functie/procedure/subroutine/...

Op 2 mei 2015 10:05:33 schreef Satoer:
Als dit het enige is wat je doet met de microcontroller, dan maakt het geen ruk uit om te optimaliseren. Als jouw code snel genoeg is, dan is het prima. Maar in jouw geval wil je nog veel meer sensors uitlezen, en een scherm aansturen. En dan is elk beetje optimalisatie meegenomen. Daarbij is eenvoudigere code makkelijker weer voor jezelf te begrijpen als je over een jaar er nog eens naar kijkt.

van het moment ik mijn achteruit inschakel, komt een ingang hoog, dan zal mijn loop programma alle bovenstaande NIET meer uitvoeren en doet die enkel het inlezen van de ultrasoonsensoren + aansturen schermen. eens de achteruit niet meer is ingeschakeld, gaat die verder met temperatuur en benzine inlezen.

PS: we gaan hier NIKS analoog gaan oplossen, dan hoef ik niet eens een microcontroller te gebruiken maak kan ik evengoed een ledbalk installeren (digifizz systeem van VW destijds)

[Bericht gewijzigd door fcapri op zaterdag 2 mei 2015 10:44:43 (15%)]

Zeg maar “je” hoor

Ik gaf 20 seconde als voorbeeld, maar je kan daar natuurlijk net zo lang over doen als je nodig acht.

Hoe lang duurt die calculate numbers dan? Als je hier geen delay in hebt zitten, dan duurt elke “refresh” van fuelvoltaverage ook zo’n 22 seconde. (= 20x readinput delay’s)

Afijn, het gebruik van delay moet je echt zien te vermijden. Tijdens de delay doet de microcontroller namelijk helemaal niks. Je scherm zal slechts om de 1.1 seconde (1x 1000ms delay en 10x 10ms delay) verversen.

Kijk even goed naar dit “Blink without delay” voorbeeld:
http://www.arduino.cc/en/Tutorial/BlinkWithoutDelay

PS: we gaan hier NIKS analoog gaan oplossen,

nou nou, dat is dwars, zou een laagdoorlaatfiltertje achter de bezinevlotter niet véél handiger zijn , scheelt hele lappen code.. En je kunt wel heel veel rekenen aan de temperatuur, maar ik weet wel zeker dat je een enorme schijnnauwkeurigheid hebt. je kunt wel weergeven dat het koelwater 84,345 graden celcius is, maar als de sensor al een afwijking van zeg 10% kent, kun je net zo goed in stappen van 5 graden werken ...

btw: heb je in de compiler nooit zien staan "Binary sketch size: 24,272 bytes (of a 32,256 byte maximum)", dan weet je toch hoever je nat bent ....

op de 3de regel van mijn starttopic staat al dat mijn programmeerruimte voor 65% (20k van de 30k) vol zit en 40% van zijn dynamisch geheugen voor variabelen.
heb wat code optimalisatie gedaan en heb nog 18k (59%) in gebruik en slechts 31% van het dynamisch geheugen (nog ff wat floats uit de code halen morgen). en dit terwijl ik functionaliteit toegevoegd heb (welkomscherm met in het groot VW op het display, en pas erna de waardes geven. bijkomend ook het scherm laten freezen als er verkeerde waardes binnenkomen. bv bij contact uit meet die overal 0V op de sensoren, dan behoud die zijn laatste getallen)

mijn temperatuur wordt per graad gegeven en niet na de comma.
op normale rijstijl loopt die tot een 88-89° op. bij doortrekken haal ik 90-92° en op een 97-98° schiet men koelfan aan in de file. hoeft niet 100% correct te zijn, als ik in de toekomst maar kan zien als er iets foutloopt (te warm of te koud) in vergelijking met nu.

lijkt mij toch redelijk correct te zijn.in dit project wil ik nu eens alles digitaal aanpakken. gewoon aftakken aan de analoge tellers van de auto zelf en alles via programmeercode omzetten naar tekst op een display.

voor de rest is het ook gewoon fantastisch om met een laptop naar een auto te lopen van 27jaar oud, ff een usb kabel inpluggen en de auto te voorzien van men laatste software (hebben al een paar mensen raar opgekeken zo). had ik condensatoren gebruikt en ik wil een kortere/langere stabiliteit, moet ik gaan solderen.

Op 2 mei 2015 11:36:22 schreef Satoer:

Afijn, het gebruik van delay moet je echt zien te vermijden. Tijdens de delay doet de microcontroller namelijk helemaal niks. Je scherm zal slechts om de 1.1 seconde (1x 1000ms delay en 10x 10ms delay) verversen.

mja, heb het al gemerkt. bij mijn parkeersensoren code heb ik een loop geschreven en als je dichter dan 1meter komt, geeft die een geluidsignaal (met een kleine delay in in functie van de gemeten afstand).
hoe dichter je komt, hoe korter de delay en hoe sneller de biepjes komen (=programma wordt telkens sneller doorgelopen).

het probleem nu, ik lees 2 sensoren uit, en ik moet een delay van 100ms aanhouden voor de tijdsregistratie van de echo (de eerste stuurt zijn signaal en ik wacht op de echo. als ik ondertussen de 2de zijn signaal stuur, krijg ik foute tijden. probleem is dus dat beide sensoren elkaar beinvloeden.

echter die delay vertraagd mijn programma teveel waardoor mijn biepjes minstens 100ms uit elkaar zitten (en op minder dan 10cm afstand zou de biep constant moeten zijn)

...echter die delay vertraagd mijn programma teveel...

Daarom hebben ze de interrupt ook uitgevonden...

zou een laagdoorlaatfiltertje achter de bezinevlotter niet véél handiger zijn , scheelt hele lappen code...

'Hele lappen code' is wel wat overtrokken. Middelen over bijv. 8 samples is vrij simpel:

Value = ((OldValue * 7) + NewValue) >> 3

Da's inderdaad een heel stuk slimmer

Geheugen lopen nogal eens vol door "memory leaks", stukjes geclaimd geheugen dat men vergeet vrij te geven als het niet meer gebruikt wordt.

Bekijk de stack en heap eens met wat tooltjes?