Qual der Wahl - Sensoren Auswertung auf Display ("Analog")

Stefan N. schrieb:
> So lange ich nur reine Ziffern ausgeben ist das auch kein großes Problem

Wie machst du das? Fertige Lib?

Stefan N. schrieb:
> Und da stoße ich komplett an meine Grenzen

In wie fern? Programmiertechnisch? Geht dir der Speicher/Laufzeit aus?

Stefan N. schrieb:
> Ist ein Arduino da noch in der Lage die Daten "schnell" zu verarbeiten?

Wie soll man da eine allgemeine Antwort liefern?
Was ist schnell? Mehr als 10-20Hz wird es bei einer Anzeige wohl kaum 
sein. Und selbst das stelle ich je nach Messwert (z.B. Öltemperatur) in 
Frage ob es notwendig ist.
Außerdem wird diverse Hardware von Arduino unterstützt. Vom kleinen 
8Bitter, über einen RP2040 bis zum Potenta ist da alles dabei.

Irgendwie musst du ja an die darzustellenden Messwerte eh dran kommen, 
und da scheint mir OBD das geeignete Mittel zu sein.

Ich habe fürs Auto ein ELM327 kompatibles Bluetooth OBD Steckerchen, und 
eine APP auf dem Handy (Torque Lite). Diese kann auch analoge 
Instrumente darstellen.

An Messwerten hat die "Lite" Version der Software nur ein paar zur 
Auswahl. Die Vollversion kann anscheinend deutlich mehr auslesen.

-> Wäre das denn eine Option für dich?

Wegstaben V. schrieb:
> Irgendwie musst du ja an die darzustellenden Messwerte eh dran
> kommen,
> und da scheint mir OBD das geeignete Mittel zu sein.

Super Idee!!!

Hast du den Link für den Umrüstsatz auf OBD beim 73er VW Käfer? ;-)

der "Stevie"

N. M. schrieb:
> Stefan N. schrieb:
>> So lange ich nur reine Ziffern ausgeben ist das auch kein großes Problem
>
> Wie machst du das? Fertige Lib?

Ja. Auf Grund meiner  nur rudimentären Kenntnisse, bastel ich mir immer 
Code-Schnippsel zusammen.


>
> Stefan N. schrieb:
>> Und da stoße ich komplett an meine Grenzen
>
> In wie fern? Programmiertechnisch? Geht dir der Speicher/Laufzeit aus?

Programmiertechnisch :-|

>
> Stefan N. schrieb:
>> Ist ein Arduino da noch in der Lage die Daten "schnell" zu verarbeiten?
>
> Wie soll man da eine allgemeine Antwort liefern?
> Was ist schnell? Mehr als 10-20Hz wird es bei einer Anzeige wohl kaum
> sein. Und selbst das stelle ich je nach Messwert (z.B. Öltemperatur) in
> Frage ob es notwendig ist.
> Außerdem wird diverse Hardware von Arduino unterstützt. Vom kleinen
> 8Bitter, über einen RP2040 bis zum Potenta ist da alles dabei.

Ja. Ich muss zugeben, dass der erste Versuch war; einzelne JPGS mit 
Zeiger ins Display zu laden.  Das dauert pro JPG gefühlte 5 Sekunden.

Danke und Gruß
der "Stevie"

Stefan N. schrieb:
> Wie kann ich bei einem "statischen" Hintergrund einen Zeiger drüber
> laufen lassen?
Da gibt es 2 Möglichkeiten:
1. du malst andauernd 5x pro Sekunde den Hintergrund ohne Zeiger und 
malst dann den Zeiger drauf, oder
2. du übermalst nur den aktuell angezeigten Zeiger mit dem Hintergrund 
und malst dann den neuen drüber.

Stefan N. schrieb:
> Programmiertechnisch :-|
Sieh nach, wie man ein Pixel mit einer bestimmten Farbe setzen kann. 
Wenn du das kannst, kannst du mit Sinus und Cosinus alle Pixel des 
Zeigers ausrechnen und setzen. Wenn das manuelle Malen des Zeigers zu 
langsam ist, dann such in deiner Grafikbibliothek nach einer 
Linienfunktion, dann musst du mit Sinus und Cosinus nur noch den 
Anfangs- und Endpunkt der Linie berechnen.

Und ja, du siehst: nur, weil es etwas an jeder Ecke gibt, muss es noch 
lange nicht einfach gewesen sein, das zu entwickeln.

