SPI Display -- am Ende gar mit Touch?

HaniMandl Entwicklung
1

Hallo zusammen,

ich fange ja gerade an zu spielen mit verschiedenen Komponenten.

Dabei fiel mir auf, dass es durchaus Vorteile bringen kann, statt I2C- ein SPI-Display zu verwenden (Auswahl Displays größer, Farbe)

Gibt es irgend jemand, der die Software daraufhin schon angepasst hat?

Ganz super wäre aus meiner Sicht eine Software, die mit einem Touch-Display auskommt. In der Gallerie gibt es dazu ein Bild. Leider komme ich nicht dran, wer das erstellt hat. Da gibt es ja anscheinend schon eine Software zu? Da steht zwar unter dem Bild “Sackgasse” - ich bezweifle aber, dass das eine Sackgasse ist. Mein Plan ist, mit einem einzigen physischen Button aus zu kommen und den Rest über das Touch Display zu machen

Grüße

2

Du meinst sicher das hier: Taster durch touch-Sensoren / touch-Pins ersetzen? Andreas H. / @aholzhammer hatte das mit dem Touchdisplay versucht, ist dann aber einen anderen Weg – weiter mit den physischen Buttons – gegangen. Michael / @MKO hatte ebenfalls experimentiert.

Kann mir gut vorstellen, dass ein Touch-Display funktionieren könnte. Wir haben über die Buttons und den Rotary ja vor allem Einstellungen angepasst und brauchen die nicht für “Sicherheitskritisches”, ausser ggf. Füllung Abbrechen / Hahn schließen. Dass es mit (touch) buttons only geht zeigt ja auch mein proof of concept im oben verlinkten thread unter posting #7.

Vielleicht könnte man dafür auch den LilyGo LilyPi verwenden. Da gibt es ein programming kit für die Oberfläche, ist aber sehr komplex und schlecht zu debuggen, daher habe ich da nicht weitergemacht.

Mein Stand ist bisher, dass wir die kompletten Display-Ausgaben neu schreiben müssten. Vielleicht magst du recherchieren, ob wir die U8g2-Ausgaben auch für ein Touch / TFT verwenden können und zusätzlich Touch-Elemente hinzufügen können, das würde den ersten Schritt erleichtern – oder eben in den sauren Apfel beißen und die Dinge neu machen.

1 Like
3

Hi,
mein “Proof-of-Concept” habe ich aus verschiedenen Gründen recht schnell verworfen. Wenn ich mich recht erinnere, waren das für mich damals vor allem der große Aufwand, da die Bildschirmausgabe und Bedienelemente stark im Code verzahnt sind, der - für mich - fehlende Mehrwert, die Erkenntnis, daß das nur direkt auf dem Display funktioniert, und ich das eher hinter einer Scheibe schützen wollte, und auch die höhere Sicherheit, die ein mechanischer Taster bietet.
Schöne Grüße
Andreas

1 Like
4

OK - schade … ich werd Mal sehen, was ich mache. Erst Mal muss ich noch ein bisschen spielen. Ich bin jetzt nicht der MCU Profi, von daher ist kurzfristig sicher nicht mit einer Lösung zu rechnen. Wenn ich die Honigernte dieses Jahr nochmal anders abfülle, passt das für mich auch ;-)

Auch wenn es immer wieder widerholt wird, halte ich es dennoch für unrichtig: nein - ein Touchdisplay muss nicht ungeschützt bleiben. Ich bin nicht sicher, ob ich das so umsetze, aber es wäre durchaus möglich, das komplette Display mit einer Schutzfolie zu überziehen (natürlich ist das nicht einfach, aber möglich). Ein kapazitives Touch-Display kann damit umgehen. Wie gesagt: ich bin unsicher, ob das praktikabel ist, aber unmöglich ist es erst Mal nicht. Auch eine “Abdichtung” des Displays ist ja nicht unmöglich.
Vielleicht sollte ich erwähnen, dass genau solche Geräteentwicklungen mein Beruf sind und da auch Prototypen eine große Rolle spielen.

Außerdem schmiere ich mir beim Honigafüllen jetzt nicht grundsätzlich alle 10 Finger voll. Ich kann da nebenher durchaus mein Handy bedienen, ohne dass es danach zwangsläufig gereinigt werden muss.

Aber ich möchte auch nicht ausschließen, dass ich es wieder verwerfe und natürlich sind es Hindernisse und ich kann nachvollziehen, dass man diesen Pfad nicht gehen möchte, wenn man ein funktionierendes Gerät hat.

