wenn ich dich richtig verstehe, benutzt du aber (auch) nur einen AVR, oder?Zitat von Klebwax
Mit AVRs funktioniert es aber doch auch mit "meinem" Code!
Oder hast du es bei dir mit einem Due oder M4 erfolgreich getestet? Das wäre ja erstmal die erste Hürde.
Nein, ich habe keine AVR/Arduino. Ich benutze PICs. Der Code funktioniert auf PIC16xx (8 Bit) und auf PIC24xxx (16 Bit). Das Ganze nach lua umgesetzt funktioniert auch auf dem ESP8266 (ich benutze die lua-Firmware). Und der Python-Code für den Raspi, den ich im Netz gesehen habe, macht das genauso. Bin aber noch nicht dazu gekommen, meinen Nunchuk am Pi zu betreiben (zu viele Projekte). Ich verwende I2C häufig, baue mir auch meine eigenen Slaves aus kleinen µC, Um der Frage zuvorzukommen, ich verwende i.d.R. keine libs. Ich benutze die nur als Anhaltspunkt, wenn mir etwas im Datenblatt unklar ist. Im Vergleich zu anderen Prokollen/Schnittstellen ist I2C so simpel, das es eigentlich schneller ist eigenen Code zu schreiben, als fremde Libraries wirklich zu verstehen.
Wenn C-Code (oder auch C++) nur auf bestimmten Prozessoren funktioniert, ist er Schrott und da, wo er geht, ist es eher Zufall.Mit AVRs funktioniert es aber doch auch mit "meinem" Code!
Oder hast du es bei dir mit einem Due oder M4 erfolgreich getestet? Das wäre ja erstmal die erste Hürde.
Wenn ich dann auch noch so etwas lese, wundert mich das nicht. Was nun, 0x00 oder 0x55? Das kann beim Debuggen mal vorkommen, aber das veröffentlichen? Da hat jemand, das was er gemacht hat nicht wirklich ernst genommen.Code:Wire.write((byte)0x55); // send a zero
MfG Klebwax
Strom fließt auch durch krumme Drähte !
Andere Codes, die wenigstens bei Arduino-AVRs funktionieren, hier schlecht zu reden, ist ziemlich billig....
Allerdings: PICs sind hier nicht das Thema, und auch Arduino AVRs sind nicht das Thema, sondern alleine Arduino-Code für die M3 und M4 Cores. Außerdem steht immer noch im Raum, dass möglicherweise der Nunchuk wegen clock-stretching oder wegen elektrischer Probleme etc. noch nicht mal 100%ig sicher auf jedem i2c-Bus mit jedem Board läuft.
Solange also dein Code nicht Arduino-ARM-kompatibel ist und noch nichtmal getestet werden konnte, nützt es nichts, und dein Code müssste dazu auch erstmal für M3/M4 in Arduinisch überhaupt zur Verfügung stehen - und darauf wäre ich wirklich gespannt.
Darf ich hier mal kurz reingrätschen und darauf hinweisen, dass wir nciht bare-metal sondern arduino und nodeMCU (das meintest du doch mit lua oder?) bibliotheken reden?
das bedeutet dass die implementation der lib für das jeweilige board durchaus äußerst unterschiedlichen sein könnte und @HaWe dein Problem gehört streng genommen in den Arduino Bugtracker, denn es kristallisiert sich immer mehr heraus dass wohl an der lib für die due boards etwas nicht stimmt dass dein nunchuck ins stlpern bringt!
ich lege nochmal dringend ans herz zu prüfen ob du irgendwie delays zwischen dem start und stop conditions einfügen kannst oder beim auslesen zwischen schreiben der registeradresse und dem beginn des lesens, vielleicht löst das dein problem schon aber ganz ohne oszilloskop um die signale zwischen den boards zu vergleichen wird das nichts
schau mal ob du dir nicht einen günstigen logic analyzer besorgen kannst oder vielleicht sogar mit einem zusätzlichen board einen DIY logic analyzer bauen kannst
mir ist klar dass du normal immer auf libs setzt um dich nciht mit sowas auseinandersetzen zu müssen, aber die libs werden auch nur von menschen geschrieben und könen fehler beinhalten (und darauf wette ich in diesem fall sogar)
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
@Ceos:
mein Code oben (von uxomm) nutzt keine weiteren Libs, und wenn du meinst, dass der Code anders aussehen müsste, dann ändere ihn mal bitte so um, das er in der geänderten Form getestet werden kann.
Auch ist es nicht nur der Due, sondern auch der Adafruit M4, der betroffen ist, und beide hatten bisher NIE Probleme mit meinen Standard-I2C-Geräten (OLED SSD1306, MPU6050, CMPS11, CMPS12, BME280, BMP280, PCF8574, MCP9808, ADS1115).
Wir sind hier ja auch im Arduino-Unterforum, daher ist es klar, dass eine funktionierende Arduino-Lösung (für i2c-Wire-class) gebraucht wird.
@Klebwax:
Sorry, das sollte in keinster Weise Kritik am Code sein.,
zumal Du völlig recht hast. Der Code ist so richtg.
Ich hab mich durch "temp" verwirren lassen. Dein temp wird ja tatsächlich ausgewertet.
Ich dachte zuerst, das ist so eine Art dummy read.
Da steht der Tastenstatus und es wird auch das NACK gesendet.
Also alles völlig okay.
Zum Problem:
Es ist schon mehrfach bei mir aufgetreten, dass alter Code, der auf verschieden Controllern lief,
plötzlich auf dem ARM nicht mehr lief. Bei mir ARM-Cortex M3
Dazu gehört z.B. atomarer Code. Nur mit Verrenkungen geht das überhaupt.
Das betrifft pre und postincrement, das kann er nicht atomar.
Habe auch I2C Interrupts bekommen mit Status 0xF8.
den gibt es garnicht, das wäre nämlich "idle modus" alles erledigt.
Interrupt Problem, tritt nur mit C-Compiler O3 Option auf. Auch hier ein typisches Cortex-M3 Phänomen
durch die internen Write Buffer.
Da bei HaWe aber schon diverse andere Chips am I2C laufen, müssen es wohl noch andere Problem geben.
Ich tippe auch auf die LIB.
Siro
Geändert von Siro (09.04.2019 um 10:23 Uhr)
@Siro: welche LIB??Ich tippe auch auf die LIB.
uxomms Code nutzt keine LIB, nur das ganz normale Arduino-Wire() für i2c, und was anderes gibt es für Arduino standardmäßig nicht!
arduino IST eine c-lib ... es geht hier nicht um externe sondern um die eigentliche basis lib arduino
wenn du kein arduino nutzt müsstest du die register händisch adressieren udn dem datenblatt folgenden inistailiseren um I2C nutzen zu können. mit arduino geht das nur weil irgendjemand anderes für dich das interface geschrieben hat udn wieder jemand anderes die anbindung an die entsprechende hardware geschrieben hat.
arduino ist kein compiler sondern nur eine library zum erleichterten programmieren in c, du compilierst imernoch grundlegenden und boardspezisfischen c code mit einem einfachen gcc
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
ich habe mir dein Link aus dem ersten Beispiel nochmal angesehen udn entdeckt, dass dort überall delay(1) verbaut sind aber auskommentiert
https://github.com/infusion/Fritzing...chuk/Nunchuk.h
kommentier doch mal probehalber die ganzen delay(1) ein und schau ob das zu besseren ergebnissen führt, damit wäre zumindest schonmal sichergestellt dass dein reine ablauf ein timing problem hat oder nicht
wenn es nicht klappt sehe ich das problem defintiv in der wire-lib implementation für die boards due und M4 und kann nurnoch empfehlen sich an deren entwickler zu wenden oder hier auf antwort von jemand mit der gleichen hardware zu hoffen (support aber eben leider nur in englisch ... PS da ist schon ein issue das das gleiche problem beschreibt, kannst du mal die prozessoren benennen die auf den boards verbaut sind, dann könnte ich mal eine antwort in das topic für dich setzen)
Es gibt 10 Sorten von Menschen: Die einen können binär zählen, die anderen
nicht.
Berechtigungen
Zitieren
Lesezeichen