Liebe Kollegen,
ATMEGA644 (5V),
Quarz 14,7456 MHz
TWI Konfiguration:
#define F_CPU 14745600UL
#define SCL_CLOCK 100000L
TWBR = ((F_CPU/SCL_CLOCK)-16)/2; (ergibt 0x41)
Das sind gemessen aber nur 11,3 kHz Bustakt auf der SCL Leitung.
Selbst wenn ich das Register runterdreh komm ich auf maximal 50kHz.
Weiß jemand wo mein Fehler liegt und wieso da keine 100kHz rauskommen?
Vielen Dank für Antworten und Denkanstöße ...
Ich habe mir angewöhnt, beim Programmstart eine LED für eine definierte
Zeit aufblitzen zu lassen. Daran erkenne ich ob der Mikrocontroller
startfähig ist und ob er mit der richtigen Taktfrequenz läuft. Außerdem
erkenne ich daran unerwartete Neustarts.
Damit beginnt eigentlich jede Fehlersuche, das sind immer die ersten
Fragen, die es zu klären gibt.
Den selben I/O Pin kann man später auch zum Ausgeben von Debug Meldungen
(Soft-UART) nutzen.
Gute Idee. Ich hab zwar auch immer meine Standard LED die mir anzeigt,
dass das Programm läuft, aber einmal aufblitzen lassen ist natürlich
eine gute Idee. Werd ich umsetzen :-)
Chris schrieb:> Ich hab zwar auch immer meine Standard LED die mir anzeigt,> dass das Programm läuft
Die wird ja hoffentlich nicht nur eingeschaltet, sondern blinkt
beruhigend vor sich hin. Und dann sieht man auch, wenn sie unrgelmäßig
oder viel zu langsam vor sich hinblinkt.
Stefan ⛄ F. schrieb:> Den selben I/O Pin kann man später auch zum Ausgeben von Debug Meldungen> (Soft-UART) nutzen.
Man kann sogar die LED zur Ausgabe von Meldungen verwenden, wenn man
einen passenden Opto-Empfänger drüber stülpen kann. Ich gebe solche
Informationen dann immer während der "Hell" Phase der blinkenden LED
aus. Und kein Mensch glaubt, dass die LED mehr tut, als nur tumb vor
sich hinzublinken.
Lothar M. schrieb:> Man kann sogar die LED zur Ausgabe von Meldungen verwenden, wenn man> einen passenden Opto-Empfänger drüber stülpen kann. Ich gebe solche> Informationen dann immer während der "Hell" Phase der blinkenden LED> aus. Und kein Mensch glaubt, dass die LED mehr tut, als nur tumb vor> sich hinzublinken.
SAUGUT! Werde ich künftig umsetzen.
Tip von mir: Bei batterieversorgten Applikationen habe ich einen Jumper,
wenn der gesetzt ist blinkt die Status-LED, wenn nicht bleibt sie
dunkel, so spare ich Batterielaufzeit.
Lothar M. schrieb:> Man kann sogar die LED zur Ausgabe von Meldungen verwenden, wenn man> einen passenden Opto-Empfänger drüber stülpen kann.
Oh Gott, da muss man sich ja noch ein Protokoll überlegen
und auch noch implementieren ....
hard worker schrieb:> Oh Gott, da muss man sich ja noch ein Protokoll überlegen> und auch noch implementieren ....
Wie wäre es mit UART und printf()?
Bei meinem Motorrad haben sie es ähnlich gemacht. Wenn es um Hilfe ruft,
blinkt die gelbe Status LED einen Fehlercode, sonst beleuchtet die das
Markenlogo.
Ich möchte nochmal auf das Thema vom Thread zurückkommen.
Laut Berechnung (siehe ersten Post) ergibt sich 0x41 für 100kHz. Da
kommen aber nur 89kHz raus. Wenn ich auf 0x39 für TWBR Register
runtergehe, dann komm ich auf gemessene 98,3kHz. Die 0x38 liegen dann
schon über 100kHz.
Die Frage: Hab ich da etwas übersehen, oder ist das an der Stelle
einfach nicht so genau?
Chris schrieb:> Ich möchte nochmal auf das Thema vom Thread zurückkommen.>> Laut Berechnung (siehe ersten Post) ergibt sich 0x41 für 100kHz. Da> kommen aber nur 89kHz raus.>> Die Frage: Hab ich da etwas übersehen, oder ist das an der Stelle> einfach nicht so genau?
Du mißt wohl falsch. Wie mißt du es denn? Und hast du einen Slave am
Bus, der Clock Stretching macht?
> Du mißt wohl falsch. Wie mißt du es denn? Und hast du einen Slave am> Bus, der Clock Stretching macht?
Ich messe von Flanke zu Flanke das SCL Signal.
Ein Slave ist am Bus (TLV493D Magnetfeldsensor). Mit dem Slave hab ich
noch keinen Kontakt herstellen können. Kämpfe noch mit der Startsequenz,
die im Datenblatt angegeben ist.
Axel S. schrieb:> Du mißt wohl falsch.
So sieht es aus.
In dem Screenshot wird zwar großartig 98kHz angezeigt, tatsächlich
passen in 80µs(*) aber 9 Bits, was 8,8µs pro Bit und damit 112kHz
wirkliche Taktrate sind.
(*) zwischen -22,6 bis 57,4µs zähle ich 9 Takte. Und welcher
Programmierer kommt eigentlich auf die blödsinnige Idee, solch krumme
Werte zu skalieren?
H. H. schrieb:> Und bei 20µs/div auch gut zu sehen.
Ach blöd aber auch, mit diesen schwachsinnigen Nachkommastellen und dem
eigenartigen Anzeigenrundungsfehler um 0 herum habe ich gar nicht
erkannt, dass das 20µs/div sind. Und genau diese allerwichtigste
Skalierung wird nirgends angezeigt.
Was ist denn das für ein Ding? Nicht, dass ich es aus Versehen auch noch
kaufe...
Vielen Dank für die Antworten.
Ja, das war blöd von mir eingestellt. Hab das Gitter jetzt auf 20µs
gestellt und mit dem Cursor nachgemessen. Es sind exakt 100kHz. Danke
für die Tipps.
Ich hatte mich auf die automatische Messung verlassen. Da steht immer
noch 89kHz. Ich tauche mal in das Handbuch ab, was denn da gemessen
wird. Auf alle Fälle ein Bedienungsfehler von mir. Schön, dass ich hier
von außen Input erhalte, dass bringt mich aus so mancher gedanklicher
Sackgasse :-)
Lothar M. schrieb:> Man kann sogar die LED zur Ausgabe von Meldungen verwenden, wenn man> einen passenden Opto-Empfänger drüber stülpen kann.
Etwas Off-Topic: Kannst Du einen Empfänger empfehlen?
Chris schrieb:> Ich hatte mich auf die automatische Messung verlassen. Da steht immer> noch 89kHz. Ich tauche mal in das Handbuch ab, was denn da gemessen> wird.
Der erste und letzte Takt ist wohl etwas länger. Kann man am negativen
Puls erahnen.
Walter T. schrieb:> Kannst Du einen Empfänger empfehlen?
Das war irgendein BPW, eine Komparatorschaltung dahinter mit einem Poti
dran, mit dem die Kommunikation per passendem Fotostrom (Vorwiderstand)
hinfrickeln kann. Wie gesagt verwende ich das Ding nur für Notfälle zum
Debuggen. Da muss dann zur Abschirmung von Fremdlicht schon mal was
gebastelt werden.
Solange die Schaltung auf dem Schreibtisch liegt, gibt die LED auch was
aus, aber es klemmt ein Draht dran. Dann saprt man sich das "Feintunen",
bis der Empfang halbwegs sicher steht.