5

Hallo zusammen,

kurzer Zwischenstand:
Display und Touch läuft. Servo auch.

Ich bin gerade dabei, mich mit der LVGL Bibliothek anzufreunden (erste slider laufen - ich kann z. B. die Helligkeit des Displays regeln oder auch das Servo steuern). Wenn das so vollumfänglich klappt, wird der ganze Sketch ziemlich sicher deutlich anders aussehen, als die offizielle Software. Insofern werde ich vermutlich nur einzelne Teile (Funktionen) übernehmen. Eine Version, die mit beiden Varianten funktionieren würde, macht aus meiner Sicht kaum Sinn, weil LVGL den Sketch mehr oder weniger übernimmt.

LVGL ist mit einem SPI Display jetzt nicht das schnellste. (besser wäre ein parallel angeschlossenes, was wohl auch möglich wäre, weil der Hanimandl außer dem Display dann sehr wenig Anschlüsse braucht. Allerdings klingt es etwas overkill, wo andere mit einem einfachen, kleinen Monochromdisplay auskommen ;-)) Aus meiner Sicht sorgt die Bibliothek (wenn ich das richtig verstehe) dafür, dass mit geringstem Aufwand das beste rausgeholt wird.

Insgesamt bin ich jetzt nicht der Programmiermeister. Ich habe zwar früher in verschiedenen Sprachen (hobbymäßig) programmiert. Das ist aber lang her und mit Microcontrollern habe ich wenig nennenswerte Erfahrung. Wenn jemand Interesse hat, sich an dem Thema zu beteiligen, freue ich mich, wenn Kontakt zu mir aufgenommen wird und wir zusammenarbeiten können.

Grüße

2 Likes
6

Habe LVGI (Doku: https://docs.lvgl.io/latest/en/html/index.html) mal mit dem LILY Pi ESP32 ausprobiert, das wäre hardwaremäßig auch mein Kandidat für den HaniMandl Touch, falls wir den Servo da angeschlossen bekommen. Alles super kompakt gleich mit Gehäuse. HX711 würde ich eh an der Waage unterbringen und Elektronik extra. Ggf. braucht es noch ein custom Kabel, damit es etwas schick wird: 5 V direkt vom Netzteil zum Servo und die Steuerleitung zum ESP, aber sind eh ungelegte Eier wenn die UI nicht steht.

Ich fand die LVGI doof zu programmieren, da braucht es ein externes Tool, um grafisch arbeiten zu können und den Rest macht man dann am Code, man muss die UI zum Testen dann immer wieder uploaden, was lange dauert. Wie hast du das gemacht? Welches grafische tool hast du genutzt, kannste was empfehlen? Die Demo auf dem Lilly Pi ESP, das default LVGI-Beispiel, fand ich jedenfalls beeindruckend, besonders wenn man bedenkt, dass man auf einen ESP und keinem Android oder RasPi unterwegs ist. Für uns sollte es leistungsmäßig reichen.

1 Like
7

Hallo,
bis gestern hab ich ausschließlich in der Arduino IDE programmiert und hochgeladen. Ja, das geht lang, aber zunächst hatte ich nix anderes zum Laufen bekommen.
Heute hab ich Visual Studio 19 verwendet und es geschafft, die Examples zum Laufen zu bekommen. Nicht jedes funktioniert, aber Visual Studio hat was, es führt einen schnell an Stellen, wo man hin möchte und natürlich geht das erzeugen viel schneller.

Wie ich da jetzt allerdings was Neues anfang, ist mir noch nicht so ganz klar. Die Examples sind ziemlich komplex aufgebaut, weil sie alle in einem Projekt laufen, in dem man dann eben ein Example freischaltet. Zum Umstricken ist das nicht besonders praktisch

Grafisch arbeiten kann ich so auch nicht, aber es geht trotzdem wesentlich schneller. In einem Video hatte ich so ein tool gesehen, mit dem man die Elemente tatsächlich nur noch auf den Bildschirm ziehen muss, aber ich weiß nicht, was das ist. Grad hab ich noch den Bunmaker (sicherheitshalber in der Sandbox) ausprobiert, der scheint ja irgendwie einen Code zu erzeugen, aber wohl leider nur für BunHMI … Ich bekomme den Eindruck für diese Module hätte ich länger Chinesisch lernen sollen ;-)

