Go Down

Topic: [OPGELOST] Splitsen van NMEAtimezone.ino in twee aparte functies (Read 415 times) previous topic - next topic

JevanHa

Hallo, ik heb een probleem wat ik niet opgelost krijg en heb daarbij hulp nodig.
Ik wil van de door mij aangepaste sketch NMEAtimezone.ino twee aparte functies maken.

De eerste functie hoeft maar eenmalig te draaien bijvoorbeeld in setup.
Hierin wordt bepaald of er van Zomer of Wintertijd offset sprake is.

De andere functie moet mij wanneer ik dat wil de lokale tijd met Zomer of Wintertijd tonen.
Deze functie toont de lokale voor de tijdzone waarin je zit weer in combinatie met de Zomer of Wintertijd offset.

Wat ik niet voor elkaar krijg is de overdracht van de juiste variablen van ene naar de andere functie. Ik denk dat het deze zijn (changeover, springForward & fallBack)

Het zal best wel simpel zijn maar ik kom nog veel ervaring en vooral kennis te kort en wil daar graag hulp bij hebben.

Het kan natuurlijk ook zijn dat het niet mogelijk is om te splitsen omdat ........ ik dat nog niet door heb waarom. Dan hoor ik dat ook graag. Vooral het waarom niet.

Mijn uiteindelijke doel is om deze twee functies toe te voegen aan NMEA Reverse GeoCache.
In DEBUG mode wil ik dan wel iedere keer de DST datum/tijd te tonen maar op het LCD scherm alleen na een drukknop verzoek.

Ter download toegevoegd mijn aangepaste (cosmetische en meer commentaar waar ik dat nodig heb) versie van Timezone_CET.ino
Kind regards
Jan
Nederlands Forum   http://arduino.cc/forum/index.php/board,77.0.html

Jantje

Er staat nu
Code: [Select]
static void DST_CET() {  // Central Europe set Daylight Saving Time
...
static NeoGPS::time_t  changeover;
...
}

Maak daarvan

Code: [Select]
NeoGPS::time_t  changeover;
....
static void DST_CET() {  // Central Europe set Daylight Saving Time
...
}


De uitleg:
Als je in een functie een variablele definieerd dan is die alleen gekend in die functie. Zo kan je makkelijk steeds weer dezelfde variabele namen gebruiken. Dit noemt men de scope van de variabele.
Elke keer als je inde functie komt wordt de variabele geinitializeerd en is klaarvoor gebruik.

Dat wil zeggen dat elke keer je in de functie komt de waarde op nul (default of waar je ze op zet) gezet wordt en als je uit de functie gaat wordt de variable verwijderd uit het geheugen.

Wil je dat de waarde "onthouden wordt" maar de scope toch tot de functie beperkt blijft voeg je "static" toe aan de variabele declaratie.

Om dus de variablele in een andere functie te kunnen gebruiken moet je de variabele definitie uit de functie brengen. Dat brengt de scope van de variabele op het niveau van de file en kan die dus ook in een andere functie gebruikt worden.
Een gevolg daarvan is dat de waarde van de variablel onthouden wordt. Het woordje static heeft dus geen zin meer. We spreken nu van een globale variabele.


Met vriendelijke groet
Jantje

Merk op dat static op het niveau van een file niks zegt over de "levensduur" van de variablele maar wel over de scope. Bij kleine projecten (zoals arduino sketches) worden variabelen op het niveau van de file bijna nooit static gemaakt.
Do not PM me a question unless you are prepared to pay for consultancy.
Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -

JevanHa

Je uitleg is duidelijk voor mij en daar ben ik dan ook mee bezig geweest. Als ik de uitleg over static variable ook goed begrepen heb, dan heb ik ook met integer variablen te maken. Ik kreeg toen alleen met een ander probleem te maken.

En dat is het volgende. Ik heb deze sketch gehaald uit examples uit de NeoGPS library  weer gebouwd door  /dev. Ik heb veel respect voor deze man vwb zijn kennis van zaken en sofware.

Maar het zijn dan meteen , en dat is mijn persoonlijke mening, niet de makkelijkste  programma's. Zo heb ik dus ook nog moeite onderstaande variable declaratie te lezen. Wat gaat er nu van wat naar wat is meteen mijn vraag wanneer ik zoiets zie.
NeoGPS::time_t  changeover;
NeoGPS::clock_t springForward, fallBack;
Gelukkig voor mij wordt ik steeds handiger met het rondstrooien van Serial.print en waar nodig zelfs delay(veel)
om dan te kunnen kijken wat er nu wel of niet en wanneer gebeurt. In eerste instantie is het dus een 10 cijferig getal (??? waarom, waarvoor) en de andere twee zijn nul. Klopt ook wel want die worden later pas weer gevuld.

Toen ik dit dus global had gemaakt ging het niet zoals verwachtte. De local time werd netjes met UTC +1 opgehoogd. En dat doet het tweede gedeelte dan ook. Maar de zomer- wintertijd wissel werd niet mee genomen. En dan zie ik niet waarom niet.
Moet ik nog meer Serial.print s rondstrooien om daarmee de flow van de sketch te leren begrijpen ?
Of is daar een andere truuk voor ?
Of gaat het fout omdat het niet in een stream wordt uitgevoerd. Want bij het uitvoerden van deel twee moet ik dan toch eerst een nieuwe sentence met de GPS ophalen om de juiste datum/tijd gegevens binnen te krijgen

Het is misschien verwarrend dat ik praat over deel 1 en deel 2. Ik heb in de download alleen het origineele programma gestuurd. Uit het commentaar er in  is dan wel te halen waar deel 1 of deel 2 zit.
Wat je dus niet ziet is hoe ik het heb uitgevoerd. En dat is dan ook een deel van mijn vraag.
Kind regards
Jan
Nederlands Forum   http://arduino.cc/forum/index.php/board,77.0.html

Go Up