Nachtrag:

Zitat von: picass in Heute um 09:50:24 CESTEs sichert den kompletten Inhalt des Systempartition – da bitte genau hinhören. Also nicht die komplette Hd, sondern nur das Betriebssystem und aller solcher, welche zum Starten der Hd nötig sind......

Das ist ggf. missverständlich formuliert. Die Sicherung umfasst den kompletten Inhalt der Partition C:, also alles, was auf der üblichen System-Partition liegt. Wenn - wie üblich - auf der auch die installierten Programme liegen, dann werden die ebenso mitgesichert und - ach ja - natürlich auch vorhandene Daten dieser Partition, also schlicht Alles darauf.

Zur Vorbereitung gehört, sich zunächst einen Grundlagen-Artikel mit Beschreibung und Handhabung durchzulesen. Der ist erst jünsgt aktualisiert worden und in der "c't" Nr.16 von 2023 abgedruckt, übrigens 5 Seiten lang. Danach lädt man vom Microsoft-Server das "Media Creation Tool" runter, startet das und wählt die passende Image-Version für das erwünschte Windows. Dieses Tool lädt anschließend das Win-Image runter. Dann auf den Heise-Server und das genannte Script downladen. Anschließen schnuppert man in die Anleitung und lässt anschließend dieses Script auf die Hardware los, womit vor allem die Sicherungs-Platte gemeint ist, welche über den USB-Anschluss angestöpselt wird. Das Script macht die Si-HD zunächst platt und zwar tutto. Dann richtet es zwei Partitionen ein, die erste Kleine ist die vom Script genutzte, die zweite hoffentlich sehr große nimmt später die Sicherungen auf.
Nun kann es ans Sichern gehen. Den PC mit dem zu sichernden System staren, die USB-Hd anschließen, im Script die Sicherungs-Routine starten (Mausclick) und ganz gebannt und hoffentlich entspannt auf den Bildschirm schauen, was da abgeht. Und da geht so Manches ab, aber das wird - fast - nicht angezeigt. Das ist gewöhnungsbedürftig, denn es poppen nicht dauernd irgendwelche Meldungen auf und es gibt auch keinen Verlaufsbalken. Da braucht es tatsächlich Zeit, Vertrauen und Geduld. Aber lass ma...., das Script gibt es schon seit Längerem und das ist hoch betriebssicher. Vor dem Bildschirm warten wäre Masochismus. Also Einkaufen fahren oder besser noch was Längerdauerndes zelebrieren. Aber dann....
Erzeugt wird ein Image, das ist hoch komprimiert und nur fürs Zurück-Sichern gedacht. Dafür wird viel Platz gespart.
Wenn du nur mit Aufwand an den Artikel kommen solltest, melde dich per PN, da kann geholfen werden, abgesehen davon, dass die Arbeit der Redaktion den Kauf einer Ausgabe dieser Zeitschrift nun wirklich wert ist.
Grüße, picass

Die kurze Antwort: die Subtract-Routine ist ein Teil einer Schleife, welche solange durchlaufen wird, bis der Wert der Subt. negativ ist. Dann wird ausgesprungen und es geht zur Anzeige. Aber nicht der genannte Wert wird benötigt, sondern der Stand des Rundenzählers in der Schleife. Mit dessen Wert wird jeweils in die beiden im EEProm abgelegten Tabellen eingesprungen.
Die andere Antwort: das gesamte Prog geht recht manipulativ ans Werk. Zwar wird am Eingang via ADC ein der Temperatur im Dieselpartikelfilter entsprechender Spannungswert eingelesen, aber schon am Anfang nicht wirklich als solcher verwendet. Dazu müsste man eine Formel mit den Sensor-Eigenschften haben. Die gibt es auch, aber zum einen lässt die sich schon auf dem Papier nicht so auflösen, dass der eingelesene Spannungswert zur Anzeige genutzt werden kann, noch wäre ein Acht-Bitter unter Assemblerprogrammierung dazu in der Lage. Und ich auch nicht.
Also werden in mehreren Stufen so was wie Analogien benutzt, um zu einer Anzeige zu kommen. Ein bißchen um vier Ecken rum, aber das ist wenigstens machbar. Also keine direkte Nutzung und Durchreichung von (Spannungs-) Werten.

