Projektlogbuch RasPi Projekt

Auf dieser Seite wird der Projektfortschritt dokumentiert. Das dient zu folgenden Zwecken:

  • Für mich selbst, um zu sehen wann habe ich was sgemacht
  • Für andere die eventuell ein ähnliches Vorhaben planen
  • … um etwas an die Welt zurückzugeben 😉

23.12.20: es geht weiter aber anders

Die Ferienzeit habe ich genutzt einmal zu überlegen wie es weitergeht. Alles weitere erfolgt auf einer eigenen Seite

Fast 2 Jahre Pause

Nach fast 2 Jahren Pause habe ich das Raspi Projekt noch einmal ausgegraben und möchte es gern weiter oder zu Ende führen. Mit etwas Abstand und vielleicht auch etwas mehr Zeit könnte sich daraus noch etwas ergeben.

30. April 2020: Die Entwicklungsumgebung wird geprüft

Eine erste Inbetriebnahme der Schaltung zeigt, es funktioniert noch. Dann will ich mal sehen ob was alles gemacht werden muss damit es auch aktuell ist und genutzt werden kann.

Los geht es auf dem Raspi, OS Update etc. …. Pakete auf den aktuellsten Stand bringen, Code Blocks starten, schauen ob noch alles funktioniert, … siehe da, es geht.

Weiter geht es mit Eagle, neue Version laden und mal das letzte Schaltplan und Board Modell laden. Geht auch alles. Prima. Dann mal in Ruhe nachdenken was war zum Schluß offen und was lief nicht so gut.

  • PWM Leistungsstufe – ist eher ein Test aber nicht gut. Heute wiess ich, es grenzt an einem Wunder das überhaupt irgendwie läuft 😉
  • Ein paar Dinge könnten vom Look & Feel anders sein bei der Telnet Ausgabe und Kommunikation mit dem Backend … ok – ist nebensächlich aber für den Einstieg kann man das ja mal machen
  • Ist SPI wirklich die richtige Entscheidung oder ist I²C nicht vielleicht besser? Ist beides gut?

Mai 2017 bis Juli 2018

Hier sind die Schritte dokumentiert, die in der Zeit Mai 2017 bis Juli 2018 erfolgten.

15.07.2018: Aktueller Stand, Weg zum Produkt

Das Wetter draußen ist super und seit nunmehr mehr als 49 Tagen läuft das System Online und ist parallel an den Solarzellen der Gartenbeleuchtung angeschlossen. In diesem Zeitraum kam es zu keinem Ausfall und das System war jederzeit erreichbar. Die angeschlossenen Verbraucher konnten jederzeit geschaltet werden.Also, wie geht es weiter auf dem Weg zum Produkt?Der letzte Platinenstand ist noch nicht bestückt. Auf der letzten Version gab es noch ein paar wenige kleinere Anpassungen. Eventuell muss dazu auch noch die Software angepasst werden. Zwei Exemplare gilt es jetzt zu bestücken und dann muß damit ein Prototyp in ein Gehäuse eingebaut werden. Wäre schon ganz gut, wenn es mal langsam wie ein fertiges Produkt ausschaut 😉Wie soll das Produkt aussehen?

  • Ein Gehaüse muß her
  • Der Raspberry Pi soll als zentrales Element in das Gehäuse rein. Weiterhin müssen min. 2 Extension Boards, 1 StepDown Wandler für 5 V, eine Reaiskarte mit min. 4 OUTLETS verbaut werden.

Das Übersichtsbild zeigt was alles geplant ist:

12.05.18: S2018-0002 „Strommessung auf Board #0“

Die Strommessung ist nicht ganz so einfach, wie die Spannungsmessung. Da es sich um ein gepulsten Ladestrom handelt müsste der Strom zur „ON“ Zeit des Signals gemessen werden. Um diesen zu synchronisieren müsste der AD Wandler wissen wann „on“ ist. Dazu gibt es eine klare Möglichkeit -> einschalten, messen, ausschalten. Das Problem dabei ist, dieser Ladeimpuls erhöht im standby (Ohne Verbraucher) die Akkuspannung und umgeht/ beeinflusst die Regelung. Alternative b) ist es einfach mehere samples auf die Zeit zu verteilen und den Maximalwert zu ermitteln. Je mehr Werte zur Verfügung stehen, desto genauer ist das Ergebnis. Mit 20 samples scheint es derzeit ganz gut zu laufen

S2018-0003 „Software PWM Generator Konzept überdenken“

Der SW-PWM Generator läuft als eigenständiger Thread. Die PWM Frequenz wird durch folgende Punke bestimmt:

  • Die PWM Bandbreite
  • In der Routine die Art wie im +DC und -DC das Programm wartet
  • Priorisierung des Threads im OS

Je höher (also hochauflösender die PWM Bandbreite) desto niedriger ist die PWM Frequenz. 0..128 => ca. 110Hz; 0..196 => ca. 75Hz; 0..256 => ca. 52Hz; 0..512 => 25Hz

Wird im Programm gar nicht gewartet (ohne nanosleep Befehl) während + und – DC kann eine PWM-Frequenz bis zu 130 kHz erreicht werden. Damit hat man allerdings auf dem Core 100% CPU Last und das ist langfristig nicht gut. Deutlich besser ist es mit der Verwendung von usleep und nanosleep. Die Parameter die ich jetzt verwendet habe sind

struct timespec ts;
 ts.tv_sec = 0;
 ts.tv_nsec = 0;

Mit diesen Daten werden die o.g. Werte erreicht. Die CPU bleibt damit in normalen Last-Parametern.

//
// Abbildung des +/- Duty Cycle, hier die negative Flanke
//
if (SCdata.EB_PWMdata[1]<SCdata.EB_PWMrange[1]) {
 for (a=SCdata.EB_PWMdata[1]; a<=SCdata.EB_PWMrange[1]; a++) 
 {
  digitalWrite(4, LOW);
  nanosleep(&ts, NULL);
 }
}

Daraus ergibt sich folgendes Fazit:

Die wichtigsten Parmeter sind nun generell bekannt. Es gibt noch eine Reihe andere Wechselwirkungen wie z.B. die Frequenz, diese hat auch Auswirkungen auf die Leistungsstufe. Ggf. passen die Kondensatoren und Spulen nicht mehr und die Verlustleistung an den MOS FET´s sind bei unterschiedlichen Frequenzen anders. Betreibt man am Ausgang beispielsweise eine Autolampe sieht man diese bei 25Hz sehr wohl flackern, ab 35Hz schon nicht mehr. Da die Parameter einstellbar sind muss man für die Anwendung am Ausgang dann die idealen Parameter ermitteln.