Oder auch einfach das richtige Tool Squareline Studio nehmen …

Grüße

8

Hallo Dinkelbiene,

interessant, was Du da treibst ;].

Ich kann ggf. gerne mit drauf schauen oder anderweitig mittun.

Verstehe.

Das hat seinen Reiz ja. UI Elemente rein per Code zu erzeugen, aber auch!

Hier müssten wir aufpassen. Wenn wir das Ergebnis wieder oder neu unter einer freien Softwarelizenz veröffentlichen wollen, würde das Modell “Free – Only for personal use” [1], nicht passen, da es die Nutzung auf “Not for commercial use” einschränkt.

Vielleicht können wir hier also einen Weg drumrum machen und das Tool entsprechend nicht nutzen? Rein mit LVGL wären wir auf der sicheren Seite.

Viele Grüße,
Andreas.

  1. https://squareline.io/pricing/licenses ↩︎

9

Hi

Guter Input (auch wenn ich jetzt nicht vorhabe, hier irgendwas zu verkaufen - den Weg ganz zu verbauen, wäre schade) und wenn ich ehrlich bin: sooo kompliziert war es jetzt nicht, die Elemente manuell zu platzieren. Was auch geht ist: Visual Studio kann den Code von Squareline ausführen und bringt dann eine Simulation als bedienbaren Bildschirm. Der Code wird dabei von Squareline nach Visual Studio übertragen. Wenn man jetzt direkt in Visual Studio einsteigt, dürfte das Lizenzthema gelöst sein. (muss ich es nur noch schaffen, zu verstehen, wie die Daten in Visual Studio abgelegt werden)

Was für mich mehr und mehr ungreifbar wird ist: ich habe keinenHanimandl und ich weiß nicht, wie die Steuerung momentan funktioniert. Es wäre mega hilfreich, wenn mich jemand auf ein Video stoßen würde, wo ich das genau sehen kann: was passiert wenn man was drückt, welche Einstellungen gibt es, etc.

Ich gehe davon aus, dass man das mit Touch deutlich anders macht, aber trotzdem wäre es hilfreich. Momentan gehe ich davon aus, dass ich 2 Screens habe:
-einer, zum Bedienen
-einer zum Einstellen

Da das Display groß ist, würde ich möglichst alles, was momentan zum Teil im Code schon eingestellt wird, im Sketch einstellen. LVGL kann ggf. scrollen, sodass das auch auf einer Seite ginge (pumpt dabei eben - insofern wäre anders schöner)
Den Bedienscreen würde ich für Automatik und Manuellen Betrieb gemeinsam machen und mit einem Softwareswitch dazwischen umschalten. Ansonsten brauchts aus meiner Sicht für den Betrieb nur 2 Werte: SOLL und IST
Dauerhaft würde ich 2 bzw. 3 Buttons anzeigen wollen: 1. Auf - 2. Zu - 3. Servo aus - also Servo Stromlos schalten (irgendwie hab ich Angst, dass ich zuschauen muss, wie Honig fließt, während ich verzweifelt versuche, gegen den Servo den Hahn zu zu drücken). Vielleicht ist es aber auch besser, das einfach per Hardware mit einem Schalter direkt am Servo zu machen. Wundert mich latent, dass der “normale” Hanimandl das nicht hat. Der physische Schalter würde auch einen MOSFET (und schlimmer: die dafür nötige Platine) sparen und wäre insgesamt einfacher und sicherer.

Momentan stelle ich mir ein Tabview (Squareline kann momentan noch kein LVGL Tabview) links vor, direkt daneben dann die individuellen Bildschirme (Betrieb bzw. Einstellen). ganz rechts dann (ich bin Rechtshänder) groß die dauerhaft sichtbaren Buttons. Vielleicht ist Tabview auch ungünstig, weil es viel Platz nimmt und es wäre entsprechend besser, ein Zahnrad bzw. einen Pfeil zurück in der linken oberen Ecke zu zeigen.
Zusätzlich habe ich ja einen physischen Button, dessen Funktion automatisch zwischen Auf (wenn nicht offen ist) und Zu (wenn nicht zu ist) wechselt.

1 Like
10

Es geht nicht um verkaufen, überhaupt nicht, ganz im Gegenteil! Es geht darum die Software als open source zu publizieren, damit andere diese auch nutzen konnen und ggf. weitere features, Verbesserungen usw. beitragen können. Ohne open source würde ich persönlich gar nichts anfangen!