Was nun hat gestern den Erfolg gebracht?
Nächste Frage, ich weiß es nicht. Weder habe ich einen krassen Fehler gefunden, noch etwa eine von sich ändernden Bedingungen abhängige temporäre Unzuverlässigkeit entdeckt. Der Erfolg trat ein, weil ich gestern nochmal Grundlagenforschung betrieb, das Hauptprogramm – Obacht: wirklich nur dieses mit nur drei der sonst 10 Seiten – ausdruckte und dann jedes Wort auf dem Papier umdrehte und sofort am Compi eine sich anbietende vermeintliche Verbesserung, rsp. Änderung ausführte.
Da wurde zunächst die lange Liste der deklarierten Variablen ausgemistet, dann wurden die Variablen einzeln mittels Suche im Prog aufgerufen und alle Positionen kontrolliert, da wurden an mehreren Stellen Vereinfachungen vorgenommen, sprich: Umständliches eliminiert, da gab es kleine, aber wohl unnötige Verbesserungen, z.B. wurde an zwei Befehle noch ein Index angehängt, obgleich per Datenblatt auch ohne das die Funktion ,,per default" vorgenommen würde. Is klar, die Subtr.-Routine wurde zum zigsten Male auseinandergenommen und wieder zusammen gesetzt. Allerdings blieb sie im Kern/von der Systematik her unverändert. Zudem wurden die Kommentare angepasst und erweitert für später mal. Der papierne Ausdruck war teilweise mit roten Markierungen reichlich bedeckt, aber nochmal: einen echten Fehler konnte ich nicht entdecken.

Ganz fertig ist das Prog noch nicht, es fehlt z.B. noch die Bearbeitung für das Überschreiten des gewünschten Messbereiches. Da springt im Moment die Anzeige zwischen dem korrekten und einem anderen Wert. Aber wenn ich bis hierher gekommen bin, wird das auch noch werden. Ist ja auch nicht als neues Problemfeld ausgemacht, sondern nur schlicht noch nicht bearbeitet. Und – ach ja – die Piepser-Funktion muss noch rein. Da soll ja noch so'n kleiner Krachmacher integriert werden, welcher den Beginn einer Regeneration LAUT verkündet.

Aber ein Segen, dass nach den schier endlos langen Tagen an Bemühungen nun die Ziellinie überschritten werden konnte. Mehrfach hatte ich ans Hinschmeißen gedacht. Nun muss sich das Alles erst mal wieder beruhigen, schließlich warten noch andere Projekte auf der berühmten Bank.
Grüße, picass

Hallo pic18 !

Zum Sichern von Festplatten-Inhalten gibt es Programme und ,,Tipps" wie Sand am Meer, manches kostenlos und natürlich auch gegen gutes Geld. Selbst habe ich mir ein Konzept zurecht gelegt, welches ich in den letzten Jahren mit Erfolg angewendet habe. Das besteht aus der Verwendung eines gekauften Programmes, das ich alleine deswegen verwenden muss, weil es in der Lage ist, auch mit älteren Win-Versionen wie z.B. Win7 umzugehen.
Mein Favorit ist aber eindeutig was Anderes und das stammt aus dem Heise-Verlag von den Redakteuren, rsp. Mitarbeitern der Zeitschrift ,,c't". Die hatten vor etlichen Jahren ein Prog selbst entwickelt, welches sich ab Win8 einsetzen lässt und vor allem für Win10 und Win11 spezialsiert ist. Dieses Programm ist genau genommen ,,nur" ein Script, allerdings ein sehr ausgefuchstes.
Es sichert den kompletten Inhalt des Systempartition – da bitte genau hinhören. Also nicht die komplette Hd, sondern nur des Betriebssystem und aller solcher, welche zum Starten der Hd nötig sind. Für das Sichern eventueller ,,hinterer" Partitionen muss man anderes verwenden, aber dazu reichen ja selbst Windows-eigene Kopier-Progs.