Es bleibt also so wie es jetzt ist. Der Punkt kann also geschlossen werden.

11.05.18: Softwareanpassung

Symtom S2018-0001:
Board 0, Messung der Spannung am Akku springt während der Anzeige

Lösung S2018-0001:
Die Messung der Spannung am Akku ist nicht synchronisert mit dem PWM Signal zur Ladung. Durch die sehr kurze Samplingtime des AD Wandlers misst der Wandler zu „undefenierten“ ON/OFF Zeiten. Das Problem ist behoben. Für die Messung wird der PWM Generator auf 0 gesetzt und es wird die Spannung am Akku ohne Ladestrom gemessen.

12.04.18: Neue Controllerplatine eingetroffen, SW Anpassungen

Das Release 3.2 ist eingetroffen und wartet auf zusammenbau. In diesem Release sind noch ein paar wenige Änderungen enthalten. Hier ist jetzt eine Diode zur Trennung der AD Wandler am Ausgang und Eingang eingefügt. War die Spannung am Solarpanel kleiner als die Akkuspannung, so hat die PWM Leistungsstufe durchgeschaltet und der AD Wandler des Solar Panels hat die Akku Spannung angezeigt und nicht die Solarspannung. Sollte jetzt also korrekt sein.

Die Softwareversion 1.6.1.9 läuft nun seit mehr als 340.000 Sekunden (3.9 Tage) problemlos. Die Performanceprobleme mit den CPU Kernen sind also wohl behoben. Das führte dazu, nix geht mehr. auch ist die Anzahl der Connections zum Admin Frontend stabil und nicht mehr begrenzt. Zwischenzeitlich ist auch die Relaisplatine eingebunden und auf diese Weise lassen sich jetzt auch Verbraucher mit 230 Volt schalten.

03.04.18: Startscript mit Screen und neues HW Release, Relaisplatine, PWM/ CPU Auslastung

Mit SCREEN läuft es jetzt erst einmal ganz gut. Das Startscript ist angepasst und sollte noch ein Socket offen sein, so wartet das Startscript jetzt bis der Socket geschlossen ist.

SCREEN ist ein Fenstermanager zur Verwendung mit textbasierten Eingabefenstern (Textkonsole). Dieses Tool kann auch gut eingestzt werden um Programme automatisiert zu starten die eine Bildschirmausgabe benötigen

Auf der Platine gab es auch noch eine Änderung. Der AD Wandler zur Messung der Solarspannung muss durch eine Diode getrennt sein. Ist das nicht der Fall wird ohne Solarspannung die Spannung vom Akku (Verfälscht durch den dazwischen liegenden MOS-FET) gemessen. Das ist möglich weil der MOS-FET durchgeschaltet ist. Desweiteren ist in der PWM Leisungsstufe der Elko falsch angeschlossen. Der Pluspol hängt am Eingang (also wo die Solarzellen angeschlossen sind) und nicht wie es richtig sein sollte am Ausgang vor der Drosselspule. Das neue Release 3.2 ist bestellt.

Die Ansteuerung der Relaisplatine funktioniert auch schon. Hierbei hatte ich auf eine fertige Version von Amazon zurückgegriffen. Das ist ein Massenartikel und kann selbst nicht günstiger hergestellt werden. Die Relaisplatine hängt über einen fertigen StepDown Wandler, 5V Stabilisierungsstufe am Akku. Der Stepdown Wandler reduziert die verlustleistung am 7805 indem die Spannung von 12V auf ca. 7V reduziert wird. Mit der Relaisplatine kann jetzt auch 230V Verbraucher geschaltet werden. Die Relaisplatine kann an jedem Board am Port B des MCP23S17 angeschlossen werden. Damit kann jedes Board bis zu 2 Relaisplatinen, also 8 Relaisports ansteuern. Softwareseitig muss ich mir da noch was einfallen lassen wie das eingebunden wird. Die Konfiguration kann dann im INI-File abgebildet werden.

SoftPWM ist notwendig, weil der RaspberryPi nur ein HW Modul hat. Das HW Modul wird für die Akkuladung verwendet auf Board 0

Ein leidiges Thema ist noch das SoftPWM Modul. Dieses läuft als Thread getrennt vom Hauptprogramm. Die Schattenseite ist, von den 4 Cores wird einer dazu vollständig genutzt um diesen Thread zu bedienen. Ich habe zwar vorgesehen diesen auch extern zu nutzen aber es ist mit etwas Aufwand verbunden. Da ist erst einmal die Hardware und natürlich auch die Integration durch Software Module.

02.04.18: Config File

Mit dem Versuch die Konfiguration des Systems komplett als Binärdatei auf die Festplatte zu schreiben hatte ich wenig Glück. Zum einen ist das nicht wirklich gut lesbar zum anderen gab es immer mal wieder Probleme für die ich nicht wirklich eine Lösung gefunden hatte.

Ein neuer Ansatz musste her. Ideal währe es, wenn diesmal das File auch von Hand editierbar ist und naja wenn es in Sektionen aufgebaut werden kann. Eine Weile suchen im Internet hat sich gelohnt, ich konnte ja nun nicht der erste sein der sowas braucht. Sobald man die richtigen Stichworte in der Suche verwendet geht es ….. gesagt getan, ich habe ein Modul gefunden, welches nicht nur lesen auch schreiben kann. Das Ergebnis ist ein solches ini-File. Was will man mehr, sieht doch gut aus.

[BOARD0]
SCdata.PWMrange=2048
SCdata.AKKUmax=12.000000
SCdata.Imax=3.000000
SCdata.PWRactual=0.000000
SCdata.logfilename=/tmp/SCDATALOG.log
SCdata.SWver=HW: REV3.1, SW: Ver. 1.6.1.5 01.04.2018
SCdata.Vrange=4096
SCdata.Vinpre=22.276596
SCdata.Voutpre=22.276596
SCdata.Vrefpre=1.000000
SCdata.PWRmax=2.489508
SCdata.PWRkwh=0.000016

[BOARD[1]]
SCdata.EB_AKKUmax[1]=0.000000
SCdata.EB_Imax[1]=1.000000
SCdata.EB_PWRactual[1]=0.000892
SCdata.EB_PWRmax[1]=2.858623
SCdata.EB_PWRkwh[1]=0.000103
SCdata.EB_PWMrange[1]=2048
SCdata.EB_Vinpre[1]=22.276596
SCdata.EB_Voutpre[1]=22.276596
SCdata.EB_Vrefpre[1]=1.000000

