PIC Assembler auf- abzählen

Klaus schrieb:
> Irgenwann habe ich aufgehört, mir über sowas Gedanken zu machen, und
>
> myCounter++;
>
> geschrieben.

Richtig, von dem Assembler kriegt man ja Augenkrebs.

Einfach:

1

int main()

2

{

3

  uint8_t val = 0, step = 1;

4

  for(;;){

5

    PORTB = val;

6

    wait();

7

    val += step;

8

    switch( val ){

9

      case 0:

10

      case 255: step = -step;

11

    }

12

  }

13

}

und gut is.

Kann es sein, dass incf das Carry Flag nicht beeinflusst? Probier mal 
statt dem Carry beim hinaufzählen das Zero-Flag zu testen.

Wenn du Eins addierst und du hast einen Überlauf, geht das Register auf 
null.

Ralf G. schrieb:
> Ich bereite einen Kurs für unsere
> Azubis vor, die in der Schule nämlich Assembler programmieren müssen...

Dann bringt es aber nichts, wenn Dir ein anderer den Code schreibt.
Wenn Du anderen Assembler beibringen willst, mußt Du erstmal selber 
Assembler können. Daran führt kein Weg vorbei.
Nichts gegen Dich, aber was ich bisher gesehen habe, sieht eher nach 
Rumraten aus, statt nach Programmieren.

Mir ist da zwischen dem Dekrementieren und der dann eigentlichen Abfrage 
des Zero/Carry Bits

1

  decf  0x20,1    ; -1

2

  movf    0x20,0    ;

3

    movwf    PORTB    ; Ausgeben

4

    call    Wait    ; Warten

5

  btfsc  STATUS,Z    ; Wenn Zero-Bit=0 überspringe nächsten Befehl

einfach zu viel dazwischen. Zumal ich aus dem Bauch heraus das Gefühl 
habe, dass eine Funktion die 'Wait' heisst, ihrerseits sehr 
wahrscheinlich die Prozessorflags Zero bzw. Carry braucht um mittels 
eigener Funktionalität Takte in Schleifen zu vertrödeln.

Eine Gefahr bei Assembler ist es immer, wenn man die Bearbeitung mit dem 
Ziel einer Flag-Beeinflussung und die Auswertung dieser Flags durch 
andere Anweisungen unterbricht. Denn dann muss man von ALLEN Dingen 100% 
exakt und sicher wissen, wie sie sich auf die Flags auswirken. Daher ist 
es oftmals programmiertaktisch besser, diese Dinge beisammen zu lassen. 
Also nicht

     DEkrement
     mach was
     Werte die Flags vom Dekrement aus

sondern

     mach was
     Dekrement
     Werte die Flags vom Dekrement aus

Du willst, dass die beide  Schleifen abwechselnd ausgeführt werde. Also 
musst du sobald eine Schleife fertig ist in die nächste springen.

beim raufzählen z.B.

aufwaerts
incf counter,f
movf counter,w
movwf PORTB
call wait
incfsz counter,w
goto aufwaerts
goto abwaerts

und fürs abwärtszählen ändert sich nicht viel...

Ralf G. schrieb:
> Ich habe momentan die Zeit dazu, und wie du vielleicht merkst,
> beschäftige ich mich ja Intensiv damit. Ich will nicht, dass mir jemand
> nen Programm schreibt, sondern meinen Fehler finden. Genug offtopic.

Dann schnapp dir Papier und Bleistift und spiel COmputer.

Auf deinem Papier schreibst du dir alle Register und deren Werte auf. 
Und auch die ALLER Flags. Wenn du einen Befehl ausführst, dann machst du 
diese Operation auf dem Papier UND du vergisst dabei auch nicht auf die 
Flags! Wenn du dir nicht sicher bist, welche Flags beeinflusst werden, 
dann schau in den Instruction Datenblättern des Herstellers nach.
Und auch wichtig: Du machst nicht das, was du dir denkst das passiert, 
sondern du machst in deiner Papier-Simulation das was im Code steht und 
was in den Instructen Set Datenblättern des Herstellers steht!


Und PS: es hilft bei derartigen Simulation ungemein, wenn man die 
'großen' Zahlen erst mal kleiner macht. Es macht nicht viel Sinn eine 
Schleife 255 mal durchzusimulieren. 4 oder 5 mal tuts auch. 1 mal ist 
hingegen wieder relativ schlecht, denn du solltest mit der Simulation 
schon wenigstens 2 Durchläufe durch eine Schleife machen um alle Effekte 
zu sehen.


Wenn du anderen Assembler beibringen willst, dann musst du intime 
Kenntnisse haben. Und die gibt es nur in den Datenblättern. Dort steht 
exakt bei jedem Befehl drinnen, welche Flags wie verändert werden. Hört 
sich jetzt schlimmer an als es ist, weil Befehle ja in Gruppen/Familien 
auftauchen und normalerweise alle Befehle aus einer Familie sich gleich 
verhalten. Aber anders geht es nicht - wenn du ausbilden willst.

Ralf G. schrieb:
> Wait ist einfach nur eine Warteschleife von 5 ms.

'einfach' ist in Assembler gar nichts.
Verändert 'Wait' die Flags oder tut es das nicht? Das ist die Frage, der 
du dich stellen musst.
Derjenige, der Wait geschrieben hat, kann darauf geachtet haben, da 
nichts zu verändern. Kann ... aber muss nicht. Ergo muss man das 
kontrollieren.

> Diese habe ich erstmal

Mit 'erst mal nur reingemacht' kannst du ein funktionsfähiges 
Assemblerprogramm ganz schnell vom Zustand "geht" in den Zustand "geht 
nicht" überführen, wenn du dir nicht absolut und 100% sicher bist, 
welche Nebenbedingunen bzw. Nebenwirkungen, wie zb die Veränderung von 
Zero/Carry Flag deine Änderung hat.

Ralf G. schrieb:
> btfsc  STATUS,C    ; Wenn Carry-Bit=0 überspringe nächsten Befehl

So wird das nix.

Druck Dir
TABLE 7-2: PIC16CXXX INSTRUCTION SET
aus und lege es Dir auf den Tisch.
Und dann schau nach, welcher Befehl das C setzen kann.
Tip: keiner, den Du bisher verwendest.

Und außerdem hilft Dir das C nicht. Es würde erst gesetzt, wenn Du zu 
weit zählst.

Hallo Ralf,

du fragst ein Status-Flag (ich sge mal nichts dazu ob es das richtige 
ist) zu einem Zeitpunkt ab, wo es nicht den erwarteten Zustand aufweist. 
Die Abfrage eines Status-Flag muss direkt nach dem Befehl erfolgen, der 
es beeinflusst. Einzige Ausnahme sind Befehle, die das jeweilige 
Status-Flag unbeeinflusst lassen. Ich sehe zwar die Implementierung 
deiner 'wait' nicht, weis aber auch so dass darin Operationen vorkommen, 
die auf die Status-Flags wirken. Du musst also umstellen.

Kommst du damit weiter?

Grüße,
Edson

Ralf G. schrieb:
> Das mit den Status abfragen hat nicht geklappt. Habs jetzt mit incfsz
> und decfsz realisiert, nachdem ich mir nochmal die genaue Funktion
> angeschaut habe.

Die Befehle incfsz und decfsz enthalten ebenfalls Abfragen über ein 
Status-Flag, und zwar in beiden Fällen das Zero-Flag.

Semantisch ist

1

   incfsz   0x20, f

2

      goto   anywhere

äquivalent zu

1

   incf   0x20, f

2

   btfss  STATUS, Z

3

      goto   anywhere

Du hast in deinem Code vorhin nicht Z sondern C abgefragt.

D3 ist unterbrochen oder hat Kurzschluß zu VCC/GND.

Er will dir damit sagen, dass du den Schaltplan posten sollst.

Ralf G. schrieb:
> Was soll D3 sein?! Gibts weder beim PIC noch beim DAC

Nicht so verbissen sein, was könnte ich wohl meinen?


Der ADC muß doch mit dem MC verbunden sein (8 Datenleitungen = D7 .. 
D0).

Ralf G. schrieb:
> Ich frage mich jetzt nur, weshalb die "Stufen" so grob sind?

Ich habe etwas Probleme mit der Interpretation des Oszi-Bildes: Die 
einzelnen "Stücke" sind doch schräg und keine Stufen!
Kann es sein, dass du 2-kanalig im Multiplexbetrieb arbeitest, was diese 
Lücken erzeugen kann? Wenn ja, schalte mal auf 1 Kanal oder auf 
"Alternate".
Woher das Doppelbild herkommt, ist auch noch komisch... Es könnte daher 
durchaus ein Messfehler sein.

Gruß Dietrich

Wird das Sägezahn signal bei der selben Schaltung richtig ausgegeben? 
Wenn ja , dann ist es kein oHardware problem

John schrieb:
> So würde es aussehen,

Sehr gut! Das erklärt das Oszi-Bild ja vollständig.
Ich nehme meinen Interpretationsversuch hiermit zurück ...