Gesichert wird aus dem laufenden Betrieb, d.h., der zu sichernde PC wird normal gestartet, danach wird über einen USB-Anschluss eine präparierte – also mit dem Script vorbereitete – externe HD angeschlossen. Das kann eine der vielen auf dem Markt befindlichen USB-Sicherungsplatten sein, die meist im 2.5"-Format herkommen, dass kann aber auch jede andere HD sein, z.B. ein Riesen-Trümmer in Terrabyte-Größe, angeschlossen über einer der handlichen und preiswerten USB-Adapter. Aus dem laufenden Win-Betrieb wird dann das Script aufgerufen und das verrichtet dann sein Arbeit und sichert. Das dauert, aber es lohnt sich.

Dieses Script hat als Nachteil, dass eine Sicherung wirklich lange dauern kann, da gibt es schnellere Si-Programme. Aber es hat Vorteile, welche andere Progs nicht haben. Es sichert vom Betriebssystem nur gewisse Teile, aber einen großen Teil lässt es aus. Das kann es, weil zum Sicherungskonzept gehört, dass vorher vom Microsoft-Server ein orig Image zur Erstellung einer neuen Win-Installation downgeladen und vom Script integriert wurde. Bei einer späteren Nutzung der Sicherung werden dann die vorher ausgelassenen Anteile aus dem orig Microsoft-Image entnommen und derart eine feine, überwiegend Neu-Install vorgenommen. Dieses Verfahren ist legal, allein schon deswegen, weil es Microsoft selbst für Händler so anbietet und das jahrelang betriebene Praxis ist.
Die Vorteile u.a. anderem: wegen dieser Teil-Neuinstall kann man das Zurückspielen der Sicherung nicht nur auf der vorher genutzten Hardware ausführen, sondern auch auf einer anderen, sprich: z.B. nach einem Total-Schaden des Alt-PCs kann man problemlos das auf einem neuen mit ganz anderer Hardware installieren. Legal, wohlgemerkt, was bedeutet: die alte Lizenz bleibt erhalten und wird mit Microsofts Segen auf den Neuen mit umgezogen.

Es gibt auf dem Heise-Server eine extra Seite und eine Kommunity für dieses Projekt: ct.de/wimage
Und – ach ja – dieses Prog ist kostenlos. Und auch das noch: natürlich muss man lesen können und sich die Anleitung komplett durchlesen und verstanden haben. Aber schwer ist da nichts. Wer lesen kann und das einfach nur nach macht, kommt damit auf Anhieb klar.

Ein weiterer Vorteil ist z.B. das Platzsparen. Dazu ein prägnantes Beispiel aus meiner Computer-Welt. Selbst unterhalte ich einen extra-PC nur für Spiele. Der hat zwei unabhängige Hds, diese neuemodischen M2's, die so aussehen wie ein Speicherriegel. Weil mein PC nur einen solchen M2-Steckplatz hat, kann auch nur eine drin sitzen. Auf beiden liegt die exakt gleich Win11-Version installiert. Auf der einen treibt Lara Croft ihr Wesen und jagt böse Buben, auf der anderen gehe ich mit dem Microsoft Flugsimulator in die Lüfte.
Beide Platten brauch beachtlich Platz, vor allem der FS. Und gettz das Sichern mit diesem Script:
weil es ja mitnichten den kompletten Inhalt der Winpartion sichert, sondern sich vom Windows nur die notwendigen ,,Einstellungen" raussucht und sichert und fürs Rückspielen das frische Microsoft-Image verwendet, wird von jeder der beiden gleichartigen Winsysteme nur ein Bruchteil gesichert und der ,,Rest" später dann aus dem M-Image genommen.
Das führt zu einem wesentlich geringeren Speicherbedarf, als es das von anderen Programmen übliche Komplett-Sichern der C:Partition erfordert.
Und beim Rückspielen wird der übergroße Teil wirklich microsoft-frisch-neu aufgebracht, die Lizenz bleibt und ein evtl. PC-Totalschaden ist egal, das läuft auf anderer Hardware ebenso.

Das mal fürs Erste.
Grüße, picass

was genau machst Du eigentlich mit der Subtract-Routine. Warum mußt Du das Ergebnis nicht sichern?

Ich bin noch nicht dazu gekommen, das System zu sichern. Die Frage war ernst gemeint.  MBR bzw GPT werde ich mit Linux sichern. Macht es einen sinn das WIN11 zu sichern, und wie mache ich das am Besten. Auch damit meine Lizens bei Festplattencrash erhalten bleibt.

Es ist vollbracht:
Auch die "deluxe"-Version, also die mit 3-stelliger 7-segment-Anzeige ist soeben ist Leben gestoßen worden. Das war eine Zangengeburt und die Wehen furchtbar und lang. Aber nu isser da! Nur noch Erleichterung!
Grüße, picass

N'en paar Minuten später dieses:
Am Ende des Progs wurde nun anstelle von sleep eine Dauerschleife eingerichtet: also ein kompletter Durchlauf, wobei es zum Anzeigen eines Wertes kommt wie auch zu erwarten zum Abspeichern der Verlaufs-Variablen, und danach nur noch Dauerlauf auf der Stelle, ohne irgendwas zu verändern.

Und dabei zeigt er nun nach je einem Durchlauf ALLES an möglichen Zahlenwerten an, also auch problemlos oberhalb von 440 - das war die bisherige Obergrenze, ab der nur noch 950 gezeigt wurde.
Daraus würde ich nun schlussfolgern wollen, dass sämtliche Programmfunktionen in Ordnung sind, aber nur einmal. Beim wiederholten Durchlauf wird irgendwas, wenn nicht alles über den Haufen geworfen.
Ein Schritt vor der Ziellinie, welcher Schritt ist der richtige?
Grüße, picass

Am Poti liegt es nicht und kann auch nicht. Erstens hatte ich gemessen: da springt nichts. Zweitens könnte es nur ein Minisprung sein, weil im Spannungsteiler für den ADC der Wert des Potis nur ein sehr geringer ist - für die hohe Auflösung - und der Wert der beiden Festwiderstände "oben" und "unten" erheblich größer ist.
In der Subtract-Routine darf das Ergebnis in das WREG-Register, in der Variablen eeplow/high muss nichts gespeichert werden. Entscheidend für den Fortgang des Progs ist der Wert des Rundenzählers, welcher die Position der beiden Tabellen im EEProm vorgibt. Die Rechenroutine selbst habe ich mehrfach überprüft. Bislang war mir kein Rechenfehler aufgefallen....

Das kann jetzt nur noch Sabotage sein. Auch mein letzter ultimativer Rettungsweg ist gescheitert. Nachdem ich jüngst festgestellt hatte, dass entgegen meiner vorigen Annahme bei HW-Debugging doch der EEProm-Inhalt angezeigt werden kann, entwickelte sich dieser Plan ,,um zwei Banden rum":
Zunächst wurden dem Prog mehrere gleichartige Routinen implementiert, die dafür sorgten, dass an markanten Stellen der aktuelle Wert interessierender Variablen ins EEProm gespeichert wurde....., es war ,,hinten" gerade noch Platz für 10 Bytes. Das wurde natürlich im Soft-Sim (SS) getestet und funktionierte prima. In einen papiernen Ausdruck wurden für den kritischen Grenzbereich – klappt noch, klappt nicht mehr – alle Werte zusätzlich eingetragen, alles gut bis dahin.

Dann wurde es ernst: Zunächst den PIC mit einem Prog befüllen, ihn dann ganz normal – also auch mit der adc-Messung – laufen lassen, aber nur einen Durchlauf (DL) zulassen und am Ende des DLs eine Sleep-Anweisung anbringen. Der eine DL würde reichen, alle Funktionen auszuüben und am Ende im neuen, zusätzlichen EEProm-Bereich quasi die Dokumentation des Verlaufs abgespeichert zu haben.

Danach wurde das  Prog nur insofern verändert, dass gleich beim Beginn der Hauptroutine ein Stopwatch eingelegt wurde. Also dieses Prog dann gleich mit dem HW-Degugger aufzurufen, sollte bewirken, dass dieses ,,neue" Prog halt auch nur bis zum Anfang laufen würde, somit noch keinerlei Änderungen von Variablen und auch kein Überschreiben im EEProm stattfinden würde. An dieser Stoppstelle nun sollte der Inhalt des EEProms mit dem neuen Bereich Auskunft über den vorigen Ablauf geben.

Alles klar, jedenfalls in der Theorie. Beim Aufruf des EEP-Inhaltes wurde dieser nicht angezeigt. Keine Ahnung, warum, auch das sonst mögliche Aktualisieren des Inhaltes über ein entsprechendes Symbol innerhalb dieses EEP-Anzeigefensters brachte nichts.

