Kleines Problem mit Leonardo Pro Micro: ein Programm das auf dem Arduino Uno problemlos läuft, funktioniert auf dem Leonardo Pro Micro nicht, bzw keine Anzeige. An pin 2 (SDA) und pin 3 (SCL) kann ich mit dem Oszi Signale sehen. Muss hier evtl die Library angepasst werden? Vertraegt das Display kurzfristig 5 Volt vom Leonardo bzw kann man zwei Dioden dazwischenhaengen? Im Anhang noch ein Bild, bei Bedarf kann ich natürlich den Code posten.
Angehängte Dateien:
-
leonardo_pro_micro.JPG
230 KB
Nutzt du die Arduino Umgebung? Für AS könnte ich dir funktionierende Sourcecodes geben. Und wenn Arduino: Warum um Gottes Willen stellst du deine Frage nicht auch im offiziellen Arduino Forum?!?!
Bernhard F. schrieb: > ein Programm das auf dem Arduino Uno problemlos läuft, funktioniert auf > dem Leonardo Pro Micro nicht, bzw keine Anzeige. Auf dem Pro Micro sitzt ein ganz anderer Prozessor, als auf dem Uno. Vielleicht liegt es an deinem Programm. Hast du da schon mal geguckt? Ohne Schaltplan und Programm zu kennen, ist es schwierig, etwas zur Lösung deines Problems beizutragen.
Forist schrieb: > Auf dem Pro Micro sitzt ein ganz anderer Prozessor, als auf dem Uno. Sollte nicht viel ausmachen, ist ja schließlich I2C, und das können sie beide. Auf dem Bild sehe ich keine Pullup. Und wenn da keine Sind, kanns auch nicht gehen. Bernhard F. schrieb: > An pin 2 (SDA) und pin 3 (SCL) kann ich mit dem Oszi Signale sehen. Und? Sehen sie gut aus?
Nutze die Arduino 1.8.1 unter Ubuntu, würde auch gerne deine Codes nutzen. Möchte die Temperatur von einem DS18B20 (one wire) auf einem I2C Display anzeigen. Ich lese sehr gerne das MC Forum und müsste mich im Arduino Forum wieder anmelden.
Auf dem Arduino läufts auch ohne Pullup, werde aber den Rat befolgen.
Habe jetzt 5k Pullup eingesetzt und funktioniert super, warum am Arduino Uno auch ohne ?? Wieder einmal vielen Dank ins Forum.
Bernhard F. schrieb: > warum am Arduino > Uno auch ohne ?? Manche Arduinos haben sie schon onBoard. Die großen ja, die kleinen eher nicht. Einfach mal den Schaltplan untersuchen, das bringt die erhoffte Klarheit. Grundsätzlich: Wenn I2C, dann ein Auge auf die Pullup. Grundsätzlich. Sonst Sorgen. Und das, das wollen wir doch alle nicht.
CO2 ist ihm N. schrieb: > Arduino F. schrieb: >> Pullup > > Warum wird der nicht mit rein programmiert? > > LG > old. Wird doch! Das macht die Wire Lib.
CO2 ist ihm N. schrieb: > Arduino F. schrieb: >> Pullup > > Warum wird der nicht mit rein programmiert? > > LG > old. Weil das bei bidirectionalen Ports nicht so einfach geht, und die internen PullUp für I²C ohnehin zu hoch-ohmig sind.
:
Bearbeitet durch User
Harry L. schrieb: > Weil das bei bidirectionalen Ports nicht so einfach geht, und die > internen PullUp für I²C ohnehin zu hoch-ohmimig sind. Doch, werden schon aktiviert! Aber ja, alleine reichen sie nicht/selten.
Arduino F. schrieb: > die Wahrheit der interne Pullup ist zu hochohmig dafür. Sag das doch einfach. LG old.
CO2 ist ihm N. schrieb: > Sag das doch einfach. Spezifikation lesen und selber denken! Ich bin doch nicht deine Denkprotese....
Arduino F. schrieb: > Harry L. schrieb: >> Weil das bei bidirectionalen Ports nicht so einfach geht, und die >> internen PullUp für I²C ohnehin zu hoch-ohmimig sind. > > Doch, werden schon aktiviert! > Aber ja, alleine reichen sie nicht/selten. Das hast du wohl nicht ganz durchdacht. Wenn du das machst, musst du deinen Pin-Zustand invertiert über das DDR-Register schreiben. PORTx[0..7] muß ja High bleiben - wegen dem PullUp. Mit DDRx[0..7] schaltest du dann die output-Stufe ein, und das darfst du nur bei Low-Pegel. Kannste zwar so machen, aber dann isses eben Kacke....
Harry L. schrieb: > die > internen PullUp für I²C ohnehin zu hoch-ohmig sind. Danke für die korrekte Antwort, während ich noch schrieb. LG old.
Harry L. schrieb: > Das hast du wohl nicht ganz durchdacht. > Wenn du das machst, musst du deinen Pin-Zustand invertiert über das > DDR-Register schreiben. > PORTx[0..7] muß ja High bleiben - wegen dem PullUp. > Mit DDRx[0..7] schaltest du dann die output-Stufe ein, und das darfst du > nur bei Low-Pegel. > > Kannste zwar so machen, aber dann isses eben Kacke.... Arduino machts per Hardware I2C und die tut das schon richtig. Da muss man nicht selber am DDRX und PORTX rum wackeln. Du bist im Soft I2C Film > Das macht die Wire Lib. Ist also nicht ganz richtig. Die von der Lib genutzte Hardware tut es.
Arduino F. schrieb: > Eine negative Bewertung für die Wahrheit? Nichts ungewöhnliches. Dafür eine positive für die Oszillogramme. LG old.
Arduino F. schrieb: > Spezifikation lesen und selber denken! > Ich bin doch nicht deine Denkprotese.... Den Schuh zieh´ ich mir nicht an, weil Bernhard F. schrieb: > An pin 2 (SDA) und pin 3 (SCL) kann ich mit dem Oszi Signale sehen. Im Gegensatz zu Euch beiden konnten wir Zuschauer die Signale vorher nicht sehen. Bernhard F. schrieb: > Wieder einmal vielen Dank ins Forum. Hollywood LG old.
CO2 ist ihm N. schrieb: > Im Gegensatz zu Euch beiden konnten wir Zuschauer > die Signale vorher nicht sehen. Was denkst du dir eigentlich... Schau mal auf das Datum der PDF Bilder.... Mannno... Du machst hier im Thread die Welle, obwohl du ganz offensichtlich keine Ahnung von I2C hast. Kommt dir das nicht selber etwas komisch vor?
Arduino F. schrieb: > keine > Ahnung von I2C hast Natürlich nicht. Ich habe I2C beim arduino im Gegensatz zu Euch beiden noch nie oszillographiert. Und deshalb kläffst Du mich an?! LG old.
Also da kommt man dann an den Punkt wo man sieht das Arduino ja doch etwas... Naja... ist. Bei einem Hardware I2C, wenn man diesen benutzt, benötigt man keine externen Pull-Up. Das erledigt die Hardware schon selbst. Der Leonardo nutzt ja einen Atmega32u4, richtig? Und wenn man nur einmal, nur EINMAL, in das Datenblatt schauen würde von dem MC den man da gerne Programmieren würde wollen, würde man sehen das der Atmega32u4 gar kein HW-I2C hat / kann. SPI ja, I2C nein. Da sind dann wieder die Probleme: "Hardware nutzen und verstehen - Level: Arduino!"
Rene K. schrieb: > Bei einem Hardware I2C, wenn man diesen benutzt, benötigt man keine > externen Pull-Up. Das erledigt die Hardware schon selbst wie verträgt sich das mit OC bei I2C? Wie soll das denn die Hardware ohne externe pullups machen wenn I2C per Definition OC sein soll? abgesehen davon hat ein Arduino i.d.R. keine OC Ausgänge, das sind push pull CMOS oder wir reden von was völlig anderes. Meine Arduinos kennen ja noch nicht mal clock stretching
Rene K. schrieb: > Und wenn man nur einmal, nur EINMAL, in das Datenblatt schauen würde von > dem MC den man da gerne Programmieren würde wollen, würde man sehen das > der Atmega32u4 gar kein HW-I2C hat / kann. SPI ja, I2C nein. Leider weiß nicht jeder, dass I2C bei Atmel TWI genannt wird. Damit würde man das dann auch im Datenblatt finden. Rene K. schrieb: > Da sind dann wieder die Probleme: "Hardware nutzen und verstehen - > Level: Arduino!" Ach, es gibt noch viel mehr Leute, welche kein Datenblatt lesen können.
Arduino F. schrieb: > Leider weiß nicht jeder, dass I2C bei Atmel TWI genannt wird. > Damit würde man das dann auch im Datenblatt finden. Und wenn, wüsstest du das TWI (gerade das Atmel TWI) proprietär zu I2C ist. Und somit ein Superset von I2C. UND I2C ist nicht TWI!
Joachim B. schrieb: > Meine Arduinos kennen ja noch nicht mal clock stretching Stimmt das? Meine Messungen sagen, dass ein AVR Slave bei einem R Zugriff etwas Zeit braucht um die Daten zusammen zu klauben. Und dazu muss der Slave den Takt ziehen. Ebenso muss der AVR Master das korrekt abhandeln, also das Stretching "erdulden". Und, das tut er auch. Irgendwelche Timeouts habe ich im Arduino Master Code bisher nicht gefunden. Kann also durchaus sein, dass der Slave den Takt bis Weihnachten ziehen darf. Stretching an Bytegrenzen ist also völlig ok. Das habe ich geprüft. Wie es mit dem Stretching zwischen einzelnen Bits aussieht, weiß ich nicht.
Arduino F. schrieb: > Kann also durchaus sein, dass der Slave den Takt bis Weihnachten ziehen > darf. und was dann? soweit ich gelesen hatte keine Chance auf timeout, es sei denn man nimmt einen anderen Pin als Hilfe der gepollt wird + Timer.
Beitrag #5086581 wurde von einem Moderator gelöscht.
Ist mir in der Praxis noch nicht unter gekommen, dass ein Slave den Bus blockiert. Joachim B. schrieb: > es sei denn man nimmt > einen anderen Pin als Hilfe der gepollt wird + Timer. Wird nicht gelingen, da die Arduino Wire Lib blockierend arbeitet. Also: Ein Fall für den WDT
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.