Mikrocontroller.net - Benutzerbeiträge [de]

Datei:SparmaticZerov2 Schaltplan.png

2011-11-07T11:36:09Z

Matze88: hat eine neue Version von „Datei:SparmaticZerov2 Schaltplan.png“ hochgeladen: Neue Version von Knut Ballhause

Sparmatic Heizungsthermostate

2011-11-05T10:09:09Z

Matze88:

Dieser Artikel sammelt Informationen zu den elektronischen Heizkörperthermostaten der Reihe "Sparmatic".

== Modelle ==

Den Sparmatic gibt es in verschiedenen Ausführungen:

Der Sparmatic Zero hat gleich zwei Versionen:
Die alte Version ist mit Schrauben zu öffnen und hat hinter der Batterie einen Pin-Header für den JTAG des Controllers.

Die neue Version hingegen ist mit Plastiknasen so verschlossen, dass er nach dem Öffnen nur mit Hilfsmitteln wieder fest verschließbar ist. Unter den Batterien sieht man jeweils hinter den Batteriekontakten 6 Testpads (2x3 Anordnung).
Die Pads auf der Seite des "+" Batteriekontaktes enthalten dabei den JTAG des Controllers, die andere Seite unter anderem den ISP.

Der Sparmatic Comet hat nur drei Tasten, dafür einen zusätzlichen Drehimpulsgeber.
Hiervon existieren baugleiche(?) Modelle, z.B. der bei Aldi verkaufte "Thermy".

Für Informationen in diesem Thread kann man die genannten Thermostate anhand der Beschaltung des Controllers in zwei Kategorien einteilen:
# Sparmatic Zero alt
# Sparmatic Zero neu, Comet, Thermy

== Sparmatic Zero v1 ==

Dieser wurde bereits ausführlich im Forum diskutiert.
Im folgenden Thread wurde eine alternative Firmware entwickelt:
http://www.mikrocontroller.net/topic/160462

== Sparmatic Zero v2 / Comet / Thermy ==

Die Entwicklung läuft noch. Aktuelle Informationen finden sich im Forum:
http://www.mikrocontroller.net/topic/237375

=== Schaltpläne und Platinenaufnahmen ===

Comet (Leopold B.):

[[Bild:SparmaticComet_Schaltplan.png|600px]]

[[Bild:SparmaticComet_Platine_TOP.jpg|300px]]
[[Bild:SparmaticComet_Platine_BOT.jpg|300px]]

Zero v2 (vorläufig):

[[Bild:SparmaticZerov2_Schaltplan.png|600px]]

[[Bild:SparmaticZerov2_Platine_TOP.jpg|300px]]
[[Bild:SparmaticZerov2_Platine_BOT.jpg|300px]]

=== Display ===

[[Bild:SparmaticComet_LCD_Segment_Belegung.jpg|400px]]

tabellarische Darstellung der einzelnen 14-Segment-Module:

[[Bild:SparmaticComet_SegmentMapping.png|600px]]

Initialisierung des LCD Controllers wie in der Originalfirmware (Leopold B.):
<c>
LCDCRB = (1<<LCDCS)|(0<<LCD2B)|(1<<LCDMUX1)|(1<<LCDMUX0)|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0);
/*
(1<<LCDCS) // Das LCD wird im asynchronen Modus (LCDCS-Bit=1)
mit der Frequenz des Quarzes TOSC1 = 32.768Hz als LCD Clock betrieben.
|(0<<LCD2B) // 1/3 bias is used
|(1<<LCDMUX1)|(1<<LCDMUX0) // 1/4 Duty; COM0:3;
|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0); // SEG0:24
*/

LCDFRR = (0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0)|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0);
/*
(0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0) // N = 16
|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0); // D = 2
// ergo f(frame) = 128Hz
*/

LCDCCR = (1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0)|(/*config.lcd_contrast*/ 10 << LCDCC0);
/*
(1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0) // 575 µs
|(config.lcd_contrast << LCDCC0); // Set the initial LCD contrast level
*/

LCDCRA = (1<<LCDEN)|(1<<LCDAB)|(0<<LCDIE)|(0<<LCDBL);
/*
(1<<LCDEN) // Enable LCD
|(1<<LCDAB) // Low Power Waveform
|(0<<LCDIE) // disable Interrupt
|(0<<LCDBL); // No Blanking
*/
</c>
=== Stellmotor ===

An ADC2 (PF2) kann die Stromaufnahme des Motors gemessen werden. Der Shunt besitzt 2,2 Ohm, der maximale Spannungsabfall ist durch eine parallele Diode begrenzt.
Leopold B. hat mal eine Stellfahrt oszillographiert:

[[Bild:SparmaticComet_Spannung_an_PF2_beim_Schliessen.png|600px]]

Datei:SparmaticComet Spannung an PF2 beim Schliessen.png

2011-11-05T10:08:06Z

Matze88: http://www.mikrocontroller.net/topic/160462#1950022 Leopold B.

http://www.mikrocontroller.net/topic/160462#1950022
Leopold B.

Sparmatic Heizungsthermostate

2011-11-05T10:07:19Z

Matze88: Bildgrößen

Dieser Artikel sammelt Informationen zu den elektronischen Heizkörperthermostaten der Reihe "Sparmatic".

== Modelle ==

Den Sparmatic gibt es in verschiedenen Ausführungen:

Der Sparmatic Zero hat gleich zwei Versionen:
Die alte Version ist mit Schrauben zu öffnen und hat hinter der Batterie einen Pin-Header für den JTAG des Controllers.

Die neue Version hingegen ist mit Plastiknasen so verschlossen, dass er nach dem Öffnen nur mit Hilfsmitteln wieder fest verschließbar ist. Unter den Batterien sieht man jeweils hinter den Batteriekontakten 6 Testpads (2x3 Anordnung).
Die Pads auf der Seite des "+" Batteriekontaktes enthalten dabei den JTAG des Controllers, die andere Seite unter anderem den ISP.

Der Sparmatic Comet hat nur drei Tasten, dafür einen zusätzlichen Drehimpulsgeber.
Hiervon existieren baugleiche(?) Modelle, z.B. der bei Aldi verkaufte "Thermy".

Für Informationen in diesem Thread kann man die genannten Thermostate anhand der Beschaltung des Controllers in zwei Kategorien einteilen:
# Sparmatic Zero alt
# Sparmatic Zero neu, Comet, Thermy

== Sparmatic Zero v1 ==

Dieser wurde bereits ausführlich im Forum diskutiert.
Im folgenden Thread wurde eine alternative Firmware entwickelt:
http://www.mikrocontroller.net/topic/160462

== Sparmatic Zero v2 / Comet / Thermy ==

Die Entwicklung läuft noch. Aktuelle Informationen finden sich im Forum:
http://www.mikrocontroller.net/topic/237375

=== Schaltpläne und Platinenaufnahmen ===

Comet (Leopold B.):
[[Bild:SparmaticComet_Schaltplan.png|500px]]
[[Bild:SparmaticComet_Platine_TOP.jpg250px]]
[[Bild:SparmaticComet_Platine_BOT.jpg|250px]]

Zero v2 (vorläufig):
[[Bild:SparmaticZerov2_Schaltplan.png|500px]]
[[Bild:SparmaticZerov2_Platine_TOP.jpg|250px]]
[[Bild:SparmaticZerov2_Platine_BOT.jpg|250px]]

=== Display ===

[[Bild:SparmaticComet_LCD_Segment_Belegung.jpg|300px]]

tabellarische Darstellung der einzelnen 14-Segment-Module: [[Bild:SparmaticComet_SegmentMapping.png|400px]]

Initialisierung des LCD Controllers wie in der Originalfirmware (Leopold B.):
<c>
LCDCRB = (1<<LCDCS)|(0<<LCD2B)|(1<<LCDMUX1)|(1<<LCDMUX0)|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0);
/*
(1<<LCDCS) // Das LCD wird im asynchronen Modus (LCDCS-Bit=1)
mit der Frequenz des Quarzes TOSC1 = 32.768Hz als LCD Clock betrieben.
|(0<<LCD2B) // 1/3 bias is used
|(1<<LCDMUX1)|(1<<LCDMUX0) // 1/4 Duty; COM0:3;
|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0); // SEG0:24
*/

LCDFRR = (0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0)|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0);
/*
(0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0) // N = 16
|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0); // D = 2
// ergo f(frame) = 128Hz
*/

LCDCCR = (1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0)|(/*config.lcd_contrast*/ 10 << LCDCC0);
/*
(1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0) // 575 µs
|(config.lcd_contrast << LCDCC0); // Set the initial LCD contrast level
*/

LCDCRA = (1<<LCDEN)|(1<<LCDAB)|(0<<LCDIE)|(0<<LCDBL);
/*
(1<<LCDEN) // Enable LCD
|(1<<LCDAB) // Low Power Waveform
|(0<<LCDIE) // disable Interrupt
|(0<<LCDBL); // No Blanking
*/
</c>
=== Stellmotor ===

An ADC2 (PF2) kann die Stromaufnahme des Motors gemessen werden. Der Shunt besitzt 2,2 Ohm, der maximale Spannungsabfall ist durch eine parallele Diode begrenzt.
Leopold B. hat mal eine Stellfahrt oszillographiert: [[Bild:SparmaticComet_Spannung_an_PF2_beim_Schliessen.png|500px]]

Datei:SparmaticComet SegmentMapping.png

2011-11-05T10:05:39Z

Matze88: http://www.mikrocontroller.net/topic/160462#1943939 Leopold B.

http://www.mikrocontroller.net/topic/160462#1943939
Leopold B.

Datei:SparmaticComet LCD Segment Belegung.jpg

2011-11-05T10:05:12Z

Matze88: http://www.mikrocontroller.net/topic/160462#1938053 Leopold B.

http://www.mikrocontroller.net/topic/160462#1938053
Leopold B.

Datei:SparmaticZerov2 Platine BOT.jpg

2011-11-05T10:04:33Z

Matze88:

Datei:SparmaticZerov2 Platine TOP.jpg

2011-11-05T10:04:21Z

Matze88:

Datei:SparmaticZerov2 Schaltplan.png

2011-11-05T10:04:07Z

Matze88:

Datei:SparmaticComet Platine BOT.jpg

2011-11-05T10:03:39Z

Matze88: http://www.mikrocontroller.net/topic/160462#1935344 Leopold B.

http://www.mikrocontroller.net/topic/160462#1935344
Leopold B.

Datei:SparmaticComet Platine TOP.jpg

2011-11-05T10:03:20Z

Matze88: http://www.mikrocontroller.net/topic/160462#1935344 Leopold B.

http://www.mikrocontroller.net/topic/160462#1935344
Leopold B.

Sparmatic Heizungsthermostate

2011-11-05T10:02:36Z

Matze88: Bilder richtig

Dieser Artikel sammelt Informationen zu den elektronischen Heizkörperthermostaten der Reihe "Sparmatic".

== Modelle ==

Den Sparmatic gibt es in verschiedenen Ausführungen:

Der Sparmatic Zero hat gleich zwei Versionen:
Die alte Version ist mit Schrauben zu öffnen und hat hinter der Batterie einen Pin-Header für den JTAG des Controllers.

Die neue Version hingegen ist mit Plastiknasen so verschlossen, dass er nach dem Öffnen nur mit Hilfsmitteln wieder fest verschließbar ist. Unter den Batterien sieht man jeweils hinter den Batteriekontakten 6 Testpads (2x3 Anordnung).
Die Pads auf der Seite des "+" Batteriekontaktes enthalten dabei den JTAG des Controllers, die andere Seite unter anderem den ISP.

Der Sparmatic Comet hat nur drei Tasten, dafür einen zusätzlichen Drehimpulsgeber.
Hiervon existieren baugleiche(?) Modelle, z.B. der bei Aldi verkaufte "Thermy".

Für Informationen in diesem Thread kann man die genannten Thermostate anhand der Beschaltung des Controllers in zwei Kategorien einteilen:
# Sparmatic Zero alt
# Sparmatic Zero neu, Comet, Thermy

== Sparmatic Zero v1 ==

Dieser wurde bereits ausführlich im Forum diskutiert.
Im folgenden Thread wurde eine alternative Firmware entwickelt:
http://www.mikrocontroller.net/topic/160462

== Sparmatic Zero v2 / Comet / Thermy ==

Die Entwicklung läuft noch. Aktuelle Informationen finden sich im Forum:
http://www.mikrocontroller.net/topic/237375

=== Schaltpläne und Platinenaufnahmen ===

Comet (Leopold B.):
[[Bild:SparmaticComet_Schaltplan.png]]
[[Bild:SparmaticComet_Platine_TOP.jpg]]
[[Bild:SparmaticComet_Platine_BOT.jpg]]

Zero v2 (vorläufig):
[[Bild:SparmaticZerov2_Schaltplan.png]]
[[Bild:SparmaticZerov2_Platine_TOP.jpg]]
[[Bild:SparmaticZerov2_Platine_BOT.jpg]]

=== Display ===

[[Bild:SparmaticComet_LCD_Segment_Belegung.jpg]]

tabellarische Darstellung der einzelnen 14-Segment-Module: [[Bild:SparmaticComet_SegmentMapping.png]]

Initialisierung des LCD Controllers wie in der Originalfirmware (Leopold B.):
<c>
LCDCRB = (1<<LCDCS)|(0<<LCD2B)|(1<<LCDMUX1)|(1<<LCDMUX0)|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0);
/*
(1<<LCDCS) // Das LCD wird im asynchronen Modus (LCDCS-Bit=1)
mit der Frequenz des Quarzes TOSC1 = 32.768Hz als LCD Clock betrieben.
|(0<<LCD2B) // 1/3 bias is used
|(1<<LCDMUX1)|(1<<LCDMUX0) // 1/4 Duty; COM0:3;
|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0); // SEG0:24
*/

LCDFRR = (0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0)|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0);
/*
(0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0) // N = 16
|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0); // D = 2
// ergo f(frame) = 128Hz
*/

LCDCCR = (1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0)|(/*config.lcd_contrast*/ 10 << LCDCC0);
/*
(1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0) // 575 µs
|(config.lcd_contrast << LCDCC0); // Set the initial LCD contrast level
*/

LCDCRA = (1<<LCDEN)|(1<<LCDAB)|(0<<LCDIE)|(0<<LCDBL);
/*
(1<<LCDEN) // Enable LCD
|(1<<LCDAB) // Low Power Waveform
|(0<<LCDIE) // disable Interrupt
|(0<<LCDBL); // No Blanking
*/
</c>
=== Stellmotor ===

An ADC2 (PF2) kann die Stromaufnahme des Motors gemessen werden. Der Shunt besitzt 2,2 Ohm, der maximale Spannungsabfall ist durch eine parallele Diode begrenzt.
Leopold B. hat mal eine Stellfahrt oszillographiert: http://www.mikrocontroller.net/attachment/93404/SparmaticComet_Spannung_an_PF2_beim_Schliessen.png

Datei:SparmaticComet Schaltplan.png

2011-11-05T09:59:46Z

Matze88: http://www.mikrocontroller.net/topic/160462#1935344 Leopold B.

http://www.mikrocontroller.net/topic/160462#1935344
Leopold B.

Sparmatic Heizungsthermostate

2011-11-05T09:58:36Z

Matze88:

Dieser Artikel sammelt Informationen zu den elektronischen Heizkörperthermostaten der Reihe "Sparmatic".

== Modelle ==

Den Sparmatic gibt es in verschiedenen Ausführungen:

Der Sparmatic Zero hat gleich zwei Versionen:
Die alte Version ist mit Schrauben zu öffnen und hat hinter der Batterie einen Pin-Header für den JTAG des Controllers.

Die neue Version hingegen ist mit Plastiknasen so verschlossen, dass er nach dem Öffnen nur mit Hilfsmitteln wieder fest verschließbar ist. Unter den Batterien sieht man jeweils hinter den Batteriekontakten 6 Testpads (2x3 Anordnung).
Die Pads auf der Seite des "+" Batteriekontaktes enthalten dabei den JTAG des Controllers, die andere Seite unter anderem den ISP.

Der Sparmatic Comet hat nur drei Tasten, dafür einen zusätzlichen Drehimpulsgeber.
Hiervon existieren baugleiche(?) Modelle, z.B. der bei Aldi verkaufte "Thermy".

Für Informationen in diesem Thread kann man die genannten Thermostate anhand der Beschaltung des Controllers in zwei Kategorien einteilen:
# Sparmatic Zero alt
# Sparmatic Zero neu, Comet, Thermy

== Sparmatic Zero v1 ==

Dieser wurde bereits ausführlich im Forum diskutiert.
Im folgenden Thread wurde eine alternative Firmware entwickelt:
http://www.mikrocontroller.net/topic/160462

== Sparmatic Zero v2 / Comet / Thermy ==

Die Entwicklung läuft noch. Aktuelle Informationen finden sich im Forum:
http://www.mikrocontroller.net/topic/237375

=== Schaltplan ===

Comet (Leopold B.)
http://www.mikrocontroller.net/attachment/92338/SparmaticComet_Schaltplan.png
[[Bild:SparmaticComet_Schaltplan.png]]

Platinenfotos: http://www.mikrocontroller.net/attachment/92339/SparmaticComet_TOP.jpg
[[Bild:SparmaticComet_Platine_TOP.jpg]]
http://www.mikrocontroller.net/attachment/92340/SparmaticComet_BOT.jpg
[[Bild:SparmaticComet_Platine_BOT.jpg]]

=== Display ===

Segmente: http://www.mikrocontroller.net/attachment/92552/SparmaticComet_LCD_Segment_Belegung.jpg

tabellarische Darstellung der einzelnen 14-Segment-Module: http://www.mikrocontroller.net/attachment/92916/SparmaticComet_SegmentMapping.png

Initialisierung des LCD Controllers wie in der Originalfirmware (Leopold B.):
<c>
LCDCRB = (1<<LCDCS)|(0<<LCD2B)|(1<<LCDMUX1)|(1<<LCDMUX0)|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0);
/*
(1<<LCDCS) // Das LCD wird im asynchronen Modus (LCDCS-Bit=1)
mit der Frequenz des Quarzes TOSC1 = 32.768Hz als LCD Clock betrieben.
|(0<<LCD2B) // 1/3 bias is used
|(1<<LCDMUX1)|(1<<LCDMUX0) // 1/4 Duty; COM0:3;
|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0); // SEG0:24
*/

LCDFRR = (0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0)|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0);
/*
(0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0) // N = 16
|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0); // D = 2
// ergo f(frame) = 128Hz
*/

LCDCCR = (1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0)|(/*config.lcd_contrast*/ 10 << LCDCC0);
/*
(1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0) // 575 µs
|(config.lcd_contrast << LCDCC0); // Set the initial LCD contrast level
*/

