[ µController-Netzwerk ] Ideensammlung - RPi mit µController verheiraten

Heute ist Stammtischzeit:
Jeden Donnerstag 20:30 Uhr hier im Chat.
Wer Lust hat, kann sich gerne beteiligen. ;)
  • So, nun sind wir mal wieder so weit.

    Für die Kommunikation zwischen RPi und µC, brauche ich eine Art Verbindungsmanager.

    Das Ganze wird wohl zunächst ziemlich rudimentär ausfallen, aber einiges dabei ist mir noch nicht klar, und da es noch genügend anderes zu tun gibt, wäre es hilfreich wenn der eine oder andere von Euch da vielleicht einen Einwand, eine Idee oder einen weiteren offenen Punkt beisteuern würde.
    Alles was ich als kritisch oder offen im Hinterkopf behalte, lässt sich berücksichtigen oder lösen. Alles was sich erst im Nachherein rausstellt ist ein Problem.

    Also:
    In meiner Vorstellung repräsentiert sich das Ganze wie ein Netzwerk, vergleichbar mit dem Internet oder dem Heimnetzwerk.
    In diesem Netz exisitieren einzelne "µNodes" - also Knotenpunkte, wobei es jetzt erst einmal egal ist, ob es sich dabei um einen µController, einen RPi oder einen Sensor handelt.
    Jede dieser µNodes hat einen Namen und eine eindeutige Id.
    Zusätzlich gibt es Informationen darüber, wie diese µNode erreichbar ist.

    Beispiel lokaler Modus:

    µNode Name "Temperatur_Gewächshaus"
    µNode Id 0x1fddffee7866
    µNode Type Sensor
    µNode Master "local"
    µNode Master Id 0x45678

    Nun weiss ich, dass dieser Sensor über die Master µNode "local" erreichbar ist, und dass es sich um einen Sensor handelt.

    In einer Verbindungstabelle steht jetzt wiederum
    µNode Id 0x1fddffee7866
    µNode Address 0x123456
    µNode Connection 1Wire

    Und damit kann ich vom lokalen RPi den Sensor mit der Adresse 0x123456 über 1Wire abfragen.


    Beispiel remote Modus:

    µNode Name "Temperatur_Orchideen"
    µNode Id 0x1fddffee7788
    µNode Type Sensor
    µNode Master "Garten"
    µNode Master Id 0x4567899


    µNode Name "Garten"
    µNode Id 0x1fddffee7998
    µNode Type ATMEGA16
    µNode Master "local"
    µNode Master Id 0x1fddffee7998

    Nun weiss ich, dass dieser Sensor über die Master µNode "Garten" erreichbar ist, und dass "Garten" ein ATMEGA16 ist.

    In einer Verbindungstabelle steht jetzt wiederum

    µNode Id 0x1fddffee7788
    µNode Address 0x47
    µNode Connection I2C

    µNode Id 0x1fddffee7998
    µNode Address 0x01
    µNode Connection rs232

    Jetzt weiss ich, dass der MEGA16 am seriellen "Bus" hängt und dass ich ihn über die Addresse 0x01 erreichen kann.
    Und damit kann ich der µNode "Garten" die Aufforderung schicken, über I2C den Sensor mit der Slave Addresse 0x47 auszulesen.

    Bis hierher denke ich, ist alles so weit klar und ich glaube, ihr könnt auch noch folgen.

    Für eine rudimentäre Verbindung reicht das alles erstmal aus.
    Am elegantesten ist natürlich eine Verbindung per TCP/IP, weil da keine Rumhampelei notwendig ist.
    Aber die meisten anderen Verbindungen gestalten sich etwas problematisch.
    USB und RS232: da gibt es die Möglichkeit verschiedener Bezeichnungen und eine Verbindung mal umzustecken.
    Wenn ich mir jetzt /dev/ttyUSB0 für eine Verbindung merke und dann aber der das kabel auf z.B. /dev/AMA0 umgesteckt wird, greife ich ins Leere.
    Das kann man durch manuelles Editiieren lösen ... besser wäre eine Automatik ;)

    So, nun wäre es, wie gesagt, schön, wenn der eine oder andere sich da mal äussern würde. Auch wenn keine Programmierkenntnisse vorhanden sind, dann sind Tipps die vom gesunden Menschenverstand herrühren, sicher auch sinnvoll.
    Ich hab' sicherlich noch irgendwas übersehen, vergessen oder nicht berücksichtigt.


    Ich wünsche Euch noch einen schönen Tag,
    -ds-

  • [ µController-Netzwerk ] Ideensammlung - RPi mit µController verheiraten? Schau mal ob du hier fündig wirst!

  • Ich habe jetzt mal eine - im Moment noch wirklich grobe - Konzept-Idee zusammegefrickelt.
    Absolute Alpha ... aber ich werde das so nach und nach übrarbeiten.

    Ich habe zudem ein Repo auf github angelegt: das ist hier erreichbar.
    Dort werde ich neben der Doku auch die entstehenden Sourcen ablegen.
    Natürlich werden diese Files auch weiterhin hier als Anhänge verewigt, aber so eine zentrale Sammelstelle ist im Augenblick da glaube ich zielführender.

    Im Anhang also dann mal der erste Draft ...
    bis später mal,
    -ds-

  • ... und da bin ich schon wieder. Die "Nägel mit Köpfen" Phase hat begonnen ;)

    Ich will mal grob skizzieren, wie ich es machen würde. Der Aufbau wäre wie eine Firma mit Chef (RPi), leitenden Angestellten (uCs) und deren Untergebenen (Sensoren, etc.) - also "wia im richtign Lebn" ;)

    Wirklich intelligente Bauteile sind nur uCs, deswegen lasse ich die anderen (Sensoren & Co) für den direkten Betrieb am RPi erstmal weg (kann man ja später noch drüber nachdenken, aber bei uC Preisen ab ca. 80 cts. - warum soll sich da der Chef noch kümmern?

    Der Ablauf sähe dann so aus:

    Init:
    - Bus abfragen, wer alles da ist (mögliche Ausfälle sind so leicht festzustellen). Diese Routine sollte man immer wieder mal aufrufen - könnte ja sein, daß sich jemand aus dem Staub gemacht hat oder sogar die ewigen Jagdgründe vorzieht ;)

    - anhand der nun vorliegenden Adressen auf dem Bus ist dem RPi eine Zuordnung anhand von tags wie z.B. "Garten", "Küche", "Heizung" etc. möglich, also ein Soll <-> Ist Vergleich. Die jeweilige Adresse ist einer ID gleichzusetzen.

    - jetzt werden alle ID's (also alle uC's) der Reihe nach abgefragt und sie antworten anhand einer zu vereinbarenden Syntax, was sie können (z.B. Temperatur, Bewegung, Luftdruck, Helligkeit, etc.). Es können für gleiche Aufgaben wie z.B. Temperaturmessung die unterschiedlichsten Sensoren eingesetzt werden. Nur dem jeweiligen uC ist bekannt, mit welcher Art Sensor er arbeitet, sein Programmodul ist individuell darauf zugeschnitten. Er prüft, ob die jeweiligen Sensoren einsatzbereit sind und meldet dem Chef (=RPi) Ausfälle. Der Chef weiß somit, was funktioniert und was nicht.

    main loop:
    Weitgehendst standardisierte Abfragen und Antworten an die/von den uCs, auf die Details will (und muß ich) jetzt gar nicht weiter eingehen, Du weißt ja, was ich meine.

    ----------------------------------------------------------------

    Das wäre mein Konzept für die erste Ausbaustufe. Mir ist diese Dezentralisierung lieber: Die Probleme sollen dort behandelt werden, wo sie entstehen - also bei den uCs.

    Wenn das läuft, kann man über Komfort wie Sensordatenbank mit code snippets, Programmierautomatik für die uCs etc. nachdenken - das wäre ohnehin ein extra Programmpaket.

    Für eine professionelle Buslösung würde ich RS485 (wie von orb schon erwähnt) vorziehen - mit welchem Aufwand das zu realisieren ist - da hab ich mangels Erfahrung auch keine Ahnung. Ein TCP Protokoll direkt auf dem Atmel ist natürlich nix, eher wäre dann zu überlegen, statt RS485 gleich Ethernet zu verwenden. Es bleibt halt die Frage, wie teuer es werden darf. Dann doch lieber gleich auch noch LWL. ;)

    cu, mmi

  • Ja moin moin, mmi :) ....

    hmmm ... kann es sein, dass ich Dich ein wenig angefixt habe ;) ...

    Deine Idee mit der Dezentralisierung behalte ich mal im Hinterkopf und nehme sie bei nächster Gelegenheit in die Doku auf.
    Die habe ich übrigens überarbeitet. Sie ist jetzt kein Mischmasch aus Doku und Forum mehr. Ausserdem sind einige Dinge schon ziemlich konkret beschrieben. Ich häng sie mal hier an. Auf github ist sie auch schon aktualisiert.

    Wie gesagt, die Dezentralisierung muss ich mir mal überlegen. Ich möchte halt den Code auf den µControllern so einfach wie möglich halten. Das erleichtert m.E. später das Generieren der Sourcen.

    Apropo Sourcen. Die häng ich auch mal an. Allerdings lohnt es sich noch nicht, die auch auf github hochzuladen.

    Nun, in diesem Sinne viele Grüsse mit Morgengrauen ... äh aus dem Morgengrauen,
    -ds-

  • MoinMoin! *staun* - diese Zeit war ja bisher immer mir vorbehalten.

    Naja, richtig angefixt hast Du mich nicht, noch weiter in die Tiefe des Projekts lasse ich mich nicht mehr ziehen.

    Sicher hat die Dezentralisierung auch ihre Nachteile, aber an erster Stelle steht der sichere Betrieb mit schneller Fehlererkennung - deshalb würde ich diese Lösung vorziehen - da hat man kurze Reaktionszeiten, Fehler werden selbst bei einem großen Netzwerk schnell erkannt, der RPi muss nix pollen, etc.

    So schön das vorgesehene, ich nenne es mal "autocoding", auch sein mag - es wird bei komplizierteren Anwendungen eher nicht die "eierlegende Wollmilchsau" werden. Rein aus meiner Erfahrung gesprochen, aber Du kannst mich ja vom Gegenteil überzeugen. ;)


  • Deine Idee mit der Dezentralisierung behalte ich mal im Hinterkopf und nehme sie bei nächster Gelegenheit in die Doku auf.

    Nun, in diesem Sinne viele Grüsse mit Morgengrauen ... äh aus dem Morgengrauen,
    -ds-

    hallo ds,

    ich bin auch angefixt, unabhängig von der Dezentralisierung,

    mein jetziger Atmel spielt ja Webinterface und hat die AD Wandler und Ports onboard.
    da der PCF AD / DA Wandler hier alleine recht teuer ist, warum nicht einen mega AT nutzen, Ports und AD inclusive und günstiger. Die Anbindung als I2C slave wäre ja möglich, nur wie programmieren ?
    Ich denke per SPI vom PI.

    Hast du schon den Weg aus dem AVR Studio die Hex über PI in den Atmel zu bekommen ?

    LG jar

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Hallo zusammen,

    @mmi:
    Hallöchen mmi,
    wie gesagt ... das Thema Dezentralisierung nehme ich mit auf und steck es in meinen geistigen Brutkasten ;) ...

    Wenn Du meinst, Du willst da nicht tiefer einsteigen, dann ist das eben so. Hauptsache Dein AVR-KnowHow bleibt für mich abrufbar :) ...
    Trotzdem sind Deine Tipps und Hinweise, wie auch die von anderen Teilnehmern, für mich hilfreich und informativ.
    Und wenn sich konkrete Probleme oder Fragen ergeben, melde ich mich schon ;)

    Und was die "Autocoding" von µController-Programmen betrifft:
    Ich bin zwar ein bisschen verrückt aber nicht größenwahnsinnig.
    Ich denke, es würde als Fernziel schon ausreichen erstmal eine Schleife mit Abfragen der Sensorwerte auf Anfrage zu realisieren.
    Von einer kompletten Hochregal-Steuerung auf Knopfdruck war nie die Rede.
    Aber ich nehme mir Deinen Hinweis gerne zu Herzen. Vielleicht ist ja das Fernziel schon viel zu hoch gesteckt ...

    @all:
    Apropo Sensorwerte: ich habe mir überlegt, dass ja genau so z.B. ein Relais per Fernsteuerung geschaltet werden kann und habe neben den Sensoren noch Actoren als mögliche µNodes eingebaut.
    Die Verbindungs-Informationen sehen jedenfalls erst mal gut aus. Bis auf die unterste Ebene - da bin ich mir nicht so sicher. Aber das wird sich zeigen, wenn ich mal den ersten Admin- und Master-µNode realisiert habe.
    Als Standard-Verbindung werde ich wohl die RS485 wählen. Aber manchmal ist das leider nicht möglich.
     
    Die TODO-Liste bis zum ersten, rudimentären Prototypen ist nicht mehr all zu lang.
    Allerdings sind noch einige andere Punkte in späteren Stufen offen bzw. ungeklärt.
    Sie gehen zwar aus der aktuellen Doku auf github oder hier in Posting #24 hervor, aber ich poste sie trotzdem mal.
    Vielleicht mag der eine oder andere mir ja ein wenig Arbeit abnehmen.

    So, nun ist erst mal gut.

    Ich wünsche Euch allen einen schönen, erfolgreichen Tag,
    -ds-

    hallo ds,

    ich bin auch angefixt, unabhängig von der Dezentralisierung,

    ... warum nicht einen mega AT nutzen, Ports und AD inclusive und günstiger. Die Anbindung als I2C slave wäre ja möglich, nur wie programmieren ?
    Ich denke per SPI vom PI.

    Hast du schon den Weg aus dem AVR Studio die Hex über PI in den Atmel zu bekommen ?

    LG jar

    jar
    ja hi jar, alter Berliner ;) ...
    naja ... ist schon eine reizvolle Herausforderung :) ...

    @all
    Den MEGA16 bzw. irgend einen µController quasi als Erweiterung des RPi ist ja Sinn und Zweck der Übung.
    Zum Flashen der Hex-Files nutze ich mein STK500 Board. Das ist per RS232 verbunden, wird von avrdude und Luna Avr unterstützt und verfügt über einen ISP-Anschluss.
    Ich wollte ja weg vom Redmonder OS.

    Einen AVR per SPI vom RPi aus zu programmieren ist in der Tat machbar und scheint wirklich nicht so kompliziert. orb hatte mir in diesem Thread einen Link zu einer entsprechenden Anleitung gepostet. Das ist mt ein Grund, warum ich diese Code-Generator Geschichte beibehalten habe.

    Alternativ dazu wäre dieses Miniboard vielleicht interessant. Da sitzt ein MEGA32 drauf und alle Pins sind rausgeführt.
    Der Clou dabei: angeblich soll es möglich sein, den AVR über USB zu programmieren. Passende Windows-Software gibts zum kostenlosen Download.
    Leider kann ich das jetzt nicht mehr verifizieren oder ausprobieren, weil ich den MEGA32 über ISP komplett platt gemacht habe.
    Weil ich keine Lust hatte herauszufinden, mit welchem Programmer dieses Board kompatibel ist um avrdude nutzen zu können, hab ich halt einfach die ISP-Schnittstelle genutzt.

    Das AVR-Studio verwende ich derzeit nicht. Mein aktueller Favorit heisst bis jetzt noch LunaAVR. Das ist eine aus meiner Sicht hervorragende IDE zur Software-Erstellung für AVR-Controller. LunaAVR bringt zwar eine eigene, objektorientierte Sprache mit, die ist aber klar und logisch und daher ziemlich eingängig.

    So, nun fällt mir erst mal nichts weiter ein.

    Viele Grüsse aus dem Süden mit seinem strahlend blauen Himmel,
    -ds-

  • Zitat


    Der Clou dabei: angeblich soll es möglich sein, den AVR über USB zu programmieren.


    Wenn man im AVR den entsprechenden bootloader hat der das regelt, sollte es kein Problem sein. So ist es ja auch beim Arduino realisiert.

  • Jain.
    Die Arduinos benutzen einen USB-Seriell-Wandler, das kleine Board einen Bootloader der eine Art Software-USB stellt. Die ist aber nicht wirklich USB-Kompatibel und läuft nicht mit jedem Rechner stabil. Es gibt schon Probleme mit Arduinos die einen Mega8 mit VUSB als Wandler auf die serielle Schnittstelle benutzen.


  • Das heisst aber noch lange nicht, dass jetzt hier Schluss ist.
    Ideen, Anregungen, Einwände zur Umsetzung bitte weiterhin hier.
    Thnx,
    -ds-

    ich warte auch die Fernprogrammierung der AVRs über SPI vom PI optimal aus AStudio :blush:

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)


  • ... für das µNode-Netz. Mein Lieber, da hab' ich mir was vorgenommen icon_eek.gif

    Das ist bei der gewünschten Flexibilität (sprich: eierlegende Wollmilchsau) ein Mordsprojekt. ;)

    Das erste Ziel (Atmel-Programmierung mit dem RPi) hast Du mit
    https://www.forum-raspberrypi.de/Thread-tutoria…C2%B5controller
    ja schon erreicht.

    Wenn das noch etwas kompakter wird, wäre für eine erste Ausbaustufe schon viel erreicht:

    1. Atmel Hardware an RPi anschliessen
    2. Atmel Software in C schreiben
    3. Compilieren
    4. Programmierung des Atmel mit "avrdude"

    Für die Punkte 3 + 4 wäre ein entsprechend komfortables Script super:
    "script quellcode.c" und ein paar Sekunden später läuft's auf dem Atmel :)

    Für komplexere Anwendungen kann man sich ja eine eigene IDE je nach Belieben zusammenstellen und ruft im Script dann nur die Programmierroutine auf.

    Kurz gesagt:
    Es sollte für jedermann so einfach wie möglich sein, ein simples Atmel C-Programm zu erstellen und den uC zu programmieren, ohne sich mit den umfangreichen Spezialitäten des avr-gcc bzw. von avrdude intensiver auseinandersetzen zu müssen.

    Gruß, mmi

  • Ich habe so etwas ähnliches vor und will es mit zigbee umsetzen, da industriestandard, gute reichweite, wenig stromverbrauch. Problem is nur der Preis für ein Modul und das es eher zur Kommunikation geeignet ist nicht für große Daten da Übertragung im kb Bereich

    Einmal editiert, zuletzt von dude-awesome (15. September 2013 um 19:19)

  • Hallo dude-awesome,

    zigbee ist nach meinem Verständnis (ich hab jetzt nur mal kurz drübergelesen) auch nichts anderes als überwiegend WLAN bzw. WLAN über 2,4 GHz.
    Das Problem ist ja, wie aufwändig falls überhaupt möglich es es ist, einrm µController das Reden über eine solche Schnittstelle beizubringen.
    Da wäre RS485 optimal ... das könnte out of the box funktionieren.
    Allerdings wird das evtl. wieder kompliziert wenn es um (asynchrone und) bidirektionale Kommunkikation geht.

    cu,
    -ds-

  • PI & AVR verbinden mache ich mit RS232 und 2 China MAX3232 Module dann entfällt auch das 3.3V zu 5V Problem

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

  • Wie meinst du das, kann doch RxD und TxD verschalten dann reden
    beide miteinander

    PS sitze auf der Terrasse und tippe auf dem HTC

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (15. September 2013 um 21:14)

  • Oder i2c oder onewire, aber dann an Pegel denken

    echte RS232 ist da schon im Vorteil

    lasst die PIs & ESPs am Leben !
    Energiesparen:
    Das Gehirn kann in Standby gehen. Abschalten spart aber noch mehr Energie, was immer mehr nutzen. Dieter Nuhr
    (ich kann leider nicht schneller fahren, vor mir fährt ein GTi)

    Einmal editiert, zuletzt von jar (15. September 2013 um 21:19)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!