ATtiny13A: HESUNSE (CY800) Funksteckdosenprotokoll auswerten

[Searcher]

Nur ist der interne RC-Oszillator bei mir dermaßen ungenau, dass er statt mit den 600kHz mit ca. 410kHz läuft, wie man im Scrennshot zum 1ten Bit sehen kann ( 550µs ).

.....

Jaaa... nicht ganz, aber auch hier wieder den ungenauen RC-Oszillator beachten. Die 300kHz werden bereits in der INT0-ISR eingestellt und gelten somit für die darauf folgende PCI0-IRQ und schließlich immer für die OC0A-IRQ.

Hallo Bernd,

irgendetwas stimmt da nicht. Der PCINT tritt auf, wenn sich an Data was tut. Zu dem Zeitpunkt ist OCR0A mit dem Wert 66 geladen und der Systemtakt auf 1/16 in INT0 mit CLKPS2 gestellt (die theoretischen 300kHz). In der PCINT ISR wird dann der TIMER0 gestartet und soll damit eine Zeit von 550µs bis CTC Comparematch machen? oder wo soll man die 410kHz im Screenshot ablesen?

550µs/(66+1) = 8,2µs für einen Timerstep. Der Timer wird also mit 1/8,2µs=121,951kHz getaktet.
Wegen 1/16 ist der Systemtakt = 16*121,951kHz= 1,951219MHz und nicht die theoretischen 4,8MHz. (Dann komme ich aber statt 1100µs aber auf über 1500µs bei OCR0A = 192 und 1/16 SYSCLK)

Läuft der Timer mit 1/8 SYSCLK wären das 1,951219MHz/8 = 243,902kHz und nicht 410kHz.

Bitte überprüfen und/oder Korrekturrechnung bzw jetzt genau mal den SYSCLK explizit über zB OC0A toggle messen. Ist der Systemtakt stabil? Ist die Stromversorgung stabil und sauber?

Der µC geht zwischen den Comparematch Interrups immer wieder in den Idle Sleep. Laß ihn doch mal durchlaufen ohne Sleep. Sind die Zeiten dann konstanter?

Die Diskrepanz von 4,8Mhz zu 1,9Mhz ist arg. Vielleicht mal einen neuen µC probieren?

Gruß
Searcher

PS und das auf 0 Setzen des TCNT0 in der Comparematch ISR ist doch eigentlich nicht nötig. Der Timer ist doch auf Comparematch eingestellt. Es reicht das OCR0A beim ersten Mal auf 192 zu stellen und von mir aus jedes Mal. Rücksetzen von TCNT0 an der Stelle verkompliziert die Berechnung, da ja die Zeit von Aufruf der ISR bis Rücksetzten des Timers ja uach noch verrechnet werden muß.

[Bernd_Stein]

...
In der PCINT ISR wird dann der TIMER0 gestartet und soll damit eine Zeit von 550µs bis CTC Comparematch machen? oder wo soll man die 410kHz im Screenshot ablesen?

Die 410kHz hatte ich mal mit dieser Codesequenz und dem DSO ermittelt und den SYS-Takt dann ausgerechnet :

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

Jetzt nicht verzagen, der Screenshot wird ja im Detail erklärt :

https://www.edv-dompteur.de/forum/in...=4148#post4148

Ab ca. 420µs ( blauer senkrechter Strich ) geht die Aufzeichnung mit der fallenden Flanke des Monoflops los ( 1% davor wird auch noch erfasst ).


Irgendwann wird dann die INT0 Low-Level IRQ erzeugt.
Am Anfang der INT0-ISR wird der erste Impuls mit LED-Gelb erzeugt. Dieser ist 4,958µs lang und entspricht somit einer Frequenz von 403,388kHz, was eigentlich die nominalen 600kHz sind ( 4,958µs:2 wegen sbi, cbi ).