LCDCRA = (1<<LCDEN)|(1<<LCDAB)|(0<<LCDIE)|(0<<LCDBL);
/*
(1<<LCDEN) // Enable LCD
|(1<<LCDAB) // Low Power Waveform
|(0<<LCDIE) // disable Interrupt
|(0<<LCDBL); // No Blanking
*/
</c>
=== Stellmotor ===

An ADC2 (PF2) kann die Stromaufnahme des Motors gemessen werden. Der Shunt besitzt 2,2 Ohm, der maximale Spannungsabfall ist durch eine parallele Diode begrenzt.
Leopold B. hat mal eine Stellfahrt oszillographiert: http://www.mikrocontroller.net/attachment/93404/SparmaticComet_Spannung_an_PF2_beim_Schliessen.png

Sparmatic Heizungsthermostate

2011-11-05T09:57:56Z

Matze88: Bilder einfügen

Dieser Artikel sammelt Informationen zu den elektronischen Heizkörperthermostaten der Reihe "Sparmatic".

== Modelle ==

Den Sparmatic gibt es in verschiedenen Ausführungen:

Der Sparmatic Zero hat gleich zwei Versionen:
Die alte Version ist mit Schrauben zu öffnen und hat hinter der Batterie einen Pin-Header für den JTAG des Controllers.

Die neue Version hingegen ist mit Plastiknasen so verschlossen, dass er nach dem Öffnen nur mit Hilfsmitteln wieder fest verschließbar ist. Unter den Batterien sieht man jeweils hinter den Batteriekontakten 6 Testpads (2x3 Anordnung).
Die Pads auf der Seite des "+" Batteriekontaktes enthalten dabei den JTAG des Controllers, die andere Seite unter anderem den ISP.

Der Sparmatic Comet hat nur drei Tasten, dafür einen zusätzlichen Drehimpulsgeber.
Hiervon existieren baugleiche(?) Modelle, z.B. der bei Aldi verkaufte "Thermy".

Für Informationen in diesem Thread kann man die genannten Thermostate anhand der Beschaltung des Controllers in zwei Kategorien einteilen:
# Sparmatic Zero alt
# Sparmatic Zero neu, Comet, Thermy

== Sparmatic Zero v1 ==

Dieser wurde bereits ausführlich im Forum diskutiert.
Im folgenden Thread wurde eine alternative Firmware entwickelt:
http://www.mikrocontroller.net/topic/160462

== Sparmatic Zero v2 / Comet / Thermy ==

Die Entwicklung läuft noch. Aktuelle Informationen finden sich im Forum:
http://www.mikrocontroller.net/topic/237375

=== Schaltplan ===

Comet (Leopold B.)
http://www.mikrocontroller.net/attachment/92338/SparmaticComet_Schaltplan.png
[[Bild:SparmaticComet_Schaltplan.png]

Platinenfotos: http://www.mikrocontroller.net/attachment/92339/SparmaticComet_TOP.jpg
[[Bild:SparmaticComet_Platine_TOP.jpg]]
http://www.mikrocontroller.net/attachment/92340/SparmaticComet_BOT.jpg
[[Bild:SparmaticComet_Platine_BOT.jpg]]

=== Display ===

Segmente: http://www.mikrocontroller.net/attachment/92552/SparmaticComet_LCD_Segment_Belegung.jpg

tabellarische Darstellung der einzelnen 14-Segment-Module: http://www.mikrocontroller.net/attachment/92916/SparmaticComet_SegmentMapping.png

Initialisierung des LCD Controllers wie in der Originalfirmware (Leopold B.):
<c>
LCDCRB = (1<<LCDCS)|(0<<LCD2B)|(1<<LCDMUX1)|(1<<LCDMUX0)|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0);
/*
(1<<LCDCS) // Das LCD wird im asynchronen Modus (LCDCS-Bit=1)
mit der Frequenz des Quarzes TOSC1 = 32.768Hz als LCD Clock betrieben.
|(0<<LCD2B) // 1/3 bias is used
|(1<<LCDMUX1)|(1<<LCDMUX0) // 1/4 Duty; COM0:3;
|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0); // SEG0:24
*/

LCDFRR = (0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0)|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0);
/*
(0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0) // N = 16
|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0); // D = 2
// ergo f(frame) = 128Hz
*/

LCDCCR = (1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0)|(/*config.lcd_contrast*/ 10 << LCDCC0);
/*
(1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0) // 575 µs
|(config.lcd_contrast << LCDCC0); // Set the initial LCD contrast level
*/

LCDCRA = (1<<LCDEN)|(1<<LCDAB)|(0<<LCDIE)|(0<<LCDBL);
/*
(1<<LCDEN) // Enable LCD
|(1<<LCDAB) // Low Power Waveform
|(0<<LCDIE) // disable Interrupt
|(0<<LCDBL); // No Blanking
*/
</c>
=== Stellmotor ===

An ADC2 (PF2) kann die Stromaufnahme des Motors gemessen werden. Der Shunt besitzt 2,2 Ohm, der maximale Spannungsabfall ist durch eine parallele Diode begrenzt.
Leopold B. hat mal eine Stellfahrt oszillographiert: http://www.mikrocontroller.net/attachment/93404/SparmaticComet_Spannung_an_PF2_beim_Schliessen.png

Sparmatic Heizungsthermostate

2011-11-05T09:56:04Z

Matze88: Display von Leopold B. aus dem Forum kopiert

Dieser Artikel sammelt Informationen zu den elektronischen Heizkörperthermostaten der Reihe "Sparmatic".

== Modelle ==

Den Sparmatic gibt es in verschiedenen Ausführungen:

Der Sparmatic Zero hat gleich zwei Versionen:
Die alte Version ist mit Schrauben zu öffnen und hat hinter der Batterie einen Pin-Header für den JTAG des Controllers.

Die neue Version hingegen ist mit Plastiknasen so verschlossen, dass er nach dem Öffnen nur mit Hilfsmitteln wieder fest verschließbar ist. Unter den Batterien sieht man jeweils hinter den Batteriekontakten 6 Testpads (2x3 Anordnung).
Die Pads auf der Seite des "+" Batteriekontaktes enthalten dabei den JTAG des Controllers, die andere Seite unter anderem den ISP.

Der Sparmatic Comet hat nur drei Tasten, dafür einen zusätzlichen Drehimpulsgeber.
Hiervon existieren baugleiche(?) Modelle, z.B. der bei Aldi verkaufte "Thermy".

Für Informationen in diesem Thread kann man die genannten Thermostate anhand der Beschaltung des Controllers in zwei Kategorien einteilen:
# Sparmatic Zero alt
# Sparmatic Zero neu, Comet, Thermy

== Sparmatic Zero v1 ==

Dieser wurde bereits ausführlich im Forum diskutiert.
Im folgenden Thread wurde eine alternative Firmware entwickelt:
http://www.mikrocontroller.net/topic/160462

== Sparmatic Zero v2 / Comet / Thermy ==

Die Entwicklung läuft noch. Aktuelle Informationen finden sich im Forum:
http://www.mikrocontroller.net/topic/237375

=== Schaltplan ===

Comet (Leopold B.)
http://www.mikrocontroller.net/attachment/92338/SparmaticComet_Schaltplan.png

Platinenfotos: http://www.mikrocontroller.net/attachment/92339/SparmaticComet_TOP.jpg
http://www.mikrocontroller.net/attachment/92340/SparmaticComet_BOT.jpg

=== Display ===

Segmente: http://www.mikrocontroller.net/attachment/92552/SparmaticComet_LCD_Segment_Belegung.jpg

tabellarische Darstellung der einzelnen 14-Segment-Module: http://www.mikrocontroller.net/attachment/92916/SparmaticComet_SegmentMapping.png

Initialisierung des LCD Controllers wie in der Originalfirmware (Leopold B.):
<c>
LCDCRB = (1<<LCDCS)|(0<<LCD2B)|(1<<LCDMUX1)|(1<<LCDMUX0)|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0);
/*
(1<<LCDCS) // Das LCD wird im asynchronen Modus (LCDCS-Bit=1)
mit der Frequenz des Quarzes TOSC1 = 32.768Hz als LCD Clock betrieben.
|(0<<LCD2B) // 1/3 bias is used
|(1<<LCDMUX1)|(1<<LCDMUX0) // 1/4 Duty; COM0:3;
|(1<<LCDPM2)|(1<<LCDPM1)|(1<<LCDPM0); // SEG0:24
*/

LCDFRR = (0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0)|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0);
/*
(0<<LCDPS2)|(0<<LCDPS1)|(0<<LCDPS0) // N = 16
|(0<<LCDCD2)|(0<<LCDCD1)|(1<<LCDCD0); // D = 2
// ergo f(frame) = 128Hz
*/

LCDCCR = (1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0)|(/*config.lcd_contrast*/ 10 << LCDCC0);
/*
(1<<LCDDC2)|(0<<LCDDC1)|(0<<LCDDC0) // 575 µs
|(config.lcd_contrast << LCDCC0); // Set the initial LCD contrast level
*/

LCDCRA = (1<<LCDEN)|(1<<LCDAB)|(0<<LCDIE)|(0<<LCDBL);
/*
(1<<LCDEN) // Enable LCD
|(1<<LCDAB) // Low Power Waveform
|(0<<LCDIE) // disable Interrupt
|(0<<LCDBL); // No Blanking
*/
</c>
=== Stellmotor ===

An ADC2 (PF2) kann die Stromaufnahme des Motors gemessen werden. Der Shunt besitzt 2,2 Ohm, der maximale Spannungsabfall ist durch eine parallele Diode begrenzt.
Leopold B. hat mal eine Stellfahrt oszillographiert: http://www.mikrocontroller.net/attachment/93404/SparmaticComet_Spannung_an_PF2_beim_Schliessen.png

Sparmatic Heizungsthermostate

2011-11-05T09:51:47Z

Matze88: /* Sparmatic Zero v2 / Comet / Thermy */

Sparmatic Heizungsthermostate

2011-11-05T09:47:07Z

Matze88:

Standardbauelemente

2008-12-08T17:00:01Z

Matze88: /* N-MOSFET */ preis irlz34n wurde bei reichelt auf 43 cent erhöht

Gerade Neulinge kennen das Problem: Man hat eine tolle Schaltung mit vielen Operationsverstärkern, Spannungsreglern, Logikbausteinen, ADCs, was auch immer entwickelt und jetzt geht's an die Realisierung.

Aber welche Bausteine nehmen unter dem Wust der Angebote? Also erstmal auf die Seiten der Hersteller und die Produktpalette durchforsten. Nach einigen Stunden gewissenhafter Recherche hat man dann endlich alle Bauteile beisammen und will bestellen. Und dann kommt das böse Erwachen: Einige Bauelemente gibt's nur bei Reichelt, andere nur bei Conrad. Farnell hat zwar das meiste, aber da kann man als Privatperson leider nicht bestellen. Manche ICs bekommt man nur in 1000er Stückzahlen oder sind halt einfach nur viel zu teuer.

