VS-Code (2): C-Programme für den Pico (Seite 3)

int8_t user_spi_read(uint8_t reg_addr, uint8_t *reg_data, uint32_t len, void *intf_ptr) {
  int8_t rslt = 0;
  asm volatile("nop \n nop \n nop");
  gpio_put(SPI_CS, 0);               // Chip select is active-low
  asm volatile("nop \n nop \n nop");
  spi_write_blocking(SPI_PORT,&reg_addr,1);
  sleep_ms(10);
  spi_read_blocking(SPI_PORT,0,reg_data,len);
  asm volatile("nop \n nop \n nop");
  gpio_put(SPI_CS, 1);               // Chip de-select is high
  asm volatile("nop \n nop \n nop");
  return rslt;
}

Die Sleep-Funktion reicht die Dauer nur in Mikrosekunden durch, beim BMP280 handelt es sich aber um Millisekunden. Das blieb im Readme zum BME280-API irrtümlich so. Die SPI-Lesefunktion setzt CS auf Low, liest die Daten vom SPI-Port und setzt CS wieder auf High. Wie genau die Funktionen heißen und welche Parameter Sie benötigen, steht in der Dokumentation des Pico-SDK [9].

VS-Code blendet als kleine Hilfe automatisch Namensvorschläge und Dateisignaturen samt Kurzhilfe direkt beim Schreiben ein. Wenn Sie also vermuten, wie eine Funktion heißt, erspart das den Griff zur Dokumentation. Im vorliegenden Fall tippen Sie also spi. Daraufhin zeigt VS-Code alle Funktionen an, die mit spi beginnen, darunter spi_write_blocking und spi_read_blocking.

Die nicht abgedruckte Write-Funktion funktioniert analog. Die per ASM-Befehl eingefügten Leer-Operationen unterstützen das vom Sensor benötigte Timing. Der Pico agiert so schnell, dass die Software andernfalls die erforderlichen 20 Nanosekunden für die CS-Wechsel nicht einhält.

Testen

Steht der Programmcode, ist es an der Zeit, das Programm zu bauen und auf den Pico zu laden. Das Bauen starten Sie mit einem Klick auf Build in der Statuszeile (Abbildung 5, rechts). Beim ersten Mal dauert das relativ lange, da die IDE dann die Pico-Support-Bibliotheken erstellt. Danach überprüfen Sie den Reiter Probleme, in dem keine Fehler mehr erscheinen sollten. Andernfalls wechseln Sie auf den Reiter und navigieren per Klick auf den Fehler zum verantwortlichen Programmcode.

Eine Software ohne syntaktische Fehler funktioniert noch nicht zwingend. Da sie auf die serielle Konsole schreibt, starten Sie jetzt ein Konsolenprogramm. Dazu wechseln Sie in den Reiter Terminal und rufen dort minicom /dev/serial0 auf.

Statt Minicom kommt auch ein anderes Konsolenprogramm infrage, etwa Tio oder Screen. Anschließend kopieren Sie das Programm mit der Schaltfläche Copy to Pico (Abbildung 5, links) auf den Controller. Es startet dort automatisch. Im Idealfall zeigt die Konsole jetzt die Messwerte an (Abbildung 8).

Abbildung 8: Im ersten Anlauf erfolgt die Ausgabe der Messwerte auf der Konsole. Im Grunde haben Sie damit alle Daten zusammen, die Sie für eine Wetterstation benötigen.

Funktioniert die Software wie vorgesehen, sparen Sie sich den Build-Schritt, denn die Kopierfunktion baut bei geänderten Dateien das Programm automatisch neu. Wenn es zwar läuft, aber nicht das tut, was Sie sich vorgestellt haben, geht es ans Debuggen. Das klappt sehr komfortabel innerhalb von VS-Code.

Fazit

Wer VS-Code nicht kennt, braucht naturgemäß etwas Übung. Viele nützliche Funktionen, wie etwa das Ein- und Ausblenden des Terminalfensters per Tastatur um den Editor-Bereich zu vergrößern, gehen erst nach einiger Zeit in Fleisch und Blut über. Danach programmieren Sie aber sehr effizient, und das Bauen und Kopieren von Pico-Programmen erledigt der Editor dank seiner vielen Erweiterungen wie von selbst.

Die komplette Version des hier vorgestellten Codes finden Sie in den Github-Repos des Autors für den BME280 [7] und BMP280 [8]. Dort gibt es im Branch TFT eine Version, die deutlich komplexer ausfällt und die Messwerte auf einem kleinen 1,8-Zoll-TFT ausgibt (Abbildung 9).

Abbildung 9: Klappt alles, bietet es sich an, die ermittelten Werte auf einem Mini-TFT auszugeben. Der Weg zur individuellen Wetterstation ist dann nicht mehr weit.

Der TFT-Branch verwendet eine externe Bibliothek als Unterprojekt; das Einbinden in die CMakeLists.txt erledigen Sie dabei ohne große Klimmzüge. Die nächste Folge dieser Reihe befasst sich neben dem Debuggen mit speziellen Hardwarefunktionen des Pico. (tle)