Stefan N. schrieb:
> Ich muss zugeben, dass der erste Versuch war; einzelne JPGS mit Zeiger
> ins Display zu laden.  Das dauert pro JPG gefühlte 5 Sekunden.
JPG ist dafür wohl auch das absolut ungeeignetste Datenformat. Das muss 
ja erst noch aufwendig dekomprimiert werden. Und hinterher hat man an 
den Kanten irgendwelchen Pixelsalat.

Stefan N. schrieb:
> Ja. Ich muss zugeben, dass der erste Versuch war; einzelne JPGS mit
> Zeiger ins Display zu laden.  Das dauert pro JPG gefühlte 5 Sekunden.

Für Zeigerinstrumente reicht normal 5Hz locker, viele sind langsamer. 
Wobei beim Drehzahlmesser 10Hz schon schöner wären. Okay, beim Käfer 
reicht wohl auch 5Hz:-)

Ein Atmega kann das mit passender Grafikprogrammierung noch schaffen. 
Mit Arduino-Libs kenne ich mich nicht aus - ich schreibe meine 
Grafikansteuerung selber.

Jpeg ist das falsche Format für einen Arduino. Die Darstellung von jpg 
braucht einiges an Rechenleistung. Für die Atmegas nimmt man besser 
Bitmap-Grafik im passenden Format, vermutlich 565-RGB für ein TFT.

Beitrag "Re: Grafikkonverter Tool für AVR/Mikrocontroller (BMP2C, BMP2ASM.)"
Beitrag "BMP/JPEG/GIF/PNG nach C-Code konvertieren"

Stefan N. schrieb:
> rudimentären Kenntnisse

Stefan N. schrieb:
> Programmiertechnisch :-|

OK, dann ist die Frage ob du dich tief in die Materie einarbeiten 
möchtest um programmieren zu lernen oder ob du einfach nur ans Ziel 
kommen möchtest.

So wie ich das sehe hast du mehrere Baustellen:
* Hardware robust genug machen um überhaupt zerstörungsfrei im Auto zu 
bestehen.
* Sensor Signale anzapfen (vermutlich analog) und an deine Hardware 
bringen ohne diese selbst zu stören oder das Sensorsignal zu 
verschlechtern.
* Sensorsignal auslesen (Software)
* Grafiken/Menü/Anzeigen erstellen und Sensorwerte geeignet anzeigen.
* Evtl weitere Punkte

Wenn ich das ganze für mich machen würde, würde ich vermutlich ein 
EVA-Board von z.B. ST kaufen/schnorren das von TouchGFX unterstützt wird 
(Preis um die 40-100€).
Dann die einzelnen Seiten/Instrumente in der GUI zusammen klicken.
ADCs instanziieren mit continuous Sample und DMA, damit die 
Sensorerfassung komplett im Hintergrund läuft.
Dann muss man nur noch regelmäßig die Werte von RAM/Register in das 
Instrument der GUI schieben.
Programmieraufwand wäre da vermutlich sehr gering.

Aber trotzdem nicht unbedingt für Anfänger geeignet.

https://www.ftdichip.com/old2020/EVE/EVEApplications.htm
Die Iren haben auch noch was. Der EVE Grafikcontroller, auch für Arduino 
ist was dabei, und eine Software "Screen Designer".

ESP32 mit lvgl Grafik ist ausreichend schnell für so eine Anwendung. Es 
gibt ein Board WT32-SC01, knappe 40€ bei Banggood oder ca. 45 € bei 
Berrybase:
https://de.banggood.com/WT32-SC01-ESP32-Development-Board-with-3_5-inch-320X480-Capacitive-Multi-Touch-LCD-Screen-Built-In-bluetooth-WIFI-p-1921644.html?cur_warehouse=CZ
Dazu findet man ein Musterprojekt mit lvgl für PlattformIO, link kann 
ich auch nochmal raussuchen.

Für lvgl gibt es einen Editor, aber man kann die Widgets auch zu Fuß 
postionieren, mit der relativen Postionierung geht das auch ganz gut. 
Hintergrund als Image und Zeiger drüber geht auch, ich hatte hier 
schonmal eine Uhr mit rundem Display gezeigt. Die runden Display gibt es 
mittlerweile auch größer, sind dann aber deutlich teurer.
In der Squarline-Studio Demo ist auch ein E-Bike Tacho drin der gut 
aussieht:
https://squareline.io/demos

