[TEST] C-Berry - 3,5" TFT Display

  • ThomasG
    Deine Demo läuft wunderbar und ist sehr gut gemacht, auch die "readme" Dateien
    erklären Alles ganz genau. Hoffentlich ist bald Zeit um die einzelnen Dateien näher
    anzusehen. Jedenfalls hat dieser ganze C-Berry Wahn (nach dem Kauf nur noch davor
    gesessen :)) einen tollen Lerneffekt, gut das ich morgen erst mal weg muss, aber
    vielleicht nehme ich das Teil sogar mit :) :) :)


    Heute früh hatte ich gerade meinen Beitrag abgeschickt und danach bemerkt das
    ThomasG genau da seinen neuen Treiber präsentiert, deshalb wurde der auf eine
    Zeile gekürzt um nicht abzulenken. Hier nun das was eigentlich darin stand:

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

    Noch ein Versuch :) Ein Bluetooth interface am Pi und eine "GPS Maus" liefern die
    Daten und das C-Berry display zeigt die Position an.
    Das mit der Anzeige sollte morgen kein Problem werden, ich habe die Positionsdaten
    wieder mt scripten und der Hilfe von "gpspipe" sowie "cut" (plus den Rest so wie bei
    SMS) bereitgestellt, die Ausgabe sollte also funktionieren.

    Zwei Sachen die Anfänger wie mich vielleicht interessieren:

    1. Wenn man den "screen" vor dem darstellen von Text nicht löscht und vorher ein bmp
    ausgegeben wird hat man ein Hintergrundbild.

    2. Das hat zwar nicht direkt mit C-Berry zu tun aber nach längerer Suche über Google
    ist mir heute etwas eingefallen. Mit cronjobs lassen sich Befehle ja nur minütlich oder
    verschachtelt (sleep) starten, schon mehrmals habe ich mir Takte im Sekundenbereich
    gewünscht. ->

    "iwatch" überwacht Verzeichnis A, script 1 schreibt alle n Sekunden eine Datei in
    Verzeichnis A, so lässt sich Befehl X alle n Sekunden ausführen.
    Das funktioniert sogar auf Systemen wo contab nicht existiert. (Beispiel wäre das Nokia
    N900, jedoch weiß ich nicht ob "iwatch" darauf nutzbar ist) Aber jetzt ist ja erst mal
    C-Berry Wahn :rolleyesIcon_smile

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

    Ein GPS Empfänger, "oldschool", nicht mit Android Navigation, so wie in den 90ern
    mit einfacher grafischer Darstellung von Daten und track. Das wäre "der Hammer" :)


    Heute habe ich aus Lego :) ein Gehäuse für Pi und C-Berry gebaut,
    ein Foto reiche ich nach :)


    edit---> Bilder vom Gehäuse, leider hatte ich nicht alle passenden Steine, daher sind viele kleine drin.

  • DerHagen
    Ganz toll das Du sowas hinbekommen hast, jetzt könnte man echt wirklich viel mit dem
    Display machen.

    Leider weiß ich noch nicht wie dein Programm zu nutzen ist, hätte gedacht das es nach
    einem make zur verfügung steht.
    Die Ausgabe lautet aber: "make: Für das Ziel »all« ist nichts zu tun."

    Wie muss man vorgehen ?

    Einmal editiert, zuletzt von erzich (8. Mai 2014 um 13:42)

  • ach so, ja ...

    make
    makefile ist dabei, fb2cberry als "exe" auch. Wenn du nichts an den sourcen änderst, stellt make das fest und compiiliert/linkt nicht neu. Aufruf siehe unten.
    Richtig Sinn macht nur die Änderung der fps -> usleep( 100 * 1000 ).
    *1000 ist um von µs auf ms zu kommen. 1000ms/100ms = 10-> also 10 fps

    Aufrufen
    zum Testen: "sudo ./fb2cberry" , kann man mit "STRG-C" wieder abbrechen.
    wenn es ok ist, dann "sudo ./fb2cberry &" (ohne Anführungszeichen), durch das & wird das Programm in den Hintergrund geschickt und die Console ist wieder frei.
    Wenn alles "richtig" eingestellt ist, kann man das auch in den autostart mit einpflegen.

    Auflösung
    Ich habe ein 1920x1080 Monitor als main display. Der BCM skaliert die Auflösung des main displays unter auf die Auflösung des TFTs (320x240). Gut, man kann alles erkennen, aber natürlich nicht wirklich lesen.
    Wer NUR den CBERRY als Monitor einsetzten möchte, der kann natürlich in der Datei
    /boot/config.txt die gewünschte Auflösung einstellen.
    Nativ habe ich 640x480 als kleinste Auflösung gesehen, dh immer noch 4x größer als das cberry.

    Ausprobieren!
    Wem das immer noch nicht gut genug ist: kann man aber auch manuell einstellen

    framebuffer_width=320
    framebuffer_height=240

    und alles andere auskommentieren.
    Dann ist der main monitor in der selben Auflöung wie das cberry und man kann alles wunderbar lesen.

    DerHagen

    Einmal editiert, zuletzt von DerHagen (8. Mai 2014 um 14:07)

  • Jetzt weiss ich warum ./fb2cberry eben nicht funktioniert hat und ich dachte es muss
    erst kompiliert werden. :)

    Die Datei war nicht ausführbar, chmod +x hat geholfen.


    Jetzt geht es :thumbs1:

  • Hallo,


    DerHagen
    C-Berry als Monitor am raspberry pi funktioniert nun 1A :danke_ATDE:
    Ich hoffe admatec wird sich bedanken :) (oder hast Du das im Auftrag gemacht ?)
    Jeder Interessent wird auf dieses Forum stossen und im Gegensatz zu vorher merken
    das C-Berry jetzt als main display genutzt werden kann. Die Verkaufszahlen werden
    sicher stark ansteigen !

    Conrad, elv und Reichelt sollten beim Preis auch "die Füße stillhalten" :), die haben zu
    der möglichen Absatzsteigerung nichts beigetragen.

    HAMMER :thumbs1::thumbs1::thumbs1::thumbs1::thumbs1: ,kann man nicht oft genug sagen!


    Jetzt stehen normalen Linux Benutzern alle Wege offen um etwas mit dem Display zu machen.

    Mein erster Test war /dev/mmcblk0p1/config.txt
    Das Display kann 320x240 ganz toll darstellen, für mich hat es jedoch nur richtig "nativ"
    geklappt mit (overscan an, overscan an allen Seiten 1px, SD TV Ausgang aktiviert). Wie es
    aussieht wenn HDMI gewählt ist weiss ich nicht aber ausser mit meinen Einstellungen war
    immer ein Rand da und die Schrift nicht "nativ" auch wenn alles ausser der Auflösung
    auskommentiert war. In dem Fall gab es einen "überspringenden" Pixel rechts.

    Darstellung der GPS Daten mit cgps und xgps hat wunderbar funktioniert

    LXDE ist zwar nicht sinnvoll aber geht auch.


    Habe leider nicht so viel Zeit zu testen die nächten Tage aber die Voraussetzungen sind
    gegeben, dank dem Displaytreiber von DerHagen, den Verbesserungen von ThomasG
    und der Möglichkeit den DS1820 auszuwerten von tuxerli. Das ist Linux !!! Genial !!!


    Mit freundlichen Grüßen

    Einmal editiert, zuletzt von erzich (8. Mai 2014 um 18:57)

  • Jetzt stelle ich mir gerade die Frage, ob wir nicht unser Wissen zusammentun sollten um eine Treiber für Ffbtft zubasteln?
    was meint ihr?


  • Jedenfalls hat dieser ganze C-Berry Wahn (nach dem Kauf nur noch davor
    gesessen :)) einen tollen Lerneffekt,


    :) Geht mir genauso. Hab mittlerweile viel zu viel Zeit mit diesem Display verbracht, dafuer hab ich auch viel gelernt und meine angestaubten programmierkenntnisse wieder refreshed.


    1. Wenn man den "screen" vor dem darstellen von Text nicht löscht und vorher ein bmp
    ausgegeben wird hat man ein Hintergrundbild.


    Ja. Genau diesen Punkt hab ich heute aufgegriffen. Ich hab nun eine PNG Bilder Anzeige eingebaut, und die Textroutine um transparenten Hintergrund erweitert. Das heisst, man kann nun Bilder anzeigen und mit Text druebermalen, sodass das Bild tatsaechlich als Hintergrund genutzt werden kann. Tatsaehlich kann der Controller Chip sogar noch mehr was transparenz angeht, sofern man den 2-Layer Modus benutzt...

    In meiner nachsten treiber version (sehr wahrscheinlich morgen) wird der PNG anzeiger und transparenter Text dann enthalten sein!


    2. Das hat zwar nicht direkt mit C-Berry zu tun aber nach längerer Suche über Google
    ist mir heute etwas eingefallen. Mit cronjobs lassen sich Befehle ja nur minütlich oder
    verschachtelt (sleep) starten, schon mehrmals habe ich mir Takte im Sekundenbereich
    gewünscht. -> "iwatch" überwacht Verzeichnis A, script 1 schreibt alle n Sekunden eine Datei in
    Verzeichnis A, so lässt sich Befehl X alle n Sekunden ausführen.


    Also die eigentlich beste methode waere es tatsaechlich ein eigenes natives program zu schreiben. so hat man die komplette kontrolle ueber alles was man machen will. Ideal waere natuerlich ne script sprache wie python, aber auch C(++) ist nicht wirklich schwer zu lernen. Nur Mut !! :)


    Beispiel wäre das Nokia N900...


    Ach das gute N900. :) Hatte das auch mal, bis es mir in der S-Bahn in Muenchen geklaut wurde. Unverschaemt!! Zumal der Dieb das garantiert nicht verkaufen konnte... Aber nochmal wollte ichs mir dann nicht kaufen, da es einfach zu teuer war. Echt schade drum!! Aber das is ne andere Geschichte...


    Heute habe ich aus Lego :) ein Gehäuse für Pi und C-Berry gebaut,


    WOW!! Dies ist der Wahnsinn. Will auch sowas :)


    anbei ein kleines Programm, welches den Inhalt des main displays auf dem cberry ausgibt, zZ sind 10fps eingestellt.

    Coole Sache. Danke!
    Ich habs noch nicht ausprobiert, nur mal kurz in den Code reingeschaut. Da das program ja letztlich ncihts anderes tut, als staendig den framebuffer als "Bild" in den DDRAM des controllers zu schreiben, gehe ich aber davon dass die CPU last recht hoch ist. Stimmt das?


    Jetzt stelle ich mir gerade die Frage, ob wir nicht unser Wissen zusammentun sollten um eine Treiber für Ffbtft zubasteln?
    was meint ihr?


    Ich stelle gerne mein Wissen und meine Erfahrungen mit der direkten programmierung des RAIO controllers bereit, werde mich aber aus Zeitgruenden selbst "nur" auf dies beschraenken. D.h. ich bastlte weiter an meinem userspace "treiber" programm in c++ weiter, und beantworte auch gerne fragen diesbezueglich, werde aber kein weiteres neues projekt mit diesem display erstmal anfangen.
    P.S. Was ist Ffbtft eigentlcih?

    Einmal editiert, zuletzt von ThomasG (9. Mai 2014 um 00:33)


  • anbei ein kleines Programm, welches den Inhalt des main displays auf dem cberry ausgibt, zZ sind 10fps eingestellt.


    Hallo DerHagen,
    Ich kann das Display mit der Funktion: vc_dispmanx_display_open( 0 ); nicht öffnen.
    Liegt es daran, dass ich kein HDMI display angeschlossen habe? Ich betreibe meinen RasPi (wo das c-berry dranhängt) als "headless" über ssh...

    Bevor ich lange google, kannst du mir bitte kurz und grob erklaeren, was diese vc befehle eigentlich machen, wo ich dokumentation finde, usw. Sind das befehle die direkt diese (vc =? VC = VideoCore?) GPU ansprechen? Wie funktioniert das alles auf der hardware ebene? Läuft das dann über diesen oft-zitierten "binary blob"? Ausgehend von meinen spärlichen Informationsbruchstücken würde das ja quasi bedeuten, dass dieses binary blob, das eigentliche "Betriebssystem" des RasPis ist, und linux mehr eine art zwischenlayer darstellt? Ich kenne mich mit den eigenarten von "embedded" systemen nicht wirklich aus... Aber langsam beginne ich glaub ich a bissl dahinterzusteigen.. :) Oder liege ich da falsch?

    Ich vermute dann also, dass ich somit ohne X oder FBdev oder irgendwas "linux-spezifisches" direkt mit der GPU reden und auf ein (hdmi-) angeschlossenes display schreiben kann? ... Dann würde ich auch sofort verstehen warum das fb2cberry.c so trivial ist.. :)

    Falls dem allen so ist, kann ich dann diese VC dazu bringen, ein virtuelles display zu erzeugen, also ohne dass ein HDMI gerät dranhängt?


    Cheers,
    Thomas

  • Zitat

    The most important thing you should know is that the RaspberryPi is a strange beast where the ARM CPU is the not main CPU - it's only a co-processor to the VideoCore GPU. When the RaspberryPi starts, a GPU blob is read from the SD card to the L2 cache and executed. This code then brings up all the important peripherals (RAM, clocks etc) and starts the ARM CPU. Then the 2nd stage bootloader or some operating system itself can be run on ARM CPU.

    GPU blob is not only a bootloader. It's actually an operating system (Video Core OS) by itself. Some important elements of the system are not directly accessible by ARM CPU and it has to communicate with GPU (using mailbox messaging system) to use them.


    das steht hier jedenfalls so:
    http://raspberrypi.stackexchange.com/questions/7122…of-raspberry-pi

    ob das stimmt kann ich nicht beurteilen.

  • so, falls wer darauf gewartet hat, hier der Zusammenhang
    zwischen fps und CPU load [%]:

    fps............sec..............CPU mit Bildausgabe......CPU ohne Bildausgabe
    1..............1.................4.................................0
    2..............0,5..............7-9..............................0
    4..............0,25............15................................0
    8..............0,125...........25...............................0
    10............0,1..............30................................0
    20............0,05............45................................0-1
    40............0,025...........61...............................1
    100..........0,01.............77...............................3

    ohne Bildausgabe bedeutet, dass die Zeile ꞋRAIO_Write_PictureꞋ auskommentiert ist.

    was soll uns das sagen?
    1) die vc -Sachen laufen quasi ohne CPU Beteiligung ab
    2) das Kopieren der Daten zum Display kostet Zeit
    3) Je höher die framerate, desto höher der CPU load (irgendwie klar)

    -> Ziel: Nur dann (und auch dann nur das) zu übertragen, was wirklich von Bild zu Bild geändert wurde.
    Das würde die CPU load deutlich reduzieren.

    Wer Ideen und/oder Lösungsvorschläge hat ... können wir gerne diskutieren.

    DerHagen

    Einmal editiert, zuletzt von DerHagen (18. Mai 2014 um 13:18)


  • 1) die vc -Sachen laufen quasi ohne CPU Beteiligung ab


    das ist gut zu wissen, wenn auch keine überraschung.


    2) das Kopieren der Daten zum Display kostet Zeit


    Genau!! Das war eben genau der Anlass meines Kommentares bzgl der Sinnhaftigkeit das LCD Modul als generisches Framebufferdisplaz zu nutzen. Aus eigener Erfahrung mit der "direkten" Programmierung des Displays, weiß ich, dass die Kommunikation mit dem Display über das SPI leider sehr viel Zeit in Anspruch nimmt.


    3) Je höher die framerate, desto höher der CPU load (irgendwie klar)


    folgt direkt aus 2)


    -> Ziel: Nur dann (und auch dann nur das) zu übertragen, was wirklich von Bild zu Bild geändert wurde.
    Das würde die CPU load deutlich reduzieren.
    Wer Ideen und/oder Lösungsvorschläge hat ... können wir gerne diskutieren.


    Meiner Meinung nach ist die einzige sinnvolle nutzung des LCD moduls, es als Status-Anzeige für individuelle Zwecke zu verwenden. Sei es als Wetterstation, WebRadio Anzeige, Öffi-Abfahrsmonitor, Uhr, Log-File Überwachung, usw ...
    Dazu muss das display prinzipiell über ein selbstgeschriebenes Programm gesteuert werden, welches eben nur die relevanten Daten bei jedem refresh überträgt, zB nur etwas Text. Somit bleibt die CPU-Last vernachlässigbar.

    Ich habe meinen Treiber eigtl. schon seit längerem deutlich aktualisiert aber noch nicht veröffentlicht, so dass nun wirklcih einfach individuelle Programme geschrieben werden können, C(++) Kenntnisse verausgesetzt.
    erzich: Darüberhinaus, hab ich auber auch ein paar simple Beispiel Programme geschrieben, mit denen man das Display aber auch bequem per kommandozeile steuern kann:
    1) Als Text-Anzeige der Linux StandardAusgabe. Somit kann man sich zB alle Ausgaben der linux kommdozeile auf dem display ausgeben lassen über eine pipe. zB als log-file überwachung oder zB ala "cat file > text2lcd"
    Das Problem damit ist die begrenzte Zeichenzahl pro Page. Ascii steuerzeichen werden zwar interpretiert (also tab und newline), aber das dipslay kann nur 40x15 Zeichen darstellen pro Seite. Eine (automatische) Seiten-weise Ausgabe steht auf meiner todo-list.
    2) Als Bild-Anzeige von PNG Bildern. Als simples kommandozeilenprogramm kann ein Bild auf dem Display darstellen mit dem Dateinamen als Argument. So kann man mit einem simplen shell-skript das dipslay als digitalen bilderrahmen verwenden zB.

    Der Treiber und die Beispielprogramme sind wie gesagt schon länger fertig. Ich hatte ledigleich noch keine Zeit die Dokumentationen und das Packageing abzudaten... Ich versuchs im laufe der woche hier noch zu releasen.

    p.s. der treiber wird neben der formatierten textausgabe nun auch PNG bilder anzeigen können, inkl. nettem überblend-effekt (im 4K farbmodus). obendrein ist ein farbmanagement integriert um zB Text/Fuellfarben bequem als RGB Triple zu definieren, welche dann automatisch in 65K oder 4K Farben umgerechnet werden.

    Cheers,
    Thomas

  • Hallo,

    ich hatte jetzt auch endlich mal wieder Zeit um etwas mit dem Display zu spielen.
    Die CPU Belastung bei X fps kann ich bestätigen, aber immerhin hat man bei 30%
    ein halbwegs nutzbares Bild. cvlc eignet sich bisher am besten um ein Video
    auszugeben, mplayer hat eine Option um direkt auf dem fb device abzuspielen
    aber das ist viel langsamer. Ein 320x240 mpeg Video geht nicht mal schlecht über
    cvlc, natürlich im Rahmen dessen was der Pi und Displaycontroller liefern können.
    Das läuft ja alles über die 234kB RAM dessen, und ganz taufrisch ist der auch nicht
    mehr :) fps lässt sich über fb2cberry.c einstellen und bei ca 25fps ist das Ergebnis
    in Ordnung, aber den "Seitenaufbau" von oben nach unten wird man immer sehen.
    Daher ist die jetzt vorhandene Lösung warscheinlich garnicht mehr zu verbessern.


    ThomasG
    Genau, das Display ist eigentlich nur dafür da über C(++) angesteuert zu werden,
    dann erfüllt es seinen Zweck und arbeitet ressourcenschonend. Man könnte sehr viele
    interessante Sachen damit machen, leider feht mir, wie warscheinlich 95%, das
    "know-how" :)


    Die Bildqualität des C-Berry ist völlig in Ordnung, man könnte es sogar Industriestandard
    nennen, aber die Oberfläche ist extrem anfällig, Vorsicht beim sauber machen !
    Meins ist nach der ersten Reinigung durch ein Brillenputztuch arg zerkratzt, vielleicht
    war aber auch ein Fremdkörper schuld. Gibt es Erfahrungen ?


    Mit freundlichen Grüßen

  • Hi,

    habe eben mein neues C-Berry Display getestet!
    Soweit alles fein :thumbs1: nur will er, bei dem UhrenBeispiel von barni7, unter Python den "droidsans" Font ums verrecken nicht verwenden!?
    Es werden nur leere Kästchen angezeigt?
    Andere Fonts funktionieren!
    Der Font ist "physikalisch" vorhanden (unter: /usr/share/fonts/truetype/droid/),
    wird aber scheinbar nicht verwendet?

    Gibt es hierzu noch einen "Trick"?
    Muss ich noch irgendwelche anderen Pakete installieren?

    System ist ein aktuelles, neu aufgesetztes Rasbian.


    Grüße,
    Jens

    Einmal editiert, zuletzt von jedo (21. Mai 2014 um 18:31)

  • Gibt es hierzu noch einen "Trick"?
    Muss ich noch irgendwelche anderen Pakete installieren?

    System ist ein aktuelles, neu aufgesetztes Rasbian.

    Selbe Ausgangssituation, bei mir hat's aber direkt funktioniert?!
    Hab nix extra installieren müssen. (EDIT: Zumindest nichts was über die Anleitung von barni7 und dbv's Erläuterung in Post#12 hinausgeht)

    Ich wünschte in dem Fall langsam ich könnte C leichter verstehen. Leider ist das nicht ansatzweise so einfach zu kapieren wie Python. Ich versuche wie bekloppt das von ThomasG beschriebene graduelle Ausschalten des Displays als C-Routine wie aus barni7's Vorgaben zu basteln und bekomme es einfach nicht hin.. lustig und frustig.

    Dafür kann ich zur Verwendung eines Alps Stec11B Encoders inzwischen die py-gaugette library empfehlen. Im Gegensatz zu allen anderen getesteten Möglichkeiten funktioniert die Ansteuerung damit bei mir wirklich absolut präzise. Webradio, ich komme ;)

    Einmal editiert, zuletzt von eqsOne (23. Mai 2014 um 11:28)

  • DerHagen
    Nein die Schutzfolie meinte ich nicht :) und arg zerkratzt war vielleicht leicht
    übertrieben, jedoch war vorher kein einziger Kratzer da und jetzt sieht man
    bei genauem hinsehen das überall kleine sind. Naja ist nicht so tragisch aber daher
    die generelle Warnung sehr vorsichtig zu säubern.


    Mal eine frage, weiss jemand wie man cvlc nach dem Start automatisch zum
    laufen bekommt ? Ich habe es mit crontab und rc.local versucht, jeweils auch als
    script aber nichts ging...

    Sinn ist den stream einer IP cam oder was auch immer auszugeben was auch bei
    manuellem Start gut funktioniert. Zu diesem zugegeben lächerlichen :lol::lol::lol:
    Test war ein Android Telefon mit "IP Camera" an Router 1 über Sat Zugang und
    der Pi mit C-Berry an Router 2 über DSL. Beide per Fritzbox VPN verbunden.
    Abgesehen von diesem Quatsch :) , obwohl eine Sat IP cam hat schon was und
    könnte an passender Stelle sogar sinnvoll sein, kann Internet über Satellit einen
    guten Upload bringen, ich habe schon bis zu 7,2Mbit geschafft von einem normalen
    Apache auf Debian Server. Aber das gehört ja hier nicht hin.

Jetzt mitmachen!

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