TWI mit 14,7456 MHz Quarz nur auf 11,3kHz Bustakt

Gast #6798773
Lesenswert?

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 ...
Gast #6798852
Lesenswert?

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.
Moderator (Firma: Titel) Persönliche Seite #6798930
Lesenswert?

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.
Gast #6798932
Lesenswert?

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.
Gast #6798998
Lesenswert?

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.
Gast #6799722
Lesenswert?

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?
#6799793
Lesenswert?

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?
Gast #6800083
Lesenswert?

> 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.
Angehängte Dateien:
Moderator (Firma: Titel) Persönliche Seite #6800101
Lesenswert?

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?
Moderator (Firma: Titel) Persönliche Seite #6800122
Lesenswert?

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...
Gast #6800160
Lesenswert?

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 :-)
Angehängte Dateien:
Moderator (Firma: Titel) Persönliche Seite #6800194
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren