Nieuwe Code Flitspaalmelder

[schueler]

Ja, daar had int moeten staan...
Zeer terechte opmerking.

Ik heb het nu opgelost in "gps.c" en "search_eeprom.c" zelf.
In "gps.c" wordt de decimaal ook in seconden omgezet en in "search_eeprom.c" wordt de seconden uit de eeprom ook nog in decimal omgezet. Zo blijft de rest van de code compatibel en kun je in "display.c" de variabelen gps.longitude.seconde en gps.laitude.seconde gebruiken.
Beschikbaar vanaf versie 1.26c dus...

Ben

[joeri fr]

Ik bedoelde de formule om van decimalen naar seconden te gaan;
unsigned char dummy = (unsigned char) ( ( ( gps.gps_lat.minute * 60 ) + 50 ) / 100 );
if ( dummy < 10 ) lcd_putc( '0' );
lcd_value_uchar( dummy );
lcd_putc( 39 ); // '
dummy = (unsigned char) ( ( ( gps.gps_lat.decimal * 60 ) + 50 ) / 100 );


bij het berekenen van 'dummy' heb je dan geen int nodig?

Groeten

[joeri fr]

Ach kijk, nu zijn de minuten goed, maar de decimalen terug in hondersten ipv seconden. Waarschijnlijk ben je iest te enthousiast geweest, en beide formules eruit gehaald...

(met welke versie van hi-tech compileer je juist? ik heb problemen als ik de 9.65P1 gebruik...)

[schueler]

Uhm...
inderdaad, was even de draad kwijt.

Heb nu een versie 1.26c waarin dit gecorrigeerd is en tevens ook voor de vergelijking. Ik heb ook een fout gemaakt in de vergelijking van de POI seconden met die van de GPS.
Ook dit is gecorrigeerd en ga ik vanavond even testen.

Zelf gebruik ik 9.65 build 4410.
Ik heb deze niet meer liggen maar het het rechtstreeks vanuit het web geïnstalleerd. Ik kreeg ook problemen toen ik versie 9.70 wilde gebruiken maar ben dus terug gegaan.


Ben

[schueler]

ja, ik vind die 9.65 versie van jou niet. Ik stuurde je hiervoor een mailtje. Kun je me ev. de link mailen waar jou versie staat?

Ik had de email gezien maar nog niet op gereageerd aangezien ik die versie nog niet gevonden had die ik gebruik.

Wat betreft de formules; in 1.26b werk je me char voor de berekening. Die gaan waarschijnlijk een overflow kennen (bvb. 99 decimalen * 60 = 595, dus boven de toegelaten 255). Waarschijnlijk is een short int aan de orde?

?!?
Welke berekening bedoel je dan?
Ik gebruik 'int' voor de vergelijking van gps met poi. Deze kan dus positief als negatief zijn.
Alleen voor de richting gebruik ik char omdat deze maar drie waarden kan bevatten. Omhoog, omlaag of op gelijk.

Een short int is iets uit de PC wereld.
In de ucontroller wereld is dit meer gebruikelijk.

Byte :  8 bit
Int  : 16 bit
Long : 32 bit

Ben

[schueler]

... maar ik krijg geen detectie van een flitspaal!

Dat is vreemd...
Dat zou niets uit moeten maken...
Is je flitspaal database in de eeprom nog wel intakt?

Ik compileer wel onder windows7. Misschien moet ik de compabiliteitsmode windows xp of zo aanzetten...
Wat draai jij van OS?

Ik gebruik XP maar dat mag niet uitmaken.
Het is compiler afhankelijk, niet operatingsystem...

Ik zal dit weekeinde eens kijken.
Versie 1.26c was overigens geen succes.
Ergens iets niet lekker waardoor ik denk ik seconden met decimalen vergelijk of zo...
Kom ik ook dit weekeinde op terug.


Ben

[joeri fr]

Ik krijg geen foutmeldingen bij het compileren, nadat ik bovenstaande heb veranderd. De display is ook correct, maar ik krijg geen detectie van een flitspaal!
Ik compileer wel onder windows7. Misschien moet ik de compabiliteitsmode windows xp of zo aanzetten...
Wat draai jij van OS?

[joeri fr]

ja, de flitspalen staan allemaal mooi in de eeprom. (8143 palen).

Het volgende gebeurde;
- ik compileerde de 1.26b versie zelf
- inladen in 876A
- opstarten: groene led knipper onregelmatig ('radartje' beweegt ook onregelmatig)
- bij een 'fix van de gps gaat het alarm verschillende keren af

Dan heb ik opnieuw gecompileerd met de regel i=i-128 apart.
Nu loopt het programma mooi, maar vindt geen enkele flitspaal, buiten 1tje op een plaats waar absoluut geen staat.

Misschien zitten er nog te lange regels of teveel bewerkingen in 1 regel?

[schueler]

Misschien zitten er nog te lange regels of teveel bewerkingen in 1 regel?

Dat betekend dus dat ze een paar kritische dingen aan de compiler veranderd hebben. De code mag niet zomaar "functioneel" ander zijn bij een nieuwe release van een compiler. Zie het eigenlijk als een bug in de compiler.
Hoe een compiler omgaat met lange berekeningen heb je zelf in de hand. De ene compiler is de andere compiler en kan uit dezelfde vergelijking een andere uitkomst komen. Om dit voor te gebruik je dan de haakjes om prioriteit te geven.

bijvoorbeed c is van het type char.

Wat is de uitkomst van c = 45 * 4 / 11 ?

De meeste zullen meteen 16 roepen.
Ik denk dat er 0 uit zal komen.
Waarom?
De meeste compiler werken van rechts naar links. Dus eerst "4 / 11" wat resulteert in 0 en dan de vermenigvuldiging wat 45 * 0 = 0 geeft.
Als het gewenste resultaat 16 was moet je dus haakjes aangeven zodat de compiler weet wat je wilt...

Dus : c = ( 45 * 4 ) / 11

ja, de flitspalen staan allemaal mooi in de eeprom. (8143 palen).

Het volgende gebeurde;
- ik compileerde de 1.26b versie zelf
- inladen in 876A
- opstarten: groene led knipper onregelmatig ('radartje' beweegt ook onregelmatig)
- bij een 'fix van de gps gaat het alarm verschillende keren af

Beats me.
Zal inderdaad dan wel op meerdere plekken fout gaan.

Dan heb ik opnieuw gecompileerd met de regel i=i-128 apart.
Nu loopt het programma mooi, maar vindt geen enkele flitspaal, buiten 1tje op een plaats waar absoluut geen staat.

Lijkt inderdaad op dat een berekening fout gecompileerd is...
Zou bij de compare functie kunnen zijn.


Ben

[joeri fr]

Wil jij zo virendelijk zijn om dan even de 1.26 te compileren met de bijgevoegde display.c file?
Dan krijg ik op m'n schermpje wat ik graag wil (gps-coordinaten met snelheid en hoogte erbij).
Misschien neem je het over in jouw programma?
Groeten