Soft I²C zum Beispiel auf ATtiny13

Hi

>Der ATtiny13 hat weder ein TWI noch ein USI Interface,
>deswegen kann man das Protokoll nur "zu Fuß" per Bit-Banging
>implementieren. Der Quelltext ist trivial und daher sicher leicht auf
>andere Mikrocontroller portierbar.

Gibt es als AppNote von ATMEL seit 1997.

MfG Spess

Stefanus,

Als Verständnis-Basis ganz brauchbar und auch hinreichend dokumentiert.
Zu einer kompletten Lösung fehlt aber noch einiges,

- Slaveseitiges Clockstretching handelst Du m.E. nicht/nicht optimal.
- Und komplett fehlt ein Exeption/ErrorHandling:
  Wenn hier der Slave abkackt, hängt auch der Master forever!

Prof. Lösungen machen masterseitig ein Timeout und versuchen zumindest, 
den Bus wieder freizutakten, teils mehrmals nach zugebilligter 
Erholungsphase. Falls das fehlschlägt gibt es zumindest ein 
ErrorHandling und der Master "überlebt".
Ich nehme aber an, dass Stefanus den Code eher als "Basis" verstanden 
haben will.

Persönlich setze ich solche BIOS-Dinge grundsätzlich in Assembler um, 
das steigert Performance/schrumpft Code um Faktoren! Von solchen 
elementaren BIOS-Aufgaben sollten Hochsprachen besser die Finger lassen.

@SPESS:
> Gibt es als AppNote von ATMEL seit 1997.
Ja, stimmt.
Die dortige Umsetzung ist aber nur akademisch/rudimentär, hat mit realer 
Anforderung fast-nix zu tun und taugt nicht für die Praxis.

Interessant wäre mal eine TAUGLICHE SLAVE-LÖSUNG für TINYs ohne USI, das 
ist nämlich ungleich herausfordender, wenn man einigermassen 
praxistauglich sein möchte.
In eben-dieser-Praxis sind TINYs auch eher als SLAVE zu vermuten, als 
als Master.

Hi

>Ja, stimmt.
>Die dortige Umsetzung ist aber nur akademisch/rudimentär, hat mit realer
>Anforderung fast-nix zu tun und taugt nicht für die Praxis.

Blödsinn. Ist in Geräten unserer Firma schon mehrere 1000 mal verkauft 
wurden. Und das nennst du 'taugt nicht für die Praxis.'
Dann solltest du an mal deiner Praxis feilen.

Jim Beam ist ubrigens ein grauenhaftes Gesöff. Amis können keins Whiskey 
machen.

MfG Spess

@SPESS:

1000x unprofessionell bleibt unprofessionell, wird durch Multiplikation 
nicht besser...
Mehr von dem Unsinn, den Du schriebst kommentiere ich nicht.

Aber wie Du selbst durchblicken lässt:
> Amis können keins Whiskey machen.

DEIN Problem scheint wirklich der Alkohol zu sein... ;-)

Jim Beam schrieb:
> Ich nehme aber an, dass Stefanus den Code eher als "Basis" verstanden
> haben will.

Genau. Beim Errorhandling käme ja auch gleich die Frage auf, was denn im 
Fehlerfall passieren soll. Eine generische Lösung, die dann auch noch 
mit den minimalen Ressourcen des ATtiny13 angemessen sparsam umgeht, 
kann ich mir nicht vorstellen.

An das Clock-Stretching habe ich gar nicht gedacht. Danke für den 
Hinweis.

> Interessant wäre mal eine TAUGLICHE SLAVE-LÖSUNG für TINYs ohne USI,
> das ist nämlich ungleich herausfordender

Allerdings. Darauf habe ich ehrlich gesagt keine Lust. Es ist ja nicht 
so, dass man unbedingt auf Teufel komm raus den kleinsten µC ohne die 
dafür vorgesehene Hardware verwenden muss.

> In eben-dieser-Praxis sind TINYs auch eher als SLAVE zu vermuten,
> als als Master.

Jawohl, aber dann bitte wenigstens einen mit USI.

Apollo M. schrieb:
> ... byte = (byte << 1) & 0xFF;

Den Teil "& 0xFF" kürzt der Compiler raus, der steht da nur, um Lint 
zufrieden zu stellen. Übrig bleibt eine Simple LSL Operation. Erzähle 
mir nicht, dass die unperformant sei.

