ARM Plattform, TPUART, Display

[greentux]

An fertigen Geräten ist halt Mist, dann man sich dann mit allen Unzulänglichkeiten rumschlagen muss. Display on/off/AutoOff, andere Apps, WLAN auto-off und was es noch alles gibt...
Mir würde ja ein "browser" reichen...

[greentux]

Ja Robert, da kommen wir schon zusammen
Fraglich ist noch, ob es Interaktion geben sollte. Also wenigstens Seitenwechsel (für mehrere Informationen) oder ob man was "wegklicken" kann.
Sehe ich dann schon nahe an meiner Vorstellung, die eher IP-basiert ist. Aber Bus-only mit ner config aus sh.py wäre prima.

[l0wside]

Hi Robert und greentux,

die Browserlösung kann ich zwar nachvollziehen, halte sie aber nicht für sinnvoll. Der Weg Richtung gopher ist mir schon sympathischer.

Der Cortex-M3 kam ins Spiel, weil ich einen µC mit LCD-Interface gesucht habe. Bei Cortex-M0 sah es da ziemlich mager aus, ich habe jedenfalls keinen gefunden. Kostenmäßig ist es sowieso ziemlich egal (LPC1785 in Einzelstückzahlen ca. 7,50 EUR netto).
Für ePaper scheint SPI plus I2C zu reichen, da ist ein Cortex-M0 dann sicher vollkommen ausreichend. Das Gesamtsystem lässt sich dann locker aus dem Bus versorgen.

Zu den Daten:
Mit widerstrebt es etwas, den auf dezentrale Funktion ausgelegten KNX, der schon alle notwendigen Informationen enthält, als Datenquelle links liegenzulassen und die gesamte Aufbereitung zentral zu machen, aber das ist eine Philosophiefrage.
Wenn es denn ein zentraler Server sein soll, würde ich überlegen, IP über KNX zu kapseln. Die Nettodatenrate ist so oder so nicht toll, aber dann sind wir bezüglich des Interfaces flexibel und könnten ohne größere Probleme z.B. parallel/alternativ Ethernet verwenden.

Keine dedizierte Software: das ist sehr relativ, wenn das Teil auf sh.py aufsetzt. Dann habe ich ja wieder die dedizierte SW, die vermieden werden sollte.
Wie wäre es mit einem festgelegten Protokoll zur Konfiguration des Geräts? Die eigentliche Konfiguration kann dann entweder ein Plugin für sh.py erledigen oder auch ein dediziertes Programm - jeder nach seinem Geschmack.

Ansonsten: Touchscreen oder Tasten?

Gruß,

Max

[greentux]

Der KNX enthält ja leider keine Informationen... Das wäre ja nur die ETS, mit der ich aber eigentlich nicht anfangen wöllte. Da hat die Konnex halt eine schöne Hürde verbaut.
Roberts Idee ist es ganz grob HTML via KNX zu tunneln. Also immerhin eine Art Seitenbeschreibung, wenn einige Informationen bekannt sind.
Man könnte also so vorgehen, das man das Layout der Seiten vl. doch vorab reinpummt (ggf. auch via KNX) und die Ansteuerung der Elemente dann doch auf dem üblichen Weg erledigt... Mmmh. Mal nachdenken.

Touch und ePaper habe ich noch nicht gefunden...

[Robert]

Ich glaube hier liegen die Ansichten diametral zueinander:
- die einen wollen quasi einen normalen Browser, der "große" Visus darstellt -> faktisch nicht mit Mikrocontrollern zu erreichen, da Visus wie smartVISU JavaScript & Co brauchen. Hier hilft eigentlich nur ein günstiges Smartphone. Evtl. kaufen mehrere das gleiche Gerät und tüfteln das gemeinsam aus. Bedeutet aber auch Fremdversorgung mit 5V (Fernspeisung oder vor-Ort-Netzteil) und WLAN-Anbindung. Energiebedarf ist über den KNX nicht zu machen.
- die anderen wollen die Idee des KNX verfolgen und ein autarkes KNX-Gerät mit vielleicht sogar ausschließlichem Busanschluss (Energie & Daten). Damit fällt eben obige Anwendung raus. Zudem riesige Farbdisplays etc. Auch ein Ethernet-PHY ist zu viel.

@Max,

wenn wir jetzt das "große Rad" drehen wollen:

Für meine diversen KNX-Selbstbauten suche ich auch noch DIE Lösung, um ohne (halblegale) ETS(-Produktdatenbank) die Funktionen und GAs zu parametrieren.

Für mich gibt es da zwei Möglichkeiten, die aber nicht mal eben von einer Person (bisher also mir) runterprogrammiert werden können:

1. Möglichkeit (ETS-Nachbau)

• PA, GAs, Funktionen werden über memwrite/memread oder die neueren properties (KNX!) übertragen: Diese Funktionen sind im Quasi-Standard eibd vorhanden bzw. können über die eibd-API von verschiedenen Programmier-/Scriptsprachen genutzt werden.
• Man zu jedem "Gerät" gibt es eine Beschreibung, was an welcher Adresse parametriert werden kann
• Parallel dazu könnte (optional) ein Tool entstehen, dass die Beschreibung des Gerätes (XML?) liest, und dem Benutzer übersichtlich darstellt (statt Kommandozeile)

Vorteile:

