Gibt es einen schnelleren aber baugleichen AVR zum Atiny2313

[Ralph H. (guru)]

Gibt es einen schnelleren aber baugleichen AVR zum Atiny2313?

Ich brauch idealerweise einen Pinkompatiblen Ersatz der mit dem internen 
Osszilator mehr als 8Mhz schafft.

Gibt es so etwas?

Danke sagt Ralph

[Logik (Gast)]

Ralph H. schrieb:
> Pinkompatiblen Ersatz der mit dem internen
> Osszilator mehr als 8Mhz schafft

Nein. Nutze eine externe Taktquelle oder einen Quarz.

[Mareike v. Stolz (Gast)]

Habe nie einen Atmega mit mehr als 8MHz internem Takt gesehen.
Evtl. Xmegas mal durchgucken.

[Thorsten S. (thosch)]

Nein, nicht pinkompatibel.

[Peter D. (peda)]

Oftmals kann man durch Strukturierung der Software mehr Geschwindigkeit 
rausholen.

Nicht pinkompatibel mit intern 16MHz: ATtiny861.

[Karl M. (Gast)]

Guten Morgen,

aus der Attiny2313 Reihe haben sich die Attiny2313p und Attiny4313 
weiter entwickelt.

Wie oben schon geschrieben über ein Pin einen ext. Oszillator 
einspeisen, das Programm neu strukturieren, oder über einen Adapter 
einen anderen AVR µC anflanschen.

[Horst (Gast)]

Mareike v. Stolz schrieb:
> Habe nie einen Atmega mit mehr als 8MHz internem Takt gesehen.

Tinys sind auch keine Megas. Der Tiny13 hatte z.B. 4,8 oder 9,6Mhz 
undlies sich noch höher anpassen.

[Rita (Gast)]

Wofür brauchst du denn mehr? Kann man das evtl. mit besserer Software 
lösen?

[mal was sinnvolles (Gast)]

Einfach die Ampere hochskillen!

[Ralph H. (guru)]

Danke Euch allen. Ich hatte das schon so geahnt, denn ich hatte auch 
schon selbst geschaut. Da werd ich mein Projekt wohl überdenken müssen.

Das Problem ist, das ich die zeitkritische Routine schon optimiert habe 
und da kein/kaum Spielraum ist.

[Noch nicht Rentner (Gast)]

> Das Problem ist, das ich die zeitkritische Routine schon optimiert habe
und da kein/kaum Spielraum ist.

So.So. Tatsaechlich ? Zeig mal.

[Ralph H. (guru)]

Noch nicht Rentner schrieb:
>> Das Problem ist, das ich die zeitkritische Routine schon optimiert habe
> und da kein/kaum Spielraum ist.
>
> So.So. Tatsaechlich ? Zeig mal.

Nun denn... hier ist der zeitkritische Teil.

;
; Jeder Pegelwechsel an den PORTB Bit0..3 bewirkt einen Interrupt der 
hier
; abgearbeitet wird. Dabei können die Bits mit 4Mhz toggeln, weil der
; abgefragte PIO-Port so oft abgefragt wird

Ausgabe:
 cli
 in  SREG1,SREG    ; SREG Register sichern
 in  mtemp2,PINB    ; Spaltenwert vom Z1013 einlesen
 andi  mtemp2,0x0F    ; nur Bits 0..3 zulassen
; Interrupt durch Spalte 7 ? (Shift und Control Spalte)
 cpi  mtemp2,0x07    ; Shift Control Spalte
 brne  noSpalte7    ; nicht Spalte 7
; wenn hier dann Statusspalte 7 für Shift  oder Control ausgeben
 ldi    mtemp1,noCode
 ldi  mtemp1,BZ7    ; CTRL
 sbrc  TastStatus, CTRL  ; auf CTRL gedrückt testen
 rjmp  MatrixAusgabe    ; ja
 mov  mtemp1,SCcode    ; SteuerCode holen
 andi  mtemp1,0xF0    ; nur (Bit7..4) zulassen
 rjmp  MatrixAusgabe    ; und ausgeben
;
noSpalte7:
 mov  mtemp1,code    ; Code holen
 cpi  mtemp1,kein_Zeichen  ; keine Taste gedrückt -> Ende
 breq  MatrixLeer    ; Spalten deaktivieren
 mov  mtemp1,code    ; Code holen
 andi  mtemp1,0x0F    ; nur Bit0..3 zulassen (Spaltencode)
 cpi  mtemp2,0x0F    ; Spaltenzähler Statuspalte 15?
 breq  Spalte15    ; ja
 cp  mtemp1,mtemp2    ; Spaltenwert gedrückter Taste = Spalte ?
 brne  MatrixLeer    ; nein, dann kein_Zeichen ausgeben
