Spi, Java, ADC, DAC

[uwe.haertel]

Hallo Leute,

nachdem mein 1.Betrag gestern wohl in den Tiefen diverser php Skripte versickert ist, heute noch ein Versuch:

Ich versuche ein Programm zu erstellen, welches über die SPI Funktion des IOW periodisch die Daten eines ADC (AD7731- Analog Device)ausliest und daraus berechnete Werte an zwei DACs ausgiebt. Den "Takt" der Anwendung gibt der ADC vor, der alle 20 ms das Beinchen hebt bzw. die RDY Leitung runterzieht.

Die SPI Leitungen sind über HCPL090 bzw 091 potential getrennt und an den langen Enden terminiert.

Ich habe hier je ein Starterkit für den Iow24 und den Iow56, auf die ich für die SPI Leitungen noch Treiber gebaut habe (die Flanken des Iow sind für die HCPLs zu rund)

Das Programm wird in Java 1.5 (JBuilder 2006) erstellt.

Prinzipiell läuft die Sache schon ganz gut. Allerdings treten verschiedene Effekte auf, zu deren Verständnis ich mir Eure Ratschläge erhoffe:

Beim Iow56 passiert folgendes: In unregelmäßigen Abständen bekomme ich beim Lesen des ADC eine Bitfolge, die zwar mit 9 anfängt, dann aber Müll enthält, welcher sich auch ständig ändert. Ich kann dies ganz gut ausfiltern, da das zweite Byte meist eine 0 oder 1 ist, ich aber eine 3 erwarte. Die "saubere Lösung" ist das aber wohl nicht.

Dies passiert unabhängig vom Speed des SPI (ich kann problemlos bis 2 MBit/s takten) aber nur, wenn ich zwischendurch jeweils ein IowKit.write schreibe um die chip select Leitung zu wechseln (lesen vom ADC, schreiben zu den DACs).


Beim Iow24 ist das Problem leider nicht so leicht zu lösen: Nach einer völlig unbestimmten Zeit (wenigen Sekunden bis mehrere Stunden) werden die vom ADC gelesenen Daten von einem Lesevorgang zum nächsten unsinnig. Nun könnte man argumentieren, die Verbindung ist einfach aus dem Takt gekommen und jetzt ist die Bitordnung durcheinander. Allerdings wird der ADC wird ja mit jedem /CS synchronisiert. D.h. selbst wenn er mal aus dem Tritt kommt, sollte er beim nächsten read wieder okay sein. Noch etwas ist merkwürdig. Wenn es gut läuft, gibt der write/read Befehl für die DACs für jedes geschriebene Byte 0xff zurück - was sicher vernünftig ist. In dem Moment, wenn die ADC Werte unsinnig werden, ändert sich das. Dann erscheinen nur noch Nullen.

Kann es sein, dass die DLL "aus dem Takt kommt"? Kann man die internen Buffer irgendwie resetten?

Schließlich habe ich noch eine Frage zur Java Implementierung von Thomas Wagner: Warum wird die write/read Anweisung nicht wie in den in C und Delphi angegebenen Beispielen durch eine einfache Folge eines IowKit.write + IowKit.read realisiert, sondern über die relativ komplizierte Konstruktion mit einem eigenen Lesethread und Callback umgesetzt?

Soviel vielleicht erstmal für jetzt. Freue mich auf "response".
Uwe

[uwe.haertel]

Okay, wer lesen kann, ist klar im Vorteil ;-) Inzwischen haben sich einige Fragen durch das Lesen anderer Beiträge erledigt.

Wenn ich es richtig verstanden habe, werden die Lese- und Schreibzugriffe für die SMFs (Pipe 1) nicht gepuffert, jedenfalls nicht in der Dll. Daher auch der eigene Lesethread.