Am Ende der INT0-ISR ist der SYS-Takt ja bereits auf nominal 300kHz umgestellt und somit der 2te Impuls bei LED-Gelb 9,875µs lang, was der wahren Frequenz von 202,532kHz entspricht.

Die Pulse an LED-Orange lass ich jetzt erstmal raus damit es nicht zu umfangreich wird.


Dann kommt es an IN/Data ( PB0 bzw. PCINT0 ) zu der steigenden Flanke. Hier wird leider durch dass Schattenmessfenster der Marker für Bit 1 bei +1310µs überblendet, deshalb habe ich dies selbst beschriftet. Der Messwert zeigt 549,375µs an. Die 1,098ms sind der Abstand zu Bit 2.

Die PCI0-ISR habe ich zu Anfang und zu Ende durch zwei Impulse kenntlich gemacht.

Meine ganzen Zeitangaben beziehen sich also auf Messungen im Logic Analyser Programm.

...
Ist der Systemtakt stabil? Ist die Stromversorgung stabil und sauber?

Der µC geht zwischen den Comparematch Interrups immer wieder in den Idle Sleep. Laß ihn doch mal durchlaufen ohne Sleep. Sind die Zeiten dann konstanter?

Die Diskrepanz von 4,8Mhz zu 1,9Mhz ist arg. Vielleicht mal einen neuen µC probieren?

Ok, wird aber dauern bis ich davon berichte.

PS und das auf 0 Setzen des TCNT0 in der Comparematch ISR ist doch eigentlich nicht nötig. Der Timer ist doch auf Comparematch eingestellt. Es reicht das OCR0A beim ersten Mal auf 192 zu stellen und von mir aus jedes Mal. Rücksetzen von TCNT0 an der Stelle verkompliziert die Berechnung, da ja die Zeit von Aufruf der ISR bis Rücksetzten des Timers ja uach noch verrechnet werden muß.

Hatte ich mal gemacht, da aber das Timming wieder nicht stimmte habe ich es wieder reingenommen und die zwei Takte stören bisher auch nicht.
Und wie bereits geschrieben, rechne ich da gar nichts aus, sondern habe die Werte für das OCR0A-Register durch experimentieren gefunden, da sämtliche Rechnungen irgendwie nicht hinhauten.


Bernd_Stein

[Searcher]

Irgendwann wird dann die INT0 Low-Level IRQ erzeugt.
Am Anfang der INT0-ISR wird der erste Impuls mit LED-Gelb erzeugt. Dieser ist 4,958µs lang und entspricht somit einer Frequenz von 403,388kHz, was eigentlich die nominalen 600kHz sind ( 4,958µs:2 wegen sbi, cbi ).

Am Ende der INT0-ISR ist der SYS-Takt ja bereits auf nominal 300kHz umgestellt und somit der 2te Impuls bei LED-Gelb 9,875µs lang, was der wahren Frequenz von 202,532kHz entspricht.

Klingt plausibel. Vielleicht bringt der idle mode meine Rechnung so durcheinander. Damit hab ich kaum Erfahrung. Wer weiß, was der für Zeiten auch beim Aufwachen braucht. Im DB finde ich dazu nicht wirklich was Konkretes. Am Einfachsten mal den Sleep überhaupt nicht verwenden und das Timing (OCR0A Werte) entsprechend anpassen.

Hab sonst keine Idee mehr. In Assembler sollte der Programmablauf schon taktgenau nachvollzogen werden können

Gruß
Searcher

PS: Trotzdem könnte man den Takt nachmessen und mit Oszi schauen, ob er nicht jittert oder schwankt. Hab das kürzlich bei einem Tiny45 über den OC0A gemacht. Man mißt mit folgendem Programm den halben Systemtakt:

Bascom file zum Takt messen. Sollte leicht auf Deine IDE für Tiny13 anpaßbar sein.

$regfile = "attiny45.dat"
$framesize = 10
$swstack = 10
$hwstack = 10
$crystal = 1000000


$asm
  ;OCR0A vom System auf 0
  sbi ddrb , 0            ;PB0 (OC0A) auf Ausgang stellen
  ldi r16 , &B0100_0010   ;COM0A0 (toggle OC0A), WGM01 (CTC mit OCR0A als top)
  out tccr0a , r16        ; ...
  ldi r16 , &b0000_0001   ;CS00 (no Timer prescaling)
  out tccr0b , r16        ;timer0 einschalten
$end Asm

[Bernd_Stein]

Hallo,

möchte nur mal wieder eine kleine Rückmeldung geben, da der Code jetzt geändert wurde und funktioniert. Genaueres werde ich zu einem späteren Zeitpunkt bekannt geben.

Klingt plausibel. Vielleicht bringt der idle mode meine Rechnung so durcheinander. Damit hab ich kaum Erfahrung. Wer weiß, was der für Zeiten auch beim Aufwachen braucht. Im DB finde ich dazu nicht wirklich was Konkretes...

Evtl. habe ich den Grund für die unregelmäßigen Aufrufe der OC0A-ISR gefunden, bin mir aber nicht sicher, da ich dies wiedermal nicht verstehe. Leider ist dieser Teil nicht übersetzt worden und gilt für den ATmega8, was aber nicht das Problem ist ( Siehe dort Systemtakt und Takteinstellungen -> Systemtakt-Vorteiler ) :

https://www-user.tu-chemnitz.de/~heh.../ATmegaX8.chm/

" The ripple counter that implements the prescaler runs at the frequency of the undivided clock, which may be faster than the CPU's clock frequency. Hence, it is not possible to determine the state of the prescaler - even if it were readable, and the exact time it takes to switch from one clock division to the other cannot be exactly predicted. From the time the CLKPS values are written, it takes between T1 + T2 and T1 + 2 * T2 before the new clock frequency is active. In this interval, 2 active clock edges are produced. Here, T1 is the previous clock period, and T2 is the period corresponding to the new prescaler setting. "

" Der Welligkeitszähler, der den Vorteiler implementiert, läuft mit der Frequenz des ungeteilten Takts, die möglicherweise schneller als die Taktfrequenz der CPU ist.
Daher ist es nicht möglich, den Zustand des Vorteilers zu bestimmen - selbst wenn er lesbar wäre, und die genaue Zeit, die zum Umschalten von einer Taktteilung zur
anderen benötigt wird, kann nicht genau vorhergesagt werden. Ab dem Zeitpunkt, an dem die CLKPS-Werte geschrieben werden, dauert es zwischen T1 + T2 und T1 + 2 * T2,
bis die neue Taktfrequenz aktiv ist. In diesem Intervall werden 2 aktive Taktflanken erzeugt. Hier ist T1 die vorherige Taktperiode und T2 die Periode, die der neuen
Prescaler-Einstellung entspricht. "

Ist jetzt aber nicht mehr wichtig, da die Periodendauern der einzelnen Elemente ( 0, 1, f, Sync ) auch nicht konstant sind.
Deshalb war es keine gute Idee immer den gleichen Abstand von Bit zu Bit zu wählen. Hier sieht man dass es bei Bit13 & 19 schon recht knapp wird mit der
Erkennung des richtigen Pegels.

https://www.edv-dompteur.de/forum/in...tachmentID=817

Deshalb habe ich eine neue Strategie ausgearbeitet und bei jeder steigenden Flanke eines Datenelementes einen INT0-IRQ ausgelöst, wo jedesmal der TCNT0 neu geladen wurde.
Beim Testen habe ich festgestellt, dass Taste B+C gleichzeitig gedrückt, den Code der Taste A wiedergibt. Dies sei nur am Rande erwähnt.


Bernd_Stein

[Bernd_Stein]

Ich habe mir überlegt, die Sache hier fortzuführen, da ich dort einfach die visuell besseren Möglichkeiten habe :

https://www.edv-dompteur.de/forum/in...=4200#post4200


Bernd_Stein