Der Wiedereinstieg ins Assemblieren hakt mal wieder......

Begonnen von picass, 02.03.2021, 17:26:43 CET

⏪ vorheriges - nächstes ⏩

picass

Traurig, traurig, alles verlernt! Zwei Jahre nach meinem letzten Programm für den PIC18F14K22 in Assembler ist alles wieder weg und der Anfang wirft Hürden auf. Habe leider die komplette Hard-& Softwareumgebung von damals nicht mehr, vor allem ist die Festplatte mit den damaligen Erfolgen Geschichte, nur noch einige Programme existieren noch.
Habe nun die Vers. 5.35 der MPLAB X IDE installiert auf Win7/32bit und versucht, eine der letzten Versionen dieses vorigen Programms zu starten, aber nix funktioniert. Hatte zuletzt den kompletten Ordner des Programms Namens "öltemp66" in den Projekt-Ordner der neu installierten Version kopiert, dann dieses Projekt geöffnet, das Sourcefile geöffnet, als auszuführende "Hardware" den Simulator (-Modus) ausgewählt, aber außer einer niedlichen Fehlermeldung: "There is no make executable in the path"  is nix - siehe Bild 3.
Ich brauche ein einziges, kleines funktionierendes Prog., dann wirds auch wieder klappen, im Moment sehe ich nix, jedenfalls kein Land. :(
Grüße, picass

picass

Die tolle Alternative, ein Prog - egal, welcher Art - auf einem anderen PC und dort unter Win7 Prof/64 bit zu erstellen, endet in nahezu gleich aussehenden Fehlermeldungen, die ich leider nicht duchschaue, siehe Bild, das von der Qualität so schlecht wie das Ergebnis ist. >:(
Grüße, picass

Peter

Hallo
Hier mal ein Link MPLAB
Weis nicht ob du den kennst. Ganz unten ist dann der Compiler für Assembler.

Peter

vloki

Probier mal das angehängte Projekt.
Wenn das funktioniert, dann kannst du ja die Dateien ersetzen.

Beim nächsten Mal verwende am besten zum Archivieren deines Projektes das hier:
https://microchip.wikidot.com/mplabx:projects-package
Dann hast du alles drin, was man braucht und keinen unnötigen Ballast.

vloki

Zitat von: Peter am 02.03.2021, 22:01:50 CETHallo
Hier mal ein Link MPLAB
Weis nicht ob du den kennst. Ganz unten ist dann der Compiler für Assembler.
Ich glaub nicht, dass der ASM30 für einen PIC18 passt.

picass

04.03.2021, 14:59:57 CET #5 Letzte Bearbeitung: 04.03.2021, 15:04:15 CET von picass
Der Hacken ist durch die Strümpfe! :)
Nach diversen Frust-Versuchen bin ich gaaaaanz von vorne angefangen:
- zuerst auf dem zuverlässigsten Arbeits-PC eine SSD freigeräumt und ein "brandneues" Win7 HomePremium 32-bit-System installiert, und den ganzen steinigen Weg über Treiber und Win-Aktualisierungen gegangen. Dazu in einem alten Ordner nach noch älteren Keys geschürft, die dunnemals Verwendung fanden. Und Microsoft war so freundlich, via Inet.....;
- aus dem Archiv von Microchip die letzte Version des MPLAB ohne X installiert, einen Schreck bekommen, so alt sollte es auch nicht sein, die also gleich wieder gekillt;
- dann pur aus Verdacht die Version 4.20 der X-Kollektion installiert, wieder gabs beim ersten Test Meckermeldungen, die aber irgendwo nachvollziehbar waren;
- dann solide ein neues Projekt für den PIC18F14K22 am vom Programm für üblich erachteten Platz angelegt, dem Prog das alte, aber passend umbenannte ASM-File untergeschoben und Tusch: die Fehlermeldungen blieben aus, stattdessen in freundlichem Grün die Vermeldung des erfolgreichen Debuggens! ;D Ne, was schön, endlich kann mit der Arbeit begonnen werden!

Hatte mich gestern eine Runde geschämt, weil das mal wieder so holperig verlief. Lag u.a. daran, dass nach dem erfolgreichen Abschluss meiner letzten Schaffensperiode eine sofortige lange Pause einsetzte, in den Folgewochen Tabula Rasa mit Festplatten stattfand: die letzten mechanischen HDs wurden aufs Abstellgleis, bzw. in die Tonne verschoben, einige neue SSDs angeschafft, in all dem Gewusel versucht, mit Acronis True Image gelegentlich auch mal was zu sichern, nur um später festzustellen, dass die neueren Versionen - damit meine ich die Jahrgänge 2017 und 2019 unzuverlässig waren: sehr häufig hängte sich der Compi beim Versuch der Restaurierung auf, statt das Image auf der neuen Hd zu installieren, und evtl. hab ich noch'n Faktor übersehen, ach ja, meine Systematik war damals auch nicht "so ganz bei der Sache" gewesen.
Aber 'nu isses ja gut. Danke für alle wohlgemeinten Tipps.
Grüße, picass

picass

Nun ist entgültig Frieden im Assemblerbereich. Hatte gestern dasselbe File, welches unter Win7/ 32 bit lief, unter einem anderen Win7 probiert, einem mit 64 bit: auch das klappte. Dann heute wieder mutig noch'n anderes Windows, nämlich Win10/ 64 bit und die fünft-letzte Version der MPLAB X IDE geladen und installiert, nämlich die Vers. 5.20 : auch hier klappt das Debuggen auf Anhieb. In dieser Version ist der MPASM Assembler v 5.84 vom 17.03.2019 noch integriert.
Könnte sein, dass der auch noch in der Version 5.30 der X IDE drin ist. Danach wohl nicht mehr, die neueren Versionen haben ein deutlich größeres Download-Volumen, da ist dann wohl der neue X-Assembler drin, mit dem mein File nicht lief.
Grüße, picass

vloki

Also bei mir tut die v5.35 mit MPASM 5.87 unter Win10 64bit ohne murren.
(gebe aber zu, dass ich das seeeeeehhhhr selen verwende)

Grüße,
   Volker

picass

26.03.2021, 17:58:48 CET #8 Letzte Bearbeitung: 26.03.2021, 18:04:48 CET von picass
Nun soll es endlich losgehen mit der Erstellung des Progs für die Rollladensteuerung. Und – is klar – 2 Jahre Pause in Sachen Umgang mit Assembler waren zu lang. Das erste kleine Testprog ist fertig, auch der Debugger ist zufrieden und quittiert es mit ,,o.k.", aber beim Simulieren bleibe ich gleich hängen, hier beim Verändern der Werte von Port-Pins.
Verwendet wird MPLAB X IDE vers. 5.20 und der darin enthaltene Assembler. Die Ports A und B sind komplett auf Eingang geschaltet, PortC auf Ausgang.  Zunächst sollten PA4 u. 5 und PB6 u. 7 eingelesen werden, und deren Werte sollen im Singlestep-Modus des Simulators vor dem Einlesen und Weiterverarbeiten halt simuliert/ äh, stimuliert werden.
Meiner Erinnerung nach konnte ich dunnemals im Fenster für die Anzeige der Variablen die Werte von PORTA, PORTB und PORTC direkt ändern. Klappt aber jetzt nicht. Verändern kann man die Werte von LATA, LATB u. LATC. Leider hat das keinen Effekt auf PORTA, PORTB u. PORTC.

Nun gibt es da ein Extra-Fenster namens ,,I/O Pins", siehe Foto. Dort kann ich die vorher eingesetzten Pinne von Port B toggeln. Nicht aber die für PortA u C. Das könnte darin liegen, dass in diesem Fenster der Musterpin RA4 als analoger Input bezeichnet wird und der RC0 als analoger Output. Wer zum Henker hat denn diese Einstellungen/Differenzierungen vorgenommen - ich jedenfalls nicht bewusst?!  Was ist zu tun, um zumindest auch alle Pinne an PortA im Simulator stimulieren zu können?
Grüße, picass
toggel.jpg

picass

Na sauber! >:( Jetzt hatte ich beim großen Bruder, rsp. Vater - bei Microchip himself - um Hilfe bei Stimulatitions-Versuchen nachgeschaut, und dann dieses!  Siehe Bild.
Grüße, picass

vloki

Hast du denn die Pins von PORTa auf digital gestellt?
Per Default sind die vermutlich "analog" und beim Lesen vom PORT bekommt man dann immer eine 0!

vloki

Zitat von: vloki am 28.03.2021, 11:19:37 CESTHast du denn die Pins von PORTa auf digital gestellt?
Also in deinem Code, nicht im Simulator.

Der Simulator versucht wohl den PIC genau so abzubilden wie du ihn konfiguriert hast. Wenn du selbst nicht daran gedacht hast, dass man für die Pins nicht nur Ein- oder Ausgang einstellen muss, dann sind die eben mit dem Vorgabewert konfiguriert und der ist im Allgemeinen so, dass möglichst nichts kaputt geht, wenn was doch anders angeschlossen ist während der PIC noch gar nicht programmiert wurde.

picass

Ach, vloki, ach! Das war mal wieder typisch für mich: eine schier unüberwindliche Gemengelage aus Vergessen der Grundlagen des PIC-Assemblers und fehl-leitender, rsp. methodisch mangelhafter Ausführung des PIC18Fxx-Datenblattes und zu optimistischer Hardware-Beschaltung.
So war es eigentlich immer: gleich am Anfang Schwierigkeiten, die Ports richtig einzustellen. Dazu gehörte auch, dass die - wie du vermutet hattest - nicht explizit auf digital eingestellt waren. Das ist nun nachgeholt, danke schon mal an dieser Stelle.
Dann das verdammte Datenblatt. Da haben ganz sicher Dipl-Ings dran gesessen, die ihr fundamentales Wissen um die Details der Assembler-Kunst verinnerlicht hatten. Nur hatten die keinerlei Ahnung von Methodik und deswegen in diesem Bereich bei den Ausführungen nicht nur Mangelhaftes, sondern nach meinem Geschmack Ungenügendes abgeliefert.

Auf mehreren Seiten wurde über die Ports referiert, dabei alles in dreifacher Wiederholung, für jeden Port extra das fast Gleiche. Auch ein scheinbar praktisches Programmier-Beispiel wurde angefügt. Aber dann gings los: statt über die Basics der Port-Einrichtung hinreichend zu informieren, gabs spaltenlange Ausführungen über Interrupt-Behandlung. Das gehört schon deswegen nicht dort rein, weil es einerseits Programme ganz ohne Interrupt geben kann und gleicherseits für die IRQs eine extra Abteilung folgt. Aber leider... leider wurde dabei das Basic der Notwendigkeit nicht, rsp. ungenügend behandelt, Eingangsports auch auf analog oder aber digital einrüsten. Der niedliche Hinweis in einem winzigen Kasten reicht NICHT. Wenn es nicht möglich ist, einen Port ohne diese Einrüstung sicher in Betrieb zu nehmen, dann gehört diese Info nicht am Ende in Kleinst-Gedrucktes, sondern ganz an den Anfang und in mehreren Sätzen und - auch das noch - in einem praktischen Programmier-Beispiel ausgeführt! Da haben die Herren Ingenieure eine miese Arbeit abgeliefert.

Jetzt wieder zu meinen Fehlern: Meine ersten Testprogramme wären ja gelaufen, wenn ich bei der Hardware nicht zu schnell und zu großzügig vorgegangen wäre. So hatte ich eine dieser kleinen Musterplatinen mit dem ewig langen Namen:"....low Count Demo Board..." genommen, und die vorhandenen Beschaltung - eine 7-Segm.-Anzeige - mit übernommen. Also viel Drahtgewirr. Dazu kamen dann 2 Taster und da kam meine Unzulänglichkeit ins Spiel. Einfach mal zwei Ports über Taster an Plus und das wars. Kein Kondensator, kein Widerstand, nix. Und das brachte dann - wie ich erst heute feststellte - alle Versuche zum Kollaps. Da starteten LEDs, obwohl das Prog gar nicht so weit war, auf den 2 Ausgangspins lagen Rechteck-Impulse an, das war ein wares Wunderwerk und alles so ungewollt.
Erst heute hatte ich die Eingänge beruhigt und Widerstände je nach Plus und GND gelegt und - zack - war der Spuk vorbei. Das liest jetzt keiner hier, und ich habe auch ganz ehrlich nix, aber auch gar nix gesagt: aber das hat mich Tage des Anlaufens gekostet. Schwitz. Nu ist der Spuk vorbei und das Prog tut erstmals das, was es soll. Da wollen wir mal hoffen, dass die Wiedereinstiges-Wehwechen damit überwunden sind.

Dem Simulator bin ich aber immer noch böse, will sagen, das Stimulieren der Portpins klappt immer noch nicht. Write to the latsch, read from the Port.....heißt es. Aber wenn ich einen Port Pin mit: bsf LATC,4 beispielweise auf "1" setze, was ja auch klappt, dann lässt das den Simulator völlig kalt und die anschließende Abfrage mit einem Sprungbefehl wie: btfsc PORTC,4 ergibt immer nur "0". Immer diesen verdammten Basics....
Grüße, picass

vloki

30.03.2021, 11:22:51 CEST #13 Letzte Bearbeitung: 30.03.2021, 11:33:32 CEST von vloki
Zitat von: picass am 29.03.2021, 17:22:50 CESTDann das verdammte Datenblatt.
Hab mich ehrlich gesagt auch gewundert, wo bei PORTA die in den meisten PIC18 Datenblättern üblich "Note" ist,
in der gleich am Anfang auf die Konfiguration als analoge Eingänge hingewiesen wird. (Bei PORTC ist sie vorhanden)

Eventuell wertet der Simulator den PORT in deinem Fall nicht aus, weil der Level dort dem Simulator
nicht bekannt sein kann, da die Beschaltung nicht bekannt ist. (Im Extremfall ein Kurzschluss zu irgendwas)

Warum liest du nicht einfach das Latch? Wenn du wissen willst, was du an den Ausgang geschrieben hast,
dann ist das die richtige Wahl. Nur wenn du wissen willst, ob das, was du am Ausgang haben willst auch in der Realität,
z.B. trotz ungünstiger Beschaltung auch am Pin bereit gestellt werden kann, dann könntest du den PORT lesen und mit dem erwarteten Pegel vergleichen. (Der Simulator kann das evtl. nicht)

vloki

Zitat von: vloki am 30.03.2021, 11:22:51 CESTEventuell wertet der Simulator den PORT in deinem Fall nicht aus, weil der Level dort dem Simulator
nicht bekannt sein kann, da die Beschaltung nicht bekannt ist. (Im Extremfall ein Kurzschluss zu irgendwas)
Hmmm,
ich benutze den Simulator eigentlich nie, aber ich habe das gerade bei mir mal schnell ausprobiert,
da ich ein Projekt in der IDE habe, das in einer möglichen Konfiguration auch einen 14K22 hat.

Bei mir folgt PORTC_4 dem LATCHC_4. Kannst ja mal dein Projekt packen und hier posten oder mir schicken...

Schnellantwort

Achtung: In diesem Thema wurde seit 120 Tagen nichts mehr geschrieben.
Wenn Sie nicht absolut sicher sind, dass Sie hier antworten möchten, starten Sie ein neues Thema.

Name:
Verifizierung:
Bitte lassen Sie dieses Feld leer:

2 beeren und 2 banannen. Welche Farbe hat die Bananne ?:
Tastenkürzel: Alt+S Beitrag schreiben oder Alt+P für Vorschau

SMF spam blocked by CleanTalk