Samstag, 17. Januar 2015

DHT22 an langem Anschlusskabel

Lieber Entwickler,

im unserem zukünftigen EFH sollen Temperaturen und Luftfeuchtigkeit mit preiswerten DHT22-Sensoren gemessen werden. Ich möchte dabei auf dezentrale Intelligenz verzichten und die Sensoren möglichst direkt an die zentrale Steuerung anschließen. Fraglich war für mich, ob die Datenübertragung über ein langes Kabel möglich ist. Dazu habe ich heute einen Test mit 50m CAT5-Kabel gemacht.

Bereits vor einiger Zeit habe die die Sensoren in meinem Blog vorgestellt. Das Bild unten zeigt meinen Testaufbau.


Die "Zentrale" wird vom STM32F4-Discovery gemimt. Zwischen den PullDown-Widerständen rechts (2x10k parallel, um die überall empfohlenen 4,7k näherungsweise zu erreichen) und de DHT22 links hängen ca. 50m CAT5-Kabel. Mein Testcode prüft nach jedem Auslesen, ob der CRC passt. Selbst nach 30 Minuten "Dauerbetrieb" incl. Störung durch einen direkt daneben laufenden ollen Heizlüfter und Handy-Downloads waren keine Probleme zu beobachten.

Happy Coding!


Montag, 5. Januar 2015

CAN-Bus mit dem STM32

Lieber Entwickler,

zunächst wünsche ich Direin gutes und gesundes neues Jahr 2015!

Bereits seit geraumer Zeit muss man beim Lesen dieses Blogs den Eindruck gewinnen, ich sei untätig um Kontext vom STM32. Doch das Gegenteil ist der Fall. Nachdem meine Frau und ich mittlerweile einem Architekten den Auftrag zur Planung unseres EFH gegeben haben, entwickele ich häufiger als zuvor. Der Grund: Unser EFH soll "automatisiert" werden und der STM32 wird eine zentrale Rolle spielen...
 Ich habe mich für eine semi-zentrale Architektur des Automationssystems entschieden. Das bedeutet, es gibt einen singulären Master, über den (fast) alle Informationen fließen. Bestimmte Funktionen sind jedoch primär aus Verdrahtungsgründen ausgelagert. Diese Funktionsbausteine müssen über eine geeignete Kommunikationsschnittstelle mit dem Master verfügen. Ich habe mich hier für CAN (http://de.wikipedia.org/wiki/Controller_Area_Network) entschieden aus den folgenden Gründen:

  • Kann Daten über ausreichend große Distanzen transportieren.
  • Multimaster-fähig
  • Nachrichtenorientiert
  • Adressierung im Protokoll integriert
  • Wählbare Bitrate (je niedriger die Bitrate, desto länger darf das Kabel werden)
  • Verfügbar sogar auf dem billigen STM32F103
  • Günstiger PHY (Sample-Bestellung den SN65HVD230 bei TI :-))
  • Sehr schönes Programmiermodell auf dem STM32
  • Viele andere Hausbus-Ansätze nutzen auch den CAN-Bus als Basis

Als einziger Nachteil könnte angesehen werden, dass maximal 64bit Daten pro Nachricht übertragen werden können. Nun ja, 8 Byte sind tatsächlich nicht viel, aber für den hier besprochenen Anwendungsfall genügt das vollauf. Im Bedarfsfalle müssen höhere Protokollschichten eben eine Aufteilung von Daten vornehmen.

Zum Testen habe ich mir gleich einen einfachen Anwendungsfall ausgedacht. Die Hausautomations-Zentrale sendet an einen dezentralen Aktor Befehle zum Ein- oder Ausschalten von Relais. Die Funktion derZentrale wird vom STM32F4-discovery-Board übernommen; der dezentrale Aktor ist ein STM32F103-Board. In einem ersten Versuch - vor der Ankunft der SN65HVD230  - habe ich die hier (http://www.keil.com/download/files/canprimer_v2.pdf) auf Seite 4 veröffentlichte Schaltung verwendet, um die beiden Boards zu koppeln. Funktionierte!

Nun kamen heute die SN65HVD230 an. Ich lötete diese zusammen mit einem Slope-Control-Widerstand (10k) und dem Busterminator (120R) auf ein DIL-Adapter und verkabelte die Boards mit Hilfe von Steckbrettern Ein Foto meines Aufbaus siehst Du unten.

Auf dem Steckbrett ich von anderen Experimenten noch etwas "Hühnerfutter" zu sehen, das uns jetzt aber nicht interessieren sollte. Spannender ist, womit ich die beiden SN65HVD230 miteinander verbunden habe: Tatsächlich sind das 305m Kabel (CAT5), die zwischen den beiden Transceivern liegen. Bei 125kBit/s funktioniert die Übertragung problemlos! Wahnsinn!

Den Code für den 103canrelayswitch und den 407homeautomation findest Du im SVN unterhalb von https://code.google.com/p/stm32tutor/ Insbesondere im 407homeautomation ist schon einiges anderes implementiert, das aber durch die Endlosschleife im CAN-Experiment erstmal ausgeblendet ist. Die entscheidende Codestelle im 407homeautomation ist in der main.c-Datei die Funktion CAN_Polling(void). Diese bereitet im 500ms-Rhythmus eine Nachricht an den 103canrelayswitch vor und versendet diese. Im 103canrelayswitch spielt die Musik in der Datei stm32f10x_it.c und zwar in der Funktion USB_LP_CAN1_RX0_IRQHandler(void). Es handelt sich hierbei um den Interrupts-Handler des CAN-Busses. Beim 103 greifen CAN und USB chipintern auf die gleichen Ressourcen zu. Am Namen des Interrupt-Handlers ist erkennbar, dass dies auch für Interrupts gilt.  Insbesondere können USB und CAN nicht gleichzeitig benutzt werden. Die seltsamen Operationen vor dem Setzen der GPIOx->ODR-Register dienen dazu, dass die Anschlüsse des Boards in der physischen Reihenfolge angesprochen werden können.



Happy coding!