ATtiny24: 2 externe counter & USI. Software Clock moegli

[rekado]

Heda!

Ich moechte einen ATtiny2313 (Master) und vier ATtiny24 (Slaves) seriell verbinden. Der Master wird ueber einen 20MHz Quarz getaktet, alle Slaves werden mit der Master-Clock gefuettert, die ueber CKOUT vom ATtiny2313 in den jeweiligen XTAL1 jedes ATtiny24 gelangt. Alle Controller laufen also mit der gleichen Clock synchron.

ATtiny2313 wie auch ATtiny24 besitzen USI (Universal Serial Interface). Um SPI zu realisieren wird jeweils ein Pin vom Master als Slave Select benutzt, der vor Lese-Schreib-Aktion vom Slave gelesen werden muss.

So. Das war die Vorgeschichte zur Verdrahtung.

Der ATtiny24 ist sehr klein, weshalb ein Pin oftmals mehrfach belegt ist. In diesem Fall kann PA4 sowohl als USCK/SCL (Clock fuer SPI) benutzt werden als auch als externer Counter Eingang fuer T1. Ich benoetige beide externe Counter, suche also nach einer Moeglichkeit die SPI Clock pinunabhaengig zu implementieren, per Software zum Beispiel.

Nach Datenblatt kann man die Shift Register Clock Source auf Software clock strobe (USICLK) stellen. Was ich nicht herausfinden konnte ist, ob dabei der Pinstatus veraendert wird oder ob dieser Software clock strobe rein intern ist und somit den USCK Pin unbeeinflusst laesst.

Habe frueher viel mit dem ATmega32 gearbeitet, der diesmal jedoch fuer so eine simple Zaehleraufgabe zu gross ist. Ich bevorzuge den ATtiny24 als Slave gegenueber dem AT2313, da er noch kleiner ist, aber dennoch ueber zwei externe Counter wie auch USI verfuegt.

Ich wuerde mich sehr freuen, wenn jemand eine Idee dazu haette, wie man beim ATtiny24 sowohl beide externen Counter benutzen kann als auch USI.

Danke!
Rekado

[rekado]

Die Frage nochmal in kuerzerer Form:

Variante 1:
Ist es moeglich Pulse am externen Counter Pin T1 zu zaehlen und das USI zu benutzen, obwohl T1 und USCK den gleichen Pin benutzen?

Variante 2:
Wird bei Benutzung des USI und interner Software-Clock die Spannung am Pin T1/USCK geaendert?

Hab das Datasheet schon durchgelesen und meine, dass es wohl moeglich sein koennte, das Datasheet ist da aber nicht ganz eindeutig.

Rekado

[linux_80]

Hallo,

ich hab USI bis jetzt nur für I2C verwendet, siehe Wiki: USI (https://www.roboternetz.de/wissen/index.php/USI_%28Avr%29), aber schau ma mal.

Die Taktleitung taktet ja immer wenn etwas über den Bus läuft, egal welcher Slave gemeint ist, wie wird hier der Takt vom Timer getrennt, evtl. mithilfe der SS-Leitung ?!
Wenn der Slave gemeint ist wird die Leitung, die für T1 gedacht ist, getrennt und der Takt für USCK verbunden :-k

Dieses Software-Clock ist nur zum takten des Schieberegisters, wenn der AVR Master ist, der Slave lässt den Takt, und somit das hereinschieben des Bytes, von aussen takten, diese Funktion kann man für sonst nix andres brauchen.

Wenn der Timer grad an diesem Pin lauscht (T1), zählt er diesen Takt gleich mit.

[rekado]

Hab mir nochmal mehrfach das Datenblatt des ATtiny24 angeschaut. Da gibt es ein gutes Diagramm zu Beginn der USI-Sektion auf Seite 122. Es sieht ganz danach aus als sei der USCK Pin allein Input fuer eine externe Clock. Wie aus dem Diagramm ersichtlich ist, kann man auch ueber das interne Register USICR Bit USICLK einen reinen Software-Takt erzeugen, der den 4-Bit Counter erhoeht und das Schieberegister weiterschiebt.

Das wird nochmal auf Seite 133 bestaetigt:

"Clearing the USICS1..0 bits enables software strobe option. When using this option, writing a one to the USICLK bit clocks both the Shift Register and the counter."

Es scheint also moeglich zu sein, eine Three-Wire-Verbindung mit nur zwei Wires zu realisieren. Es ist beim USI egal woher der Takt kommt. Damit das ganze funktioniert muessen die zwei internen Takte von Master wie auch Slave synchron laufen. Das koennte man hinbekommen indem man den Master mit Quarz laufen laesst und die Slaves ueber CLKOUT/CLKIN synchron mit dem Master laufen. Es muss nur eine Startbedinung zur Synchronisation erfuellt werden, damit Master wie Slave zur gleichen Zeit mit Schieben anfangen (braucht man also doch wieder insgesamt drei Signale).

Vorteil bei der Sache ist aber, dass man die USI Clock (USCK)hardwaremaessig von der Pulsquelle, deren Pulse an T1 gezaehlt werden sollen trennen kann und nicht mehr auf die Mehrfachbelegung dieses Pins angewiesen ist.

Mir jedenfalls hilft das - irgendwie. Denk ich.

[linux_80]

Den ersten Teil mit dem Softclock hab ich ja auch schon so wiedergegeben, da sind wir uns einig ;-)

