Warte-Befehl in Assembler?

Also mir ist kein solcher Befehl bekannt. Du kannst entweder den Delay 
Schleifen generator(irgendwo zu downloaden, such in den 
Beiträgen)verwenden oder den Timer. Beides ist ziemlich einfach. Um nur 
schnell etwas mit dem Relais zu machen ist der Schleifengenerator ideal. 
Man kan genau eingeben wie lange gewartet werden soll und der Code wird 
generiert.


Fritz 7

Wenn du während des Wartens was anderes zu tun hast bzw ein Interrput 
oder so ausgelöst werden könnte und die Zeit eher kritisch ist, ist die 
Lösung über den Timer weitaus eleganter als den Prozessor nop'en zu 
lassen, bis die 500ms vorbei sind (denn was anderes zum warten gibts 
eigentlich nicht).

Hi,

danke für den Link. Allerdings geht es da ja meistens um einen 
Generator, der den Code erzeugt (die meistens Links sind defekt). Ist es 
denn wirklich so schwer? Gibt es nicht ein paar gut kommentierte Zeilen, 
daß ich auch weiß, was ich mache?

Kennt noch jemand einen funktionierenden Link zu einem Generator?

Danke!

Sebastian

so als perfektionist: was mache ich denn wenn ich es ganz genau haben 
will? soweit ich das ueberblickt habe, ist in dem generierten code die 
zeit, die die schleifenverwaltung benötigt nicht mit einbezogen. da 
stellt sich natürlich die frage: war ich nur unfähig die anleitung zu 
lesen oder fehlt da eine liste mit der zyklenanzahl, die pro befehl 
benötigt werden?

antworten werden dankbar entgegengenommen...
Holger

Ich denke schon das die Takte für die Sprungbefehle usw mit eingerechnet 
werden. Ansonsten bekommt man ja völlig falsche Werte.
Die Genauigkeit der Zeitmessung hängt auch mit der Taktfrequenz 
zusammen.

> Ich denke schon das die Takte..
Und ich weiß es. (Hab nachgesehen).

> Die Genauigkeit der Zeitmessung hängt auch mit der Taktfrequenz zusammen.
Nein. Vielleicht meinst du die Auflösung - die Genauigkeit jedenfalls 
hängt nicht mit der Taktfrequenz zusammen.

Schmittchen.

jo, jetzt hab ich das auch kapiert, stimmt also wirklich genau. und hab 
auch inzwischen die zyklenanzahlen gefunden... instructions.pdf sei 
dank...

Hi
Also mit den Schleifen beim AVR ist das so eine Sache. Als Beispiel sei 
die RC5 Fernbedienung genannt. Wenn man den Anhang anschaut, so ist das 
eine simpelst Geschichte bei der C-Control von Conrad. Programmiert man 
das Gleiche beim AVR, so erhält man alles, nur keine RC5 Befehle. Wenn 
man sich dann den generierten Code von Compilern (Bascom etc.) oder was 
zu RC5 an Codebeispielen zum AVR anschaut, so stellt man schnell fest, 
dass hier mit ober und unter-limits gearbeitet wird. Warum, wenn die 
Befehle immer die gleiche Zeit benötigen?
Also ich habe meine absoluten Zweifel an Schleifen oder auch Timer 
Routinen beim AVR
Peter

Hi Peter,
ehrlich gesagt versteh ich das nicht so ganz was Du meinst. Wieso soll 
es Probleme geben mit Delays oder Schleifen beim AVR?

Gruß
Markus

Hi Markus
Ich habe jetzt mal das umgeschriebene Prog für AVR angehängt. Ich weis 
zwar nicht mehr, auf welchem Versuchsstand das Prog ist, aber wenn du 
die beiden Progs vergleichst, siehst du, dass sie das gleiche machen. 
Der Unterschied, mal von Kleinigkeiten abgesehen, besteht darin, das 
Prog für C-Control funzt, das Prog für AVR funzt nicht. Ich habe dann 
das Prog für den AVR in alle möglichen Richtungen geändert, um zu 
erfahren, wie lange ein Biphasenslot dauert (mit Schleifen). Es kam nur 
selten der gleiche Schleifenzähler dabei raus. Wenn du dir dann mal die 
funktionierenden Progs für den AVR anschaust, siehst du, dass diese mit 
Zeitunter- und Zeitobergrenzen für einen Biphasenslot arbeiten. Ich habe 
jedenfalls kein funktionierendes RC5 Prog für den AVR gefunden, dass wie 
bei der C-Control mit festen Schleifenzählern läuft.
lg
Peter

Hi Peter,
kenn mich mit RC5 nicht aus. Weiß auch nicht was mit Bipahsenlot gemeint 
ist.
Aber ich sehe trotzdem keinen Grund warum man mit dem AVR keine 
Schleifen oder sowas machen können soll. Vielleicht liegt es einfach 
daran das der AVR um einiges schneller ist als die C-Control und daher 
bestimmte Programmiertechniken, die mit der C-Control noch 
funktionieren, mit dem AVR nicht mehr möglich sind. Deshalb evt die von 
Dir angesprochene Lösung mit den Ober- und Untergrenzen. Vielleicht um 
Signalungenauigkeiten, die die C-Control noch nicht registrieren würde, 
auszugleichen.

