Gibt es einen schnelleren aber baugleichen AVR zum Atiny2313

Nein, nicht pinkompatibel.

Oftmals kann man durch Strukturierung der Software mehr Geschwindigkeit 
rausholen.

Nicht pinkompatibel mit intern 16MHz: ATtiny861.

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 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

also eine Tastaturmatrix abfragen, stimmts?

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

http://www.z1013.de/

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

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.

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.

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.

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.

Ä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

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 :-)

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.

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 schrieb:
> Eventuell kannst du mit dem
> Ziehen der BRDY Leitung der PIO beliebig Zeit "schinden".

Oder direkt am /WAIT der CPU.

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

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 :-)

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.