Das ist jetzt die Deprise numero 25! Warum zum Henker sträubt sich die MPLAB-Umgebung (MU), das zu zeigen, was sie wenige Minuten vorher noch getan hatte? Zeitgleich klappte manchmal auch das Anzeigen der Variablen nicht, obwohl das bislang immer geklappt hatte. Ist die bislang bewährte Vers. 5.20 irgendwie defekt? Oder doch nicht so bewährt?

Wenn ich mir die bislang investierte Lebenszeit so anschaue, frage ich mich, ob das noch passt.
Grüße, picass

ich arbeite hier mit MPLAB-X, benutze aber viele Funktionen wie den Simulator nicht. Mit der alten MPLAB-IDE konnte ich vom C-Programm den erzeugeten Assembler-code anschauen, also links das C-Programm und recht denn erzeugten Code. Diese Funktion habe ich im MPLAB-X nicht entdeckt. Auch benutze ich noch den alten C18 Compiler, da meine Programme sonst kompiliert werden.
Das mit dem Springen des Wertes klingt für mich wie wenn der Poti springt. Hast du mal die Eingangsspannung nach gemessen?
-oder kann es sein das das Ergebnis < 0 ist? Was für einen Wert gibst Du denn aus, den eep-Wert oder den adc-Wert?

Die Sub-Routine sollte eigentlich stimmen, du benutzt doch einen PIC18!? Der sollte den Befehl SUBWFB kennen. Probiers doch damit einmal.

    sub1:
    MOVLB eephigh ;Bank auswählen                
    movff  eephigh,sub      ;eephigh soll nicht überschrieben werden: sichern
    movf    adclow,W,BANKED      ;adclow in WREG
    subwf  eeplow,F,BANKED      ;eep minus adc (WREG),ergebnis in F-REG! -WREG?
    movf    adchigh,W,BANKED      ;adchigh in WREG
    subwfb  eephigh,F,BANKED    ;eeprom minus adc (WREG),ergebnis in F-REG! - WREG?

    return 

was mir jetzt aufgefallen ist, Du schreibst das Ergebnis jedesmal ins W-Register, muss das Ergebnis nicht ins F-Register eep. Oder willst Du nur den Wert vergleichen? Dann kann es sein das Du das C bzw. N - Bit vor der Hi Subtration löschen mußt. So kenne ich es noch vom 6510 Motorola.

Pic18, du bist ja voll der Liebe! Dass du dir soviel Zeit nimmst, um in eine Materie rein zu schauen, welche nicht zu deinem üblichen Tageswerk gehört, ist 'ne ganz feine Sache. Wenn Hilfe von Nöten ist, bist du da! Das war der freundliche Teil   und nun zum anderen!

Stichwort: Banking. Man merkt und sieht auch an deinem Beispiel, dass du in der Tat da länger nicht mehr in der Materie steckst. Mit dem MPLAB X, der ja auch nicht mehr die neueste Entwicklungsumgebung darstellt, ist vieles geändert worden – auch der Umgang mit dem Banking. Früher mal war das voll der Horror: andauernd in den Datenblättern rascheln und nur ja keine falsche Bank wählen. Das ist heute mit dem X nicht mehr so verkniffen. Bei den SFR's, also den tagesüblichen ,,Befehlen", braucht man gar nichts zu machen. Die liegen allesamt  in einer Bank, der Numero 15, und bei diesen SFR's kann man sogar das Benennen der Bank unterlassen. Der Assembler ist ein schlaues Kerlchen und kombiniert sich da was Richtiges zusammen.

Stichwort: Wandelzeit für den ADC. Das ist auch recht unkritisch. Der braucht mindestens 1,7 µS, dann passt es. Meine PICs haben da kein Prob, weil ich meine Steuer-PICs mit nur 31kHz betreibe, da passt es immer. Zudem hatte ich mir das Leben leicht gemacht und die komplette Beispiel-Routine fürs ADC-Einlesen aus dem Datenblatt kopiert und übernommen. Zudem-Zwei: würde da was nicht passen, gäbe es häufiger zufällige, divergierende Ergebnisse. Das ist aber bei meinem Prob nicht der Fall: es gibt nur immer ein- und dasselbe Ergebnis und dessen Eintritt ist auch immer steuerbar.

Stichwort: der ADC-Wert wird rechtsbündig ausgelesen. Passt. Und ja: adc ist eine Kopie von ADRES

Stichwort: die übersandte Subtraktions-Routine. Ok, dass ,,Retten" des High-Register kann und sollte man auslassen, das stammte noch aus einem früheren Prog. Aber man merkt, dass du das Beispiel nur ,,beblickt" hattest, denn den Pferdefuß konntest du so kaum entdecken. Ich hatte nicht umsonst angeregt, die zwei Rechenübungen auszuführen. Macht man das, sieht man bei der ersten  Variablen das Erwartete, bei der zweiten V die Sprengfalle: diese Sub-Routine entspricht zwar vielen Vorlagen aus dem Inet, aber die sind genauso fehlerbehaftet wie die abgebildete: die ist Murks hoch sowieso und liefert zu 50 % Fehler. Du hast vermutlich keinen Compi mit installiertem MPLAB X. Falls doch, mache den Versuch, es lohnt sich.

Der Riesenfloh ist aber noch immer nicht dingfest. Ich versuchs mal mit einer Grobskizze des Prog-Ablaufes:
(1.) Generell soll an einem Port ein analoges Signal im Bereich zwischen ca. einem und ca. zwei Volt eingelesen werden. (2.) Dieses Signals wird in eine Zählschleife (ZS) geschickt, in welcher geschaut wird, wann es von der Größe her mit einer anderen Variablen in etwa korreliert, die ihre Größe aus einer Tabelle im EEProm raus gelesen hat. Das kann sie, weil in der ZS eine weitere Variable ,,die Runden" mitzählt. (3.) Die beiden Variablen – adc und eep – werden in der vermaledeiten Subtractions-Routine verglichen und (4.) entsprechend verzweigt: entweder zu (5.) ,,höher" oder (6.) zur Anzeige.
Diese 6 direkt aufeinander folgenden Teile des Hauptprogrammes werden in einer Dauerschleife durchlaufen: passt es, wird angezeigt, passt es noch nicht, wird nach oben geswitscht. Weil diese Dauerschleife immer bei Null beginnt, muss nicht extra ,,runter"-geswitscht werden. Also fortwährender Dauerlauf.

Gettz bitte Konzentration, es folgen drei zu vergleichende PIC-Einsätze, deren Progs sich nur in einer Winzigkeit unterscheiden:

1.) Im Soft-Simulator (SS) wird nur das ADC-Einlesen manipuliert, der Wert muss natürlich vorher ins Prog gestanzt werden. Aber alles andere ist ,,original", also gleich dem Prog in dem µC. Und im SS klappt Alles! Da kann man für den ADC eingeben, was man will, hinten kommt immer was Richtiges raus.

2.) Dasselbe Prog nun in den PIC geschoben, wobei natürlich der ADC für normalen Betrieb freigeschaltet wird. Mittels Trimmer wird die Eingangsspannung im genannten Bereich variiert und raus kommt, dass von Null bis 450 (die Zahlen sollen Temperaturen repräsentieren) alles palletti ist, aber 'nen winzigen Tacken höher getrimmt und schon ist das Malheur da: es wird nur noch 950 angezeigt. Trimmt man wieder runter, passt alles wieder, es werden sinnvolle Temps angezeigt.

3.) Gettz die Version numero Drei, gestern frisch gefunden:
Packt man das im SS harmonierende Prog in den PIC – der ADC ist wieder deaktiviert und stattdessen ein passender Wert im Prog vorgegeben - und ruft den HW-Debugger (HD) auf, dann – Tusch – gibts Überraschendes. Für den HD wird im Prog ein einziger StopWatch implementiert und zwar ganz am Ende der Prog-Schleife, nachdem also die Anzeige gefüttert und komplett beschickt war. Ein Wunder: auch in diesem Modus macht der PIC brav alles, was er sollte. Er schluckt jedwede Zahlenvorgabe für den ADC und schietet hinten das exakt passende Zahlen-Triumvirat aus!!!
Aber ganz alleine, so ohne Compi-Verbindung, schlägt der Riesenfloh zu!
Gettz ihr! Wo ist der?
Grüße, picass