Spalte15:
 mov  mtemp1,Code    ; Code laden
 andi  mtemp1,0xF0    ; nur ZeilenCode (Bit7..4) zulassen
MatrixAusgabe:
 lsr  mtemp1    ; 1x rechtsschieben wegen Bits in PortD 3..6
 out  PortD,mtemp1    ; SpaltenCode nun ausgeben
MatrixEnde:
 out  SREG,SREG1    ; Statusregister zurück
 reti        ; hier Ausgang Ausgabe
;
MatrixLeer:
 ldi  mtemp1,kein_Zeichen   ; keine Spalte aktiv, ggf.aktive Spalte 
löschen
 rjmp  MatrixAusgabe    ; ausgeben

;***            Ende Interruptroutine  ***            Ausgabe

[Wegstaben V. (wegstabenverbuchsler)]

also eine Tastaturmatrix abfragen, stimmts?

[Peter D. (peda)]

Wegstaben V. schrieb:
> also eine Tastaturmatrix abfragen, stimmts?

http://www.z1013.de/

Dafür kann man auch bequem einen ATmega328 mit 20MHz Quarz nehmen.

[Noch nicht Rentner (Gast)]

Das soll die Interruptroutine sein ? Was soll das cli am Anfang ? Das 
braucht's nicht. Interrups sind im interrupt sowieso disabled.

Ohne jetzt die Funktionalitaet zu kennen .. Tastenauswertungen macht man 
nicht in einem Interrupt weil's nie so pressiert. Displayausgaben ebenso 
nicht, weil man eh nicht so schnell sieht.

was soll das Ganze?

Entweder wird so oft abgefragt, oder so oft drauf reagiert.
Was ist an de PORTB Bit0..3 angeschlossen ?

[Ralph H. (guru)]

Also... es ist nur ne Ausgaberoutine, die bei jedem Toogeln der Bits
B0..3 aufgerufen wird und tatsächlich soll damit die Spaltenabfrage
eines Z1013 "beantwortet" werden.
Das geht bei Taktfrequenzen bis 3Mhz problemlos, aber bei 4 Mhz ist
das Timing dann nicht mehr ausreichend, auch ohne CLI.

Das CLI ist tatsächlich unnötig, aber ich hab mir das angewöhnt es
immer mit in die ISR zu bauen.

Ich denke, dass ist so nicht zu lösen, sondern nur mit schnellerer 
Hardware.

[S. Landolt (Gast)]

Ohne den Sinn des Ganzes verstehen zu wollen, zwei Kleinigkeiten:

 ldi    mtemp1,noCode
 ldi  mtemp1,BZ7    ; CTRL

Der erste Befehl ist sinnlos.


 mov  mtemp1,code    ; Code holen
 cpi  mtemp1,kein_Zeichen  ; keine Taste gedrückt -> Ende
 breq  MatrixLeer    ; Spalten deaktivieren
 mov  mtemp1,code    ; Code holen

Der letzte Befehl ist unnötig.

[Noch nicht Rentner (Gast)]

Was soll eine Ausgabe mit 4MHz Geschwindigkeit aufgrund eines Interrupts 
? Das macht doch gar keinen Sinn.

Wie immer .. ich muss raten .. eine 7 Segment Matrix. Die steuert man zb 
im idle loop oder in einem Timer interrupt an, und erledigt 
kommunikations- inputs asynchron im Interrupt.

Falls es sich um Tasten handelt ... waer alles ganz falsch. Wo bleibt 
die Entprellung. Tasten schneller als 50Hz abzufragen bringt nichts.

Ich bezweifle die Sinnhaftigkeit des gezeigten Konzeptes.

[S. Landolt (Gast)]

> ... mit dem internen Osszilator mehr als 8Mhz ...
Wäre das Hochziehen von OSCCAL eine Lösung?


(Zu viel Punsch: "des Ganzen")

[(prx) A. K. (prx)]

Wegstaben V. schrieb:
> also eine Tastaturmatrix abfragen, stimmts?

Nö. Das andere Ende davon. Das ist die Tastenmatrix selbst. Nämlich ein 
µC an Stelle der Matrixtastatur eines Z1013. Der µC muss dann schnell 
genug sein, um auf die Matrix-Abfrage der CPU des Z1013 rechtzeitig 
reagieren zu können. Die 3-4 MHz beziehen sich auf den Takt des Z1013.

[Ralph H. (guru)]

A. K. schrieb:
> Das dürfte so ungefähr das Gegenteil der Abfrage einer Tastenmatrix
> sein. Nämlich ein µC an Stelle der Matrixtastatur eines Z1013. Der µC
> muss dann schnell genug sein, um auf die Matrix-Abfrage der CPU des
> Z1013 rechtzeitig reagieren zu können. Die 3-4 MHz beziehen sich auf den
> Takt des Z1013.

