-         
Seite 1 von 3 123 LetzteLetzte
Ergebnis 1 bis 10 von 28

Thema: ATtiny13A: Wo kommt der eine Takt her?

  1. #1
    Erfahrener Benutzer Roboter-Spezialist Avatar von Bernd_Stein
    Registriert seit
    19.09.2008
    Ort
    Deutschland : Nordrhein-Westfalen ( NRW )
    Alter
    49
    Beiträge
    401

    ATtiny13A: Wo kommt der eine Takt her?

    Anzeige

    Hallo zusammen,

    wieder habe ich ein Problem. Wo kommt der eine Takt her ?

    Eins vorweg :

    Theoretisch 4,8Mhz, praktisch ist der interne RC-Oszilator aber nur mit
    3,2Mhz, bei meinem ATtiny13A, bei 5V und ca. 20°C unterwegs. Um dies
    festzustellen, habe ich meinen üblichen Trick verwendet ( Endlosschleife
    -> Pin toggeln und ausmessen )

    Heißt: *Ein Takt sind ca. 312,500ns *

    Bei dem LA-Ausschnitt ist zu sehen, dass die LED-Gelb ( PB2 ), 2,333µS
    nach der steigenden Flanke von PB1 folgt.

    Klicke auf die Grafik für eine größere Ansicht