Ein weiteres Problem ist immer noch der Start des Programmes. Zeitweise kommt es vor, das Programm ist einfach von jetzt auf gleich beendet. ich bin mir nicht sicher ob es daran liegt das ich das aus einem SSH Fenster heraus gestartet habe und es mit dem schließen des Fensters zu tun hat oder ein anderes Problem eine abnormale Beendigung die Ursache ist. Auf jeden Fall habe ich jetzt mit SCREEN das ganze mal gestartet und will mal sehen ob es jetzt länger läuft. Die Konfigurationsdatei wird jetzt im Zusammenhang mit der Logdatei geschrieben, das sort dafür dass die Parameter und aktuellen Werte nicht verloren gehen. Wenn das alles dann auch stabil läuft müssen die Parameter die geschrieben und gelesen werden noch einmal angepasst werden. Das sind aktuell nur die notwendigsten.

31.3.18: Socket anpassen

In der aktuellen Version war es nur möglich einen Socket für die „remote“ Einstellung zu nutzen. Da nach Aufbau der verbindung ein eigener Thread gestartet wird konnte dieses erst einmal ganz einfach angepasst werden. Jetzt muss es im Betrieb sich einfach einmal zeigen, ob es geht oder nicht. Auf jeden Fall ist jetzt mehr als eine Verbindung möglich.

29.3.18: Socket nochmal nachbessern

Die letzten Tage habe ich das System mal im Dauerbetrieb laufen lassen und wollte mal sehen wie es im echten Betrieb aussieht. Ein Ergebnis ist, irgendwann kann man sich remote nicht mehr aufschalten und der Hauptprozess muss neu gestartet werden. Bisher war es so, eine Connection ist möglich für die remote administration und wenn die Verbindung abgebaut wird kann sich erneut angemeldet werden. Das scheint so nicht zu klappen, insbesondere wenn die Verbindung abgebrochen wird.

20.03.18: Extension Board zur Steuerung des Ausganges

Jetzt habe ich ein weiteres Extension Board verwendet um damit exemplarisch eine Lampe zu steuern. Nicht irgendeine Lampe – eine LED Lampe mit 12Volt.

Eigentlich funktionierte es wie geplant. Der SoftPWM ist allerdings im WiringPI Modul nicht gerade ein Highlight was die Geschwindigkeit angeht. Ich habe das jetzt neu geschrieben und es ist denkbar einfach und recht gut. Der Software PWM von mir läuft mit ca. 470Hz und einer Bandbreite von 2048Bit. Damit lässt sich eine recht feine Abstufung einstellen. Die > 400Hz führen dazu das es nicht flackert. Durch Reduktion der Auflösung würde die Frequenz noch höher werden.

Der SoftPWM von mir läuft jetzt als Thread parallel zum eigentlichen Programm und wird über das globale Struct mit dem Parameter-SET des Extension Board ID#1 gesteuert. Das ist denkbar einfach und gut.

An der Benutzerführung der Software habe ich ebenfalls noch ein paar Finetunings gemacht und es zeigt sich das es wohl am besten ist, das Programm auf dem Raspi ausschließlich als Service ohne jede Interaktion laufen zu lassen. Die Interaktion sollte dann über TCP/IP auf dem Socket erfolgen. Das ist erheblich einfacher und sogar besser. Momentan ist zwar nur eine einzige Verbindung möglich aber da muss ich mal schauen, das geht bestimmt auch anders.

12.03.18: Übersicht

Das Übersichtsbild zeigt wo die Reise hingehen soll. Ein paar dieser Bausteine sind noch nicht realisiert. (Stepdown und 5V Power Supply)

Die 5V Spannungsversorgung für den Raspberry Pi kommt derzeit noch aus der Steckdose. Im Zielbetrieb sollte natürlich auch der Steuercomputer aus dem Akku gespeist werden. (Sonst ist es ja keine Inselanlage)

Das Extension Board ist in diesem Modell bereits 2x eingesetzt. Board #0 wird immer zur Ladesteuerung verwendet und Board #1..#7 für die Steuerung weiterer Verbraucher und IO´s.

Über die am Extension Board #1 angeschlossene Relaiskarte können Verbraucher potenzialfrei, also auch mit 230 Volt, angeschlossen werden.

Übersicht als PDF Datei

  • Overview.pdfDie PDF Datei zeigt das schematische diagram welche Komponenten der Steuerung angehören

10.03.18: Software weiter verbessert

Die Steuersoftware läuft seit einigen Tagen jetzt im Dauerbetrieb. Das Programm kann mitlerweile als Service im Hintergrund laufen und seit heute kann über einen eigenen Port über einen Socket auf das Programm zugegriffen werden.

Zwei wesentliche Funktionen sind jetzt etabliert.

  • Das Dashboard, in dem alle wichigen Parameter und Daten erkennbar sind
  • Das Konfigurationsinterface, indem Betriebsparameter angepasst werden können

Der Port ist aktuell fest auf 9000 eingestellt, kann aber grundsätzlich angepasst werden. Eine Telnet Verbindung zeigt zuerst das Dashboard und von dort aus kann das Setup der Betriebsparameter aufgerufen werden. Erst war es etwas schwierig diese Tasks mit in den eigentlichen Steuerprozess einzubinden. Später stellte sich dann heraus, es ist einfacher und auch viel leichter dieses als Thread laufen zu lassen. Im Test lief es jetzt fehlerfrei und dabei ist auch die Frage ob der Filedescriptor „blocking“ oder NONBlocking“ ist nicht mehr wichtig.

04.03.18: DS3231 RTC (Echtzeit Uhr; optional)

Habe eben noch einmal die Anschlussbelegung geprüft. Passt doch und ist alles ok. Dann kann ich ja anfangen und aus dem Datenblatt des Bausteins heraussuchen welche Register gesetzt und gelesen werden müssen.

Zuvor muss aber die I2C communication laufen. Also erst einmal etwas lesen, nachdenken und probieren.

Das Foto zeigt das Extension Board mit aufgesteckten RTC Modul.

03.03.18: Board Rev 3.0 und aktuelle SW Version

Heute habe ich die aktuelle Boardversion 3.0 bestückt und in Betrieb genommen. Der Instrumentenverstärker ist nun vom Board verschwunden, dafür sind nun alle Bauteile des Step Down Wandlers darauf und die RTC mit I2C Anschluss ist hinzugekommen.