Lothar M. schrieb:
> Sieh nach, wie man ein Pixel mit einer bestimmten Farbe setzen kann.
> Wenn du das kannst, kannst du mit Sinus und Cosinus alle Pixel des
> Zeigers ausrechnen und setzen.

das wird eine Lichtorgel, ein Geflacker ohne Ende. Es ist wesentlich 
effizienter Teilbereiche im RAM zu rendern und am Block in den TFT 
Controller zu schieben (wenn man nicht ein Display hat das im 
Speicherbereich des Controllers liegt). Und das ist dann schon eine 
deutlich aufwändigere Sache.

Steve van de Grens schrieb:
> Wenn du die relativ teuren Winkelfunktionen scheust, dann könntest du
> die Messwerte auch als Balken anzeigen.

Für so kleine Embedded-TFT könnte man die Zeigerstellungen auch vorher 
bereits mit Anfangs- und Endpunkt berechnen und in einer LUT ablegen: 
für einen 270°-Zeiger würde vermutlich eine Abstufung mit 3° und damit 
90 Werten ausreichen.

An dieser Stelle schon mal herzlichen Dank für die vielen Antworten. 
Toll!

Das hier sieht echt klasse aus:

PIC schrieb im Beitrag #7234125:
> und viele weitere Grafiken…
>
> https://youtu.be/NSOKTJQubxc

Leider finde ich auf dem YT Kanal wenig Zusatzinfos über "MicroMite".

Ist das auf Basis hiervon:
https://micromite.org/micromites/

Das scheint ja etwas mehr Aufwand zu sein.

@mani: Nein ich scheue mehr Aufwand nicht unbedingt - sollte sich aber 
in Grenzen halten. µC "Programmierung" ist nur ein Hobby von vielen - 
bei mir ;-)
Das was du beschrieben hast enthält ja schon viele Fachbegriffe, die mir 
einzeln bekannt sind, aber in einen Zusammenhang zu bringen doch noch 
etwas schwer fällt ;-)

Ich werde mal in Ruhe alle hier genannten Möglichkeiten für mich 
anschauen und bewerten.

Ich danke euch an dieser Stelle schon vielmals
der "Stevie"

P.S.: Im Anhang, wie EINE Anzeige aussehen soll. Mittels Taster sollen 
dann andere Werte eingeblendet werden können. Das hier ist ein "echter" 
Screenshot :-D

Steve van de Grens schrieb:
> indem man das untere Ende des Zeigers auf einer horizontalen Geraden
> enden lässt. Also mit festem Y-Wert.
Der ändert dann je nach Füllstand seine Länge. Aber im Grunde ist der 
Zeiger in dem Bild auch schon zu lang. Wenn das ein mechanischer Zeiger 
wäre, dann würde er bei 1/2 unten "überstehen"... ;-)

Stefan N. schrieb:
> P.S.: Im Anhang, wie EINE Anzeige aussehen soll.

Dafür reicht ja ein kleines 1.8 Zoll TFT 128x160:

https://www.ebay.de/itm/402652039495?

Sollen da später mal mehrere TFT rumwerkeln?

Lothar M. schrieb:
> Steve van de Grens schrieb:
>> indem man das untere Ende des Zeigers auf einer horizontalen Geraden
>> enden lässt. Also mit festem Y-Wert.
> Der ändert dann je nach Füllstand seine Länge. Aber im Grunde ist der
> Zeiger in dem Bild auch schon zu lang. Wenn das ein mechanischer Zeiger
> wäre, dann würde er bei 1/2 unten "überstehen"... ;-)

... so ist es auch. Beim analogen Instrument "verschwindet" die Spitze 
des Zeiger bei 1/2.

der "Stevie"

Stefan N. schrieb:
> ... so ist es auch. Beim analogen Instrument "verschwindet" die Spitze
> des Zeiger bei 1/2.
Ja, super, dann ist die Aufgabe tatsächlich ganz ohne Sinus und Cosinus 
lösbar.

>Ist ein Arduino da noch in der Lage die Daten "schnell" zu verarbeiten?

Das Hauptproblem ist sein kleiner Speicher von 2KByte SRAM. Das auch 
noch in Farbe, dann reicht der Platz nicht für den gesamten Bildinhalt. 
Wenn der daher im Display abgelegt wird, muss man für jeden bewegten 
Zeiger einen Teil davon in den Arduino zurücklesen, ändern und 
zurückschreiben.
Das Bild unter dem Zeiger muss man irgendwo retten und später wieder an 
dieselbe Stelle im Bildspeicher schreiben, wenn der Zeiger 
weitergewandert ist.

Für Winkel und Kreise gibt es den Bresenham-Algorithmus.
https://de.wikipedia.org/wiki/Bresenham-Algorithmus
das kann auch ein Arduino.

'Der Arduino' hat schon seit vielen Jahren sehr viel mehr Speicher als 2 
kB...
Und schnelle Interfaces für Displays und und und.

mimi schrieb:
> Stefan N. schrieb:
>> Ist das auf Basis hiervon:
>> https://micromite.org/micromites/
>>
>> Das scheint ja etwas mehr Aufwand zu sein.
>
> Von all den hier vorgestellten Löungen ist es die mit dem minimalsten
> Aufwand, billig und leich umzusetzen.
>
> Ein kleiner PI PICO oder PIC, Display dran und fertig.
> Halbe Stunde einlesen und los geht es.
> Und Basic verstehen ist leichter als alles Andere
> und hierfür völlig kostenlos, ausreichend, schnell und stabil.
>
> Schau hier:
> https://geoffg.net/picomite.html
>
> oder da:
> https://geoffg.net/BoatComputer2.html
>
> und dort:
> https://geoffg.net/picomite.html

... das liest sich echt gut.
Jetzt gibt es nur noch eine(?) Hürde. Ich habe kein Windows.
Nutze schon seit über 20 Jahren Linux. Mittlerweile Ubuntu.
Die Arduino IDE läuft auf meinem Rechner gut.
Dann werde ich mal weiter ... lesen ... Ich meine, ich hätte da was 
gesehen.
Zur Not muss WINE herhalten. Wobei ich das noch nieeeee benutzt habe und 
tw auch keine guten Sachen drüber gelesen habe.

der "Stevie"

EDIT: Das hier hab ich auch noch gefunden. Das zeigt ja die 
Möglichkeiten schon sehr ut.
https://www.youtube.com/watch?v=eDn7LFyoEm8

>Der Arduino
Ich meine den "klassischen" mit ATmega328. Der hat zwar einiges Flash 
und EEprom, aber immer noch nur 2k SRAM. Natürlich gibt es unter dem 
Namen noch anderes, heute muss es nicht mal mehr ein AVR sein.

>Und schnelle Interfaces für Displays und und und.
Wenn am Display der R/W fest auf write liegt, um I/O-Pins zu sparen, 
kann man nicht mal den Bildschirmspeicher zurücklesen.

mimi schrieb:
> Stefan N. schrieb:
>> https://www.youtube.com/watch?v=eDn7LFyoEm8
>
> Nein jetzt bringst Du leider einiges durcheinander

... das hab ich befürchtet ...
Ich denke, dass das Projekt wieder "abendfüllend" für den Winter ist.
;-)

@mimi
Was brauche ich an Hardware?
Einen Pi Pico und ein Nextion Display? Oder reicht ein SPI TFT? Davon 
hab ich noch welche rum liegen. Mit oder ohne SD Slot?

Danke und Gruß
der "Stevie"

P.S.: Ich möchte mich hier nochmal in aller Form für den Umgangston 
bedanken. Ich habe das hier im Forum schon anders erlebt, wie mit 
"Anfängern" umgegangen wird.

Nextion ist einfach weil es ein Intelligentes Grafikdisplay mit eigenem 
Controller ist und mit ein paar seriellen Befehlen gesteuert wird, das 
kann auch ein kleiner Arduino Nano.
Nachteil: original Nextion ist teurer, bei den Clonen muss man suchen 
wie die zu programmieren sind.
Der Pico hat schon viel Power, der ESP32 mehr aber kostet auch nicht 
mehr. Daher würde ich den für diese Anwendung bevorzugen.

Thomas F. schrieb:
> Stefan N. schrieb:
>> P.S.: Im Anhang, wie EINE Anzeige aussehen soll.
>
> Dafür reicht ja ein kleines 1.8 Zoll TFT 128x160:
>
> https://www.ebay.de/itm/402652039495?
>
> Sollen da später mal mehrere TFT rumwerkeln?

@igel ein 1,8" reicht (leider) nicht. Muss ein 2,4" sein.
Aber es soll bei einem bleiben.

Danke und Gruß
der "Stevie"