Name:	ATtiny13A_Zeitspanne.jpg
Hits:	13
Größe:	19,1 KB
ID:	34932

    Für mein daherhalten, erzeugt diese Codesequenz 4 oder 6 Takte, bis die
    steigende Flanke von LED-Gelb kommt:
    _main:
    sbis PINB,1
    rjmp _main
    sbi LED_PORT,led.ge ;LED-Gelb einschalten ( TEST )################################################## #######################


    6T wären 1,875µs. Bleiben also noch 458ns, was locker ein Takt ist.
    Deshalb meine Frage : "Wo kommt der eine Takt her?"
    ;
    .include "Header.inc" ;Label und Werte Zuweisungen
    .include "Hardware.inc" ;Hardware Label Zuweisungen
    ;
    ;Programmstart nach RESET ( Interrupt Vektoren Tabelle )
    ;
    .CSEG ;Was ab hier folgt kommt in den FLASH-Speicher
    .ORG $0000 ;Programm beginnt an der FLASH-Adresse 0x0000..

    rjmp _reset ;..mit der RESET-Vektortabelle

    .include "IRQt13.inc" ;Restliche Interrupt Vektortabelle

    .ORG INT_VECTORS_SIZE ;Programmadresse nach den ganzen IRQ-Vektoren
    ;
    ;IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII
    ;IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII
    ;I Erstinitialisierungen
    ;IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII
    ;IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIII IIIIIIIIIIIIIIIIIIIIIIIIIIIII
    ;
    _reset:
    ;
    ;Ports Erstkonfiguration
    ;
    sbi DDRB,led.pla ;PORT-Bit als Ausgang f. PLA-LED
    sbi DDRB,led.ora ;PORT-Bit als Ausgang f. SLEEP-LED
    sbi DDRB,led.ge ;PORT-Bit als Ausgang f. TEST-LED
    ;
    ;Variablen initialisieren ( r0-r31 haben unbestimmten Inhalt )
    ;
    ;
    ;HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
    ;HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
    ;H Hauptprogrammschleife
    ;HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
    ;HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH HHHHHHHHHHHHHHHHHHHHHHHHHHHHHH
    ;
    ;sbi PINB,led.pla ;Systemtakt -> Gemessene Frequenz..######################################## ##############################
    ;rjmp pc-1 ;..mal 8 nehmen ################################################## #######################

    _test:
    cbi PORTB,led.ora ;LED-Orange einschalten
    sbi PORTB,led.ora ;LED Orange ausschalten
    ldi xl,8
    clr b

    _main:
    sbis PINB,1
    rjmp _main
    sbi LED_PORT,led.ge ;LED-Gelb einschalten ( TEST ) ################################################## #######################
    cbi LED_PORT,led.ge ;LED-Gelb ausschalten ( TEST ) ################################################## ######################
    _main_1:
    sbic PINB,1
    rjmp _main_1
    sbi LED_PORT,led.pla ;LED-PLA einschalten ( TEST ) ################################################## #######################
    cbi LED_PORT,led.pla ;LED-PLA ausschalten ( TEST ) ################################################## #######################
    ;
    ;Systemtakt ( 4,8MHz ) durch X teilen
    ;
    in a,CLKPR ;Clock Prescaler Register laden..
    sbr a,1<<CLKPCE ;..Sicherheitsprozedur..
    cbr a,1<CLKPS3|1<<CLKPS2|1<<CLKPS1|1<<CLKPS0;..
    out CLKPR,a ;..durchfuehren..
    ldi a,$7F ;..CLKPCE loeschen..
    and a,b
    out CLKPR,a

    inc b
    cpse b,xl
    rjmp _main

    rjmp _test


    ; rjmp PC ;Endlosschleife

    .EXIT ;Ende des Quelltextes


    Bernd_Stein
    Geändert von Bernd_Stein (05.04.2020 um 16:58 Uhr) Grund: Wollte den Schreibfehler bei den Stichwörtern wegmachen, weiß aber nicht wie das geht
    CRS Robotics A255, TRONXY X3A, TinkerCAD, c´t-Lab, ProfiLab Expert, AVR8 Assembler

  2. #2
    Erfahrener Benutzer Roboter-Spezialist
    Registriert seit
    07.04.2015
    Beiträge
    575
    Ich hätte ja jetzt gesagt: Das ist ein Fall für den Simulator, in dem man sowohl Takte, als auch Zeiten von solchen Codefragmenten recht verlässlich vermessen kann.

  3. #3
    Erfahrener Benutzer Roboter-Spezialist Avatar von Bernd_Stein
    Registriert seit
    19.09.2008
    Ort
    Deutschland : Nordrhein-Westfalen ( NRW )
    Alter
    49
    Beiträge
    401
    Zitat Zitat von Holomino Beitrag anzeigen
    Ich hätte ja jetzt gesagt: Das ist ein Fall für den Simulator, in dem man sowohl Takte, als auch Zeiten von solchen Codefragmenten recht verlässlich vermessen kann.
    Welcher?

    Der im Atmel Studio 7 ( AS7 ) ist nicht so ganz dafür zu gebrauchen. Habe mir extra die neuste Version heruntergeladen. Was da genau unrund läuft berichte ich mal später.


    Bernd_Stein
    CRS Robotics A255, TRONXY X3A, TinkerCAD, c´t-Lab, ProfiLab Expert, AVR8 Assembler

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.603
    Blog-Einträge
    133
    Zitat Zitat von Bernd_Stein Beitrag anzeigen
    Wo kommt der eine Takt her ?
    ...
    ....
    Heißt: *Ein Takt sind ca. 312,500ns *
    ...
    Für mein daherhalten, erzeugt diese Codesequenz 4 oder 6 Takte, bis die
    steigende Flanke von LED-Gelb kommt:
    _main:
    sbis PINB,1
    rjmp _main
    sbi LED_PORT,led.ge ;LED-Gelb einschalten ( TEST )################################################## #######################
    Ablauf meiner Ansicht nach:
    - steigende Flanke an PB1
    - es dauert max. 1,5 Takte bis Status im PIN Register steht
    ( ww1.microchip.com/downloads/en/DeviceDoc/doc8126.pdf , 10.2.4 Reading the Pin Value )
    - SBIS braucht einen Takt wenn PIN noch LOW ist
    - RJMP braucht zwei Takte zum Springen nach _main
    - Zwei Takte von SBIS wenn PIN jetzt high ist
    - Zwei Takte von sbi LED_PORT,led.ge

    1,5T + 1T + 2T + 2T + 2T = 8,5 Takte

    worst case: 8,5T * 312,5ns = 2656,25ns

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  5. #5
    Erfahrener Benutzer Roboter Genie
    Registriert seit
    05.11.2007
    Ort
    Berlin
    Beiträge
    1.020
    Hallo Bernd_Stein,

    Ich prüfe auch immer als erstes ob meine CPU richtig läuft.
    "Instruction Cycle Time". Bei den vielen Einstellungen in Registern liegt man gerne mal falsch.

    Dazu toggle ich aber lediglich einen Pin 3 mal und dann kommt der Loop
    So kann ich sicher gehen, dass innerhalb der 3 Signale kein Laufzeitverzögerungen/Takte usw. zusätzlich drin sind.
    Mit dem Ossi schaue ich mir das Signal dann an. Normalerweise ergibt dies 3 symetrische Impulse
    und dann folgt eine etwas längere Pause wegen dem Loop oder Jump.

    loop:
    Pin High
    Pin Low
    Pin High
    Pin Low
    Pin High
    Pin Low
    jump loop

    Das der RC Oszillator derart daneben liegt kann ich mir kaum vorstellen,
    statt 4,8 Mhz nur 3,2 Mhz ist eher unwahrscheinlich
    Laut Datenblatt kann er 10 Prozent abweichen
    somit läge die Frequenz bei 4,8-0,48 = 4,32 MHz
    Dieser lässt sich aber noch kalibrieren.
    Ob er dadurch dann derart verschoben werden kann bin ich mir aber nicht sicher.

    Siro
    Geändert von Siro (05.04.2020 um 20:54 Uhr)

  6. #6
    Erfahrener Benutzer Robotik Einstein Avatar von wkrug
    Registriert seit
    17.08.2006
    Ort
    Dietfurt
    Beiträge
    2.073
    Ich weiss jetzt zwar nicht, ob der tiny 13 einen PWM Generator hat, wenn ja würde ich da mal eine vom Prozessortakt abhängige PWM ausgeben lassen.
    Der Timer läuft unabhängig vom Prozessorkern und somit auch von Interrups und Kommando Taktzyklen.

    Damit sollte sich eine qualifizierte Aussage über den Takt treffen lassen.

  7. #7
    Erfahrener Benutzer Roboter-Spezialist Avatar von Bernd_Stein
    Registriert seit
    19.09.2008
    Ort
    Deutschland : Nordrhein-Westfalen ( NRW )
    Alter
    49
    Beiträge
    401
    @Searcher
    Danke, jetzt sehe ich den Worst-Case-Fall ebenfalls so.

    Ich überlege mir später den " Best-Case-Fall", also die kürzeste Ausführungszeit.

    Mein ( ein ) Problem mit dem Simulator vom AS7 ist, dass beim Rücksetzen des Programmzählers am Breakpoint, der Befehl zwar ausgeführt wird, aber der PC diesen Befehl nicht mitzählt :

    Klicke auf die Grafik für eine größere Ansicht

