ein AD7798 soll an einem Atmega32U4 in Betrieb genommen werden. Die Schaltung wird aus USB versorgt. als Treiber verwende ich etwas vom AD7714 Umgeschriebenes. Der AD7714 lief, der AD7798 macht leider Probleme. weder der umgeschriebene Treiber lief bisher problemlos noch das Beispiel im Datenblatt auf S.20. je nachdem was ich am Code ändere erhalte ich mal Werte 0,0,0,65535,0,65535,0,0,1023. Oder auch 0,0,0,65280,0,0. Es erscheint wenig stabil. am SPI sollte es nicht liegen, denn das SRAM auf der Platine lässt sich schreiben und auslesen. die Entkoppel-Cs 10u/100n sind in Chipnähe angebracht. Siehe Bild. Auf der Platinenrückseite ist eine Massefläche (Analogmasse). Widerstände 8.2k liegen zwischen +-CH1, +-CH2. eigentlich sollte das doch gehen?
Angehängte Dateien:
-
P1100094_small.jpg
320 KB
:
Bearbeitet durch User
Schau dir mal das Digitalsignal mit dem Oszi an. Die genannten Werte sind auffällig: >>> bin(65280) '0b1111111100000000' >>> bin(65535) '0b1111111111111111' >>> bin(1023) '0b1111111111'
:
Bearbeitet durch User
Matthias W. schrieb: > am SPI sollte es nicht liegen, denn das SRAM auf der Platine lässt sich > schreiben und auslesen. Naja, so ein ADC macht zwar etwas wie SPI, aber hat da durchaus seine eigenen Anforderungen. Nimm mal ein Oszilloskop/Logikanalysator und guck dir an ob du beim SPI das Timing auf Seite 7 einhältst. Dann guck mit einem Oszilloskop ob die Pegel am SPI eingehalten werden und frei von Störungen sind. Wenn dein Oszilloskop/Logikanalysator noch SPI dekodieren kann, könntest du mal gucken was da tatsächlich über die Leitung geht.
> am SPI sollte es nicht liegen, denn das SRAM auf der Platine lässt sich > schreiben und auslesen. Bizarre Vorstellung. Davon solltest du abruecken und dir das GENAU anschauen. Olaf
Gustl B. schrieb: > Naja, so ein ADC macht zwar etwas wie SPI, aber hat da durchaus seine > eigenen Anforderungen. Nimm mal ein Oszilloskop/Logikanalysator und guck > dir an ob du beim SPI das Timing auf Seite 7 einhältst. Danke Gustl ! vielleicht war es naiv zu glauben daß das vom Timing her ähnlich sein sollte wie beim AD7714 mit dem es ja problemlos ging? Was soll am AD7798 grundsätzlich anders sein? > Dann guck mit einem Oszilloskop ob die Pegel am SPI eingehalten werden > und frei von Störungen sind. die Pegel sahen für mich ok aus. Wie gesagt - das SPI-RAM klappt ja auch. es ist nahezu unmöglich direkt am ADC-chip messen weil die Pins so winzig sind. Die Mess-Spitze rutscht da extrem leicht ab. Ich habe daher ein paar cm entfernt gemessen - direkt an den Pins der Atmega32u4-Platine. > Wenn dein Oszilloskop/Logikanalysator noch SPI dekodieren kann, könntest > du mal gucken was da tatsächlich über die Leitung geht. leider nein. Es ist ein Analog-Oszi. Daher kann ich nur Sachen anschauen die schnell hintereinander passieren. Wenn eine längere Pause da ist um auf die Werte zu warten geht das nicht brauchbar.
Olaf schrieb: > Bizarre Vorstellung. Davon solltest du abruecken und dir das GENAU > anschauen. mit dem Oszi habe ich angesehen was für Signale da kommen. Das sah für mich ok aus.
Matthias W. schrieb: > als Treiber verwende ich etwas vom AD7714 Umgeschriebenes. Der AD7714 > lief, der AD7798 macht leider Probleme. Warum sollte ein Treiber für den AD7714 beim AD7798 zu irgendwelchen sinnvollen Ergebnissen führen? Hast du schon mal im Datenblatt die Registerbelegung angesehen? Alleine schon die Belegung des zentralen Communication Registers hat bei den beiden Bausteinen nichts miteinander zu tun, außer dem gleichen Namen. RTFM
> Hast du schon mal im Datenblatt die Registerbelegung angesehen?
Manchmal frag mich wieso es ueberhaubt noch Datenblaetter gibt.
Vielleicht sollten die Hersteller einfach nur noch Arduinotreiber
bereitstellen damit die Welt in kollektiver Bloedheit versinken kann.
.-)
Olaf
Matthias W. schrieb: > Das ist mir auch aufgefallen Sven. Na dann ist das Problem doch schon gelöst.
Wolfgang schrieb: > Warum sollte ein Treiber für den AD7714 beim AD7798 zu irgendwelchen > sinnvollen Ergebnissen führen? Danke Wolfgang. Da ich den Treiber für den AD7714 selbst geschrieben habe kenne ich diesen Treiber. > Hast du schon mal im Datenblatt die Registerbelegung angesehen? ja. > Alleine schon die Belegung des zentralen Communication Registers hat > bei den beiden Bausteinen nichts miteinander zu tun, außer dem gleichen > Namen. ja. Eben deswegen habe ich den Treiber an den AD7798 angepasst. Niemand ist ohne Fehler. Daher weiß ich noch nicht warum es bisher nicht klappt. wie man im Code sehen kann habe ich diverse Versuche unternommen. Leider fand ich zum AD7798 kein so schönes Beispiel im Datenblatt wie beim AD7714. daher hoffe ich auf Hinweise. Vielleicht hat ja jemand diesen AD7798 benutzt und hat etwas das arbeitet. Das war die Idee.
Beao Bachta schrieb: > Na dann ist das Problem doch schon gelöst. Vielleicht kannst Du das näher erläutern. Noch sehe ich nicht wie mich das weiterbringt.
Matthias W. schrieb: > Noch sehe ich nicht wie mich das weiterbringt. Ich sehe das durch diesen ultimativ heissen Tip: Wolfgang schrieb: > Hast du schon mal im Datenblatt die Registerbelegung angesehen? Also allgemein heisst das RTFM.
Olaf schrieb: > Manchmal frag mich wieso es ueberhaubt noch Datenblaetter gibt. Danke Olaf. Leider führt dieser Hinweis hier zu nichts, denn ich habe sehr wohl das Datenblatt angesehen - und deswegen auch den Treiber angepasst. Nur geht es eben nicht ! Also wird es einen Fehler geben - entweder im Code (siehe oben) - oder bei der Hardware (Cs zu weit weg?) oder eine Mischung aus beidem. Oder hast Du eine andere Idee. Der Code ist gepostet. Wenn Dir daran etwas auffällt kannst Du es gerne sagen.
Beao Bachta schrieb: > Also allgemein heisst das RTFM. das ist bereits geschehen ! lies Du mal den obigen Text und schau den Code dazu an !
Matthias W. schrieb: > lies Du mal den obigen Text und schau den Code dazu an ! Ich habe mir den Code schon ganz zu Beginn angeschaut und beschlossen dass ich in diesem Chaos weder was suchen noch was finden will. Nachdem keine Hinweise zum Code gegeben werden nehme ich an dass es anderen genauso geht.
noch ein Hinweis: am SPI hängt auch ein DAC. Auch dieser arbeitet einwandfrei. es gab mal ein Problem mit der DAC-Ausgabe. Die Ursache war ein Fehler bei der Einstellung des Mode. Ohne den richtigen SPI-Mode geht der DAC nicht richtig. dieses Problem sollte es hier eigentlich nicht geben. Laut Datenblatt sollte Mode 3 passen und das hatte ich auch gewählt.
auch das SPI-Timing sollte nicht das Problem sein. Jedenfalls änderte sich nichts als ich die CS-Befehle durch 2 Befehle hintereinander probeweise verlängert habe.
Beao Bachta schrieb: > Ich habe mir den Code schon ganz zu Beginn angeschaut und > beschlossen dass ich in diesem Chaos weder was suchen noch > was finden will. na dann lass es halt sein. vielleicht hat ja jemand etwas das schon mal funktioniert hat bei diesem oder einem ähnlichen chip und will ernsthafter mithelfen das in Betrieb zu bekommen.
Der erste Schritt wäre es m.E. die Register rückzulesen und zu schauen, ob plausible Werte drinstehen (bzw. ob die Werte drinstehen, die vorher reingeschrieben wurden). Ansonsten würde ich mir ein Digitaloszi organisieren, um zu sehen ob das was auf der Leitung ist, mit den gelesenen Werten korrespondiert.
Bernd schrieb: > Der erste Schritt wäre es m.E. die Register rückzulesen und zu schauen, > ob plausible Werte drinstehen (bzw. ob die Werte drinstehen, die vorher > reingeschrieben wurden). Vielen Dank Bernd. Das ist eine sehr gute Idee ! Da das zurücklesen sehr schnell geht muss das auf dem Analog-Oszi zu sehen sein wenn man es rasch genug hintereinander macht. leider hat mein Versuch das Status-Register auszulesen nicht geklappt. Keine Ahnung woran das lag. beim AD7714 hatte ich auf das Auslesen verzichtet und stattdessen ein delay eingebaut bevor ich die Werte auslas. Diesmal wollte ich es genauso machen. Nur ging es eben leider nicht. es sollte möglich sein herauszufinden warum das Status-Register auslesen nicht geklappt hat. Das kann ich näher ansehen.
Es reicht ein Logikanalysator für wenige € um sehen zu können was da auf den Leitungen passiert.
Gustl B. schrieb: > Es reicht ein Logikanalysator für wenige € um sehen zu können was da auf > den Leitungen passiert. Danke Gustl. Grundsätzlich hast Du recht. Mit dem Oszilloskop sieht man jedoch auch die Form der Dignale und die Amplitude und ggf. auch Überschwinger oder Unterschwinger. Momentan nutze ich ein altes HM1005 mit 3 Kanälen. Das ist schon hilfreich wenn man die 3 Tastköpfe mal dran hat und sie nicht ständig wieder abfallen. Am chip selbst kann ich halt leider nicht messen ! Ich muss immer einen Ort in der Nähe suchen. Mir gefällt momentan nicht daß die Messungen so unzuverlässig sind. So als würde der SPI-Mode nicht stimmen. Dabei sollte der schon stimmen. Ich muss es genauer ansehen !
Wir löten immer extrem dünnen Draht direkt an die Beinchen des Chips, und am anderen Ende kommen das die Messspitzen des Oszis. Dann hat man die Hände auch frei. Und ohne Oszi wird es nicht gehen. Wenn man technisch in diesen Bereich gehen möchte, dann sollte die Werkstatt entsprechend hochgerüstet werden.
PittyJ schrieb: > Wir löten immer extrem dünnen Draht direkt an die Beinchen des Chips Danke Pitty ! Das ist schon wirklich sehr eng. Es war schwer das einzulöten und die Kurzschlüsse wieder loszuwerden.
Matthias W. schrieb: > Bernd schrieb: >> Ansonsten würde ich mir ein Digitaloszi organisieren > > schwierig. Mit Analog-Oszi wirst du wenig Freude haben und suchst/flasht dich tot. Kaufe dir für 6€ einen kleinen Logikanalysator. Wenn du den SPI nicht gerade mit 20MHz laufen lässt, reicht der völlig und dekodiert SPI anständig. z.B. https://www.ebay.com/itm/331803014389
Beao Bachta schrieb: > Ich habe mir den Code schon ganz zu Beginn angeschaut wenn Du das getan hast - so frage ich mich warum Du die Datei ad7798.h übersehen hast. In dieser Datei ist doch sofort zu sehen daß da die Register des AD7798 aufgelistet sind. > Also allgemein heisst das RTFM. Du hättest also sofort sehen müssen daß ich das Datenblatt sehr wohl sehr aufmerksam gelesen habe - sonst wäre es nicht möglich gewesen diese Datei zu erstellen ! Lies und denke in Zukunft genauer bevor Du so etwas postest das leider niemanden hier weiterbringt. Olaf schrieb: > Manchmal frag mich wieso es ueberhaubt noch Datenblaetter gibt. das gerade gesagte zum Thema Datenblatt gilt leider auch für Dich Olaf ! es ist leicht sich über andere lustig zu machen - leichter jedenfalls als etwas wirklich Produktives und Nützliches beizutragen. Du hast keine Ahnung wie oft ich dieses Datenblatt nun schon angesehen habe und immer wieder Änderungen probiert habe weil ich dachte etwas vielleicht falsch verstanden zu haben.
Matthias W. schrieb: > Ich muss immer einen Ort in der Nähe suchen. Da hat man direkt für das nächste Platinendesign gelernt: Testpunkt einplanen ;) An Datenleitungen immer eine gute Idee. Als Behelf kann man auch einen dünnen Fädeldraht an den IC-Pin löten und daran die Probe hängen. > Mir gefällt momentan nicht > daß die Messungen so unzuverlässig sind. So als würde der SPI-Mode nicht > stimmen. Dabei sollte der schon stimmen. Und genau deshalb brauchst du irgendwas digital-Oszi-ähnliches ...
Wolfgang schrieb: > reicht der völlig und dekodiert SPI > anständig. z.B. Ebay-Artikel Nr. 331803014389 Danke Wolfgang für den Hinweis !
Sven B. schrieb: > Da hat man direkt für das nächste Platinendesign gelernt: Testpunkt > einplanen ;) > An Datenleitungen immer eine gute Idee. Ja. Sven. Durchkontaktierungen sind in der Nähe. Beliebig viele will man natürlich nicht. > Als Behelf kann man auch einen dünnen Fädeldraht an den IC-Pin löten und > daran die Probe hängen. ja. Die Lupe hat 4 dpt. Leicht gibt es einen Kurzschluß.
Auf der Platine sind doch 70% des Platinenplatzes leer. Da passt locker ein bequem großer Testpunkt an die SPI-Leitungen. ;)
Sven B. schrieb: > Da passt locker > ein bequem großer Testpunkt an die SPI-Leitungen. ;) ja. Nur nützt das momentan wenig für das Testen dieser schon bestückten Platine. Erst mal muss diese Fassung laufen. Wer Ideen dazu hat . . . Wolfgang schrieb: > Kaufe dir für 6€ einen kleinen Logikanalysator. so ein Teil ist nun gekommen. Der Treiber hakt noch.
Matthias W. schrieb: > Nur nützt das momentan wenig für das Testen dieser schon bestückten > Platine. Die meisten kommen doch am ISP Stecker an ?!? Den kannst ja noch eben anlöten. Einzig /CS benötigt eine Sonderbehandlung. Auch immer wieder gerne genommen: CS von anderem Baustein nicht auf High gezogen, dann quatscht er dazwischen. Und dieses auch: Den default /CS bzw SS Pin des 32U4 nicht auf Ausgang gestellt.
Gustl B. schrieb: > Es reicht ein Logikanalysator für wenige € um sehen zu können was da auf > den Leitungen passiert. Jein. Für denn Fall, das die Logikpegel korrekt sind, mag das stimmen. Ich habe schon mehrfach den Fall gesehen, das Ausgänge gegeneinander treiben. Das ergibt dann so lustige dreiwertige Zustände auf der digitalen Leitung. Das kann ein Logikanalysator nicht auflösen. Daher schaue ich grundsätzlich als erstes mit dem Oszi und gehe dann erst ggf. auf die Logikkanäle. Mit einem Analogoszi muß man etwas tricksen, um SPI darzustellen: Ich würde auf die fallende Flanke von /CS triggern. Dann kann man mit dem zweiten Tastkopf auf MOSI oder MISO gehen. Damit sich ein stehendes Bild ergibt, muß die Software in einer Schleife auf Dauerübertragung gehen. In die Schleife kommt auch eine kleine Pause, damit man weiß, wo die eigentliche Übertragung anfängt, falls mehrere Bytes bzw. Datenpakete übertragen werden. Achja: günstig ist es auch, sich die Taktleitung (CLK) mal im Bezug zum Datensignal (MOSI) anzuschauen und das Ergebnis mit dem Datenblatt zu vergleichen. Wenn das Oszi nur zwei Kanäle hat, macht man mit der Händykamera ein Foto. Schon hat man ein Speicheroszilloskop :-)
Beim AD7799 ist es noetig das Datenblatt bis auf die letzte Zeile zu lesen und zu verstehen. Ich hatte an dem auch etwas laenger. Und glaube mich zu erinnern, da war was mit dem CS timing. Bei den timings muss man jede Flanke im datenblatt mit den effektiven Flanken vergleichen. Werden alle timings eingehalten. Daher verwende ich keine SPI Modis von Prozessoren mehr, verwende deren Pins, fuer den Fall, dass diese Pins irgendwann auch mit der Funktion betrieben werden sollten. Und schreibe jede Flanke selbst...
:
Bearbeitet durch User
Arduino Fanboy D. schrieb: > Die meisten kommen doch am ISP Stecker an ?!? > Den kannst ja noch eben anlöten. ja. An dieser Stelle geht es. Oder am aufgesteckten 32u4-Board. Das ist halt ein paar cm entfernt. > Auch immer wieder gerne genommen: > CS von anderem Baustein nicht auf High gezogen, dann quatscht er > dazwischen. ja. Das sollte passen. Es gibt ja ein SRAM und den DAC. Der DAC jedoch kann nichts senden, weil er keinen Ausgang hat. Das SRAM arbeitet einwandfrei und sollte eigentlich am Ende den CS wegnehmen. Ich schau es nochmal an. > Und dieses auch: > Den default /CS bzw SS Pin des 32U4 nicht auf Ausgang gestellt. danke für den Hinweis. Wenn das nicht passt geht SPI wohl gar nicht. Das SPI geht jedoch.
Joggel E. schrieb: > Und schreibe jede Flanke selbst... normalerweise ist CS kein Problem, denn man schaltet das aktiv ein und schickt erst dann etwas über SPI weg. Somit sind wohl 125ns dazwischen und das sollte wohl reichen. testweise hatte ich auch 2 CS-Befehle hintereinander gesetzt. Damit sind es dann 250ns. Das hat jedoch nichts gebessert. Daher sollte es wohl kein CS-Timing-Problem sein.
Matthias W. schrieb: > Wenn das nicht passt geht SPI wohl gar nicht. Das > SPI geht jedoch. Wenn du meinst.... Wieso triffst du zu der SS bzw. /CS Ansage keine klare Aussage? Wieso bist du in der Sache auf Annahmen angewiesen? Wieso löst das bei dir keine Handlung aus? Weißt du gar nicht, was du da gebaut/programmiert hast?
Arduino Fanboy D. schrieb: > Wieso triffst du zu der SS bzw. /CS Ansage keine klare Aussage? > Wieso bist du in der Sache auf Annahmen angewiesen? > Wieso löst das bei dir keine Handlung aus? > Weißt du gar nicht, was du da gebaut/programmiert hast? Danke erst mal für den Trigger und die Bereitschaft zu helfen. schau mal auf den Kalender ! heute ist der 24.12. kannst Du Dir nicht denken daß ich manchmal auch anderes zu tun habe als nur diesem Frust-Thema nachzuhängen das offenbar nicht so einfach zu lösen ist wie man oben sehen kann? wenn es so einfach wäre - so würde es längst laufen ! meine letzten Tests sind eine Weile her. damals hatte ich eine ganze Menge probiert und auch Signale angesehen. auswendig weiß ich das alles momentan nicht mehr. in der Datei jedoch steht oben die Historie drin. nur will diese Datei ja offenbar keiner genauer ansehen?! wenn ich die Datei nicht gepostet hätte - so wären wohl mails gekommen in der Art: wie dämlich ich wohl bin zu fragen ohne den Code zu posten. als ich ihn dann gleich am Anfang postete - hieß es dann sinngemäß: wie dämlich ich wohl bin weil ich nach einem funktionierenden Code frage. Ich soll halt das Datenblatt erst mal lesen. Das habe ich gelesen, sonst wäre der Treiberteil dazu nicht möglich gewesen. > Wieso triffst du zu der SS bzw. /CS Ansage keine klare Aussage? die Aussage ist: Der Code lief mit einem AD7714 und DAC und SRAM. Daher ist nicht anzunehmen daß es ein CS-Thema ist. > Wieso bist du in der Sache auf Annahmen angewiesen? weil es eben noch immer nicht geht. Und ich daher weder sicher sein kann daß die Hardware 100% i.O. ist - es kann aber auch ein Softwarethema sein. > Wieso löst das bei dir keine Handlung aus? das Ganze hatte jede Menge Handlung und Tests ausgelöst. Bis ich am Ende die Nase voll hatte und sah daß ich eine Pause brauche - oder Hilfe von jemandem der so ein Teil hat, kennt und helfen will und kann. ich fragte bei Mouser an ob da jemand eine Idee hat. Die verwiesen mich auf Analog Devices. Da kam ich über das Forum auch nicht weiter. Keine einzige Antwort. Irgendwann wird man vom Frust gepackt und legt das erst mal als unlösbar weg. > Weißt du gar nicht, was du da gebaut/programmiert hast? doch. Das weiß ich gut. Der Vorgänger lief ja. Änderungen waren nur ein Umlegen der CS-Adressen und das andere Chip AD7798. Was ich gemacht habe ist dokumentiert. Einiges steht in dem zip. Nur ist das nun eine Weile her. Und weil es nicht richtig geht kann ich nicht ausschließen einen Fehler gemacht zu haben. Vielleicht etwas übersehen, etwas falsch verstanden. Nur was eben. Daher muss ich alles wohl noch mal ansehen. Nur heute nicht mehr ! Vielen Dank und frohe Weihnachten Fanboy !
Joggel E. schrieb: > Beim AD7799 ist es noetig das Datenblatt bis auf die letzte Zeile zu > lesen und zu verstehen. Ich hatte an dem auch etwas laenger. Und glaube > mich zu erinnern, da war was mit dem CS timing. vielleicht hast Du einen Codeteil der bei Dir läuft und den ich mal testen könnte. Der AD7799 ist ja nicht so anders wie der AD7798.
Matthias W. schrieb: > die Aussage ist: Der Code lief mit einem AD7714 und DAC und SRAM. > Daher ist nicht anzunehmen daß es ein CS-Thema ist. Wenn deine Diagnostischen Fähigkeiten so weit ausgebildet wären, dass diese Aussage eine hohe Wahrscheinlichkeit hätte, dann könntest du dieses Problem selber lösen. Matthias W. schrieb: > nur will diese Datei ja offenbar keiner genauer ansehen?! Unübersichtlich! Keine vollständige Portliste. Und natürlich habe ich (in den adxxx und spixxx Dateien) nach der SS Abhandlung gesucht. Sonst könnte ich das doch gar nicht behaupten, dass du an der Stelle schlampig warst. Aber das war ja alles für die Katz, interessiert dich ja nicht. Matthias W. schrieb: > Vielen Dank und frohe Weihnachten Fanboy ! Dir auch.... Und Tschüss.
Arduino Fanboy D. schrieb: > Keine vollständige Portliste. die Ports stehen in main.c. Ganz unten in der Init.. -Funktion.
Arduino Fanboy D. schrieb: > Sonst könnte ich das doch gar nicht behaupten, dass du an der Stelle > schlampig warst. > Aber das war ja alles für die Katz, interessiert dich ja nicht. Unsinn. Wenn Du was konkretest sagen würdest (was Dir genau aufgefallen ist und wo) - so käme ein Dialog zustande. Aber den suchst Du scheinbar ja nicht. Warum nicht?
Arduino Fanboy D. schrieb: > dass diese Aussage eine hohe Wahrscheinlichkeit hätte, ich habe ziemlich ausführliche Tests mit dem Oszi gemacht und dabei keine fremden CS-Signale gesehen wenn ich auf den ADC zugreife. So habe ich es in Erinnerung ! > dann könntest du dieses Problem selber lösen. leider bisher eben nicht. Ich hatte mal ein Problem mit dem DAC. Der Zugriff lief nicht mehr brauchbar. Die Ursache war ein Fehler der beim Umschreiben in den Treiber kam. Als dann der SPI-Mode deswegen falsch war kam halt ein falsches periodisches Signal an. Solche Fehler sind grundsätzlich möglich wenn man an Software ändert. Auch wenn man manchmal denkt - mir passiert so etwas nicht. Nobody is perfekt !
Matthias W. schrieb: > Arduino Fanboy D. schrieb: >> Keine vollständige Portliste. > > die Ports stehen in main.c. Ganz unten in der Init.. -Funktion. Tja... Habe ich nicht gefunden! Dann behaupte ich ab jetzt das Gegenteil. Deine SS Initialisierung ist ok.
Arduino Fanboy D. schrieb: > Deine SS Initialisierung ist ok. vielen Dank ! Dann ist dies schon mal als Fehler ausgeschieden. es gibt noch eine ini-Funktion in der ad7798.c-Datei. da sollte es eigentlich auch stimmen. wenn beides stimmt sollte der Zugriff klappen. in der Tat tut der Ausgang ja auch etwas, nur eben bisher nicht so wie ich es mir gewünscht hatte. wenn der Mode nicht stimmt kann Unsinn passieren. Nur sollte der passen. Das muss ich näher mit dem Oszi oder dem kleinen Logikanalysator noch ansehen !
Matthias W. schrieb: > je nachdem was ich am Code ändere erhalte ich mal Werte > 0,0,0,65535,0,65535,0,0,1023. Oder auch 0,0,0,65280,0,0. Es erscheint > wenig stabil. Habe deinen Code mal durch die Arduino IDE genudelt.
1 | c:\temp\arduino_build_232519\sketch\ad7798.c: In function 'adc_read': |
2 | c:\temp\arduino_build_232519\sketch\ad7798.c:304:43: warning: 'data_l' is used uninitialized in this function [-Wuninitialized] |
3 | 304 | data= ((((unsigned int)data_h) << 8) | (unsigned int)data_l); |
4 | | ^~~~~~~~~~~~~~~~~~~~ |
Eine uminitialisierte Variable ist ein Zufallsgenerator. Oder?
Arduino Fanboy D. schrieb: > Habe deinen Code mal durch die Arduino IDE genudelt. Vielen Dank ! Ich muss das mal anschauen. Melde mich dann !
Seite 7 und Seite 20 des Datenblattes : Wenn CS faellt und wenn es hochkommt, muessen SCLK und DIN beide jeweils high sein. Ist das so ? Nachgeprueft ?
Mach doch mal einen Screenshot einer Messung. #CS und SCLK gleichzeitig wäre fein. Oder ... kann man diesen Ardiuno Dingens auch simulieren und sich dann eine Signalform als Ergebnis anzeigen lassen?
Gustl B. schrieb: > Mach doch mal einen Screenshot einer Messung. #CS und SCLK gleichzeitig > wäre fein. Oder ... kann man diesen Ardiuno Dingens auch simulieren und > sich dann eine Signalform als Ergebnis anzeigen lassen? Danke Gustl ! Nur mit welchem der vielen Softwarestände die ich schon machte soll ich das machen? Es wurden schon so viele Varianten gestestet. Mal da eine Änderung, mal dort. Nicht mal der Status ließ sich brauchbar auslesen. Daher wollte ich mal warten bis jemand mit einer ähnlichen CPU etwas hat das bei ihm definitiv läuft. Ich habe schon viel zu viel Zeit da investiert. Und momentan drücken leider andere Themen. Ich muss daher einfach das Thema beiseite legen. Sorry !
Angehängte Dateien:
-
AD7798.png
12 KB
Matthias W. schrieb: > Nur mit welchem der vielen Softwarestände die ich schon machte soll ich > das machen? Es wurden schon so viele Varianten gestestet. Mal da eine > Änderung, mal dort. Nicht mal der Status ließ sich brauchbar auslesen. Das klingt nicht nach einer systematischen Vorgehensweise. Für viele verschiedene Softwarestände verwende ich git. Da kann man für jede Variante einen Branch anlegen, ohne die anderen Varianten zu beeinflussen. Immer wenn ein Stück funktioniert, wird es eingecheckt. Ich würde mit der aussichtsreichsten Variante weitermachen: Einfach mal alle SPI-Signale auf ein Scope/LA legen und schauen, ob das Signalspiel und die Zeiten aus dem Datenblatt eingehalten werden: https://www.analog.com/media/en/technical-documentation/data-sheets/AD7798_7799.pdf
Bernd schrieb: > Immer wenn ein Stück funktioniert, wird es eingecheckt. Danke Bernd ! leider gab es bisher keine Variante die wirklich brauchbar war. Was hätte ich da einchecken sollen? die ganzen Fehlversuche? > Ich würde mit der aussichtsreichsten Variante weitermachen und welche ist das? natürlich dachte ich anfangs - nimm den Code der beim 7714 prima läuft und änder die Register entsprechend dem Datenblatt. Das lief so leider nicht. Es kamen immer neue Instabilitäten. Daher wechselte ich sogar mal das chip. wenn es am Ende ein Problem mit den Entstör-C`s ist? nicht nah genug am chip? Probleme mit der Durchkontaktierung auf die Massefläche? Überschwinger wg. Reflexionen? Blöd.
Matthias W. schrieb: > Nur mit welchem der vielen Softwarestände die ich schon machte soll ich > das machen? Hast du da jeweils was am Timing von SCLK und #CS geändert?`Wenn ja, dann mach mal mehrere Bildchen. Oder mach einfach ein Bildchen von dem was du meinst, dass wir uns hier mal angucken sollten ...
Wenn man etwas dem Poster zugute halten muss ist es Biss. Er ist nun schon sein zwei Monaten dran. An etwas, was an einem Abend laufen muss.
Joggel E. schrieb: > An etwas, was an einem Abend laufen muss. Genau so. Oder wenigstens am nächsten Abend. Gerade deswegen fehlt ihm etwas. Der Biss.
Beo Bachta schrieb: > gerade deswegen fehlt ihm etwas. Der Biss. bissige Kommentare bringen nicht voran. Ich habe momentan ganz andere Sorgen als dieses leidige Ding in Betrieb zu bekommen. Aber das ist Euch vermutlich nicht klar oder schlicht egal. sonst würdet Ihr nicht so einen Schwachsinn posten ! wer wirklich helfen will soll sich überlegen wie er das am besten tun kann ohne wenig hilfreiche Sprüche: - wer hat einen Code der nachweislich auf dieser CPU läuft - wer will das zur Verfügung stellen - wer hat Interesse ggf. selbst zu testen - eine Leer-Platine könnte ich zusenden. Ernstgemeinte Vorschläge gerne auch per PM. Joggel E. schrieb: > An etwas, was an einem Abend laufen muss. na dann ran ! einen Abend wird doch einer Zeit haben?
Na ich helfe schon gerne, kenne mich aber nicht mit uCs aus. Was ich aber beurteilen kann ist ein Bildchen das die SPI Übertragung zeigt. Wenn du also Screenshots machen kannst vom Oszi, dann immer her damit.
Gustl B. schrieb: > Na ich helfe schon gerne, kenne mich aber nicht mit uCs aus. danke Gustl ! > Wenn du also Screenshots machen kannst vom Oszi, dann immer her damit. eben da fehlt es momentan an der Zeit. Die Platine ist abgebaut, die Geräte weggeräumt. Die Zeit für die Versuche war im November.
I steuere externe SPI Devices ueblicherweise ueber irgendwelche Pins an. Die werden zuoberst definiert. // the external ADC // AD7799 // ADC_SCK[@PORTD,4]:bit; // output at cpu // ADC_CS[@PORTD,5]:bit; // output at cpu // ADC_DO[@PORTD,6]:bit; // input at cpu // ADC_DI[@PORTD,7]:bit; // output at cpu procedure ResetADC; // send 4bytes with $FF var j:byte; begin ADC_CS:=0; // for j:=1 to 32 do ADC_Clk:=0; ADC_DI:=1; ADC_Clk:=1; endfor; ADC_CS:=1; ADCWait:=0; end; //updates the channel //sets the config register // sets the speed and starts the conversion // procedure StartADC; var cr,j:byte; w:word; b1[@w]:byte; b2[@w+1]:byte; begin cr:=%00010000; // write config reg ADC_CS:=0; // for j:=1 to 8 do ADC_Clk:=0; if ((cr and $80)=$80) then ADC_DI:=1; else ADC_DI:=0; endif; ADC_Clk:=1; cr:=cr shl 1; endfor; b2:=%00010000; // unipolar, gain =1 for j:=1 to 8 do ADC_Clk:=0; if ((b2 and $80)=$80) then ADC_DI:=1; else ADC_DI:=0; endif; ADC_Clk:=1; b2:=b2 shl 1; endfor; case xADCChannel of 0: xADCChannel:=0; b1:=%00110000; | // reference detection, buffer enabled, channel = A1 1: xADCChannel:=1; b1:=%00110001; | // reference detection, buffer enabled, channel = A2 2: xADCChannel:=2; b1:=%00110010; | // reference detection, buffer enabled, channel = A3 endcase; for j:=1 to 8 do ADC_Clk:=0; if ((b1 and $80)=$80) then ADC_DI:=1; else ADC_DI:=0; endif; ADC_Clk:=1; b1:=b1 shl 1; endfor; ADC_CS:=1; nop; cr:=%00001000; // write mode reg ADC_CS:=0; // for j:=1 to 8 do ADC_Clk:=0; if ((cr and $80)=$80) then ADC_DI:=1; else ADC_DI:=0; endif; ADC_Clk:=1; cr:=cr shl 1; endfor; b2:=%00110000; // mode = single conversion, close power switch for j:=1 to 8 do ADC_Clk:=0; if ((b2 and $80)=$80) then ADC_DI:=1; else ADC_DI:=0; endif; ADC_Clk:=1; b2:=b2 shl 1; endfor; case xADCChannel of 0: b1:=%00000111; ADCWait:=6; {debugpulse4;} | //60ms -> 70ms 1: b1:=%00000111; ADCWait:=6; {debugpulse4;} | //60ms -> 70ms 2: b1:=%00000111; ADCWait:=6; {debugpulse3;} | //60ms -> 70ms endcase; for j:=1 to 8 do ADC_Clk:=0; if ((b1 and $80)=$80) then ADC_DI:=1; else ADC_DI:=0; endif; ADC_Clk:=1; b1:=b1 shl 1; endfor; //ADC_CS:=1; // stays down end; procedure ReadADC; var cr,j:byte; w:word; b1[@w]:byte; b2[@w+1]:byte; begin cr:=%01011000; // read data reg //ADC_CS:=0; // assumed already low for j:=1 to 8 do if ((cr and $80)=$80) then ADC_DI:=1; else ADC_DI:=0; endif; ADC_Clk:=0; nop; ADC_Clk:=1; cr:=cr shl 1; endfor; ADC_DI:=1; tADC4:=0; // msb of 32bit - stays zero tADC3:=0; for j:=1 to 8 do // byte 1 ADC_Clk:=0; nop; ADC_Clk:=1; if ADC_DO=true then tADC3:=tADC3 or $01; else tADC3:=tADC3 and $FE; endif; if j<8 then tADC3:=tADC3 shl 1; endif; endfor; tADC2:=0; for j:=1 to 8 do // byte 2 ADC_Clk:=0; nop; ADC_Clk:=1; if ADC_DO=true then tADC2:=tADC2 or $01; else tADC2:=tADC2 and $FE; endif; if j<8 then tADC2:=tADC2 shl 1; endif; endfor; tADC1:=0; for j:=1 to 8 do // byte 3 ADC_Clk:=0; nop; ADC_Clk:=1; if ADC_DO=true then tADC1:=tADC1 or $01; else tADC1:=tADC1 and $FE; endif; if j<8 then tADC1:=tADC1 shl 1; endif; endfor; ADC_CS:=1; case xADCChannel of 0: b1:=tADC2; b2:=tADC3; LongADC1:=tADC1; LongADC2:=tADC2; LongADC3:=tADC3; LongADC4:=tADC4; ADCx[0]:=w; xADCChannel:=1; // next | 1: b1:=tADC2; b2:=tADC3; LongADC1:=tADC1; LongADC2:=tADC2; LongADC3:=tADC3; LongADC4:=tADC4; ADCx[1]:=w; xADCChannel:=2; // next | 2: b1:=tADC2; b2:=tADC3; LongADC1:=tADC1; LongADC2:=tADC2; LongADC3:=tADC3; LongADC4:=tADC4; ADCx[2]:=w; xADCChannel:=0; // next xADCdone:=true;| endcase; end; Auslesen und neu starten damm per timer, zB alle Sekunde oder so. main() loop if timercame then .. ReadADC; StartADC; .. timercame:=false
:
Bearbeitet durch User
Joggel E. schrieb: > I steuere externe SPI Devices ueblicherweise ueber irgendwelche Pins an. > Die werden zuoberst definiert. Danke Joggel für den guten Willen ! Das hatte ich anfangs auch über irgendwelche Pins gemacht weil das besonders flexibel ist. Dann nahm ich lieber das SPI-Interface des AVR-Chips her. Es gibt auch das TWI-Interface. Man kann es nehmen, muss aber nicht. Man kann die SPI-Register schreiben und lesen. Das hat bisher geklappt bis zu diesem Chip. Ich nehme halt kein Pascal, sondern C.
Naja. du wolltest etwas was funktioniert... zu lesen ist der Code. Und ist mit C implementierbar.
Joggel E. schrieb: > Naja. du wolltest etwas was funktioniert... der Code läuft bei Dir mit dem AD7798? > zu lesen ist der Code. Und ist mit C implementierbar. ja. Meine Pascal-Erfahrungen (Lesen eines Buchs dazu) stammen von 1986. Seitdem habe ich nichts damit gemacht.
mit dem 7799, welcher 24 bit wandelt, entgegen den 16 bit des 7798. Also einfach die Register und commands vergleichen und anpassen.
Joggel E. schrieb: > mit dem 7799, welcher 24 bit wandelt, entgegen den 16 bit des 7798. ok. Danke für den Hinweis.
Es gibt Beispielcode vom Hersteller: https://wiki.analog.com/resources/tools-software/uc-drivers/renesas/ad7799
Tippgeber schrieb: > Es gibt Beispielcode vom Hersteller: Boooaahhh, kaum 8 Monate später gibt Tippgeber einen heissen Tip. Bei solchen Rekationszeiten kann es ja hurtig voran gehen.
Tippgeber schrieb: > Es gibt Beispielcode vom Hersteller: > https://wiki.analog.com/resources/tools-software/uc-drivers/renesas/ad7799 danke für den Hinweis. Es gab auch damals ein Evaboard mit Code. Nur weiß man eben leider nicht wo der Fehler dann liegt. Es kann sein daß ein Fehler in der SPI-Ansteuerung ist. Dann hilft der Code auch nicht so viel. man könnte sich so ein Board kaufen falls nicht zu teuer und das anschauen und versuchen zu sehen wo Unterschiede zu meinem Design liegen. es wäre einfacher wenn es ein Beispiel für AVR gäbe.
Kalender Kalender schrieb: > Boooaahhh, kaum 8 Monate später gibt Tippgeber einen heissen Tip. immerhin. Besser als nichts. Der Wandler verschönert momentan das Design im Regal. Dort steht er gut und wartet auf die Verschrottung oder Wiederbelebung was auch immer. Das war ein Lernprojekt - und ich habe gelernt daß nicht immer die Dinge so klappen wie sie sollen. Und wenn es klemmt gibt es manchmal keine einfache Lösung.
> Und wenn es klemmt gibt es manchmal keine einfache Lösung.
Oh. Doch. Messmittel vorausgesetzt, muss man jede Zeile des Datenblattes
lesen, anwenden, messen, nachvollziehen, korrigieren.
Pandur S. schrieb: > Oh. Doch. Messmittel vorausgesetzt, muss man jede Zeile des Datenblattes > lesen, anwenden, messen, nachvollziehen, korrigieren. wenn die Datenblätter doch immer so eindeutig und leicht zu verstehen wären.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.