Det finns inget mer exakt sätt att få tid på arduino, men jag föreslår att du använder millis () istället.

micros () returnerar mikrosekunder, eller miljondelar av en sekund, eftersom arduino var påslagen. Frågan är att det 32-bitars osignerade heltalet som används för att lagra tid på arduinoen bara kan räkna cirka 70 minuter av mikro innan det rinner över och återställs till 0. (se http://arduino.cc/en/reference/micros)

millis () är i tusendels sekund sedan arduino slås på, och den kommer inte att återställas på cirka 50 dagar. Om du tycker att en tusendels sekund är tillräckligt bra upplösning kommer det förmodligen att vara det bättre valet.

Om du behöver tid för att vara absolut, som i dag / timme / minut, måste du köpa en realtidsklocka för att ansluta till arduino. De är ungefär 20 dollar och finns i alla vanliga arduino-tillbehörsbutiker som sparkfun, adafruit, ect.

På din fråga om beställningen går båda kommandona så snabbt att jag inte kan tänka mig någon anledning att det skulle ha någon betydelse.

För "så snabbt som möjligt" skulle jag

1. skriva om din provtagningskod på monteringsspråk (bara de två påståenden, inte hela programmet); och
2. Buffra rådatapar i minnet om du har tillräckligt med det, och lagra det sedan på kortet efter att mätningen skurit. Om du behöver mer datautrymme, tänk på att tidpunkten för en tät monteringsslinga är konsekvent (och snabb!) Och kan mätas. Du kanske inte behöver läsa klockan alls. Observera att du kan få samma timingkonsistens med C / C ++ om du läser analoga och klockportar direkt, och kanske lika snabbt. Det är bara det med monteringsspråk, WYWIWYG (vad du skriver är vad du får); kompilatorns kodgeneratorer och optimerare kommer inte att röra med det.

Ett möjligt problem med din kod när du har skrivit den är att writeData troligen buffrar data för de flesta samtal, men när ett samtal resulterar i en full buffert, skriver hela bufferten till kortet och introducerar jitter i din sampling.

Adresserar din redigering av den 3 juni 2014, "Jag skulle vilja spela in den exakta tiden som analogRead-data samlades in ":

Eftersom du föreslog att använda micros () (i motsats till en realtidsklocka) antar jag att du är nöjd med den relativa tiden. När du väl vet att din datainsamlingskod är helt förutsägbar är förskjutningen från att läsa data till läsningstiden konstant, och eftersom vi ändå använder relativ tid kan det diskonteras eller åtminstone korrigeras för.

Det är naturligtvis inte helt förutsägbart, eftersom du i det här fallet använder en avbruten klocka och kan förvänta dig att ibland avbrottet inträffar mellan data som läses och klockan läs, sträck offset för den tupeln. För att bli ännu mer exakt måste du hålla avbrott avläst, läs timern själv på ett oföränderligt sätt. f / ex, du kan köra timern i en sådan takt att du kan förvänta dig att ta två eller flera prover mellan överflöden av lågordningsbyte, läsa och lagra endast den låga ordningsbyten som ditt tidsprov och efterbearbeta tiden data för att rekonstruera byte med hög ordning genom att detektera omslag i låg ordning.

Med inga avbrott som körs och när du vet hur snabbt du kan sampla data utan att läsa klockan kan du läsa och spara klockan en gång omedelbart innan du tar det första provet och dra slutsatserna för varje efterföljande prov baserat på den kända samplingsfrekvensen.