Inzwischen habe ich auch die Quellen für die Dll gefunden; leider sind meine Kenntnisse der Windows Systemfunktionen recht begrenzt so dass sich mir die Funktion des Ganzen nur äußerst langsam erschließt :-(

Ich habe aber immernoch das Problem, dass die SPI Kommunikation mit mehreren Slaves (also IOWrites zum Umschalten der Chip Select Leitungen zwischen den SPI Write/Reads) nicht stabil funktioniert.

Natürlich kann das auch meinem Aufbau liegen. Trotzdem möchte ich nochmal nachfragen:

Hat jemand Erfahrung mit so einer Betriebsart? Kann es sein, dass sich IOWrite und SPI Write/Read gegenseitig in die Quere kommen? Oder ist es möglich, dass sich die Verzögerungen durch die JNI Aufrufe negativ auswirken.

Wäre für diverse Ratschläge sehr dankbar
Uwe

[wayoda]

Hallo Uwe,
ohne Code und Hardware kann man nicht so viel sagen, aber für einige Tips reichts schon.:

Wenn ich es richtig verstanden habe, werden die Lese- und Schreibzugriffe für die SMFs (Pipe 1) nicht gepuffert, jedenfalls nicht in der Dll. Daher auch der eigene Lesethread.

Die DLL puffert durchaus ungelesene Reports (128 Stück), sowohl für die IO-Pins als auch für die SpecialModes.

Der (Java-)Lesethread und das ganze Paket von Thomas Wagner sind zusätzliche Klassen um den Java-Zugriff zu vereinfachen. Der eingentliche Einsprungspunkt in die NativeCode-DLL befindet sich in Klasse com.codemercs.iow.IowKit.

Inzwischen habe ich auch die Quellen für die Dll gefunden; leider sind meine Kenntnisse der Windows Systemfunktionen recht begrenzt so dass sich mir die Funktion des Ganzen nur äußerst langsam erschließt :-(

Ich denke es handelt sich nicht um ein grundsätzliches Problem mit den Schreibzugriffen in der Library. Dafür hat sich der Code schon zu lange im (SPI-)Einsatz bewährt. Wenn man sich die Dokumentation der Library ansieht sollte dies zum Verständnis genügen.

Ich habe aber immernoch das Problem, dass die SPI Kommunikation mit mehreren Slaves (also IOWrites zum Umschalten der Chip Select Leitungen zwischen den SPI Write/Reads) nicht stabil funktioniert.

Ich habe einmal ein ähnliches Problem mit den CS-Leitungen gehabt.
Bei mir ging es um ein LCD-Display am SPI-interface.
Mein Programm sah in etwa so aus:

Code: Select all

Ein Schreibbefehl auf die IO-Pins aktiviert die CS-Leitung meines Displays;
Ich schalte den SPI-Mode am IOWarrior ein;
Ich übertrage ich Daten an das Display;

Das lustige an meinem Programm war: Es funtktionierte mit einem IOWarrior24 ganz prima, lief aber mit einem IOWarrior56 gar nicht!
Mein Problem war die Aktivierung des CS bevor der SPI-Mode eingeschaltet wurde.
Auch wenn dein Programm wahrscheinlich anders funktioniert würde ich besonderen Augenmerk auf das Timing der Schreibzugriffe auf die unterschiedlichen Funktionen des IOWarrior legen.
Ich gehe davon aus, das alle Schreibzugriffe aus nur einem Thread erfolgen!!???

Hat jemand Erfahrung mit so einer Betriebsart? Kann es sein, dass sich IOWrite und SPI Write/Read gegenseitig in die Quere kommen?

Wäre ein Verdacht dem ich nachgehen würde.
Mein Test-Vorschlag :
eine Gedankenpause von einigen Millisekunden zwischen allen Schreib/Lese-Befehlen

Oder ist es möglich, dass sich die Verzögerungen durch die JNI Aufrufe negativ auswirken.

Hier sag ich mal nein. Heutige Rechner sind so schnell, dass man so etwas vernachlässigen kann.

Eberhard

[uwe.haertel]

Hallo Eberhard, danke für die Hinweise.

Eines irritiert mich ein wenig. Bisher bin ich davon ausgegangen, dass die Initialisierung der Spi- SpecialModeFunction nur die dafür reservierten Pins und deren Verhalten beeinflusst. Die Funktion der anderen Pins sollte doch davon unabhängig bleiben - ist das so???

Ich initialisiere die Spi Funtionalität gleich zu Beginn und schalte sie auch erst zum Programmende wieder aus. Die CS Leitungen liegen an einem anderen Port auf den ich dann per IOWrite zugreife. Ich hoffe, ich muss nicht vor jedem IOWrite die Spi Funktion aus- und danach wieder anschalten !?!

Also der PAP ist ungefähr so:

1. Finden Iow, Initialisierung bla, bla... Spi ein.
2. IOWrite für CS des ADC
3. Initialisierung des ADC, Start Convertierung
SCHLEIFE BEGIN
SmfWrite(Warte auf RDY | drei Dummy Byte)
SmfRead(lese drei Byte Daten vom ADC);
IOWrite(CS Leitung DAC1 auf low)
SmfWrite(drei Byte an DAC 1)
SmfRead(drei Dummy Byte);
IOWrite(CS Leitung DAC2 auf low)
SmfWrite(drei Byte an DAC 2)
SmfRead(drei Dummy Byte);
IOWrite(CS Leitung ADC auf low)
SCHLEIFE END
Abspann


Das funktioniert ja soweit auch, bis eben die oben beschriebenen Probleme auftreten.

Gruß, Uwe

[wayoda]

Hallo Eberhard, danke für die Hinweise.

Eines irritiert mich ein wenig. Bisher bin ich davon ausgegangen, dass die Initialisierung der Spi- SpecialModeFunction nur die dafür reservierten Pins und deren Verhalten beeinflusst. Die Funktion der anderen Pins sollte doch davon unabhängig bleiben - ist das so???

Ja, das hast Du richtig verstanden. Es war nur die Ursache meines eigenen Fehlers.

Ich initialisiere die Spi Funtionalität gleich zu Beginn und schalte sie auch erst zum Programmende wieder aus.

So sollte es auch sein!

1. Finden Iow, Initialisierung bla, bla... Spi ein.
2. IOWrite für CS des ADC
3. Initialisierung des ADC, Start Convertierung
SCHLEIFE BEGIN
SmfWrite(Warte auf RDY | drei Dummy Byte)
SmfRead(lese drei Byte Daten vom ADC);
IOWrite(CS Leitung DAC1 auf low)
SmfWrite(drei Byte an DAC 1)
SmfRead(drei Dummy Byte);
IOWrite(CS Leitung DAC2 auf low)
SmfWrite(drei Byte an DAC 2)
SmfRead(drei Dummy Byte);
IOWrite(CS Leitung ADC auf low)
SCHLEIFE END
Abspann

Ich hätte es genauso wie Du gemacht.

Hilft denn folgendes vielleicht?
Weil:
Die Schreibbefehle auf die IO-Pins und SpecialModes sind so viel ich weiß auch schon Windows-intern nicht synchronisiert (ein IOWarrior besteht aus zwei unabhängigen Dateien in welche die Daten geschrieben werden.. Vorstellbar wäre, das die CS-leitung noch nicht umgeschaltet hat wenn das Programm über die SPI-SpecialModes schon Daten schickt.
Nur eine Idee, aber folgendes sollte das Problem an den Tag bringen:

Code: Select all

//Ich würde als test ein bisschen warten nach dem IOwrite
IOWrite(CS Leitung DAC1 auf low)
sleep(5); //ein paar millisekunden mal einfach ausprobiern
SmfWrite(drei Byte an DAC 1)
.....

Eberhard

[uwe.haertel]

Das mit dem sleep habe ich auch schon versucht. Es schien zwar tendenziell die Störungen ein wenig zu verringern bzw. die Zeit bis zum Ausfall des iow24 zu verzögern, wirklich geholfen hats aber nicht.

Jetzt habe ich aber folgendes ausprobiert: Nach jedem IOWrite mache ich ein IORead (IowKit.read(handle, 0, ioReportLength)). Aus Symetriegründen sozusagen. Und in der Tat, beim iow56 hilfts - nach 250000 Spi Zugriffen noch kein fehlerhafter Record. Vorher gabs da schon mind. 50 davon.

Ob es beim iow24 auch hilft kann ich erst morgen sagen, Da tritt der Fehler machmal erst nach Stunden auf.

Die Quellen für die Dll schau ich mir auf alle Fälle noch mal gründlicher an - Wenn sie nur ein bisschen ausführlicher kommentiert wären :-((

Gruß, Uwe

[Guido Körber]

Wie sieht denn der Hardwareaufbau aus? Bei solchen Problemen mit instabilem Verhalten stellt sich oft heraus, dass die Stromversorgung eines oder mehrerer Teile der Schaltung subotimal ist. Besonders bei der Verwendung von Stützkondensatoren direkt an den Chips wird oft gespart...

[Robert Marquardt]

Ich glaube es ist ein Verstaendnisproblem hier. Eine Aktion auf dem SPI ist immer ein Schreib-Lese-Paar.
Wenn man den Antwortreport nicht liest, dann wartet er natuerlich in einer Warteschlange das man ihn liest. Ist die Warteschlange voll so wird der aelteste Report verworfen.
Wenn man also nicht die Antwort des IOWarriors wegliest, dann bekommt man spaeter Reports die nichts mit der letzten Schreibaktion zu tun haben.

[uwe.haertel]

@Guido

Die Hardware ist okay. Die Outputs werden mit einem 74245 getrieben und sind auf Empfängerseite mit 1K terminiert. Und die Stützkondensatoren am Treiber und den Kopplern sind auch dran.

@Robert

Genauso habe ich das auch verstanden: Spi Transfers werden immer als Write/Read Aktion gemacht.

Bei den normalen PortIOs sollte das aber nicht so sein, oder? Wenn ich auf den Iow schreibe IowKit.write(handle, 0x00, _ioReport) muss ich doch nicht anschließend auslesen, oder?

Gruß, Uwe

[Robert Marquardt]

Das haengt davon ab ob sich etwas an den Pins aendert. Jedesmal wenn sich etwas an den Pins aendert, schickt der IOWarrior einen Report auf der IO-Pins Pipe. Man sollte daher mit IowKitReadNonBlocking nach dem Schreiben die Report-Queue leeren und nur den letzten (aktuellsten) Report verwenden.

[wayoda]

Jedesmal wenn sich etwas an den Pins aendert, schickt der IOWarrior einen Report auf der IO-Pins Pipe. Man sollte daher mit IowKitReadNonBlocking nach dem Schreiben die Report-Queue leeren und nur den letzten (aktuellsten) Report verwenden.

In diesem Fall sind aber die Reports, die auf der IO-Pin Pipe gelesen werden könnten, gänzlich uninteressant für den Programmablauf. Es gibt von daher auch keinen Grund sie zu verarbeiten oder auch nur zu lesen.

@Uwe
Noch mal zu den CS-Leitungen:
Ich hatte damals für den Betrieb von 2 Displays am SPI-Bus, das /SS-Signal vom SPI-Interface logisch mit den IO-Pins für die Auswahl des Displays verknüft.

Das CS-Signal für eines der Displays entstand also aus
(IO-Pin-für-Display==LOW) & (/SS-von-SPI==LOW)

Damit wurde dann das jeweilige Display nur für die Dauer der Datenübertragung aktiv.

Eberhard

[uwe.haertel]

Naja, nach der Ermahnung von Guido hab ich nochmal hardwaremäßig alles durchgemessen (obwohl ich das schon mehrere male gemacht habe, bevor ich andere belästige, muss ich schon sehr verzweifelt sein).

Jedenfalls könnte es sein, als ob der Abblock-Kondensator am Treiber (74LS245) eine kalte Lötstelle hatte. Ich hab's jedenfalls nachgelötet und es lief eine Stunde ohne Probleme - dann bin ich aber nach hause gegangen. Morgen werde ich sehen, ob's daran lag.

Auf alle Fälle kann ich erstmal arbeiten, denn mit dem iow56 Kit lief es zuletzt störungsfrei (mit IoPin write+ IoPin read). Dank allen, die sich mit meinem Problem beschäftigt haben.

Uwe

P.s.: Was die Dll angeht, hab ich aber Blut geleckt. Die schau ich mir mal genauer an. Die scheint doch im Laufe der Jahre doch ein wenig ins Kraut geschossen zu sein und sollte mal, der Jahreszeit entsprechend, "ausgegeizt" werden ;-)

[Robert Marquardt]

Die 1.5 DLL ist heftig ueberdesignt. Es war ein 2.0 API vorgesehen das so nicht realisiert wird. Um genau zu sein die DLL versucht Dinge zu implementieren die in einer DLL nicht moegliich sind.
Mitte letzten Jahres bin ich dann erst mal ausgefallen und habe noch schnell die DLL auf das 1.5 API beschraenkt. Urspruenglich sollte die DLL das 1.5 und das 2.0 API exportieren.

Inzwischen geht es mir wieder gut und ein neues komplett anderes 2.0 API ist in Arbeit. Das wird mit einer unsichtbaren Traegerapplikation fuer die Thread arbeiten, denn es werden virtuelle Teilgeraete eingefuehrt.