Gruß
Markus

> Der Unterschied [...] besteht darin, das Prog für C-Control funzt, das Prog für 
AVR funzt nicht

Aha, und den Grund dafür suchst du dann am AVR? Seltsame Logik.
Im Netz gibts genug RC5-Beispiele für AVRs. Die meisten bauen auf Peter 
Fleurys Implementation auf.
<http://www.mysunrise.ch/users/pfleury/avr-software.html>;

Das Problem bei der Fernbedienungssoftware ist nicht AVR oder RC5, 
sondern daß nicht alle Hersteller sich streng an RC5-Specs halten. 
(Viele Fernbedienungen benutzen auch andere, RC5-inkompatible Protokolle 
- das nur nebenbei). Oftmals wird auch der EmpfägerIC (TSOP17xx) mit der 
falschen Frequenz eingesetzt.

Das gleiche Problem sehe ich übrigens beim Empfang/Auswertung der 
DCF77-Signale. Wirklich idiotensichere AVR-Software dazu gibt es 
nicht... aber auch den AVR als solchen würde ich das nicht schieben.

Schmittchen.

Hi
erklärt mir doch einmal, was an meiner Logik falsch ist. Ein Bit dauert 
Biphasencodiert 1778 us. Bei 8MHz dauert ein Takt 0,000000125 s. 1778us 
= 0,001778 s. 0,001778 / 0,000000125 = 14224. Wenn nun das 
Biphasensignal in 4 Teile zerlegt wird, dann 14224 / 4 = 3556 Takte bis 
zur Abfrage des Pegels. Bei dem AVR vergehen bei mir zwischen 11000 und 
17000 Takten pro Bit. Bei der C-Control ist die Anzahl der Takte immer 
gleich.
Wie gesagt, ich möchte den AVR nicht madig machen. Wenn ich den nicht 
gut finden würde, dann würde ich ihn nicht nutzen. Tue ich aber. Ich 
warne nur vor Schleifenzählern. Möglicherweise treibt der AVR durch INTs 
etc. andere Dinge die Zeit brauchen. Dann ist mein Schleifenzähler 
makulatur.
Was lernt man aus der von Schmittchen angegebenen Referenz?
if ( (timer > RC5BITREF1) && (timer < RC5BITREF2) ) {
        // startbit ok, decode
Nun, es wird ein Zeitslot für die Codierung verwendet, also kein fester 
Zeitwert wie bei der C-Control. Allein die Ermittlung des Zeitslots ist 
fast so aufwendig, wie der gesamte RC5-Code der C-Control. Das heist 
meiner Meinung nach aber nicht, dass die C-Control dem AVR überlegen 
ist.
lg
Peter

Vorweg: Mein "Peter-Fleury-Link" war leider nicht der, den ich zu diesem 
Thema bringen wollte (hab mich in meinen Bookmarks verirrt). Eigentlich 
wollte ich auf Bray verweisen:
http://bray.velenje.cx/avr/
Und der verwendet einen Interrupteingang und den Timerinterrupt zur 
Dekodierung.

> Bei dem AVR vergehen bei mir zwischen 11000 und 17000 Takten pro Bit.
Nein, sondern genau 14224, wie du auch oben ausgerechnet hast (@8MHz). 
Nochmal: 1Bit ist 1778us lang. Bei 8MHz (=125ns) werden genau 14424 
Takte ausgeführt. Das was du beobachtet hast, war wahrscheinlich bei 
einer AVR-RC5-Version, die nicht auf die fallende Flanke des 
IR-Empfängerausgangssignal reagiert. So können in deinem Falle noch alle 
möglichen Interrupts dazwischenkommen bis das Hauptprogramm per Polling 
merkt, daß da was ansteht. Oder je nach Zustand des AVRs/ext.Hardware 
kann die Ausführung einzelner Hauptprogrammteile unterschiedlich viel 
Zeit in Anspruch nehmen. Das kann dann zu den 11000-17000 Takten führen.
Aber das hast du ja schon selbst bemerkt:
> Möglicherweise treibt der AVR durch INTs etc. andere Dinge die Zeit brauchen...

Wie RC5 am besten dekodiert wird, beschreibt Ralf Spettel auf seiner 
Seite sehr anschaulich:
http://www.spettel.de/ralf/index_reload.html?http://www.spettel.de/ralf/projekte/avr_rc5/index.shtml

Zieh dir die Seite mal rein, dann dürften auch deine Bedenken/Probleme 
bzgl. unterschiedlicher Taktzahlen im Prinzip geklärt sein.

> Was lernt man aus der von Schmittchen angegebenen Referenz?
Wie mans besser nicht machen sollte. ;-) oder besser :-(

Können bei der C-Control keine "unvorgesehenen" Dinge (wie z.B. INTs 
oder je nach Situation zeitlich unterschiedlich lange Programmteile) 
auftreten? Das hieße dann ja, daß während RC5 dekodiert wird, nichts 
anderes ausgeführt werden kann?
(Anm.: Ich kenne die C-Control nicht).

Schmittchen.

Hallo Schmittchen
Erst mal danke für die links. ich denke, die sind für alle interessant. 
weiter denke ich, dass wir den disput hier beenden können, denn mit 
deinem satz
>Oder je nach Zustand des AVRs/ext.Hardware kann die Ausführung einzelner 
Hauptprogrammteile unterschiedlich viel Zeit in Anspruch nehmen. Das kann dann zu 
den 11000-17000 Takten führen.
Aber das hast du ja schon selbst bemerkt:<
haben wir ja doch noch einigkeit erzielt. ursprünglich wollte ich ja 
lediglich zur vorsicht bei der verwendung von schleifen mit 
schleifenzählern warnen. die rc5 problematik war nur ein beispiel zur 
verdeutlichung. viele standartroutinen zur zeitvertrödelung benutzen 
aber genau diesen schleifentyp. auch delay.zip auf der homepage von bray 
(http://bray.velenje.cx/avr/) verwendet diesen typ. dein zweiter link 
ist ebenfalls sehr hilfreich in der angelegenheit. er besagt, grob 
vereinfacht, vertraue nicht auf einen zähler, sondern synchronisiere 
dich mit hilfe von steigenden oder fallenden flanken. er weist auch 
darauf hin, dass die methode von bray problematisch sein kann. kann, 
nicht muss.
lg
peter

Hi
Einen kleinen Einwurf habe ich noch. Wiso gibt es keine Idiotensichere 
SW für DCF77, wie meinst du das Schmittchen? Erst solltest du testen und 
dann drüber herfallen.
Schleifen benutze ich übrigens nur um eine min. benötigte Zeit zu 
überbrücken, niemals aber um Zeiten zu messen,(naja fast nie) wozu sind 
denn sonst Timer da.
Gruss Uwe

Hallo Uwe
als ich die implementation der rc5 routine gestartet habe, war ich noch 
neu beim avr. was lag da näher, als mit schleifen zu arbeiten. der timer 
kam erst später. wenn man neu an einem prozessor rangeht, fängt man halt 
mit dem leichten (schleifen) an. wenn das dann schon nicht klappt, naja 
dann kann es sein, dass einem das selbstvertrauen zur 
timerprogrammierung fehlt. ging mir jedenfalls so.
lg
peter

> Wiso gibt es keine Idiotensichere SW für DCF77
Ich schrieb: "Probleme beim Empfang/Auswertung [...]. Idiotensichere 
Software gibts nicht..."
Naturbedingt ist das DCF77-Signal nicht immer frei von Störungen und der 
Empfang ist auch nicht immer perfekt. Wenn man den TTL-Ausgang der 
gängigen DCF-Empfänger betrachtet, so erscheint das eigentlich immer 
sauber. Timingkritisch sollte die DCF-Kodierung im Gegensatz zu RC5 auch 
nicht sein. Dennoch schaffen es die meisten Softwareimplementationen 
nicht daraus die richtige Zeit zu erzeugen. Die meisten im Netz 
verfügbaren Sourcen bauen auf Volker Oths Code auf. Er verzichtet auf 
Plausibilitätsprüfungen, die meiner Meinung nach bei schlechtem Empfang 
wichtig sind. Z.B. wenn eben noch der 25.Aug war, dann kann in 5min 
nicht der 23.Aug sein usw.. Aber dann besteht ja auch das Problem, daß 
man anfangs eine verläßliche Zeit/Datumsangabe braucht, um solche 
Prüfungen durchzuführen.
Zusammenfassend: Das Problem liegt im (teilweise) schlechten Empfang mit 
fehlender Plausibilitätskontrolle. Eine Software, die man irgendwo 
hernimmt, wie sie z.B. auf jeder AVR-Seite für LCDs bereitsteht, gibts 
für DCF77 ((noch)) nicht.

Vom Gegenteil lasse ich mich natürlich gern überzeugen. Ich muß 
allerdings auch dazusagen, daß seit meinen Erfahrungen inzwischen über 
ein Jahr vergangen ist.

Schmittchen.

Hi!
Dann schaue dir bitte "DCF77-Uhr mit LCD" in der Codesammlung an, dann 
reden wir nochmal.
Gruss Uwe

@Uwe: So wie ich deinen Assemblercode lese hast du auch keine 
Plausibilitätsprüfungen integriert (habe den für mich schwer lesbaren 
Ass.Code nur überflogen, falls doch implementiert, bitte nicht schlagen 
:-)). Und das Problem mit der Anfangsuhrzeit bleibt auch bestehen - 
irgendwann braucht man eine Uhrzeit, für die man sicher sein kann, daß 
sie stimmt, sonst sind alle Plausibilitätskontrollen unnütz. Dreimalige 
"gültige", aufeinanderfolgende Uhrzeit könnte dafür reichen. (Bei mir 
dauert das dann ca. 30min - 3h, bis 3x gültige Uhrzeit kommt; mit Volker 
Oths C-Code).

Allgemein: Die Uhrzeit der Uhr per Taster (oder sonstwie) vorsagen, 
finde ich am Ziel einer Funkuhr vorbei.
Ich habe hier auch eine gekaufte fertige Funkuhr (mit Funkthermometer), 
die auch manchmal die falsche Zeit anzeigt. Meist werden die Stunden als 
0 erkannt. Dann ist um 16:54 -> 0:54.
Ich bin hier ca. 150km südwestlich von Frankfurt. Zwischen Frankfurt und 
der Funkuhr (auch dem Modul) stehen noch ein paar Bildschirme und die 
Gebäudeaußenwand - evtl. wirkt sich das auf meinen schlechten Empfang 
aus?

Schmittchen.

Hi
Habe leider momentan etwas wenig Zeit.
Ich mache einen Quersummentest zwischen alter und neuer Zeit. Da sich 
pro Übertragung meistens nur die Minute ändert ist das sehr 
wirkungsvoll.
Will sagen: alte Zeit + 1 mit neue Zeit muss gleich sein, sonst war es 
fehlerhaft. Damit konnte ich bis jetzt alle fehlerhaften Zeichen 
verhindern. Das Ding läuft bei mir als Schaltuhr und da wären falsche 
Zeiten fatal.
Ich mache es noch mal optisch:
12:20 30.8.02 Quersumme = 18+1 = 19
12:21 30.8.02 Quersumme = 19
Wenn das OK ist kann die Zeit synchronisiert werden.
Es wird automatisch ein Fehler bei jedem Übergang der Minutenzehner 
erzeugt (19->20 Q1=3 Q2=2)
Für 1.Synchr.braucht man, wenn Sign.OK 2 Minuten, wenn Sign. Müll halt 
länger. Ich habe schon mal ne 1/2h gewartet.
Wie gesagt die Sache ist sehr sicher.
Gruss Uwe

Hallo Peter
>>daß das AVR-Programm nicht funktioniert liegt bestimmt nicht an >>der 
Delay-Routine sondern daß es eben doch nicht gleich ist.
>>Z.B. ist mir sofort ins Auge gesprungen, daß das SREG nicht >>gesichert wird, es 
ist doch aber ein Interrupt (endet mit RETI).
>>D.h. Dein Hauptprogramm hat eigentlich gar keine andere Chance, >>als gegen den 
Baum zu laufen.
Wie ich schon schrieb, handelt es sich um einen Auszug des Programmes. 
Weiter schrieb ich, dass ich nicht mehr weis, welcher Stand der vielen 
Testversuche es ist. Aber egal. Tatsache ist, dass man mit Zeitschleifen 
über vertrödeln mit "nop" oder ähnliches keine genauen Zeiten hinkriegt. 
Versuche doch mal bitte die Routine von der C-Control in AVR (AT90S*) 
Assembler zu programmieren. Ich wünsche viel Freude.
Weiter mußte ich feststellen, dass auch der Timer nicht besonders genau 
ist. Beispiel:
Die Routine von Volker Oth zum DCF77 Signal prüft bei einem AVR mit 8 
MHz und eingestelltem Teiler von 1024 mit dem Timer 1 und INT1 bei der 0 
auf Timercounter 1 kleiner 1171, bei einer 1 auf kleiner 1953 und beim 
Startbit auf größer 11718. Bei mir wurde gemessen:
Für eine 0 zwischen 600 und 960
Für eine 1 zwischen 1300 und 1600
Für das Startbit 14000 und 15500
also bei zwei Sekunden ungenau auf etwa 200 ms. Bei Zeitkritischen 
Sachen wohl etwas zu ungenau.
Frage mich bitte nicht, woran das liegt. Die Funkuhr von Volker Oth 
funktioniert einwandfrei. Auch bei laufendem PC und laufendem Fernseher. 
Es sollte aber klar sein, dass Zeitschleifen ohne Sync über ein externes 
Signal problematisch sind.
Welchen Grund das hat, ob z.B. die Taktfrequenz des Quarzes schwankt, 
oder bei Schaltvorgängen die Spannung kurz zusammenbricht, oder, oder, 
oder, muß man wohl von Fall zu Fall untersuchen.
lg
Peter

Hallo Peter
warum hat die C-Control die Probleme nicht?
lg
Peter

Hallo Andreas
Ich weis nicht, ob Du mich meinst. Ich habe nicht behauptet, dass die 
Angabe der Anzahl der Takte pro Befehl falsch ist. Ich habe behauptet, 
dass die Ausführung von Schleifen unterschiedlich lange dauern kann. 
Auch der Timer 1 liefert unterschiedlich Timercounts bei der DCF77 Uhr 
von Volker Oth. Ich denke weiter, dass das Thema nun ausgereizt und 
ausdiskutiert ist. Wer glaubt, man könne den Werten trauen, der soll sie 
halt nutzen. Ich jedenfalls traue ihnen nicht mehr von 12:00 bis Mittag. 
Wer meint ich wäre im Unrecht, naja der soll mir eine funktionierende 
Umsetzung der C-Control Routine zeigen. Die ist wie gesagt winzig und 
funktioniert. Alle RC5 Programme des AVR sind wahre Monster im Vergleich 
dazu. Wenn ich so im unrecht bin, warum sind die Programme für den AVR 
so riesig? Warum arbeiten sie mit Bereichswerten und nicht mit starrem 
Schleifenzähler, meinetwegen auch festen Timercounts? Ich habe technisch 
nicht die Möglichkeit zu prüfen, was denn nun zu den Unterschieden 
führt. Ich denke aber mal, wenn ein und derselbe RC5 Empfänger an der 
C-Control feste Zeiten pro Bit hat und beim AVR nicht, wenn die Zeiten 
bei der DCF77 Uhr dermaßen schwanken, dann liegt für mich die Ursache 
eindeutig beim AVR. Wenn man dies berücksichtigt, dann kann man denke 
ich mit dem AVR alles machen. Die C-Control hat bei weitem nicht die 
Leistungsfähigkeit des AVR. In Assembler geschriebene Programme dürfen 
nur einige wenige Byte groß werden. Der Basic Interpreter ist extrem 
fehlerhaft, und, und, und.
lg
Peter

Hallo Andreas
Leider war nur der Int0 für die RC5 aktiv. Somit schwer erklärbar. Bei 
der DCF77 war nur INT 1 aktiv und an dem hing die DCF77. Wie gesagt, mir 
fehlen die technischen Möglichkeiten, um abzuklären, was die 
unterschiedlichen Timercounts/Zeitschleifen erklärt. Ich denke, ich habe 
sogar Ints abgeklemmt, gepollt und trotzdem keine korrekte Erkennung der 
RC5 mit Zeitschleifen hinbekommen. Aber egal, die AVR's sind super und 
ich bleibe dabei. Probleme sind keine mehr, wenn man sie als Problem 
erkannt hat und einen Ausweg dafür gefunden hat. Dies ist sowohl bei RC5 
als auch mit DCF77 gelungen. Man verwendet eben Zeitbereiche. Auch wenn 
das vielleicht für einen Perfektionisten nicht optimal erscheint, mir 
reicht es, wenn es funktioniert. Ich muß nicht für alles eine hieb und 
stichfeste Erklärung haben. Wenn mir einer eine gibt, super, wenn nicht, 
na dann eben klapt oder klapt nicht. Wenns klapt, bin ich zufrieden.
lg
Peter

Hallo Peter
damit wären wir ja mal wieder einig. Ein Zeitfenster muß her. Feste 
Werte klappen nicht. Mit Routinen, die beim AVR Zeitfenster verwenden, 
kannst Du die Strasse pflastern. Es ist mir aber kein Programm bekannt, 
welches mit festen Werten (ob über Schleifen oder über Timercounter) 
realisiert wurde.
lg
Peter

Och Peter
guck mal richtig hin.
>>;--------------------------------------------------------------------- --------
>>; Warteroutine fuer 1/4 eine Biphasenbits = 444us = 444T bei 12Mhz
>>;                       ;Aufrufcall  2T
>>w444    lda #147     ; 3
>>loop    deca          ; 3  A -1
>>        bne loop     ; 3  6*0,5µs = 3µs/Schleife
>>  rts
Ich übersetze es Dir aber gerne.
w444 = Label
lda #147 = lade Akkumulator decimal 147
loop = label
deca = akkumulator --
bne loop = wenn akkumulator > 0 dann springe zum Label loop
rts = return subroutine

Wo ist das Zeitfenster?
Hier nochmal das Prog der C-Control


; RC5-Unterprogramm   RC5.ASm
; nach einer Vorlage von Olaf Kaluza

PC  .equ $01
Cnt .equ $0A3
Kon .equ $0A4
Adr .equ $0A5
Tas .equ $0A6

        .org $101
        Clr Kon
        Clr Adr
        Clr Tas
        brset 0,PC,rc6
rc5     brset 0,PC,rc5  ;Warten auf Startbit
        jsr w444        ;warten
        brset 0,PC,rc5  ;Stoerimpuls
        jsr w444  ;Naechsten Biphasenpegel
        jsr w444
        brclr 0,PC,rc5  ;Stoerimpuls
        jsr w444
        jsr w444
        brset 0,PC,rc5  ;Stoerimpuls
        jsr w444        ;Ok weiter
        jsr w444        ;Kontrollbit einlesen
        jsr getbit      ;Kontrollbit hier im Carry
        rol Kon
        ldx #5        ;5 Adressbits
rcadr   jsr w444
        jsr w444
        jsr getbit
   rol Adr    ;Bit merken
  dex
        bne rcadr
        ldx #6       ;6 Datenbits
rcdat   jsr w444
        jsr w444
        jsr getbit
        rol Tas         ;merken
        dex
        bne rcdat
rc6     rts                     ;Zurueck zum Hauptprogramm
;----------------------------------------------------------------------- 
------
;Einlesen eines Bits, Rueckgabe in Carry
getbit  lda  #255 ;Timeout festlegen
        sta  Cnt
        brset 0,PC,gethi  ;Wird es ein Lowbit?
gbl1    brset 0,PC,gbl2   ;Auf Biphasensprung syncronisieren
        dec Cnt
        bne gbl1
        bra biterr        ;Timeout
gbl2    jsr w444
        brclr 0,PC,biterr  ;Fehler
        clc                ;Lowbit
        rts
gethi   brclr 0,PC,gethi2   ;auf Phasensprung syncronisieren
        dec Cnt
        bne gethi
        bra biterr          ;Timeout
gethi2   jsr w444
        brset 0,PC,biterr ;Fehler?
        sec                ;Highbit
        rts
biterr  Clr Kon       ;Fehler, alles löschen
  clr Adr
   clr Tas
        clr Cnt
  rts

;----------------------------------------------------------------------- 
------
; Warteroutine fuer 1/4 eine Biphasenbits = 444us = 444T bei 12Mhz
;                       ;Aufrufcall  2T
w444    lda #147     ; 3
loop    deca          ; 3  A -1
        bne loop     ; 3  6*0,5µs = 3µs/Schleife
  rts

         .END
Mann, wenn Du meinst, in der Proc getbit wird ein Zeitfenster abgefragt, 
i9rrst Du. Es wird lediglich abgefragt, ob eine Störung auf der Leitung 
war. Wie gesagt, nicht reden machen. Bitte mach das doch bitte im AVR 
eins zu eins. Sind doch nur ein paar Befehle. Solltest Du Fragen zu 
einem Befehl haben, ich sage Dir gerne was welcher Befehl macht.
lg Peter

Hallo Peter
wo liegt das Problem? Machs doch genau so im AVR. Und damit soll es nun 
auch genug sein. Ich weis nicht, vielleicht drücke ich mich 
unverständlich aus. Mach  es  genau  so  wie  bei  der C-Control.  Wenn 
es  dann  funktioniert,  dann  gebe  ich  mich geschlagen.
lg
Peter

Lieber Peter
ich habe das C-Control Programm erst exakt, dann in ich weis nicht wie 
vielen Variationen umgesetzt. Es klapt eben nicht. Die Diskusion geht 
langsam in eine Richtung, die keinen Erfolg verspricht.
Also, wenn du eine exakte Umsetzung des Programmes für den AVR hast, und 
nicht etwas mit Zeitfenstern oder ähnliches, dann bin ich der Erste, der 
zugibt, dass ich im Unrecht bin.
Solange ich das nicht sehe, sage ich:
1. Delays über Zeitschleifen mit festem Schleifenzähler kannst Du 
vergessen. Dies wird auch unisono in den diversen Foren bestätigt. Lies 
Dir vielleicht noch mal die Beiträge durch.
2. Auch mit dem Timercounter ist Vorsicht geboten. Auch dies wird in 
anderen Foren bestätigt.
3. Ich sage nicht, woran das liegt, denn das weis ich nicht. Es gibt 
eine Reihe von Möglichkeiten woran es liegen könnte. Auch diese sind in 
den Beiträgen zu Warte-Befehl in Assembler aufgeführt.
lg Peter

Langsam wird die Diskussion hier etwas diffus. Am Ende weiss wohl keiner 
mehr wie die Timer und Interrupts bei der AVR Familie wirklich 
funtionieren. Ich möchte
an dieser Stelle nur folgendes anmerken sowohl mit
reinen Zählschleifen als auch mit Timer-gesteuerten
Routine sind auf 1clk genaue Delays möglich es kommt
immer auf die Programmstruktur an.

Wenn dem so wäre, dass ich beim Timer gesteuerten Delay immer mit einem 
Jitter leben müßte, hätte ich
den Einsatz Einsatz von AVR Prozessoren längst be-
endet bzw. hätte die Prozessorarchitektur nicht richtig verstanden.

Also ich nicht. Der Unterschied zwischen den Aus-
führungszeiten 1/2 Takte ist ja sehr gering und in
einer Interruptroutine sehr leicht ausgleichbar.
Ohne Prescaler ist auch das manuelle Reload ohne Jitter möglich. Da ich 
ja immer eine genaue Kontrolle
über jeden einzelnen Taktimpuls habe. Etwas komplexer
werden die Korrekturen bei eingeschaltetem Prescaler.
Bei den neueren AVRs der MEGA-Familie hat Atmel zusätzlich die 
Möglichkeit eines Prescaler Reset spen-
diert, welchses die Programmierung an dieser Stelle
erheblich vereinfacht.

Ohne Prescaler und ohne weitere aktive Interrupts sorgt dieser 
Kunstgriff für einen Ausgleich der 2
unterschiedlich Befehlslängen. Allerdings sind die
Möglichkeiten wie zusätzliche WAIT-States bei externem Speicher (ist mir 
sowie zu langsam und maximal 4K
internes SRAM dürften wohl in jedem Fall reichen) nicht berücksichtigt.

in  R16,TCNTx(L)   ;R16 = aktueller Wert Timer 0,1,2
sbrc R16,0         ;Bit0 = 0 -> jump = 2 Takte sonst
                   ;no JUMP = 1 Takt
sbrs R16,0         ;immer 2 Takte


Bei aktivem Prescaler ist die Sache mit der taktge-
nauen Synchronisation etwas aufwendiger, da ja hier
keinerlei Möglichkeit besteht, den Zählerstand des
Prescalers auszulesen.

Hi!
gerade mit Prescalers geht es am besten. bei zb.einem Prescalers von 
1024 hast du genau 1024 Takte Zeit um dich um den Timerwert zu kümmern 
ohne das Verfälschungen auftreten.
Gruss Uwe

Wenn der Wert des Timer-Register TCNTx von Bedeutung ist, hast du recht. 
Wenn du aber z.B. ein Rechteck mit exaktem 50/50 Tastverhältnis an einem 
Port via Timer-Interrupt erzeugen willst und z.B. noch Interrupts vom 
UART und SPI autreten, wird's bei aktivem Prescaler richtig schwierig 
dieses zu realisieren, da man ja mit unterschiedlichen Response-Zeiten 
beim Timer-Interrupt rechnen muß.

Hallo,

wow was für thread !
ich fand es hochspannend die Beiträge zu verfolgen

eine Frage:

könnte von euch jemand die DCF-Decodierroutine
so in assembler schreiben das man sie in ein
Bascom-Basicprogramm einbinden kann?

Es gibt allerding einige Dinge die man dabei beachten
muß

Die Hilfebeschreibung dazu weiter unten

eine andere Möglichkeit wäre das Assemblerprogramm
einmal ausführlich zu kommentieren so das man es auch
als Basic/Turbo-Pascal-Programmierer versteht.

Dann könnte ich etwas äquivalentes in Basic programmieren oder wäre der 
Basic-code nicht schnell
genug?

Vielen Dank schon im Voraus

viele herzliche Grüße

Stefan


Mixing ASM and BASIC

BASCOM allows you to mix BASIC with assembly.
This can be very useful in some situations when you need full control of 
the generated code.

Almost all assembly mnemonics are recognized by the compiler. The 
exceptions are : SUB, SWAP,CALL and OUT. These are BASIC reserved words 
and have priority over the ASM mnemonics. To use these mnemonics precede 
them with the ! - sign.
For example :

Dim a As Byte At &H60  'A is stored at location &H60
Ldi R27 , $00      'Load R27 with MSB of address

Ldi R26 , $60      'Load R26 with LSB of address
Ld R1, X      'load memory location $60 into R1
!SWAP R1      'swap nibbles

As you can see the SWAP mnemonic is preceded by a ! sign.

Another option is to use the assembler block directives:
$ASM
  Ldi R27 , $00      'Load R27 with MSB of address
  Ldi R26 , $60      'Load R26 with LSB of address
  Ld R1, X        'load memory location $60 into R1
  SWAP R1      'swap nibbles
$END ASM


A special assembler helper function is provided to load the address into 
the register X or Z. Y can may not be used because it is used as the 
soft stack pointer.


Dim A As Byte    'reserve space
LOADADR a, X    'load address of variable named A into register pair X

This has the same effect as :
Ldi R26 , $60  'for example !
Ldi R27, $00   'for example !

Some registers are used by BASCOM
R4 and R5 are used to point to the stack frame or the temp data storage
R6 is used to store some bit variables:
  R6 bit 0 = flag for integer/word conversion
  R6 bit 1 = temp bit space used for swapping bits
  R6 bit 2 = error bit (ERR variable)

  R6 bit 3 = show/noshow flag when using INPUT statement
R8 and R9 are used as a data pointer for the READ statement.

All other registers are used depending on the used statements.

To Load the address of a variable you must enclose them in brackets.
Dim B As Bit

Lds R16, {B}  'will replace {B} with the address of variable B

To refer to the bitnumber you must precede the variable name by BIT.
Sbrs R16 , BIT.B   'notice the point!
Since this was the first dimensioned bit the bit number is 7. Bits are 
stored in bytes and the first dimensioned bit goes in the LS bit.

To load an address of a label you must use :
LDI ZL,  Low(lbl * 1)
LDI ZH , High(lbl * 1)
Where ZL = R30 and may be R24, R26, R28 or R30
And ZH = R31 and may be R25, R27, R29 or R31.

These are so called register pairs that form a pointer.

When you want to use the LPM instruction to retrieve data you must 
multiply the address with 2 since the AVR object code consist of words.
LDI ZL,  Low(lbl * 2)
LDI ZH , High(lbl * 2)
LPM ; get data into R0
Lbl:

Atmel mnemonics must be used to program in assembly.
You can download the pdf from www.atmel.com that shows how the different 
mnemonics are used.
Some points of attention :
* All instructions that use a constant as a parameter only work on the 
upper 16 registers (r16-r31)

So LDI R15,12  WILL NOT WORK

* The instruction SBR register, K
will work with K from 0-255. So you can set multiple bits!

The instruction SBI port, K  will work with K from 0-7 and will set only 
ONE bit in a IO-port register.

The same applies to the CBR and CBI instructions.

You can use constants too:
             .equ myval = (10+2)/4
              ldi r24,myval+2    '5
              ldi r24,asc("A")+1  ; load with 66

Or in BASIC with CONST :

CONST   Myval  = (10+2) / 4

Ldi r24,myval

How to make your own libraries and call them from BASIC?
The files for this sample can be found as libdemo.bas in the SAMPLES dir 
and as mylib.lib  in the LIB dir.

First determine the used parameters and their type.
Also consider if they are passed by reference or by value

For example the sub test has two parameters:
 x which is passed by value (copy of the variable)
 y which is passed by reference(address of the variable)


In both cases the address of the variable is put on the soft stack which 
is
 indexed by the Y pointer.

The first parameter (or a copy) is put on the soft stack first
To refer to the address you must use:
    ldd r26 , y + 0
    ldd r27 , y + 1
This loads the address into pointer X


The second parameter will also be put on the soft stack so :
The reference for the x variable will be changed :

To refer to the address of x you must use:
   ldd r26 , y + 2

   ldd r27 , y + 3


To refer to the last parameter y you must use
   ldd r26 , y + 0
   ldd r27 , y + 1


Write the sub routine as you are used too but include the name within 
brackets []

[test]
test:
  ldd r26,y+2   ; load address of x
  ldd r27,y+3
  ld r24,x         ; get value into r24
  inc r24          ; value + 1
  st x,r24         ; put back
  ldd r26,y+0  ; address of y
  ldd r27,y+1
  st x,r24         ; store
  ret                 ; ready

[end]


To write a function goes the same way.
A function returns a result so a function has one additional parameter.
It is generated automatic and it has the name of the function.
This way you can assign the result to the function name
For example:

Declare Function Test(byval x as byte , y as byte) as byte
A virtual variable will be created with the name of the function in this 
case test.
It will be pushed on the softstack with the Y-pointer.

To reference to the result or name of the function (test) the address 
will be:
   y + 0 and y + 1
The first variable x will bring that to y + 2 and y + 3
And the third variable will cause that 3 parameters are saved on the 
soft stack
To reference to test you must use :
   ldd r26 , y + 4
   ldd r27 , y + 5

To reference to x
   ldd r26 , y + 2
   ldd r27 , y + 3
And to reference y
  ldd r26 , y + 0
  ldd r27 , y + 1


When you use exit sub or exit function you also need to provide an 
additional label.  It starts with sub_ and must be completed with the 
function / sub routine name.  In our example:

sub_test:


When you use local variables thing become more complicated.
Each local variable address will be put on the soft stack too
When you use 1 local variable its address will become
   ldd r26,  y+0
   ldd r27 , y + 1
All other parameters must be increased with 2 so the reference to y 
variable changes  from
  ldd r26 , y + 0 to ldd r26 , y + 2
  ldd r27 , y + 1 to ldd r27 , y + 3
And of course also for the other variables.

When you have more local variables just add 2 for each.

Finally you save the file as a .lib file
Use the library manager to compile it into the lbx format.
The declare sub / function must be in the program where you use the sub 
/ function.

The following is a copy of the libdemo.bas file :

'define the used library
$lib "mylib.lib"

'also define the used routines
$external Test

'this is needed so the parameters will be placed correct on the stack
Declare Sub Test(byval X As Byte , Y As Byte)


'reserve some space

Dim Z As Byte


'call our own sub routine
Call Test(1 , Z)

'z will be 2 in the used example
End

When you use ports in your library you must use .equ to specify the 
address:
.equ EEDR=$1d
In R24, EEDR

This way the library manager know the address of the port during compile 
time.

As an alternative precede the mnemonic with a * so the code will  not be 
compiled into the lib. The address of the register will be resolved at 
un time in that case.


This chapter is not intended to learn you ASM programming. But when you 
find a topic is missing to interface BASCOM with ASM send me an email.

Dem kann ich nur zustimmen. Zumal es sich hier um Auszüge aus einem 
Handbuch handelt, würde ein entsprechender Link ausreichen. Auf der 
BASCOM Hompage
findet sich übrigens auch ein entsprechendes DEMO-Programm zur DCF77 
Decodierung in BASIC