Aktuellen Entwicklungsstand klonen und Arbeitsumgebung einrichten

(Anmerkung: Nach negativer Erfahrung mit der Submodul-Funktionalität von Git haben wir uns dazu entschlossen, den RIOT-OS-Fork getrennt vom Applikationsrepository zu verwalten.)

Zunächst sollte ein leerer Ordner angelegt werden, der als Arbeitsverzeichnis für das komplette Projekt dient: mkdir arbeitsverzeichnis

Anschließend werden die beiden Repositories geklont:

git clone git@github.com:michz/diy14bus.git
git clone git@github.com:patkan/RIOT.git

Fertig. Wie die Toolchain eingerichtet wird, ist beispielhaft im Artikel ARM-Toolchain - bis es läuft... beschrieben.

Woher weiß unsere Applikation, wo RIOT liegt?

Im Anwendungs-Makefile muss der Pfad zu RIOT angegeben werden.

Beispiel:

    # name of your application
    APPLICATION = first-test-f1

    # If no BOARD is found in the environment, use this default:
    BOARD ?= stm32f0discovery-diy

    ######## THIS IS THE IMPORTANT LINE ########
    # This has to be the absolute path to the RIOT base directory:
    RIOTBASE ?= $(CURDIR)/../../RIOT/

    # Modules required by this application
    USEMODULE += cc110x_spi
    USEMODULE += cc110x_legacy


    # Change this to 0 show compiler invocation lines by default:
    QUIET ?= 1

    include $(RIOTBASE)/Makefile.include

Die Zeile, in der die Variable RIOTBASE definiert wird, stimmt exakt so, wenn die Repositories wie oben auf derselben Verzeichnisebene liegen. Dies ist der Entwicklungsstandard und sollte so eingehalten werden, damit die anderen Entwickler nicht bei jedem Kompilieren das Makefile anpassen müssen.

Umgang mit den Repositories

Beide Repositories (RIOT-OS-Fork mit dem Betriebssystem und das diy14bus-Repository mit den Anwendungen und Projektdateien) sind völlig unabhängig voneinander zu betrachten und zu behandeln.

Welchen Mikrocontroller für die Endhardware

Anmerkung: Diskussionen bitte irgendwo, wo man tatsächlich auch diskutieren kann. (Piratenpad z.B.)

STM32

STM32F030F4P6TR

• Kosten <1€ pro Stück
• Vorteil: Ähnlich zum F3, in den wir uns jetzt schon eingearbeitet haben. (Noch zu checken)

• Auch über JTAG mit USB-PROG programmierbar, dann sparen wir uns den zweiten µC für die Programmierung. So weit muss es aber gar nicht kommen, wir nehmen uns einfach den JTAG von einem st-link vom Eval-Board. UPDATE: Das funktioniert nicht so wie gedacht. Es kann mit dem St-Link nur der ARM des jeweiligen Boards programmiert werden, weil der µC für die Programmierung die Device-ID des montierten ARMs kennt. Beim Programmieren kommt daher folgende Fehlermeldung:

  $ make flash
  st-flash write bin/stm32f3discovery/first-test.hex 0x8000000
  2014-11-26T22:42:10 INFO src/stlink-common.c: Loading device parameters....
  2014-11-26T22:42:10 WARN src/stlink-common.c: unknown chip id! 0xe0042000
  make: *** [flash] Fehler 255
  

  Macht ja auch Sinn, sonst kauft sich jeder ein STM32F0 board für 10€ und nicht den Programmer für 30€. Den USB-Prog versuch ich dann morgen.

• Was spricht dagegen?

Allgemeine Sachen und Struktur von RIOT

Allgemeine Hinweise

• damit wir uns im Quelltext synchronisieren können und damit wir wissen, wo noch offene Baustellen von uns sind, diese TODOS als

   // TODO DIY
  

  kennzeichnen, damit wir mit

  $ grep -i "TODO DIY" ./ -R
  

  auf das ganze Repository unsere Baustellen leicht finden können.