millis () is interrupt-gestuurd, dus delay () heeft er geen invloed op, althans niet op een op ATmega gebaseerd bord.

Dat wil niet zeggen dat millis () ook helemaal correct is. Elk tikje van de timer is niet precies 1 ms, maar is 1,024 ms. Deze fout stapelt zich geleidelijk op totdat er een correctie is aangebracht. Dit is te zien aan de implementatie van de TIMER0_OVF (timer 0 overflow) interrupt-handler.

Een andere bron van onnauwkeurigheid is de oscillator / kristal zelf, die niet precies 16 MHz is. Het is echter redelijk dichtbij, en zolang de temperatuur niet te veel verandert, is het relatief stabiel.

Het bovenstaande betekent dat je ongeveer 1 ms vrij bent bij gebruik van millis () . Dit klinkt niet als uw probleem.

Een ander mogelijk probleem zou zijn wat getECG () aan het doen is - het kan erg traag zijn.

  float eHealthClass :: getECG (void) {float analog0; // Lezen van analoog inch analog0 = analogRead (0); // binair naar spanning conversie retour analog0 = (float) analog0 * 5 / 1023.0; }  

analogRead () is traag, maar niet zo traag dat het een lus als deze beïnvloedt.

Een ander probleem dat ik heb gezien hebben is wanneer ze de kloksnelheid veranderen, maar boards.txt niet correct veranderen. Dit betekent dat de constanten die worden gebruikt in de millis () -implementatie verkeerd zijn en dat de tijden verkeerd zijn.

Als u werkelijk waarden elke 50 ms wilt lezen, is dit een veel betere manier om te implementeren dit is om het volgende te doen

  statisch lang lastUpdate; if (millis () - lastUpdate > 50) {lastUpdate = millis (); // Do stuff}  

We zouden echt de tijdstempels moeten zien die je krijgt. Als je de jaren 30 daadwerkelijk als 10en ziet, dan is er iets anders aan het werk.

Als interrupts zijn uitgeschakeld voor een significante fractie van de eHealth.getECG () aanroepduur, kan het aantal van millis () achterblijven. Anders zou millis () een veel nauwkeurigere tijd moeten retourneren dan de 3x fouten die je hebt beschreven.

U zei dat uw gesamplede signaal hoger in frequentie lijkt dan u had verwacht, wat kan gebeuren als uw samplefrequentie lager is dan u had bedoeld. Gaat u uit van een samplefrequentie van 20 Hz? Je lus kan behoorlijk wat langer duren dan 50 ms, wat je zou zien in de afgedrukte tijden, maar die zouden nog steeds de kloktijd moeten volgen. Als je daar geen rekening mee zou houden, maar 50 ms / sample had aangenomen, zou je een schijnbare versnelling van de gegevens zien.

Als dit niet het probleem is, is de volgende stap het omschakelen van een uitvoer terwijl u zich in loop () bevindt, en meet de frequentie van de resulterende blokgolf met een frequentiemeter (sommige goedkope DVM's kunnen dit doen) of een 'scope. Doe hetzelfde met een lege loop () . Het eerste experiment zal uw werkelijke bemonsteringsfrequentie of -interval bepalen; de tweede zal je vertellen of millis () (dat wil zeggen, de timer0-frequentie) is wat je verwachtte.

Hier hetzelfde. Ik kan hieraan toevoegen dat als onderbrekingen zijn uitgeschakeld, de gemeten tijd "realtime" is. Hoe dan ook, ik begrijp niet waarom deze vertraging, want als de lus te lang duurt, zou de millis () hoe dan ook real-time waarden moeten retourneren (alleen met meer afstand tussen elke waarde)