Analyzer für I2C/TWI und 1-Wire/microLAN

[dino03]

USART läuft (mit memory-mapped Registern)

Hallo alle,

Als nächstes wird wohl die RS232 und danach der
256-Byte Ring-Puffer kommen.

und wieder ein Problem im Sack
Der USART läuft mit 115k2 8n1 und knallt mir das Terminal-Fenster vom PuTTY
mit einem Testtext voll ...
230k4 kann der PC leider nicht mehr

"the quick brown fox jumps over the lazy dog 0123456789 THE QUICK BROWN
FOX JUMPS OVER THE LAZY DOG 0123456789 "

Wer sich fragt warum man so einen blöden Text nimmt ... in dem Satz sind
alle Buchstaben des normalen Alphabets enthalten. Testtext für Fernschreiber.
und man kann ihn sich relativ gut merken.

Das arbeitet jetzt unter dem Menüpunkt "Systemtest".

Ne Tabelle mit 16 verschiedenen Baudraten habe ich auch schon angelegt.
Die wird sich dann auch durchwählen lassen.

Jetzt fehlt noch der 256-Byte Ring-Puffer (Sendepuffer vom Analyzer).

------21.03.09 20:15------
Ich mach erst mal ne kleine Designänderung im Programm um mir in Zukunft
die Arbeit zu erleichtern und zwar folgendes ...

aus ...

ldi ZH,0x3A
ldi ZL,0x15

wird ...

ldi ZH,HIGH(2*flashaddr)
ldi ZL,LOW(2*flashaddr)

Damit muß ich im Quellcode nichts mehr per Hand anpassen, wenn ich die
Tabellen, Texte, ... im Programmflash an eine andere Stelle verschiebe.

Gruß
Dino

 

[dino03]

Hallo zusammen,

ich wollte mal wieder die neueste Version des Quelltextes hier reinstellen.

>>>> Da isser >> >> Anhang anzeigen TWI-1W-Analyzer_v12.zip

Alle Tabellen im Flash werden jetzt über Label angesprochen. Damit
erspar ich mir größere Änderungen (Editor-Orgien) wenn ich die
Tabellen mal wegen Platzmmangel verschieben muß.

Die Baudraten-Tabelle ist jetzt auch in Verwendung und im Modus
RS232-Testtext kann man einen Text von 1k2..250k0 8n1 senden.
Die Baudrate läßt sich sehr schnell umschalten (Up/Down) und
dann muß man nur noch einen Taster drücken um den Testtext
abzufeuern

Als nächstes kommt jetzt der Ring-Puffer ...

So wie es aussieht wird es wohl ein recht brauchbares Werkzeug
für jeden Bastler

Gruß
Dino

 

[dino03]

Erste Anfänge der I2C/TWI-Analyse

Hallo Leute,

es geht weiter. Heute hab ich mir mal ein paar Gedanken gemacht, wie ich
das mit der Erkennung der I2C Bits und Signale mache. Mal so ein wenig
auf nem Blatt rumgemalt und so. Ich laß euch mal an meinen Gedankengängen
teilhaben Evtl hilft es ja einem anderen bei einer Problemlösung.

Also zuerst, was haben wir beim I2C für Zustände auf dem Bus ...

Datenübertragung
SDA -====- Darf sich nur wärend der Low-Phase von SCL ändern
SCL __--__ Die Daten sind wärend High-Phase gültig

Start-Signal
SDA ---___ 1->0 => negative Flanke
SCL ------- 1--1 => bleibt 1

Stop-Signal
SDA ___--- 0->1 => positive Flanke
SCL ------- 1--1 => bleibt 1

=== Datenübertragung - noch mal zerlegt ===

Daten - Change 1->0
SDA ---___ 1->0 => negative Flanke
SCL ______ 0--0 => bleibt 0

Daten - Change 0->1
SDA ___--- 0->1 => positive Flanke
SCL ______ 0--0 => bleibt 0

Daten 0 - Valid Start
SDA ______ 0--0 => bleibt 0
SCL ___---- 0->1 => positive Flanke

Daten 0 - Valid Ende
SDA ______ 0--0 => bleibt 0
SCL ----___ 1->0 => negative Flanke

Daten 1 - Valid Start
SDA ------- 1--1 => bleibt 1
SCL ___---- 0->1 => positive Flanke

Daten 1 - Valid Ende
SDA ------- 1--1 => bleibt 1
SCL ----___ 1->0 => negative Flanke

