Neueste Beiträge

#1
V
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von vloki - Heute um 20:15:55 CEST
Zitat von: picass am 02.10.2022, 18:23:43 CESTIch gehe davon aus, dass nicht der PIC18F14K22 einen in Hardware gegossenen Flag-, rsp. Rechenfehler aufweist, sondern dass dieser auf der Softwareseite zu finden ist. Das hast du ja auch schon selbst indirekt bestätigt, indem du mir geraten hattest, eine andere Software zu verwenden, nämlich eine Hochsprache.
Es gibt weder Rechenfehler in der Hardware noch der Software und die Hochsprache hatte ich empfohlen, weil ich davon ausgehe, dass die Programmierer der Compiler die Geschichte mit den Flags so gut im Griff haben, dass korrekte Berechnungen durchgeführt werden ;-)
#2
P
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von picass - 02.10.2022, 18:23:43 CEST
Hallo Volker!
Deine Einlassungen stimmen so nicht. Wenn man davon ausgeht, dass die  Rechenfehler, rsp. die Rechenprobleme nicht in beiden Bestandteilen, hier auf der einen Seite der µC und auf der anderen Seite die ,,Software" – egal, welcher Art sie auch ausgestaltet ist, rsp. wie sie benannt wird  - liegt, dann muss man schon deutlich auf eine der beiden möglichen Seiten zeigen.

Ich gehe davon aus, dass nicht der PIC18F14K22 einen in Hardware gegossenen Flag-, rsp. Rechenfehler aufweist, sondern dass dieser auf der Softwareseite zu finden ist. Das hast du ja auch schon selbst indirekt bestätigt, indem du mir geraten hattest, eine andere Software zu verwenden, nämlich eine Hochsprache.

Also dann doch ganz klar: das Problem liegt – wie ich es wiederholt beschrieben hatte – bei den Mängeln, rsp. der Unzulänglichkeit, rsp. der Unzuverlässigkeit der IDE und des MPLAB. Diese beiden Komponenten fasse ich mal unter dem Oberbegriff ,,Software" zusammen, auch wenn das etwas unscharf ist, weil auch noch das davon erzeugte Programm mit dazu gehört, aber egal: diese beiden Komponenten sind es, welche die Probleme ursächlich erzeugen.

Leider magst du meine Beispiele nicht beachten, z.B. das mit der Unzuverlässigkeit auch des C-Flags, rsp. versuchst sie umzudeuten in sowas wie persönliches falsches Verhalten. Aber nein: nicht ich rechne mit negativen Zahlen, diese Zahlen sind ja nur willkürliche Beispiele für eine einzelne Rechenaufgabe, welche sich aus dem Einlesen und Verarbeiten der 10Bit des Analogwandlers ergeben. Das hat mit einzelnen Personen nun wirklich gar nichts zu tun.

Wenn man sich bei Assemblieren nun aber weder auf das N- noch auf das Carry-Flag verlassen kann, dann ist das aus meiner Sicht eine Bankrotterklärung für dieses System. Klar, man kann die von einem Negativ-Flag geforderte, aber nicht geleistete Funktion ersetzen, indem man – wie ich dargestellt hatte – zu Compare-Befehlen (CB) greift. Wenn man aber nun auch noch Konstruktionen für das Ersetzen des unzuverlässigen C-Flags erstellen muss, wird das System irgendwie unbrauchbar, rsp. eine Zumutung. Das Gestrampel mit dem Ersetzen des C-Flags habe ich auch geschafft, ebenfalls mit CB, aber das generiert und summiert dann doch zu einer abstrusen Einschränkung der Handelbarkeit des Assemblers.

Eine solche Einschränkung hätte selbstverständlich entsprechende deutliche Hinweise in den technischen Unterlagen nach sich ziehen müssen. Kleinste, geschickt verborgene und noch kryptische Einsilbrigkeit kann nicht akzeptiert werden. Mit diesen Einschränkungen kann man leben, aber das befreit sie nicht vom Makel.
Grüße, picass
#3
V
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von vloki - 30.09.2022, 12:31:22 CEST
Zitat von: picass am 30.09.2022, 10:34:16 CESTWenn der Subtrahend größer ist als der Minuend, was ja nun wirklich nicht als ,,Spezial-Fall" deklariert werden sollte, dann muss ein Übertrag erfolgen, rsp. dem Subtrahend eine ,,Eins" abgezogen werden. Dafür braucht es ein Flag. Zwei stehen zur Verfügung und beide sind unzuverlässig.

