Übersicht serieller Grafik-LCD's?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    Aufgrund technischer Veränderungen ist der Mailverkehr innerhalb des Forums (Private Nachrichten) nur noch eingeschränkt möglich. Die Einschränkung ist notwendig, um zusätzliche Betriebskosten für das Forum zu vermeiden. Näheres zu den Hintergründen im Thread "Aktuelles zum Forum".Wir bitten um Verständnis.

    Hinweis kann nach Kenntnisnahme deaktiviert werden!

    • Übersicht serieller Grafik-LCD's?

      Hallo!

      Derzeit kämpfe ich gerade mit einem EADOGM128x64W den ich voreilig eingeplant habe, und immer mehr zweifel an dieser Entscheidung.
      Eben erst, wie schon öfters, suche ich nach möglichen Alternativprodukten:

      - Ansteuerung seriell (SPI oder I²C)
      - Pixelbereich 120x60 aufwärts, idealer weise farbe (RGB)
      - möglichst einfache grafische Steuerung (1)
      - Bascom-Lib die kompatibel mit anderen Slaves am Bus ist (2)

      Mit Bedingung (1) meine ich:
      Texte mit verschiedenen Fonts pixelgenau positionieren. Grafische Diagramme pixelbasiert über Gesamtfläche definierbar.
      Beispiel bei einem 120x60'er ein Werteverlauf über 120 Pixel breite (Zeitlinie) und 60 Pixel (Wertlinie) Pixel setzen.

      Genau sowas versuche ich gerade mit dem EADOGM128x64 und verzweifel daran, das alles in 8 Zeilen eingeteilt ist, und eben kein "Set Pixel 102, 44" geht.

      Mit Bedingung (2) meine ich das verhalten der glcdEADOGM128x6.lbx:
      Offensichtlich definiert sie die in der Config GraphLCD angegebenen Pins als Soft-SPI und blockiert somit meinen einzigen Hardware-SPI wo noch weitere Slaves bedient werden wollen.

      Was ich alles finde auf ebay und AliExpress sind entweder überteuerte Teile (>60€) oder eben nicht seriell :(

      Was gäbe es denn aktuell so an Alternativen in diesem Bereich? Kennt jemand vielleicht eine schöne Übersicht?

      Grüße

      Jürgen
    • Das nicht vorhandene pixelgenaue setzen beim EaDog liegt daran das im Seriellen modus nicht gelesen werden kann.
      Dafür hatte mal jemand hier ne Lösung vorgestellt in der der Displayonhalt im Prozessor ram liegt, dort werden die Änderungen gemacht und dann das ganze Bild auf einmal an das Display übertragen wird. dann geht auch wieder das pixelgenaue arbeiten.
      Eine alternative in einfarbig 128x64 mit einem st7490 währe eine Seriell-paralell umsetzung ähnlich wie beim Text display mit einem PFC8574, dann natürlich mit anderem Chip der mehr Pins hat.

      Für was richtig grossen und buntes vielleicht ein alter TFT sceen mit einem arduino VGADuino ? VGA auf HDMI umsetzer gibts auch falls du nen modernen Monitor nehmen willst
    • Hallo Mitch64!

      Mitch64 schrieb:

      Die EADoc Displays sind nach meiner Erfahrung recht gut.
      Warum willst du wechseln?

      Was ist das Problem was geht nicht? Vielleicht gibts ja eine andere Lösung als das Display wechsel.
      Vielleicht liegts auch gar nicht am Display?

      Nunja...das EADOGM128x64 ist "gut" für Testdarstellung verschiedener Fonts, wenn es alleine an einem exclusiven (Soft-)SPI hängt und die glcdEADOGM128x6.lbx funktioniert.
      Jedoch selbst dann sind keinerlei grafischen Befehle möglich wie z.B.:

      BOX, BOXFILL, LINE, CIRCLE und vor allem PSET welches ich gerade am wichtigsten bräuchte.

      Das alles und einiges mehr unterstützt die glcdEADOGM128x6.lbx nicht.


      Erschwerend bei mir kommt hinzu das bei mir nichtmal die glcdEADOGM128x6.lbx funktioniert:

      EADOGM mit weiteren Slaves am selben SPI-Bus (Hardware)?


      Das Problem ist bis heute unverändert und bestärkt mich in meiner These:

      Die Config Graphlcd legt zwanghaft auf den definierten Pins eine eigene Soft-SPI und blokiert damit meine Hard-SPI.


      Das führt dazu das ich mir nun einen Abeiern muss mit einem eigenen Minnimalfont mit ner riesigen Latte von Zeichen(8)-Arrays um überhaupt Buchstaben und Zahlen manuell ins Display zu bekommen. Das degradiert mein 128x64 LCD zu einem 8x8 Zeichen-LCD welches mit einem erheblichen Aufwand nur zu bedienen ist.


      Weiterhin ahnte ich bei der Planung nicht das solche Befehle wie PSET bei dem LCD gar nicht funktioniert.


      Sollte ich jemals nochmal etwas mit diesen EADOG's machen, dann nur rein textbasierte an einem exclusiven Soft-SPI.

      Und dafür ist das LCD m.E. etwas zu teuer, denn im Font8x8 kann es weniger anzeigen als ein 204 TestDisplay für einstellige €.


      Das mit Abstand einzige was mir mit diesen EADOGM128x64 noch einfällt, was zu testen wäre:

      Ob die Teile als Projektorfilter für eine unfocussierte Laserdiode taugen...


      Ne, was ich eventuell für dieses Projekt, aber erstmal für zukünftige Projekte suche wäre:

      Etwas vergleichbares an Display mit Einzelpixelsteuerung (PSET) über die komplette Anzeigefläche.
      Gerne mehr als 128x64 und eben so gerne auch in Farbe.
      Und wenn es geht primär günstige Sachen aus Fernost.

      Grüße

      Jürgen
    • In dem Link gibst du an, dass insgesamt 4 Geräte am Hardware-SPI betrieben werden sollen.
      Hier nochmal die Auflistung:


      1: Erstes EADOGM128x64 soll gemischt ca. 70-90% Testbasierend genutzt werden.
      2: Zweites EADOGM128x64 soll später 100% Grafik (xy-Charts) anzeigen.
      3: Ein RFM69HW FFSK-Modem
      4: Eine SDHC-Karte für ein kleines AVR-DOS als Datenlogger

      Frage 1:
      Laufen alle Geräte auf der gleichen Spannung wie der Controller? Und welche Spannung ist das? 3V, 5V?

      Frage 2:
      Verwendest du einen Pegelshifter? Wenn ja für welches (welche) Geäte?
      Also was ist wo genau angeschlossen?

      Wenn du eine Hardware-SPI konfiguriert hast, dann wird auch keine Soft-SPI eingebunden.
      Diese kann also deine Hardware-SPI nicht blockieren. Aber bei Verwendung von Pegelshiftern, die kein Tristate unterstützen, kann es zu Datenkollisionen kommen. Vielleicht ist das dein Problem.

      Bezüglich Grafik wie Boxen oder Kreise.
      @Schraubbaer hat es bereits erwähnt. Wenn das Display-Ram via SPI nicht auslesbar ist, weil nur Schreibleitung angehängt ist, können keine einzelnen Pixel manipuliert werden.

      Wenn du aber die Möglichkeit hast, das Display via 4-Pin oder 8-Pin Datenbus einschl. Write-Leitung anzuklemmen,
      dann lassen sich auch wieder Kreise darstellen.

      Aber bestimmt hast du die Platine schon fertig?
    • Hallo!

      Schraubbaer schrieb:

      Das nicht vorhandene pixelgenaue setzen beim EaDog liegt daran das im Seriellen modus nicht gelesen werden kann.
      Dafür hatte mal jemand hier ne Lösung vorgestellt in der der Displayonhalt im Prozessor ram liegt, dort werden die Änderungen gemacht und dann das ganze Bild auf einmal an das Display übertragen wird. dann geht auch wieder das pixelgenaue arbeiten.

      Hm, dieses hört sich für mich erst mal interessant an, müsste aber erst mal eruieren ob diese Lösung über die glcdEADOGM128x6.lbx läuft (geht bei meinem aktuellen Projekt nicht) oder ob die das EADOGM direkt ohne diese Lib ansteuert.

      Nur finde ich diese Lösung nicht.
      Meine mich aber daran zu erinnern das zumindest sowas in der Art mal damals im alten Forum diskussiert wurde.

      Schraubbaer schrieb:

      Für was richtig grossen und buntes vielleicht ein alter TFT sceen mit einem arduino VGADuino ? VGA auf HDMI umsetzer gibts auch falls du nen modernen Monitor nehmen willst

      Ja, sowas in der Art schwirrte mir vor einiger Zeit auch durch den Kopf.
      Da geht es um eine Anfrage eines kompletten Neudesigns von schon seit Jahrzehnten nicht mehr produzierter Geräte.
      Tischgeräte die Zustandswerte von Sensoren und Maschinen auf einem kleinen Display anzeigt, und rückseitig meißt einen fetten Multipin-Industriestecker haben.
      Dort wurden dann große Anzeigetafeln mit befeuert...so richtig Altertümlich mit bedruckter Glas- oder Plaxiglascheibe mit Lämpchen hinter.

      Mein Gedanke war spontan: Wenn ich sowas mal angehe, dann nur mit einer opionalen Schnittstelle wo man beliebige Monitore bis riesige Displays anschließen kann. Also irgendwas in Richtung HDMI.

      Aber davon ab: Hier geht es mir eher um kleine Teile. Wenn 128x64 für mich bissel eng wirkt, dann sage ich mal grob:
      Alles unterhalb oder bis 400x200 wäre interessant.
      oder mal so als Indiz noch worauf ich hinaus will:
      Habe mich vor einiger Zeit mal in die FTDI FT800-Familie eingelesen und lechtend nach entsprechenden LCD's gesucht.
      Was ich allerdings fand (>60€) war preislich nicht unbedingt meinem Bastelfaktor entsprechend.

      Grüße

      Jürgen
    • Die meisten EAdog kompatiblen displays mit st7565 haben nur seriell rausgeführt, Ich hab noch welche die Paralell können, sind aber industrie restposten, heisst wenn alle dann alle :(
      Ansonsten wenns Fernost sein soll gibts das backpack vom Digole: ebay.de/itm/371837002396
      Ähnlich dem von Sparkfun: eckstein-shop.de/SparkFun-Grap…0V1w-SEAQYAiABEgIaZvD_BwE

      Aber alls nichts was direkt und einfach als lib verfügbar ist


      Tobias
    • achso, hatte immer das gleiche dilemma, grösseres Display mit mehr und vor allem grösseren Pixeln ist nichtmehr günstig sobald du 128x64 verlässt. Da sind 60 euro schnell weg. Höher auflösende Displays bearbeitet ja Mister Display hier im Forum regelmässig, die sind aber doch recht klein mit ner riesen auflösung = Mäusekino :(
      Ich hab auch noch 3zu4 8,4" TFT Displays, sowas ist aber wenn du es nicht wie ich irgendwo kostenlos raussreissen darfst unbezahlbar.
      Und selbst für aktuelle 14" Monitore zahlste inzwischen wesentlich mehr als für ein 24" Monitor.
      Wenns um ein Statusdisplay geht kannst du natürlich über ne Halbklassische lösung nachdenken: Rückseitig bedrucktes Glas, ( oder bunter Folie aufkleben, dahinter LED für jede funktion/Position. Als luxusversion mit WS2812 für jeden "Pixel"

      Tobias
    • Hast du meinen Post #5 gelesen?

      In der Zwischenzeit habe ich mal das Datenblatt von dem EA DoGm128-6 angeschaut.
      Die Daten übernummt das Display mit steigender Clock-Flanke.

      Demzufolge ist diese Konfiguration nicht richtig.
      config SPI = HARD, INTERRUPT=OFF, DATA_ORDER=MSB , MASTER=Yes , POLARITY=Low , PHASE = 0 , CLOCKRATE=4 , NOSS=1

      Müsse wohl eher mit Polarity = High und Phase = 1 sein.

      config SPI = HARD , INTERRUPT = OFF , DATA_ORDER = MSB , MASTER = Yes , POLARITY = High , PHASE = 1 , CLOCKRATE = 4 , NOSS = 1

      Siehe Datenblatt Seite 5
    • Hallo Mitch64!

      Mitch64 schrieb:

      Frage 1:Laufen alle Geräte auf der gleichen Spannung wie der Controller? Und welche Spannung ist das? 3V, 5V?
      Alle digitalen Schaltungsteile laufen im Regelbetrieb auf Vcc 3,3V.
      Genaugenommen:
      Hauptspannungsversorgung kommt aus zwei parralelen 18650 LiIon. Wenn die *irgendwann* unter 3,3V rutschen sinkt auch Vcc, bis ein Reset-Controller bei 2,5V die Notbrense zieht. Vorher schon, nach viel gepiepe und geblinke mit der LCD-Beleuchtung sorgt ein N-FET dafür das bei 2,9V (ADC) der Tiefentladeschutz greift.

      Also exakt: Vcc extrem: 2,9-3,3V für alles.

      Mitch64 schrieb:


      Frage 2:
      Verwendest du einen Pegelshifter? Wenn ja für welches (welche) Geäte?
      Also was ist wo genau angeschlossen?
      Kein einziger Pegelwandler, weil nicht nötig.
      Das einzige an Besonderheit, wo ich mir aber keinen Fehler vorstellen kann:

      Zum Zeitpunkt des Schaltungsentwurfes bin ich an verschieden Stellen im Netz sowie auch in der Bascom-Hilfe über den Hinweis gestolpert das SD-Karten mit Datenfehlern reagieren können, wenn Daten über den SPI laufen ohne das die SD angesprochen wurde.
      Da ich aber nur einen HW-SPI habe und der für alle vier SPI-Slaves herhalten muss, habe ich den SD-Kartensockel über einen BUS-Schalter geführt.
      Ein PI3C3125-W14 sorgt dafür das der SPI am SD-Kartensockel vom restlichen SPI getrennt wird solange /CS der SD High bleibt.
      In diesem Zustand sorgen drei zusätzliche PullUp's (47k) dafür das die SPI-Signale an der SD-Karte High bleiben.
      Erst wenn /CS der SD-karte auf Low gezogen wird, schaltet der PI3C3125 die SD-Karte an den SPI.

      Letzteres war bislang noch nie der Fall, weil ich den Schaltungsteil in Bascom noch nicht angefangen habe (AVR-DOS).

      Habe mal den schon mehrfach angepassten Schaltplan angehängt, auf dem zwar noch einige Änderungen fehlen, aber zumindest der SPI-relevante Bereich durchweg aktuell ist.
      Letzte Änderung: PB4 war als Eingang genutzt, der ist nun totgelegt und fest als Ausgang definiert (ungenutzter /CS des SPI).

      Mitch64 schrieb:

      Wenn du eine Hardware-SPI konfiguriert hast, dann wird auch keine Soft-SPI eingebunden.Diese kann also deine Hardware-SPI nicht blockieren.

      Bist du dir darin absolut sicher?
      Als Konfigurationsbefehl nutze ich:
      Config GRAPHLCD = 128 * 64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7

      Und der Effekt ist folgender:

      Config GRAPHLCD = 128 * 64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7

      Config SPI = HARD, INTERRUPT=OFF, DATA_ORDER=MSB , MASTER=Yes , POLARITY=Low , PHASE = 0 , CLOCKRATE=4 , NOSS=1
      SPIINIT

      Führt dazu das das LCD nicht mehr reagiert, ich aber problemlos mit dem RFM69 sprechen kann.

      config SPI = HARD, INTERRUPT=OFF, DATA_ORDER=MSB , MASTER=Yes , POLARITY=Low , PHASE = 0 , CLOCKRATE=4 , NOSS=1
      SPIINIT
      Config GRAPHLCD = 128 * 64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7

      Führt dazu das das LCD wunderbar funktioniert, aber dann sind alle anderen SPI-Slaves (bisher der RFM69) tot. Kein lesen, kein Schreiben.

      Mitch64 schrieb:

      Bezüglich Grafik wie Boxen oder Kreise.@Schraubbaer hat es bereits erwähnt. Wenn das Display-Ram via SPI nicht auslesbar ist, weil nur Schreibleitung angehängt ist, können keine einzelnen Pixel manipuliert werden.

      Wenn du aber die Möglichkeit hast, das Display via 4-Pin oder 8-Pin Datenbus einschl. Write-Leitung anzuklemmen,
      dann lassen sich auch wieder Kreise darstellen.
      Aber bestimmt hast du die Platine schon fertig?

      Ja, die Platine ist schon fertig.
      Einen 4Bit oder 8Bit Mode sind mit dem EADOGM128 nicht möglich, weil nur die SPI-Pins rausgeführt sind.

      Grüße

      Jürgen
      Dateien
    • Zumindest wird keine Software-SPI generiert per Config SPI=Soft.

      Aber ich denke ich verstehe jetzt dein Problem.

      Also wenn du die Zeilen
      Config LCD=...
      und
      Config SPI=...

      vertauschst, dann funktioniert immer das, was zuletzt konfiguriert wurde.

      Die LCD-Lib steuert ja die Pins direkt an. Befehle über die Hardware SPI werden nicht direkt gesetzt.
      Sondern da sitzt die SPI-Hardware dazwischen. Das eine Schließt wohl das andere aus.

      Ich hätte jetzt 3 Vorschläge:

      Vorschlag 1:
      Die SPI als Soft-SPI konfigurieren. Dann greifen deine SPI-Anweisungen auch direkt auf die Pins zu.
      Das wäre ein Versuch wert.

      Vorschlag 2:
      Wenn Vorschlag 1 nicht geht, wirst du wohl fürs Display drei andere Pins als die SPI-Pins verwenden müssen.

      Vorschlag 3:
      Alternativ zum Vorschlag 2 könnte man die Kommandos, die ans LCD gehen auch per Hardware-SPI
      senden lassen. Dazu muss man aber 2 Routinen umbiegen und die Werte ins SPI-Daten-Register schreiben.

      Das Umbiegen der Ausgabe kann mit den Bascom-Direktiven
      $LcdPutCtrl und $LcdPutData gemacht werden.

      Schau dir dazu mal die Bascom-Hilfe an.

      Die Daten wie z.B. CLS wird dann in r24 (glaube ich) als Byte-Commando übergeben.
      In der neuen Routine musst du dann nur den Wert ins SPDR schreiben und warten, bis das Byte versendet ist (Abwarten, bis SPDR.SPIF gesetzt ist). CS nicht vergessen setzen und löschen.

      Musst aber weiterhin die Config Befehle für SPI und LCD angeben. Am besten SPI nach LCD.
      Grund: In den Libs werden Konstanten definiert, die von den Libs benötigt werden.

      Kannst es ja mal ausprobieren in der Reihenfolge wie angegeben.
    • Hallo Mitch64!

      Deine Hinweise Aus Post 9 + 11 habe ich mir mal in meinen Projektnotitzen gespeicher.
      Beim Abarbeiten der ersten Sachen habe ich mir irgendwas ganz mächtig verhuntzt.

      An deinen Hinweis aus Post 9 habe ich vor einiger Zeit auch schon mal gehabt.
      Bin aber davon wieder abgekommen, weil:
      RFM will POLARITY=Low , PHASE = 0 und damit kann ich (ohne Lib) auch problemlos das LCD ansprechen.

      Bislang allerdings nur Testmuster "Muster(128)" mit aufsteigenden Werten von h01-h7F, Zeilen löschen (128Bytes h00) und Zeilenwechsel.
      Die Lib würde mir bei den Texten helfen.

      Werde mich damit bestimmt kommende Woche nochmal extrem beschäftigen. Allerdings - das war auch die intention mit diesem Thema hier nach alternativen Displays, steigt in mir langsam der Zweifel auf ob ich da vielleicht die falsche Wahl getroffen habe.
      LCD nicht problemlos grafisch beherrschbar, der ATmega1284 hat nur noch einen Pin frei, mein derzeitiges Testprogramm reicht schon an 25-29% Flashauslastung obwohl ich AVR-DOS und Mini-Webserver noch gar nicht angefangen habe.

      Alternative Displays wären da erst der erste Schritt einer Überlegung, ein µC mit mehr Ports, mehr Flash, mehr SRAM würde warscheinlich irgendwo richtung ATXmega laufen..:-(

      Naja, ein paar Tage knie ich mich da nochmal rein das Projekt irgendwie mit dem EADOGM hin zu biegen.

      Grüße

      Jürgen
    • Hallo Schraubbaer!

      Schraubbaer schrieb:

      achso, hatte immer das gleiche dilemma, grösseres Display mit mehr und vor allem grösseren Pixeln ist nichtmehr günstig sobald du 128x64 verlässt. Da sind 60 euro schnell weg. Höher auflösende Displays bearbeitet ja Mister Display hier im Forum regelmässig, die sind aber doch recht klein mit ner riesen auflösung = Mäusekino :(
      Ja, bei "kleinen" LCD's tritt das gleiche Problem zu Tage wie mit neuen TFT's die man soch an den PC hängt.
      Kann mich noch vor einigen Jahren daran erinnern an den Umstieg von 600x725 oder so auf irgendwie 12xxXxxxx.
      Bei kleinen Displays ist es das selbe...egal ob 100x100 oder 400x400, wenn die aktive Fläche eben nur 3,5x3,5cm ist passt vielleicht mehr Info ins Display, ohne Brille oder Lupe bringt einem das aber wenig..:-)

      Geben tut es vieles, vor allem in Fernost sogar bezahlbar, die Frage ist nur: Hat irgend jemand sich schon mal damit beschäftigt welche LCD-Controller untereinander so kompatibel sind das sie eventuell mit einer Bascom-Lib ansteuerbar wären?
      Das Problem ist offensichtlich: Die Bascom-Hilfe wird gelegentlich überarbeitet, aber eher in Hinblick auf neue Befehle und Funktionen von Bascom, eher weniger mit aktuellen G-LCD Controllern.

      Mein aktuelles Sorgenkind, der EADOGM128 nutzt den ST7565R (allerdings nur CS, SCK und MOSI rausgeführt)

      Die auf dem ersten Blick interessanten Displays haben dagegen eher Controller wie ST7735, ST7789 oder ILI9341, ILI9225 und diverse andere:


      de.aliexpress.com/item/32996979276.html
      de.aliexpress.com/item/33012793224.html

      Wobei ich sehe das die meißten dort auch wieder das gleiche Problem wie der EADOGM haben: SPI ohne MISO.
      Lediglich größeren aus dem zweiten Link ist komplett bestückt mit einer kompletten SPI.
      Also ab 2,2"

      Was die Kompatibilitäten mit anderen Controllern angeht finde ich im Web aber nur skurile und teils fragwürdige Infos die alle sammt von der RasberryPI-Fraktion stammten. Also nix mit hardwarenahen Infos, nur dove Anleitungen welche Github-Schnipselchen für diverse Controller gebraucht werden usw.

      Grüße

      Jürgen
    • Hallo Mitch64!

      Mitch64 schrieb:

      Vorschlag 1:Die SPI als Soft-SPI konfigurieren. Dann greifen deine SPI-Anweisungen auch direkt auf die Pins zu.
      Das wäre ein Versuch wert.
      Das war's!!!!

      BASCOM-Quellcode

      1. Config GRAPHLCD = 128 * 64eadogm , Cs1 = Porta.4 , A0 = Porta.6 , SI = Portb.5 , SCLK = Portb.7 , Rst = Porta.7
      2. initlcd
      3. Config SPI = Soft, DIN = PinB.6, DOUT = Portb.5, SS = NONE, Clock = Portb.7, MODE = 1
      4. spiinit

      Zumindest bisher (seit einigen Minuten) laufen parallel der RFM69HW sowie die Ausgabe der RTC in Zeile 1 des LCD's augenscheinlich zuverlässig.
      Das Einzige was ich mir nun für Gedanken mache ist die SPI-Geschwindigkeit.

      Die ATmega1284 läuft mit 11,0592MHz Baudquarz, also so ziemlich die höchste Baudgerechte Clock die für 3,3V noch spezifiziert ist. Zwischen CS-Card (SPI) und ESP (UART 115200Bd) soll später der Datenlogger ausgelesen werden (einige MB erwarte ich).
      Daher habe ich mich damals auf die HW-SPI festgelegt.
      Muss ich mit der Soft-SPI nun mit drastischen Performanceeinbrüchen Rechnen?

      Grüße

      Jürgen
    • Hallo!

      Mein Einstieg mit dem EADOGM in die grafischen LCD's ist ziemlich holprig.

      Bisher habe ich häufig bei Text-LCD's 162 - 204 in unterschiedlichen Subs einzelne Felder selektiv beschrieben.
      Beim EADOGM läuft das schief.

      Oberste Zeile wird als Zeitanzeige sekündlich geschrieben.

      Lcdat 1 , 1 , Wochentag ; " " ; Date$ ; " " ; Time$


      Dritte Zeile wird bei Empfang und nach Decodierung eines Datenpaketes vom RFM69 aktualisiert.

      If RX_0(1) = &hA0 then
      lcdat 3, 40, "Repeater"
      end if

      If RX_0(1) = &hA1 then
      lcdat 3, 40, "Sensor 1"
      end If


      Unterste Zeile wird einmal die Minute aktualisiert.

      AkkuS = Fusing(Akkuspannung1, "#.###")
      Lcdat 8, 1, "Akku: ";AkkuS;"V "



      Sieht dann so aus wie im ersten Bild.

      Nach ein paar Minuten "scrollt" die Anzeige aber ziemlich durcheinander (Bild 2) bis zu einem Zustand wo alle Zeilen ausserhalb der Anzeigefläche liegen.

      Ich ahne es wäre wohl sinnvoller das EADOGM in einer eigenen Sub komplett in einem Schub zu beschreiben...

      Jürgen
      Dateien
      • DSCF5246.jpg

        (89,98 kB, 15 mal heruntergeladen, zuletzt: )
      • DSCF5247.jpg

        (98,18 kB, 14 mal heruntergeladen, zuletzt: )
    • DG7GJ schrieb:

      Muss ich mit der Soft-SPI nun mit drastischen Performanceeinbrüchen Rechnen?
      Hi Jürgen
      Ich denke nicht, dass du mit wesentlichen Geschwindigkeitseinbußen rechnen musst.
      Das hat auch einen einfachen Grund.
      Wenn Bascom z.B. 100 Byte über die Hardware-SPI einliest, schreibt der eine 0 ins SPDR (Datenregister) und wartet, bis das gesendet ist (SPSR.SPIF gesetzt).
      Dann wird das 2. Byte angefordert, also wieder eine 0 ins SPDR schreiben, warten bis abgesndet. Das macht der 100x für 100 Byte.
      Bei Soft-SPI wartet der Controller nicht, sondern bedient die Pins. Ich denke da wirst du nicht viel merken.

      Anders ist es, wenn du Daten per Interrupt im Hintergrund über die HW-SPI einlesen lässt, dann kann die Wartezeit für andere Aufgaben genutzt werden. Dann hättest du einen Gewinn. Also von dem her glaube ich nicht, dass du da wesentliche Einbußen hast gegenüber Hard-SPI. Beim Schreiben ist es das gleiche, nur in die andere Richtung.

      DG7GJ schrieb:

      Sieht dann so aus wie im ersten Bild.
      Ich kenne solche Effekte von anderen Displays wie die 128x64 Grafik-Displays (Einfarbig). Wenn man da Texte ausgibt, die über den rechten Rand hinaus schreiben, dann zerfleddert es den ganzen Display-Inhalt.
      Tip: Achte drauf, dass deine Texte und Zahlen nicht über den rechen Rand schreiben. Das sind evtl. Rambereiche, die vielleicht nicht unbedingt für die Display-Daten gedacht sind.
    • DG7GJ schrieb:

      Muss ich mit der Soft-SPI nun mit drastischen Performanceeinbrüchen Rechnen?
      Ja, klar. Bei Hard-SPI ballert er die Daten raus, das geht in den MHz Bereich, je nach Clock-Einstellung.
      Bei Soft SPI musst du jeden Pegelwechsel einzeln machen und blockierst dabei noch das Programm.

      DG7GJ schrieb:

      Nach ein paar Minuten "scrollt" die Anzeige aber ziemlich durcheinander
      Stack zu klein?

      Jeder SPI Slave braucht seinen eigenen CS Pullup, der CS muss auch im Programm gesetzt werden.
      Ein Wechsel verschiedener SPI Konfigurationen zur Laufzeit geht über die Register.
    • Michael schrieb:

      Ja, klar. Bei Hard-SPI ballert er die Daten raus, das geht in den MHz Bereich
      Du hast recht. Ich habe das mal gemessen.
      Da ich kein 11,ungrad Quarz da habe, habe ich es mit 8MHz und 12MHz gemacht und Hard- und Soft-SPI gegenüber gestellt.

      Ausgegeben wurden 50 Byte und die Zeit gemessen.
      Das Ergebnis steht im Kopf vom Testprogramm.

      BASCOM-Quellcode

      1. ' Messen der Ausgabedauer von 50 Byte per Hardware-SPI bzw. per Software-SPI
      2. ' TestPin (PortB.0) wird für die Dauer der Ausgabe High geschaltet.
      3. ' Die Ausgabedauer kann per Oszi gemessen werden.
      4. ' Ergebnis:
      5. ' Systemtakt | Hard-SPI | Soft-SPI
      6. ' -----------|----------------|--------------
      7. ' 8MHz | 340,5µs | 835,0µs
      8. ' | (2724 Takte) | (6680 Takte)
      9. ' -------------------------------------------
      10. ' 12MHz | 227,5µs | 557,0µs
      11. ' | (2730 Takte) | (6684 Takte)
      12. ' | (SCK: 3MHz) | (SCK: 800kHz)
      13. $Regfile = "m168def.dat"
      14. $Crystal = 12000000
      15. Config Base = 0
      16. Dim DataArray(50) as Byte
      17. Dim i as Byte ' Index
      18. TestPin Alias PortB.0 ' Dauer der Datenausgabe messen (Oszi)
      19. Config TestPin = Output
      20. SS Alias PortB.2 ' SS-Pin Controller
      21. Config SS = Output
      22. 'Config SPI = HARD , INTERRUPT = OFF , DATA_ORDER = MSB , MASTER = Yes , POLARITY = Low , PHASE = 0 , CLOCKRATE = 4 , NOSS = 1
      23. Config SPI = Soft , DIN = PinB.4 , DOUT = Portb.3 , SS = NONE , Clock = Portb.5 , MODE = 1
      24. SPIINIT
      25. For i = 0 to 49 ' Array befüllen
      26. DataArray(i) = $AA
      27. Next
      28. Do
      29. Waitms 500
      30. Set TestPin
      31. SPIOut DataArray(0) , 50
      32. Reset TestPin
      33. Loop
      Alles anzeigen

      Faktor zwischen Hard- und Soft-SPI liegt bei ca. 2,45 bei 12MHz Systemtakt.

      Man kann das aber sicherlich beschleunigen, wenn man eigene Routinen schreibt (in Assembler).
      Gerade, wenn du später so riesige Datenmengen auslesen willst, würde sich das vermutlich bezahlt machen.
    • Hallo!

      Tja, wieder ein Argument für ein Redesign.
      Aber egal, ich versuche nun erst mal mit der vorhandenen Hardware so weit zu kommen bis es in den Wirkbetrieb geht.

      Im Kern soll es die Sensordaten von 8, später maximal 14 Sensoren (relative Luftfeuchtigkeit + Temperatur aus ChipCap CC2D sowie Luftdruck + Temperatur aus MPL3115A2) empfangen.

      Aus SD-Karte sollen die Rohdaten-Pakete mitgeloggt werden.

      Die grafischen LCD's sollen die decodierten Werte über den zeitlichen Verlauf als Diagramm anzeigen.
      Stelle ich mir grob wie folgt vor:
      Luftfeuchtigkeit 0-100%, Temperatur 0-40°C, Luftdruck 900-1200,xxhPa, daraus errechnet die Abs. Luftfeuchtigkeit und darauf basierend den Taupunkt.

      Wären für ein monocromes LCD wie dem EAGOGM128x64 also 5 Diagrammseiten je Sensor.
      Mit RGB-LCD's/TFT's wäre es vielleicht übersichtlicher, weil man die einzelnen Wertkanäle in unterschiedlichen Pixelfarben übereinander auf eine Seite legen könnte.

      Tja, und größere Chips...gäbe da noch welche in TQFP-64 und TQFP-100, ATmega2561 und halt ATXmega.
      Naja, kommt Zeit, kommt Rat.

      Grüße

      Jürgen