Diese Idee? Naja, bin einfach davon ausgegangen, dass ohne "Exra-Befüllung" durch Anweisungen im Programm Register auf Null stehen. Hatte mich bislang einfach nicht um diese Bedingungen bekümmert. Die schiere Menge der 347 Seiten des Datenblattes hatte mich beim ersten Aufeinandertreffen nicht nur beeindruckt, sondern eher erschlagen. Systematisch durch gearbeit hatte ich diese Seitenflut nicht und mir auch nur ausgewählte Kapitel ausgedruckt.
Aber gettz habe ich mir das Kapitel 22.6 der "Reset State of Registers" zu Gemüte geführt und werde es zukünftig beachten. Hoffentlich.
Grüße, picass

Zitat von: picass in 07.10.2024, 16:34:20 CESTUnd da nach dem Einschalten des µC's erstmal alle Register von Natur aus auf Null liegen...

Wie warst du denn auf diese Idee gekommen?

Die TRIS Bits stehen doch defaultmäßig auch alle auf "1" für Eingang.
Wenn analog Eingang möglich, dann ist analog auch immer die Voreinstellung.
(von evtl. Config Bits mal abgesehen)

Schade!
Bin um 20 min zu spät! Verspätung ist aber entschuldigt, musste zwischenzeitlich viel Käsekuchen essen!
Das Datenblatt hatte ich nicht ausgewrungen, dort also keine Erleuchtung bezogen, aber mein heiß geschätztes Testboard - das mit dem langen Namen - hat diese Wahrheit ausgespuckt: ohne ANSEL explizit auf Null zu setzen, liefert z.B. ein Sprungbefehl, welcher mit dem nicht korrekten ANSEL-Bit versehen ist, völlig unerwartete Sprünge!   Dieses A-Bit auf "0", und schon prescht der Springer dorthin, wo er auch erwartet wird.
Dies Erkenntnis habe ich noch nicht in mein Nutzprog übernommen, weiß nicht, ob ich heute noch dazu kommen. Aber der Floh sollte sich besser aus eigenem Antrieb verziehen, denn nun sind nebenbei auch die Erkenntnisse da, dass den Hardware-Debugger keine Schuld triftt. Der reagiert auf externe Zustandsänderungen durch Wechsel von plus auf GND oder umgekehrt nunmehr prächtig. Auch die mit Zweifeln betrachteten Sprungbefehle nach Bit-Test-File-Abfrage arbeiten endlich so, wie erwünscht. Die Aussichten steigen! Zeit für den Floh: mach'n Abgang !
Ach ja, beinahe vergessen: danke für dein Datenblätterwald-Gerausche!

Räusper.........! Die Glaskugel von Volker hat einen hervorragenden (Durch-) Blick erlaubt: alle Neune! Es war doch mal wieder die nicht passende Port-Konfiguration.
Gruß, picass

Hallo picass,

ANSEL und ANSELH stehen nach Neustart bzw. Reset auf 11111111 bzw. ----1111.
Siehe Dabla Seiten 94, 95 und 254 und damit auf Analog!

Gruß
PICkel

Da sind wir uns - fast - einig: wie üblich wird der Fehler beim Nutzer liegen!
Aber fein, dass man so als Nutzer in der Not nicht alleine gelassen wird. Die ist schon erheblich: u.a. habe ich schon zwei PIC18F13K22 geschrottet und das Wort "Zeit" sollte ich nicht anfassen, sonst...  Sonst hatte ich schon daran gedacht, das Piccen einzustellen, weil mir das Gefummel mit den einzelnen Bits und der Kampf im Drahtverhau doch über die Grenzen wächst. Ob der Wechsel vom Vierzehner zum Dreizehner Glück brachte, wäre auch noch zu debattieren.
Dein Tipp, es könne was mit der Port-Config zu tun haben, ist insoweit gerechtfertigt, als mir das früher schon verschiedentlich ein Bein gestellt hatte. Aber diesmal nicht: es gibt nur drei Port-Pinne als Eingang und die sind alle digital. Das Digitale wird durch das Register ANSEL erledigt: wenn das auf "0" steht, ist's digital. Und da nach dem Einschalten des µC's erstmal alle Register von Natur aus auf Null liegen, müsste das reichen. Deswegen habe ich auf ein "clear" verzichtet.
Verzichtet habe ich auch auf eine Entprell-Programm-Routine. Wenn ich sonst nicht weiter komme, wird das noch geprüft. Aber die Einganssignale sind "eigentlich" sehr sauber.
Mittlerweile hatte ich die Sprungverzweigung nach Bit-Test-Befehlen im Verdacht. Dafür habe ich jetzt gerade wieder mein Lieblings-Board ausgekramt, das "PICkit Low Pin Count Demo"-Board. Da stricke ich den Eingangsteil meines Programmes um, sodass die Zuweisungen stimmen und werde gleich wieder auf die Flohsuche gehen. Ist für mich nicht möglich, abzusehen, wann der Schlag erfolgen wird. Bis jetzt ist der Floh immer noch ausgewichen!   Sollte ich den heute erschlagen können, wäre das ein besonders feines Geburtagsgeschenk an mich.
Grüße, picass

Du machst irgendwas falsch, sonst würde der Debugger funktionieren. ;-)

Meine Kristallkugel ist zwar sehr unzuverlässig, aber irgendwo im tiefsten Ratenebel,
(aufgrund fehlender Informationen) könnte ich mir eventuell vorstellen,
dass der entsprechende Pin nicht richtig als digitaler Eingang konfiguriert ist?

Kurz zur Klarstellung: das o.g. Projekt war in der Tat vollendet worden und gelungen.

Nun stehe ich vor einem neuen Problem mit dem Hardware-Debugging (HwD).
In meinem neusten Projekt "Reaktionstester" steckt noch ein Floh, den ich nicht finden kann. Die Hardware - also die PIC-Schaltung mit den Anschlüssen für die Schalter und das 100-Hz-Signal der Netzfrequenz sind mehrfach kontrolliert. Die benötigten Signale kommen alle an richtiger Stelle an. Das Prog läuft im Soft-Sim auch prima, dort ist kein Haken zu finden. Aber der PIC weigert sich, das in die Praxis umzusetzen. Also bliebe noch das HwD. Um da für ungestörte Verhältnisse zu sorgen, wurden fürs HwD die drei Signale vom Port A weg verlegt auf den Port B. An dessen 4 Pinnen liegen 3 Eingänge, der vierte Pin ist ein Ausgang (für LED an oder aus).
Aber der HwD scheint ein eigenwilliges Eigenleben zu führen. Er reagiert nicht auf die Drücke der beiden Tasten pb4 und pb5, obwohl dessen Signale richtig anliegen. Was geht da ab? Der müsste doch "eigentlich" real auf Portsignale reagieren? Die Abfrage erfolgt über übliche Sprungbefehle wie z.B. "btfss PORTB,4"  :also springen, wenn pb4 auf "1" liegt. Macht er aber nicht.
Kann der überhaupt nicht auf Signale von außen reagieren? Den Soft-Sim kann man derart nutzen, dass der Port-Pin stimuliert wird. Das klappt dort prima, nur ist beim HwD diese Funktion der Stimulation nicht vorgesehen, weil ja das echte Signal genutzt werden kann.
Komme nicht weiter und an die verplemperte Zeit mag ich nicht mehr denken.
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

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

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