Zeitverzögerung beim PIC16F84A

[Marcel H. (marcel_2004)]

Moin, sitze gerade vor einem PIC16F84A welcher mit Assembler 
programmiert werden soll. Nun ist die Aufgabe mit dem RISC Befehlssatz 
eine Funktion zu schreiben in welcher eine Verzögerung von etwa 1s 
vorkommen soll. Bin allerdings etwas aufgeschmissen und weiß nicht genau 
wie ich die Verzögerung von etwa 1s hinbekomme.
Vielleicht kann mir ja jemand einen Denkanstoß oder ähnliches geben!
Danke im vor raus!

[STK500-Besitzer (Gast)]

Marcel H. schrieb:
> Bin allerdings etwas aufgeschmissen und weiß nicht genau
> wie ich die Verzögerung von etwa 1s hinbekomme.

Du weißt die Taktfrequenz deines PIC?
Dann bastelst du dir Zählschleifen, die den Controller für eine Sekunde 
blockieren.
Um auf die "genaue" Zeit zu kommen, musst du natürlich wissen, wie lang 
jeder Befehl deiner Schleifen braucht.

Oder du nimmst eine Kamera, die auf eine Uhr (mit Sekundenzeiger) guckt, 
die dann meldet, dass der Sekundenzeiger sich bewegt hat.

[Teo D. (teoderix)]

Entweder stupide ne For-Schleife mit NOP(s) oder den Timer benutzen um 
damit ne Var hoch|runter zählen.

[Peter D. (peda)]

Für so extrem lange Zeiten nimmt man einen Timerinterrupt, z.B. alle 
1ms.
Darin zählt man dann eine Variable runter und wenn sie 0 erreicht, führt 
man einen Callback aus oder setzt ein Flag, was dann in der Mainloop die 
Aktion ausführt.
Demm in real will man nicht, daß so lange die CPU überhaupt nichts 
macht, sondern weiterhin andere Aufgaben bearbeitet.

Eine elegante Lösung ist auch ein Scheduler, in den man z.B. bis zu 10 
verzögerte Aufgaben reinstellen kann und der sie dann einmalig oder 
zyklisch aufruft. Den Scheduler schreibt man natürlich in C, in 
Assembler wird das zu unübersichtlich.

[Teo D. (teoderix)]

Peter D. schrieb:
> Den Scheduler schreibt man natürlich in C, in
> Assembler wird das zu unübersichtlich.

Wie so sollte das?
Ist doch nur ne Liste von Calls.

[Peter D. (peda)]

Teo D. schrieb:
> Wie so sollte das?
> Ist doch nur ne Liste von Calls.

Assembler kennt keine Variablentypen und erst recht keine Structs und 
Arrays. Die ganzen Indirectionen, Pointer und Displacements zu Fuß zu 
berechnen, ist nur was für extreme Masochisten.

typedef void (*funcp)(void);
typedef uint16_t t_res;

typedef struct
{
  uint8_t next;                                         // next in list or end mark
  t_res delta;                                          // delta to previous entry
  t_res period;
  funcp func;
} t_ctrl_struct;

static t_ctrl_struct t_ctrl_lst[MAX_SCHEDULE];
static t_res t_delay;                                   // count down until next service
static uint8_t t_first;                                 // point to first entry

[STK500-Besitzer (Gast)]

Peter D. schrieb:
> Denn in real will man nicht, dass so lange die CPU überhaupt nichts
> macht, sondern weiterhin andere Aufgaben bearbeitet.

Die Aufgabe klingt nach einer Grundlagenveranstaltung der 
Mikrocontroller-Programmierung (zumindest kenne ich das sowohl aus der 
Ausbildung, als auch aus dem FH-Studium).
Dabei geht es darum, die Zählparameter einer Warteschleife zu bestimmen, 
wenn man die Taktanzahl der benötigten Befehle kennt.

Natürlich kann man es anders machen, aber jemand, der nicht mal solchen 
Pippifax hinbekommt, soll einen Scheduler programmieren / verwenden?

[Teo D. (teoderix)]

Peter D. schrieb:
> Assembler kennt keine Variablentypen und erst recht keine Structs und
> Arrays.

Du denkst zu komplex.
Mann muss nicht gleich einen ganzen Walt planen, wenn man nur ne 
Verkehrsinsel begrünen will.