Doch auch bei dieser Version haben sich noch ein paar kleine Fehler eingeschlichen. Der 74244 ist gar nicht an der Stromversorgung und der I2C Baustein hat eine falsche Pinbelegung – Ups. Da die Version 3.1 bereits in Arbeit ist werden diese Punkte mit aufgenommen und gefixed. In der Version 3.1 kommen dann auch 2 weitere MOS-FETs als Verstärkung hinzu. Dann werkeln da 3 Stück. Damit sollte dann genug Power und Schaltleistung vorhanden sein. Jeder FET sollte so ca. 10A mit Kühlung hinbekommen und da es P-Kanal MOS-FETs sind können die einfach parallel geschaltet werden.

Was ist bei der Software passiert? Viel!

Den Exkurs in Richtung mehrere Prozesse gleichzeitig und Multi Threading habe ich nach ein paar Nachtschichten jetzt verworfen. Das Programm ist jetzt gut strukturiert mit einem Parameter Set der alle wichtigen Daten beinhaltet, sowohl für die Steuerung als auch für das Logging etc.

Das Dashboard, siehe Screenshot, zeigt nun alle wichtigen Daten in einer Übersicht an und das allerbeste ist, vom Handy kann das Dashboard mit einem Terminalprogramm ebenfalls abgefragt werden. Das war eine ziemlich schwere Geburt aber jetzt weiß ich wie das Thema Socket Programmierung unter C geht. Macht echt Spaß, wenn man es verstanden hat. Bei der Gelegenheit kann man auch gleich noch etwas interne Dinge zum Thema Steuerung von IO Kanälen lernen und wie man Eingabekanäle auf „NONE BLOCKING“ stellt.

Durch die zentrale Steuerung über die Struct Variable lassen sich nun auch viele Dinge schon einstellen. Dazu gibt es ein eigenes Setup Unterprogramm. Insbesondere die PWM Werte sind jetzt flexibel konfigurierbar. Hier noch einmal der Hinweis, der HW Generator des Broadcom Chipsatzes auf dem Raspi hat einen Takt von 19.2 MHz. Der Vorteiler und die PWM Bandbreite ist einstellbar, somit kann die Frequenz und die Feinheit sehr gut justiert werden.

Bereits in der Version 3.0 ist der Vorteiler am AD Wandler nun noch einmal angepasst. Der Bereich geht nun bis 40 Volt und der AD Wandler für die Strommessung lässt sich auf den entsprechenden ACS712 Typen anpassen (10A, 20A und 30A). Erste Test am Solarpanel was auf dem Dach montiert ist waren positiv. Mittlerweile habe ich für Testzwecke mal einen neuen Akku mit 12V/12Ah beschafft und der fühl sich richtig wohl.

Das Logging ins Filesystem ist nun kontinuierlich, da werden dann wirklich viele Daten geschrieben, minütlich oder stündlich möglich. Mit minütlich ist es ganz passabel.

Wenn jetzt in HW-Version 3.1 die RTC auch läuft, dann schlägt man 2 Fliegen mit einer Klappe. A) eine RTC speichert ja nun mal die Zeit wenn der Strom ausfällt B) der Raspi hat gar keine HW Uhr, dann hat er über das Board eine.

27.02.18: PWM Background

Das Thema PWM ist nicht ganz trivial und die wichtigsten Daten sind hier jetzt einmal zusammengefasst.

Der Broadcomm Chip läuft mit einer Frequenz von 19.2MHz. Über die Vorteiler Einstellung und die PWM Range lässt sich die Frequenz für den PWM Generator einstellen. Die Berechnung ist wie folgt.

f = 19.2MHz / Vorteiler / PWMrange

Diese Formel gilt solange der PWM Generator im Modus Mark/ Space läuft. Damit ergeben sich folgende Grenzen unter der Annahme das PWM range sinnvoll ist 0..100 = 96kHz bei f= 19,2 MHz / 2 / 100

Der Screenshot zeigt das PWM Signal mit 468.8Hz und einem DC von 22,7%

Mit höheren Frequenzen steigen auch die Nebenwirkungen der PWM Leistungsstufe. Die Verlustleistung am MOSFET nimmt zu (u.a. weil die GS Kapazität eine bedeutende Rolle spielt) und die LC Kombination in dem StepDown Wandler arbeitet zwar mit kleineren Werten (was die Bauweise begünstigen würde) aber auch die Nebenwellen der Schaltstufe können sich dadurch negativer auswirken.

Ein Kompromiss ist scheinbar so im Bereich von 400-800 Hz zu arbeiten und einer PWM Range von 0..2048. Je höher die Range ist, desto länger benötigt die Schaltung zu reagieren aber auch umso granularer und detailierter ist die Einstellung. Dabei bleibt der Wert ebenfalls stabiler, denn es gibt nur sehr kleine Spannungssprünge.

Die Lösung ist vermutlich experimentell die richtigen Parameter zu ermitteln. (Da diese über das Setup einstellbar sind ist dieses kein Problem.) Die ermittelten Werte könnten dann die Defaultwerte darstellen.

27.02.18: Updates zum Extension Board

Es ist fast ein Monat vergangen seit dem letzten Posting hier, in der Zeit ist doch einiges passiert. Ich liste das mal auf:

  • Neues Platinenupdate
  • Step Down Wandler läuft nun auch so wie er soll

Die meisten Veränderungen haben sich im Bereich der Software ergeben:

  • Der Reglkreis läuft nun sehr gut und vor allem schnell
  • Logging von wichtigen Daten in eine Datei
  • Dashboard liefert alle wichtigen Daten auf den Schirm
  • Alle Parameter sind in einem STRUCT Datentyp vereint und sind über spezielle Menüs konfigurierbar. Die wichtigsten sind bereits umgesetzt
  • Der PWM Generator on Board kann Frequenzen bis zu 600kHz, die Wahl der Frequenz soll noch als Parameter konfigurierbar gemacht werden. Muss noch einprogrammiert werden
  • Die Stromstärke kann nun auch als Parameter mit eingestellt werden

So ganz langsam nimmt das kleine Gerät fahrt auf. Technisch ist es schon in der Lage das alte System zu ersetzen (zumindest im Labor). Hardwareseitig sind jetzt noch ein paar Modifikationen angesagt. Diese Woche wird wohl die neue Platine mit den Step Down Wandler on Board kommen und der Instrumentenverstärker MCP6S28 ist von der Platine verschwunden, wird nicht benötigt.

Softwareseitig wird auf jeden Fall noch ein Webinterface kommen sowohl für die Ausgabe der Daten als auch zur Eingabe und Steuerung.

