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.
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.
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.
Weil das bei bidirectionalen Ports nicht so einfach geht, und die
internen PullUp für I²C ohnehin zu hoch-ohmig sind.
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:> 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:> 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:> 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.
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
leonardo_pro_micro.JPG
(230 KB)