Das ist schlecht und du solltest dir zumindest einen zusammenbauen, man kann das schwer alles in ein Video packen und irgendwelche Fragen bleiben sonst immer offen. Die Teile sind nicht teuer und du kannst vieles ja auch für die touch-Variante weiterverwenden …

So ist das jetzt auch prizipiell.

Ich würde den Manuellen Modus komplett weg lassen, siehe auch Taster durch touch-Sensoren / touch-Pins ersetzen? - #7 by clemens, da habe ich das auch schon weggelassen.

Wir hatten einen Notaus schon irgendwo (FB oder hier) diskutiert, da ich den über USB-Netzteil betreibe das auch greifbar ist habe ich den Bedarf nicht gesehen. Stecker raus und du hast die Funktion. MOS-FET o.ä. bringt auch nichts, falls ein Software- oder Hardwarefehler auftritt kannst du den auch nicht mehr schalten. Entweder ein echter Notaus oder zumindest plus trennen oder gar nichts, würde ich sagen.

Macht die LVGL-Demo auch, nur oben.

Warum haben wir einen physischen Button? Für mich macht das Ganze nur Sinn, wenn alle Buttons weg kommen.

Noch eine prinzipielle Frage? Gibt es neben LVGL auch andere Frameworks? Ggf. brauchen wir auch gar kein Framework wie LVGL und können das anders lösen, nicht dass ich das unbedingt wollen würde, nur als Denkanregung, ob das ggfl. weniger komplex / besser handlbar oder auch das Gegenteil davon ist. Vielleicht gibt es auch was wo man U8g2-code weiterverwenden kann …

1 Like
11

Hi,

OK - das war mir tatsächlich nicht bewusst, dass ich den Code nicht Mal teilen dürfte. Das wäre für mich auch absolut entscheidend.

Manuellen Modus weg lassen klingt gut, wobei die Buttons auf und zu ja schon so was erzeugen würden. Verstehe ich richtig, dass Du die Funktion eben dann so ändern würdest, dass da An/Aus steht?

Ich bin nicht sicher, ob ich wirklich Bock hab, mir extra zum Spielen einen Hanimandl mit Buttons und I2C Display aufzubauen. Letzteres hab ich nicht … naja - Mal sehen …

Das mit dem NotAus stimmt soweit schon, wobei ich meinen persönlichen Hanimandl ja ggf. mit Batterie betreiben können möchte, wenn Tests zeigen, dass das funktioniert. Bisher zieht der Power Mux bei USB Betrieb deutlich zu viel Strom aus der Batterie, was dann insgesamt wenig Sinn macht. So paranoid dass ich nur als Notstrom die Batterien einbaue, bin ich dann doch nicht …

Den einen physikalischen Button möchte ich haben, weil mein Gehäuse (eine alte Küchenwaage von Beurer - DS81) das schon hat. Da geht es mir so, dass ich ungern irgend was, was an dem Gehäuse vorgesehen ist, weglassen möchte - mag vielleicht seltsam klingen und vielleicht lasse ich mich bei den Batterien noch bekehren (wobei ich bisher den Eindruck habe, dass die Batteriel über die beiden Pololu Module das ganze gut betreiben können, auch wenn ich sehr kräftig am Servo drücke und den Strmfluß dahin deutlich erhöhe - bisher keine Aussetzer). Beim Taster gibt es keinen Grund - es ist zu einfach, den einzubauen und der Schalter befindet sich zu auffällig am Gehäuse …

Das ganze ohne irgend eine Bibliothek … ja - wäre eine Möglichkeit

Ja - LVGL kann Tabview - und nein - nicht nur oben und es kann auch tabview auf einem Teil des Bildschirms - aber Squareline kann es gar nicht. Das tabview Objekt ist wohl ein Kind des allgemeinen lv_objects bei dem es Position und Größe gibt.

1 Like
12

Der manuelle Modus wird über den 3-fach-Schalter aktiviert und hat nicht direkt etwas mit an–aus / Servo auf–zu zu tun. Diese Funktion haben die beiden Taster momentan im Auto-Modus ja auch, klar und die brauchen wir auch weiterhin.

1 Like
13

Es gibt jetzt eine open source Variante zu Squareline Studio: EEZ Studio
Habe heute den FLOSS Weekly Podcast darüber gehört:

Die Maintainer haben auch noch einige andere interessante Hardware Projekte am Laufen.

2 Likes