Zitat von: Ottmar in 04.06.2023, 17:54:38 CESTOk, vielleicht hilft es Dir weiter!

Ach, Ottmar, das weiß ich noch nicht so recht, ob mir die nur zwei Beispiel-Texte und die paar Zeilen der Erläuterung weiter helfen könnten. Da muss ich noch mal streng drüber nachdenken!


Danke dir sehr, das hilft dem Opa in den Sattel! Der Volker hatte dunnemals sich auch schon mal über Relocables und Ähnliches geäußert. Das lag aber für meine Erinnerung recht weit weg....
Die Umarbeitung der drei Programme wird 'ne rechte Herausforderung für mich. Bin schon bangiglich gespannt, was denn die drei PICs dazu sagen werden, wenn die neu gestalteten drei Platinen mal fertig bestückt und mit den umgemodelten Progs gefüllt sein werden. Schwitz!
Grüße, picass

Sorry picass
Habs fast vergessen!
porta    equ 0x05
portb    equ 0x06
intcon  equ 0x0b
trisa    equ 0x85
trisb equ 0x86
das sind keine Variablen welchen Du einen Speicherplatz zuweisen darfst!
Sie sind alle in der p18F14K22.INC Definitions bereits belegt!.
Siehe dort z.B.
;----- Register Files -----------------------------------------------------
IOCB            EQU  H'0F7A'
ANSEL            EQU  H'0F7E'
ANSELH          EQU  H'0F7F'
PORTA            EQU  H'0F80'
PORTB            EQU  H'0F81'
PORTC            EQU  H'0F82'

Ottmar

