Neueste Beiträge

#1
P
Projekte und Eigenbau / Aw: Feuchten Keller trocknen
Letzter Beitrag von PICkel - Heute um 14:56:33 CEST
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
#2
P
Projekte und Eigenbau / Aw: Feuchten Keller trocknen
Letzter Beitrag von picass - Heute um 13:44:36 CEST
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
#3
P
Projekte und Eigenbau / Aw: Reaktionszeit messen
Letzter Beitrag von picass - Gestern um 11:38:14 CEST
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
#4
P
Projekte und Eigenbau / Aw: Reaktionszeit messen
Letzter Beitrag von picass - 11.10.2024, 19:13:30 CEST
Das "morgen" war dann doch übermorgen, aber lass' ma. >:D 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? >:D
Grüße, picass
#5
P
Projekte und Eigenbau / Aw: Reaktionszeit messen
Letzter Beitrag von picass - 09.10.2024, 19:30:28 CEST
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. O:-)
Grüße, picass
#6
P
Mikrocontroller / Aw: Hardware-Debugging läuft n...
Letzter Beitrag von picass - 09.10.2024, 11:02:18 CEST
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. >:D
Grüße, picass
#7
V
Mikrocontroller / Aw: Hardware-Debugging läuft n...
Letzter Beitrag von vloki - 09.10.2024, 09:05:00 CEST
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)
#8
P
Projekte und Eigenbau / Aw: Reaktionszeit messen
Letzter Beitrag von picass - 08.10.2024, 18:55:48 CEST
PLATSCH !......Igitt, diese ekligen Spritzer !
Er ist erschlagen, der RIESEN-Floh !

Seit gerade hat die Reaktions-Schaltung ihre Arbeit aufgenommen: drückt man die grüne Bereitschaftstaste, wird nach Ablauf der im Hintergrund erzeugten Zufallszahl die große, rote LED-Lampe angezündet und die Messung der Zeit startet. Nach Drücken der fetten, grünen Stopp-Taste wird diese Zeit nach kürzester Berechnung auch angezeigt. Klappt wunderbar.
JETZT! Vorher war das 'ne wüste Schinderei und über die benötigte Zeit rede ich nicht, das verdränge ich.

Der Riesen-Floh war die nicht korrekte Port-Initialisierung, genauer gesagt, für die Abfrage der Tastendrücke musste beim entsprechenden Port das ANSEL-Register auf Null gesetzt werden, um den digitalen Input zu gewährleisten. Is klar, nach dem Igitt-Manöver waren noch zwei weitere "Anpassungen" notwendig, aber nach dem TOTSCHLAG war der Weg frei.
Nun könnten noch Modifikationen möglich sein wie z.B. die Zufallszeit noch etwas auszuweiten. Oder es könnten die Ergebnisse von etwa 8 Mess-Durchläufen gesammelt und danach der ermittelte Mittelwert auf die Anzeige geschoben werden.

Aber jetzt erst mal bin ich - nein, nicht erfreut, dafür war die Schinderei zu groß - erleichtert, dass dat Ding endlich funktioniert! Auf den Sieg werde ich mir heute Abend was gönnen, z.B. ein Glas Rotwein zum Käseknäcke. Oder so.
Grüße vom höchst Erleichterten picass
#9
P
Mikrocontroller / Aw: Hardware-Debugging läuft n...
Letzter Beitrag von picass - 07.10.2024, 18:19:05 CEST
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! :o  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 ! >:D
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
#10
P
Mikrocontroller / Aw: Hardware-Debugging läuft n...
Letzter Beitrag von PICkel - 07.10.2024, 17:44:51 CEST
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