Bist du ganz sicher, dass "(0x80>>bit)" schneller ist?

Ich finde deinen Ansatz auch nicht so gut. die Bits von 0 bis 7 zu 
zählen, aber tatsächlich die Bits 7 bis 0 zu senden. Das stiftet 
Verwirrung.

Außerdem Hand auf Herz: Kommt es bei I²C auf einzelne CPU Takte an?

Stefanus F. schrieb:
> Übrig bleibt eine Simple LSL Operation

Ich habe jetzt mal ins Assembler Listing geschaut. Interessanterweise 
hater Compiler daraus "add r24, r24" gemacht. Aber egal, ist auch nur 
eine kurze Operation mit dem gleichen Ergebnis.

Anbei die korrigierte Datei mit Clock-Stretching.

Hi

>Interessanterweise
>hater Compiler daraus "add r24, r24" gemacht. Aber egal, ist auch nur
>eine kurze Operation mit dem gleichen Ergebnis.

lsl r24 und add r24,r24 haben den gleichen Assemblercode. Also ist 
beides richtig.

MfG Spess

Apollo M. schrieb:
> diese benutzt den avr toggle befehl, welcher dann auch für die clock
> benutzt werden sollte!

MOMENT MAL....

Du setzt doch NICHT ETWA bei H das Portbit auf AUSGANG-H??
Das enspricht absolut NICHT der I2C-Spec.!

Korrekt ist:
H = Port-ist-EINGANG mit Pullup
L = Port-ist-AUSGANG mit elektrisch L

Ansonsten kann es elektrische Kurzschlüsse auf dem Bus geben,
und es widerspricht komplett der I2C-Spezifikation.
Das wird ständig und gerne falsch gemacht.

Apollo M. schrieb:
> die beste variante ist die nr.2

Warum? Schneller ist hier vollkommen sinnlos, da die gesparte Zeit in 
einer längeren Warteschleife vernichtet werden muss.

Ich lege in erster Linie Wert auf gut lesbaren Code, da ich in einem 
Team arbeite und oft Sachen korrigieren muss, den Kollegen vorher 
entwickelt haben. Oft ist das so alter Code, dass sich niemand mehr 
daran erinnern kann und daher auch nicht erklären kann.

Performance-Optimierung steht in der Rangliste ganz unten, noch unter 
Keller-Aufräumen.

> daher sollte dann das dddrx reg
> zum toggling benutzt werden!

Stimmt, eigentlich kann ich mir die Schreibzugriffe auf das PORTB 
Register sparen.

Stefanus F. schrieb:

> Warum? Schneller ist hier vollkommen sinnlos, da die gesparte Zeit in
> einer längeren Warteschleife vernichtet werden muss.

Das scheint nur so. Tatsächlich kann man gesparte Takte in in der 
Bitschieberei und Ausgabe dafür nutzen, das nächste Byte zu holen (als 
Transmitter) bzw. das vorige zu verarbeiten (als Receiver). Das 
verbessert insgesamt zumindest den Durchsatz oder erlaubt es überhaupt 
erst, bestimmte Timing Constraints einzuhalten.

Das gilt nicht nur für I2C, sondern ganz generell für alle Sachen die 
irgendwelche Bitserialierungen machen. Bekanntes Beispiel für sowas ist 
z.B. V-USB. Das würde ohne solche Techniken überhaupt nicht 
funktionieren können.

Der Trick ist dabei eben gerade, die "überflüssige" Zeit nicht in 
nutzlosen Warteoperationen zu vernichten, sondern sie sinnvoll zu 
nutzen.

> Ich lege in erster Linie Wert auf gut lesbaren Code

Wenn ich die Wahl habe zwischen schlecht lesbarem Code und gut lesbaren, 
aber komplett unbrauchbarem Code, dann fällt mir diese Wahl nicht 
schwer...

Aber OK, für einen I2C-Master spielt das alles wirklich nur eine 
untergeordnete Rolle. Wenn er richtig implementiert ist, wird auch 
langsamer Code immer funktionieren. Nur der erreichbare Durchsatz ist 
halt nicht so hoch, wie er sein könnte. Wenn er trotzdem genügt: ja dann 
würde ich natürlich auch den gut lesbaren Code bevorzugen. Schon 
deshalb, weil er auch viel einfacher zu schreiben ist...