31.01.18: Test des Extension Boards geht weiter

Jetzt wo das PWM Modul läuft gibt es noch wenige Punkte die geprüft werden müssen. Zum einen macht der Instrumentenverstärker noch nicht das was er soll und der MCP23S17 hat 2 8Bit breite Ports. Port A wird für die Chip Select Signale in Kombination mit /CS1 vom Raspberry Pi verwendet, Port B ist ein GPIO.

Um den Ausgang des Port B zu testen habe ich bei ALLPCB noch einen Test Adapter bestellt. Dieser soll bis Freitag, 2. Februar 2018 angekommen sein.

Heute ist auch aus USA von OSH Park das PWM Modul auf PIC Basis gekommen. Ich muss sagen, der Lieferant überzeugt mich nicht. Preislich und von der Geschwindigkeit kann er mit ALLPCB keinesfalls mithalten. Die Qualität ist ebenfalls nicht so gut. Dabei meine ich die mechanischen Dinge. Dort wo die Platinen aus dem Nutzen getrennt sind befinden sich noch „NASEN“ die jetzt manuell zu entfernen sind. Das habe alle anderen Lieferanten besser gemacht. Das die Lötpads vergoldet sind ist schön aber eher nice to have.

Sobald die Platine Test Adapter angekommen ist geht es weiter mit der Programmierung des MCP32S17 um darüber ggf. auch Relais oder ähnliches anzusteuern. Bis dahin denke ich mal nach warum der Instrumentenverstärker solche „zicken“ macht

25.01.18: PWM Amplifier Modul läuft wie geplant

Heute habe ich die letzten Bauteile auf der PWM Treiberstufe bestückt. Das ging mal ganz reibungslos – läuft sofort und wie geplant. Erst einmal unter Laborbedingungen, also mit einer Autolampe und am Netzteil und siehe da, it works.

Die AD Wandler zeigen auch schon die richtigen Werte an. Enzig wenn das Tastverhältnis zu klein ist schafft es der Wandler nicht die Spannung zu ermitteln, bzw. er misst gena in der Pause und dann ist nunmal keine Spannung am Ausgang. Das sollte sich allerdings ändern wenn ein Akku angeschlossen wird zum laden, dann sollte immer etwas angezeigt werden.

24.01.18: Extension Board lebt

Es hat jetzt schon einiges an Zeit gekostet aber nun geht es voran. Nachdem einige Probleme mit dem 23S17 behoben waren und jetzt endlich klar ist das nach einem Power On Reset (POR) der Baustein in BANK 1 startet und nicht in Bank NULL (wie man ja nunmal vermuten könnte) klappt es auch mit der Kommunikation. Leider ist das Datenblatt dazu nicht ganz eindeutig und auch das Internet oder die Leute die das Internet füllen. Wenn man dann seinen eigenen Schaltplan korrekt liest und per Jumper die richtige Hardware Adresse einstellt hat das Vorteile 😉

Also, der Logic Analyser zeigt deutlich das die Porterweiterung der Chip Select Kanäle geht und auch die Bausteine lassen sich ansprechen. Als erstes klappte das mit dem TC77, dann mit der Referenzspannungsquelle und mit den A/D Wandler 3208. Einzig der Instrumentenverstärker zickt noch rum. Sobald er im Sockel steckt gehen alle CS Leitungen gleichzeitig auf LOW – ups.

So jetzt geht es erst einmal ins Bett – schluß für Heute.

Ach ja, natürlich gibt es auch hier ein paar Dinge die im Schaltplan zu ändern sind und beim kommenden Platinenlayout angepasst werden können oder müssen. Das ist aber derzeit überschaubar.

22.01.18: Ergebnisse/ Fortschritt vom Wochenende

Erste Ergebnisse nach der Bestückung des Boards „SC-SPI-PWM“

  • Der 5V Teil kommt komplett raus – wird nicht gebraucht, alles auf dem Board läuft mit 3.3V
  • An der Sub-D Buchse ist Masse falsch angeschlossen, muss von PIN9 auf Pin5
  • Die Elkos im Netzteil können ein kleineres Rastermaß haben
  • Die Trennwiderstände von dem „In Circuit Programming Adapter“ bekommen andere Werte (68 Ohm). Damit erkennt der PicKIT auch den Controller korrekt
  • Die Programmierumgebung ist eingerichtet und per RS232 kommuniziert PIC18F46K20 bereits mit mir. Hier musste auch erst mal noch ein Update auf die neue IDE gemacht werden und bis dann alles soweit lief verging leider die eine und andere Stunde. Eine Nachtschicht hat es aber gebracht 😉

Die „Extension Board Platinen“ sind ebenfalls heute morgen eingetroffen. Da geht es dann dran sobald das PWM Board grundsätzlich läuft. Eine erste Sichtkontrolle scheint aber so zu sein, wie es soll.

PWM Modul:

Die Programmierung des PWM Moduls (ECCP1) auf dem 18F46K20 ist keine hexerei. Mit einigen Mausklicks ist das Modul im MCC konfiguriert und mit einer kleinen Schleife von 0..1023 kann auch schon das Tastverhältnis auf die gesamte Breite getestet werden. Läuft also und am Anschluß kommt das an was ankommen soll.

19.01.2018: Bestückung des PWM Generators

Nachdem die Platinen eingetroffen sind habe ich schon mal angefangen die Bestückung zu machen. Auch dabei ist kein Fehler auf der Platine aufgetreten. Qualität also immer noch Tip Top. Das Bild zeigt die fast fertig bestückte Platine. Die beiden ICs, der Controller und der MAX232 sind noch nicht bestückt. auch fehlen noch die Tantal Kondensatoren für den MAX232.

18.01.2018: PWM Generator PCB geliefert

Wow, das muss man schon sagen da bin ich mal begeistert. Die Platinen für den PWM Generator hatte ich zum Vergleich in USA bei OSH Park und in China bei AllPCB bestellt und die Challenge hat eindeutig ALLPCB gewonnen. Heute gegen 13.00 Uhr klingelt es an der Tür und TNT liefert wie versprochen 6 Platinen in einwandfreier Qualität.

Nochmal zusammengefasst, 11.1.18 bestellt, 3 Platinen zum Preis von 15.84USD inkl. Transport und am 18.1.18 um 13.00 Uhr 6 Platinen geliefert.

Sieht so aus als ob die mit weiteren Aufträgen rechnen können.

12.01.2018: Externer PWM Generator

Das Thema PWM hat mich noch einmal beschäftigt und ich bin zu dem Entschluß gekommen einen externen PWM Generator mit möglichst viel Fexibilität einzusetzen. Die Suche nach einem Baustein der sowohl SPI als auch einen flexiblen Generator mit unterschiedlichen Frequenzen vereint ist nicht so leicht. In der Regel sind es Module, welche zur Dimmung von LEDs oder 7-Segment Anzeigen eingesetzt werden. So richtig passen tun die aber irgendwie alle nicht.

Herausgekommen ist dabei jetzt eine Lösung auf PIC 18F4620 Basis. Der Controller hat eigentlich alles was man braucht onBoard (und noch vieles mehr). Was er nicht hat ist das passende Stück Software, das muss nun geschrieben werden. Da ich gerade etwas Zeit und auch Lust hatte habe ich mal einen Schaltplan erstellt und aus der Idee ein kleines Board gemacht, welches nun nicht ausschließlich für PWM zu verwenden ist. Bei der Gelegenheit hab ich auch gleich mal nach einem weiteren Platinenlieferanten gesucht und bin bei OSH Park fündig geworden.

Hier nun noch die Spezifikationen des µC Boards:

  • PIC18F4620 (32MB ROM, 1k EEPROM, 4kRAM, 1x RS232, SPI, 2xPWM, diverse IO)
  • RS232
  • SPI
  • 2xPWM
  • Spannungsaufbereitung 5V und 3.3V, 9V in
  • IN-CIRCUIT Programming Connector für Pickit2 und Pickit3

10.01.2018: Anleitung und Beschreibung für das Extension Board

  • Raspi-Extension-Board-V1.pdfWährend die Platine produziert wird und die Bauteilbestellungen auf dem Weg sind bleibt Zeit die Beschreibung anzufangen. Die erste Version ist jetzt fertig und kann hier angesehen werden.

5.1.2018: Das Extension Board ist bestellt

Nun ist es soweit, dass Board ist bestellt und nun warte ich auf die Lieferung. Das PCB soll bis zum 11. Januar 2018 erstellt sein und dann muss es noch geliefert werden. Die Zeit kann genutzt werden um die fehlenden Bauteile zu beschaffen.

Ein paar ACS712 in der 30A Version sind bereits auf dem Weg und so kann auch die Strommessung durchgeführt werden.

31.12.17: Jahresende -> Meilenstein geschafft

Die letzten 2 Tage habe ich mich erfreulicherweise dem Raspi Extension Board widmen können. Zusammenfassend kann ich sagen der Schaltplan und das PCB ist soweit fertig und kann nun beauftragt werden. Bis dahin war es doch noch eine nervige Sache und der Teufel steckte dann doch noch im Detail.

Was genau macht das Board eigentlich?

Es beinhaltet einen 8 Kanal ADC, einen Instrumentenverstärker mit 8 Kanälen, eine Referenzspannungsquelle mit 2 programmierbaren Outlets für die AD Converter, zur Messung der OnBoard Temperatur gibt es einen TC77 auf der Platine und mit einen MCP23S17 werden 8 weitere Chip Select Signale und 8 weitere GPIOs zur Verfügung gestellt. An einem SPI Connector können weitere SPI Devices angeschlossen werden, wie beispielsweise ein SPI Dsiplay. Das DOGM-162 hat mich mal wieder fast einen Tag gekostet und etliche Stunden vor dem Logic Analyser und beim Software Debuggen. **GRRRR** Ziel war es auf dem Extension Board nur Systeme zu verwenden, die über SPI kommunizieren. Falls es notwendig sein sollte kann jetzt auch noch eine RTC oder weitere Temperatursensoren hinzugefügt werden. Die Art der Geräte spielt keine entscheidende Rolle, Hauptsache ist sie haben einen SPI Anschluß.

Verbesserungen hat auch die Software bekommen. Der Umstieg auf die IDE CodeBlocks hat viel Übersicht und Struktur gebracht. Insbesondere die SPI Communication ist nun gut unterwegs, der damalige Exkurs in die Welt der Variablen und deren Handhabung von Zeigern etc. hat doch noch einmal etwas Vorschub gebracht.

Das besondere ist auch das mehrere Boards zum Einsatz kommen können. Es ist angedacht das bis zu 7 Boards als Extension zum Einsatz kommen können. Die Begrenzung ist auf Basis des MCP23S17 und dessen Adressdecoder (der kann nur A0..A2). Vermutlich ist diese Grenze schon zu hoch. Ich rene nicht damit 7 Boards auslasten zu können.

Der AD Wandler hat im Test recht genau abgeschnitten, obwohl hier keine Präzisionsbauteile verwendet wurden. Mit einem einfachem Spannungsteiler war die Abweichung zum digitalen 4-stelligen Multimeter nur eine, max. 2 Stellen hinter dem Komma. Das sollte wohl erst einmal ausreichen. Fest verkabelt ist auf dem Board die Messung am PWM Eingang, am PWM Ausgang. Die Strommessung wird dann mit Sensoren gemacht die auf Basis des Magnetfeldes einen Wert ausgeben und diesen dann analog zum Strom über einen der AD Wandler anzuzeigen. Da die Stromwandler so in der Dimension 20 Ampere und höher spielen habe ich diese NICHT auf die Platine gelegt. Da ist es besser diese dann mit einer dicken Steuerleitung zu versorgen.

Thema PWM. Der Raspi hat leider nur einen HW PWM Generator. Der ist auch nicht besonders gut, denn sowohl die Frequenz als auch die Performance sind suboptimal und nur wenig konfigurierbar. Für weitere PWM outlets gibt es die Möglichkeit von Software PWM. Die sind ebenfalls mehr schlecht als recht und benötigen viel CPU Leistung. Vermutlich wird ein PIC Microcontroller hier bei weitem bessere Dienste leisten können.

Damit sollten jetzt die Komponenten für ein neues Solar Controller Modul generell vorhanden sein und sobald das PCB da ist geht es daran die Software zu schreiben und pünktlich im Frühjahr mit den Tests zu beginnen.