• geringe Belastung des Busses auch während der Parametrierung
• Verwendung des eibd als Standard-Tool
• niedrige Anforderungen an die Rechenleistung des Gerätes
• niedrige Anforderungen an die Programmierung des Gerätes (kein Webserver o.Ä.)

Nachteile:

• für komplexe Optionen nicht unbedingt intuitiv
• benötigt eibd (nicht jeder hat den laufen)

2. Möglichkeit (Webserver)

• jedes Gerät hat ein minimalistisches Webinterface
• Daten werden wie auch von Max vorgeschlagen über den KNX mit Property-Read/Write an die/von der PA getunnelt
• ein Programm/Treiber entpackt die Daten und ermöglicht die Darstellung in einem Browser

Vorteile:

• komfortabel wenn es einmal läuft besonders für mehrere Geräte
• auch komplexe Parametrierungen machbar
• mit dem SLIP-Protokoll bestehen schon etablierte Ansätze für so etwas, außerdem gibt es guten Beispielcode für die Integration ins IP-Netz (z.B. Borderrouter für Meshing des Contiki Projektes)

Nachteile:

• hohe Buslast beim Benutzen des Interfaces
• Webserver muss implementiert werden
• höhere Anforderungen an Speicher und Rechenleistung
• benötigt ebenfalls eibd und besagtes Programm/Treiber zu Umsetzung

Wenn man bereit ist, direkt an das Gerät zu gehen, gibt es natürlich noch Möglichkeiten wie direkte serielle Verbindung, USB (CDC-ACM oder Ether-Device für die IP-Lösung) oder SD-Karte. Halte ich aber für unzweckmäßig.

Bei einer schönen Implementierung könnte man über Bootloader etc nachdenken.

Wäre schön wenn sich da was täte - aber wie gesagt, das schwierige ist die Software... Da brauch man auch nicht mal Mikrocontroller-Programmierer zu sein, sondern es würden ja auch Leute für die PC-seitige Programmiersoftware von Möglichkeit 1 gebraucht.

Grüße
Robert

[l0wside]

Hallo Robert,

deine Aussage mit den diametralen Ansichten kann ich nur unterschreiben. Es wird am Ende beide Lösungen geben, nichts macht alle gleichermaßen glücklich.

Große Visu
Was die große Visu angeht, ist m.E. der Einsatz eines Tablets mit einem angepassten Browser das Mittel der Wahl. Daran bastle ich gerade (Android-Programmierung ist aber nur bis zu einem gewissen Punkt spaßig, fehlende Websocket-Unterstützung und faktisch fehlende SIP-Unterstützung nerven mich gerade gewaltig).
Anschluss hier über Ethernet oder WLAN. Die kritischsten Punkte hier sind Gehäuse (das Thema hat man aber immer) und Spannungsversorgung (PoE bietet sich an), der SW-Aufwand ist dagegen halbwegs überschaubar.
Ich packe die Entwicklungsversion bei Gelegenheit mal auf Github.

KNX-only
Das autarke Gerät hat genauso seine Existenzberechtigung. Neben dem Bett beispielsweise brauche und will ich kein großes Tablet, aber ein kleines reflexives Display (d.h. ePaper) im 55er-Raster könnte mir schon gefallen. Hier wäre eine Standardlösung auf Basis Cortex-M (Standard-HW mit µC, Busschnittstelle und Stack) sicher eine feine Sache.
Bezüglich Parametrierung: warum nicht eine Art Telnet-Server auf dem Gerät implementieren? Extended Frames können 256 Byte, das reicht für eine einfache Kommandozeile mit (strukturierten) Befehlen, je Befehl ein Frame. Das gleiche Interface kann ja auch eine Oberfläche nutzen.

Direkt ans Gerät zu gehen halte ich nicht für sinnvoll - wenn man schon einen Bus dorthin hat, kann man ihn auch nutzen. Bootloader allerdings ist in jedem Fall eine sinnvolle Sache.

Beschreibung der Optionen
XML-beschreibung der Optionen ist sicher eine gute Idee, ich würde mich hier an Android orientieren. Dort sieht das z.B. so aus:

    <PreferenceCategory
        android:key="pref_key_gui"
        android:title="GUI Preferences" >
        <EditTextPreference
            android:key="pref_key_gui_defaultsite"
            android:title="Default Site" />

        <ListPreference
            android:defaultValue=0
            android:entries="@array/pref_ctl_shutdown_items"
            android:entryValues="@array/pref_ctl_shutdown_items"
            android:key="pref_key_ctl_shutdown"
            android:persistent="true"
            android:title="Screen Off Condition" />
        <ListPreference
            android:defaultValue=0
            android:entries="@array/pref_gui_reloadonwake_items"
            android:entryValues="@array/pref_gui_reloadonwake_items"
            android:key="pref_key_gui_reloadonwake"
            android:persistent="true"
            android:title="Reload page on wakeup" />
    </PreferenceCategory>

Das muss man natürlich etwas abstrippen/modifizieren, aber das Rad wenigstens nicht von vorne neu erfinden. Es gibt auch Optionen, die abhängig von anderen Optionen eingeblendet werden, Wertebeschränkungen usw. - siehe hier.


Gruß,

Max

[greentux]

Ja, die KNX only Variante gefällt mir. Gute Zusammenfassung Max.