Marcus H. schrieb:
> Für morgen Vormittag habe mir eine Portierung inkl. Sensoransteuerung
> für einen Soft-I2C in Maschinensprache auf einen ATtiny814 vorgenommen.

Warum? Der hat doch ein richtiges TWI Interface sogar mit Filter für 
"noise and spike suppression" und konfigurierbaren Timeouts.

Mein obiger Code kann doch nur eine Notlösung mit provisorischem 
Charakter sein.

c-hater schrieb:
> Wenn er trotzdem genügt: ja dann
> würde ich natürlich auch den gut lesbaren Code bevorzugen.

Na dann sind wir uns ja einig.

Marcus H. schrieb:
> Die Anfänger die sich auf Deinen Post verlassen wären sicher froh
> gewesen, Du hättest diese Einschätzung Deines Beispiels auch eingangs
> schon so geschrieben.

Ja stimmt, darauf hätte ich hinweisen sollen.
Aber auf einem µC mit nur 32 Bytes RAM (+32 Register) kann man halt 
ohnehin keine Weltbewegenden Sachen machen. Ich habe den nur verwendet, 
weil ich meine Vorräte aufbrauchen will.

Stefanus F. schrieb:
> aber jetzt habe ich eins, weil ich es gerade für eine
> Bastelei selber brauchte

Ist ja soweit OK, nur ein paar Bemerkungen meinerseits:
- i2c_start sollte bool sein und die while Zeile in i2c_start sollte 
durch eine kleine Verzögerung und dann ggf. return false ergeben.
- in i2c_stop sollte die while Zeile ganz raus. Es ist ja bereits alles 
erledigt.
- das unbegrenzte while in i2c_send ist auch nicht nett.
- das i2c_communicate mißfällt mir. Es ist mir zu überladen. Ich mache 
es lieber getrennt, das ist mMn handlicher:

void I2C_Init (void);
bool Do_I2C_Start (byte Adresse, bool obRead); // 7 bit
bool Do_I2C_Write (byte aByte);
byte Do_I2C_Read  (bool Acknowledge);
void Do_I2C_Stop  (void);

W.S.

Hi

>Auf einem Tiny13 macht Assembler nicht nur Spaß, sondern auch Sinn. Ist
>halt noch ein niedlich kleiner Mikrocontroller. Und so ein Bitbongo (tm)
>ist in Assembler auch nicht schlechter zu lesen als in C.

Gibt es doch schon: AVR300: Software I2C™ Master Interface

MfG Spess

Apollo M. schrieb:
> hier mal zwei varianten für die "high performer" ...
>
> void i2c_send(uint8_t data) { //send data bits and starts with msb
>     for (uint8_t bit = 0; bit!=8; bit++) {
>         if (data & (0x80>>bit)) SDA_HIGH;
>         else SDA_LOW;
>
>         I2C_DELAY;
>         SCL_HIGH;
>         I2C_DELAY;
>         SCL_LOW;
>     }
> }
>
> oder so ...

Das ist für dich high performer. aha.

Ähem.. guck mal:

1

byte I2C_dio (byte b)

2

{ byte c, e;

3

  c = 0x80;

4

  e = 0;

5

  while (c)

6

  { if (b & c) SDA_high(); else SDA_low();

7

    sdelay(sdavorscl);

8

    SCL_high();

9

    sdelay(sclhigh);

10

    c = c>>1;

11

    e = e<<1;

12

    if (SDA_State()) e |= 1;

13

    SCL_low();

14

    sdelay(sdahalte);

15

  }

16

  return e;

17

}

Das kann man sowohl für Read als auch für Write benutzen. Bei Read eben 
$FF senden. Allerdings schert es sich nicht um Verzögerungen vom Slave.

W.S.

Stefanus F. schrieb:

> Aber auf einem µC mit nur 32 Bytes RAM (+32 Register) kann man halt
> ohnehin keine Weltbewegenden Sachen machen. Ich habe den nur verwendet,
> weil ich meine Vorräte aufbrauchen will.

Der Tiny13 hat allerdings 64Byte RAM (+32 Register)...

