Zitat Zitat von Bernd_Stein Beitrag anzeigen
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 *
Jo okay wenn ich es also richtig verstehe möchtest du den Takt sprich die Zeit ermitteln. Und der Tiny läuft auf 4,8Mhz um wenige Khz würde ich mich jetzt nicht festlegen wollen siehe
DB
During reset, hardware loads the calibration data into the OSCCAL register and thereby auto-matically calibrates the oscillator. There are separate calibration bytes for 4.8 and 9.6 MHzoperation but only one is automatically loaded during reset (see section “Calibration Bytes” onpage 104). This is because the only difference between 4.8 MHz and 9.6 MHz mode is an inter-nal clock divider

3,2/4,8 = 0,66666 sprich 66,66%
3,2Mhz = 312,5ns
4,8Mhz = 208,3ns Taktzeit

Sonst lese er mal vom Tiny das OSSCAL aus was nach einem RESET reingeschrieben wurde siehe Seite 104
The signature area of the ATtiny13 contains two bytes of calibration data for the internal oscilla-tor. The calibration data in the high byte of address 0x00 is for use with the oscillator set to 9.6MHz operation. During reset, this byte is automatically written into the OSCCAL register toensure correct frequency of the oscillator.There is a separate calibration byte for the internal oscillator in 4.8 MHz mode of operation butthis data is not loaded automatically. The hardware always loads the 9.6 MHz calibraiton dataduring reset. To use separate calibration data for the oscillator in 4.8 MHz mode the OSCCALregister must be updated by firmware. The calibration data for 4.8 MHz operation is located inthe high byte at address 0x01 of the signature area.



Zitat Zitat von Bernd_Stein Beitrag anzeigen
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:	14
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

EIJJAAAAAAIJJAIIIIIIIIII da is ja so einiges im Argen.
1. Woher sollen wir wissen was in deinen Includes steht bzw ob es überhaupt sinnvoll ist ?

2. Includes entweder komplett vorne und hinten anfügen aber nicht unbedingt irgendwo im Programm.

3. Wenn du mit INT arbeitest was meinst du was du bei der Initialisierung noch brauchst ?
DEN STACKPOINTER!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

4. Was steht in der ISR als Rücksprung bzw ist das RETI eingetragen ? Wenn nicht läuft er dir dein CTRL die gesamten ISR-Routinen durch, bisher sind sie für uns alle UNSICHTBAR siehe Punkt 1, und wenn da irgendwas steht wird das
gnaaaadenlos abgearbeitet was dann zu unerwarteten Effekten führen kann wie zb ein RESET des gesamten CTRL. Besonders wenn ein RET/RETI ausgeführt wird ohne den SP angelegt zu haben.

5. Sieh dir mal an wie ich es Bibliotheken gepackt habe https://www.roboternetz.de/community...328-Bibliothek

6. Zu
.ORG INT_VECTORS_SIZE ;Programmadresse nach den ganzen IRQ-Vektoren
was komplett falsch verstanden worden ist
EINMAL folgendes lesen https://www.mikrocontroller.net/topic/265926

7. Was meinst du wie sehr ein Taster prellt ? Da arbeitet er die Befehle folgend auf SBIC/S sofort mehrmals ab deshalb ist absolut unelegant einen Taster ohne Wartezeit oder Entprellroutine so abzufragen.
Sollte das Signal natürlich DIGITAL vorliegen ist es so durchaus normal. Leider fehlt der Kommentar was die Ursache zum Auslösen ist.

8. Zum Systemtakt änder verweise ich auf S.28 des DB wie dort 100%ig zu verfahren ist und nicht irgendwie https://ww1.microchip.com/downloads/...oc/doc2535.pdf


Vorschlag wenn du ohne große INIT usw usf deinen Systemtakt ermitteln möchtest wie folgt

INIT:
SBI DDRX , Y ; 2Takte

Start:
SBI PORTX , Y ; 2Takte
CBI PORTX , Y ; 2Takte
SBI PORTX , Y ; 2Takte
CBI PORTX , Y ; 2Takte
SBI PORTX , Y ; 2Takte
CBI PORTX , Y ; 2Takte
rjmp Start ; 2Takte

Beim RJMP bleibt das Bit etwas länger gelöscht ist aber nicht weiter schlimm man könnte daran erkennen wann das Programm wieder von vorn beginnt. So eine Art Synch....

PS: Dein nicht erklärbarer Takt kommt von deiner Software und von nichts anderen !!!! ASM macht nur das was DU, der Programmierer geschrieben hast, auch wenn mal etwas vergessen wurde

- - - Aktualisiert - - -

Zitat Zitat von Bernd_Stein Beitrag anzeigen
Es ist schon ein Elend mit diesen Foren. Da hat man mal einen kompetenten Schreiber der sich der Sache annimmt, dann taugt die Forensoftware leider nichts.
Man investiert eine menge Arbeit und aus dem Bild wird dann nur noch ein " Piktogramm ". Oder die Forensorftware ist Top, aber es nehmen nur Trolle an der Diskusion teil.

Also nochmal etwas anders :

Meines Wissens her, ist bei einem Latch im transparenten Teil, der Eingang gleich dem Ausgang ( D = Q ). Das Latch ist in der High-Phase des Systemtaktes transparent, also ab der steigenden Flanke bis zur fallenden Flanke des Systemtaktes.

Höchstwahrscheinlich ist dies wieder nur ein Prinzipschaltbild und dass PINxn-Register speichert mit der steigenden Flanke immer nur den gespreicherten Zustand des Latches und nicht den im transparenten Moment, oder es ist grundsätzlich so, dass ein Latch nicht so schnell vom Latch-Zustand in den Transparenten umschaltet wie ich es jetzt annehme.

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

Name:	ATtiny13A_Synchronization_Eigen_Ausschnitt.jpg
Hits:	10
Größe:	26,3 KB
ID:	34943

Dass man ein Latch nimmt und nicht ein zweites D-FF mit negiertem Takteingang, muss irgend etwas damit zu tun haben, dass man versucht kurze Pegelwechsel auszublenden, wir aber nur ein Prinzipschaltbild zu sehen bekommen, wo dies nicht ersichtlich ist.

So, schicke dies erstmal los bevor noch was schiefgeht.


Bernd_Stein

Das Problem hat NIX, 0 mit der HW des CTRL zu tun !!!!

Aber um die Informationslage etwas zu verdichten kann man ganz vereinfacht sagen das Daten erst auf den PORT/DDR/PIN gelegt/abgefragt werden wenn der nächste Systemtakt kommt. Dies soll sicherstellen das die Daten immer und zu jeden Zeitpunkt KONSISTENT sind.

Man stelle sich vor dies wäre nicht so und am Eingang/Ausgang wird es ASynchron geändert was das für ein Durcheinander in UNSERER SW geben würde. Manche Programmteile würde immer ausgeführt manche gar nicht und andere wiederum nur ab und an und manch andere nur mit gaaaanz viel Glück.

Siehe ADC wenn 10bit ausgelesen werden sollen wird das Datenwort, also die 10Bit = 8 Bit low und 2 Bit High, MUSS ADCL als erstes gelesen werden und erst wenn ADCH gelesen WORDEN ist wird ADCH:L für den ADC freigegeben wieder Ergebnisse dort zu hinterlegen damit die Datensätze konsistent bleiben.