Name:	AS7_Simu_Reset Cycle Counter.jpg
Hits:	4
Größe:	46,3 KB
ID:	34936

    Edit: Die ist auch richtig, da der PC ja auf Null ist und somit erstmal nur " 1st Instruction Fetch " ausgeführt wird, aber in diesem Fall störend.

    EDIT : -> Quatsch, der PC müsste gezählt werden, aber der Befehl nicht ausgeführt.


    >>
    Ich prüfe auch immer als erstes ob meine CPU richtig läuft.
    "Instruction Cycle Time". Bei den vielen Einstellungen in Registern liegt man gerne mal falsch.

    Dazu toggle ich aber lediglich einen Pin 3 mal und dann kommt der Loop
    So kann ich sicher gehen, dass innerhalb der 3 Signale kein Laufzeitverzögerungen/Takte usw. zusätzlich drin sind.
    Mit dem Ossi schaue ich mir das Signal dann an.
    >>

    @Siro
    Ich mache es so ähnlich, deshalb die auskommentierte Codesequenz :

    ;sbi PINB,led.pla ;Systemtakt -> Gemessene Frequenz..########################
    ;rjmp pc-1 ;..mal 8 nehmen ########################


    >>
    Ich weiss jetzt zwar nicht, ob der tiny 13 einen PWM Generator hat, wenn ja würde ich da mal eine vom Prozessortakt abhängige PWM ausgeben lassen.
    Der Timer läuft unabhängig vom Prozessorkern und somit auch von Interrups und Kommando Taktzyklen.

    Damit sollte sich eine qualifizierte Aussage über den Takt treffen lassen.
    >>

    @wkrug
    Halte dies für zu Aufwändig. Siehe Antwort zu @Siro

    Sorry, für die Formatierung, habe jetzt aber keinen Bock da weiter herum zu experimentieren. Ein korreturversuch muss reichen.


    Bernd_Stein
    Geändert von Bernd_Stein (08.04.2020 um 09:14 Uhr) Grund: siehe Edit :
    CRS Robotics A255, TRONXY X3A, TinkerCAD, c´t-Lab, ProfiLab Expert, AVR8 Assembler

  8. #8
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.603
    Blog-Einträge
    133
    Hallo Berd_Stein,

    Ich hab mir den Ablauf nochmal durch den Kopf gehen lassen und meine, daß der worst case eigentlich nur 7,5T lang sein kann. Ich gehe dabei davon aus, daß der externe Pegel kurz nach fallender Flanke des System Clock, etwa bei Zeitpunkt "A" high wird. Das SBIS wird zum Zeitpunkt B ausgeführt. Da kann der Zustand noch nicht im PIN Register stehen sondern wird erst im Zeitpunkt C dort stehen.

    Klicke auf die Grafik für eine größere Ansicht