[Peter D. (peda)]

Teo D. schrieb:
> Du denkst zu komplex.

War jetzt auch nur mal als Ausblick gedacht, wenn man erfahrener ist. Ab 
der 2. Zeitaufgabe geht es mit dem Scheduler einfacher.

Ein Timerinterrupt hat den Vorteil, daß man die Dauer direkt einstellen 
kann und nicht umständlich Befehlszyklen abzählen muß. Man kann also das 
Programm leicht erweitern, ohne daß sich die Zeiten durch die 
zusätzlichen Befehle verlängern.

[Peter D. (peda)]

Als ich 1990 mit dem 8051 angefangen habe, habe ich sehr schnell schon 
die Timer benutzt.
Ich war einfach zu faul, Befehle abzählen zu müssen, denn dabei kann man 
sich auch schnell verzählen und die Zeiten stimmen nicht.

[STK500-Besitzer (Gast)]

Peter D. schrieb:
> Als ich 1990 mit dem 8051 angefangen habe, habe ich sehr schnell schon
> die Timer benutzt.
> Ich war einfach zu faul, Befehle abzählen zu müssen, denn dabei kann man
> sich auch schnell verzählen und die Zeiten stimmen nicht.

Timer erfordern i.d.R. auch Interrupts. Die werden vielleicht noch 
später im Unterricht behandelt.

[Teo D. (teoderix)]

Peter D. schrieb:
> Teo D. schrieb:
>> Du denkst zu komplex.
>
> War jetzt auch nur mal als Ausblick gedacht, wenn man erfahrener ist. Ab
> der 2. Zeitaufgabe geht es mit dem Scheduler einfacher.

Tja, rein aus Forentradition, sollten wir uns jetzt drei Tage und 
Nächte, die Köppe darüber einhauen, was denn nu genau als "Scheduler" 
gelten darf und ob das ab dem 2. oder 5. Slot sinnvoller ist... ;D

[W.S. (Gast)]

Peter D. schrieb:
> War jetzt auch nur mal als Ausblick gedacht, wenn man erfahrener ist.

Nein, mein Lieber. Deine Ratschläge setzen nicht nur einen C-Compiler 
voraus, sondern auch noch genügend Platz im Zielcontroller. Bedenke mal, 
daß recht viele PIC16 mit 2K an Befehlsworten auskommen müssen und 
obendrein auch nur rund 200 Byte an RAM zur Verfügung haben (wenn man 
mal durchscheinende RAM-Bereiche und Register abzieht). Und da fängst du 
großspurig an von Zeugs zu schreiben, was definitiv zu fett ist für die 
Zielhardware. Ein Scheduler in C, und als nächstes kommt ein voll 
ausgebautes printf und eine Weile später ein komplettes Linux mit 
grafischer Oberfläche?

Man sollte ein bissel auf dem Teppich bleiben. Ich erinnere mich da an 
einen Jung-Ex-Kollegen, der bei einem kleinen PIC10 im SOT23 Gehäuse und 
nur maximal 512 Befehlsworten meinte, er wüßte keinen Grund, solche 
Winzlinge NICHT in C zu programmieren. Nun ja, manche Leute brauchen 
unbedingt einen V6, um beim Bäcker um die Ecke ihre Frühstücks-Semmel zu 
holen.

Und hier ein kleines Beispiel, wie man sowas in etwa machen kann:

; Quarzfrequenz= 20 MHz
; 1 ms = 5000 Befehlstakte (etwa 256 * 19.5)
; 1 Befehlstakt = 200 ns

; so etwa 1 ms warten
Wait_1: MOVLW  2

; W mal so etwa ne halbe ms warten  (W=0 --> 128 ms)
Wait:  MOVWF   Hudl
       MOVLW   0
                         ; Taktverbrauch
_wzy:  NOP               ; 1
       NOP               ; 2
       CLRWDT            ; 3
       NOP               ; 4
       NOP               ; 5
       ADDLW   1         ; 6
       SKIP    Z         ; 7
       GOTO    _wzy      ; 8+9
       DECFSZ  Hudl,F
       GOTO    _wzy
       RETURN

W.S.

[Peter D. (peda)]

W.S. schrieb:
> Man sollte ein bissel auf dem Teppich bleiben.

