Display, welches *einfach* via GPIO angesteuert werden kann?

Wurde mir vom Entwickler des Gnublin-Displays, dessen Ansteuerprogramm ich ja verwenden will, nun auch geschrieben.

Was mir auch spanisch vorkommt ist die Tatsache, dass ich den CS-Pin nicht festlegen kann. Eigentlich ist doch das der Weg um mehr als ein Device an den SPI zu hängen, oder?

Umstellen des CS-Pin geht auf der Olinuxino-Plattform nicht: [root@alarm gpio]# modprobe spidev cs_pin=33 [ 1119.680000] spidev: `33' invalid for parameter `cs_pin' [root@alarm gpio]# modprobe spidev cs_pin=1 [ 1338.840000] spidev: `1' invalid for parameter `cs_pin'

Ich würde behaupten, dass mindestens der CS-Pin im Kernel-Treiber falsch gehandhabt wird. Auf den anderen Anschlüssen habe ich ja Aktivität festgestellt.

Um das auszuschließen wäre ich dankbar wenn mir nochmal jemand einen Tipp geben könnte.

Das gnublin-dogm-Tool sendet nur zum SPI-Port. Es wird nie gelesen. Was muss denn der CS-Pin tun wenn gesendet wird? Low ziehen vor dem Senden und danach wieder auf High? Wenn dem so ist, dann programmiere ich mir um die Senderoutine jetzt ein paar Codezeilen die einen von mir festgelegten GPIO-Pin genau so ansteuern. Und dann sehen wir ob das Display mit dem selbstgebauten CS läuft.

Gruß

Manuel

Am Sun, 01 Sep 2013 09:50:49 +0200 schrieb Manuel Reimer:

Ohne mir das jetzt im Detail angeschaut zu haben: spricht etwas dagegen CS des LCD-Moduls fest auf Low zu legen? Die Adressierung der Teilnehmer am SPI-Bus (falls mehrere vorhanden wären) erfolgt doch anderweitig.

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 Sun, 01 Sep 2013 10:13:25 +0200 schrieb Lutz Schulze:

Nämlich wie?

Verwechselst Du vielleicht SPI und IIC ...?

Ade

Reinhard

Am Sun, 01 Sep 2013 09:50:49 +0200 schrieb Manuel Reimer:

Genau. Theoretisch müßte man nach der fallenden Flanke von CS ein paar (zig) Nanosekunden warten, aber das erledigt wohl das Betriebssystem ...

Allerdings musst Du irgendwie sicherstellen, dass auch die der letzte Taktimpuls raus ist, bevor CS wieder inaktiv wird. Normalerweise gibt's da ein Statusbit, aber notfalls geht auch eine einfache Wartezeit von ca. 10

• SCL-Periode.

Einen Versuch ist's sicher wert.

Ade

Reinhard

Am Sun, 01 Sep 2013 09:50:49 +0200 schrieb Manuel Reimer :

Genau, mit Wartezeit hinten dran, wie schon jemand schrieb.

Das Testprogramm kannst Du dann gleich nochmal minimal ändern und statt des Displays einfach nur eine LED + Vorwiderstand oder ein Voltmeter an den CS hängen. Im Sekundentakt geschaltet läßt sich unabhängig davo n, ob das Display funktioniert, die Funktionsfähigkeit von Kernelcode und CS-Pin feststellen. Vielleicht ist der Pin kaputt und alles andere nicht?

Marc

Am 1 Sep 2013 11:15:30 GMT schrieb Reinhard Forster:

Ups, da habe ich beim überfliegen doch nur die Hälfte herausgelesen (siehe hier Bild 1, Kaskadierung der Slaves).

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 Sun, 01 Sep 2013 14:49:05 +0200 schrieb Lutz Schulze:

Na ja, das ist eigentlich keine Adressierung der Slaves, die Daten werden einfach durch alle Bausteine durchgeschoben (Prinzip Schieberegister).

Ade

Reinhard

Sowas habe ich in der Praxis noch nie gesehen (außer bei JTAG). Üblich ist die Sternverbindung.

CS fest auf Low legen geht meist auch nicht, da eine fallende CS-Flanke normalerweise den Beginn einer Übertragung signalisiert, nach der z.B. Adresse und Daten geschickt werden. Wenn es konstant auf Low ist, dann gibt es keine Markierung, wann die Adresse anfängt. Wobei es aber auch Ausnahmen gibt. Z.B. kenne ich einen AD-Wandler, bei dem die Kommunikation auch zurückgesetzt und somit synchronisiert werden kann, indem eine gewisse Anzahl Nullen gesendet wird, und jedes Adresswort mit einer binären 1 beginnt. Sowas ist aber selten.

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss

Ich habe jetzt verschiedene Szenarien durch.

Sehr auffällig ist, dass, obwohl im Datenblatt beschrieben ist, das die zwei SSP-Ports nichts miteinander zu tun haben, beim intensiven Schreiben auf den SPI-Port reichlich Traffic an den Pins des SD-Kartenslots zu vermerken ist. Ich habe das doofe Gefühl mein CS fällt da raus. Nach dem Beenden meines Testprogramms hängt das ganze System eine Weile. Sogar ein harmloses "ls" scheint komplett stecken zu bleiben. Das ganze fängt sich dann nach einiger Zeit wieder.

Morgen teste ich meine Display-Platine mal am Raspberry. Wenn sie dort geht werde ich wohl oder übel den Raspberry als Basis nehmen. Damit bekomme ich zwar neue Probleme, aber das optimale Board scheint es schlicht nicht zu geben...

Gruß

Manuel

Was meinte denn der Olimex Support dazu, daß du die GPIO-Pins nicht ansprechen kannst? Du solltest dir vielleicht überlegen, ob du das richtige Hobby hast, wenn du SPI nicht per Software über GPIO selbst implementieren kannst :-)

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss

Noch keine Antwort.

Leicht abgewandelt ging das vor einigen Tagen auch direkt an Olimex direkt via Mail. Ich habe von denen in der Vergangenheit schonmal Antwort erhalten. Hat damals aber auch schon einige Zeit gedauert.

Es ist noch kein Meister vom Himmel gefallen ;)

Und mit C(++) stehe ich nunmal auf Kriegsfuß. Ich brauche einfache Usermode-Treiber mit denen ich mit meiner Hardware sprechen kann.

Wie SPI komplett auf Basis von GPIO gehen soll ist mir ein Rätsel. Mir reichen schon die kryptischen Codesequenzen um das Display zu initialisieren und Daten darauf auszugeben.

Gruß

Manuel

Ich hatte ja schon ein Beispiel gepostet. Hier noch ein schön formatiertes und dokumentiertes aus der Wikipedia:

Musst du natürlich statt "output_high(SD_CS);" am Anfang "output_low(SD_CS);" schreiben, da dein Display ein Low für CS braucht, wenn Daten geschrieben werden. Und es wird dort kein MISO verwendet, du kannst also damit keine Daten vom Display lesen. Aber für dein Display brauchst du ja nur schreiben, vermute ich mal. Ansonsten nach "spi bitbanging" im Web suchen und eins der tausenden von anderen Beispielen ansehen.

Fehlt dann nur noch die Implementierung von output_high/output_low zur Ansteuerung der GPIO-Pins, was bei allen Linux-Systemen gleich ist. Hier ein Beispiel, was man einfach übernehmen könnte:

--
Frank Buss, http://www.frank-buss.de 
electronics and more: http://www.youtube.com/user/frankbuss

Am Sun, 01 Sep 2013 21:05:01 +0200 schrieb Frank Buss:

Natürlich. Es gibt aber Fälle, wo mehrere _gleiche_ Bausteine eingesetzt werden, z. B. elektronische Potis. Heißt dann meistens "Daisy Chain". So verstehe ich jedenfalls die "Kaskadierung der Slaves" bei Wikipedia.

Streiche "Adresse", setze "Übertragung" ... ;-)

Mit CS dauerhaft auf low wäre ich aber auch sehr vorsichtig, auch wegen der steigenden Flanke, die oft (z. B. bei DACs) eine Übernahme der Daten aus dem Pufferregister nach wohin-auch-immer auslösen.

Ade

Reinhard

Am Mon, 02 Sep 2013 08:49:59 +0200 schrieb Frank Buss:

Genau. Allerdings heißen die Anschlüsse aus gutem Grund nicht MOSI und MISO, sondern SI und SO (Serial In / Out).

Der Grund? SO wird _nicht_ hochohmig, wenn CS inaktiv wird, darf also nicht an die MISO-Leitung.

Quelle: Z. B. Datenblatt Microchip MCP42010

Ade

Reinhard

Danke für den Tipp. Ich werde das mal so ausprobieren.

Aktuell sieht es aber so aus als hätte ich entweder mein Display kaputtgespielt oder schon ein defektes geliefert bekommen. Was von beidem kann man natürlich nicht mehr feststellen.

Auch am Raspberry tut sich auf jedem Fall garnichts. Und zwar obwohl ich mit meiner "Ohrhörer-Methode" jetzt auf allen Daten-Pins Aktivität feststellen kann und CS im Leerlauf diesmal "Low" und nicht "High" ist.