Nach einigen Jahren praktischer Erfahrung hat man dann seine "Standardbauelemente", die man immer wieder verwendet. Dieser Artikel soll helfen andere von dieser Erfahrung profitieren zu lassen. Ähnliche Anregungen findet man auch in der de.sci.electronics-FAQ: Grundausstattung des Bastlers [[http://dse-faq.elektronik-kompendium.de/dse-faq.htm#F.2]].

== Hinweise ==
Hier soll eine Liste von häufig anzutreffenden, preiswerten und verfügbaren Standardbauelementen entstehen. Diese Liste soll knapp und bündig sein, für technische Daten wird auf die Datenblätter verwiesen. Hier gilt: "weniger ist mehr", exotische Bauelemente sind also unerwünscht. Für hier gelistete Typen sollte gelten:
* für Privatpersonen verfügbar
* preiswert (nicht billig)

Nicht gelistet werden sollen:
* hunderte Typen, die alle den gleichen Zweck erfüllen, aber keinen Mehrwert bringen. Stattdessen auf die bekanntesten / preiswertesten beschränken.
* Details. Stattdessen die Felder "Besonderheiten" und "Anwendungen" benutzen, z.B. "I²C, 12bit" bei Besonderheiten für einen ADC oder "Präzision, Audio" bei Anwendungen für einen OpAmp.

Wer eine Sparte, oder eine Anwendung vermisst, aber selber nichts dazu beitragen kann: Einfach hinzufügen. Wer z.B. einen HF OpAmp sucht und hier nicht fündig wird sollte also eine neue Zeile einfügen und in die Spalte Anwendungen "HF" eintragen. Vielleicht kann ja jemand den Rest der Zeile füllen.

Immer den Grundtypen listen und nicht eine der Varianten, und schon gar nicht alle Varianten einzeln! Also z.B. "LM324" statt "LM324N".

Wenn möglich Direktlinks auf Datenblätter vermeiden und eine Suchmaschine befragen: "http://www.datasheetarchive.com/search.php?q=lm324"
* so werden alle Varianten gefunden
* und tote Links vermieden

Die wichtigsten, allgemeinen Standard-Typen ganz oben in der Tabelle listen, danach erst die Spezialtypen für bestimmte Anwendungen.

Und weil es mir so wichtig ist nochmal: Ich rufe geradezu dazu auf, überflüssige, unverfügbare Typen zu löschen!

= Aktive Bauelemente =
== Analog ==

=== Transistoren ===
====NPN====
{| border="1" class="sortable" id="transistors-npn"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| BC 337
| 0,04
| Standardtyp
| bis ~300mA sinnvoll
| R,D
| [http://www.google.de/search?num=100&hl=de&q=datasheet+bc337+filetype%3Apdf&btnG=Suche&meta=lr%3Dlang_de%7Clang_en PDF]
|-

| MMBT 2222A
| 0,05
| SMD TO-23 Gehäuse, Ptot bis 350mW
| bis ~ 300mA sinnvoll
| R,D
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=1;INDEX=0;FILENAME=A100%252F2N2222ASMD%2523FAI.pdf;SID=29Jo9LE6wQAR0AADnPx904c70c3257c398b8b92e44b2052e44b2f]
|-
| BC 547/847
| 0,03
| Standardtyp, BC847 in SMD
| bis ~50mA sinnvoll
| R,D
| [http://www.semiconductors.philips.com/acrobat_download/datasheets/BC847_BC547_SER_6.pdf PDF]
|-
| BC 635/639
| 0,07
| andere Pinbelegung als BC547 (= BD135 in anderem Gehäuse)
| bis ~500mA sinnvoll
| R,D
| [http://www.semiconductors.philips.com/acrobat/datasheets/BC635_BCP54_BCX54_6.pdf PDF]
|-
| BD 433/437
| 0,19
| niedrige Sättigungsspannung
| bis ~2A sinnvoll
| R
| [http://www.fairchildsemi.com/ds/BD%2FBD435.pdf PDF]
|-
| TIP41C
| 0,24
| Ptot: 65W, geringe Stromversärkung (max.75)
| Grenzwert 10A
| R
| [http://www.datasheetcatalog.org/datasheet/fairchild/TIP41C.pdf PDF]
|-
| TIP102
| 0,42
| Ptot bis 80W mit Kühlkörper, hohe Stromverstärkung von über 1000 über einen sehr großen Bereich.
| Grenzwert 8A
| R
| [http://www.fairchildsemi.com/ds/TI%2FTIP102.pdf PDF]
|-
| TIP 3055
| 0,75
| Ptot bis 90W mit Kühlkörper, Stromverstärkung sehr niedrig (bei großen Strömen << 100)
| Grenzwert 15A
| R
| [http://www.ortodoxism.ro/datasheets/PowerInnovations/mXvutwr.pdf PDF]
|-====
| 2N6284
| 2-3€
| Linearer NPN-PowerDarlington; Ptot 160W; Antiparalele C-E Diode; komplementärtyp: 2N6287
| Vcbo 100V; Vceo 100V;Vebo 5V;Ic 20A (peak 40A);Ib 0,5A
| R
| [http://www.ortodoxism.ro/datasheets/SGSThomsonMicroelectronics/mXvsruq.pdf PDF]
|-
|}

====PNP====
{| border="1" class="sortable" id="transistors-pnp"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| BC 327
| 0,04
| Komplementärtyp zu BC337
| bis ~300mA sinnvoll
| R,D
| [http://www.google.de/search?num=100&hl=de&q=datasheet+bc327+filetype%3Apdf&btnG=Suche&meta=lr%3Dlang_de%7Clang_en PDF]
|-
| BC 557
| 0,03
| Komplementärtyp zu BC547C
| bis ~50mA sinnvoll
| R,D
| [http://www.semiconductors.philips.com/acrobat_download/datasheets/BC556_557_4.pdf PDF]
|-
| BC 636/640
| 0,07
| Komplementärtyp zu BC635
| bis ~500mA sinnvoll
| R,D
| [http://www.semiconductors.philips.com/acrobat/datasheets/BC640_BCP53_BCX53_6.pdf PDF]
|-
| TIP 2955
| 0,75
| Ptot bis 90W mit Kühlkörper
| Grenzwert 15A
| R
| [http://www.ortodoxism.ro/datasheets/motorola/TIP2955.pdf PDF]
|-
|}

Siehe auch: [[Transistor-Übersicht]]

====N-MOSFET====

BUZ10, BUZ11 etc. sind wie alle BUZ Typen ziemlich veraltet. Bitte nicht listen; es gibt fast immer was besseres von IRF.
{| border="1" class="sortable" id="mosfet-n"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| IRF1010N
| 0,87
| max 50V, max 85A, 11 mOhm On-Widerstand
| Alles, was mit POWER zu tun hat ...
| R
| [http://www.irf.com/product-info/datasheets/data/irf1010n.pdf PDF]
|-
| IRLZ34N
| 0,43
| max 55V, max 30A, 35 mOhm On-Widerstand
| Gatespannung kompatibel mit 5V-Controllern.
| R, D
| [http://www.irf.com/product-info/datasheets/data/irlz34n.pdf PDF]
|-
| IRLML2502
| 0,42
| max 20V, max 4,2A (cont.), 45 mOhm On-Widerstand
| SOT23 SMD-FET, extrem niedrige V_GS_th, bei niedrigem R_DS_on
| D
| [http://www.irf.com/product-info/datasheets/data/irlml2502.pdf PDF]
|-
| BS170
| 0,13
| max 60V, bis 500mA, 5 Ohm On-Widerstand
| veraltete Technik, aber in bastelfreundlichem TO-92 Gehäuse
| R,D
| [http://www.fairchildsemi.com/ds/BS/BS170.pdf PDF] (Fairchild)
|-
| BSS123
| 0,06
| max 100V, max 170mA (cont.), Thresholdspannung 1,7V, On-Widerstand 1,3Ohm
| SOT23 SMD-FET, auch für 3V3-versorgte Schaltungen bestens geeignet
| R,D
| [http://www.fairchildsemi.com/ds/BS/BSS123.pdf PDF] (Fairchild)
|-
| BUK100-50GL
|
| Logic-Level Power
|
|
| [http://www.nxp.com/pip/BUK100-50GL_1.html PDF] (NXP)
|-
| IRLIZ44N
|
| Logic-Level Power
|
|
|
|-
| IRLR2905, IRLU2905
|
| Logic-Level Power
|
| C
|
|-
| IRLU3410
|
| Logic-Level Power
|
|
|
|}

====P-MOSFET====

{| border="1" class="sortable" id="mosfet-p"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| IRLML6401
| 0,21
| max -12V, ca -4,3A (cont.), ca. 0,05 Ohm On-Widerstand
| SOT-23 SMD FET, extrem niedrige V_GS_th, bei niedrigem R_DS_on
| D
| [http://www.irf.com/product-info/datasheets/data/irlml6401.pdf]
|-
| IRF7220
| 1,10
| max -14V, ca -10A (cont.), ca. 0,02 Ohm On-Widerstand
| Gehäuse SO-8, brauchbar in 3,3V Systemen
| R
| [http://www.irf.com/product-info/datasheets/data/irf7220.pdf PDF]
|-
| IRFR5305
| 0,56
| max -55V, -31A (cont.), ca. 0,065 Ohm On-Widerstand
| Gehäuse D-Pak (SMD, TO-252AA), Uth=-2 bis -4V
| R
| [http://www.irf.com/product-info/datasheets/data/irfr5305.pdf PDF]
|-
| BS250
| 0,26
| max -45V, bis -230mA (cont.), 14 (und mehr) Ohm On-Widerstand
| veraltete Technik aber in bastelfreundlichem TO-92 Gehäuse von R lieferbar
| R
| [http://www.vishay.com/docs/70209/70209.pdf PDF] (Vishay)
|-
| NDS0610
| 0,07
| max -60V, bis -120mA (cont.), 20 (und mehr) Ohm On-Widerstand
| SMD Gehäuse Anwendung z.B. als [http://www.mikrocontroller.net/topic/42113#317220 Verpolschutz mit geringem Spannungsabfall]
| D DK
| [http://www.fairchildsemi.com/ds/ND%2FNDS0610.pdf PDF] (Fairchild)
|-
|}

====MOSFET-Pärchen====

{| border="1" class="sortable" id="mosfet-n-p"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| IRF7389
| 0,51
| 30 V, >2,5 A, 30/60 mOhm On-Widerstand
| Gehäuse SO-8
| D,R
| [http://www.irf.com/product-info/datasheets/data/irf7389.pdf PDF]
|-
|}

Siehe auch: [[Mosfet-Übersicht]]

=== Dioden ===
{| border="1" class="sortable" id="mosfet-p"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| 1N4148
| 0,02
| Kleinsignal-Gleichrichterdiode
|
| R,D
| [http://www.fairchildsemi.com/ds/1N%2F1N4148.pdf D]
|-
| 1N4001..1N4007
| 0,02
| Mehrzweck-Gleichrichterdiode, 1N4001..1N4007 mit gestaffelter Sperrspannung
| 1A
| R,D
| [http://www.fairchildsemi.com/ds/1N/1N4001.pdf D]
|-
| UF4001..UF4007
| 0,06 - 0,07
| UltraFast-Gleichrichterdiode, gestaffelte Sperrspannung, trr<50ns bzw 75ns
| 1A
| R, D
| [http://www.ortodoxism.ro/datasheets/vishay/uf4001.pdf Datenblatt]
|-
| 1N5400..1N5408
| 0,06
| Mehrzweck-Gleichrichterdiode, 1N5400..1N5408 mit gestaffelter Sperrspannung
| 3A, 50..1000V
| R, D
| [http://www.ortodoxism.ro/datasheets/fairchild/1N5401.pdf D]
|-
| UF5404, UF5408
| 0,11 bzw 0,22
| UltraFast-Gleichrichterdiode, gestaffelte Sperrspannung, trr<50ns bzw 75ns
| 3A, 50..1000V
| R
|
|-
| BAT46
| 0,10
| Kleinsignal-Schottky-Diode
| 150mA
| D,R
| [http://www.alldatasheet.com/view.jsp?Searchword=BAT46 D]
|-
| BAT54(A/C/S)
| 0,072
| sehr schnelle Kleinsignal-(Doppel-)Schottky-Diode
| 200mA
| R, D
| [http://www.alldatasheet.com/view.jsp?Searchword=BAT54 D]
|-
| SB120-SB160
| 0,13
| Schottky-Diode
| 1A 20-60V
| R
| [http://www.alldatasheet.com/view.jsp?Searchword=SB140 D]
|-
| 1N5817-1N5819
| 0,15
| Schottky-Diode, sehr ähnlich zu SB120-140
| 1A 20/30/40V
| R, D, C
| [http://www.alldatasheet.com/view.jsp?Searchword=1N5819 D]
|-
| BA159
| 0,051
| Standard-Diode
| HF 1A 1000V
| R
| [http://www.alldatasheet.com/view.jsp?Searchword=BA159 D]
|-
| BAV99
| 0,041
| Standard-Doppeldiode, SOT-23
| ESD-Schutz
| R
| [http://www.alldatasheet.com/view.jsp?Searchword=BAV99 D]
|-
|}

Siehe auch: [[Dioden-Übersicht]]

=== Instrumentenverstärker ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| INA128
| 6,15 (R)
| Verstärkung über 1 Widerstand einstellbar
| Brückenverstärker , Datenerfassung
| R,F
| [http://focus.ti.com/lit/ds/symlink/ina128.pdf#search=%22ina128%22 PDF]
|-
| INA326
| ca. 3 (DK)
| Low Power, läuft an 3.3 oder 5 V
| Medizintechnik (EKG), Sensoren
| DK
| [http://www.ti.com/lit/gpn/ina326 PDF]
|-
| AD620
| ca. 8 (R)
| Standardtyp
| EKG, EEG, Brückenverstärker
| R, RS, DK
| [http://www.analog.com/UploadedFiles/Data_Sheets/37793330023930AD620_e.pdf PDF]
|-
|}

=== Operationsverstärker ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| LM358
| 0,09
| Single Supply
| 2-fach Standard-OP
| alle
| [http://www.datasheetarchive.com/search.php?q=lm358 PDF]
|-
| LM324
| 0,13
| Single Supply
| 4-fach Standard-OP
| alle
| [http://www.datasheetarchive.com/search.php?q=lm324 PDF]
|-
| LM393
| 0,10
| Single Supply
| 2-fach Standard-Komparator
| alle
| [http://www.datasheetarchive.com/search.php?q=lm393 PDF]
|-
| LM339
| 0,10
| Single Supply
| 4-fach Standard-Komparator
| alle
| [http://www.datasheetarchive.com/search.php?q=lm339 PDF]
|-
| TLC3702
| 0,80
| Single Supply
| 2-fach Micropower-Komparator (20µA) PushPull Ausgang
| F
| [http://www.datasheetarchive.com/search.php?q=tlc3702 PDF]
|-
| NE5532
| 0,23
| 2 * Audio OP
| kann 600 Ohm treiben
| alle?
| [http://www.datasheetarchive.com/search.php?q=NE5532 PDF]
|-
| LMC6484
| 2,35
| rail-to-rail in/out
| 4-fach OP
| R
| [http://www.national.com/ds.cgi/LM/LMC6484.pdf D]
|-
| TS912
| 1
| rail-to-rail in/out
| 2-fach OP
| R
| [http://www.st.com/stonline/products/literature/ds/2325/ts912.pdf PDF]
|-
| OP07
| 0,25
| geringer Offset
| <80µV je nach Hersteller
| R,D
| [http://www.reichelt.de/?;ACTION=7;LA=6;OPEN=1;INDEX=0;FILENAME=A200%252FOP07%2523AD.pdf; PDF]
|-
| TL062
| 0,17
| Low Power/JFET Eingang
| 2-fach OP
| R
| [http://focus.ti.com/lit/ds/symlink/tl062.pdf PDF]
|-
| TL072
| 0,15
| Low Noise/JFET Eingang
| 2-fach OP
| R
| [http://focus.ti.com/lit/ds/symlink/tl072.pdf PDF]
|-
| LMC6062
| 2,05
| Micropower, CMOS
| 2-fach OP, Is=40 µA (typ.)
| R
| [http://www.national.com/ds.cgi/LM/LMC6062.pdf PDF]
|-
| LM4250
| 0,98
| Micropower, "programmierbar"
| 1-fach OP, Is=10 µA
| R
| [http://www.national.com/ds.cgi/LM/LM4250.pdf PDF]
|-
| ICL7611
| 0,82
| Micropower, "programmierbar"
| 1-fach OP, Is=10 µA
| R
| [http://datasheets.maxim-ic.com/en/ds/ICL7611-ICL764X.pdf PDF]
|-
| ICL7621
| 1,10
| Micropower
| 2-fach OP, Is=100 µA
| R
| [http://datasheets.maxim-ic.com/en/ds/ICL7611-ICL764X.pdf PDF]
|-
| LM 13600
| 0,90
| National
| OTA - Steilheits-OP 50V/µs
| R
| [http://www.national.com/ds.cgi/LM/LM13700.pdf PDF]
|-
| CA 3140
| 0,47
| Intersil
| BIMOS-OP - kleiner Eingangsstrom
| R
| [http://www.intersil.com/data/fn/fn957.pdf PDF]
|-
|}

Warum findet sich in obiger Liste kein 741, war er doch lange Zeit "der" OPV schlechthin? Nun, er wird allgemein als "veraltet" angesehen, da er aus den 60er Jahren stammt (1968 von Fairchild vorgestellt, etwa ab 1969 kommerziell erhältlich) und keine besonderen technischen Daten aufweist. Der immerhin etwa fünf Jahre jüngere 324 (von 1974) kostet häufig ein paar Cent weniger, enthält dafür aber vier statt einen OPV mit besseren Daten.

Bitte oben noch einige günstige Low-Power-OPVs einfügen! Danke!

=== Spannungsregler ===
==== Linearregler ====
{| border="1" class="sortable" id="linearregler"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| LP2950
| 0,39 - 0,53
| Festspannungsregler Low-Dropout
| 3 - 5V 100mA, TO-92, <120µA Ruhestrom
| R, D
| [http://www.datasheetarchive.com/search.php?q=LP2950 PDF]
|-
| LM317
| 0,22
| Linearer einstellbarer Spannungsregler
| max 40V -> 1,2 - 37V, max 1.5A, TO220
| alle
| [http://www.datasheetarchive.com/search.php?q=LM317 PDF]
|-
| MAX663
| 1,80
| Linearer, einstellbarer Spannungsregler
| sehr niedriger Eigenstromverbrauch
| R
| [http://datasheets.maxim-ic.com/en/ds/MAX663-MAX666.pdf PDF]
|-
| LM78xx
| <1,00
| Festspannungregler (xx=05: 5V, xx=12: 12V ...)
|  
| alle
|  
|-

| LM79xx
| <1,00
| Festspannungregler, negative Spannung (xx=05: -5V, xx=12: -12V ...)
|  
| alle
|  
|-
| LF33
| <1,00
| Festspannungregler
| +3,3V, TO-220, 1A
| R
|  
|}

Siehe auch:
* [http://www.national.com/an/AN/AN-1148.pdf AN-1148: Application Note 1148 Linear Regulators: Theory of Operation and Compensation] von National Semiconductor Corporation (PDF)

==== Schaltregler ====
{| border="1" class="sortable" id="schaltregler"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| LM2576
| 1,60
| Step-Down
| max 40V -> 1,2 - 37V, max 3A, TO220-5
| alle
| [http://www.datasheetarchive.com/search.php?q=LM2576 PDF] - [http://www.mikrocontroller.net/topic/58094#450561 mit Funk-Entstördrossel FED100µ (Reichelt...) bis 3 A]
|-
| MC34063A
| 0,25
| Step-Up/-Down
| SO-8/DIP-8; Tool zum Berechnen auf www.nomad.ee
| R
| [http://www.onsemi.com/pub/Collateral/MC34063A-D.PDF PDF], [http://www.mikrocontroller.net/articles/MC34063]
|-
| PR4401
| 0,50
| Led-Treiber, Step-Up, Batteriebetrieb mit einer Zelle (bis 0,9 V)
| SO-23
| R, [http://www.ak-modul-bus.de/ AK Modul-Bus]
| [http://www.prema.com/pdf/pr4401.pdf PDF]

|-
|}

==== Shuntregler/[[Spannungsreferenz]] ====
{| border="1" class="sortable" id="schaltregler"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| TL431
| 0,10
| Shuntregler mit 2,5 V interner Präzisions-Referenz < 2 %
| Präzise Alternative zur Z-Diode, Spannungsbegrenzung
| C, R, DK
|[http://www.datasheetarchive.com/search.php?q=TL431 PDF]
|-
| LT1021
| 5,00
| Shuntregler mit interner Präzisions-Referenz < 0,05 %
| hoch präzise Alternative zur Z-Diode
| C, R, DK
|[http://www.datasheetarchive.com/search.php?q=LT1021 PDF]
|-
| LM336
| 0,30
| Shuntregler mit interner Präzisions-Referenz < 4 %
| Präzise Alternative zur Z-Diode
| C, R, DK
|[http://www.datasheetarchive.com/search.php?q=LM336 PDF]
|-
|}

=== Timer ===
{| border="1" class="sortable" id="can"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| 555
| 0,15
| Universeller Zeitgeber.
| Für alles, wirklich alles. CMOS-Versionen lassen sich aufgrund ihrere niedrigeren Betriebsspannung besser mit µCs verbinden.
| alle
| [http://www.google.de/search?q=555+Datasheet Google]
|-
| DS1307
| 1,95
| 64 X 8 Serial Real Time Clock. Quarzuhr / Kalender Baustein mit serieller TWI-Schnittstelle.
| Uhrenfunktion, unabhängig vom µC, aber µC-Steuerbar. Batteriepufferbar (3V-Knopfzelle wie CR2032) um die Zeit bei ausgeschalteter Board-Betriebsspannung weiter zu zählen.
| D, R
| [http://www.google.de/search?q=DS1307 Google]
|-
| PCF8583
| 1,50
| I²C/TWI Real Time Clock, Calendar, SRAM, Alarm, Timer, Eventcounter
| Auf Basis eines SRAM-chips, deshalb kann ein großer Teil als SRAM genutzt werden (ca 240 bytes). Berechnet Datum (4 jahre, jahr0 = schaltjahr), Uhrzeit (12/24), Wochentag. ein 32khz-Uhrenquarz ist nötig, sonst als Uhr unbrauchbar da störempfindlich. Möglichkeit eines Interruptausganges bei voreingestellter Alarmzeit. Bemerkenswert einfaches Protokoll. Kann umgeschaltet werden in einen Timer-Modus (einfacher Counter mit bestimmter Timebase) oder Event-Counter-Modus (Eingangssignale zählen).
| R
| [http://www.alldatasheet.com/view.jsp?Searchword=PCF8583]
|-
|}

=== Analogschalter und Multiplexer ===
Die DG2xx DG3xx DG4xx, teilweise auch DG5xx bezeichnen Analogschalter und Multiplexer die sich zum Industriestandard entwickelt haben. Es gibt sie von vielen Herstellern und zahlreichen Ausführungen in allen R(on) Bereichen und sind Pinkompatibel. Anstelle von "DGxxx" benutzen Hersteller für verbesserte/moderne Präzissions-Versionen ihre eigenen Präfixe wie "ADGxxx" von Analog Devices oder "MAXxxx" von Maxim. Für einfache Schalter werden häufig die letzten zwei Ziffern 01 bis 05 und 11-13 benutzt, 06/07/08/09 bezeichnet 16:1 8:1 und 4:1 Multiplexer in Single Ended und Differential Ended. Spannungsbereich geht bis +/-12 oder +/-15 V, die Steuereingänge haben zum Teil TTL-Kompatibilität, andernfalls einen Pin der den Logikpegel definiert (z.B. VCC).
{| border="1" class="sortable" id="can"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| DG201/DG202/DG212
| ~2-3€
| Vierfach Einzelschalter in SPST, SPDT,
| Zum µC-gesteuerten schalten von Analogsignalen, in Audio, Video, und Messschaltungen, in OP-Schaltungen für programmierbare Verstärkungen
| Maxim, Analog Devices, u.a.
| [http://search.datasheetcatalog.net/cgi-bin/helo.pl?text=DG202&action=Search]
|-
| DG306/DG406
| ~4-10€
| 16:1 Analog-Multiplexer
| Zum Multiplexen von Analogsignalen, Kanalauswahl für ADC-Messschaltungen.
| Maxim, Analog Devices, u.a.
| [http://search.datasheetcatalog.net/cgi-bin/helo.pl?text=DG306&action=Search]
|-
| DG307/DG408
| ~4-10€
| Zweifach 8:1 bzw Einfach 8:1 differential ended (8 Doppelkanäle)
| Zum Multiplexen von Analogsignalen, Kanalauswahl für ADC-Messschaltungen auch für differentielle Eingänge.
| Maxim, Analog Devices, u.a.
| [http://search.datasheetcatalog.net/cgi-bin/helo.pl?text=DG308&action=Search]
|-
|}

== Digital ==

=== CAN ===
{| border="1" class="sortable" id="can"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| MCP2515
| 2,55
| SPI-CAN 2.0B Baustein
|
| D,F,R
| [http://www.datasheetarchive.com/search.php?q= PDF]
|-
| SJA1000
| 4,55
| PellCAN 2.0B 1Mbit/s
|
| F,R
|-
|}

=== Logik ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| 74HC4050
| 0,27
| z.B. 5V => 3V
| Pegelwandler unidirektional abwärts
| alle
| [http://www.datasheetarchive.com/search.php?q=74hc4050 PDF]
|-
| HEF4104B
| 0,77
| z.B. 5V => 12V
| Pegelwandler unidirektional aufwärts
| alle
| [http://www.datasheetarchive.com/search.php?q=HEF4104B PDF]
|-

|}

=== USB ===
{| border="1" class="sortable" id="usb"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| FT232
| 3,59
| USB <-> RS232 Wandler
| Zugriff über virtuellen COM Port
| D, R
| [http://www.datasheetarchive.com/search.php?q=ft232 PDF]
|-
| FT245
| 4,79
| USB <-> Seriell Wandler mit paralleler Schnittstelle
| Zugriff über virtuellen COM Port
| D, R
| [http://www.datasheetarchive.com/search.php?q=ft245 PDF]
|-
| TUSB3410
| 3,50
| USB <-> RS232 mit 8052 CPU
| Zugriff über virtuellen COM Port
| DK
| [http://focus.ti.com/docs/prod/folders/print/tusb3410.html PDF]
|-
|}

=== Treiber ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| ULN2003A
| 0,17
| 7-fach Low-Side Treiber
| 50V/500mA
| R, D
| [http://www.datasheetarchive.com/search.php?q=ULN2003 PDF]
|-
| ULN2803A
| 0,44
| 8-fach Low-Side Treiber
| 50V/500mA
| alle
| [http://www.datasheetarchive.com/search.php?q=ULN2803 PDF]
|-
| UDN2981
| 1,50
| 8-fach High-Side Treiber
| 50V/500mA
| R
| [http://www.datasheetarchive.com/search.php?q=UDN2981 PDF]
|-
| ICL7667
| 1
| Dual inverting FET Treiber
| 18V, 20ns@1nF
| R
| [http://www.datasheetarchive.com/search.php?q=ICL7667 PDF]
|-
|}

=== Analogschalter aus der 4000 Logikreihe ===
Die folgenden Schalter werden digital gesteuert, daher sind sie im Kapitel [[#Digital|Digital]] einsortiert. Sie basieren auf standard CMOS-Technologien, sind daher weit verbreitet, günstig, haben aber daher auch nur mäßige Eigenschaften und begrenzte Anwendungsbereiche. Analogschalter für Präzisionsanwendungen sind im Kapitel [[#Analog|Analog]].

{| border="1" class="sortable" id="can"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| 4051
| 0,25
| 8:1 Analogmultiplexer.
| Zum µC-gesteuerten Umschalten von Analogsignalen. Je nach Typ sind Analogsignale bis in den 100 MHz Bereich mit einer Schaltfrequenz bis mehrere 10 MHz möglich.
| alle
| [http://www.google.de/search?q=4051+datasheet Google]
|-
| 4052
| 0,11
| Zwei 4:2 Analogmultiplexer.
| Zum µC-gesteuerten Umschalten von Analogsignalen. Je nach Typ sind Analogsignale bis in den 100 MHz Bereich mit einer Schaltfrequenz bis mehrere 10 MHz möglich.
| alle
| [http://www.google.de/search?q=4052+datasheet Google]
|-
| 4053
| 0,16
| Drei 3:2 Analogmultiplexer.
| Zum µC-gesteuerten Umschalten von Analogsignalen. Je nach Typ sind Analogsignale bis in den 100 MHz Bereich mit einer Schaltfrequenz bis mehrere 10 MHz möglich.
| alle
| [http://www.google.de/search?q=4053+datasheet Google]
|-
| 4066
| 0,15
| Vierfach Analogschalter / -koppler.
| Zum µC-gesteuerten Schalten oder Umschalten von Analogsignalen. Je nach Typ sind Analogsignale bis in den 100 MHz Bereich mit einer Schaltfrequenz bis mehrere 10 MHz möglich.
| alle
| [http://www.google.de/search?q=4066+datasheet Google]
|-
| 4067
| 0,60
| 1:16 Analogmultiplexer/-demultiplexer
|
| alle
| [http://www.google.de/search?q=4067+datasheet Google]
|-
|}

=== Galvanische Trennelemente ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| CNY17
| 0,17
| Optisch, Standardtyp
| billig
| R,C
| [http://www.datasheetarchive.com/search.php?q=CNY17 PDF]
|-
| 6N137
| 0,49
| Optisch, Logikausgang
| sehr schnell
| R,D
| [http://www.datasheetarchive.com/search.php?q=6N137 PDF]
|-
| ADUM240*
| 10
| Induktiv, 3V/5V Logik
| extrem schnell, EN90650, 5kV
| F
| [http://www.datasheetarchive.com/search.php?q=adum240 PDF]
|-
| ISO72*
| 1,25
| Kapazitiv, 3V/5V
| 6kV, bis zu 150MHz
| DK,F
| [http://focus.ti.com/paramsearch/docs/parametricsearch.tsp?family=analog&familyId=897&uiTemplateId=NODE_STRY_PGE_T PDF]
|-
|}

=== Displays ===
Bei den Textdisplays eignet sich praktisch jedes HD44780 konforme Display.
Praktisch jeder Elektronikversender hat eine Auswahl an verschiedenen Größen zu bieten.
Wer keinen besonderen Anspruch auf die Größe der Displays hat sollte sich bei Pollin und in Ebay umschauen.

=== Speicher ===

==== [[EEPROM]] ====

{| border="1" class="sortable" id="EEPROMmemory"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| ST 24C01 BN6, ST 24C02 BN6, ST 24C256 BN6 (allgemein 24C## mit ## Größe in kbit)
| 0,14€ - 1,40€
| EEPROM Speicher mit seriellem (I2C) Interface, 1kbit bis 256 kbit Speicher. Viele verschiedene Hersteller.
| Speichern von Konfigurationsdaten
| R
| [http://www.datasheetarchive.com/search.php?q=24C PDF]
|-
|}

== Converter ==
=== ADC ===

{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Geschwindigkeit
! Lieferant
! Datenblatt
|-
| ADC830
| 6
| AD-Wandler
| 8770CPS
| C,R
| [http://www.datasheetarchive.com/search.php?q=adc830 PDF]
|-
|-
| LTC2400
| 9,55
| 24-Bit-ADC
| ca. 6CPS
| R
| [http://www.linear.com/pc/downloadDocument.do?navId=H0,C1,C1155,C1001,C1152,P1636,D1887]
|-

|}

=== DAC ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| 08
| 0,90
| 8-Bit DAC mit parallelem Businterface.
| Alt, preiswert. Benötigt viele µC Pins (min. 8, paralleler Bus) und eine doppelte Spannungsversorgung. Langsamere Version: 0808.
| alle
| [http://www.google.de/search?q=LTC1456+Datasheet Google]
|-
| 7524
| 3,00
| 8-Bit DAC mit parallelem Businterface
| Benötigt viele µC Pins. Single-Supply (5V bis 15V).
| alle
| [http://www.google.de/search?q=7524+Datasheet Google]
|-
| TDA8444
| 1,20
| Achtfach 6-Bit DAC mit seriellem TWI-Businterface. Bezahlbarer sechsfach-DAC, allerdings mit geringer Auflösung.
| Dort wo µC gesteuert viele Ausgangskanäle mit geringer, ungenauer Auflösung benötigt werden.
| R
| [http://www.google.de/search?q=TDA8444+Datasheet Google]
|-
| PCF8591
| 2,50
| 8-Bit DAC, 8-Bit ADC mit seriellem TWI-Businterface.
| Z.B. in Regelkreisen wo sowohl ein DAC, als auch ein ADC benötigt wird.
| R
| [http://www.google.de/search?q=PFC8591+Datasheet Google]
|-
| TDA8702
| 2,50
| 8-Bit Video DAC mit parallelem Businterface und Clock-Eingang.
| Schnelle Wandlung bis 30 MHz. Benötigt viele µC Pins.
| R
| [http://www.google.de/search?q=TDA8702+Datasheet Google]
|-
| LTC1661
| 3,70
| Dual 10-bit DAC mit seriellem 3-Leitungs-Businterface.
| Guter Kompromiss aus Preis und Leistung.
| F, C (Suchfunktion weigert sich manchmal ihn im Conrad-Shop zu finden), R
| [http://www.google.de/search?q=LTC1661+Datasheet Google]
|-
| LTC1257
| 8,-
| 12-bit DAC mit kaskadierbarem seriellen 3-Leitungs-Businterface.
| Genauer µC-steuerbarer DAC.
| C, F, R
| [http://www.google.de/search?q=LTC1257+Datasheet Google]
|-
| LTC1456
| 10,-
| 12-bit DAC mit kaskadierbarem seriellen 3-Leitungs-Businterface.
| Genauer µC-steuerbarer DAC.
| C
| [http://www.google.de/search?q=LTC1456+Datasheet Google]
|-
|}

== Sensoren (aktiv) ==
=== [[Temperatursensor|Temperatur]] ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| LM75
| 1,75
| Temperatursensor mit I²C (TWI) Bus Interface (3.3V und 5V Version) (SMD)
|
| D, R
| [http://www.datasheetarchive.com/search.php?q=LM75 PDF]
|-
| DS1621
| ~5
| Temperatursensor mit I²C (TWI) Bus Interface (wie LM75, kein SMD)
|
| C, D
|
|-
| DS18B20
| 2,95
| Temperatursensor mit 1-Wire Interface
|
| D, R
| [http://www.datasheetarchive.com/search.php?q=DS18B20 PDF]
|-
| LM35
| 1,19
| Analoger Temperatursensor
| 10mV/°C absolut
| D
| [http://www.datasheetarchive.com/search.php?q=LM35 PDF]
|-
| LM335
| 0,87
| Analoger Temperatursensor
| 10mV/K absolut
| R
| [http://www.datasheetarchive.com/search.php?q=LM335 PDF]
|-
|}
Wenn man z.B. einen Übertemperaturschutz (oder eine andere Schaltung, bei der es nur eine Schaltschwelle gibt) bauen will, dann empfiehlt sich die Verwendung eines NTCs. Dessen Kennlinie ist gegenüber den Kennlinien von z.B. LM335 dahingehend im Vorteil, dass eine geringe Temperaturänderung besser messbar ist.

= Passive Bauelemente =
== Sensoren (passiv)==
=== Licht ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| BPX 65
| 3,35
| Fotodiode 10µA, 350-1000nm
| schnelle Lichtmessungen (bis MHz Bereich), großer Wellenlängenbereich
| R
| [http://www.ortodoxism.ro/datasheets/infineon/1-bpx65.pdf PDF]
|-
|}

=== [[Temperatursensor|Temperatur]] ===
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| KTY81
| ~0,50
| nichtlinear, bis 150°C
| in μC Schaltungen
| R, D
| [http://www.semiconductors.philips.com/acrobat/datasheets/KTY84_SERIES_5.pdf PDF]
|-
| KTY84
| 0,72
| nichtlinear, bis 300°C
| in μC Schaltungen
| R
| [http://www.datasheetcatalog.org/datasheet2/e/0l2lc3p1dl8e5dgghsfh2oee43py.pdf PDF]
|-
| PT100 / PT1000
| ab 3,00
| lineare Kennlinie
| analoge Messschaltungen
| F C
|
|-
|}

== Widerstände ==
Mit einem Widerstandssortiment, welches die E12-Werte enthält, kann man normalerweise nicht falsch liegen. Denn früher oder später benötigt man jeden Widerstandswert der E12-Reihe einmal.

Für einen Einstieg eignen sich die Sortimente vom Pollin. Auch ein Blick in Ebay kann sich lohnen um ein Einstiegssortiment zu bekommen.

== Kondensatoren ==
{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| 100nF Keramik
| ~0.05
|
| Als sogenannter Abblockkondensator zwischen VCC und GND vor allem bei Digital-ICs zwingend erforderlich, schadet aber auch bei den meisten Analog-ICs nicht.
|
| [http://www.datasheetarchive.com/search.php?q= PDF]
|-
| 100nF Keramik SMD 0603
| ~0.01 (bei 100 Stück)
| SMD 0603
| Als sogenannter Abblockkondensator zwischen VCC und GND vor allem bei Digital-ICs zwingend erforderlich, schadet aber auch bei den meisten Analog-ICs nicht.
| D
| [http://www.google.de/search?num=100&hl=de&q=datasheet+0603+chip-capacitors+filetype%3Apdf&btnG=Suche&meta=lr%3Dlang_de%7Clang_en PDF]
|-
|}

= Mechanische Bauelemente =

== Taster / Schalter ==

== Steckverbinder ==

{| border="1" class="sortable" id="opamps"
|-
! Bezeichnung
! Preis (€)
! Beschreibung
! Anwendungen
! Lieferant
! Datenblatt
|-
| WSL 10G
| 0,07
| Wannenstecker, 10-polig, gerade, Raster 2,54 mm
| Verbindung zwischen zwei Platinen mit Flachbandkabel
| -
| -
|-
| PFL 10
| 0,09
| Pfostenleiste, 10-polig, Schneidklemmtechnik, Raster 2,54 mm
| Verbindung zwischen zwei Platinen mit Flachbandkabel
| -
| -
|-
| -
| 3,55
| Flachbandkabel, 10-polig, 3 Meter, Raster 1,27 mm
| Verbindung zwischen zwei Platinen mit Flachbandkabel
| -
| -
|-
|
| 0,70
| D-Sub 9-polig auf 10-polig Pfostenleiste mit Flachbandkabel
| Anschluss für serielle Schnittstelle am PC
| -
| -
|-
|
| 0,35
| Flachkabel-IC-Sockelverbinder
| Übergang von Leiterplatte auf Steckbrett
| -
| -
|-
|
| 0,40
| Reihenklemme/Anreihklemme (verschieden Typen, für Lochraster: Raster 5.08)
| Anschluss der Spannungsversorung, leistungsstarke Verbraucher
| -
| -
|-
|
| 0,30
| Hohlstecker/DC-Stecker
| siehe englische Wikipedia [http://en.wikipedia.org/wiki/Coaxial_power_connector Coaxial power connector]
| -
| -
|-

|}

= Lieferanten =

'''Lokale Lieferanten: [[Lokale Anbieter]]'''
 
Allgemeine Lieferantenliste: [[Elektronikversender]]
 

{| border="1" class="sortable" id="opamps"
|-
! Kürzel
! Name
! Webseite
! Kommentar
|-
|B
|Bürklin
|[http://www.buerklin.de www.buerklin.de]
|Versand nur Firmen & Studenten, Ladengeschäft in München und Düsseldorf
|-
|C
|Conrad
|[http://www.conrad.de www.conrad.de]
| 
|-
|D
|CSD-Electronics
|[http://www.csd-electronics.de www.csd-electronics.de]
| 
|-
|DK
|Digikey
|[http://de.digikey.com www.de.digikey.com]
|Mindestbestellmenge
|-
|F
|Farnell
|[http://www.farnell.de www.farnell.de]
|Versand nur Firmen & Studenten
|-
|M
|Meilhaus
|[http://www.meilhaus.de www.meilhaus.de]
|Nur gewerbliche Kunden
|-
|P
|Pollin
|[http://www.pollin.de www.pollin.de]
| 
|-
|R
|Reichelt
|[http://www.reichelt.de www.reichelt.de]
|Hohe Mindestbestellmenge für Ausland
|-
|}

[[Category:Bauteile|!]]
[[Category:Grundlagen]]

Diskussion:Leistungsaufnahme von Mikrocontrollern

2008-09-21T13:11:05Z

Matze88: sry, völliger schwachsinn entstanden bei meiner letzten bearbeitung

Diskussion:Leistungsaufnahme von Mikrocontrollern

2008-09-21T13:10:17Z

Matze88: Die Seite wurde neu angelegt: -Stromaufnahme Mega88 3,3V im OFF State beträgt nie und nimmer 300µA. Das sind wesentlich weniger, allerdings habe ich gerade keine Zahl parat. Kontrolle?

-Stromaufnahme Mega88 3,3V im OFF State beträgt nie und nimmer 300µA. Das sind wesentlich weniger, allerdings habe ich gerade keine Zahl parat. Kontrolle?

GPS Mini Navigator

2008-09-15T16:59:15Z

Matze88:

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:

[[Media:GPSMiniNavigatorb0.3.zip| GPS Mini Navigator Version beta 0.3]]

Behobene Fehler:
* Falscher Variablentyp verhinderte ein Anzeigen von Distanzen > 255 Metern
* Dezimalausgabe (genutzt von GPS Länge, Breite, Höhe) wurde direkt wieder überschrieben
* Bugreport 12.09.2008 bezügl. Tastensperre war fehlerhaft; Der Fehler trat durch eine bereits behobene Endlosschleife auf.

Bekannte Fehler:
* Abspeichern falscher Werte als Wegpunkt (siehe b0.2)
* Öffnen der Wegpunktdatei 0xFF (siehe b0.2)

[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]

Behobene Fehler:
* Wiedereinschalten aus dem Standby wurde nicht ausreichend überprüft. (Achtung. Verändertes Timing beim Einschalten, siehe Changelog)
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife.

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.
* Entdeckt 12.09.2008: Nutzt man die "Tastensperre" (Shutdown bei aktiviertem GPS LOG), so treten Fehler bei der Aufzeichnung auf. Dies wird weiter untersucht, wenn ich mehr Zeit habe.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variable Anzahl).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 4 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logger Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1, 16, 128, 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 an ist, sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt relativ zur Bewegungsrichtung
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts (bzw. rückwärts sofern die Option angewählt ist) in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der aktuell annavigierte Punkt weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf springt zum nachfolgenden Wegpunkt.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkt Datei und gibt die Nummer binär aus. Die Wegpunktdatei kann parallel zum GPS Log erstellt & abgespeichert werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 1000 ms muss sie losgelassen und nach weiteren 600 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt. (LED 5 und 6 geben den ungefähren Batteriestatus wieder. 6 ist voll, 5 ist fast leer (max. 30 Minuten GPS verbleibend). Sind beide LEDs aus, so wird das GPS Modul bis zum Aufladen deaktiviert.)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

GPS Mini Navigator

2008-09-15T16:57:57Z

Matze88: /* Menü */

''von Matthias Larisch''

(Achtung: Diesen Artikel habe ich nach Wettbewerbsschluss noch bearbeitet, bitte beachtet beim Bewerten, dass ihr euch die alte Version anschaut. Danke)

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:

[[Media:GPSMiniNavigatorb0.3.zip| GPS Mini Navigator Version beta 0.3]]

Behobene Fehler:
* Falscher Variablentyp verhinderte ein Anzeigen von Distanzen > 255 Metern
* Dezimalausgabe (genutzt von GPS Länge, Breite, Höhe) wurde direkt wieder überschrieben
* Bugreport 12.09.2008 bezügl. Tastensperre war fehlerhaft; Der Fehler trat durch eine bereits behobene Endlosschleife auf.

Bekannte Fehler:
* Abspeichern falscher Werte als Wegpunkt (siehe b0.2)
* Öffnen der Wegpunktdatei 0xFF (siehe b0.2)

[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]

Behobene Fehler:
* Wiedereinschalten aus dem Standby wurde nicht ausreichend überprüft. (Achtung. Verändertes Timing beim Einschalten, siehe Changelog)
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife.

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.
* Entdeckt 12.09.2008: Nutzt man die "Tastensperre" (Shutdown bei aktiviertem GPS LOG), so treten Fehler bei der Aufzeichnung auf. Dies wird weiter untersucht, wenn ich mehr Zeit habe.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variable Anzahl).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 4 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logger Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1, 16, 128, 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 an ist, sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt relativ zur Bewegungsrichtung
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts (bzw. rückwärts sofern die Option angewählt ist) in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der aktuell annavigierte Punkt weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf springt zum nachfolgenden Wegpunkt.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkt Datei und gibt die Nummer binär aus. Die Wegpunktdatei kann parallel zum GPS Log erstellt & abgespeichert werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt. (LED 5 und 6 geben den ungefähren Batteriestatus wieder. 6 ist voll, 5 ist fast leer (max. 30 Minuten GPS verbleibend). Sind beide LEDs aus, so wird das GPS Modul bis zum Aufladen deaktiviert.)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

GPS Mini Navigator

2008-09-15T16:54:55Z

Matze88: Rechtschreibung, verschönerung und ein paar Details

''von Matthias Larisch''

(Achtung: Diesen Artikel habe ich nach Wettbewerbsschluss noch bearbeitet, bitte beachtet beim Bewerten, dass ihr euch die alte Version anschaut. Danke)

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:

[[Media:GPSMiniNavigatorb0.3.zip| GPS Mini Navigator Version beta 0.3]]

Behobene Fehler:
* Falscher Variablentyp verhinderte ein Anzeigen von Distanzen > 255 Metern
* Dezimalausgabe (genutzt von GPS Länge, Breite, Höhe) wurde direkt wieder überschrieben
* Bugreport 12.09.2008 bezügl. Tastensperre war fehlerhaft; Der Fehler trat durch eine bereits behobene Endlosschleife auf.

Bekannte Fehler:
* Abspeichern falscher Werte als Wegpunkt (siehe b0.2)
* Öffnen der Wegpunktdatei 0xFF (siehe b0.2)

[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]

Behobene Fehler:
* Wiedereinschalten aus dem Standby wurde nicht ausreichend überprüft. (Achtung. Verändertes Timing beim Einschalten, siehe Changelog)
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife.

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.
* Entdeckt 12.09.2008: Nutzt man die "Tastensperre" (Shutdown bei aktiviertem GPS LOG), so treten Fehler bei der Aufzeichnung auf. Dies wird weiter untersucht, wenn ich mehr Zeit habe.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variable Anzahl).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 4 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logger Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1, 16, 128, 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 an ist, sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt relativ zur Bewegungsrichtung
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts (bzw. rückwärts sofern die Option angewählt ist) in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der aktuell annavigierte Punkt weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf springt zum nachfolgenden Wegpunkt.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkt Datei und gibt die Nummer binär aus. Die Wegpunktdatei kann parallel zum GPS Log erstellt & abgespeichert werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt

(LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

Datei:GPSMiniNavigatorb0.3.zip

2008-09-15T16:48:37Z

Matze88: GPS Mini Navigator Software Version beta 0.3 für Lizenz und Changelog siehe im Zip-Archiv

GPS Mini Navigator Software Version beta 0.3
für Lizenz und Changelog siehe im Zip-Archiv

GPS Mini Navigator

2008-09-15T16:47:17Z

Matze88: /* Software */ Release b0.3

''von Matthias Larisch''

(Achtung: Diesen Artikel habe ich nach Wettbewerbsschluss noch bearbeitet, bitte beachtet beim Bewerten, dass ihr euch die alte Version anschaut. Danke)

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:

[[Media:GPSMiniNavigatorb0.3.zip| GPS Mini Navigator Version beta 0.3]]

Behobene Fehler:
* Falscher Variablentyp verhinderte ein Anzeigen von Distanzen > 255 Metern
* Dezimalausgabe (genutzt von GPS Länge, Breite, Höhe) wurde direkt wieder überschrieben
* Bugreport 12.09.2008 bezügl. Tastensperre war fehlerhaft; Der Fehler trat durch eine bereits behobene Endlosschleife auf.

Bekannte Fehler:
* Abspeichern falscher Werte als Wegpunkt (siehe b0.2)
* Öffnen der Wegpunktdatei 0xFF (siehe b0.2)

[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]

Behobene Fehler:
* Wiedereinschalten aus dem Standby wurde nicht ausreichend überprüft. (Achtung. Verändertes Timing beim Einschalten, siehe Changelog)
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife.

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.
* Entdeckt 12.09.2008: Nutzt man die "Tastensperre" (Shutdown bei aktiviertem GPS LOG), so treten Fehler bei der Aufzeichnung auf. Dies wird weiter untersucht, wenn ich mehr Zeit habe.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

Interrupt

2008-09-15T10:28:04Z

Matze88: Änderung 31076 von 91.57.253.196 (Diskussion) wurde rückgängig gemacht.

== Einleitung ==

Bei bestimmten Ereignissen in Prozessoren wird ein '''Interrupt''' ausgelöst. Dabei wird das Programm unterbrochen und ein Unterprogramm, die sogenannte '''I'''nterrupt '''S'''ervice '''R'''outine ('''ISR'''), aufgerufen. Wenn dieses beendet ist läuft das Hauptprogramm ganz normal weiter.

Bei [[Mikrocontroller]]n werden Interrupts z.B. ausgelöst wenn:
* sich der an einem bestimmten Eingangs-Pin anliegende Pegel ändert
* eine vorher festgelegte Zeitspanne abgelaufen ist ([[Timer]])
* eine [[Seriell|serielle]] Übertragung abgeschlossen ist
* eine Messung des [[ADC |Analog-Digital-Wandlers]] abgeschlossen ist

== Wichtige Eigenschaften von ISRs ==

ISRs reagieren auf ein bestimmtes Ereignis, welches relativ oft oder selten passiert. Prinzipiell sollte man ISRs möglichst kurz halten und schnell beenden. '''Im Mittel muss die Interruptroutine kürzer sein als die Periodendauer des Ereignises, anderenfalls wird es passieren, dass Interrupts "verschluckt" werden''', d.h. beim UART gehen Daten verloren, beim Timer gehen Zählzyklen verloren, beim AD-Wandler gehen Daten verloren etc. '''Solche verschluckten Interrupts sind bisweilen schwer zu finden, weil es nur sehr wenige in ganz bestimmten Konstellationen sind.''' Wenn dann eine per Timer realisierte Uhr in der Stunde um 1s falsch geht, merkt man das oft nicht. '''Langwierige Berechnungen, Auswertungen, Ausgaben oder gar Warteschleifen haben in ISRs nichts zu suchen.''' Typische C-Funktionen wie printf(), scanf(), längere Ausgaben auf ein [[LCD]] etc. sollte man nicht in ISRs vornehmen. Hier kommt sinnvollerweise eine andere Programmiertechnik zu Einsatz, nämlich die Übergabe von Parametern bzw. Steuersignalen an das Hauptprogramm.

=== Interruptsteuerung ===

Interrupts müssen wie alle anderen Module und Funktionen eines Mikrocontrollers gesteuert werden. Dazu wird auf praktisch allen Mikrocontrollern ein zweistufiges System verwendet.
* Globale Interruptsteuerung über ein CPU-Statusbit: Beim [[AVR]] ist das das I-Bit (Interrupt) im Statusregister (SREG). Dieses Bit wirkt wie ein Hauptschalter und kann global die Ausführung aller Interrupts ein - und ausschalten. Das heisst aber nicht, dass während der Zeit der inaktiven Interrupts diese verloren gehen. Vielmehr wird das jeweilige Interruptbit gesetzt, und wenn die Interrupts wieder freigegeben werden wird der Interrupt ausgeführt. Verloren gehen Interrupts erst dann, wenn die Sperrzeit zu gross ist und währenddessen mehr als ein Interrupt vom selben Typ eintrifft. Siehe [[# Zeitverhalten eines Timerinterrupts]] und [[#Zeitverhalten des UART Empfangsinterrupt]]
* Lokale Interruptsteuerung für jede einzelne Interruptquelle über Maskenbits in mehreren Interruptmaskenregistern. Hier kann jede einzelne Interruptquelle individuell ein- und ausgeschaltet werden.

Dieses System hat eine Reihe von Vorteilen. So können sehr schnell und einfach alle Interrupts kurzzeitig gesperrt werden, wenn beispielsweise [[#Atomarer Datenzugriff | atomare]] Operationen durchgeführt werden sollen, oder besonders zeitkritische Abläufe ausgeführt werden. Danach können alle konfigurierten Interrupts einfach wieder freigeschaltet werden, ohne dass die CPU viele verschiedene Interruptmaskenbits verwalten müsste.

Eine ISR wird demnach nur dann ausgeführt, wenn
* die Interrupts global freigeschaltet sind
* das individuelle Maskenbit gesetzt ist
* der Interrupt eintritt

=== Verschachtelte Interrupts ===

Einige Mikrocontroller, wie z.B. der [[AVR]] kennen nur zwei CPU-Zustände. Normale Programmausführung und Interruptausführung, gesteuert durch das I-Bit der CPU. Die normale Programmausführung kann jederzeit durch Interrupts unterbrochen werden. Die Interruptausführung kann nicht durch neue Interrupts unterbrochen werden. Die ISR wird erst zu Ende bearbeitet, zurück in die normale Programmausführung gesprungen und erst dann werden neue, wartende (engl. pending) Interrupts bearbeitet.

Etwas komplexere Mikrocontroller oder große Prozessoren bieten verschiedene Interruptlevel (Stufen) an . Dabei gilt meist je niedriger die Zahl des Levels, um so höher die Priorität. Ein Interrupt mit höherer Priorität kann einen Interrupt mit niedriger Priorität unterbrechen. Ein Interrupt mit gleicher Priorität wie der gerade bearbeitete Interrupt kann das im allgemeinen nicht. Das nennt man verschachtelte Interrupts (engl. nested interrupts). Klassische Vertreter hierfür sind [[8051]], PowerPC, [[X86]] und Motorola 68000.

Auf dem AVR kann man [[AVR-GCC-Tutorial#Unterbrechbare_Interruptroutinen | verschachtelte Interrupts]] sowohl in Assembler als auch in C nachbilden, allerdings mit einigen Einschränkungen und Tücken. Das ist jedoch Leuten vorbehalten, die schon viel Erfahrung auf diesem Gebiet haben. Zu 99,9% braucht man sie nicht.

=== Zeitverhalten eines Timerinterrupts ===

Ein Timerinterrupt wird im allgemeinen dazu genutzt, in konstanten, periodischen Abständen bestimmte Funktionen aufzurufen. Es ist möglich, dass während eines Timerinterrupts derselbe Interrupt wieder aktiv wird, weil die Routine sehr verzweigt ist und dieses Mal sehr lange dauert.

Wenn zum Beispiel der Timerinterrupt mit einer Periodendauer von 100ms aufgerufen wird, er aber unter bestimmten Umständen 180ms benötigt, dann wird nach 100ms nach Eintritt in die ISR der Interrupt wieder aktiv, das Timer Interrupt Flag wird gesetzt. Da aber gerade ein Interrupt bearbeitet wird, wird er nicht sofort angesprungen, weil währenddessen die Interruptfunktion global gesperrt ist (beim AVR ist das I-Bit in der CPU gelöscht). Der Interrupt wird zu Ende bearbeitet, die CPU springt zurück zum Hauptprogramm. Dabei werden die Interrupts wieder global eingeschaltet. Der zwischenzeitlich eingetroffene und zwischengespeicherte Interrupt wird nun sofort ausgeführt, sodass das Hauptprogramm praktisch gar nicht weiter kommt, bestenfalls einen Maschinenbefehl. Nun sind aber nur noch 20ms bis zum nächsten Timerinterrupt übrig. Wenn dieser nun wieder 180 ms benötigt werden in dieser Zeit aber '''zwei''' Interrupts ausgelöst, nach 20ms und 120ms. Da diese aber nicht gezählt oder andersweitig einzeln gespeichert werden können, geht ein Interrupt verloren. Das ist ein Programmfehler.

=== Zeitverhalten des UART Empfangsinterrupts ===

Ein [[UART]] Interrupt zum Empfang von Daten per [[RS232]] mit 115200 [[Baud]] ist ein recht häufiges Ereignis (1 Zeichen = 10 Bits = 86,8μs). Wenn kontinuierlich Daten empfangen werden, wird nach jeweils 86,8μs ein neuer Interrupt ausgelöst. Dabei wird das empfangene Datenbyte vom UART aus dem Empfangsschiebegregister in einem Puffer kopiert. Während das neue Zeichen Bit für Bit empfangen wird, wird es zunächst im Schieberegister des UART gespeichert. Die Daten im Puffer bleiben davon unberührt. Die CPU muss nun schnell das empfangene Datenbyte aus dem Empfangsbuffer auslesen. Die maximale Verzögerung, die sich die CPU erlauben kann von der Aktivierung des Interrupts bis zum tatsächlichen Auslesen des Datenregisters beträgt ziemlich genau die Übertragungszeit von einem Zeichen. Wenn bis dahin nicht das Zeichen von der CPU ausgelesen wurde, wird es vom UART überschrieben und ein Fehler im Statusregister des UART signalisiert (Overrun, Überlauf des Datenpuffers). Die UARTs in heutigen Mikrocontrollern haben mindestens ein Byte Puffer wie hier beschrieben. Die neueren [[AVR]]s haben sogar effektiv 3 Byte Puffer im UART, praktisch ein kleines [[FIFO]], womit der Datenempfang besser gepuffert werden kann, wenn die CPU gerade mit anderen sehr wichtigen Dingen beschäftigt ist. D.h. kurzzeitig kann sich die CPU erlauben, die Übertragungszeit von bis zu drei Zeichen zu warten, ehe sie die Daten ausliest. Dann müssen sie aber sehr schnell hintereinander gelesen werden. Im Mittel hat die CPU aber nur die Übertragungszeit eines Zeichens zur Verfügung, um es abzuholen.

=== Zusammenfassung ===

Interruptserviceroutinen:
* sollten so kurz wie möglich gehalten werden
* können im Einzelfall nahezu doppelt so lange dauern wie die kürzeste Periodendauer des Ereignisses, ohne dass Interrupts verloren gehen (z.B. Timerinterrupt).
* dürfen im Mittel maximal solange dauern wie die kürzeste Periodendauer des Ereignisses
* dürfen maximal solange dauern, wie die kürzeste Periodendauer des Ereignisses, wenn man auf Nummer sicher gehen will, dass keine Interrupts verschluckt werden
* Die Interruptzeit versteht sich immer abzüglich einer kleinen Reserve für das Anspringen und Verlassen des Interrupt minus Panikreserve

== Beispiele für die praktische Programmierung ==

Die Beispiele sind mit WINAVR 20060421 compiliert und getestet worden. Als Mikrocontroller wird ein AVR vom Typ ATmega32 verwendet. Alle Programme wurden mit Optimierungsstufe -Os compiliert.

=== Steuersignale zwischen ISR und Hauptprogramm ===

In vielen Anwendungen wird ein Timer verwendet, um in regelmässigen Abständen bestimmte Aktionen auszuführen, wie z.B. Tasten abfragen, ADC-auslesen, ein LCD auffrischen etc. Wenn viele Dinge zu erledigen sind, nebenbei aber noch andere Interrupts verwendet werden, dann ist es notwendig die Funktionsaufrufe aus dem Timerinterrupt in die Hauptschleife zu verlagern. Der Interrupt signalisiert über eine Steuervariable (engl. Flag, Flagge), das ein neuer Timerzyklus begonnen hat. Dadurch wird der Timerinterrupt sehr kurz und die langwierigen, aber meist nicht zeitkritischen Funktionen werden als normales Programm ausgeführt. Damit kann die CPU auf andere Interrupts schnell reagieren.

Wichtig ist auf jeden Fall, dass die Steuervariable, welche in der ISR und in der Hauptschleife verwendet wird, mit [http://www.netrino.com/Embedded-Systems/How-To/C-Volatile-Keyword '''volatile'''] deklariert wird. Ausserdem muss sowohl der Lese- als auch Schreibzugriff auf die Steuersignale [[#Atomarer Datenzugriff | '''atomar''']] sein. Auf dem AVR ist das mit 8 Bit Variablen direkt möglich, für grössere Variablen müssen die Interrupts kurzzeitig gesperrt werden.

Das Beispiel ist sehr einfach gehalten um das Prinzip zu veranschaulichen. Ein Timer mit einer Überlaufperiodendauer von ca. 65ms stösst periodisch eine Funktion zum Togglen einer LED an, welche dadurch mit ca. 7 Hz blinkt.

<c>
/*
*******************************************************************************
*
* Timer Interrupt Demo
*
* ATmega32 mit internem 1 MHz Oszillator
*
* LOW Fuse Byte = 0xE1
*
* An PD5 muss eine LED mit 1 kOhm Vorwiderstand angeschlossen werden
*
*******************************************************************************
*/

#define F_CPU 1000000

#include <avr/io.h>
#include <avr/interrupt.h>

// globale Variablen

volatile uint8_t flag;

int main() {

// IO konfigurieren

DDRA = 0xFF;
DDRB = 0xFF;
DDRC = 0xFF;
DDRD = 0xFF;

// Timer2 konfigurieren

TCCR2 = 6; // Vorteiler 256 -> ~65ms Überlaufperiode
TIMSK |= (1<<TOIE2); // Timer Overflow Interrupt freischalten

// Interrupts freigeben

sei();

// Endlose Hauptschleife

while(1) {
if (flag == 1) { // Neuer Timerzyklus ?
flag = 0;

// hier steht jetzt in Normalfall ein grosser Programmblock ;-)
PORTD ^= (1 << PD5); // LED toggeln
}
}
}

// Timer2 overflow Interrupt
// hier wird der Hauptschleife ein neuer Timerinterrupt signalisiert

ISR( TIMER2_OVF_vect ) {
flag = 1;
}
</c>

=== UART mit Interrupts ===

Der UART ist ein oft benutztes Modul eines Mikrocontrollers. Anfänger nutzen ihn meist im sogenannten Polling Betrieb (engl. to poll, abfragen). D.h. wenn ein Zeichen empfangen werden soll, fragt eine Funktion den UART in einer Schleife ununterbrochen ab, ob Daten empfangen wurden. In dieser Zeit macht die CPU nichts anderes! Und wenn lange kein Zeichen eintrifft tut sie sehr lange nichts, sie ist praktisch blockiert! Senden verläuft ähnlich, nur dass hier die CPU vor dem Senden prüft, ob der UART ein neues Byte aufnehmen kann. D.h. während der UART selbsttätig das Zeichen sendet ist die CPU zum Warten verdammt. All diese Nachteile haben nur einen Vorteil. Die Funktionen und Mechanismen zur UART-Nutzung sind sehr einfach, klein und leicht anwendbar.

Will man aber die CPU nicht sinnlos warten lassen, was vor allem bei niedrigeren Baudraten ziemlich lange sein kann, muss man die Interrupts nutzen. Der AVR hat gleich drei davon.

* '''RXC''' (Receive Complete): Ein Zeichen wurde empfangen.
* '''UDRE''' (UART Data Register Empty): Der Zwischenpuffer des Senders ist leer und kann ein neues Zeichen aufnehmen. Dieser Zwischenpuffer ist wichtig, um lückenlos auch bei hohen Baudraten senden zu können.
* '''TXC''' (Transmit Complete): Das aktuelle Zeichen wurde vollständig inclusive Stopbit gesendet und es liegt kein neues Datenbyte im Sendepuffer. Dieser Interrupt ist extrem nützlich für eine Halbduplexkommunikation, z.B. auf einem RS485-[[Bus]]. Hier kann man nach dem vollständigen Senden aller Bytes den Bustranceiver (z.B. MAX485) von Senden auf Empfangen umschalten, um den Bus freizugeben.

Bei Nutzung der Interrupts kann die CPU andere Dinge bearbeiten und muss nur kurz einen Interrupt ausführen, wenn ein Zeichen empfangen oder gesendet wurde.

Die Kommunikation zwischen ISRs und Hauptschleife erfolgt wieder durch Flags und zwei Pufferarrays (uart_rx_buffer und uart_tx_buffer). Es gibt zwei Funktionen, eine zum Senden von Strings, eine zum Empfangen. Das Senden sowie Empfangen kann parallel erfolgen und läuft vollkommen unabhängig vom Hauptprogramm. Die Daten werden in spezielle Puffer kopiert, sodass das Hauptprogramm mit seinen Strings sofort weiterarbeiten kann. Im Beispiel ist die CPU nicht wirklich mit sinnvollen Dingen beschäftigt, zur Demonstration des Prinzips aber ausreichend.

Um das das Programm real zu nutzen braucht man ein Terminalprogramm, z.B. Hyperterminal von Windows. Dort muss nur die richtige Baudrate eingestellt werden (9600 8N1, 9600 Baud, 8 Bits, keine Parität, 1 Stopbit, keine Flusskontrolle). Ausserdem muss man im Menu Datei -> Eigenschaften -> Einstellungen -> ASCII Konfiguration den Punkt "Eingegebene Zeichen lokal ausgeben (lokales Echo)" aktivieren. Nun kann man beliebige Texte eintippen. Mit RETURN wird die Eingabe abgeschlossen und der AVR vermittelt den empfangenen String an das Hauptprogramm. Diese sendet ihn einfach zurück, paralle dazu wird der String gemorst per LED angezeigt. Sollte es Probleme bei der Inbetriebnahme des UART geben, so findet man hier wichtige Hinweise zur [[AVR_Checkliste#UART.2FUSART | Fehlersuche]].

<c>
/*
*******************************************************************************
*
* UART Interrupt Demo
*
* ATmega32 mit 3,6864 MHz Quarz an XTAL1/XTAL2
*
* LOW Fuse Byte = 0xFF
*
* An PD5 muss eine LED mit 1 kOhm Vorwiderstand angeschlossen werden
* An PD0/PD1 ist ein MAX232 angeschlosssen, um Daten vom PC zu empfangen/senden
*
*******************************************************************************
*/

// Systemtakt in Hz, das L am Ende ist wichtig, NICHT UL verwenden!
#define F_CPU 3686400L
// "Morsedauer" für ein Bit in Millisekunden
#define BITZEIT 100

#include <string.h>
#include <avr/io.h>
#include <avr/interrupt.h>
#include <util/delay.h>

// Baudrate, das L am Ende ist wichtig, NICHT UL verwenden!
#define BAUD 9600L

// Berechnungen
// clever runden
#define UBRR_VAL ((F_CPU+BAUD*8)/(BAUD*16)-1)
// Reale Baudrate
#define BAUD_REAL (F_CPU/(16*(UBRR_VAL+1)))
// Fehler in Promille
#define BAUD_ERROR ((BAUD_REAL*1000)/BAUD-1000)

#if ((BAUD_ERROR>10) || (BAUD_ERROR<-10))
#error Systematischer Fehler der Baudrate grösser 1% und damit zu hoch!
#endif

// globale Variablen für den UART

// Puffergrösse in Bytes, RX und TX sind gleich gross
#define uart_buffer_size 32

volatile uint8_t uart_rx_flag=0; // Flag, String komplett empfangen
volatile uint8_t uart_tx_flag=1; // Flag, String komplett gesendet
char uart_rx_buffer[uart_buffer_size]; // Empfangspuffer
char uart_tx_buffer[uart_buffer_size]; // Sendepuffer

// lange, variable Wartezeit, Einheit in Millisekunden
void long_delay(uint16_t ms) {
for (; ms>0; ms--) _delay_ms(1);
}

// einen String senden
// vor Aufruf der Funktion muss man prüfen, ob uart_t_flag==1 ist
// nur dann kann ein neuer String gesendet werden

void put_string(char *daten) {

if (uart_tx_flag==1) {
// String daten ind en Sendepuffer kopieren
strcpy(uart_tx_buffer, daten);
// Flag für 'Senden ist komplett' löschen,
uart_tx_flag = 0;
// UDRE Interrupt einschalten, los gehts
UCSRB |= (1<<UDRIE);
}
}

// einen empfangenen String kopieren
// vor Aufruf der Funktion muss man prüfen, ob uart_rx_flag==1 ist
// anderenfalls ist der RX Buffer noch ungültig

void get_string(char *daten) {

if (uart_rx_flag==1) {
// String kopieren
strcpy(daten, uart_rx_buffer);
// Flag löschen
uart_rx_flag = 0;
}
}

// Ein Byte im RS232 Format auf eine LED ausgeben

void morse(uint8_t data) {
uint8_t i;

// Startbit, immer 0
PORTD &= ~(1 << PD5); // LED aus
long_delay(BITZEIT);

for(i=0; i<8; i++) {
if (data & 0x01) // Prüfe Bit #0
PORTD |= (1 << PD5); // LED an
else
PORTD &= ~(1 << PD5); // LED aus
long_delay(BITZEIT);
data >>= 1; // nächstes Bit auf Bit #0 schieben
}
// Stopbit, immer 1
PORTD |= (1 << PD5); // LED an
long_delay(BITZEIT);
}

// Hauptprogramm

int main (void) {

char stringbuffer[64]; // Allgemeiner Puffer für Strings
uint8_t buffer_full=0; // noch ein Flag, aber nur in der Hauptschleife
char * charpointer; // Hilfszeiger

// IO konfigurieren

DDRA = 0xFF;
DDRB = 0xFF;
DDRC = 0xFF;
DDRD = 0xFF;

// UART konfigurieren

UBRRH = UBRR_VAL >> 8;
UBRRL = UBRR_VAL & 0xFF;
UCSRB = (1<<RXCIE) | (1<<RXEN) | (1<<TXEN);

// Stringpuffer initialisieren

stringbuffer[0] = '\n';
stringbuffer[1] = '\r';

// Interrupts freigeben

sei();

// Endlose Hauptschleife

while(1) {

// "Sinnvolle" CPU Tätigkeit
PORTD &= ~(1<<PD5);
long_delay(300);
PORTD |= (1<<PD5);
long_delay(300);

// Wurde ein kompletter String empfangen
// und der Buffer ist leer?
if (uart_rx_flag==1 && buffer_full==0) {
// ja, dann String lesen,
// die ersten zwei Zeichen
// aber nicht überschreiben
get_string(stringbuffer+2);
buffer_full=1;
}

// Ist letzte Stringsendung abgeschlossen
// und ein neuer String verfügbar?
if (uart_tx_flag==1 && buffer_full==1) {
// Newline + Carrige return anfügen
strcat(stringbuffer, "\n\r");
put_string(stringbuffer); // zurücksenden
buffer_full=0; // Buffer ist wieder verfügbar
// Alle Zeichen per LED morsen
charpointer = stringbuffer;
while(*charpointer) morse(*charpointer++);
}
}
}

// UART RX complete interrupt

// hier werden Daten vom PC empfangen und in einem String zwischengespeichert
// Wird ein Stringterminator empfangen, wird ein Flag gesetzt, welches dem
// Hauptprogramm den kompletten Empfang signalisiert

ISR(USART_RXC_vect) {

static uint8_t uart_rx_cnt; // Zähler für empfangene Zeichen
uint8_t data;

// Daten auslesen, dadurch wird das Interruptflag gelöscht
data = UDR;

// Ist Puffer frei für neue Daten?
if (!uart_rx_flag) {
// ja, ist Ende des Strings (RETURN) erreicht?
if (data=='\r') {
// ja, dann String terminieren
uart_rx_buffer[uart_rx_cnt]=0;
// Flag für 'Empfangspuffer voll' setzen
uart_rx_flag=1;
// Zähler zurücksetzen
uart_rx_cnt=0;
}
else if (uart_rx_cnt<(uart_buffer_size-1)) {
// Daten in Puffer speichern
// aber durch if() Pufferüberlauf vermeiden
uart_rx_buffer[uart_rx_cnt]=data;
uart_rx_cnt++; // Zähler erhöhen
}
}
}

// UART TX data register empty interrupt
// hier werden neue Daten in das UART Senderegister geladen

ISR(USART_UDRE_vect) {
// Zeiger auf Sendepuffer
static char* uart_tx_p = uart_tx_buffer;
uint8_t data;

// zu sendendes Zeichen lesen,
// Zeiger auf Sendepuffer erhöhen
data = *uart_tx_p++;

// Ende des nullterminierten Strings erreicht?
if (data==0 ) {
UCSRB &= ~(1<<UDRIE); // ja, dann UDRE Interrupt ausschalten
uart_tx_p = uart_tx_buffer; // Pointer zurücksetzen
uart_tx_flag = 1; // Flag setzen, Übertragung beeendet
}
else UDR = data; // nein, Daten senden
}
</c>

=== Wie lange dauert meine Interruptroutine ? ===

Diese Frage sollte man beantworten können, zumindest sollte eine Worst Case Abschätzung gemacht werden. Das geht auf zwei Wegen.

* Simulation, dabei muss in einer verzweigten ISR der längste Pfad simuliert werden. Dazu müssen alle beteiligten Variablen auf den ensprechenden Wert gesetzt werden.
* Messung mit dem [[Oszilloskop]], dabei wird zum Beginn der ISR ein Pin auf HIGH gesetzt und am Ende auf LOW. Damit kann man in Echtzeit die Dauer der ISR messen. Die zusätzlichen Taktzyklen zum Aufruf und verlassen der ISR sind konstant und im wesentlichen bekannt. Mit einem modernen Digitaloszilloskop und dem "Infinite Persistence Mode" kann man eine Worst Case Messung vornehmen

Als Hilfmittel zur Fehlersuche kann man auch am Ende der ISR prüfen, ob das jeweilige Interrupt-Request Bit schon wieder gesetzt ist. Wenn ja, dann ist die ISR in den meisten Fällen zu lang. Auch hier kann man einen Ausgang auf HIGH setzen und somit den Fehler anzeigen.

==Interruptfeste Programmierung==

=== Atomarer Datenzugriff ===

Von einem atomaren (engl. atomic) Datenzugriff spricht man, wenn der Zugriff innerhalb einer nicht unterbrechbaren Maschinenanweisung abgearbeitet wird.

Alle Variablen, Steuerregister und I/O-Ports, die sowohl im Hauptprogramm als auch in Interrupts verwendet werden, sind mit viel Sorgfalt zu behandeln.

Beispiel:
<c>
port |= 0x03;
</c>
übersetzt sich auf AVR Prozessoren in
<avrasm>
IN r16,port
ORI r16,0x03
OUT port,r16
</avrasm>
Wenn nun zwischen IN und OUT ein Interrupt auftritt, der beispielsweise Bit 7 verändert, dann geht mit dem OUT-Befehl diese Änderung verloren, da der OUT Befehl den alten Zustand vor dem Interrupt wiederherstellt.

'''Gefährlich ist das insbesondere deshalb, weil der Fall nur selten auftritt und dies Verhalten sehr schlecht reproduzierbar ist.'''

Bei verschiedenen Prozessor-Architekturen tritt das Problem verschieden häufig auf. So übersetzt sich obiger Code bei MSP430 Prozessoren in einen einzelnen Befehl
<pre>
OR #0x03,port
</pre>
und stellt somit kein Problem dar. Im Zweifel hilft nur ein Blick in den erzeugten Assembler-Code. Bei der Übernahme fremden Codes ist dies zu beachten. Was bei i51 kein Problem war, kann bei AVR zu einem Problem werden, unter Umständen sogar abhängig von verwendeten Port sein.

Ein ähnliches Problem entsteht bei Variablen, deren Grösse die Wortbreite der Maschine übersteigt. Bei 8-Bit-Prozessoren wie AVR oder i51 also bereits bei normalen "int" Variablen. Diese Variablen werden zwangsläufig byteweise verarbeitet. Wenn genau dazwischen ein Interrupt erfolgt, wird ein falscher Wert gelesen. Wenn beispielsweise eine Interrupt-Routine einen 16-Bit-Zähler verwendet und von 0x00FF auf 0x0100 hochzählt, dann kann das Hauptprogramm auch schon mal versehentlich die Werte 0x01FF oder 0x0000 lesen.

Dies ist auch ein Grund, weshalb für Programmierung auf derart "niedriger" Ebene Kenntnisse in Prozessorarchitektur und Assembler-Programmierung sehr hilfreich sind.

'''Abhilfe''': Wenn man sich nicht wirklich ganz sicher ist, sollten um kritische Aktivitäten herum jedesmal die Interrupts abgeschaltet werden.

Beispiel ([[AVR-GCC]]):
<c>
cli(); // Interrupts abschalten
port |= 0x03;
sei(); // Interrupts wieder einschalten
</c>

Wenn man ein globales Einschalten der Interrupts mit sei() vermeiden will, kann man die folgende Methode benutzen. Hierbei werden die Interrupts nur eingeschaltet, wenn sie vorher bereits eingeschaltet waren (Hinweis aus der FAQ von avr-libc):

<c>
{
// ...
{
uint8_t sreg; // Lokale Sicherungskopie von SREG
sreg = SREG;
cli();
// hierhin kommt der Code mit atomarem Zugriff
SREG = sreg;
}
// ...
}
</c>

Je nach Prozessor kann man das Problem manchmal auch ohne Abschalten von Interrupts durch geeignete Programmierung lösen. So führt
<c>
port = (port & ~0x0F) | lcd_data;
</c>
immer zum beschriebenen Problem,
<c>
port &= ~0x0F;
port |= lcd_data;
</c>
jedoch nicht, wenn die beiden Zeilen zu jeweils einem Assembler-Befehl übersetzt werden. Was dann aber abhängig von den Optimierungs-Einstellungen des Compilers werden kann. Eine Interrupt-feste Variante für AVR-Prozessoren der neuesten Generation, wie beispielsweise Tiny2313 und Mega88 (alle ab 2004):
<c>
PINx = (PORTx & 0x0F) ^ lcd_data;
</c>

=== Reentrante Funktionen ===

Eine Funktion ist reentrant (wiedereintrittsfest), wenn sie mehrmals gleichzeitig aktiv sein kann, ohne dass sich diese Aufrufe gegenseitig beeinflussen. Betrifft beispielsweise Funktionen, die sowohl im Hauptprogramm als auch in Interrupts aufgerufen werden. Manche C Compiler erfordern eine besondere Kennzeichnung solcher Funktionen. Wenn möglich sollte man es jedoch vermeiden, eine Funktion aus dem Hauptprogramm '''und''' aus einem Interrupt aus aufzurufen. Das ist meist problemlos machbar.

== Siehe auch ==
* [[Timer]]
* [[AVR-Tutorial: Interrupts | AVR-Tutorial - Interrupts in Assembler]]
* [[AVR-GCC-Tutorial#Programmieren_mit_Interrupts | AVR-GCC-Tutorial - Interrupts in C]]
* [[ADC]]
* [http://www.nongnu.org/avr-libc/user-manual/group__util__atomic.html Atomare Operationen im AVR-GCC]

GPS Mini Navigator

2008-09-12T11:13:32Z

Matze88: /* Software */ Bugreport

''von Matthias Larisch''

(Achtung: Diesen Artikel habe ich nach Wettbewerbsschluss noch bearbeitet, bitte beachtet beim Bewerten, dass ihr euch die alte Version anschaut. Danke)

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:

[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]

Behobene Fehler:
* Wiedereinschalten aus dem Standby wurde nicht ausreichend überprüft. (Achtung. Verändertes Timing beim Einschalten, siehe Changelog)
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife.

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.
* Entdeckt 12.09.2008: Nutzt man die "Tastensperre" (Shutdown bei aktiviertem GPS LOG), so treten Fehler bei der Aufzeichnung auf. Dies wird weiter untersucht, wenn ich mehr Zeit habe.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

GPS Mini Navigator

2008-09-09T09:03:19Z

Matze88: /* Software */

''von Matthias Larisch''

(Achtung: Diesen Artikel habe ich nach Wettbewerbsschluss noch bearbeitet, bitte beachtet beim Bewerten, dass ihr euch die alte Version anschaut. Danke)

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:

[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]

Behobene Fehler:
* Wiedereinschalten aus dem Standby wurde nicht ausreichend überprüft. (Achtung. Verändertes Timing beim Einschalten, siehe Changelog)
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife.

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

Datei:GPSMiniNavigatorb0.2.zip

2008-09-09T09:01:21Z

Matze88: GPS Mini Navigator Version b0.2. Lizenz: GPLv2, Changelog liegt bei.

GPS Mini Navigator Version b0.2. Lizenz: GPLv2, Changelog liegt bei.

GPS Mini Navigator

2008-09-08T10:42:15Z

Matze88: /* Software */

''von Matthias Larisch''

(Achtung: Diesen Artikel habe ich nach Wettbewerbsschluss noch bearbeitet, bitte beachtet beim Bewerten, dass ihr euch die alte Version anschaut. Danke)

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:

[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]

Behobene Fehler:
* Wiedereinschalten aus dem Standby wurde nicht ausreichend überprüft.
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife.

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

GPS Mini Navigator

2008-09-08T10:41:48Z

Matze88: /* Software */

''von Matthias Larisch''

(Achtung: Diesen Artikel habe ich nach Wettbewerbsschluss noch bearbeitet, bitte beachtet beim Bewerten, dass ihr euch die alte Version anschaut. Danke)

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:

[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]

Behobene Fehler:
* Wiedereinschalten aus den Standby wurde nicht ausreichend überprüft
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

GPS Mini Navigator

2008-09-08T10:41:10Z

Matze88: Software Update

''von Matthias Larisch''

(Achtung: Diesen Artikel habe ich nach Wettbewerbsschluss noch bearbeitet, bitte beachtet beim Bewerten, dass ihr euch die alte Version anschaut. Danke)

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts:
[[Media:GPSMiniNavigatorb0.2.zip| GPS Mini Navigator Version beta 0.2]]
Behobene Fehler:
* Wiedereinschalten aus den Standby wurde nicht ausreichend überprüft
* Fehler beim Laden der nächsten Waypoint Datei, sofern rückwärts navigieren aktiviert und zuvor die letzte Waypoint Datei geladen war führte zu einer Endlosschleife

Bekannte Fehler:
* Race Condition: Mit einer SEHR geringen Wahrscheinlichkeit wird beim Wegpunkte abspeichern ein völlig falscher Wert gespeichert, falls der GPS Interrupt gerade die Positionsdaten aktualisiert UND dabei gerade eine Wertänderung stattfindet, die nicht nur das letzte Byte betrifft. Die Wahrscheinlichkeit ist so enorm gering (Ich habs noch nicht ausgerechnet, aber sie dürfte weit unter 1:1 Million liegen), dass ein Fix (-> Zugriffssperre) zur Zeit noch nicht lohnt, erstmal sind wichtigere Sachen (z.B. PC Software) dran.
* Nach der letzten Wegpunktdatei wird die Datei 0xFF geöffnet als Schutz vor einer Endlosschleife (falls keine Wegpunktdatei existiert). Weitere Überprüfungen notwendig, sodass wieder bei der ersten Wegpunktdatei begonnen wird.

[[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

GPS Mini Navigator

2008-09-07T15:26:09Z

Matze88: Kategorien erweitert

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts: [[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]
[[Category:GPS|G]]
[[Category:Projekte|G]]

GPS Mini Navigator

2008-08-31T22:26:41Z

Matze88: /* PC Interaktion */ Link angepasst

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts: [[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/ GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]

GPS Mini Navigator

2008-08-31T22:07:39Z

Matze88: /* GPS Zugriff */ Minimale Formatanpassungen

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts: [[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
# Breitendifferenz der Punkte nach Meter umrechnen
# Längendifferenz der Punkte nach Meter umrechnen
# Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
# Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/|GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]

Datei:GpsMiniNavigatorSchaltplan.png

2008-08-31T22:00:28Z

Matze88: hat eine neue Version von „Bild:GpsMiniNavigatorSchaltplan.png“ hochgeladen: Aktualisierter Schaltplan

Schaltplan zur GPS Mini Navigator Platine.

GPS Mini Navigator

2008-08-31T21:58:38Z

Matze88: Letzte Änderungen

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts: [[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei.

''Achtung:'' Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus- und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
a) Breitendifferenz der Punkte nach Meter umrechnen
b) Längendifferenz der Punkte nach Meter umrechnen
c) Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
d) Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

'''
Das Menü ist zur Zeit wie folgt gegliedert'''
* ''0 - allgemeine GPS Funktionen''
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.

* ''1 - GPS Logging Funktionen''
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)

* ''2 - Wegpunkt Funktionen''
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei (Erneuter Aufruf: Nächste Wegpunkt Datei öffnen)
** 1* - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2* - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
** LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.

* ''3 - Wegpunkte einspeichern''
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei

* ''4 - Allgemeine Optionen''
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.
** (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)

== PC Interaktion ==
Für den PC habe ich bereits einfachste Übertragungsprogramme geschrieben, welche jedoch zur Zeit noch ungetestet und stark aufs Debugging ausgelegt sind. Diese werden erst zu späterer Zeit veröffentlicht.
[[http://www.gpsbabel.org/|GPS Babel]] eignet sich wunderbar, um ausgelesene Daten in ein Google Earth kompatibles Format umzuwandeln, um sich z.B. die GPS Logs anzusehen. Auch können in Google Earth erstellte Pfade so als Waylist für den Mini Navigator umgewandelt werden.

[[Category:Wettbewerb|G]]

GPS Mini Navigator

2008-08-31T21:49:37Z

Matze88: /* GPS Zugriff */ Funktionen erläutert

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts: [[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei. Achtung: Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

Für das Rechnen mit Koordinaten benutze ich hauptsächlich eine Funktion:
<c>
uint32_t calculate_distance (gps_coords *a, gps_coords *b)
{
uint8_t latstate = 0;
uint32_t lat_distance;
if(a->lat > b->lat)
{
latstate = 1;
lat_distance = a->lat - b-> lat;
}
else lat_distance = b->lat - a->lat;
lat_distance = mul32_16u(div32u(lat_distance,100),11112); // * 10^7 * 10^-2 *10^-1= *10^4 meters
lat_distance = div32u(lat_distance, 10000);
uint16_t distance_cache = lat_distance;
lat_distance = mul32_16u(lat_distance, lat_distance); // square of lat_distance

uint8_t lonstate = 0;
uint32_t lon_distance;
if(a->lon > b->lon)
{
lonstate = 1;
lon_distance = a->lon - b->lon;
}
else lon_distance = b->lon - a->lon;
/* square(((lon_diff / 1000) * cos_val * 1113) / 10000) = lon_diff * 111,3 * cos(angle)*/
lon_distance = mul32_16u(div32u(lon_distance, 1000), my_cos(div32u(labs(a->lat),10000000))); //->10^6 // simplification:
//a->lat instead of a->lat+b->lat/2
lon_distance = div32u(mul32_16u(lon_distance, 1113),10000); // ->meters
lon_distance = isqrt32(mul32_16u(lon_distance, lon_distance) + lat_distance);
uint8_t temp_angle = (my_acos(div32u(mul32_16u(distance_cache,100),lon_distance)) * 100) >> 8; // 0-90 deg. angle

if(latstate)
{
if(lonstate) temp_angle +=70;
else temp_angle = 70 - temp_angle;
}
else if(lonstate)
temp_angle = 140 - temp_angle;

return (lon_distance) | ((uint32_t)temp_angle << 16);
}
</c>

In Zusammenarbeit mit einfachsten, auf Tabellen basierenden Kosinus und Umkehrfunktion liefert diese Ergebnisse mit meistens nicht einmal 2 % Abweichung. Der Ablauf:
a) Breitendifferenz der Punkte nach Meter umrechnen
b) Längendifferenz der Punkte nach Meter umrechnen
c) Nach dem Satz des Pythagoras den Abstand der Punkte bestimmen, Länge und Breite stehen dabei für orthogonale Vektoren, somit haben wir ein rechtwinkliges Dreieck
d) Da wir hier gleich alle Seiten berechnet haben, kann einfach der Winkel zwischen Ankathete und Hypothenuse berechnet werden.

Der Winkel muss zum Schluss noch korrigiert werden, jenachdem, in welchem Quadranten (Koordinate a als Ursprung und b als Punkt im 2 dimensionalen Koordinatensystem betrachtet) wir uns befinden.
Diese Funktion liefert für alle Punkte, die nicht mehr als 65535 Meter auseinander liegen korrekte Ergebnisse.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

Das Menü ist zur Zeit wie folgt gegliedert:
* 0 - allgemeine GPS Funktionen
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.
* 1 - GPS Logging Funktionen
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)
* 2 - Wegpunkt Funktionen
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei
Erneuter Aufruf: Nächste Wegpunkt Datei öffnen
** 1 - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2 - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* 3 - Wegpunkte einspeichern
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei
* 4 - Allgemeine Optionen (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.

[[Category:Wettbewerb|G]]

GPS Mini Navigator

2008-08-31T21:40:49Z

Matze88: /* Software */

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, in dem die meiste Arbeit steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts: [[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei. Achtung: Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

Das Menü ist zur Zeit wie folgt gegliedert:
* 0 - allgemeine GPS Funktionen
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.
* 1 - GPS Logging Funktionen
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)
* 2 - Wegpunkt Funktionen
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei
Erneuter Aufruf: Nächste Wegpunkt Datei öffnen
** 1 - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2 - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* 3 - Wegpunkte einspeichern
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei
* 4 - Allgemeine Optionen (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.

[[Category:Wettbewerb|G]]

GPS Mini Navigator

2008-08-31T21:39:23Z

Matze88: /* SD-Karte und Dateisystem */

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, wo die meiste Arbeit drin steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts: [[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);</c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei. Achtung: Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

Das Menü ist zur Zeit wie folgt gegliedert:
* 0 - allgemeine GPS Funktionen
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.
* 1 - GPS Logging Funktionen
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)
* 2 - Wegpunkt Funktionen
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei
Erneuter Aufruf: Nächste Wegpunkt Datei öffnen
** 1 - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2 - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* 3 - Wegpunkte einspeichern
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei
* 4 - Allgemeine Optionen (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.

[[Category:Wettbewerb|G]]

GPS Mini Navigator

2008-08-31T21:38:48Z

Matze88: Vervollständigung

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Auf der Suche nach einem passenden Projekt hat mir eines meiner Hobbies, das Fahrrad fahren, sehr geholfen: Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger für knapp 30 €. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch der Schwerpunkt des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Ephemeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Neben den Standardkomponenten wie Quarz, Blockkondensatoren, Pullups gibt es eine (Mikro-)SD Karte, 8 LEDs, 2 Taster und 2 P-Fets. Die LEDs sind in einer Art Matrix angeschlossen: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Ich habe Osram SMD-LEDs in rot verwendet, welche mit etwa 0,7 mA betrieben werden. Die Lichtausbeute ist allerdings für Sonnenlichtbedingungen zu schwach. Als Taster bieten sich SMD Miniaturhub Taster an, welche günstig zu beziehen und optimal durch Gehäusebohrungen bedienbar sind. P-Kanal Logic-Level Fets gibts mit dem IRF7314 gleich als Doppelpack im SO8 Gehäuse, 20 V, ~5 A bei nur 0,06 Ohm RdsOn @ 3,3 V Vgs. Alle von mir ausgesuchten Komponenten sind preiswert beim großen R zu beziehen.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, sie funktioniert aber. Für alle Drahtbrücken und Verbindungen habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas Dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Aufgrund geringer mechanischer Last im fertigen Gehäuse funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
* ~4 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
* ~70-75 mA GPS Tracking
* ~10 mA Bluetooth Modul an
* ~50 mA Bluetooth Modul verbunden
* ~30 mA Bluetooth Modul ohne Verbindung, nachdem es einmal verbunden war (wohl ein Bug)
* ~35 µA für die komplette Schaltung im Standby (µC Powerdown)
* ~10 µA Transcend Mikro-SD Karte 512 MB, wenn CS auf high
* ~30 mA Mikro-SD Karte schreiben/lesen

== Software ==

Die Software ist der eigentliche Schwerpunkt dieses Projekts, wo die meiste Arbeit drin steckt. Bis heute habe ich etwa 45 Tage, mal mehr mal weniger, insgesamt etwa 200 Stunden mit dem Quelltext oder Informationen dazu gearbeitet.
Die aktuelle Version ist nicht als fertig zu bezeichnen, es wird immer jemanden geben, der tolle Ideen einbringen oder Funktionen verbessern kann. Für mich persönlich ist der jetzige Stand brauchbar und ausreichend, weshalb ich mich an dieser Stelle für eine Veröffentlichung entschieden habe. Der Quelltext ist weder ausführlich überarbeitet noch lange Zeit debuggt worden, hat aber im Alltag bereits ohne auffällige Fehler funktioniert. Sollte dennoch ein Bug auftreten, so fühl dich frei, ihn zu beheben und deine Veränderungen zu veröffentlichen.

Download des kompletten Quelltexts: [[Media:GPSMiniNavigatorb0.1.zip| GPS Mini Navigator Version beta 0.1]]

=== Aufbau ===
Das Programm besteht aus mehreren Einzelkomponenten, welche größtenteils Zentral aus der Hauptschleife gesteuert werden.
Zum Einsatz kommen folgende Komponenten:
* Software Uart von Peter Danneger (suart.c/suart.h)
* Tastenentprellung von Peter Danneger (keys.c)
* Angepasste MMC/SD Library von Ulrich Radig (mmc.c/mmc.h)
* diverse Rechenalgorithmen in Assembler von elm-chan (sqrt32.S)
* ein einfach gestriktes eigenes Dateisystem (filesystem_simple.c)

Außerdem existieren noch folgende Sourcefiles bzw. Module:
* Hauptschleife, Interruptcodes, kleine Funktionen, die kein eigenes Sourcefile haben (egl.c/egl.h)
* GPS Uart Handling (gps_uart.c/gps_uart.h)
* "User Interface" bzw. Menü (ui.c)
* erste Version des Dateisystems auf Clusterbasis. Verworfen aufgrund zu großer Komplexität ohne Nutzen (filesystem.c/filesystem.h)

Zusätzlich ist noch der Bootloader von Peter Danneger zu erwähnen, welcher bei so einem Projekt sehr hilfreich ist. Auf der Platine gibt es wenig Platz für einen ISP Anschluss, sodass die Firmware anderweitig auf den µC gespielt werden muss. Der Bootloader benötigt nur 512 Byte und bringt ein Software Uart mit. Das Bluetooth-Modul eignet sich somit auch für Firmware Updates, das Beschreiben des kompletten Flashs dauert bei mir 3,78 Sekunden.

Im folgenden werde ich auf die einzelnen Module und das Programm als ganzes näher eingehen.

=== SD-Karte und Dateisystem ===

Ulrich Radigs MMC/SD Library eignet sich für kleine bis mittelgroße Mikrocontroller Projekte aufgrund seiner Einfachheit sehr gut. Die Bibliothek unterstützt hauptsächlich das Schreiben und Lesen von ganzen Blöcken, neben dem Lesen von CID und CSD Register. Ich habe dabei die Block-Lese Funktion erweitert, sodass man auch Teile von Blöcken lesen kann. Dabei wird der Takt zur SD-Karte während einem Block Read einfach angehalten und an späterer Stelle fortgesetzt. Dies ist auf einem System mit 1 kByte Ram sehr praktisch, da man Lesevorgänge nicht zwischenspeichern muss. Der Nachteil ist allerdings, dass die SD-Karte und der SPI Bus bis zum Abschluss des Lesevorgangs blockiert sind.

Dafür ergeben sich dann folgende Funktionen:
<c>void mmc_read_sector_start (uint32_t addr);</c>
Initialisiert den Lesevorgang ab Sektor addr.

<c>uint8_t mmc_read_sector_continue(uint8_t *Buffer, uint16_t count);</c>
Liest (count) Bytes in den übergebenen Puffer.

<c>void mmc_read_sector_finish(uint8_t *Buffer, uint8_t discard_bytes);</c>
Schließt den Lesevorgang ab, wobei man die restlichen Bytes entweder in den übergebenen Puffer speichern oder aber verwerfen (discard_bytes = 1) kann.

Das Dateisystem ist möglichst einfach gestrikt und baut auf Sektoradressierung auf. Dabei gibt es maximal 256 Dateieinträge, jede Datei kann beliebig lang sein. Es unterstützt das Anlegen & Schreiben in neue Dateien, das Öffnen & Lesen bestehender Dateien, das Löschen von Dateien und das Leeren des gesamten Speichermediums. Löschen (großer Dateien) und Formatieren dauert aufgrund des sektorbasierenden Aufbaus sehr lange. Ein für dieses Projekt wichtiges Feature ist die Möglichkeit, zwei Dateien parallel zu beschreiben.

Der Aufbau aller Sektoren ist wie folgt:
Byte 0: Dateityp. Bisher implementiert: 0 - FT_NONE, 1 - FT_LOG (GPS Aufzeichnung, 2 - FT_WAY (Liste von Wegpunkten zur Navigation)

Byte 1 - 507: Nutzdaten

Byte 508 - 511: Adresse des nächsten Sektors.

Dabei werden lediglich die ersten 256 Sektoren als Dateitabelle angesehen, obwohl eine Datei theoretisch an jeder Stelle des Datenträgers anfangen könnte.

<c>uint8_t create_file (uint8_t filetype);</c>
Erstellt eine Datei des angegebenen Typs. Rückgabewert ist die Dateinummer

<c>uint8_t write_file (uint8_t *Buffer, uint8_t count);<c>
Schreibt in die zuvor mit create_file angelegte Datei, dabei maximal 255 Bytes am Stück. Rückgabewerte können Fehlermeldungen (->filesystem_simple.h) sein.
Zum Schreiben wird ein 512 Byte großer Puffer benutzt, welcher beim Eintreffen des 508. Nutzdatenbytes auf die SD-Karte geschrieben wird.

<c>uint8_t close_write_file ();</c>
Füllt den Rest des Sektors mit Nullen auf und beendet den Schreibvorgang auf die Datei. Achtung: Die genaue Länge der Nutzdaten kann später nicht festgestellt werden, sie ist für dieses Projekt auch uninteressant. Die Restbytes bis zur nächsten Sektorgrenze sind immer 0, eine ungültige Adresse zum nächsten Sektor wird als End of File interpretiert.

<c>uint8_t open_file (uint8_t filenumber);</c>
Öffnet die angegebene Datei und gibt den Dateityp zurück. Diese Funktion lässt die SD-Übertragung offen.

<c>uint8_t read_file (uint8_t *Buffer, uint16_t bytes);</c>
Liest (bytes) Bytes aus der geöffneten Datei in den Puffer. Auch hier bleibt die SD-Übertragung offen.

<c>void close_read_file ();</c>
Diese Funktion beendet den aktuellen Lesevorgang und beendet den SD-Zugriff.

<c>void swap_write_files ();</c>
Diese Funktion sichert alle für den Schreibzugriff nötigen Variablen und schreibt den nicht vollständig gefüllten Schreibpuffer temporär auf die SD Karte. Danach wird ein vorher gesichertes Set von Variablen geladen und der Puffer von der SD Karte gelesen. Somit kann man zwei Dateien gleichzeitig zum Schreiben geöffnet haben und abwechselnd beschreiben.

=== GPS Zugriff ===

Das GPS-Modul wird nach dem einschalten mit
<c>void gps_enable(uint8_t enable_interrupt);</c>
in den Sirf Modus initialisiert und je nach Parameter der USART RX Interrupt aktiviert. Alle Daten vom GPS-Modul werden dann im Interrupt ausgewertet und entsprechend in eine Struktur geschrieben:
<c>typedef struct
{
union
{
struct
{
int32_t lat;
int32_t lon;
int32_t alt;
};
uint8_t coords[12];
};
union
{
uint32_t dword;
struct
{
unsigned second:6;
unsigned minute:6;
unsigned hour:5;
unsigned day:5;
unsigned month:4;
unsigned year:6;
} s;
} date;
uint16_t sog; // bit 0-2 is nav type
uint8_t sv;
uint8_t hdop; // bit 7 is trickle power indicator (not used in current version)
} gps_log_entry_t;</c>

Es werden also Länge, Breite, Höhe, das aktuelle Datum, die Geschwindigkeit, die Anzahl der Satelliten, der Typ des Sat-Fixes (3D, 2D, etc.) und der HDOP geloggt. Außerdem wird der aktuelle Kurs in eine globale Variable geschrieben, sodass dieser im Programm zur Verfügung steht.

=== LED und Tastenhandling ===

Über einen Timer werden alle 2 ms die Tasten abgefragt und nach der Entprellroutine von Peter Danneger bearbeitet. Außerdem werden die LEDs gemäß der globalen Variable
<c>volatile uint8_t led;</c>
gesetzt. Zusätzlich findet im Timerinterrupt noch eine Überprüfung statt, ob das Bluetooth-Modul aktiviert ist, indem der RX Pin vom Software Uart auf High-Pegel geprüft wird. Ist das Modul aktiviert, so wird auch das Software Uart aktiviert.

=== Software Uart Handling ===

In der Hauptschleife wird überprüft, ob das Software Uart aktiviert ist. Ist dies der Fall, so wird die Empfangsfunktion aufgerufen, welche für die Kommunikation mit dem PC zuständig ist. Das Protokoll sieht vor, dass alle eingehenden Bytes als Kommando interpretiert werden, bis ein gültiges Kommando empfangen wurde. Per switch Anweisung wird dann für jedes Kommando eigenständig Code ausgeführt. Die wichtigsten Funktionen dienen zum Lesen und Schreiben aus dem Dateisystem:

SUART_CREATE_FILE gibt nach Aufruf direkt ein SUART_SUCCESS zurück und erwartet daraufhin den Dateitypen. Nach Ausgabe der Dateinummer folgt ein SUART_COMPLETED.

SUART_WRITE_FILE gibt SUART_SUCCESS zurück, erwartet in 2 Bytes (Low Byte zuerst) die zu schreibende Dateilänge und interpretiert alle Folgedaten als Datenbytes, bis der Bytezähler auf 0 ist. Da der SD Kartenzugriff hier länger dauern kann, muss der PC alle (n*507)+1 Bytes warten, bis ein SUART_NEXT_SECTOR empfangen wird. Zusätzlich muss an dieser Stelle der Timer Interrupt deaktiviert werden, da sonst die 8 MHz des AVRs nicht mehr für 38400 bps Software Uart mit durchlaufenden Daten ausreicht.

SUART_READ_FILE öffnet die übergebene Dateinummer, gibt den Dateityp zurück und schreibt dann jeweils 507 Bytes zum PC, bis ein SUART_STOP_COMMAND empfangen wurde oder die Datei zu Ende ist.

SUART_CALL_BOOTLOADER stellt eine Sonderfunktion dar, welche auf die Erkennungsbytes von Peter Dannegers Bootloader reagiert und dann den Mikrocontroller per Watchdog reseted. Dies ermöglicht ein ganz einfaches Programmieren mit der zugehörigen Software direkt aus der laufenden Applikation.

=== Menü ===

Die Menüsteuerung ist sehr umfangreich, aber dennoch so einfach wie möglich gehalten. 8 LEDs und 2 Taster bieten nicht sehr viele Möglichkeiten.
Grundsätzlich sieht die Struktur wie folgt aus:
Es gibt Obermenüs (0-4) und Untermenüs (variabel, bis zu 5).
Die Tasten links und rechts kurz gedrückt schalten jeweils einen Menüpunkt/Untermenüpunkt weiter oder zurück.
Drückt man lange links, so wird ein Menüpunkt aufgerufen, also ein Untermenü betreten oder eine Aktion ausgeführt.
Lange rechts hingegen geht grundsätzlich zurück in das Wurzelmenü.

Die LEDs 0 und 1 zeigen dabei die Menünummer an (Menü 5 wird ebenso wie 0 als 0 angezeigt, was aber aufgrund der Steuerung in beide Richtungen dennoch kein Problem darstellt), LEDs 2-4 die Untermenünummer. Leider muss sich der Anwender hier minimal mit Binärcode rumschlagen, aber für uns ist das kein Problem :-).

Die LEDs 5-7 können je nach Menüpunkt Zusatzinformationen anzeigen. Außerdem blenden einige Untermenüs die Menüanzeige aus und nutzen alle 8 LEDs für ihre eigene Anzeige. Dies passiert aber erst nach einmaligem Aufruf, erst ein zweiter Aufruf durch Taste links lang führt dann die jeweilige Aktion aus.

Das Menü ist zur Zeit wie folgt gegliedert:
* 0 - allgemeine GPS Funktionen
** 0 - Ausgabe der Breite als 7 stellige Dezimalzahl, jede Stelle wird dabei einzeln für eine Sekunde angezeigt, Nullen werden als LED 7 0 1 dargestellt, die 9 wird als LED 7 und LED 6 dargestellt.
** 1 - Ausgabe der Länge als 7 stellige Dezimalzahl
** 2 - Ausgabe der Höhe als 7 stellige Dezimalzahl
** 3 - Ausgabe der Geschwindigkeit, binär in km / h
** 4 - Ausgabe des aktuellen Kurses, LED 0 ist dabei Nord.
* 1 - GPS Logging Funktionen
** 0 - GPS Log starten und stoppen
** 1 - Einstellen eines GPS Log Intervals in Sekunden (1 16 128 1024)
** 2 - Einstellen eines GPS Log Intervals in Metern (Aus, 50, 400, 2000)
* 2 - Wegpunkt Funktionen
** 0 - Erster Aufruf: Anzeige aktuell geöffneter Wegpunkt Datei
Erneuter Aufruf: Nächste Wegpunkt Datei öffnen
** 1 - Erster Aufruf: Anzeige der Entfernung zum Wegpunkt in 16 Meter Schritten binär, falls LED 7 = 1 sind es 2048 Meter Schritte.
** 2 - Erster Aufruf: Anzeige des Kurses zum Wegpunkt. LED 0 ist dabei die Bewegungsrichtung.
Für 1 und 2 gilt: Erneuter Aufruf navigiert den nachfolgenden Wegpunkt an.
** 3 - Sucht automatisch den nächsten Wegpunkt aus der Wegpunktdatei. Sucht dabei nur vorwärts in der Datei, sodass alle bereits zurückgelegten Wegpunkte nicht mit einbezogen werden.
** 4 - Optionen: Aufruf erhöht Optionen um 1. LED 6 (Bit 0) steht für automatisches Weiterspringen zum nächsten Wegpunkt, sofern der jetzige weniger als 20 Meter der aktuellen Position entfernt ist.
LED 7 (Bit 1) aktiviert bedeutet, dass alle Wegpunkte in umgekehrter Reihenfolge annavigiert werden.
* 3 - Wegpunkte einspeichern
** 0 - Erstellt eine neue Wegpunkte Datei und gibt die Nummer binär aus. Diese Schreibzugriffe können parallel zum GPS Log durchgeführt werden!
** 1 - Speichert den aktuellen Punkt als Wegpunkt ab
** 2 - Beendet die Wegpunkte Datei
* 4 - Allgemeine Optionen (LED 5 und 6 geben den Batteriestatus wieder. 6 ist voll, 5 ist fast leer und garnichts steht für leer)
** 0 - Ausschalten / Standby. Zum Wiedereinschalten die rechte Taste anklicken, nach rund 700 ms muss sie losgelassen und nach weiteren 400 ms müssen beide Tasten gedrückt sein.
** 1 - GPS Modul ein und Ausschalten. Der Status wird auf LED 7 dargestellt.

[[Category:Wettbewerb|G]]

GPS Mini Navigator

2008-08-31T20:33:13Z

Matze88: Teil Software, allgemein

Datei:GPSMiniNavigatorb0.1.zip

2008-08-31T20:27:39Z

Matze88: Quellcode mit Hex-File für Mega88 des GPS Mini Navigators von Matthias Larisch. Der Code unterliegt der GPL v2 oder höher.

Quellcode mit Hex-File für Mega88 des GPS Mini Navigators von Matthias Larisch. Der Code unterliegt der GPL v2 oder höher.

GPS Mini Navigator

2008-08-31T20:15:46Z

Matze88: Korrektur des ersten Teils

GPS Mini Navigator

2008-08-27T23:59:08Z

Matze88: Änderung 30579 von 85.182.121.200 (Diskussion) wurde rückgängig gemacht.

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Mit ein Hauptauslöser für dieses Projekt ist dann außerdem meine Leidenschaft zum Fahrrad fahren. Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger, der hat knapp 30 € gekostet. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch das Hauptmerkmal des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Epiphmeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nur noch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.

=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Zusätzlich zur Grundbeschaltung wird an das Hardware SPI Interface eine SD-Karte angeschlossen. Außerdem hängt an Port C eine Art LED Matrix: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, ich habe die Platine versehentlich einige Minuten nach dem Entwickeln nochmal in den Entwickler gelegt. Zum Verbinden habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie einfach nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Da die mechanische Last im fertigen Gehäuse sehr gering ist, funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
-3,5 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
-~70-75 mA GPS Tracking
-~30 mA Bluetooth Modul an
-~60 mA Bluetooth Modul verbunden

=== Software ===
[[Category:Wettbewerb|G]]

GPS Mini Navigator

2008-08-27T23:38:47Z

Matze88: Kategorie falsch

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Mit ein Hauptauslöser für dieses Projekt ist dann außerdem meine Leidenschaft zum Fahrrad fahren. Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger, der hat knapp 30 € gekostet. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch das Hauptmerkmal des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Epiphmeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nurnoch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.
=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Zusätzlich zur Grundbeschaltung wird an das Hardware SPI Interface eine SD-Karte angeschlossen. Außerdem hängt an Port C eine Art LED Matrix: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, ich habe die Platine versehentlich einige Minuten nach dem Entwickeln nochmal in den Entwickler gelegt. Zum Verbinden habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie einfach nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Da die mechanische Last im fertigen Gehäuse sehr gering ist, funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
-3,5 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
-~70-75 mA GPS Tracking
-~30 mA Bluetooth Modul an
-~60 mA Bluetooth Modul verbunden

=== Software ===
[[Category:Wettbewerb|G]]

GPS Mini Navigator

2008-08-27T16:06:34Z

Matze88:

''von Matthias Larisch''

== Einleitung ==

Seit einiger Zeit schwirrte mir im Kopf die Idee herum, einen GPS Empfänger zum Basteln zu kaufen. Mit ein Hauptauslöser für dieses Projekt ist dann außerdem meine Leidenschaft zum Fahrrad fahren. Ich habe mir häufig bei Google Earth Strecken angeschaut, die ich dann nachfahren wollte. Wie toll wäre es, einen Richtungsweiser auf dem Fahrrad dabei zu haben, um nicht immer auf der ausgedruckten Karte nachzuschauen, wo es weitergeht? Das Projekt sollte beginnen!

Zuerst kaufte ich mir bei Ebay einen SysOnChip Smart Blue GPS Bluetooth Empfänger, der hat knapp 30 € gekostet. Der Vorteil ist hierbei, dass ein GPS Empfänger, ein Bluetooth Modul und ein Akku in einem schönen kleinen Gehäuse zusammengefasst sind.

Danach begann ich mit der Entwicklung einer kleinen Schaltung für einen Mega88, welche 8 LEDs, 2 Taster, 2 Fets zum Steuern von Peripherie, den Quarz sowie ein paar Widerstände/Kondensatoren enthält.

Die Schaltung war schnell geätzt und die Platine in Form gesägt, langwierig wurde es dann, sie in das Originalgehäuse vom Bluetooth GPS zu integrieren.

Damit war der Grundstein für die Softwareentwicklung gelegt, auf welcher auch das Hauptmerkmal des Projektes liegt.

== Hardware ==
=== GPS/Bluetooth Modul ===
Mein Modul ist ein SysOnChip Smart Blue, welches ein Samsung SIRF III GPS-Modul und ein Samsung BTPZ5002OA Bluetooth-Modul enthält. Der Lithium Ionen Akku mit 1100 mAh ist ein Standard Modell, der EL-EN5.
Am Innenaufbau erkennt man schnell, dass eine Erweiterung sehr einfach von statten geht:

[[Bild:SysOnChipSmartBluePlatineoben.jpg‎|300px]]

Links das GPS-Modul, oben gehen die Uart RX/TX Pins ab zum Bluetooth-Modul. Die untere Verbindung ist ein GPS Signalindikator. Ganz unten ist die 5 V Versorgungsbuchse, mit der der Akku geladen werden kann. Dadrüber befindet sich der Ladecontroller, links vom Ladecontroller ein 3,3 V Low-Drop Regler, welcher im Standby nur rund 20 µA Strom aufnimmt. Der Schalter oben trennt die komplette Schaltung hinter dem 3,3 V Regler.

Um eine Schaltung auf diese Platine aufzubauen, können die Uart-Leitungen durchtrennt werden. Die Baudrate beträgt sowohl für das GPS-Modul als auch für das Bluetooth Modul unveränderbar 38400 bps, ohne Parität und mindestens 1 Stoppbit.

Das GPS-Modul wird über 2 Quellen mit Strom versorgt: Einmal erkennt man im Bild links einen größeren Kondensator, rechts daneben und ein Stück nach unten ist eine Leiterbahn zur Durchkontaktierung zum 3,3 V Layer, welche durchtrennt werden kann.

Außerdem wird das Modul jedoch noch anderweitig mit 3,3 V versorgt, um Almanach & Epiphmeriden Daten auch nach Ausschalten der Hauptversorgung zu behalten. Das geschieht über den Pin, an dem der Kondensator DC2 nach Masse führt.
Anmerkung: Ich habe diesen Kondensator bei weiteren Arbeiten abgerissen, das GPS Modul macht nach längeren Standby Phasen nun Probleme beim Einschalten, welche eventuell auf eine unsaubere Standby Versorgung zurückzuführen sind. Dies wird weiter untersucht.

Auf der Rückseite der Platine ist nurnoch die GPS-Antenne verbaut, die über das abgeschirmte Kabel, welches man oben neben der Bluetooth-Antenne sehen kann, mit dem GPS-Modul verbunden ist.
=== µC Platine ===
[[Bild:GpsMiniNavigatorSchaltplan.png|300px]]

Das Herzstück der Schaltung ist ein AT Mega88. Ich empfehle für den Nachbau allerdings eine Version mit mehr Flash und eventuell sogar 2 Uarts zu verwenden.

Zusätzlich zur Grundbeschaltung wird an das Hardware SPI Interface eine SD-Karte angeschlossen. Außerdem hängt an Port C eine Art LED Matrix: Alle LEDs haben einen gemeinsamen Pin (PC1), welcher bei 4 LEDs an der Anode und bei den anderen 4 an der Kathode hängt. Jeweils 2 LEDs kommen dann zusammen an einen weiteren Pin des Controllers, sodass eine LED bei PC1 Low und z.B. PC0 High und die andere bei PC1 High und PC0 Low leuchtet. Somit kann man mit 5 Pins 8 LEDs anschließen und hat dabei einen vertretbaren Softwareaufwand bei relativ geringem Layoutaufwand. Der Grund für die Verwendung dieser Methode war bei mir auch der Platzmangel, welcher es mir nicht ermöglicht, mehr als 3 Leiterbahnen zu den LEDs auf der Unterseite des Controllerboards zu führen (siehe unten).

Durch 2 P-Kanal Mosfets kann die SD Karte und das GPS-Modul vom Strom getrennt werden.

Das GPS-Modul wird mit dem Hardware-Uart des µCs verbunden, da dies hauptsächlich benutzt wird, wohingegen für das Bluetooth-Modul ein Software-Uart ausreichen muss.

=== Verbindung beider Platinen ===

[[Bild:GpsMiniNavigatorPlatinenUnten.jpg|300px]] [[Bild:GpsMiniNavigatorPlatinenOben.jpg|300px]]

Die Zusatzplatine habe ich so zugeschnitten, dass man sie einfach auf die Oberseite, also die Seite mit der GPS Antenne, aufsetzen kann. Hier wird nun auch klar, warum ich sehr platzsparend arbeiten musste. Leider ist meine selbstgeätzte Platine nicht besonders gut geworden, ich habe die Platine versehentlich einige Minuten nach dem Entwickeln nochmal in den Entwickler gelegt. Zum Verbinden habe ich 0,3 mm Kupferlackdraht verwendet, empfehlen würde ich etwas dünneren, z.B. 0,2 mm. Es ist außerdem nicht ratsam, Drähte direkt an die Pins vom TQFP Mega anzulöten, dort halten sie einfach nicht so gut wie auf einem Lötpad. Da ich keine Lust habe, die Platine noch einmal neu zu layouten, zu sägen und zu löten bleibt das allerdings bei meinem Aufbau so. Da die mechanische Last im fertigen Gehäuse sehr gering ist, funktioniert das bisher auch fehlerfrei.

Die Mikro-SD Karte findet auf der anderen Seite der Platine ihren Platz. Der 100 nF Kondensator zwischen Vcc und GND sollte so dicht wie möglich an der Karte platziert werden. Die Uart Leitungen der Originalplatine habe ich durchtrennt und je 2 Drähte direkt am GPS- und am Bluetooth-Modul angeschlossen. Das GPS-Modul wird vom Dual-Fet versorgt, meine Schaltung bekommt ihren Strom direkt vom Ausgang des 3,3 V Reglers, deshalb ist die Implementierung eines Zustands mit extrem niedriger Stromaufnahme wichtig. Der Originalschalter auf der Platine schaltet in diesem Zustand nur noch das Bluetooth Modul Ein und Aus.

Die Stromaufnahme der einzelnen Module beträgt im Übrigen:
-3,5 mA AT Mega 88, aktiv, 8 MHz, PRR = 0xFF
-~70-75 mA GPS Tracking
-~30 mA Bluetooth Modul an
-~60 mA Bluetooth Modul verbunden

=== Software ===
[[Category:Wettbewerb|P]]

Datei:GpsMiniNavigatorPlatinenOben.jpg

2008-08-27T15:55:49Z

Matze88: GPS Mini Navigator auf SysOnChip Smart Blue Platinenoberseite

GPS Mini Navigator auf SysOnChip Smart Blue Platinenoberseite

Datei:GpsMiniNavigatorPlatinenUnten.jpg

2008-08-27T15:54:56Z

Matze88: GPS Mini Navigator auf SysOnChip Smart Blue Unterseite

GPS Mini Navigator auf SysOnChip Smart Blue Unterseite