Hier noch einmal die technischen Daten in der Übersicht:

  • 1x Port Expander MCP23S17: Port A 8x CS Erweiterung, Port B 8 weitere GPIO (Input/Output 3,3V Level)
  • 1x Temperatusensor TC77 on Board
  • 1x MCP3208 8 Channel 10Bit ADC
  • 1x MCP6S28 Instrumentenverstärker mit 8x 10Bit ADC
  • 1x MCP4812 Dual Vref für die ADCs; Über SPI programmierbar in 2mV Steps, 10 BIT Auflösung
  • 1x Power Stufe für PWM Aufbereitung; Der sollte so 20-25A bei bis zu 50V schalten können (wenn nicht vorher die Leiterbahn verdampft, ggf. muss im nächsten release was dickeres her oder mit Kupferdrath verstärken. Das sind nur wenige cm auf dem PCB)
  • 1x Feature Connector zum Anschluß weiterer SPI Devices
  • 1x SPI BUS termination

Als nächstes werde ich mal zusammenfassen warum ich die CS Erweiterung so gemacht habe wie es ist und wie die Realisierung abgelaufen ist. Nach einigem suchen im Internet habe ich gesehen das es einige Lösungen dafür gibt, die nehmen aber oft frei GPIOs vom Raspi und das ist genau nicht so gut. Ich dachte das geht besser 😉

04.09.17: Es geht voran, einige Dinge sind jetzt geklärt

Das Wochenende hat ein paar neue Erkenntnisse gebracht.

MCP23S17

Das Ding wollte einfach nicht so wie ich es wollte und den Fehler habe ich nicht gefunden. Ich habe ihn nicht sauber angesprochen bekommen und eine Ausgabe war reine Glücksache. Tracking und Debugging des SPI Bus brachte nicht wirklich eine Idee. Den Baustein auslesen ging auch nicht. Alles vom Testboard abgerissen und neu aufgebaut, …. manchmal hilft ja einfach ein Neubeginn.

Jetzt sollte es aber gehen denn, nachdem ich noch einmal aufgefrischt wie man mit Variablen in (insbesondere mit Pointern) hantiert hat sich mein Problem fast von selbst gelöst. Das & Zeichen ist entscheidend!

unsigned char *daten;

unsigned char elemente[2];

*daten = &elemente

„wiringPiSPI“ Bibliothek

In der Bibliothek gibt es den Befehl zur Kommunikation mit dem Device auf dem Bus. Wichtig ist die Erkenntnis, der Schreibpuffer wird mit dem lesenden Wert überschrieben. Das bedeutet in dem übergebenen Parameter ist auch der eingelesene Wert enthalten. Also in dem Array elemente und nicht in result!

result = wiringPiSPIDataRW (0, &elemente, 3);

Da nun die Kommunikation mit dem SPI Bus sauber läuft habe ich auch den Temperatursensor noch einmal eine neue Software Version verpasst und der Code ist nun deutlich besser – und es funktioniert.

Der Code hat allgemein noch ein Refresh erhalten um lesbarer zu werden und so sind jetzt einige #defines hinzugekommen. Codeblocks als IDE macht mitlerweile richtig Spaß und Notepad++ ist Geschichte. Die Compilerwarnungen sind auch fast weg. Parallel habe ich bereits angefangen den Schaltplan zu vervollständigen und schon mal die ersten Bauteile auf der Platine zu positionieren. Halbe Eurokarte wird eng, zumal der Leistungsteil noch nicht enthalten ist.

26.08.17: CodeBlocks als IDE installiert

Aus der Microcontroller Programmierung ist man etwas verwöhnt, da gibt es eine vernünftige IDE um zu Programmieren. Gesucht gefunden ?

Ich weiss es noch nicht. Da ich die eigentliche Programmierung unter Windows mache habe ich mir auf dem Raspi Samba installiert und habe dann das Projektverzeichnis für Notepad++ freigegeben. Das ist natürlich keine wirklich tolle Lösung und Notepad++ ist keine IDE.

CodeBlocks ist für Linux und für Windows verfügbar. Meine Lösung ist jetzt folgende. CodeBlocks läuft auf dem raspi und die Bildschirmausgabe erfolgt auf Windows. Das ist möglich durch den installierten X11 Server XMING. Da ich sowieso einen Zugang über Putty brauche kann ich auch noch das X11Forwarding einschalten in der Putty Session und schon kommt die Umgebung auf den Windows Bildschirm. Was ist jetzt besser?

Erst einmal hat man jetzt alle Features die eine solche IDE bietet und zum anderen ist die Projektverwaltung mit allen Files und compilieren, ausführen, …. angenehmer und einfacher. Zur Fehlersuche steht innerhalb der IDE auch der Debugger zur Verfügung.

22.08.17: Kamera ist gekommen

Die bestellte Kamera ist heute gekommen.

20.08.17: Strukturelle Anpassung im Programm

Damit der Code etwas lesbarer wird habe ich jetzt auch die Source File gespilttet. Dazu gibt es jetzt für jedes Modul ein eigenes File. Das macht die Entwicklung einfacher und das eigentliche Programm lesbarer.

Ich bin auf der Suche nach einer entsprechenden IDE. Gefunden habe ich bereits ein paar aber in der Konstellation das alles auf dem RasPi läuft nur die Softwareentwicklung auf der Workstation unter Windows läuft ….da hab ich noch nicht die Lösung gefunden. Muss noch etwas probieren. In der Übergangszeit geht es wohl auch mit Notepad++

Was den SPI Bus und die Erweiterung angeht mit dem MCP23S17 bin ich einen deutlichen Schritt weiter. Für den temperatur Sensor TC77 habe ich jetzt die Anpassung mit dem PIO gemacht und das läuft auch. Jetzt muss das vereinheitlicht werden.

Im Hauptprogramm habe ich vorgesehen das es einen Scheduler gibt der alle 1, 5, 15, 30 und 60 Sekunden läuft. In diesen Sektionen können Programmteile gelegt werden die nicht so oft aufgerufen werden müssen. (z.B. Logging, Temperaturabfrage, ….)

17.08.17: Nochmal der Port Expander für SPI

Nachdem ich den MCP23S17 nicht ans laufen bekommen habe und immer wieder nach dem Fehler suchte habe ich ihn nun endlich gefunden … ein Bit im ICON Register war leider falsch gesetzt und kaum macht man es richtig, geht es.Manchmal benötigt man etwas Abstand von der Sache und einen neuen Anlauf.

Das Ergebnis ist nun, weitere 16 CS Leitungen stehen für Geräte am SPI Bus zur Verfügung. Das sollte erst einmal reichen. Die Routine ist jetzt nutzbar und es müssen noch ein paar Marcos in C definiert werden. Mit diesem Modul wird jetzt eines der CS Leitungen für den Port Expander verwendet und eine CS Leitung ist noch frei für mögliche Erweiterungen.