Um die Flanken und Änderungen alle zu erkenne werde ich den
PinChangeInterrupt auf SDA und SCL anwenden.

SDA liegt auf Port PC4 und SCL liegt auf Port PC5. Wir haben also folgende
Portbit-Belegung ...

PC7 PC6 PC5(SCL) PC4(SDA) PC3 PC2 PC1 PC0

uns interessieren aber nur Bit 4 und 5. Alles andere wird also mit 0 gelöscht.
(das geht mit cbr Register,0xCF ; Clear Bits in Register)

Um Flanken zu erkennen nutze ich meinen altten Trick mit dem Bits
verschieben 2 Bits müssen erkannt werden und 2 Bits sind in dem Byte
noch frei (6+7). Wir bauen uns also folgendes Konstrukt ...

Bit7 | Bit6 | Bit5 | Bit4 | Bit3 | Bit2 | Bit1 | Bit0
SCL | SDA | SCL | SDA | -0- | -0- | -0- | -0-
_letztes_ | _aktuelles_ | __uninteressant__

Und jetzt kommt der Gehirnschmalz Wir setzen unsere obigen Diagramme
in eine Zustands-Tabelle um (man ich krieg Zustände)

last now
C D C D
0 0 0 0 =====> Spikes
0 0 0 1 -> Daten Change 0->1 (0x10)
0 0 1 0 -> Daten 0 Valid Start (0x20)
0 0 1 1 =====> SDA+SCL mit positiver Flanke
0 1 0 0 -> Daten Change 1->0 (0x40)
0 1 0 1 =====> Spikes
0 1 1 0 =====> SDA negative Flanke + SCL positiver Flanke
0 1 1 1 -> Daten 1 Valid Start (0x70)
1 0 0 0 -> Daten 0 Valid Ende (0x80)
1 0 0 1 =====> SDA positive Flanke + SCL negative Flanke
1 0 1 0 =====> Spikes
1 0 1 1 -> Stop-Signal (0xB0)
1 1 0 0 =====> SDA+SCL mit negative Flanke
1 1 0 1 -> Daten 1 Valid Ende (0xD0)
1 1 1 0 -> Start/RepeatedStart (0xE0)
1 1 1 1 =====> Spikes

Alle mit ===> sind Fehlerzustände, die man abfangen muß oder als
Fehlermeldung ausgeben kann.

Damit habe ich nun für die weitere Arbeit am Analyzer die Zustände des
I2C/TWI-Busses vorliegen. In Assembler sieht das ungefähr so aus ...



CodeBox ASM

 ; InterruptServiceRoutine für PinChange von SDA+SCL

in neues,PortC  ; Port abfragen - Bits 4+5 sind interessant (SDA/SCL)

cbr neues,0xCF  ; alle unnötigen Bits löschen

lsl  speicher   ; den aktuellen Zustand der alten Abfrage in die Position

lsl  speicher   ; last schieben (Bits 4+5 nach Bits 6+7) also 2 Positionen weiter

                ; aufgefüllt wird dabei von rechts mit Nullen (spart Arbeit)

add speicher,neues  ; Das neue und alte zum Wert aus der Zustandstabelle

                ; kombinieren und wieder speichern

 ; jetzt können wir je nach Wert entscheiden was wir weitermachen wollen

Jetzt muß ich nur noch die Bits zusammensetzen oder Fehlermeldungen
ausgeben.

Auf diese Art kann ich auch fehlerhafte Zustände auf dem Bus oder Spikes im Bereich
100..400ns erkennen.

So einfach kann das Leben sein

Gruß
Dino

 

[dino03]

Doch nicht so einfach ...

Hallo alle,

ich hab noch ein paar weitere Gedanken gehabt ...
Mit meiner Methode könnte es ein paar Engpässe mit dem Timing geben
da der PinChangeInterrupt dann wohl 3x bei einem Bit auslösen würde:

1. Data-Change (SDA) --__ oder __--
2. Data valid Start (SCL) __--
3. Data valid Ende (SCL) --__

also habe ich bei 100kHz Datentakt ca 3us pro Vorgang (wenn überhaupt).
Das wird wohl schwierig. Ich glaube, hier brauche ich eine echt gute Idee
um das Problem zu lösen. ....

Na mal sehen. Noch ein paar mal drüber schlafen. Evtl kommt dann ne gute
Idee ganz von selbst ...

Oder hat einer von euch ne Lösung dafür ??

Hier mal das Timing für SCL kleiner/gleich 100kHz

Takt kleiner oder gleich 100kHz

        ___________               _____                ______________
SCL ___/           \_____________/     \______________/           |
       |           |       |     |     |       |      |           |
    _________      |    ___|___________________ ___   |      _____|
SDA    |     \_________/___X___________________X___\________/     \__
       |     |     |       |     |     |       |      |     |     |
       |<--->|<--->|       |<--->|<--->|<----->|      |<--->|<--->|  
       |4,7us  4us |       |250ns  4us  0-3,4us|      | 4us  4,7us|
       |           |       |                   |      |           |
       | --START-- |       | ------Daten------ |      | --STOP--- |

- - - - - - - - -
Mal sehen, evtl muß ich SDA und SCL mit INT0 und INT1 verbinden um
flankengetriggerte Interrupts auslösen zu können die für beide Signale einzeln
sind. Ich hab mir mal ein paar andere Lösungsmöglichkeiten angesehen und
das ist so ungefähr in der Art gelöst. Ich hab auch schon an eine externe
Erkennung gedacht um das alles hardwaremäßig zu beschleunigen. Na mal
sehen.

- - - - - - - - -
Ich hab mich für eine Hardware-Beschleunigung entschieden. Damit bekomme
ich mit einem NAND-Gatter, einem EXOR und einer kleinen Verzögerung
die Start/Stop-Bedingung und die Datenübernahme ohne zusätzliches
Bit vergleichen in die Interrupt-Serviceroutinen. Dann habe ich nach dem
rausrechnen der Interrupt-Response-Time innerhalb der ISR noch Zeit von
ungefähr 65 Taktzyklen. Die Interruptverarbeitung dauernd dann von der
Auslösung bis zum Ende der ISR ca 4us. Das sollte schnell genug sein um
jedes Bit bei 100kHz mitzubekommen. Reicht evtl mit hängen und würgen
auch für 250kHz SCL. In diesen 65 Taktzyklen muß ich den Dateenbus (SDA)
abfragen, die entsprechenden ASCII-Zeichen generieren und in den Ringbuffer
schreiben. Der Rest (Versendung aus Ringbuffer mit 115k2 über die RS232 zum
PC) kann dann in der normalen Hauptschleife bearbeitet werden.

Gruß
Dino

 

[dino03]

Hardwarebeschleunigte Start/Stop-Erkennung

Hallo,

ich hab mal nen neuen Plan drangehängt ...

Unten rechts sind ein paar Gatter, mit denen ich die Start/Stop-Bedingungen
(hoffentlich) sauber erkennen kann. Damit entlaste ich die ISRs da ich die
Datenbit-Wechsel raus filter. So es denn alles funktioniert

INT0: zuständig für Start/Stop-Bedingung (negative Flanke)
- SDA=0 -> Start
- SDA=1 -> Stop

INT1: zuständig für Datenbits (positive Flanke)
- SDA=0 -> Datenbit 0
- SDA=1 -> Datenbit 1

Ich muß jetzt also keine zusätzlichen Bus-Zustände in Software behandeln.
Jetzt laß ich mich mal überraschen ob das so funktioniert

Nach der Berechnung des Timings ist das jetzt ...
- 4 Taktzyklen bis zur Auslösung des Interrupts (Eingang, Hardware)
- 4 Taktzyklen für die Ausführung des Interrupts (Push PC, Load Vector, ...)
- 3 Taktzyklen für den Sprung zur ISR (Jump INT0/INT1)
- 65 Taktzyklen für das Innere der ISR (maximal)
- 4 Taktzyklen für Rücksprung aus der ISR (RETI, Pop PC, ...)
damit habe ich 65*50ns => 3,25us Luft für die ISR

Gruß
Dino

 

[dino03]

Mal wieder ne neue Version vom Schaltplan ...

Hallo zusammen,

ich hab mal wieder ne neue Version gezeichnet.


Die Software entwickelt sich auch langsam.
Der gelesene ROM-Code von 1Wire-Devices wird jetzt
an der RS232 ausgegeben. Damit kann man jetzt
Devices im großen Maßstab erfassen.

5 Diagnose-LEDs hab ich auch noch an die unbenutzten
Gatter gepackt. Dadurch kann man besser Fehler bei
der Programmierung finden.

- - - - - - - - - - - - - - - - - -
Ich hab heute mal mit nem USB-RS232-Dongle den USART ausgelastet.
Ich konnte zu meiner Freude feststellen, das 250kBit/s kein Problem sind.
Bei einer RS232 auf dem Mainboard eines PCs ist bei 115k2 das Maximum
erreicht. Wenn man UBBRH/UBBRL weiter verkleinert sollte auch eine noch
schnellere Kommunikation zwischen dem ATmega und dem PC funktionieren.

Gruß
Dino

 

[dino03]

Hallo,

nachdem dieses Projekt jetzt schon ein knappes halbes Jahr im
Dornröschenschlaf schlummert werde ich wohl ab Oktober langsam wieder
etwas mehr Zeit haben ... endlich ...

Dann geht es hier auch weiter und beim ASCII-Terminal, der LED-Anzeige
für Uhren (7Segment und Dotmatrix) und dem Daddelboard auch.

Also ... noch etwas Geduld ...

Gruß
Dino

 

[dino03]

werde ich wohl ab Oktober langsam wieder
etwas mehr Zeit haben ... endlich ...

schön wärs gewesen.
und so begab es sich das noch ein weiteres Jahr ins Land zog
Auweia ... solange liegt das Ding hier schon halb fertig rum ...

Und damit es mal vorwärts geht hab ich einen Entschluß gefaßt. Ich werde
bei meinen Projekten die so vor sich hindümpeln auf Bascom mit eingelegtem
Assembler für zeitkritische Sachen umsteigen. Mit dem heutigen Tag fängt es
bei diesem Projekt an.

Es werden so die einen oder anderen Mußeminuten (zu Mußestunden reichts
leider nicht) in Bascom-Code umgesetzt. Das geht schneller voran und ist
effizienter.

Langsam müssen mal ein paar Nägel mit Köpfen rauskommen ...

Der Anfang ... Anhang anzeigen TWI-1W-Analyzer_Bas_100918.bas

Gruß
Dino

 

[Grandpa]

Hi Dino,

... in Bascom-Code umgesetzt. Das geht schneller voran und ist
effizienter....

na endlich. Auf diese Einsicht haben wir ja lange warten müssen....


Güsse,

Michael

 

[dino03]

na endlich. Auf diese Einsicht haben wir ja lange warten müssen....

ich wollte mich nicht auf das Niveau von eurem BASCOM-Gestümper runter
begeben Ein richtiger Programmierer ist mit jedem Bit per-Du

Gruß
Dino

 

[Dirk]

Hi Dino,

Ein richtiger Programmierer ist mit jedem Bit per-Du

der Spruch ist gut

Ich bin gespannt, wie du die zeitkritischen Bereiche hinbekommst und ob es hier ausreicht, Assembler in Bascom zu verwenden. Wenns funktioniert, würde ich mir den Analyzer gerne nachbauen

Noch einen schönen Abend,
Dirk

 

[Grandpa]

Dino, Du,

ich wollte mich nicht auf das Niveau von eurem BASCOM-Gestümper runter
begeben

wie darf ich das denn jetzt verstehen???


Michael

 

[dino03]

Hi Dirk,

Ich bin gespannt, wie du die zeitkritischen Bereiche hinbekommst und ob es hier ausreicht, Assembler in Bascom zu verwenden. Wenns funktioniert, würde ich mir den Analyzer gerne nachbauen

darfst du gerne nachbauen
Mit etwas Glück schaff ich es, 400kHz I2C mitzulesen und über den UART
zum PC zu schicken

Gruß
Dino

 

[dino03]

Hi,

PinChangeInterrupt für die Tasten läuft schon wieder rudimentär
Anhang anzeigen TWI-1W-Analyzer_Bas_100919.bas

schnell mal zusammengestümpert

Gruß
Dino

 

[dino03]

Hi zusammen,

dieser SCH...!!! T-Mobile UMTS-Zwangsproxy !!
Ich wollte nen Anhang hochlladen und es geht keiner der Buttons im Editor.
Cache gelöscht, Browser neu gestartet, ... nix hilft! Erst wie ich dann die
Verbindung getrennt und neu aufgebaut habe lief es wieder
Was basteln die da eigentlich für nen Murks zusammen ??
Die Bildkomprimierung hab ich sicherheitshalber schon abgeschaltet. Nutzt aber
auch nicht immer was damit die Buttons auch funktionieren. Ich hoffe mal die
kriegen hier bald die DSL-Strippe ran ...

Naja ...
also hier mal der neueste Code mit Bascom. Gegenüber Assembler ist das aber
schon recht aufgebläßt. 12% Flash verwendet
Ich hab ein wenig mit dem PCINT gespielt und so ein paar weitere Kleinigkeiten.

Gruß
Dino

 

[dino03]