Hallo picass,
habe Dir mal 2 Dateien angehängt. Einmal "Relocatable" code und "absoluter" Code. So mache ich das standardmäßig.
Die Variablen legst du beim 18F14K22 bei absoluem code ab h060 ab (vgl. Beispiel. Dann sparst Du Dir das langweilige  "var1 equ 0x060 .......

CBLOCK 0x60.
  var1
  usw...
ENDC

Bei relocatable sorgt der Linker dafür dass die Variablen an die richtige Adresse gespeichert werden, ausgenommen Du gibst definitiv eine Adresse vor.

LOC_VAR        UDATA
  cntLine    RES 1
  tmpAddr    RES 1
  cntAscii    RES 1

Leider hat der 18F14K22 nur einen PORTC,7:0
PORTA und PortB haben nicht die vollen 7 Bits zur Verfügung.

Ok, vielleicht hilft es Dir weiter!
Gruß Ottmar

Buddel den Fred mal aus, weil er nun mal passt!
Vom Assembler des PIC16F84 zu demjenigen für den PIC18F14K22 - hier dem aus der MPLAB X IDE, dem MPASMX v5.87 - gibts einige wenige Unterschiede. Dunnemals wurden in einem Prog als Erstes die Constanten mit ihrer Speicherplatz-Zuweisung aufgeführt. Danach kamen die Variablen dran - siehe Beispiel.
Bei ersten Debbuging-Versuchen wurde die Aufführung der Constanten nicht angemeckert. Einfach so lassen?
Grüße, picas
constante.txt

Nach all den Eingriffen hat die Hardware der Rollladensteuerung – will sagen: die vielen Geräte mit ihren PICs intus – den Praxistest bestanden. Watt ,ne Freude!
Heute gings dem einen der beiden durch mechanische Probs geplagten Rollläden an den Kragen. Da hatte sich die alleroberste Latte um fast 20 cm verschoben und hakte an einer Befestigungsschraube. Noch nie erlebt so was, der Grund dafür ist auch unersichtlich. Jetzt auch Geschichte! Der letzte Mohikaner, also Rollladen, hat nach einigem Grübeln recht sicher ein Prob mit seiner in den Motor-Körper integrierten Elektronik (Bosch). Da gibt es so ein Feature, welches beim Hochziehen Hindernisse erkennen und ggf. beseitigen soll, so z.B. bei teilweise festgefrorenen R-Stäben. Da läuft der Mot nur ein ganz kurzes Stück an, bricht das (dünne) Eis auf, zieht erneut ein Stückchen, usw., usw.. Das ist es wohl, was im Moment ,,funktioniert", obwohl just die ersten Freibäder öffnen. Sprich: da wird ein neuer Motor fällig. Das wird dann Kuster's letztes Gefecht und dann ist es auch gut.

Also fast. Denn nun steht die Bestückung der drei neuen Platinen an – die dritte kommt hoffentlich heute Nachmittag noch – und danach erfolgt das Abtauchen in die Tiefen der 20-Jahre-alten Assembler-Progs. Einen Blick habe ich mir gestern schon gegönnt. Kompliment, was ich dunnemals so auf die Beine stellte. Kommt mir heute kompliziert vor, also komplizierter als nötig. Die erste Planung sieht daher Ballast-Abwürfe vor, ab dem Wochenende, danach folgt die ,,Übersetzung" etlicher geänderter Assembler-Befehle, schwitz.
Grüße, picass

Zitat von: pic18 in 31.05.2023, 22:18:04 CEST......Laptops brauchen wesentlich länger und sind um einige Jahre jünger.

Die Geschwindigkeit des Startens u. Auschaltens von Win-Betriebssytemen wird von vielen Faktoren beeinflusst, sowohl von Hard- als auch von Softwareseite her. Lange Zeiten ergeben sich gerne, wenn es Probs mit dem Win selbst gibt, weil das mittlerweile durch häufiges Löschen, Neuinstallieren, Defragmentieren, etc., etc... durch gestrubbelt ist. Bei NBs kann das furchtbar werden, wenn dann noch lahmaschige (Pardon) mechanische HDs drin sitzen. Das Win-System komplett neu aufsetzen und in NBs eine SSD einsetzen hat schon oft für runde Augen zwecks des Speeds geführt.

Aber bitte - "pic18" - wir sollten Probs über allgemeine PC-Probleme in einem Extra-Fred debattieren, sonst wird dieser Fred unleserlich zwecks des Support-Endes für Win10.

Die Entscheidung, ob oder wann ich meine PCs aufrüste, rsp. quasi neue anschaffe, wird mir in einem Fall vermutlich sehr rasch abgenommen. Mein Haupt-Arbeits-PC - is klar: nicht Win11-tauglich - hat gestern Mucken gemacht und das gleich zweimal mit klaren Hinweisen auf Probs mit der Graka. Weil diese im Motherboard integriert ist, gibts da keine Rettung. Eine Extra-Graka wäre keine Lösung, weil selbst einfachste Grakas so teuer sind, dass man gleich ein modernes Motherboard und in der Folge einen einfachen, modernen Prozessor mit integrierter GPU kaufen kann. Ich werde mich gleich mal unschauen.
Aus meiner Sicht ist das Neukaufen unumgänglich, es sei denn, man möchte komplett auf Linux umsatteln. Das wäre für eine HD, mit welcher man die üblichen Inet-Anwendungen hat, auch für mich eine gangbare Lösung. Aber.... , aber bei weitergehenden Arbeiten wie dem Sichern von Daten, dem Hantieren und Experimentieren mit verschiedener Hardware bin ich mit dem gewohnten Windows einfach besser bedient. Sprich: werde mich so langsam ans Aufrüsten machen.
Grüße, picass

ich hatte gestern den Bootstick nochmal gestartet, restore ausgeführt. Nach einer halben Stunde hatte der Bootstick immer noch gleichmäßig geblinkt. Dann hatte ich den Ausschalter länger gedrückt und siehe da, der PC startete normal. Seit dem läuft alles perfekt. Nun hatte ich noch ein paar Updates gemacht. Mein altes Vista- System habe ich auch nicht zerschossen. Mich wundert es nur, das der alte PC so schnell hoch- und auch wieder schnell herunterfährt. Meine beiden Laptops brauchen wesentlich länger und sind um einige Jahre jünger.

@Peter, die Rechtschreibung funktioniert jetzt plötzlich auch.

Die Lage an der ,,Kell- u. Roll-PIC" – Front sieht so aus:
Gut!

Vorgestern schon hatte der kellpic sinnvolle Signale von seinem angestammten Platz aus gesendet. Gestern tat es auch der rollpic ihm nach, aber zusammen ging trotzdem nichts. Heute nun wurde der gordische Knoten der Kabel-Verknotungen gelöst – da hatte sich beim Auseinander – u. wieder Zusammenbau  was verwirrt. Aber nu' versteht und unterhält sich die gesamte Anlage wieder miteinander. Endlich. Aber so gänzlich weg ist das ,,Verwirr-Optionale" noch nicht. Mir ist schlicht kein  eindeutiger Fehler bekannt und ein defektes Bauteil hat's eh nicht gegeben. Beim kellpic wurde die Zuführung des 50-Herz-Signals (50HS) optimiert. Optimiert, mehr nicht. Denn meine zwischenzeitliche Annahme und auch Berichterstattung über die 20 Jahre angehaltene Überlastung des PIC-Ports für die Aufnahme des 50HS stimmte nicht. Nur in der Simul-Anlage war das so, im Original lag das Eingangssignal am PIC nie größer als 4,5 Volt. Also, so recht kein Grund für all den Troubel entdeckt. Aber nu' läuft es wieder und das wird hoffentlich so bleiben.

Das Gestrampel hatte aber definitiv viele gute Seiten. Mittlerweile stehe ich wieder bestens im Stoff, die fehlenden Unterlagen für die alten Schaltungen sind inzwischen neu angefertigt, und – hüstel – auch die Systematik für den Umgang mit der ganzen Anlage hat eine erkennbare Steigerung genommen. Und gerade eben trafen die von AISLER gebackenen ersten zwei Platinen ein, mithilfe derer sowohl endlich die bislang nicht vorhandenen Ersatzteil-Schaltungen erstellt werden können als auch bei der Gelegenheit auf neuere Bausteine – also neuer PIC-Typ, SMDs u. Diverses – umgeswitscht werden kann.

Fehlt nicht noch was? Klar man, die Programme. Da bin ich noch bei ersten Vorarbeiten, um die Werkzeuge für die Prog-Bearbeitung bereit zu legen. Zum Beispiel hatte mich der schlichte Ausdruck der alten Programm-Files (.asm) gequält, weil die Ausdrucke via MPLAB-X-IDE (MXI) völlig unbrauchbar waren. Da ließen sich weder die Buchstabengröße noch die Breite der Seite in sinnvolle Zusammenhänge bringen. Und der Ausdruck via Textverarbeitungs-Prog war noch schlimmer, weil die Zeilenumbrüche und die Leerzeichen wahllos durcheinander waren und eine Korrektur eine tagelange Sisiphus-Arbeit geworden wäre. Heute wurde auch da zugeschlagen: das MXI vers.5.20 wurde gekillt und die letztmögliche ver.5.35 installiert. Und gucke da, plötzlich ist der Ausdruck über dessen Oberfläche auch wieder möglich, rsp. verwertbar. Wehe, die Roll-Anlage wagt es, nochmal zu spinnen. Dann..... , dann wird Alles zubetoniert.
Oder so ähnlich.
Grüße, picass

Zitat von: pic18 in 30.05.2023, 21:44:42 CESTSobald ich den Stick entferne....

Ist bei meinem Arbeits-PC genau umgekehrt: wenn ein USB-Stick "hinten" montiert ist, will der PC unbedingt von dem starten und ignoriert anderes. Da sind die Bio'sse schon eigensinnig. Dunnemals konnte man eine Reihenfolge der eventuellen Startgeräte eingeben und die wurde auch abgearbeitet, aber "moderne" Bio'sse......

Wo genau hängt der PC denn beim Startversuch?
Wir werden hier aber - so interessant das auch ist - in diesem Fred off-topic. Daher würde ich für Fragen allgemeiner PC-Technik und für Debatten hinsichtlich Linux-Nutzung doch das Erstellen eigener Freds nahelegen, sonst verwässert das die Debatte um Supportende für Win10.
Grüße, picass

Danke, muss mal nachschauen. Im Moment bring ich den Rechner nicht mehr zum Starten.