Man kann auch mit 2kB Flash ne ganze Menge machen, z.B. float habe ich 
auch auf dem AT89C2051 benutzt, braucht 1kB Flash.
Atmel hat aber auch die kleinen 8Pinner gut ausgerüstet, z.B. ATtiny85: 
8kB Flash, 512B RAM.

Mit PIC kenne ich mich nicht aus.
Ich hab hier noch ein Delaymacro für den 8051 gefunden:

mdelay  macro value, rx, ry     ;cycle, used register(s)
          local m____1
          if( value < 5 )
            rept value
              nop
            endm
          elseif( value < 515 )
              mov rx, #low((value-1)/2)
              djnz rx, $
            if((value and 1) = 0)
              nop
            endif
          else
              mov rx, #high(value/2+253)
              mov ry, #low(value/2-2)
m____1:       djnz ry, m____1
              djnz rx, m____1
            if(value and 1)
              nop
            endif
          endif
        endm

0..4 Zyklen werden mit NOP gemacht, 5..514 Zyklen mit einem DJNZ und 
515..65535 Zyklen mit 2 DJNZ.
Der alte A51 Assembler kann leider nur 16Bit rechnen.

[Mario M. (thelonging)]

http://www.onlinepiccompiler.com/delayGeneratorENG.php

[H. H. (Gast)]

W.S. schrieb:
> Bedenke mal,
> daß recht viele PIC16 mit 2K an Befehlsworten auskommen müssen und
> obendrein auch nur rund 200 Byte an RAM zur Verfügung haben (wenn man
> mal durchscheinende RAM-Bereiche und Register abzieht).

Der 16F84A hat nur 1K Befehlsworte und 68 Bytes RAM.

[Jan (Gast)]

W.S. schrieb:
> Ich erinnere mich da an einen Jung-Ex-Kollegen, der bei einem kleinen
> PIC10 im SOT23 Gehäuse und nur maximal 512 Befehlsworten meinte, er
> wüßte keinen Grund, solche Winzlinge NICHT in C zu programmieren.

Recht hatte er.

[W.S. (Gast)]

H. H. schrieb:
> Der 16F84A hat nur 1K Befehlsworte und 68 Bytes RAM.
Ist eben noch enger als ich so allgemein geschrieben habe.


Jan schrieb:
> Recht hatte er.
Damit daß er es nicht weiß. Tja, das isses wohl.


Peter D. schrieb:
> Man kann auch mit 2kB Flash ne ganze Menge machen, z.B. float habe ich
> auch auf dem AT89C2051 benutzt,
Benutzt. Hmm. Für die PIC16 hatte ich die GK-Arithmetik selber 
geschrieben. Sowohl für 4 Byte GK als auch eine Variante mit 5 Byte. 
Damit die Mantisse groß genug ist, um das auch im Frequenzzähler 
benutzen zu können.

Ansonsten weiß ich, was man alles in Assembler hinkriegt, auch wenn man 
keine Riesenvorräte an RAM+Flash hat. Alles andere sind die leider 
vielgehörten Ausreden von C-Programmierern, die nur vertuschen wollen, 
daß sie es eben nicht können.

W.S.

[Teo D. (teoderix)]

H. H. schrieb:
> Der 16F84A hat nur 1K Befehlsworte und 68 Bytes RAM.

Ich hab ne kleine Dosierpumpe gebaut, wo ein 16F84 (ohne A!:) mit C 
vergewaltigt wurde und da sollte man solche "Klimmzüge" nur in 
homöopathischen Dosen anwenden.
Man muss da auch nicht wirklich geizig mit den Ressourcen sein, aber 
wenn der "Jagdinstinkt" einmal geweckt ist... :D

Hab kürzlich erst ein neues Update gemacht.
Eigentlich wollte ich ja nur "Globale Dosis-Ende Tasten-Sperre" 
einfügen....
/*
48 byte RAM; 864 Words
Globale Dosis-Ende Tasten-Sperre hinzugefügt (+10 Words)
Buzzer Init Macro, auf Funtion Aufruf geändert (-5 Words)
Buzzer(void) ohne Parameter, buzzer Struct auf Global geändert (-16 
Words)
Buzzer_Init() an_1bit Parameter raus geworfen (-16 Words)
 * Geplant
 * 20 Byte RAM noch frei -> Strucht Bitfeld (wieder) auf Char umstellen 
-> weniger Code?
 * ERLEDIGT 49 Bayte RAM; 858 Words (-6 Words)
 */

