Nochmals, da ist was dumm gelaufen, daher eine Bitte an den ADMIN den vorhergehenden Beitrag zu löschen!

movlw "H"                  schreibt den Wert Ascii(72) ins WREG
movwf OutLcdDten überträgt den  Inhalt des WREG in die Variable OutLcdDaten

Danach wird eine Subroutine zur Ausgabe des Zeichens aufgerufen.
Bei mir etwa so:

movlw  "H"
CALL        OutLcd_Data:
;..........................
  OutLcd_Data:
      ;sends 1 data-byte through the LCD 4bit-interface (2 nibbles)
  movwf    LcdData          ;copy Instruction from WREG to variable
  CALL    LcdBusy          ;LCD ready to receive next instruction?
  movf    LcdData,w        ;contents LCD-Data (Charakter)
  ANDLW    b'11110000'      ;Bitmask to select HI-nibble
  BANKSEL  LCD_LAT          ;Wechsel zu Bank 2
  movwf    LCD_LAT          ;LCD_PORT write Nibble to 4bit-databus
  bsf      LCD_RS            ;1=LCD-Data-mode
  bsf      LCD_E            ;enable LCD 4bit-databus
  nop                        ;toggle
  bcf      LCD_E            ;disable databus
  BANKSEL  0
  swapf    LcdData, w        ;change the nibbles
  andlw    b'11110000'      ;Bitmask to select the LO-nibble
  BANKSEL  LCD_LAT
  movwf    LCD_LAT          ;LATx /LCD_PORT write Nibble to 4bit-bus
  bsf      LCD_RS            ;1=LCD-Data-mode
  bsf      LCD_E            ;enable LCD 4bit-databus
  nop                        ;toggle
  bcf      LCD_E            ;databus is now disabled  
  bcf      LCD_RS            ;=0 LCD-control-mode
  BANKSEL  0                ;bank 0
  RETURN

Funktion:
LcdData = b'01001000' = d'72" = 0x48
Mit LcdBusy wird gefragt, ob das LCD mit etwas anderem beschäftig ist, z.B. einer anderen Ausgabe. Das Byte wird nun in sein oberes, bzw. unteres Nibble zerlegt und jedes Nibble wird einzeln mit
bsf Lcd_E in das LCD übertragen.
bsf LCD_RS schaltet das LCD auf Datenempfang um.
Daten: ausgebbare zeichen
bcf LCD_RS wird verwendet wenn eine Instruktion, z.B. eine Ausgabeadress verwendet werden soll.

mfG Ottmar

Versuche schon seit geraumer Zeit, so etwas Einfaches wie eine Übersetzung eines Progs, welches in der Alt-Form der Assemblersprache unter MPASM geschrieben wurde. Übrigens von dem Übervater "Sprut". Da gibts Dinge, rsp. Ausdrücke, an denen ich mich festbeiße, aber auch solche, über die ich nur den Kopf schütteln kann. Das erste Beispiel passt wohl für Beides. Da geht es in einem Prog - geschrieben für einen PIC16F84 - um die Initialisierung und letztlich die Ausgabe von Text auf ein LCD-Display. In der Ausgaberoutine "Hallo ausgeben" finden sich solche Zeilen wie:
- movlw 'H'
- movwf OutLcdDaten

Was habe ich übersehen? Bei diesem Befehl wird doch eine Zahl übergeben und kein Buchstabe?!
Grüße, picass

Ich würde einen digitalen Sensor vorziehen. Sonst hast du evtl. wieder Umrechnungsprobleme.
Hier http://www.stefan-buchgeher.info/elektronik/feuchtemodul2/feuchtemodul2_kap04.html habe ich ein älteres Projekt mit RS232 Schnittstelle gefunden. Es ist zwar in C geschrieben, aber der ASM-Code ist unter download http://www.stefan-buchgeher.info/elektronik/feuchtemodul2/feuchtemodul2.zip auch da. Vielleicht kannst Du damit was anfangen.