Ich gebe dir allerdings trotzdem insofern Recht, dass der Tiny13 ein 
wirklich ziemlich eingeschränkter Vertreter der AVR8-Familie ist. Ich 
bin zu meinem einzigen Exemplar vor ca. 10 Jahren gekommen, als er die 
paar Cent beigetragen hat, die ich noch brauchte, um bei einer 
Pollin-Bestellung einen Gutschein einlösen zu können.

In all den Jahren war er bei etlichen Projekten immer mal wieder in der 
Vorauswahl, ist dann aber immer wegen irgendwelcher störenden 
Beschränkungen rausgeflogen. So kommt es, dass ich dieses eine Exemplar 
dieser Supergurke immer noch rumliegen habe. Inzwischen bin ich auch 
nicht mehr sicher, dass ich überhaupt jemals eine passende Anwendung für 
das Teil finde. Für Anwendungen der in Frage kommenden Klassen ist immer 
der Tiny25 die bessere Wahl und der kostet ja praktisch dasselbe.

Der Tiny13 hat aber ein besonderes Feature, was bisher nicht erwähnt 
wurde:
Nämlich der RC-Clock mit 9.6Mhz anstelle 8Mhz der anderen 8-Pinner.

Kann manchmal nützlich sein.

Jim Beam schrieb:

> Der Tiny13 hat aber ein besonderes Feature, was bisher nicht erwähnt
> wurde:
> Nämlich der RC-Clock mit 9.6Mhz anstelle 8Mhz der anderen 8-Pinner.

Die anderen kannst du per OSCCAL auch völlig problemlos auf 9.6 
zwirbeln. Ist dann zwar, streng genommen, ausserhalb der jeweiligen 
Specs, aber mir ist noch kein Fall untergekommen, wo diese moderate 
"Übertaktung" (sowieso nur relevant für den Schreibzugriff auf Flash und 
EEPROM) irgendwie zu Problemen geführt hätte. Garantiert ist es aber 
herstellerseitig eben nicht. Das kann schon wichtig sein. Für 
Bastelprojekte allerdings nicht und auch nicht für kommerzielle 
Anwendungen, wo eben nicht in Flash oder EEPROM geschrieben wird.

c-hater schrieb:
> Die anderen kannst du per OSCCAL auch völlig problemlos auf 9.6
> zwirbeln.

Interessant, käme mir sehr gelegen wenn das klappt.
Werde das auf jeden Fall mal pröben.

Habe mal irgendwann bei Atmel gelesen, dass man OSCCAL nur in kleinen 
Schritten ändern sollte, von 8->9.6 wäre dann aber schon ein Klopper 
nehme ich an. Sollte ich da am Progstart eine Schleife einbauen, oder 
wie hast Du das gemacht?

> - weil meine Anwendungen nicht nur mal eben kurz auf dem Schreibtisch
> laufen sollen, sondern ohne Wartungsmöglichkeit für lange Zeit im Feld
> unterwegs sind

In dem Falle ist I2C grundsaetzlich nicht verwendbar. Es gibt naemlich 
durchaus ICs die sich so weghaengen das sie die Clockleitung auf Masse 
ziehen. Deshalb gibt es modernere I2C-ICs die einen Mindesttakt 
verlangen und sich resetten.

Olaf

Jim Beam schrieb:
> Sollte ich da am Progstart eine Schleife einbauen, oder
> wie hast Du das gemacht?

Ganz einfach:
OSCCAL = 0xff;

Dann läuft das Teil mit ca. 14 - 15 MHz. Ein 20 MHz AVR wird damit auch 
nicht übertaktet.
Fertig.

Als erstes sollte man klären, ob diese ganzen Maßnahmen überhaupt 
angemessen sind.

In meinem konkreten Fall geht es um ein Kinderspielzeug (ein 
Eltern-Detektor vor der Zimmertüre). Der darf ruhig mal hängen bleiben.

Alfred K. schrieb:

> Ganz einfach:
> OSCCAL = 0xff;

Wie Jim Beam schon festgestellt hat, empfiehlt Atmel, bei Änderungen von 
OSCCAL keine großen Sprünge zu machen. Sie sollten <= 2% bleiben. Also 
besser in einer Schleife vom Initialwert zum gewünschten Wert laufen 
lassen.

> Dann läuft das Teil mit ca. 14 - 15 MHz. Ein 20 MHz AVR wird damit auch
> nicht übertaktet.