Nicht geplant
Auf Assembler umschreiben (-650 Words erwartet) :D

[MaWin (Gast)]

Peter D. schrieb:
> Als ich 1990 mit dem 8051 angefangen habe, habe ich sehr schnell
> schon die Timer benutzt.
> Ich war einfach zu faul, Befehle abzählen zu müssen, denn dabei kann man
> sich auch schnell verzählen und die Zeiten stimmen nicht.

Na ja, man kann auch erst mal eine Schleife bis 100000 zählen lassen, 
abstoppen und dann korrigiert man diesen Wert damit 1 Sekunde bei 
rauskommt.

Man kann auch lernen wie die Inder
https://youtu.be/k_S2gRkUVn8

[Teo D. (teoderix)]

MaWin schrieb:
> Na ja, man kann auch erst mal eine Schleife bis 100000 zählen lassen,
> abstoppen und dann korrigiert man diesen Wert damit 1 Sekunde bei
> rauskommt.

Wenns wirklich auf ne "genaue" Sekunde ankommt, ist ne Delay-Schleife eh 
zu ~100% der falsche Weg.

[Peter D. (peda)]

MaWin schrieb:
> Na ja, man kann auch erst mal eine Schleife bis 100000 zählen lassen,
> abstoppen und dann korrigiert man diesen Wert damit 1 Sekunde bei
> rauskommt.

Das ist mit Abstand das umständlichste, was ich je gehört habe. Gerade 
mit ineinander verschachtelten Schleifen wird man damit kaum einen 
minimalen Restfehler erzielen.

[Georg (Gast)]

Peter D. schrieb:
> Der alte A51 Assembler kann leider nur 16Bit rechnen.

Das ist doch kein reales Hindernis - man kann auch mit einem 
4bit-Prozessor 10stellige Dezimalzahlen verarbeiten, das konnten schon 
die ersten Taschenrechner. Zählen ist noch einfacher, gibt es einen 
Überlauf zählt man die nächsthöhere Stelle um 1 hoch, usw.

Am Assembler liegt es nicht wenn man das nicht hinbekommt.

Georg

[Jens M. (schuchkleisser)]

Ich hab das immer so gemacht:

Einfache Schleife

Delay
  movlw  n
  movwf  d1
Delay_0
  decfsz  d1, f
  goto  Delay_0
  return

Dauert (n-1)*3 + 2 Zyklen, plus 2 (init) plus 4 (call/return) Zyklen.
Benötigt eine RAM-Adresse d1.

Doppelte Schleife

Delay
  movlw  n1
  movwf  d1
  movlw  n2
  movwf  d2
Delay_0
  decfsz  d1, f
  goto  $+2
  decfsz  d2, f
  goto  Delay_0
  return

Dauert ((n1-1)*5) + ((n2-1)*1280) + 4, plus 4 (init) plus 4 
(call/return) Zyklen.
Damit kommt man schonmal etwas weiter, braucht dafür 2 Bytes RAM.

Dreifache Schleife

Delay
  movlw  n1
  movwf  d1
  movlw  n2
  movwf  d2
  movlw  n3
  movwf  d3
Delay_0
  decfsz  d1, f
  goto  $+2
  decfsz  d2, f
  goto  $+2
  decfsz  d3, f
  goto  Delay_0
  return

Dauert ((n1-1)*7) + ((n2-1)*1792) + ((n3-1)*458752) + 6, plus 6 (init) 
plus 4 (call/return) Zyklen.
Braucht 3 Bytes RAM.

Natürlich kann man alle 3 Versionen auch "inline" benutzen, dann 
entfällt halt das return und die jeweils 4 Zyklen fehlen.
Und: es geht auch, nur eine Schleife "Delay_0" zu nutzen, aber mehrere 
Initialisierungsteile mit verschiedenen Werten, da muss man dann aber 
noch jeweils ein goto einrechnen (2 Zyklen).

Sehr kurze Verzögerungen kann man mit nop (1 Zyklus) oder goto $+1 (2 
Zyklen) machen.