Wie kann man nur NICHT an den guten, alten Sprut denken!    Tsssss!
Danke, PICkel. Dieses File habe ich runter geladen und werde versuchen, es in "meine" Assembler-Version - also die mit dem "X" und v.5.20 - zu übersetzen. Anzeigen habe ich noch irgendwo im Regal versteckt. Das wäre schon mal 'ne Menge weiter.
Um dem digitalen Wirrwar zu entgehen, hatte ich ja schon den analogen Datenübertragungsweg für Sensoren genannt. Der nächste Punkt wäre nun, eine Tabelle oder wieder 'ne Formel für solchen Sensor wie den HIH 5031-001 von Honeywell zu finden. Aber bitte: das soll keine Aufforderung darstellen, das Suchen für einen zu Faulen zu übernehmen. Ist nur mein Gedanke an die nächste Baustelle....
Nochmal danke...., einmal mehr kann nicht schaden!
Grüße, picass

Was ASM für das LC-Display betrifft:
https://www.sprut.de/electronic/pic/programm/lcd.htm

Ist für 16F84, sollte sich aber ohne große Probleme an andere PICs anpassen lassen.

Gruß
PICkel

Es ist ein wenig undankbar, über die Funktion der o.g. beschriebenen, fertig gekauften Anlage so was wie ein entgültiges Urteil zu sprechen. Klar ist allerdings eines: im serienmäßigen Zustand und der damit verbunden, teils eingeschränkten Einstellbarkeit der Parameter ist die Anlage nur teilweise nützlich, ganz häufig leider gar nicht. Es gibt viel zu viele Fälle, in denen sie nicht oder falsch oder gar nicht nachvollziebar arbeitet. So ist sie bei bestens trockener und warmer, teils heißer Luft im Dauerstreik: tagelang rührt sich nichts und lässt diese Chance komplett verstreichen. Sobald es kalt draußen wird und damit meine ich Temps unterhalb von 18° C, erweckt sie zum Leben und besonders häufig, rsp. dauernd arbeitet sie, wenn es echt kalt draußen ist. Dann kühlt sie den bis dahin warmen Keller deutlich runter auf kalt. Am störensten ist sie aber, wenn sie Luft von draußen nach innen befördert, wenn es draußen regnet. Nach meinem Geschmack ist es dann draußen nicht nur feucht, sondern nass, was sich gänzlich ohne hoch präzise Sensoren verifizieren lässt, wenn man - ausgestattet mit der von der Natur auf dem Kopf plazierten Glatze - ein paar Schritte nach draußen tritt. Ebenso wenig sinnvoll finde ich, wenn das LCD-Display vermeldet, dass draußen eine Luftfeutigkeit von 88 % herrrscht, im Keller nur 80%, und dann die deutlich feuchtere Luft von draußen nach drinnen gepumpt wird. Die Formel ist aus meiner Sicht schon recht krude, wenn sie so was für gut hält.
Das Gerät und seinen Preis würde ich für gut halten, wenn es mehr oder überhaupt Möglichkeiten bieten könnte, an den Parameter-Schrauben zu drehen. Und wenn es in der Lage wäre, draußen Regen zu erkennen.

Wiederhole: es wird sich nicht vermeiden lassen, da tatsächlich selbst Hand anzulegen.

Dabei - und u.a. deswegen schreibe ich diesen Beitrag - brauche ich aber eure Hilfe. Das eigentliche Steuerprog würde ich wohl selbst schaffen. Wo es bei meinen µC-"Künsten" hakt, ist sowohl das Nutzen eines LCD-Displays unter Assembler als auch das Auslesen von Sensoren, welche digitale Formate für die Datenübertragung nutzen.

Eigentlich möchte ich nicht wirklich unbedingt eine neue Programmiersprache - egal, wie sie heißt - lernen müssen, nur um diese beiden genannten Techniken verwenden zu können. In Hochsprachen gibt es doch - wenn ich das richtig verstehe - sogenannte Bibliotheken, welche zugeschnitten auf z.B. einen Sensor es ermöglichen, das Gewusel der Zeitprotokolle und der Impulszählung und all' solchem Schweinskram der Biblio zu überlassen und "nur" ein paar Bedien-Parameter anzupassen. So was müsste es doch unter Assembler auch geben. Oder wenn nicht: da müssten doch irdenwo im Inet fertige Programmteile existieren, in denen das beispielhaft vorgestrampelt ist. Bei Microchip gabs doch früher mal unendlich viele Programm-Sammlungen - deren Namen begann in der Regel mit AN... - für bestimmte Techniken.