Der nächste Schritt ist nun, die bestehenden SPI Module so umzuschreiben, dass die CS Leitungen des Port Expanders verwendet werden. Das sollte eigentlich reine Fleißarbeit sein und Probleme sollten hier jetzt nicht bei auftauchen.

26.5.17: Port Expander für SPI

Nach einer Nacht drüber schlafen ist es jetzt klar wie es weiter geht und mehere Geräte am SPI Bus angesprochen werden können. Der Weg über eine Daisy Chain soll erst einmal ausgeschlossen werden. Bleibt also für jedes Device eine eigene CS Leitung zur Verfügung zu stellen. Der Raspi hat zwei CS Kanäle. Am CS0 kommt jetzt ein Port Expander und der schaltet vor der Übertragung das richtige Device ein. Dann wird die Übertragung CS1 gemacht und danach am Port Expander wieder der CS auf HIGH gelegt. Als Port Expander wird die 16 Kanal Varainte genommen, dann können die nicht genutzen Ports ggf. auch noch anders verwendet werden.

Dann geht es weiter mit den Devices am Bus. Ich habe noch einen TC77 Temperatursensor hier liegen. Der sollte recht schnell verdrathet sein und dann kann die Software dazu geschrieben werden.

So ganz ist das Thema PIC noch nicht vom Tisch. Der PIC hat einige devices on board und könnte gute Dienste leisten, zumal er dann auch programmierbar währe und ebenfalls über SPI kommunizieren kann. Damit könnte man sich auch einige einzelne Geräte sparen. Bleibt auf jeden Fall im Hinterkopf.

TC77 (Temperatur Sensor) ist online

Gesagt, getan – der Temperatursensor ist ONLINE. Mit ein paar Käbelchen angeschlossen und etwas Programmierung verrichtet er schon seinen Dienst. Dabei hatte ich noch ein Fehler in der SPI Routine gefunden. Diese hat zwar den Wert der über MISO gesendet wurde gelesen aber leider nicht korrekt zurückgegeben. Jetzt passt es und ich weiss das die Temperatur in der Bastelbude jetzt 20.1 Grad ist.

24.5.2017: SPI Bus und Programmiersprache

Nachdem ich mich nun an Python versucht habe, weil das ja die Programmiersprache ist die besonders mit dem Raspi klar kommt und es hier bereits einige Libraries gibt, muss ich mir eingestehen – wir werden wohl keine Freunde. Die Alternative ist C. Wie schaut meine Umgebung jetzt aus?

Der Raspi hat nun erst einmal im Netzwerk seinen Platz gefunden, das Projektlaufwerk gibt er jetzt auch mit Samba an Windows Rechner frei. Damit ist das schreiben von Programmen einfacher – ich nutze gern einen anderen Editor als VI oder nano, oder …. Notepad++ ist deutlich angenehmer.

Das was ich unter Python nicht hinbekommen habe ist unter C dann doch erheblich angenehmer. Die strukturelle Schreibweise in C (oder gcc) liegt mir mehr und auch das es kein Interpreter, sondern ein Compiler ist passt mir auch. Unter Python hatte ich Programmabbrüche die ich nicht erklären konnte und … Schluss damit, ist nicht meins!

Unter C nutze ich wiredPi. Das geht super und jetzt habe ich den SPI Bus exemplarisch angeschlossen. Auf einem LCD (DOGM-162) wird jetzt die aktuelle Uhrzeit und Datum ausgegeben. Für das Troubleshooting ist nun der LogicAnalysator und das DSO mit aktueller Software nutzbar. Im Bild ist ein Screenshot vom LogicAnalyser. Macht richtig Spaß mit dem Kleinen am EKG 😉

Jetzt ist erst mal nachdenken angesagt. Von Haus aus hat der SPI Bus 2 CS Leitungen. Jetzt müsste ich mal überlegen wie die Erweitert werden sollen und dann auch von der Software unterstützt wird.

Nachdenken = schlafen. Gute Nacht

15.5.17: Struktureller Aufbau vom Programm

Hier mal ein paar strukturelle Überlegungen zum Programm:

Das Programm wird beim start des Raspi über den Runlevel gestartet als Daemon, also als Service und läuft im Hintergrund. Eine Kommunikation mit dem Programm über eine Tastatur ist nicht vorgesehen. Wenn eine Kommunikation stattfinden soll, dann muss diese über ein Interface (Netzwerk oder Datei) erfolgen.

Jede Funktion beendet sich automatisch und wartet niemals auf eine Eingabe. Das ist notwendig um ein hängen bleiben der Software zu vermeiden.

Zeitkritische Themen werden mit Interrupts bearbeitet. Das ist noch eine besondere Baustelle da Linux kein Echtzeit OS ist und nicht garantieren kann das ein Timer zu einer korrekten Zeit ausgelöst wird.

Das Hauptprogramm läuft in einer Endlosschleife und steuert die nicht zeitkritischen Themen vom logischen Ablauf. Zeitkritische Themen werden vom Timer Interrupt als ISR (Interrupt Service Routine) aufgerufen.

Sektionen im Programm:

  • Interpreter
  • Hinweise zum Autor, Version, Historie
  • Bibliotheken die eingebunden werden
  • Globale Variablen
  • Funktionen
  • Hauptprogramm (endlos)

Ein wichtiger Punkt ist wie Programmteile parallelisiert werden. Bei Microcontrollern wird das unter anderem mit Timer Interrupts gelöst. Ich habe eine Idee wie das unter Linux gemacht werden kann, ist aber nicht so komfortabel wie beim Microcontroller und lage nicht so genau, noch so schnell. Hier jetzt der Quellcode:

13.5.17: Erste Inbetriebnahme und Entwicklungsumgebung

Der Raspberry Pi Model 3 und das Gehäuse sind in der letzten Woche eingetroffen. Das OS ist installiert und das kleine System läuft seit ein paar Tagen im hauseigenen Netzwerk ganz gut und stabil.

Gestern habe ich ein paar Dinge für die Peripherie bestellt. Erstaunlicherweise kann man bei Amazon hier recht viele Dinge bestellen bei denen es einfach nicht mehr lohnt diese selber zu bauen.

Bestellt habe ich:

  • Expansion Board + Anschlusskabel an den Pi
  • IO Expander

Damit ist zumindest erst einmal die Kommunikation mit der Außenwelt über den GPIO möglich. Der Zugriff auf den GPIO Port in dem Gehäuse ist doch etwas verwinkelt und klein, mit dem Anschlusskabel ist das dann alles auf der Werkbank einfacher und mit dem Breadboard flexibler.