AT90S2313 als I2C-Slave (Software-Implementierung)

[talentraspel_kai]

Hallo zusammen,

ich habe mal das Thema I2C für AVR-Mikrocontroller ohne die entsprechende Hardwareunterstützung umgesetzt. Ausgehend von den originalen Atmel-Applikationvorschlägen gibt es das jetzt als Assemblerprogramm und auch in C mit WinAVR unter http://www.talentraspel.de/portal/index.php?id=226.

Da diese Form der Umsetzung jedoch wenig Parallelität zulässt, habe ich das Ganze noch in veränderter Form als I2C-Servosteuerung (http://www.talentraspel.de/portal/index.php?id=227) und als I2C-PWM (http://www.talentraspel.de/portal/index.php?id=228) implementiert. Die Lösung arbeitet jitterfrei und lässt sich auch vom Ausfall der Kommunikation nicht stören.

Um die Ansteuerung vom PC aus auch ohne eigenes I2C-Interface zu ermöglichen, habe ich die Kommunikation über die ISP-Schnittstelle (http://www.talentraspel.de/portal/index.php?id=197) um eine I2C-ISP-Bridge (http://www.talentraspel.de/portal/index.php?id=229) erweitert.

Viel Spass beim ausprobieren, ich freue mich auf eure Kommentare.


Grüße,
Kai.

[PicNick]

Hi, ich hab' mich mit der Thematik I2C slave ohne HW-Unterstützung auch schon auseinandergesetzt. Man kann es halt drehen und wenden, fremdgetaktete Datenübertragung ist mit Software ein Jammer.
Zwischen den Takten sind immer nur ein paar zerquetsche Cycles möglich, ohne Abstimmung des gesamten Programms darauf wird es knapp. Gottseidank bietet I2C die Möglichkeit, auch als Slave auf die Bremse zu treten, aber es ist halt einen Notlösung.

[talentraspel_kai]

Ein Jammer - so ist es. Es war auch nicht einfach, das auszutüfteln. Aber nun läuft es schnell und störungsfrei ... und zwar in diesem Falle sogar ohne Waitstates vom Slave.

Aber es stimmt, in der eigentlichen Kommunikationsroutine wird auch tatsächlich nur das jeweils übertragene Byte einfach abgelegt. Den Rest macht die Hauptroutine. Und durch die Begrenzung von SCL auf 50 kHz darf sogar der Interrupt für die Servosteuerung oder die PWM mal der Kommunikation dazwischenkommen.

Grüße,
Kai.

[PicNick]

Ihr habt jedenfalls meinen vollen Respekt. Die Aufgabenstellung ist auf jeden Fall geeignet, als Aufnahmsprüfung für Höhere Bit-Quetscher zu dienen.
Keep codin' !

[stupsi]

Sehr interessant hier. Ich mag funktionale Bausteine, die den Prozessor entlasten.
Wieviel code wird denn für den slave benötigt? In Kai's Link hab ich die Datei i2c_slave.hex mit 1,17k Größe gesehen.
Leider durchschaue ich das C-Programm nicht. Daher kann ich nicht sehen, welche I2C-Befehle man dort ausführen kann.

Ist es möglich, auf einen 8-pin-Typen, z.B. den ATTiny 13 mit 1k Flash eine I2C-Steuerung eines Motors realisierbar? Oder muß man da zu PIC-Bausteinen wechseln oder ist beides unmöglich?


Gruß Stupsi

[talentraspel_kai]

Sogar auf einem ATTiny13 kann man eine softwarebasierte I2C-PWM-Motorsteuerung realisieren. Der Code ist deutlich unter 1KByte, er kann also auch in einen ATTiny13 rein. Allerdings macht das so direkt keinen Sinn. Statt die PWM über den Timer-1 laufen zu lassen, muss man die Hardware-PWM verwenden. Das reicht aber in jedem Fall, da man aufgrund der geringen Pinzahl eh nur einem Motor vernünftig rechts/links mit PWM anschliessen kann.

Einfache Rechnung:
- ATTiny13 mit internem Takt => 6 I/O-Leitungen
- 2 fallen weg für I2C => 4 I/O Leitungen zur Motorsteuerung
- 3 brauche ich pro Motor wenn ich z. B. einen L298 direkt anschliesse (rechts, links und enable), damit ich Rechtslauf, Linkslauf, Stop und Leerlauf unterscheiden kann. Das kann ich nur über einen zusätzlichen Inverter auf zwei Leitungen reduzieren. Also passt in der einfachen Variante nur ein Motor dran.

Man kann zwar das Problem mit dem ATTiny13 auch lösen. Aber warum so kompliziert und warum immer wieder ein neues Design? Wenn es schon ein Tiny sein soll, dann einfach der zum AT90S2313 kompatible ATTiny2313. Quarz dran, Software rein und fertig. Mit einem 20MHz Quarz kommt man dann sogar auf 100KHz SCL.

Wenn mir jemand einen vernünftigen Grund liefert, warum eine solche Lösung unbedingt mit einem ATTiny13 gemacht werden soll, baue ich das eventuell mal um.


Die I2C-Ansteuerung des voeliegenden PWM-Moduls kann am besten nachvollzogen werden, wenn man sich das zugehörige Testprogramm anschaut. Ausserdem sieht man im Slave-Programm in der Hauptkommunikationsschleife einen Programmteil, der die empfangenen Kommandos auswertet und die Parameter für die interne PWM-Routine neu stetzt.

Es gibt Kommandos zum Setzen des PWM-Anteils für die einzelnen Motoren, Kommandos für rechts/links/stop pro Motor und ein generelles RESET-Kommando zum Rückstellen des Moduls.


Grüße,
Kai.

[PicNick]

@Kai: Ich find's nicht gut, zu viele Varianten zu produzieren, ohne speziellen Grund. Es ist eine Schweinerei, das alles im Lauf der Zeit up-to-date zu halten und/oder Support zu liefern.
Bleib' bei dem 2313, so wie's ist.

[stupsi]

Danke Kai für deine Einschätzung, das lässt hoffen...

@Picknick: Meine Frage sollte Kai nicht motivieren, sein Konzept zu ändern, mir ging es nur um die theoretische Machbarkeit mit einem kleineren Mikrocontroller. Ich habe größte Schwierigkeiten, mich in die Mikrocontroller-Programmierung einzuarbeiten, daher verwende ich auch Kai's Skript vom Modularen Experimentiersystem, um mir ein Grundverständnis zu verschaffen. Das zugehörige Experimentiersystem mit dem 2313 find ich sehr praxisnah und universell und hab es auf Lochraster nachgebaut.

Aber jetzt der Hintergrund zu meiner Frage:
Das I2C-PWM-System ist für einen L293D auf jeden Fall gut geeignet; Aber schon beim L298 findet er auch seine Grenzen wegen der Strom-Meßausgänge. Es fehlen die A/D- Eingänge beim 2313; leider auch beim ATTiny2313. Hier wäre der ATTiny26 richtig?

Ich bastel gerade an einem Motortreiber höherer Leistung. Dort ist eine Stromüberwachung intern zwingend notwendig und über I2C wünschenswert.
Bei der Suche nach einer Lösung hab ich den ATTiny13 als geeignet gefunden. Hier der Entwurf:

LINK: ATTINY13-I2C-PWM-Konzept (http://home.arcor.de/stupsi74/infos/ATTiny13%20Motorcontroller.pdf)

Ist der I2C-Entwurf praxisnah oder "oversized"?

und hier integriert in die Gesamt-Schaltung: LINK: Motortreiber mit ATTINY13 (http://home.arcor.de/stupsi74/infos/bts555-tiny13.gif)
(Das Prinzip des Leistungstreibers ist auch für kleine Leistungen (ab 2A) sehr preiswert machbar.)

Wenn man 2 Motore betreiben will, nimmt man einfach 2 Controller mit verschiedenen I2C-Adressen. (oder besser den ATTiny26 für 2 Motore???)

Naja, noch ist alles im Entwurfstadium. Zum Lernen beschäftige ich mich weiter mit dem AT90S2313.

Gruß Stupsi

[Briegel]

Endlich! Ich habe so lange nach einer Assembler-Umsetzung für einen Software-TWI Slave gesucht. Vielen Dank an talentraspel_kai!

Nun aber das Problem:

Ich habe den (ASM-) Code zum Testen mal so modifiziert, dass er das empfangene Byte nicht auf PortB gibt, sondern es um eins erhöht und dann auf Abfrage zurückschickt.
Benutzter AVR bei mir ist Tiny2313. Pins und Interruptvektoren sind kompatibel zum AT90S2313.
Leider funktionierte aber irgendwie garnichts. Nach längerem Suchen habe ich herausgefunden, dass der Slave die eigene Adresse nicht erkennt und somit kein ACK sendet.
Ich habe zunächst an einen Denkfehler meinerseits gedacht und den Master mal alle Adressen durchprobieren lassen, aber der Slave hat auf keine(!) reagiert. Am Code des Masters dürfte es aber nicht liegen. (TWI funktioniert einwandfrei z.B. mit Ultraschallsensor SRF08)
Also einfach mal im Slave die Adressabfrage so umgestrickt, dass er sich immer angesprochen fühlt. Und plötzlich funktionierte es.

Das ist zwar soweit ganz schön, mein Problem ist jetzt nur, dass ich nicht wirklich weiß, wie ich die Adresserkennung wieder so hinkriege, dass er nur auf seine eigene Adresse reagiert. Ist irgendwie unhöflich, sich im Bus ungefragt in die Gespräche anderer Leute einzumischen :- (

Hat schon jemand dasselbe Problem gehabt und nun zufällig eine Lösung parat?

Vielen Dank
Briegel