Habe aber eben bei Reichel geschaut: es gibt auch für Feuchtemessungen Sensoren mit analogem Ausgang. Das wäre zwecks der von mir geschilderten noch nicht vorhandenen Fähigkeit, Digitales im Sensorenbereich zu nutzen, doch eine gute Empfehlung?! Oder übersehe ich da was?
Also verblieben als drängenste Prob-Felder das Ansteuern von LCD-Displays und diese vermaledeite Formel, welche mathematische Klimmzüge erfordert. Na, was meint ihr? Wäre jemand in Stimmung, da mit helfender Hand einzusteigen? Oder gibt es Hinweise auf nutzbare Beispiele?
Grüße, picass

Oben schrieb ich:"...die Hardware kommt first!" Entsprechend nun als Anhang das Programm, geschrieben in der "mittleren" Version des MPASM, also MPASM X v 5.20 und das für den PIC18F13K22. Gerade noch getestet: es funktioniert.

Die Erzeugung des Zufalls - dieses Prob hatte mich ja lange gehindert, weil es als doch kompliziert erschien - ist nach meinem Geschmack bestens gelöst und das mit einfachsten Mitteln. Is klar, wir werden hier keine wissenschaftlich untermauerten Statistiken drüber stülpen, wozu auch. Nach momentaner Einstellung gibt es vorab eine feste Sekunde Wartezeit und dann folgt die durch Zufall generierte variable Phase, die im Moment zwischen null und 5 Sekunden liegt. Das langt bestens, um auf dem falschen Fuß erwischt zu werden. Wem das nicht langen sollte, der kann durch einfaches Verändern einer "2" durch Vergrößern dieser Zahl die bange Wartezeit verlängern.

Die Hardware beschreibe ich an dieser Stelle erst mal nicht weiter, das war bereits oben passiert. Eine extra Platine mit sämtlichen Bauteilen hatte ich nicht verwendet, sondern eine fertige Schaltung für diese 3x7-seg-Anzeige benutzt. Für die  100-Hz-Signal-Erzeugung und das Entprellen der beiden Tasten hatte ich einen LM311 und ein IC CD4014 mit Schmitt-Triggern auf Lochrasterplatte gebaut. Falls doch jemand Bedarf an Hardware-Infos haben sollte, bitte hier melden.
In der Zip-Datei befindet sich der komplette MPLAB X - Ordner für dieses Projekt und in diesem Ordner noch zusätzlich eine Textdatei mit dem Prog.
Grüße, picass
reaktion12.X.zip

Das "morgen" war dann doch übermorgen, aber lass' ma. Aber 'nu haben fertig!

Die Mittelwertbildung ist eingefügt und das läuft dann so: während acht Reaktionsmessungen wird der aktuelle Wert auf addiert. Nach diesen Achten wird die Summe durch 8 geteilt und auf einfache Weise - shift right - der Mittelwert gebildet, welcher dann am Schluss zur Anzeige gelangt.

Is klar, das anschwellende Prog bedurfte einer Säuberung, und auch die Hardware beschwerte sich, weil die Verkablung für mechanische Belastung nicht gedacht war. Zwecks der vielen Umprogrammierungen  zog der Adpapter klammheimlich ein Kabel los, welches am µC-Bein'chen angelötet war und daraufhin meckerte der PICkit3-Programmer. Na ja, Geburtswehen halt.

So wie die Schaltung ist, kann sie bleiben. Sie ist gut und funktioniert ebenso. Die erste Mittelwert wirft 0,22 Sekunden Reaktionszeit aus. Bietet jemand mehr? Also weniger?
Grüße, picass

Hab' meinen Spass mit der Schaltung!
Die erziehlten Reaktionswerte trösten über das Ungemach der Erstellung hinweg. Es hat sich gelohnt, für die Stopptaste etwas Geld auf den Tisch zu legen und was Gutes zu installieren. Die Taste lässt sich zuverlässig und vor allem fix drücken und sie hat einen klaren Druckpunkt.
Heute wurde die Messzeit - also die Wartezeit zwischen Start und Aufleuchten der roten Lampe - variiert: erst gibts eine Sec Vorlauf, dann kommt die durch Zufall erzeugte Zeit mal zwei. Das ergibt eine gute Bandbreite. Eventuell noch mal drei, da kann man nun spielen. Morgen kommt - hoffentlich - das Aufaddieren einiger Messwerte und die Mittelwertbildung. Aber erst mal Spass haben mit dem Testgerät.
Grüße, picass

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