Neueste Beiträge

#1
P
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von picass - Gestern um 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.
#2
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
#3
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
#4
P
Elektronik allgemein / Aw: Footprint zu klein
Letzter Beitrag von picass - 15.09.2022, 18:08:49 CEST
Jepp...., da sagst du was!
Hatte mich bislang nur wenig, jedenfalls zuwenig an die Selbsterstellung oder Bearbeitung von Bauteilen in Bibliotheken ran getraut, aber nu....
Grüße, picass
#5
avatar_Peter
Elektronik allgemein / Aw: Footprint zu klein
Letzter Beitrag von Peter - 15.09.2022, 13:59:57 CEST
Dann kannst du auch direkt die Pads für SMD Elkos anpassen.
Die sind auch ein bischen zu klein zum löten.
Finde ich.
#6
P
Elektronik allgemein / Aw: Footprint zu klein
Letzter Beitrag von picass - 15.09.2022, 11:00:15 CEST
Hab's getan. Also den Footprint auseinander gezogen. Dazu ein Projekt geöffnet, die Bibliothek mit dem down geladenen Footprint geöffnet, dann Package ausgewählt und zu meiner Überraschung ließ sich jede der beiden "Füße-Reihen" einzeln gruppieren und verschieben. Das dann mit neuem Namen für diese neue Bibliothek abspeichern und fertig wars. Also fast. Denn nun war es zuweit auseinander gezogen. Also nochmal, diesmal gegenüber dem Ausgangszustand um genau 1,27 mm gezogen und das passt nun, was der Ausdruck nachwies.
Das Verlöten klappte ja vorher auch, aber beim nächsten Male wird es ohne das bisherige Gefrickel auskommen. :) Danke für die Ermunterung.
Grüße, picass
#7
avatar_Peter
Elektronik allgemein / Aw: Footprint zu klein
Letzter Beitrag von Peter - 14.09.2022, 18:42:32 CEST
Im Layoutprogramm einfach den Footprint grösser machen.
Sollte eigentlich in jedem Programm möglich sein.
Ich drucke dafür immer das Layout aus und schaue ob alle
Bauteile genug Platz haben zum löten.
#8
P
Elektronik allgemein / Footprint zu klein
Letzter Beitrag von picass - 14.09.2022, 17:34:31 CEST
Seit der Erstellung eigener Platinen, welche den von mir geschätzten PIC18F14K22 als µC tragen, treibt mich ein evtl. kleines, aber doch vorhandenes Prob um: Der von irgendeinem Versender - evtl. Mouser oder Farnell - downgeladene Footprint mag prima sein für Schwallbad-Lötungen, aber für händisches Löten ist das eine Herausforderung. Der µC muss vor dem Löten auf Bruchteile eines Millimeters exakt aufgesetzt werden und darf danach sich auch nicht einen Hauch mehr bewegen. Die Breite der "Fußabdrücke" ist so arg eng bemessen, dass außen zum Aufbringen von Lötzinn fast nichts zur Verfügung steht. Nach innen ist reichlich Platz für jeden Fuß, nach außen aber nahezu nichts.
Lässt sich so'n Footprint irgendwie auseinander ziehen? Oder gibt es eine andere Lösung? Bislang gab es noch kein Kontaktproblem, das könnte aber noch kommen und vor allem wäre es schön, wenn sich das Gefummel um die extreme Exaktheit etwas entspannen ließe.
Grüße, picass
#9
P
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von picass - 14.09.2022, 17:24:12 CEST
Mir gefällt nicht, dass die Verantwortung für diese Krücke dem Programmierer in die Schuhe geschoben wird. Würden - wie von mir dargestellt - zwei Flags verwendet, eines für die wahre Anzeige des negativen Wertes und eines für die technische Handhabung der Subraktionsrechnung im Zweier-Komplement, dann wäre das eine saubere Sache und die Verantwortung läge dort, wo sie hingehört, nämlich beim Ersteller eines Rechensystems, welches keine oder zumindest keine unnötigen Fallgruben bereit hält. Mir muss nicht alles gefallen, schon gar nicht, wenn es unnötig unvollkommen ist. Für mich ist die Logik nicht diejenige, dass man sich einer Krücke anpassen muss, sondern vielmehr, dass es bessere Lösungen ohne Fallen geben sollte.

Einem Sparkassen-Angestellten, welcher mir vermitteln wollte, dass die Mahnung der Überziehung meines Kontos zu Recht bestünde, obwohl von einem Guthaben von 2.500 € nur 250 € entnommen wurden, und der darauf hinweist, dass ihr System nun mal so rechnet, werde ich auch weder "Recht geben" wollen, noch sowas für gut befinden müssen. Das sollte nachvollziehbar sein.
Grüße, picass
#10
V
Compiler Software / Aw: MPLAB X IDE : Fehler ...
Letzter Beitrag von vloki - 14.09.2022, 15:56:25 CEST
Zitat von: picass am 14.09.2022, 15:34:38 CESTEine "Rechenmethode" einzuführen, welche diesen niedlichen Zahlenbereich auch noch zweiteilt in einen "sicheren" Bereich und einen, in welchem man mit unsicherem Ausgang rechnen muss, halte ich für eine Zumutung.
Die Verantwortung liegt beim Programmierer.
Der muss wissen, was er tut und die passenden Flags als Hilfsmittel heranziehen.

Wenn man das N-Flag abfragt, dann geht man davon aus, dass es negative Zahlen gibt,
somit das MSB nicht mehr für den Zahlenraum zur Verfügung steht und nicht mit Zahlen > 127 gerechnet werden kann.

Die "a8" aus dem Eröffnungspost ist dann ja schon eine negative Zahl (-88).
Wenn man da noch "5" abziehst, kommt "a3" raus (-93). Passt doch ;-)