Ersatz-Display habe ich da. Später löte ich das mal in die Platine und dann bekomme ich am Raspberry hoffentlich erstmals eine Ausgabe...

Wenn das klappt gehe ich das Thema "SPI via GPIO" mal an.

Gruß

Manuel

Am Mon, 02 Sep 2013 18:16:35 +0200 schrieb Manuel Reimer :

Am besten vor dem neu Einlöten nochmal die Leerlaufpegel aller Pins kontrollieren, nicht daß es sofort nochmal passiert.

Marc

Habe ich.

Bei meinem Pech habe ich natürlich die Version des Displays bestellt, bei der eine silberne Folie hintendran fehlt. Also die vom alten abgepuhlt und auf das neue geklebt... Sieht scheiße aus... Gibt's die Folie irgendwo zu kaufen? Oder doch wieder mal neues Display?

Wie dem auch sei: Neues Display aufgelötet, Verdrahtung nochmal geprüft, gnublin-dogm-Programm gestartet und...

Wieder nichts...

So langsam kotzt mich das ganze echt an!

Ganz allmählig tendiere ich dazu das da:

und das da: zu bestellen. Angeblich funktioniert das ganze damit ja. Und wenn nicht habe ich wenigstens einen Ansprechpartner der mir bei meinem Problem hilft. Vielleicht schreibe ich die mal an und frage nach wie viel es kostet die zwei Platinen bestückt und getestet geliefert zu bekommen...

Oder ich vergesse endlich den Blödsinn mit dem Display-Gebastel und knalle da einfach eine Handvoll schnöde LEDs für die Statusanzeige dran. Für ein nettes Gimmik wird das ganze langsam sehr Zeit- und Geldintensiv. Den Raspberry habe ich ja auch schon nur angeschafft um zu testen ob mein Display-Aufbau eigentlich funktioniert.

Ich kann echt nicht in Worte fassen wie sehr mich das ganze ank*tzt...!

Gruß

Manuel

Nein, nicht das ich wüsste.

Das wirds wohl sein. Warum machste zum probieren keine Pfostenverbinder und Kabel dran. Spart ne Menge STress.

Jetzt ahnst Du vielleicht, warum ich schon seit den 80er Jahren nur Forth einsetze. Da komme ich bestens klar mit so einem HW-Geraffel. Rapid Prototyping!

So ein Display läuft nach spätestens 1h Arbeit.

Hab auch einige Projekt in Forth fertig gemacht und dann auf C(-auweh) und einmal sogar auf Pascal umschreiben lassen, weil der Kunde sich in Forth nicht einarbeiten wollte (grober Fehler).

War unterm Strich immer noch billiger als der Wettbewerb, der sich wochenlang mit C erfolglos abgemüht hat.

Ok das hilft Dir aktuell nicht, solltest aber mal einen Gedanken an Forth verschwenden. Ideal, wenn man nicht genau weiss, wie diverse Schnittstellen funzen oder zum erproben finsterer Algorithmen.

Die haben sogar einen uC Verleih

Saludos (an alle Vernünftigen, Rest sh. sig) Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt! 
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf 
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p 
(lt. alter usenet Weisheit)      iPod, iPhone, iPad, iTunes, iRak, iDiot

Am Mon, 02 Sep 2013 20:26:32 +0200 schrieb Manuel Reimer :

Dein Hauptproblem ist imho die Beschäftigung mit zwei Baustellen gleichzeitig. Das mal was kaputtgeht ist normal, habe selbst grade neulich einen Drucksensor durch unachtsame Verbindung von Schaltungmasse und Erde geschrottet - leider ganz ohne spektakuläre Qualmwolke. ;)

Konzentriert man sich auf ein Teil zur Zeit, kann man sich darauf verlassen, daß der Rest funktioniert. Deswegen wird z.B. Anfängern für µC-Basteleien auch empfohlen, den Programmer nicht selbst zu bauen sondern fertig zu kaufen. Dann weiß derjenige wenigstens, daß nur seine µC-Schaltung bzw. das hineingeladene Programm das Problem ist, nicht auch noch der Programmieradapter. Noch besser ist es dann, mit einer fertigen Platine anzufangen, dann kann man die Hardware ganz ausschließen und sich auf die Programmierung konzentrieren.

Ich hatte ja schon empfohlen, erstmal den CS-Pin zu testen, einfach was rausschreiben und Spannung angucken. Das mit dem dogm-Progrmm und ggf. mal mit was eigenem. Wenn der korrekt arbeitet, kann man das Display angehen.

Sinnig wäre auch, an den taktisch wichtigen Stellen Strombegrenzungswiderstände und ggf. ein Schutzdiodenpaar vorzusehen.

Marc

--
Warning: Do not look directly into laser with remaining eye.