- Willkommen im Forum „PIC-Microcontroller“.
...
Autor picass
- 28.10.2022, 10:29:43 CESTNachfolgendes sieht nach einer veritablen Unhöflichkeit oder gar Provokation aus. Ist aber nur der Anschein:
Ich werde auch deinen gerade formulierten Hinweis nicht aufgreifen. Jedenfalls nicht jetzt. Sitze wirklich total in einer Zeitklemme drin, es sind zu viele Jobs, die ich auf einmal erledigen müsste. Und z.Z. sitzt mir auch meine Frau im Nacken, die - leider zu Recht - anmahnt, dass etliches Zugesagtes immer noch nicht erledigt wäre.
Die Gemengelage mit dem Rechenfehler möchte ich einfach noch mal komplett von vorne aufrollen, auch, weil ich natürlich darin interessiert bin, zumindest dicht an so was wie die "Wahrheit" ran zu kommen. Es gibt immerhin schon den dezenten Hinweis, dass die Funktion des Carry-Flags von mir nicht genau erfasst wurde. Aber jetzt kommen erst mal andere Projekte dran, z.B. mein Regenerations-Anzeiger, danach die Garagentor-Steuerung. Dann kommt Urlaub, dann.....
Ein offenes Wort noch: es würde mich freuen, wenn es uns gelingen würde, ein weitgehend friedliches Miteinander bewahren zu können.
Grüße, picass
Ich werde auch deinen gerade formulierten Hinweis nicht aufgreifen. Jedenfalls nicht jetzt. Sitze wirklich total in einer Zeitklemme drin, es sind zu viele Jobs, die ich auf einmal erledigen müsste. Und z.Z. sitzt mir auch meine Frau im Nacken, die - leider zu Recht - anmahnt, dass etliches Zugesagtes immer noch nicht erledigt wäre.
Die Gemengelage mit dem Rechenfehler möchte ich einfach noch mal komplett von vorne aufrollen, auch, weil ich natürlich darin interessiert bin, zumindest dicht an so was wie die "Wahrheit" ran zu kommen. Es gibt immerhin schon den dezenten Hinweis, dass die Funktion des Carry-Flags von mir nicht genau erfasst wurde. Aber jetzt kommen erst mal andere Projekte dran, z.B. mein Regenerations-Anzeiger, danach die Garagentor-Steuerung. Dann kommt Urlaub, dann.....
Ein offenes Wort noch: es würde mich freuen, wenn es uns gelingen würde, ein weitgehend friedliches Miteinander bewahren zu können.
Grüße, picass
Autor vloki
- 27.10.2022, 13:24:00 CESTetwas 
-toppic, aber mit Bezug zu einem Beitrag von mir weiter oben:
Zufällig bin ich in einem anderen Forum auf deine Anfrage bzgl. MPASM - PIC_AS gestoßen
und dadurch auf die Lösung meines Problems mit der Anzeige der Variablen im Debugger gekommen.
Die Variablen müssen dafür beim PIC-AS als "global" deklariert sein.
Wird auch im MPLAB_XC8_PIC_Assembler_User_Guide_for_Embedded_Engineers.pdf irgendwo erwähnt
-toppic, aber mit Bezug zu einem Beitrag von mir weiter oben:Zufällig bin ich in einem anderen Forum auf deine Anfrage bzgl. MPASM - PIC_AS gestoßen
und dadurch auf die Lösung meines Problems mit der Anzeige der Variablen im Debugger gekommen.
Die Variablen müssen dafür beim PIC-AS als "global" deklariert sein.
Wird auch im MPLAB_XC8_PIC_Assembler_User_Guide_for_Embedded_Engineers.pdf irgendwo erwähnt
Autor picass
- 27.10.2022, 10:31:24 CESTWiderspruch auf allen Ebenen wie es scheint. Ich halte mich aber an mein Wort und lege diese Angelegenheit auf Eis. Viel.... viel zu viel Zeit ist bislang dafür geopfert worden und meine anderen, wichtigen Projekte lagen da auf Eis. Die müssen aber dringend weiter geführt werden und denen wird meine Aufmerksamkeit nun gelten. Mag sein, dass diese Angelegenheit hier auch noch mal aufgegriffen wird für eine Überprüfung. Aber nun gibt's Eis. Das könnte auch zur Abkühlung evtl. angeheizter Atmosphäre dienen.
Grüße, picass
Grüße, picass
Autor vloki
- 24.10.2022, 19:06:50 CESTZitat von: picass in 24.10.2022, 17:24:36 CESTIch werde die fruchtlose Debatte hier beenden.Gut
Zitat von: picass in 24.10.2022, 17:24:36 CESTAnhand von Beispielen konnte nachgewiesen werden...Nö
Zitat von: picass in 24.10.2022, 17:24:36 CESTDiese Fehlverhalten – oder wie man das auch immer benennen mag – sind System-FehlerWelche? (nein, bitte nicht antworten;-))
Zitat von: picass in 24.10.2022, 17:24:36 CESTDas sind Beweise genug.Ich habe keinen einzigen gesehen
Zitat von: picass in 24.10.2022, 17:24:36 CESTJeder, welcher über die programm-technischen Voraussetzungen verfügt, kann die einfachen Beispiele auf seinem Computer nach vollziehen...... und wird keinerlei Systemfehler finden
Autor picass
- 24.10.2022, 17:24:36 CESTIch werde die fruchtlose Debatte hier beenden. Es konnte aufgezeigt werden, dass in dem Problem-/Spannungsfeld von Assembler-Programmierung in der MPLAB X IDE-Umgebung (bis Vers. 5.35) logische Fehlentscheidungen und auch Rechenfehler stattfinden.
Anhand von Beispielen konnte nachgewiesen werden, dass nach Subtraktionen mal weder ein Negativ- noch ein Carry-Flag gesetzt wurde, und ebenso das Gegenteil, dass danach gleichzeitig ein N- und ein C-Flag gesetzt wurden. Beides steht für einen Fehler. Ebenfalls gab es Beispiele von Subtraktionen, in denen schlichtweg ein echter Rechenfehler auftrat.
Diese Fehlverhalten – oder wie man das auch immer benennen mag – sind System-Fehler. Die gezeigten Rechenfehler finden sich nicht nur in meinem Beispiel wieder, sondern auch in Muster-Rechenentwürfen namhafter Autoren, hier gezeigt am Beispiel im Buch ,,Mit dem PIC-Controller erfolgreich arbeiten" von Dr. Anne König und Manfred König, erschienen im Verlag Markt@Technik, Auflage 1996, Seite 398. Das exakt gleiche Programmbeispiel inclusiv des Rechenfehlers (bis auf unwesentliche Bezeichner-/Variablen-Namen Änderungen) findet sich bei SPRUT, und alles geht auch auf Beispiele von Microchip zurück.
Das sind Beweise genug. Für Lern- und Akzeptanz-Unwillige werde ich nun aus grundsätzlichen Erwägungen heraus keine Zeit mehr investieren. Mag sein, dass es nicht jedem gegeben ist, zwischen dem Problem und der Problembeseitung einen Trennstrich zu ziehen. Mir ging es in diesem Fred alleine um die Darstellung des Problems, rsp. den Hinweis darauf.
Jeder, welcher über die programm-technischen Voraussetzungen verfügt, kann die einfachen Beispiele auf seinem Computer nach vollziehen. Damit ist für mich hier Schluss. Ich beende meine Beiträge und bin stolz auf meine Entdeckung. Der Fred erhält von mir das vom Forum zur Verfügung gestellte Merkmal: gelöst. Wer sich an dem anderen Problemfeld, der Vermeidung dieser Rechenfehler – z.B. durch Umgehungsstrategien – engagieren möchte, darf und sollte das in einem eigenen Fred tun und kann sicher sein, dafür auch Anerkennung zu finden.
Grüße, picass
Anhand von Beispielen konnte nachgewiesen werden, dass nach Subtraktionen mal weder ein Negativ- noch ein Carry-Flag gesetzt wurde, und ebenso das Gegenteil, dass danach gleichzeitig ein N- und ein C-Flag gesetzt wurden. Beides steht für einen Fehler. Ebenfalls gab es Beispiele von Subtraktionen, in denen schlichtweg ein echter Rechenfehler auftrat.
Diese Fehlverhalten – oder wie man das auch immer benennen mag – sind System-Fehler. Die gezeigten Rechenfehler finden sich nicht nur in meinem Beispiel wieder, sondern auch in Muster-Rechenentwürfen namhafter Autoren, hier gezeigt am Beispiel im Buch ,,Mit dem PIC-Controller erfolgreich arbeiten" von Dr. Anne König und Manfred König, erschienen im Verlag Markt@Technik, Auflage 1996, Seite 398. Das exakt gleiche Programmbeispiel inclusiv des Rechenfehlers (bis auf unwesentliche Bezeichner-/Variablen-Namen Änderungen) findet sich bei SPRUT, und alles geht auch auf Beispiele von Microchip zurück.
Das sind Beweise genug. Für Lern- und Akzeptanz-Unwillige werde ich nun aus grundsätzlichen Erwägungen heraus keine Zeit mehr investieren. Mag sein, dass es nicht jedem gegeben ist, zwischen dem Problem und der Problembeseitung einen Trennstrich zu ziehen. Mir ging es in diesem Fred alleine um die Darstellung des Problems, rsp. den Hinweis darauf.
Jeder, welcher über die programm-technischen Voraussetzungen verfügt, kann die einfachen Beispiele auf seinem Computer nach vollziehen. Damit ist für mich hier Schluss. Ich beende meine Beiträge und bin stolz auf meine Entdeckung. Der Fred erhält von mir das vom Forum zur Verfügung gestellte Merkmal: gelöst. Wer sich an dem anderen Problemfeld, der Vermeidung dieser Rechenfehler – z.B. durch Umgehungsstrategien – engagieren möchte, darf und sollte das in einem eigenen Fred tun und kann sicher sein, dafür auch Anerkennung zu finden.
Grüße, picass
Autor vloki
- 22.10.2022, 13:39:47 CESTZitat von: picass in 21.10.2022, 17:42:46 CESTDazu gibt es mindestens zwei Ansätze, die beide auf eine Vermeidungs-Taktik raus laufen. Man kann schlicht die Sprungbefehle, welche das N-Flag nutzen, vermeiden
Man könnte auch einfach akzeptieren, wozu CARRY, /BORROW und NEGATiV Flags benutzt werden und sich nicht versuchen raus zu reden. Es gibt keine Schwäche des 2er Komplements und dein Problem existiert schlicht nicht.
Autor picass
- 21.10.2022, 17:42:46 CESTEs gab diverse Gründe, warum ich mich erst jetzt wieder einschalte: zum Einen kam ein anderes, für mich wichtigeres Projekt (keine µC-Anwendung) unangemeldet dazwischen, zum Anderen war das Rechenproblem bereits von mir gelöst worden– siehe oben. Leicht tragisch empfinde ich den Verlauf dieses Freds. Da haben wir offenkundig zuletzt prima aneinander vorbei geredet.
Mir ging es in diesem Fred darum, eine Schwäche des ,,Zweier-Komplent-Rechnens" aufzuzeigen, nicht mehr, aber ganz sicher auch nicht weniger. Etwas unglücklich widersprachst du, Volker, und schobst das auf vermeintliche Fehler in meinem Programm. Danach bemühtest du dich, das Programm so umzuschreiben, dass es ohne Fehler auflaufen konnte. Da hattest du dir ordentlich Mühe gegeben, dafür auch ein herzliches Danke. Aber mehr hätte ich mich gefreut, wenn du meine Darstellung der erkannten Schwäche anerkannt hättest. Das Programm zum sauberen Laufen zu bekommen, war mir ja selbst schon gelungen.
Dazu gibt es mindestens zwei Ansätze, die beide auf eine Vermeidungs-Taktik raus laufen. Man kann schlicht die Sprungbefehle, welche das N-Flag nutzen, vermeiden und stattdessen das C-Flag für Verzweigungen nutzen. Oder man vermeidet überhaupt eine ,,echte" Subtraktion und setzt auf einfachen Überlauf, das Abfragen des C-Flags und damit auf den ,,bit-test-und-Sprung-wenn"-Befehl, so wie du es in deinen beiden letzten Prog-Vorschlägen ausgeführt hattest. Wobei es genau genommen um andere Sprungbefehle geht, statt bra also bit-test.
Mein ganzes µC-Bemühen liegt seit einigen Tagen brach, weil anderes erledigt werden musste. In den nächsten Tagen versuche ich, weiter zu kommen.
Grüße, picass
Mir ging es in diesem Fred darum, eine Schwäche des ,,Zweier-Komplent-Rechnens" aufzuzeigen, nicht mehr, aber ganz sicher auch nicht weniger. Etwas unglücklich widersprachst du, Volker, und schobst das auf vermeintliche Fehler in meinem Programm. Danach bemühtest du dich, das Programm so umzuschreiben, dass es ohne Fehler auflaufen konnte. Da hattest du dir ordentlich Mühe gegeben, dafür auch ein herzliches Danke. Aber mehr hätte ich mich gefreut, wenn du meine Darstellung der erkannten Schwäche anerkannt hättest. Das Programm zum sauberen Laufen zu bekommen, war mir ja selbst schon gelungen.
Dazu gibt es mindestens zwei Ansätze, die beide auf eine Vermeidungs-Taktik raus laufen. Man kann schlicht die Sprungbefehle, welche das N-Flag nutzen, vermeiden und stattdessen das C-Flag für Verzweigungen nutzen. Oder man vermeidet überhaupt eine ,,echte" Subtraktion und setzt auf einfachen Überlauf, das Abfragen des C-Flags und damit auf den ,,bit-test-und-Sprung-wenn"-Befehl, so wie du es in deinen beiden letzten Prog-Vorschlägen ausgeführt hattest. Wobei es genau genommen um andere Sprungbefehle geht, statt bra also bit-test.
Mein ganzes µC-Bemühen liegt seit einigen Tagen brach, weil anderes erledigt werden musste. In den nächsten Tagen versuche ich, weiter zu kommen.
Grüße, picass
Autor vloki
- 14.10.2022, 12:41:27 CESTSo, weil ich gerade mal wieder mein Script überarbeite und den Assemblerteil an den Assembler vom XC8 anpassen möchte, habe ich das mal mit diesem kleinen Progrämmchen versucht. Leider ist es mir nicht gelungen, die Variablen im Debugger anzeigen zu lassen (IDE v6.00, XC8 v2.30). Hoffentlich wird das noch verbessert 
Trotzdem hänge ich das mal hier an.
Kommentare habe ich etwas angepasst und den einen Bit-test-skip Befehl in einen Branch abgeändert, weil evtl. nicht offensichtlich ist, warum das Überspringen des Inkrement für den sich ja darauf beziehenden nachfolgenden Branch hier kein Problem darstellt.
Unten noch das Variablenfenster mit Anzeige der Werte durch Eingabe der Adressen...
Trotzdem hänge ich das mal hier an.
Kommentare habe ich etwas angepasst und den einen Bit-test-skip Befehl in einen Branch abgeändert, weil evtl. nicht offensichtlich ist, warum das Überspringen des Inkrement für den sich ja darauf beziehenden nachfolgenden Branch hier kein Problem darstellt.
Code Auswählen
#include <xc.inc>
PSECT udata_acs
adcL: DS 1 ;variable für daten aus analog-eingang
adcH: DS 1
hunderter: DS 1 ; für decode
zehner: DS 1
einer: DS 1 ; auch fuer temp!
PSECT resetVec,class=CODE,reloc=2
resetVec:
goto main
PSECT code
main:
movlw 00000010B ;set cpu clock speed of 31KHz
movwf OSCCON,A ;move contents of working register into OSCCON
clrf OSCTUNE,A ;
clrf LATA,A
clrf TRISA,A ;port a ausgang
clrf LATB,A ;
clrf TRISB,A ;port b ausgang
clrf LATC,A ;
clrf TRISC,A ;port c Configure as output
; für rechenprobe adc füllen (mit irgendwas)
_MainLoop:
nop ;adc = wert nach auslesen des analogen eingangs
movlw 0x67 ;adcL
movwf adcL,A ;
movlw 0x02 ;adcH
movwf adcH,A
call indezimal ;zerlegen in hunderter, zehner, einer
bra _MainLoop ;zurück zum anfang
indezimal: ;adc wert in dezimalstellen
; - analogmesswert in adcL & adcH
; - d'100' oder d'10' in WREG
;-------------------
_hun: ;hunderter stelle ermitteln
clrf hunderter,A
_hunLoop: ;
movff adcL,einer ;sichern u wiederherstellen,wenn negativ war
movlw 100 ;WREG mit h'64' = d'100' füllen
subwf adcL,F,A ;ergebnis wieder in adcL
bc _hunInc ;wenn ergebnis positiv, hundert++
decf adcH,A ; sonst adcH--
bnc _hunEnd ;wenn adcH negativ wird, ab zu zehner und einer
_hunInc:
incf hunderter,A ;ist noch hunderter
bra _hunLoop ; weiter hunderter zählen
_hunEnd: ;ausgang: hunderter in hunderter, rest in einer (temp)
movff einer,adcL ;erst adcL wiederherstellen einer (temp) -> adcL
clrf adcH,A ; das aber auch !!!
;----------------
_zehn: ;eingang: zehner und einer
clrf zehner,A
_zehnLoop:
movff adcL,einer ;sichern u wiederherstellen,wenn negativ war
movlw 10 ;wieviel zehner stecken in adcL ?
subwf adcL,F,A ;minus zehn, der rest in adcL
btfss CARRY ;keiner Zehner mehr?
return ; fertig - Einer sind schon in einer!
incf zehner,A ; sonst zehner++
bra _zehnLoop ; und weiter zehner zaehlen
END
Unten noch das Variablenfenster mit Anzeige der Werte durch Eingabe der Adressen...
Autor vloki
- 11.10.2022, 09:29:56 CESTPS: die Kommentare sollte man evtl. noch überarbeiten.
(Da stehen noch einige Altlasten)
Noch ein beispielhafter Screenshot vom Watches Fenster:
(Da stehen noch einige Altlasten)
Noch ein beispielhafter Screenshot vom Watches Fenster:
Autor vloki
- 11.10.2022, 09:21:41 CESTZitat von: picass in 10.10.2022, 18:43:15 CESTIn der Subraktionsschleife hattest du was Schlimm-Verbessert, indem die Bearbeitung des High-Bytes übersehen wurde.Nö, Tausender berechnest du ja auch nicht. Das passt so ;-)
Ok, ich habe das ganze nochmal ein bisschen ausgemistet,
um für mich persönlich die Übersichtlichkeit zu erhöhen:
Code Auswählen
...
indezimal: ;adc minus bit
; - analogmeßwert in adcL & adcH
; - d'100' oder d'10' in bitl & bith
; für rechenprobe adc füllen mit h'0118' = d'280'
movlw h'67' ;adcL
movwf adcL ;
movlw h'02' ;adcH
movwf adcH
nop
;-------------------
_hun: ;adc minus bit, ergebnis wieder in adc
clrf hundert
_hunLoop: ;
movff adcL,einer ;sichern u wiederherstellen,wenn negativ war
movlw D'100' ;bitl & bith mit h'64' = d'100' füllen
; call subtract ;adc minus bit
subwf adcL,F,A ;ergebnis wieder in adcL
btfss STATUS,C ;ergebnis positiv, dann dec überspringen
decf adcH
bnc _hunEnd ;wenn negativ, ab zu zehner
incf hundert ;ist noch hunderter
bra _hunLoop ;weiter hunderter zählen
_hunEnd: ;ausgang:hunderter in hundert,zehnerrest in temp
movff einer,adcL ;erst adcL wiederherstellen temp,adcL
clrf adcH ; das aber auch !!!
;----------------
_zehn: ;eingang: zehner u einer
clrf zehner
_zehnLoop:
movff adcL,einer ;vorsorglich umspeichern in einer
movlw D'10' ;wieviel zehner stecken in adcL ?
subwf adcL,F,A ;minus zehn, der rest in adcL
; bnc _zehnEnd ;keiner zehner mehr,ab zum einer-zählen
btfss STATUS,C
return
incf zehner ;ist noch zehner
bra _zehnLoop ;weiter zehner zählen
end