Name:	sync.PNG
Hits:	13
Größe:	19,3 KB
ID:	34937

    Also zweiter Versuch zum Ablauf:
    - steigende Flanke an PB1
    - es dauert max. 1,5 Takte bis Status im PIN Register steht
    ( ww1.microchip.com/downloads/en/DeviceDoc/doc8126.pdf , 10.2.4 Reading the Pin Value )
    - SBIS beginnt einen halben Systemtakt nach steigender Flanke an PB1 und braucht einen Takt wenn PIN noch LOW
    - RJMP braucht zwei Takte zum Springen nach _main
    - Zwei Takte von SBIS wenn PIN jetzt high ist
    - Zwei Takte von SBI LED_PORT,led.ge

    0,5T + 1T + 2T + 2T + 2T = 7,5 Takte

    worst case: 7,5T * 312,5ns = 2343,75ns

    In der vorherigen Rechnung bin ich davon ausgegangen, daß SBIS zum Zeitpunkt C ausgeführt wird. Da kann dann aber schon der "echte" Zustand von PB1 im PIN Register stehen und der RJMP zur _main wäre nicht nötig.

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

  9. #9
    Erfahrener Benutzer Roboter-Spezialist Avatar von Bernd_Stein
    Registriert seit
    19.09.2008
    Ort
    Deutschland : Nordrhein-Westfalen ( NRW )
    Alter
    49
    Beiträge
    401

    ATtiny13A: Figure 10-3 verstehen

    Zitat Zitat von Searcher Beitrag anzeigen
    Hallo Berd_Stein,

    Ich hab mir den Ablauf nochmal durch den Kopf gehen lassen und meine, daß der worst case eigentlich nur 7,5T lang sein kann. Ich gehe dabei davon aus, daß der externe Pegel kurz nach fallender Flanke des System Clock, etwa bei Zeitpunkt "A" high wird. Das SBIS wird zum Zeitpunkt B ausgeführt. Da kann der Zustand noch nicht im PIN Register stehen sondern wird erst im Zeitpunkt C dort stehen.
    Um so genauer man sich mit dieser Sache auseinandersetzt, um so verwirrender wird es für mich.
    Ich sehe es leider nicht so für den Worst-Case-Fall, da du ja

    1. zum Zeitpunkt A richtigerweise erstmal angenommen hattest, dass der Signalpegel low ist.

    2. Ja, zum Zeitpunkt C wird sbis ausgeführt, aber sbi ja noch nicht.

    3. Dein jetziges Szenario mit High-Pegel direkt nach der fallenden Flanke des Systemtaktes ist genau das, was im DB beschrieben ist und wir in Figure 10-3 zu sehen bekommen.

    Was ich jedoch blöd gemacht finde, denn woher weiß den PINxn, dass es den Zustand erst einen Takt später vom LATCH übernehmen soll und nicht zeitgleich, wenn LATCH sich im tranparenten Abschnitt ( High-Phase des Systemtaktes ) befindet ?

    In dieser Zeit ist ja D direkt an Q vorhanden und somit auch an D von PINxn.

    Diese Frage kam mir auf, als ich selbst mal ein Signalverlauf aufgezeichnet habe und und nicht wusste wie sich jetzt PINxn verhält ( siehe Punkte ).
    Ich habe jedoch den LATCH-Bereich straffiert, da ich den Transparentenbereich für irrelevant halte.

    Klicke auf die Grafik für eine größere Ansicht

Name:	ATtiny13A_Synchronization when Reading an Externally Applied Pin value_Eigen.jpg
Hits:	12
Größe:	17,5 KB
ID:	34939

    Ich Suche schon verzweifelt nach einem günstigen Bitmustergenerator ( pattern generator ), finde jedoch nichts günstiges ( um die 50€ ).


    Bernd_Stein
    Geändert von Bernd_Stein (08.04.2020 um 08:54 Uhr)
    CRS Robotics A255, TRONXY X3A, TinkerCAD, c´t-Lab, ProfiLab Expert, AVR8 Assembler

  10. #10
    Erfahrener Benutzer Robotik Einstein Avatar von Searcher
    Registriert seit
    07.06.2009
    Ort
    NRW
    Beiträge
    1.603
    Blog-Einträge
    133
    Zitat Zitat von Bernd_Stein Beitrag anzeigen
    Was ich jedoch blöd gemacht finde, denn woher weiß den PINxn, dass es den Zustand erst einen Takt später vom LATCH übernehmen soll und nicht zeitgleich, wenn LATCH sich im tranparenten Abschnitt ( High-Phase des Systemtaktes ) befindet ?
    Habe ich dem Text aus dem DB unter der Grafik entnommen. Latched wird bei fallender Flanke und ins PIN Register einen halben Takt später mit steigender Flanke geschrieben.

    Zitat Zitat von DB
    Consider the clock period starting shortly after the first falling edge of the system clock. The latch
    is closed when the clock is low, and goes transparent when the clock is high, as indicated by the
    shaded region of the “SYNC LATCH” signal. The signal value is latched when the system clock
    goes low. It is clocked into the PINxn Register at the succeeding positive clock edge.
    As indicated by the two arrows tpd,max and tpd,min, a single signal transition on the pin will be delayed
    between ½ and 1½ system clock period depending upon the time of assertion.


    Zitat Zitat von Bernd_Stein Beitrag anzeigen
    3. Dein jetziges Szenario mit High-Pegel direkt nach der fallenden Flanke des Systemtaktes ist genau das, was im DB beschrieben ist und wir in Figure 10-3 zu sehen bekommen.
    Nicht ganz. Für den worst case muß der Einlesebefehl (in Figure 10-3 das in) bzw Abfragebefehl (dein SBIS) einen Systemtakt früher beginnen damit der "echte" PB1 Zustand noch nicht im PIN Register steht und ein RJMP ausgeführt wird. Der SBIS danach bekommt dann den echten PB1 Zustand, macht den SKIP und kann die LED einschalten.

    Gruß
    Searcher
    Hoffentlich liegt das Ziel auch am Weg
    ..................................................................Der Weg zu einigen meiner Konstruktionen

Seite 1 von 3 123 LetzteLetzte

Ähnliche Themen

  1. [ERLEDIGT] ATtiny13A: Pin Change Interrupt vs. INT0
    Von Bernd_Stein im Forum Assembler-Programmierung
    Antworten: 7
    Letzter Beitrag: 17.04.2020, 16:17
  2. [ERLEDIGT] Empfängersignal mit ATtiny13A erkennen
    Von Lichti01 im Forum Elektronik
    Antworten: 14
    Letzter Beitrag: 24.06.2017, 07:19
  3. ATTiny13A Schalter abfragen/entprellung mit Variablen
    Von Denn Is im Forum C - Programmierung (GCC u.a.)
    Antworten: 19
    Letzter Beitrag: 01.07.2014, 11:21
  4. Attiny13a RS232
    Von flecralf im Forum C - Programmierung (GCC u.a.)
    Antworten: 1
    Letzter Beitrag: 09.10.2013, 18:27
  5. CLK Takt höher als Datenbus Takt (SDRAM)
    Von saoirse im Forum Elektronik
    Antworten: 1
    Letzter Beitrag: 25.08.2007, 17:12

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •