Ich würde an ein Embedded-Linux-Board gerne ein kleines zweizeiliges Textdisplay bauen.
Ich habe dieses hier da:
formatting link
Und hoffte, dass ich selbiges einfach auf die von mir verwendete Plattform umbauen könnte:
formatting link
Allerdings geht das eben leider nicht so einfach. Alles, was wirklich funktioniert, sind GPIO-Pins, die ich "High" oder "Low" setzen kann. Für SPI fehlt wohl das unterstützende Kernel-Modul.
Aktuell weiß ich nichtmal mit welcher GPIO-Nummer ich welchen Pin steuere und welche Pins überhaupt steuerbar sind.
Da mir bei einer solchen Basis SPI zu kompliziert scheint die Frage: Gibt es etwas wirklich einfaches das man über ein paar einzelne setzbare/löschbare Bits zum Text-Anzeigen bewegen kann?
SPI ist als synchrones Protokoll auf Master-Seite nicht timingkritisch, es kann also auch mal ein wenig ungleichmäßig laufen, solange die Maximalfrequenz nicht überschritten wird.
Das macht es leicht, auch unter Nicht-Echtzeitbedingungen einen funktionierenden Master mit Bit-Banging zu realisieren. Viel leichter, als es z.B. wäre, asynchrone Protokolle wie etwa RS232 unter denselben Umständen zu realisieren.
Alternativ könntest du auch die allseits bekannten Displays nach "Industriestandard" einsetzen, also die HD44780-kompatiblen. Deren Protokoll ist ebenfalls synchron, hat also auch die Eigenschaft, beliebig langsamer sein zu können.
Ich bin der Meinung, daß SPI von der Programmierung her deutlich einfacher ist, es gibt nur zwei verschiedene Zeiten, deren Minimalwerte einzuhalten sind. Bei den HD44780 sind es viel mehr verschiedene Zeiten, die einzuhalten sind und diese sind abhängig vom gesendeten Kommando, es ist also nicht möglich, den Protokoll-Layer vom Anwendungs-Layer zu trennen.
Nö, SPI ist wirklich deutlich einfacher. Und obendrein universeller, denn wenn der Protokoll-Layer erstmal steht, kann man auch andere Sachen als Displays darüber betreiben. Und, last but not least: man braucht auch weniger Pins als für HD44780, nämlich im jeweiligen Minimum nur drei statt sechs.
Seite 39: würde mal vermuten, daß "Linux GPIO" die Pinnummer unter Linux ist, die du also wie üblich unter /sys/class/gpio ansprechen kannst, wie dort auf Seite 14 demonstriert, und "OLinuXino GPIO Connector #" ist die Nummer des Pins, wie auf Seite 37 zu sehen.
Am einfachsten wird aber wohl sein, den UEXT-Connector zu verwenden (auch auf Seite 37 beschrieben), denn dort ist bereits SPI dran: MOSI, MISO, SCK und CS. Ich habe das Board zwar nicht, aber würde mich wundern, wenn dazu nicht bereits das Kernel-Modul vorhanden ist, da der iMX233-Prozessor eigentlich gut von Linux unterstützt wird. Musst du ggf. erst per "modprobe" laden, da ansonsten der Pin bereits beim Booten als SPI reserviert würde und nicht mehr als normaler GPIO verwendet werden könnte (wenn noch nicht das neue Linux Pin-Mux-Konzept verwendet wird). Hier ein Beispiel, wie das beim Raspberry Pi für I2C geht:
formatting link
Danach sollte dann auch einfach das gnublin-dogm Programm laufen, was den SPI-Treiber verwendet.
Geht das nicht, kannst du auch normale GPIO-Pins nehmen und per Bitbanging das SPI-Protokoll selbst implementieren. Am einfachsten wäre dabei, das Programm von denen als Basis zu nehmen:
formatting link
und du brauchst dann nur den ioctl-Aufruf in der Transfer-Routine per Software zu implementieren, was ziemlich einfach ist. Siehe z.B. die Funktion "oneArgumentCommand" hier:
formatting link
Sollte problemlos laufen, wenn du spiData, spiClock und spiSelect für Linux umschreibst, um den GPIO-Pin anzusteuern und ggf. erst spiClock auf 1, dann auf 0, statt erst auf 0 und dann auf 1 zu setzen, je nach verwendeten SPI-Modus.
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
Hab das Datenblatt nur kurz überflogen, aber es scheint ähnlich den "normalen" HD44780 Displays zu sein. Du kannst also nach Beispielcode für HD44780 kompatiblen Displays suchen.
Das sollte reichen. Man kann auch SPI in Software realisieren. Aber wenn du genügend IOs hast, ist es parallel vermutlich einfacher.
Kann man. Ich würde den 4-Bit Modus wählen. Dann benötigst du 6 Bits wenn ich mich nicht irre. Die 4 Datenbits an D7..D4, die RS_Leitung, und WR*.
Enable kannst du normalerweise fest an High legen. Lesen musst du nicht, nur langsam genug schreiben.
Kann aber einiges an Frust verursachen, bis es zum erstenmal funktioniert.
Ja, mehrfach. Plane das anstehende Projekt schon eine ganze Weile und habe im Netz verschiedene Boards verglichen.
Das die angebotenen Ports auch funktionieren habe ich einfach mal als gegeben angenommen.
Tja. Dachte ich auch. Aber Fehlanzeige... :(
Was GPIO angeht wird das zum Ratespiel. Das Beispiel mit dem "LED blinken lassen" funktioniert auch nicht. Einen GPIO 65 gibt es laut Kernel garnicht.
Die Threads, die ich dazu aufgemacht habe, sind bisher unbeantwortet:
formatting link
Und eine Google-Suche ergibt, dass es für den Kernel zwar wohl irgendwelche Patches gibt, aber eigentlich wird mir das ganze ab dem Punkt zu fummelig.
Mein Fazit zum Olinuxino: Top Hardware die wirklich durchdacht ist und mit wertigen Komponenten aufgebaut wurde.
Aber: Fummeliges GPIO und mindestens fehlender Kernel-Support für SPI.
Auch wenn ich die Olinuxino-Boards eigentlich sehr interessant gefunden habe, wird meine kurzfristige Lösung für dieses Problem sein, dass ich mir einen Raspberry anschaffe.
Eigentlich habe ich etwas gegen diese Hype-Plattform, aber ich gehe mal davon aus, dass eben durch den Hype dort die Software eigentlich top sein sollte.
Olinuxino behalte ich für Aufgaben bei denen ich die Hardware-Ports nicht brauche. Und wegen der Software werde ich mal den Hersteller wissen lassen, dass ich einen funktionierenden SPI-Support ganz nett gefunden hätte.
Klingt nicht gut. Zumindest die GPIO-Ports sollte man doch laut Manual ansprechen können, sonst sollten die das korrigieren.
Schonmal bei Olimex angefragt? Die haben auf der Homepage unten eine Support eMail-Adresse angegeben:
formatting link
Vielleicht wissen die auch was zum SPI-Treiber. Zumindest die Software-Emulation ist in Linux nur ein Config-Eintrag setzen und die Pins in der Hardware-Description definieren, was eine Sache von Minuten ist, wenn man die Cross-Compiler Umgebung usw. sowieso schon aufgesetzt hat. Ich hatte die I2C-Implementierung auch erst so auf dem Rasperry Pi getestet, bevor ich dann den Treiber für das Hardwaremodul selbst geschrieben habe, was mittlerweile in den offiziellen Raspberry Pi Kernel integriert wurde.
--
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss
Geht ja auch. Bleibt nur die Frage was ich mit was bediene und warum ich auch mit einer Schleife, die alles von 0 bis 255 als GPIO-Port auf gut Glück erst auf 1 und dann auf 0 bringen sollte, die LED keine Anstalten gemacht hat irgendwie zu reagieren.
Hin und wieder landet man aber schonmal einen Treffer und findet einen Ausgang und eine GPIO-Nummer die zusammenpassen und kann eine daran angeschlossene LED dann auch steuern.
Für mein Display werde ich wohl zwei GPIO-Ports finden, die ich missbrauchen kann. Müssen auch nicht auf dem UEXT-Connector sitzen, denn ich werde an der Stelle des Connectors ohnehin eine Platine andocken und die kann einen brauchbaren GPIO auch vom langen Connector abholen.
Was SPI angeht bin ich aber schon was weiter. Wenn ich mich nicht täusche haben die bei Archlinux ARM schlicht die Konfigurations-Option "SPIDEV" nicht gesetzt. Weiterhin gibt es für den Kernel einen Patch der einen Bug im SPI beseitigt. Konfiguration habe ich korrigiert und Patch mit eingebaut. Aktuell kompiliert mein Olinuxino den Kernel. Das geht behäbig aber braucht dafür kaum Strom. Werde das also so die Nacht durchlaufen lassen.
Wenn es so funktioniert, dann wird mein nächster Versuch sein mal den aktuellen Kernel von kernel.org zu bauen. Dort sind einige der Patches, die beim Archlinux ARM Kernel noch nötig sind, schon fest integriert und möglicherweise auch noch mehr Bugs gefixt.
Am Sat, 24 Aug 2013 20:57:58 +0200 schrieb Manuel Reimer:
Wahrscheinlich müssen die vor Verwendung initialisiert werden. Wissen die Pins schon dass sie Ausgang sind?
Was ist denn das für ein rumgestocher? Die Pins des Boards werden doch wohl dokumentiert sein?
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Am Fri, 23 Aug 2013 17:29:35 +0200 schrieb Manuel Reimer:
Das ist als Information etwas dünn.
Gibt es Fehlermeldungen beim ausführen der Befehle? Existieren die Verzeichnisse und Dateien in die in dem Beispiel im Manual auf Seite 14 die Werte out und 0 oder 1 geschrieben werden?
Läuft im Hintergrund der Prozess der dann letztendlich mit diesen Werten die Pins ansteuert?
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Der Olinuxino ist nicht fähig seinen eigenen Kernel zu kompilieren. Die
64MB RAM sind ruck zuck voll. Mit Swap geht es zwar weiter, aber nach 24 Stunden habe ich das ganze dann abgebrochen.
Auf meinem Desktop habe ich einen Crosscompiler improvisiert und schaffe damit auch lauffähige Kernel zu bauen. Mit dieser Anleitung bin ich dann zu einem "spidev" unter "/dev" gekommen:
formatting link
Auch das gnublin-dogm-Tool habe ich für den Olinuxino gebaut und dann das Display korrekt angeschlossen (dreimal geprüft).
Das Tool gibt aus, das Display würde nun korrekt anzeigen. Keine Fehlermeldung. Auf dem Display landet aber *nichts*.
Ich weiß an der Stelle jetzt echt nicht mehr weiter und werde das Gefühl nicht los mit dem Thema schon wieder viel zu viel Zeit verschwendet zu haben.
Am Tue, 27 Aug 2013 22:51:40 +0200 schrieb Manuel Reimer :
Falls vorhanden, mit einem Oszi auf den SPI-Bus gucken, ob der auch arbeitet, den Takt natürlich auch. Ohne Scope womöglich: Eine LED zum Test ankoppeln wird nix bringen, vielleicht ein Lautsprecher über hochohmigen Widerstand zum abhören - geht das, hat das mal wer versucht?
Ebenfalls, falls vorhanden: mit einem anderen Controller mal das Display ansteuern? Aus der gleichen Versorgung speisen und nur die SPI-Leitungen mal zum anderen Controller rüberstrippen.
jedenfalls irgendwie systematisch eingrenzen, wo der Fehler liegt. Dann gezielt da schrauben ...
Habe ich nicht und habe auch nie gelernt mit sowas umzugehen.
Guter Gedanke. Vielleicht ist der Fehler ja auf meiner Display-Platine und dann kann ich am Code lange schrauben.
Am Raspberry sollte das LCD eigentlich ohne viel Gebastel laufen (wird vom gnublin-dogm Tool offiziell unterstützt). Folglich wäre das durchaus eine Option einen solchen mal als zweite Testplattform zu besorgen.
Am Wed, 28 Aug 2013 00:05:20 +0200 schrieb Marc Santhoff:
Soundeingang vom PC oder anderen NF-Verstärker, einfach mal lauschen ob sich auf den Pins überhaupt was tut.
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Messwerte nachträgliche Wärmedämmung http://www.messpc.de/waermedaemmung.php
Am Wed, 28 Aug 2013 11:08:15 +0200 schrieb Manuel Reimer :
Daraus kann man schließen, daß der SPI-Bus (und die Software dran) versucht seine Aufgabe zu erfüllen.
Also wird entweder Blödsinn bzw. nicht verständliches zum Display gesendet oder die Displayhardware ist nicht OK. Ersteres sollte leicht zu fixen sein, die Initialisierungen, etc. sind ja gut dokumentiert und Beispielcode dazu gibt es auch reichlich. Ein fertiges Tool muß natürlich das richtige Display konfiguriert haben.
IIRC ist CS bei den DOGs invertiert, sollte also nach Masse gezogen werden, damit es aktiv wird.
Wer treibt das Signal denn? Ich kenne es auch nicht anderes als Marc es schrieb, wenn ein Chip einen Datentransfer annehmen soll, muss dessen Chip Select dabei auf Low sein.
Am Wed, 28 Aug 2013 12:30:34 +0200 schrieb Manuel Reimer :
Im schnell gegriffenen Datenblatt zum DOGM wurden 2K als Pulldown benutzt.
Vergessen den Port einzuschalten, auf Ausgang zu schalten und ggf. (z.B. bei STM32-Chips) den Timer für die Hardwareabteilung einzuschalten?
Vielleicht den Codeteil, der CS schaltet mal separat in einem Programm benutzen, um schön langsam (=sichtbar) eine LED + Pulldown gegen Ub zu schalten? So im 1000ms-Rhytmus wäre passend.
Auch mal im System-Log gucken, ob das Fehlermeldungen auftauchen.
Der Teil (CS) wird vom "gnublin-dogm"-Programm komplett an das Usermode-Interface für den SPI-Bus abgetreten.
Wie schon oben angedeutet: CS wird vom "spidev"-Treiber mitverwaltet. Über die GPIO-Schnittstelle kommme ich an diese Ports, weil schon vom SPI-Treiber belegt, nicht ran.
Der Hersteller, bzw. die Community um den Olinuxino, hat aber auch nicht wirklich viel Interesse mir bei dem Problem irgendwie zu helfen:
formatting link
Raspberry ist bestellt und kommt morgen. Wenn es damit geht, dann baue ich mein Projekt um den Raspberry herum auf.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.