Darum geht es auch garnicht. Worum es geht, sind Schreibvorgänge in 
Flash oder EEPROM. Das dafür nötige Timing wird bei den allermeisten 
AVR8 aus dem  RC-Oszillator abgeleitet, auch die Programmierspannung 
wird mit Ladungspumpen erzeugt, die durch diesen Oszillator getaktet 
werden.

DA sind also ggf. Probleme zu erwarten, nicht beim Betrieb der MCU. Die 
MCU macht erst Probleme, wenn der Takt für die Betriebsspannung zu hoch 
wird, bei 5V und RC-Oszillator als Taktquelle also nie, auch nicht wenn 
man OSCCAL auf Maximum setzt. Bei kleineren Betriebsspannungen sieht das 
naturgemäß anders aus, dann muss man natürlich auch diese Abhängigkeit 
bei Spielereien an OSCCAL berücksichtigen.

Das steht übrigens alles in den Datenblättern, man muss die einfach nur 
mal lesen...

c-hater schrieb:
> Worum es geht, sind Schreibvorgänge in
> Flash oder EEPROM. Das dafür nötige Timing wird bei den allermeisten
> AVR8 aus dem  RC-Oszillator abgeleitet

Damit hast Du Recht und das muß berücksichtigt werden, wenn man 
schreibende EEPROM-Zugriffe braucht. Da das Timing eh sehr ungenau sein 
wird, kann man bei Bedarf OSCCAL auch vor und nach den Zugriffen 
umstellen.

c-hater schrieb:
> Das steht übrigens alles in den Datenblättern, man muss die einfach nur
> mal lesen...

Da steht aber auch, dass man während der Änderungen den Prozessor im 
Reset halten soll. Dazu hätte ich gerne ein Programmbeispiel.
Geht man zu den ATmega, dann gibt es keine Einschränkungen, die nur 2% 
Änderungen empfehlen. In der Praxis funktioniert auch direktes 
Beschreiben mit 0xFF problemlos.
Das zu den AVR Datenblättern.

Ich sehe jedenfalls keinen Grund, einen ATtiny13 nur wegen seiner 9,6 
MHz einem ATtiny25/45/85 zu bevorzugen.

Marcus H. schrieb:
>> In meinem konkreten Fall geht es um ein Kinderspielzeug (ein
>> Eltern-Detektor vor der Zimmertüre). Der darf ruhig mal hängen bleiben.
> Mmmh? Ich hatte Dich älter eingeschätzt. :D

Ich bin der, der nicht rein darf.

Alfred K. schrieb:

> Da das Timing eh sehr ungenau sein
> wird, kann man bei Bedarf OSCCAL auch vor und nach den Zugriffen
> umstellen.

Jepp.

> Da steht aber auch, dass man während der Änderungen den Prozessor im
> Reset halten soll.

Das bezieht sich auf einen extern eingespeisten Takt und genau den 
"verbotenen" Fall. Sprich: wenn man das macht, muss man das per externer 
Hardware lösen, eine Lösung per Programm ist dann natürlich nicht 
möglich.

Bezüglich des RC-Oszillators hilft eine Tatsache, die nicht dokumentiert 
ist, sich aber sehr leicht nachweisen läßt. Nämlich der Fakt, dass die 
Änderung von dessen Takt per OSCCAL einer Zeitkonstante unterliegt. Der 
erzeugte Takt folgt also nicht sprunghaft dem Wert in OSCCAL. Deswegen 
bleibt in den meisten Fällen auch eine größere Änderung von OSCCAL 
folgenlos. Wenn man sich die Sprungantwort anschaut, sieht man aber, 
dass bei wirklich extremen Änderungen die 2%-Latte sehr deutlich 
gerissen wird. Wenn man also clever ist, vermeidet man diese potentiell 
gefährliche Situation, zumal die "Kosten" dafür ja nun wirklich sehr 
überschaubar sind.

> Ich sehe jedenfalls keinen Grund, einen ATtiny13 nur wegen seiner 9,6
> MHz einem ATtiny25/45/85 zu bevorzugen.

Sag' ich ja. Die potentiellen Probleme lassen sich halt mit sehr wenig 
Aufwand zuverlässig umgehen, wenn sie denn in einer konkreten Anwendung 
überhaupt relevant sind.