Bei 4MHz Quarz-Takt ist ein Zyklus = 1 µs, auch ein gern genommenes 
Verständnisproblem beim PIC.

[Peter D. (peda)]

Georg schrieb:
> Das ist doch kein reales Hindernis

Dann erzähle mir mal, wie ich dem Delay-Macro den Wert 65537 übergebe, 
wenn der Assembler nur 16-bittig rechnet.

[Teo D. (teoderix)]

Peter D. schrieb:
> Georg schrieb:
>> Das ist doch kein reales Hindernis
>
> Dann erzähle mir mal, wie ich dem Delay-Macro den Wert 65537 übergebe,
> wenn der Assembler nur 16-bittig rechnet.

Na so wie alle das machen. Man kann halt nur einen gewissen Bereich 
abdecken und für jeden gibts halt dann ein eigens Macro.

[Peter D. (peda)]

Teo D. schrieb:
> Na so wie alle das machen. Man kann halt nur einen gewissen Bereich
> abdecken und für jeden gibts halt dann ein eigens Macro.

Man kann sich aber auch die Hose mit der Kneifzange anziehen.

Der AVR-Assembler rechnet intern 64-bittig, d.h. selbst ein Delay von 
24h läßt man ihn bequem selber ausrechnen:

.nolist
.include "tn12def.inc"

        .equ    F_CPU = 1200000       ; 1.2MHz

        .equ    zeit1 = 10            ; 10s
        .equ    zeit2 = 60 * 60 * 24  ; 24h

#define byte5(x)  byte4(x / 256)

.macro  warte
        ldi     r16, byte1( @0 / 7 )
        ldi     r17, byte2( @0 / 7 )
        ldi     r18, byte3( @0 / 7 )
        ldi     r19, byte4( @0 / 7 )
        ldi     r20, byte5( @0 / 7 )
_warte11:
        subi    r16, byte1(1)         ; 1 Zyklus
        sbci    r17, byte2(1)         ; 1 Zyklus
        sbci    r18, byte3(1)         ; 1 Zyklus
        sbci    r19, byte4(1)         ; 1 Zyklus
        sbci    r20, byte5(1)         ; 1 Zyklus
        brne    _warte11              ; 2 Zyklen
                                      ; = 7 Zyklen
.endmacro
.list
.listmac

main:
        sbi     ddrb, pb1
        sbi     portb, pb1
        warte   F_CPU * zeit1         ; 10s
        cbi     portb, pb1
        warte   F_CPU * zeit2         ; 1d
        rjmp    main

Beitrag "Re: 24h Schalter mit Attiny 12"

[Teo D. (teoderix)]

Peter D. schrieb:
> Dann erzähle mir mal, wie ich dem Delay-Macro den Wert 65537 übergebe,
> wenn der Assembler nur 16-bittig rechnet.

Peter D. schrieb:
> Der AVR-Assembler rechnet intern 64-bittig, d.h. selbst ein Delay von
> 24h läßt man ihn bequem selber ausrechnen: .....

Wenn dir langweilig ist, such die einen interessanteren Job!

[Martin (Gast)]

Bei Sprut findest Du Beispiele für Warteschleifen in Assembler, einfach 
etwas weiter runterblättern:

https://www.sprut.de/electronic/pic/programm/lauflicht/lauflich.htm

So ähnlich habe ich das bereits für Projekte genutzt.

Der PIC wartet dann natürlich einfach dumm und ist blockiert für weitere 
Aufgaben. Anders ginge es via Interrupt ähnlich dem millis() Befehl bei 
Arduino.

[Daniel (Gast)]

Alter Falter, wer programmiert noch Assembler? Nimm MPLAB IDE und dir 
gehts deutlich besser, glaub mir !

[W.S. (Gast)]

Daniel schrieb:
> Alter Falter, wer programmiert noch Assembler? Nimm MPLAB IDE und dir
> gehts deutlich besser, glaub mir !

Alter Falter, wer kaut noch selber sein täglich Brot? Nimm lieber fertig 
gekauten Instant-Brei und dir gehts deutlich besser, glaub mir !

W.S.

[Hans Werner Schuster (Gast)]

Was soll das mit dem Taktzahlgefummel? Für sowas nimmt man nen Timer.