Ach so, bei der Subtraktion ist das "Carry" ja ein "/Borrow".
Also muss auf "0" verglichen werden. (bnc negativ)
#4
V
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von vloki - 30.09.2022, 11:47:24 CEST
Zitat von: picass am 30.09.2022, 10:34:16 CESTEine Frage wäre es, ob in den neueren Versionen der MPLAB-Umgebung dieses Prob beseitigt wäre.
Nochmal - die IDE und der Assembler haben mit deinem Problem absolut nichts zu tun.
Die sind nicht in der Lage die Hardware nach deinem Geschmack zurecht zu biegen!
#5
P
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von picass - 30.09.2022, 10:51:55 CEST
Schade, die Nachbearbeitungszeit war schon rum.

Kann sein, dass ich mich wie weiland Münchhausen gerade am eigenen Haarschopf aus dem Sumpf ziehe, denn ich habe gerade in die PIC-Bibel geschaut, also in das Datenblatt. Und da gibt es sowas wie die "compare"-Befehle. Die benötigen selbst kein Flag und erzeugen auch keines. Wenn die gleich stattfindenden Test das verifizieren sollten, was da versprochen wird, dann wäre das die Lösung.
Grüße, picass
#6
P
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von picass - 30.09.2022, 10:34:16 CEST
Zitat von: vloki am 30.09.2022, 09:36:55 CESTPasst alles.
Nichts passt, siehe nachfolgendes Beispiel.
Die Croux beginnt bei so was scheinbar Simplem wie einer 16-bit-Subtraktion. Wenn der Subtrahend größer ist als der Minuend, was ja nun wirklich nicht als ,,Spezial-Fall" deklariert werden sollte, dann muss ein Übertrag erfolgen, rsp. dem Subtrahend eine ,,Eins" abgezogen werden. Dafür braucht es ein Flag. Zwei stehen zur Verfügung und beide sind unzuverlässig. Ende der Erklärung und dafür die Bankrott-Erklärung der Subtraktion beim PIC unter den genannten Bedingungen – Assembl. und X IDE. Da sollte man nicht drum rum reden und da helfen auch keine Grundrechen-Beispiele, die keinen Bezug zur Realität dieser Problematik haben.

Wenn an einem analogen Eingang tatsächlich die Werte von 0 bis max. 10 bit vorkommen, dann kann nicht ernsthaft erwartet werden, dass man diesen Wertebereich in 8-bit-Dekaden zerlegt und die dann nochmal in zwei 128-bit-Bereiche und die Eingangswerte auf die entsprechenden Zugehörigkeiten abklopft. Das ist einfach Murks, wenn die Programmiersprache da kein verlässliches Arbeiten zulässt und dieser Murks sollte auch als Murks benannt werden.

Jetzt verstehe ich im Nachhinein auch, warum ich beim Ausbaldowern solcher Prog-Beispiele anderer Autoren ins Stolpern und Grübeln kam, warum das manchmal einfach nicht klappen wollte. Auch die weiter oben genannten beiden promovierten Autoren, die beiden Könige, sind in diese Falle getappt, ohne auch nur im Ansatz dieses Problem genannt und noch viel weniger, einen Ausweg aufgezeigt zu haben. Es war mir früher schon aufgefallen, dass deren Beispiele zu Rechenfehlern führten, ohne allerdings die Ursache gekannt zu haben.

Da bin ich nun echt ratlos, wie es weiter gehen soll, wenn niemand in der Lage ist, eine praktisch umzusetzende Hilfe zu geben. Das Assemblern möchte ich ungerne aufgeben. Es gibt Programme, die in diversen Steuerungen laufen und für die einfach Service in dieser Sprache bereit stehen muss.
Eine Frage wäre es, ob in den neueren Versionen der MPLAB-Umgebung dieses Prob beseitigt wäre.
Grüße, picass
#7
V
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von vloki - 30.09.2022, 09:36:55 CEST
Na ja, wenn du schon mit negativen Zahlen rechnest, dann gibt es eben keine .244.
Das ist dann -12! (hatten wir doch weiter oben schon, alles >127 ist dann negativ)

1 -(-12) = 13. Kein Überlauf und nicht negativ. Passt alles.

Verwende (lerne) irgendeine Hochsprache, dann musst du dich mit den Details nicht mehr plagen ;-)
#8
P
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von picass - 29.09.2022, 18:38:06 CEST
Waterloo beim Rechnen !

Habe nach einer Pause die Spur der ,,Rechenkunststücke" in Assembler unter MPLAB X IDE bei Version 5.20 wieder aufgenommen. Da fasst einen nicht nur das Grauen, da ist das Ende des Rechnens mit dem PIC nahe.

