AVR NEt IO & ethersex firmware

Hallo Boui,

wenn Du noch nicht angefangen hast, würde ich mir die neueste Version mit dem Befehl „git pull origin“ ziehen. Ansonsten gilt, wenn Du eine lauffähige Version hast, die alle deine Anforderunge erfüllt, bleibt dabei. Erst wenn neuere Features eingebaut werden, die Du auch brauchen könntest, in ein Testsystem laden und weiter sehen.

Anbei der Link zu den Installationshinweisen:
Voraussetzungen - zerties.org

Am einfachsten ist es aber, wenn Du in eine virtuelle Maschine die Live-CD installierst. Da ist dann auf dem Ubuntu schon alles drauf (AVR-Compiler, Sourcen, …), was man zum Erstellen einer Ethersex Firmware braucht. Ist zwar nicht mehr das neueste Ubuntu, aber was solls, zum Compilieren taugt es. Live CD - zerties.org

Gruss
Bernd

Hi Bernd,

danke, dass Du mich schon mal auf den Sattel gehoben hast. Ich teste mein Spielzeug mal am WE.

Hallo Boui,

ich habe auf der Ethersex-Homepage noch eine Link auf ein Videotutorial gefunden. Eventuell ganz hilfreich:
YouTube - Embedded Webserver für ca. 30 Euro (AVR Webserver) part 1

Zur Anbindung an IPS steht da aber nichts drin. Wenn Du den WEB-Server einmal am Laufen hast, ist der Rest nicht mehr sehr schwer. Das sind nur ein paar Zeilen PHP-ECMD-Code: Dallas 1-wire Bus - zerties.org

Gruss
Bernd

Ich glaube ich werde mich nun auch mit Ethersex und dem AVR von Pollin beschäftigen, wollte zwar zuerst was mit CAN machen, aber ist mir alles zu unausgereift :slight_smile:

und so nen AVR habe ich immerhin noch zwei rumliegen irgendwo.

Aber ne Frage, hat war bzw gibt es eine Möglichkeit, das der AVR Änderungen automatisch verschickt? Also ohne Pollen von IPS aus?

Und gibt es eine Möglichkeit ein Licht modul oder so zu installieren?
Also ich habe einen Taster, und bei jeder Änderung soll das Licht an/aus geschaltet werden, und der aktuelle Status an IPS übermittelt werden, aber das das Modul auch ohne IPS auskommt.

Gibt es da Möglichkeiten, wo suche ich da für sowas alles am besten?

(Bin gerade dabei die ISO CD zu installieren und auszupacken und upzudaten usw… sehe dann sicher auch mehr … falls hier fragen dabei sind, die sich dann automatisch klären, dann gleich mal sorry :slight_smile: )

Hallo sn00py,

ja, die Funktion gibt es. Ist einzustellen unter:

 Menuconfifg -> I/O -> (Full-featured) I/O abstract model (Port I/O)

und dann

Menuconfifg -> Applications -> Watch IO changes (and react) ->

hier muss dann eingetragen werden, was an welchem Port bei steigenden oder fallenden Flanken gesetzt werden soll. Anbei ein Beispiel:

ECMDTCP(PA1, RISING, 192.168.100.2 io set port0 0x01 0x01)

Sorry für aller anderen Forumsteilnehmer, wenn man das Ethersexprojekt nicht kennt, ist alles kaum zu verstehen. Ich wollte es hier nur sn00py zeigen, da ich mir damals einen Wolf danach gesucht habe.

Gruss
Bernd

Also glaub vieles kann man mit dem Control6 machen, da sollte sich die primitiven Lichtsteuerungen/pumpensteuerung machen lassen
und acuh gleich ein versenden von UDP Meldungen an IPS.

Hat das schon mal wer ausprobiert?