So ist es !

Danke auch für den Hinweis auf die 2 sinnlosen Befehle. Ich probier das 
mal aus.

[(prx) A. K. (prx)]

Weiss nicht ob es viel bringt, aber einen Teil der Abfragerei liesse 
sich eindampfen, indem man abhängig vom Wert springt.

Also beispielsweise sowas wie
  ldi   zh, high(table)   ;einmal vorneweg

interrupt:
  in    sreg1, sreg
  in    zl, PORTB
  swap  zl
  andi  zl, 0xF0
  ijump

Die "Tabelle", die notwendigerweise an einer Code-Adresse xx00 anfängt, 
hat im obigen Beispiel 16 Befehle Platz pro Wert, den die Portpins 
einnehmen können. Ist also 512 Bytes gross. Geht kleiner, wenn man 
beispielsweise nur 8 Befehle pro Wert braucht. Das Z Register sollte nur 
im Interrupt verwendet werden - was u.U. an anderer Stelle nach 
kreativer Lösung verlangt.

Wobei man den SWAP einsparen kann, wenn die Pins so auf dem Port liegen, 
dass es zur Anzahl Befehle passt, die man pro Fall in der Tabelle 
braucht.

[(prx) A. K. (prx)]

Ähnliche Idee: Man könnte auch 2 der im Code vorkommenden 4-Bit Gruppen 
zu einer Sprungtabelle mit 256 Fällen zusammenfassen. Die Tabelle 
enthält dann nur Sprungbefehle zum Code für den jeweiligen Fall. Müsste 
man mal analysieren, ob das was bringt.

Also ungefähr:

interrupt:
  in   sreg1, sreg
  in   zl, portb
  andi zl, 0x0F
  or   zl, code ;oder was auch immer, mit 0 in 0..3
  ijump

table:
  rjmp fall_0_0
  rjmp fall_0_1
  ...
  rjmp fall_F_F

[S. Landolt (Gast)]

Ich glaube nicht, dass das doppelte Springen zeitliche Vorteile bringt.

(nur damit das nicht so stehenbleibt: PINB und ijmp)

[Ralph H. (guru)]

A. K. schrieb:
> Ähnliche Idee: Man könnte auch 2 der im Code vorkommenden 4-Bit Gruppen
> zu einer Sprungtabelle mit 256 Fällen zusammenfassen. Die Tabelle
> enthält dann nur Sprungbefehle zum Code für den jeweiligen Fall. Müsste
> man mal analysieren, ob das was bringt.
>
Das ist ein interessanter Ansatz ! Dankeschön :-)

[(prx) A. K. (prx)]

S. Landolt schrieb:
> Ich glaube nicht, dass das doppelte Springen zeitliche Vorteile bringt.

In der ersten Fassung wird nur 1x gesprungen. Der Code der 16 Fälle 
steht dann direkt in der Tabelle, die pro Fall 16 Befehle fasst.

In der zweiten Fassung wird zwar 2x gesprungen, aber es werden mehrere 
bedingte Sprünge in einem Rutsch erledigt.

> (nur damit das nicht so stehenbleibt: PINB und ijmp)

Yep. War quick-and-dirty.

[(prx) A. K. (prx)]

Zum Originalcode: Der längste kritische Pfad im Interrupt sollte so 
wenig ausgeführte Sprünge wie möglich enthalten. Nicht ausgeführt sind 
sie nämlich schneller.

Also nicht:
  cmp ...
  brne l1

  befehl1
  befehl2
  reti

l1:
  befehl1
  befehl2
  befehl3
  befehl4
  reti

Denn hier wird der sowieso schon längere Pfad durch den ausgeführten 
Sprung noch einen Takt länger.

----

Mann kann auch das Ende vom jeweiligen Pfad mit repliziertem Code 
ausstatten, statt zum gemeinsamen Ende des Interrupts zu springen. Also

 ;weg; rjmp  MatrixAusgabe    ; und ausgeben
 ;Code von MatrixAusgabe kopiert:
   lsr  mtemp1    ; 1x rechtsschieben wegen Bits in PortD 3..6
   out  PortD,mtemp1    ; SpaltenCode nun ausgeben
   out  SREG,SREG1    ; Statusregister zurück
   reti        ; hier Ausgang Ausgabe

 ...

MatrixLeer:
 ldi  mtemp1,kein_Zeichen   ; keine Spalte aktiv, ggf.aktive Spalte
löschen
 ;weg; rjmp  MatrixAusgabe    ; ausgeben
 ;Code von MatrixAusgabe kopiert:
   lsr  mtemp1    ; 1x rechtsschieben wegen Bits in PortD 3..6
   out  PortD,mtemp1    ; SpaltenCode nun ausgeben
   out  SREG,SREG1    ; Statusregister zurück
   reti        ; hier Ausgang Ausgabe

Bei sowas sind Macros nützlich.

[C. A. Rotwang (Gast)]

A. K. schrieb:

> Nö. Das andere Ende davon. Das ist die Tastenmatrix selbst. Nämlich ein
> µC an Stelle der Matrixtastatur eines Z1013. Der µC muss dann schnell
> genug sein, um auf die Matrix-Abfrage der CPU des Z1013 rechtzeitig
> reagieren zu können. Die 3-4 MHz beziehen sich auf den Takt des Z1013.

Der Z1013 läuft aber original mit 1 resp 2 MHz, ausserdem läßt sich die 
Z80 CPU für einen Befehl mehrere Takte Zeit. Eventuell kannst du mit dem 
Ziehen der BRDY Leitung der PIO beliebig Zeit "schinden".

[(prx) A. K. (prx)]

C. A. Rotwang schrieb:
> Eventuell kannst du mit dem
> Ziehen der BRDY Leitung der PIO beliebig Zeit "schinden".

Oder direkt am /WAIT der CPU.

[C. A. Rotwang (Gast)]

A. K. schrieb:
> C. A. Rotwang schrieb:
>> Eventuell kannst du mit dem
>> Ziehen der BRDY Leitung der PIO beliebig Zeit "schinden".
>
> Oder direkt am /WAIT der CPU.

Ja, aber weil die Tastatur direkt an der PIO hängt, ist BRDY IMHO die 
sauberer Variante. BRDY findet sich auch als Anschluß an X4, WAIT nicht.

Evntuell wäre noch zu Überlegen, ob man den Tastaturdecoder mit dem A46 
A47 auch gleich den Z1013 erledigen lässt. das spart einige strippen an 
den AVR, man müsste dann aber 5 strippen vom D175 rüberfädeln. Aber 
vielleicht ist das ja eh schon vorgesehen.

[C. A. Rotwang (Gast)]

C. A. Rotwang schrieb:

> Evntuell wäre noch zu Überlegen, ob man den Tastaturdecoder mit dem A46
> A47 auch gleich den Z1013 erledigen lässt.

Tippfehler, gemeint ist:

Eventuell wäre noch zu Überlegen, ob man den Tastaturdecoder (4 bit reg, 
Binar-dezimal encoder) mit dem A46,A47 auch gleich den AVR 
miterledigen lässt.

[Ralph H. (guru)]

Ne Männer... /BRDY und Wait kommen nicht in Frage! und 4Mhz stimmt 
schon.

[C. A. Rotwang (Gast)]

Ralph H. schrieb:
> Ne Männer... /BRDY und Wait kommen nicht in Frage! und 4Mhz stimmt
> schon.

Wer übertaktet muss eben leiden ;-). Häng doch mal ein scope dran, 
wieviel Zeit ist zwischen -Zeile Setzen und -spalte lesen?

[Ralph H. (guru)]

C. A. Rotwang schrieb:
> Wer übertaktet muss eben leiden ;-). Häng doch mal ein scope dran,
> wieviel Zeit ist zwischen -Zeile Setzen und -spalte lesen?

So ein genauen Oszi hab ich leider nicht, aber ich schau mir das mal
im Quelltext direkt an.
Das "Problem" bei der Schaltung ist, dass ich die Hardware nicht mehr
ändern kann, weil bereits zuviele davon im Einsatz sind.

Aber wir kriegen das hin :-)

[M. K. (sylaina)]

Ralph H. schrieb:
> Das CLI ist tatsächlich unnötig, aber ich hab mir das angewöhnt es
> immer mit in die ISR zu bauen.

Warum? Verbrät doch nur Zeit die bei dir eh schon knapp ist. Das 
solltest du dir unbedingt wieder abgewöhnen.

[S. Landolt (Gast)]

Da auf meinen Vorschlag mit OSCCAL so gar keine Reaktion erfolgte, 
möchte ich nochmal darauf zurückkommen.

> Das geht bei Taktfrequenzen bis 3Mhz problemlos,
> aber bei 4 Mhz ...

Also ein Faktor von 1.333, d.h. der ATtiny2313 müsste mit 10.67 MHz 
laufen. Laut Datenblatt sollte das problemlos gehen, und bei meinen 
Exemplaren verlangt dies ein OSCCAL von $E4 bzw. $F2, bei einem 
ATtiny2313A $E5.


(cave: es könnte Probleme mit dem Programmiergerät geben)