Becker active. mit SD-Karte erweitern

Es ist nun schon mehrfach vorgekommen, das durch Kartenaktualisierung der Speicher des Gerätes nicht mehr ausreicht. Dann fehlt einfach die Hälfte und die Navigation geht nicht mehr richtig. Der Content Manager bleibt mit einer entsprechenden Fehlermeldung stehen und das war´s. Danach bleibt eigentlich nur das Zurücksetzen in den alten Zustand. Der Speicher der SD-Karte kann nicht genutzt werden. Eigentlich sollte das ja zur Speichererweiterung dienen. Nach langen Suchen habe ich die Abhilfe für dieses Problem gefunden. Auf der SD-Karte müssen entsprechende Verzeichnisse vorhanden sein, damit die ganze Sache funktioniert. Leider schweigt sich die Dokumentation darüber aus.

Damit die Nutzung der SD-Karte erfolgen kann müssen folgende Verzeichnisstruktur im Hauptverzeichnis der Karte vorhanden sein:

addons
   -> CONTENT
         -> building
         -> lang
         -> map
         -> phoneme
         -> poi
         -> speedcam
         -> voice
   -> license
   -> tts_nua_v5
         -> CZC
         -> DUN
         -> ENG
         -> FRF
         -> HUH
         -> ITI
         -> PLP
         -> SPE





Danach verschiebt man die einzelnen nicht immer benutzten Teile der Kartendaten vom Gerät auf die entsprechenden Verzeichnisse der Karte. Ab sofort wird beim Update die SD-Karte mit aktualisiert und der Gerätespeicher hat weiterhin seine Reserven.

Basteln mit ATmegas

Da meine bessere Hälfte ihre ursprüngliche Heimat etliche Kilometer entfernt hat und ab und zu ein wenig Heimweh hat, haben wir einfach ein Stück alte Heimat in der Schrankwand untergebracht.
Dieses war die erste Version:

Der Leuchtturm ist an den der Greifswalder Oie angelehnt, allerdings entspricht das Feuer nicht diesem nur die Drehrichtung. Des "Feuer" wird von einen Atmega8 mit 1Mhz Takt auf 16 Leuchtdioden verteilt. Da alles über Pulsweitenmodulation gesteuert wird, kam bei der ersten Version Assembler zum Einsatz.

Version 1 Leuchtturmelektronik

der mechanische Unterbau simuliert Schiffsbewegungen 

(hier noch die alte rasselnde Getriebeversion)

Inzwischen ist der Atmega8 einem Arduino ProMini gewichen (bei einem Preis von 7€ lohnt sich Selbstbauen nicht mehr) und das Feuer des Leuchtturms entspricht jetzt annähernd dem Original. Die etwas lauten Getriebe des Schiffsmechanismus wurden durch Schrittmotoren ersetzt. Das Schiff bekam eine entsprechende Beleuchtung und mit einen Neopixelstreifen mit 60 LED´s wird Tag- und Nachtwechsel erzeugt.
Ein ProMini ist für die Beleuchtung zuständig und steuert gleichzeitig die beiden Controller im Leuchtturm und der Schiffsmechanik.

Über Zufallszahlen im Verhältnis 1/20 wird im Nachtzyklus ein Gewittereffekt erzeugt und die Schiffsmechanik erzeugt heftigeren Seegang. Gleichzeitig wird die Beleuchtung des Fischerbotes auf ein normales Motorschiff reduziert.

Raspi-Bastelei

Hier hatte ich mich mal einem WiFi-gesteuertem Fahrzeug gewidmet. Das Teil diente eigentlich nur zur Anregung für ein größeres Projekt und ist aufgrund seiner Robustheit zeitweise heute noch im Einsatz.
In der Zwischenzeit ist selbst meine kleine Version 2 schon veraltet, da sie noch auf einem umherliegenden Raspberry Pi Version B beruht. Da die GPIO des alten Raspi recht bescheiden ist, wurde einfach ein Gertboard aufgesetzt. Somit gibt es für zusätzliche Aufgaben einen Atmega, sowie die Möglichkeit 5V Komponenten einzusetzen, ohne den Raspi in den Schaltkreishimmel zu schicken.
Da das alles nur eine erste Konzeptbastelei ist, spielt Schönheit erstmal keine Rolle. Das ganze ist jetzt schon über ein Jahr im Aufbau, da einfach die Zeit fehlt.

Das Fahrwerk und die Halterungen des Aufbaus stammen aus dem 3D-Drucker, Ketten und Getriebe von Tamia. Als Motorendstufe ist ein L293D auf einer Lochrasterplatte im Grundchassis untergebracht. Als Stromversorgung dient eine USB-Powerbank.

Der Raspi wird über WLan gesteuert und der Kamerastream per Netcat übertragen. Das ergibt eine sehr geringe Verzögerung des Videos.

der Unterschied zwischen SFR und erweiterten SFR

In einem Programm bekam ich ständig Fehlermeldungen beim Compilieren.
Ein Test zeigte dann ein komisches Verhalten in der Timerprogrammierung.

So kann bei einem ATmega328P das Timerregister "TIMSK0" nicht per "OUT" sondern nur über "STS" beschrieben werden.


Beispielcode

/*
 * timertest2.asm
 */ 

.def temp = r16
.def leds = r17

.org 0x0000
        rjmp    main                  ; Reset Handler
.org OVF0addr
        rjmp    timer0_overflow       ; Timer Overflow Handler

main:
        ; Stackpointer initialisieren
        ldi     temp, HIGH(RAMEND)
        out     SPH, temp
        ldi     temp, LOW(RAMEND)     
        out     SPL, temp

        ldi     temp, 0xFF            ; Port D auf Ausgang
        out     DDRD, temp

        ldi     leds, 0xFF

        ldi     temp, (1<<CS00)|(1<<CS02)       ; CS00 und CS02 setzen: Teiler 1024
        out     TCCR0B, temp


        ldi     temp, (1<<TOIE0)      ; TOIE0: Interrupt bei Timer Overflow
        ; out     TIMSK0, temp        ; dieser Befehl bringt eine Fehler (Wert ausser Bereich)
sts TIMSK0, temp              ; STS weil TIMSK0 (0x6E) im erweiterten SFR liegt

        sei

loop:   rjmp    loop

timer0_overflow:                      ; Timer 0 Overflow Handler
        out     PORTD, leds
        com     leds
        reti

Grund des Problems:
Das Register TIMSK0 liegt in den erweiterten SFR (0x60 - 0xFF).
OUT funktioniert nur im normalen SFR (bis 0x5f), danach sind normale SRAM-Befehle nötig.