Mit Control6 habe ich bisher noch nichts gemacht. Die Logik läuft bei mir in IPS. Ich wollte aber schon lange mal beginnen einfache Tasks auf den AVR auszulagern. Dann läuft alles autonomer und das kommt meinem Prinzip eher entgegen. Logging von Messwerten auf SD und dann stündlich als Päckchen an IPS ist so ein Beispiel.

Die vorher beschriebene Variante mit Watch IO and react habe ich zumindest soweit getestet, dass ich am AVR einen Schalter betätigt habe und im Etherreal das dann auch mit der richtigen Zieladresse gesehen habe. Auf der IPS oder einem anderen AVR muß dann nur ein Socket offen sein, um dieses Paket aufzunehmen.

Gruss
Bernd

Danke icey, hab deinen vorletzten post erst im nachhinein gesehen :slight_smile:

Also ich glaub mit dem Control6 kann man vieles machen, soviel ich bisher gelesen habe …
Ich will einfach die wirklich primitiven funktionen wie drücke taster -> licht geht an - direkt im controller haben …

Hallo Bernd, was mache wenn mir menuconfig ein [-] anzeigt bei dieser Option?

Das gleiche habe ich auch beim bootloader … ?

Weisst du zufällig obs irgendwo Infos gibt, wann wo was einzusetzen ist?

Wenn eine Option nicht wählbar ist [-], liegt es in der Regel daran, dass eine notwendige vorherige Option nicht aktiviert wurde. Z.B. kannst Du bestimmte Applikationen nicht nutzen, wenn UDP nicht aktiviert wurde. Eine dirkete Übersicht habe ich auf der Ethersexpage auch noch nicht gefunden. Alles leider sehr empirisch, das ist bei dem Projekt aber auch das Problem :frowning:

Gruss
Bernd

Da ich mit denselben Fragen „kämpfe“:

  • gewisse Eigenständigkeit
  • aktives Melden bei IPS

werde ich mich wohl auch mit dem ESX-Projekt beschäftigen.

Eine wesentliche zusätzliche Frage, die ich habe - vielleicht kann die hier jemand beantworten:

Ich würde gerne mittels AVR-Net-IO auch die Serielle Schnittestelle via LAN „verlängern“, um damit im Heizraum eine einzige Platine zu haben, mit der ich einerseits Pumpen und Licht Steuern kann und andererseits auch mit der Heizungsanlage (Wärmepumpe Stiebel) via RS232 kommunizieren kann.

Ist im Ethersex solch ein „Modul“ drin oder nutzt es die RS232 nur zur Kommunikation PC <-> AVR?

Danke
jwka

Hallo, habe mich nun etwas beschäftigt mit E6, und auch dabei mit dem Control6, sieht sehr vielversprechend aus :slight_smile:

serielle schnittstelle kann es laut doku weiterleiten siehe YPort - zerties.org

die [-] Probleme habe ich mittlerweile auch schon rausgefunden :slight_smile:
Für den bootloader braucht man den nächst größeren ATMEGA (werde ich mir nächste woche gleich mal ordern, in verbindung mit zusäzlichen Boards :slight_smile: )

und das „Watch IO changes (and react)“ hätte ich auch schon aktiviert bekommen, allerdings werde ich gleich alles per CONTROL6 Script lösen …

Hast Du sowas wie ein „Protokoll“ oder „Things to be done“ zusammengestellt, das hier vielleicht mal zu veröffentlichen wäre?

Es würde dem einen oder anderen (u.a. mir) vielleicht die eine oder andere schlaflose Nacht ersparen.

Und noch ne Frage: MUSS ich denn mit Linux oder kriegtman das Ganze auch unter WinXP zum fliegen? Grundsätzlich habe ich das für das Pollin Board nämlich hier am laufen …

Danke
jwka

meinst du mich?

Also ich bin gerade erst beim Testen der ganzen einzelnen Komponenten vom E6, Control6, versenden per UDP, versenden per TCP usw. … sobald ich was habe, mit dem ich dann anfangen kann, werde ich mich melden :slight_smile:

Ich habe mir die Live CD in einer virtuellen Umgebung isntalliert - das klappt wunderbar - das flashen ist etwas mühseliger, da ich in der VM keinen Com port habe, und so immer das file zuerst auf meinen lokalen rechner kopieren muß, und von dort dann flashen muss - das ginge sonst auch automatisch …
(Es geht glaub ich auch auf WinXP, aber ist sicher nicht gerade einfach zu installieren, mit dem cygwin und co)

Aber bislang bin ich mächtig beindruckt von dem E6 samt Control6 und co …

Ich glaub es war die richtige wahl (hatte auch schon einige komponenten von iSysBus hier rumliegen - das wäre auf CAN Bus … aber so find ichs besser :wink: )

So, habe nun einiges rumgebastelt :slight_smile:

Ich habe mir mal überlegt, wie ich die Daten von Änderung möglichst schnell vom E6 zu IPS bekomme und mir sind vorerst mal folgende sachen eingefallen

[ul]
[li]Direkt per UDP
[/li][li]Direkt per TCP
[/li][li]ECMD UDP
[/li][li]ECMD TCP
[/li][/ul]

Direkt per UDP habe ich die befürchtung, das mit einmal Senden oft pakete verloren gehen, auf eine Rückantowrt zu warten und co ist mir zu komplex.

Direkt per TCP ist mir im Control 6 und co auch zu komplex, vorallem die Fehlerprüfung, falls mitten drinnen mal der Empfänger nicht mehr erreichbar ist.

ECMD UDP - Wartet automatisch auf eine Antwort vom empfänger, und verschickt bis zu 12 Mal die Paketem falls diese Antwort nicht ankommt.
Aber das problem ist, man kann maximal 1 Paket gleichzeitig senden, das nächste Paket kann erst dann wieder gesendet werden, wenn das vorherige abgeschlossen wurde (12 mal gesendet oder rückantwort erhalten) - die nächsten Pakete werden einfach verworfen.

ECMP TCP - Wartet auch auf die Antwort vom Empfänger - Vorteil gegenüber der UDP Varainte, es könenn bis zu 3 Pakete gleichzeitig versendet werden.

Daher habe ich mir für mich mal folgendes überlegt im contro6 Skript baue ich mir einen Sendebuffer zusammen, der sofort verschickt wird.
Muß im nächsten Zyklus wieder was versendet werden, dann wird das erst im SendeBuffer gespeichert, und erst nach 5 Zyklen dann an den PC versendet.

Wobei immer zuerst die Eingänge geprüft werden, und dann die Ausgänge (falls ein Eingang einen Ausgang schaltet, wird beides gleichzeit versendet)

Im Sendebuffer werden die Befehle (möglichst kurze) einfach per # getrennt.

Die Defaultmässigen PIN_RISING und co, werden nicht verwendet, da ich ein Softwaremässiges entprellen drinnen habe, zumindest bei Tastern und co, wobei bei Tastern SOFORT geschaltet wird also wenn die auf HIGH gehen, wirds sofort übernommen, und erst beim HIGH->LOW wird entprellt (muß dann xx zyklen anliegen damits übernommen wird)

Ein kurz/lang drücken benötige ich nicht

So das war m al kurz der Status :slight_smile:

Nun warte ich das pollin die AVR-Net Bausätze wieder Lagernd hat, damit ich für die produktiven bestellen kann.

Und der nächste schritt ist auch mal hardwaretechnisch zu überlegen wie ich die Taster die mit 230V beschaltet sind in den AVR-Net Eingang reinbekomme.

Auch einen ATMEGA 644 muß ich mir dann bei pollin besorgen, den ich will das System auf jeden Fall mit nem Bootloader ausstatten -> keine Lust später im Pool schacht oder wo auch immer mit dem Notebook rumzukrabbeln :wink:

Klingt gut, ich kann aber das Thema „Paket verloren“ bzw. sichere Übertragung nicht qualifiziert kommentieren, weil ich das Control6 usw. noch nicht kenne und damit auch nicht weiss, wie man wo eingreifen kann.

Ich hätte jetzt gedacht, dass man das Thema „Quittung“ einfach mit ner zusätzlich getimerten Routine abfangen kann und nach XX Zyklen schlicht das Paket wieder und wieder sendet.

UDP hat doch, wenn ich recht erinnere auch ne Sequenznummer, die man in einer Liste halten und aktualisieren kann? Kommt dann die Quittung des UDP Paktes zu spät, ist einfach ein zweites schon raus und die Quittung des vorherigen wird ignoriert (oder für das zweite schon mit verwendet)?

Man müsste dann in das Datenpaket ne eigene Sequenznummer einbauen und prüfen, ob man die schon mal empfangen hat. Wenn ja, ist nur ne Quittung zu schicken, wenn nein, ist der Datensatz auszuwerten.

Zusammen mit „Alive“ Messages, die regelmässig kommen, könnte dann auch eine Garbage Collection über Sequenznummern erfolgen bzw. sogar erkannt werden, welche Paket-Nummern verloren gegangen sind.

Im Sinne der Zuverlässigkeit wäre das ja eine relevante Info, denn wenn ich ne Device habe, wo viele Pakete verloren gehen, ist da ja auch ein Hinweis, dass da auf der Strecke was nicht stimmen kann.

Dass ein noch keine weitere Methode gibt, wundert mich ein bischen. Ich finde auch dass zwischen der „permanenten“ (Socket) und „zufälligen“ (UDP) Verbindung noch irgendwie was fehlt.

jwka

Ich glaub ich werde einen Teil der Intelligenz dann auch ins IPS auslagern, sowie die IsAlive Meldung - sprich ich werde einfach jede Minute dann per TCP/ECMD die aktuellen Ports und Temperatur und co (die ich nicht per Änderung haben will) nach mal validieren.
Da kann ich dann falls wirklich irgendwo irgendwie doch mal was verloren ging, den Status aktualisieren.

Für die ersten Versionen werde ich mich mal auf das ESEND bzw ECMD PRotokoll verlassen und mal schaun, wie es sich im Echtsystem dann macht (immer mit der Absciherung das ich jede Minute zu 100% die richtigen Werte habe, oder eben weiss, das die Verbindung sowieso tot ist … )

Bin sehr an Deinen Ergebnissen interessiert.

Ich denke, wir sollten im neuen Wiki da auch Ergebnisse und How-To’s einstellen, denn diese Technik ist eigentlich hichinteressant aber auch mit viel Initialaufwand verbunden, was sicher viele (ungerechtfertigt) abschrecken dürfte.

jwka

So, mal zwischenbericht

Heute angekommen 5NetIO und 7ATMEGEA 644

Gelich so nen ATMEGA 644 in das bestehende NetIO reingesteckt, rumprobiert, rumprobiert rumprobiert
und der Bootloader läuft - genau so wie es sein sollte.
Beim hochfahren des Bootloaders, holt er sich das File vom TFTP Server ab und fertig …

Nächste Schritte sind nun, schaun, das die Ausgänge und Eingänge mal so funktionieren wie sie sollen (Optokoppler, Relais und co)

werde auch die platine des NetIO’s verstümmeln (abfräsen, und dranlöten von den PIN’s zu einer Ausgangsplatine), da ich noch Hutscheinengehäuse und fertige Platinen von einem anderen Projekt habe, wo schon Optokoppler drauf sind … mal schaun, ob sich da was basteln lässt :wink:

Platine verstümmeln vom Net-IO? Oder von der Relaiskarte?

Mein Net-IO Projekt sollte längst gestartet sein, zweie liegen hier rum … ich hoffe, dass es in 2-3 Wochen soweit ist, dass ich da dran komme.

Ich verfolge Deine Posts mit Spannung!

jwka