Wenn ich es richtig verstehe, willst du eine Art asynchrone Übertragung herstellen, bei dem der Slave den eigenen Takt erzeugt, und nicht den externen vom Master, zum takten des Schieberegisters ?
Da man die Datenleitung sowieso selber per DDRx auf Ausgang oder Eingang stellen muss, könnte das schon hinhauen :-k

Das einzige Problem ist dann nur noch, das man nicht genau weiss, wann der Master das nächste Bit rüberschiebt, Du bräuchtest bei jedem Byte ein Startbit (und evtl. Stoppbit(s)), wie bei UART, um zu erkennen wann was kommt !

Jetzt musst Du nur noch sicherstellen, das die Clockleitung in diesen Fällen auch nicht mit dem USI verbunden ist, und da irgendwas durcheinanderbringt.
Wenn die per DDRx auf Eingang steht, man den Takt aber nicht als Taktquelle auswählt, stehen die Chancen meiner Meinung nach Gut, das es so gehen könnte.

Kapitel 16.4.1 (ein Satz) im Tiny24 DB bestätigt das eigentlich auch.

[rekado]

Na, das ist ja gut, dass bisher noch nichts so recht dagegen spricht!



Wenn ich es richtig verstehe, willst du eine Art asynchrone Übertragung herstellen, bei dem der Slave den eigenen Takt erzeugt, und nicht den externen vom Master, zum takten des Schieberegisters ?


Schon. Nur, dass es nicht so recht asynchron ist, da ja Master wie auch Slave exakt den gleichen Takt haben (eben ueber CLKO/CLKI; die Uebertragungsstrecke fuehrt ja nur zu einem festen berechenbaren minimalen Offset und nicht gleich zu einer Asynchronitaet wie es bei zwei Quarzen der Fall waere). Der Master muss also nur Bescheid geben, wann er gerne was vom Slave haben moechte - da es viele Slaves gibt, kann das ja ueber einen Slave Select Pin funktionieren.
Master wie auch Slave schieben dann einfach wie wild drauf los und komminizieren nicht mehr ueber Stoppbit sondern konzentrieren sich auf den eigenen 4-Bit-Counter Overflow Interrupt.



Jetzt musst Du nur noch sicherstellen, das die Clockleitung in diesen Fällen auch nicht mit dem USI verbunden ist, und da irgendwas durcheinanderbringt.


Das versteh ich nicht. Hatten wir nicht gerade ueber die Wegrationalisierung der USCK-Leitung gesprochen? Wird nicht verbunden, der Pin ist aber durch die externe Counterquelle belegt.

[rekado]

Zitat:

Jetzt musst Du nur noch sicherstellen, das die Clockleitung in diesen Fällen auch nicht mit dem USI verbunden ist, und da irgendwas durcheinanderbringt.



Das versteh ich nicht. Hatten wir nicht gerade ueber die Wegrationalisierung der USCK-Leitung gesprochen? Wird nicht verbunden, der Pin ist aber durch die externe Counterquelle belegt.


Oh, ich verstehe doch. Nevermind.

[linux_80]

Wenn Du nur darauf vertraust, das beide gleich schnell getaktet werden, kann es bei längeren Übertragungen schon zu einem (Bit-)Versatz kommen, denn die Verarbeitung zwischen den Bytes kann ja (bei Master und Slave) unterschiedlich sein ! Deswegen gibts bei UART Start- und Stoppbits, um den Empfänger vor jedem Byte zu synchronisieren.

Die Übertragung ist immer Asynchron wenn keine Taktleitung vorhanden ist, egal wie die µCs getaktet werden.
Die Fehlerrate ist natürlich am geringsten wenn beide gleich schnell takten.

Evtl. musst Du noch ein paar Experimente zum herausfinden der optimalen, max., Geschwidigkeit machen, auch um die Verzögerungen zwischen den Bytes anzugleichen.

[rekado]

denn die Verarbeitung zwischen den Bytes kann ja (bei Master und Slave) unterschiedlich sein


Stimmt, daran hab ich nicht gedacht. Dummerweise kann ich grad gar keine Experimente machen, weil ich Microcontroller, Oszilloskop, Steckbrett und so alles nicht nach China mitgenommen hab.

Ich plane jeweils nur 16 Bytes pro Zaehlsklaven an den Mastercontroller zu verschicken, eigentlich nicht viel. Wie koennte die Verarbeitung zwischen den Bytes unterschiedlich sein? Angenommen, es wuerden Befehle mit gleich langer Ausfuehrungszeit verwendet werden muessten doch beide Controller gleich schnell arbeiten, oder? Befehle haben ja immer eine feste Ausfuehrungszeit (so vier Cycles zum Beispiel oder so) in Abhaengigkeit von der Systemclock. Wenn die Clock identisch ist duerfte es da keinen Versatz geben, oder?

Angenommen den gibt es doch: dann koennte man natuerlich zur Synchronisation als Startbit-Ersatz einen Slave Select Interrupt ausloesen, so bei jedem Byte also eine Pin Change Interrupt Service Routine durch Pulsen der selbstdefinierten Slave Select Leitung aufrufen.

Danke fuer die Denkanstoesse! Hat mich tatsaechlich weitergebracht!

[linux_80]

Auch wenn sich das in der theorie gut anhört, würde ich das mit geeigneten Messinstrumenten nachprüfen, dass der Empfang nicht nur zufällig klappt, sondern doch so wie gewollt ;-)