Hallo zusammen,

die beiden INT0 und INT1 laufen und mit PCINT1 hab ich auch ein wenig gespielt
um dem I2C-Bus auf den Puls zu fühlen. Im Moment kommt nur wirres Zeugs mit
dem ich noch nicht so richtig was anfangen kann. Irgendwo ist da noch der
Wurm drin. Ich muß mir das alles nochmal ein wenig durch den Kopf gehen lassen.
Aber es entwickelt sich langsam.

Damit ich bei den Tests keine Timing-Probleme bekomme läuft der I2C-Bus
der mir die Signale liefert bis jetzt aber nur mit 29kHz (weniger ging nicht).
Trotzdem bekomme ich noch keine saubere Erkennung der Start/Stop-Ereignisse
und der Datenbits. Na mal sehen

Gruß
Dino

 

[dino03]

I2C Bus-Zustände

[FONT="Courier New"]
Data stable
SCL ------- Hi
SDA ======= Hi or Low

Data change
SCL -_____- Low
SDA ==x=x== Data change (Hi/Low)

Start Condition
SCL ------- Hi
SDA ----___ Hi to Low

Stop Condition
SCL ------- Hi
SDA ____--- Low to Hi

Transfer
SCL ---___---___---___---___---___---___---___---___---___---------
SDA -____-----______------------______------______------________---
     S |  7  |  6  |  5  |  4  |  3  |  2  |  1  |  0  |  A  |  P  
          1     0     1     1     0     1     0     1    =====> B5h
[/FONT]

Das muß ich jetzt irgendwie in Software gießen
Das kann doch nicht so schwer sein ...

Gruß
Dino

 

[dino03]

Hallo zusammen,

ich hab jetzt mal das Scope an den Analyzer gehängt um zu sehen was da
eigentlich abläuft. Hier mal ein paar Bildchen ...

zuerst einmal der gesamte Schaltplan ...

hauptsächlich geht es um einen kleinen Teil unten rechts ...

die Hardwarebeschleunigung für die Start/Stop-Erkennung.

Das Ding macht irgendwie Zicken.

Es hat sichh jetzt rausgestellt das wohl ein paar kleinere Böcke auf der Platine
sind. Schaltplan sieht ok aus aber auf der Platine scheint die eine oder andere
SDA/SCL-Vertauschung im I2C-Bus zu sein. Unter anderem bei den Lötstellen
der Hardwarebeschleunigung. Die erzeugt die 100ns Nadelimpulse niccht aus
der SDA-Leitung sondern aus der SCL-Leitung. MIST !

Also werde ich jetzt mal die Platine mit dem Schaltplan abgleichen.

EDIT: Ergebnis ...
Bei der Beschleunigerschaltung hab ich SDA und SCL vertauscht und am
INT1 liegt nicht SCL sondern SDA. Also kein Wunder das alles durcheinander
kommt. Werd ich die Tage wohl mal etwas zurechtlöten müssen



Gruß
Dino

 

[dino03]

Hallo,

jetzt hab ich die Leitungsvertauschungen beseitigt. Es ist jetzt besser aber
immer noch nicht gut. Ich bekomme zwar jetzt Kolonnen von 8Bit und es wird
auch ein Ack-Bit erkannt. Aber es gibt immer noch genug Bit-Kolonnen die
keine 8Bit lang sind und es gibt noch zu viele Start-Stop-Bits die eigentlich
keine sind.

Hier mal der aktuelle Quellcode für die Leute die ein wenig mitsuchen wollen
Anhang anzeigen TWI-1W-Analyzer_Bas_101106.bas

Gruß
Dino

 

[dino03]

Analyse der Schaltung für die Hardwarebeschleunigung

Hallo,

da ich nicht genau wußte was da nicht so richtig läuft und weil ich ja nun den Saleae LogicAnalyzer aus Dirk seinem Shop mein Eigen nennen kann hab ich ihn mal eingesetzt ...

Hier der gesamte Verkehr mal als Beispiel und im Detail ...


Das ist nun die Analyse der Signale an der Schaltung für die Hardwarebeschleunigung ...

Die Start- und Stop-Sequenzen auf dem I2C-Bus werden über eine Schaltung aus EXOR und NAND hardwaretechnisch erkannt. Damit wird die Software erheblich entlastet.

Wie gesagt wußte ich nicht genau ob die Hardware sauber ihren Dienst versieht oder nicht. Darum nun eine genauere Analyse die aber zufriedenstellen ausgefallen ist ...
...
..
.