Ein voll lustiges Beispiel für User mit Galgenhumor ist angefügt. Da soll in einer schlichten 8-bit-Subtraktion dieses gerechnet werden: dez'1' minus dez'244'. Der PIC kann sich nicht entscheiden, was er vom Ergebnis halten soll, weswegen er gleich gar kein Flag setzt, weder das N für negativ noch das C für positiv. Braucht man das Ergebnis für eine Sprungverzweigung, ist man am Ende, nichts geht mehr. So habe ich feststellen müssen, dass nicht nur das N-Flag gelegentlich nicht gesetzt wird, nix, das triftt auch für das C-Flag zu. Und einen daraus resultierenden ,,echten" Rechenfehler hatte ich auch gefunden.

In einem meiner Programme wird über einen analogen Eingang ein 10-bit-Wert eingesammelt. Der wird dann für die Ausgabe des bis 1.023 reichenden Ergebnisses auf vier Stück 7-segm.-Anzeigen als erstes umgesetzt: vier Variable sammeln die Werte für Tausender, Hunderter, Zehner und Einer ein. Für die Bildung dieser Variablen wird je eine Subtraktion benötigt und darauf folgt eine Verzweigung, je nachdem, ob was Positives oder Negatives rum gekommen ist. Da kann man es nur falsch machen: Setzt man auf das N-Flag, gibt es Fehler, setzt man auf das C-Flag, wird es nicht anders.
Was ein Schrott. Die neueren Versionen nach 5.35 haben eine völlig andere Syntax, sodass man komplett von vorne neu lernen müsste. In diesem Zusammenhang war schon mal von ,,Kultur-Schock" die Rede. Bin mit dem X IDE-Zeug am Ende.
Grüße, picass

Nachtrag:
- das zip-File enthält den kompletten Ordner, welchen das X IDE erzeugt, darunter dann auch das asm-File mit dem Programm.
- das Bild aus seinem Debug-Lauf zeigt das "Unentschieden" nach der Subtraction, der grüne Balken ist die Position des Debuggers.
#9
P
Elektronik allgemein / Aw: Probleme beim Löten
Letzter Beitrag von picass - 18.09.2022, 17:22:14 CEST
Die neue Positionier-Pinzette hat ihre erste Bewährungsprobe bestanden. Habe bei der Gelegenheit meine Bestückungstechnik zumindest bei Bauteilen im SMD-1206-Format umgestellt und nutze nun auch das vorige Verzinnen eines der beiden Lötpads. Was mit einer einfachen Pinzette häufig nicht klappte, das funktioniert nun recht gut, nämlich das Niederdrücken und auch noch leichtes Korrigieren der Lage. Vorher sprang zu oft so'n Winzling weg, nun nicht mehr. Das beschleunigt jetzt diese Einlötvorgänge erkennbar, und vor allem wird das ewige Wegspritzen und/oder dauernde Verrutschen verhindert, welches vorher mit der Klemmpinzette die Regel war. Bei anderen Bauteilen mit mehr als zwei Anschlüssen, vor allem bei ICs ist aber nach wie vor diejenige mit der Klemmpinzette für mich die beste Lösung.
Grüße, picass
#10
P
Elektronik allgemein / Aw: Probleme beim Löten
Letzter Beitrag von picass - 15.09.2022, 18:24:18 CEST
Zitat von: picass am 25.08.2022, 17:23:25 CESTDie "Neue" ist da.
Mal sehen, evtl. biege ich an den Spitzen rum.....
Muss mich mal selbst zitieren, damit der Zusammenhang gleich ersichtlich ist.
Habe nicht nur gebogen, sondern die gute Bernstein-Pinzette auch an einen der beiden Doppel-Schleifsteine der entsprechenden Maschine gehalten. Mit umwerfendem Erfolg: die langem Greifer'chen sind zu kurzen Stummeln mutiert. :-\  Nachdem der erste Schreck verflogen war, ergab der Praxistest aber, dass es haargenau passte. Schluck, war ein klein wenig zufällig passend, so'n Schleifstein schafft echt was weg, aber lass 'ma.

Dazu hätte auch ein Billig-Pinzette gereicht, na, man macht so seine Erfahrungen. :'( Aber unterm Strich habe ich exakt das, was mir vorschwebte: eine P. zum Positionieren von Bauteilen im SMD 1206-Gehäuse, vorwiegend natürlich von R's. Die Pinzette sollte so'n Teil runter auf die Platine, auf die Lötpads halt drücken, also ganz runter, ohne einen auch nur winzigen Luftspalt und in dieser Position sehr fest halten können. Vor allem auch bei Vorverzinnung eines Pads sollte das sichere Runterdrücken ohne jedwede seitliche oder andere Bewegung als nur nach unten möglich sein. Das klappt perfekt. Mag auch anders gehen, aber so ist es gut. O:-)
Grüße, picass