Das Fred-Thema entspricht zunächst einer Absichtserklärung (AE).

Eigentlich wollte ich nur vermelden, dass die vor zwei Tagen erst bestellten 32-ziger-PICs ganz entgegen aller Erwartungen zwecks der Paket-Flut vor Weihnachten tatsächlich heute, am 24.12., Vormittags noch angeliefert wurden. Ein fettes Kompliment an die DHL! Die zwei PICs lege ich mir heute mal unverdächtig – also ohne, dass meine Frau davon etwas bemerken muss – unter den nicht vorhandenen Weihnachtsbaum...., also irgendwo zwischen die anderen Geschenke.    Für mich echt eine Freude. Aber halt auch erst nur eine AE.

Ob es gelingt, einen 32-ziger-PIC zum Verarbeiten von Basic zu bewegen, wird für mich eine spannende Auseinandersetzung. Es gibt/gab genau den im F-Thema genannten PIC-TYP auch schon fertig mit dem Basic-Interpreter vermählt zu kaufen. Diese Kombi nennt sich dann Micromite. Also ähnlich dem Picomite, welcher auf dem Raspi-Pi mit der RP2040-CPU und verbandeltem Basic läuft. Um die Namensverwirrung voran zu treiben: Der Typ von Basic, welcher auf beiden sehr unterschiedlichen CPU-Typen läuft/ laufen soll, nennt sich ,,MMBasic". Das ist hoffentlich wirklich gleich. Wenn ja, dann könnte es mit dem 32-PIC und Basic was werden.

Aber...... leider ist ja nun Weihnachten.  Mit den 32-PIC // Basic – Vermählungen wirds also wohl ein paar Tage dauern. Gettz ist Gänsekeule, Kuchen backen und verputzen, sich mit der puckligen Verwandtschaft arrangieren und – ach ja – Harmonie angesagt. Letzteres ,,natürlich" in höchstem Maße. Allerdings werde ich das in ertragbaren Grenzen halten. Eine Überschreitung wäre dann doch 'ne Chance für den Weihnachts-32-ziger-PIC. Gettz ab zum Froh-Sein....!
Grüße, picass

MMBasic auf einem 32-ziger-PIC: das Gesamtwerk nennt sich dann Picomite.
Nach über einem Dutzend an Detail-Probs, gelöst an den Gänsekeulen-Feiertagen immer mal so in einer Lücke, stehe ich nun direkt vor der Ziellinie! Aber eben auch genau da: der letzte Schritt fehlt noch!

Formales vorweg: bei den nachfolgenden Beschreibungen  verwende ich als Kürzel für als gelungen angesehene Aktionen dieses :  ,, EiO"

Um das Prinzip zu skizzieren: Is klar – der richtige Typ eines PICs muss ran, für den Anfang sicher in der DIL-Version: EiO
Dann braucht es einen tauglichen Brenner: hier der PICkit3, also EiO
Ein passendes Brenn-Prog: hier die MPLAB IPE, also EiO
Weiter benötigt ein ,,Experimentier-Board", welches den PIC aufnimmt: EiO
Danach das Brennen der Datei, welche das MMBasic für genau diesen PIC-Typ enthält: EiO
Dann ein Interface (IF), welches die serielle Kommunikation zwischen PC und PIC übernimmt: EiO
Das Ziel wäre, über dieses USB zu Seriell-IF irgendwas Sinnvolles zum Testen rüber zu senden: Zappenduster!

Zunächst ließ sich alles gut an. Dann klemmte es erstmals bei Verwendung der bis dato zuverlässig funktionierende IPE. Die wollte sich einfach nicht umstellen lassen vom 18F84K22 auf den 32-ziger-PIC. Irgendwann war ich es leid und habe die installierte Version 3.20 und auch die neuere 6.0 und auch den C8-Compiler komplett raus geworfen, also gelöscht und die neueste Version der MPLAB-Umgebung, die Vers. 6.05 installiert. Davon allerdings nur die IPE und da auch nur das für 32-ziger-PICs. Das brachte Erfolg.

Dann das ganze Hardware-Gestrampel! War nach der guten, wirklich zu Recht von den Heise-Redakteuren gelobten Dokumentation und den abgedruckten Schaltbildern zwar möglich, aber letztlich doch ein ziemliches Gefummel, eine Spannungsversorgung sollte ja auch noch rein.

Danach wurde es übel: Das Interface wurde vom Win10 zwar gefunden und es gab auch eine eingeblendete Meldung, das Gerät wäre einsatzbereit, aber der Gerätemanager zeigte ein gelbes Ausrufezeichen und war sich selbst nicht so sicher, was nun ginge oder nicht. Jedenfalls wurde nicht eindeutig ein passender Treiber geladen. Dann also Recherche im Inet und gleich 4 mögliche Treiber vom Hersteller des Chips ,,CP2102" geladen. Einen davon ausgewählt und dessen Install wurde als Erfolg vermeldet, auch der Gerätemanager gab anschließend seine Zustimmung.

Die Einrichtung belief sich u.a. auf die Auswahl des ser. Ports am PC, die Übertragungs-Geschwindigkeit – hier 9800 B - ......, das hatte ja beim µC-"Vorgänger", dem PiPico auch geklappt.

Aber dann das dicke Ende: es kommt keine Kommunikation zustande. Das zeigt sich schon daran, dass das Terminal-Prog "VT100" mit seinem eingebauten Micro-Editor sich weigert, am ,,Prompt", also der Stelle für den Cursor den sonst üblichen Pfeil nach rechts zu zeigen. Das wäre ja noch verschmerzbar, aber das Prog nimmt keinerlei Eingabe von der PC-Tastatur an. Egal, ob Zahlen, Buchstaben, Funktionstasten, es tut sich nix! Direkt im Basic-Prog, dem "PICO-MMB", war es nicht besser.

Also den Oszi ran. Das USB-Interface führt in Richtung PIC drei Leitungen weiter: einmal GND, also Masse und dann die Leitungen ,,RXD" und ,,TXD". Die sollen laut Schaltplan halt mit dem PIC verbunden werden, wobei die Daten- und die Taktleitung quasi gekreuzt am PIC angeschlossen werden. Das ist nach Plan nicht misszuverstehen. In die beiden ,,Daten-Leitungen" wurde je ein 1 kO-Widerstand eingebaut. In der Beschreibung fand sich der Hinweis, dass dies aus Sicherheitsgründen erfolgen sollte, falls der CP2102 mit 5 Volt betrieben würde. Dessen Betriebsspannung habe ich nicht gemessen, die Anschlussleitungen sind derart winzig und einen Schaltplan gibts für das IF eh nicht und mit den dicken Messspitzen wollte ich da kein Unheil anrichten. Das wird aber – siehe nachstehend – nicht das Prob. sein.
Alle Anschlüsse und alle verlegten Leitungen auf dem Lochraster-Board habe ich sorgfältigst ausgeführt, mehrfach optisch und mit dem Ohm-Meter kontrolliert und anschließend alle Spannungen überprüft: dies alles scheint perfekt zu sein. Der PIC bekommt seine 3,3 Volt und diese Spannung liegt im Leerlauf  auch auf den beiden Leitungen RXD u TXD.

Gettz der Oszi: am TXD-Ausgangspin (Senden) des Interfaces kann man im zeitlichen Bereich von 50 und/oder 100 µS/Einheit mit gutem Willen Rechtecksignale erkennen. Die sind aber nicht sauber darstellbar, es ist lediglich auf der Grundlinie – also nahe GND – so was wie das untere Ende der Rechtecke sichtbar. Das, was da unten sichtbar ist, sieht nach einem sauberen Signal aus. Aber das alles ist sehr verhuscht und mit der SingleShot-Funktion konnte ich nichts einfangen. Auf der anderen Leitung, der ,,RXD" konnte ich auch bei bestem Willen kein Zucken, keinerlei Abweichung des Dauerpegels von 3,3 Volt erkennen.

Und nu' bin ich mehrere Runden ratlos. Einen neuen Interfacebautstein habe ich bestellt, aber wann der kommt....?!
Was gettz? Wo was machen?
Grüße, picass

Da fehlt der 10uF Kondensator am Controller.
Oder hab ich den übersehen ?

Was für ein 10 µF- C ?
Laut Schaltbild soll am Pin 20 ein 47 µF-Tantal angeschlossen werden. Der sitzt da, das ist die kleine, okerfarbene Perle. Dieser C ist zur Glättung einer intern erzeugten Spannungsreferenz nötig.
Wollte mir aber heute mit dem Oszzi auch die Speisespannungen anschauen, ob es da Schwinger geben sollte. Inzwischen habe ich aber den PIC selbst im Verdacht, mehr dazu später.
Grüße, picass

32-ziger PIC kann Basic !


Ich muss jetzt ,,einen Lauten machen", das geht nicht anders! Das Traumziel ist erreicht, seit heute,  dem 28.12.22 um 09:40 Uhr, hat der PIC32MX170F250 die Kommunikation mit seinem Basic-Dialekt über die Terminal-Schnittstelle aufgenommen.
Gut....: ,,print ,,hello"" und ,,print 1/7" sind noch nicht so der Bringer, aber er kann es ! Is klar, da muss noch Etliches verifiziert werden, aber der Durchbruch ist da.

Warum hatte es vorher nicht geklappt? Die Überprüfung der Betriebsspannungen – s.o. - ergab ziemliche Ruhe auf den Leitungen. Aber....räusper.... der zuletzt in der IC-Fassung Sitzende war zurecht in Verdacht geraten: der war gar nicht programmiert! Das also nachgeholt, ein paar Einstellungen und TUSCH !
Diesen noch Sprachunkundigen hatte ich gestern Abend noch ganz schnell in die Fassung gequetscht, weil ich den anderen, den ersten der beiden Typen in Verdacht hatte, beim Gestrampel mit der 5.20-IPE und ihren Voreinstellungen für den PIC18F14 und dessen Spannung von 5 Volt, was sich ja nicht so ändern lassen wollte, einen Klatsch weg eingefangen zu haben.

Gut, den jetzt eben auch noch ausprobiert und – Tusch2 - : auch der kann nun Eins-geteilt-durch-Sieben.
Warum ging das gestern nicht?   Woher soll ich das wissen?   An der Hardware hab ich heute nichts geändert, nur die grundsätzlichen Einstellungen für das Interface noch mal durchgegangen. Einzige bewußte Änderung: die Übertragung von 9800 auf 38400 baud hoch gesetzt. Ob es das war? Glaube ich weniger, aber nu' isses halt passiert und ich hoffe, es bleibt auch so.

Damit eröffnet sich – bin noch vorsichtig: wenn es so bleibt – ein riesiges Feld an Möglichkeiten. Eines ist schon beschlossen: wenn der 32-PIC durch hält, dann werde ich ihn zukünftig verwenden, nicht den Rasperry Pi Pico. Der kommt nur dann zum Zuge, wenn es anders nicht geht oder der ein Feature ermöglichen sollte, welches sonst nicht greifbar wäre. Der Pi Pico ist nominell ca. 3x so schnell, zumindest von seinem Systemtakt her, aber das ist mir persönlich erst mal völlig wurscht. 50 MHz anstelle von 31,25 Khz ist ja auch schon mal ein ,,netter" Sprung.

Bin im Moment recht glücklich, so mC-mäßig !
Grüße, picass

Glücklich über die Ziellinie gelaufen und direkt dahinter ins Straucheln geraten  und gestürzt!

Zur o.g. ,,Verifizierung" sollte als Zweites die Ermittlung der Arbeitsgeschwindigkeit des 32-ziger-PICs erfolgen. Dazu wurde das Prog – beinhaltend die Abarbeitung derjenigen Formel, welche für das ,,Trocken-Keller"-Projekt benötigt wird – geladen und ausgeführt. Also versucht, auszuführen...!
Da gabs dann die Meckermeldung: ,,unbekannte Syntax" und das bezog sich explizit auf die Ermittlung des Logarithmus zur Basis 10. Und da war Schluss mit Lustig, da warf das Micromite-Basic den Reiter ab.
Während diese Funktion in der Dokumentation für das Picomite-Basic, also diejenige MMBasic-Version, welche für den Rasberry Pi Pico geschrieben ist, enthalten ist, fehlt die F in der Doku für den PIC, also im Micromite-Basic. Das Micromite ist also doch kein komplett Gleiches wie das Picomite, sondern – zumindest, was die Rechenoperation anbelangt – eine Teilmenge.

Wie gewonnen, so zerronnen! Ohne die Ermittlung des dekadischen Logarithmus'ses kann ich das gesamte Bascic-Prog für den 32-ziger PIC vergessen. Es bleiben nur drei Wege aus dem Dilemma und das auch nur theoretisch:

- es gäbe einen beschreitbaren Weg, den dekadischen L ,,zu Fuß" zu berechnen. Das wird ja von diversen ,,Autoren" im Inet behauptet, aber nur mit derart verkürzten und anonymen und kryptischen Kürzeln ,,ausgeführt", dass sie ganz sicher selbst nicht verstanden haben, was sie da von anderen abgeschrieben haben. Is klar – kein einziges Rechenbeispiel konnten/wollten sie in ihrer Wissens-Allmacht beibringen.

- ein gleichzeitig Gönner wie Könner fügt die vermisste Mathe-Funktion (dekadischer L), welche ja in dem parallelen Basic-Dialekt beinhaltet ist, auch der Micromite-Basic-Version hinzu.

- Abkehr vom PIC und weiter mit dem Picomite und dem Rasberry.

Das Leben ist ungerecht..., hier mal wieder ein Beispiel aus der hatten Praxis.
Grüße, picass

Nachtrag: der "natürliche" Logarthmus lässt sich laut Doku bearbeiten, ..... falls das irgendwie weiter helfen sollte.
 

Laut Datenblatt sind es 10uF.
Da würde ich mal im Netz suchen, vielleicht hat ja jemand die Mathematischen
funktionen dort eingefügt.

Kreisch ! Jubel und so weiter.....

Man/frau kennt es ja! Hoffentlich: Wo ein Wille ist, da könnte auch ein Gebüsch in erreichbarer Nähe sein.
Habe inzwischen gleich zwei Wege gefunden, den 32-ziger-PIC zu retten.

Weg eins: Das wäre die Interpolation zwischen den vorausberechneten Werten des Logarithmus. Da in diesem Fall (feuchter Keller) nur L's von 0 bis 5 zu berechnen wären, wäre das ja noch übersichtlich und die Genauigkeit akzeptabel. Aktzeptabel auch deswegen, weil es genau zwei Werte insgesamt zu berechnen gilt, nämlich die Zahlen der Taupunkt-Temperatur für innen und außen. Eine prinzipielle Rechen-Ungenauigkeit würde bei beiden Zahlen in nahezu gleicher Weise eingehen und damit – tusch – unversehens eine gute Genauigkeit möglich werden lassen.

Weg zwei: El-Nix-Raffo hat nach dem Wühlen im Wust diverser Unterlagen und ihrem Studium was entdeckt!   Entdeckt wurde, dass es einen Zusammenhang zwischen natürlichem Logarithmus und solchem zur Basis 10 (dekadischer) gibt: Da hat die Eulersche Zahl (e) ihre Hand mit im Spiel. Das geht dann so:
ln(x) = log(x) : log(e)

Die Formel lässt sich umstellen auf:
log(x) = ln(x) * log(e)

Wenn man – wie das Micromite – keinen Logarithmus zur Basis 10 berechnen kann, ist diese Formel witzlos. Also fast.
Die Eulersche Zahl ist ja bekannt und deren Logarithmus-Wert zur Basis 10 kann man ja im Voraus berechnen, zumindest dann, wenn man wie ich einen über 30 Jahre alten HP41CV sein Eigen nennt. Diese Vorausberechnete als Konstante in die Formel eingesetzt, dann bliebe ,,nur" noch der natürliche Logarithmus zu berechen.....! Und das kann das Micromite ja, wie vorher benannt und just eben getestet. Damit steht der Bewältigung der Formel zur Berechnung der Taupunkttemperaturen nichts mehr im Weg! Ähm, nichts im Moment Bekanntes... ! Und damit könnte der 32-ziger-PIC gerettet sein, rsp. für dieses Prog nutzbar.
Es steht noch aus, die übrigen ,,Zutaten" wie Anschluss eines kleinen Displays und der Feuchte- u. Temp-Fühler via I²C zu testen. Wenn das auch...., dann kann es mit dem 32-ziger-Piccen losgehen.

Ach ja, nun weiß ich auch, warum gestern die Kommunikation nicht klappen wollte. Es liegt tatsächlich an der einzigen, heute offensichtlich durchgeführten Änderung: die USB zu Seriell -Schnittstelle arbeitet nicht mit 9800 baud, sondern verlangt 38400 baud. Das  ist wahrscheinlich in dem Basic, welches dem PIC einverleibt wurde, so implementiert. Je nun, wenns sein muss.....!
Grüße aus der 32-bit-Welt, picass

Zitat von: Peter in 28.12.2022, 14:10:21 CETLaut Datenblatt sind es 10uF.

Zu dem Wert des von dir genannten Kondensators enthält das Manual für das ,,Micromite"-Basic auf S.11 eine Ausführung, sinngemäß: Dieser C muss ein hohe Qualität haben. Z.B. darf kein ,,normaler" Elko genommen werden. Es muss entweder ein 47 µF Tantal sein oder aber ein 10 µF  X7R Multilayer-Ceramic.

Neugierig war ich auf die Geschwindigkeit bei der Abarbeitung eines Basic-Programmes. Einen Vorgeschmack gibt das Programm, mit welchem der Taupunkt – s.o. - berechnet wird. In diesem Prog sind 16 einzelne Berechnungen enthalten. Die hatte ich in einer Schleife zusammen gefasst, und daran eine Pause von 1 mS angefügt. Zu Anfang der Schleife wird ein Port auf ,,1" gesetzt und  an deren Ende wieder auf ,,0".
Der DigiOszi zeigt für die High-Zeit – also die Schleife mit der Formelberechnung – genau 640 µS Dauer an, also 0,000 640 Sec.

Da diese Formelberechnung im gesamten Programm zur Keller-Entfeuchtung der mit Abstand dickste Brocken sein dürfte und zu diesem nur noch die Ausgabe der Werte auf einem kleinen LCD-Bildschirm kommen, wird das Alles wohl auf weniger als eine Sekunde kommen. Ganz schön flott..... Wenn meine PIC18F... in einem Vergleich ein einfach motorisierter Wagen aus dem Volkswagenkonzern wäre, etwa ein Polo, dann wäre der PIC32MX170 incluciv des Micromite-Basic's ein echter Porsche!
Der haut was wech....!
Grüße, picass

Das war der letzte, wichtige, noch fehlende Stein in der Kette, zu glauben, den Aufbruch vom 8-Bitter zu einem 32-Bitter-PIC   - programmiert mit Basic – geschafft zu haben: die Nutzung eines Displays. Ist auch vollbracht!

Was das Alles für mein zukünftiges Programmieren bedeutet, mag ich sicherlich noch gar nicht so recht zu beurteilen. Aber am Beispiel für die Inbetriebnahme des s/w-LCD-Displays mit dem allseits verbreiteten HD44780 Display-Controller lassen sich die neuen Rahmenbedingungen gut demonstrieren. Die Arbeiten für den zusätzlichen Anschluss dieses Displays auf der Lochrasterplatte, auf welcher der PIC ja bereits saß, beliefen sich mit aus Gründen der Betriebssicherheit ausführlichem Studium entsprechender Unterlagen und dem Verlegen der Anschlüsse, also auch dem Löten auf 2 Stunden. Nach dem Anschalten des PCs und der beiden Netzteile  (5 Volt extra für das Display) vergingen nach dem Start des Terminalprogrammes und der dortigen Eingabe von zwei Zeilen Code bis damit zum Erfolg der Anzeige vielleicht 10 min.
Mich erinnernd an das vorige Gestrampel mit der Assemblerprogrammierung fehlen mir jetzt schlicht die passenden Worte. Vielleicht gerade diese doch:
,,Unfassbar" und ,,gut"
Der übliche Tagesgruß fällt heute anders aus.

Jetzt ist auch das geschafft, was im "Feuchte-Keller"-Programm den sinngebensten Anteil hat: die Messung von Temperatur und Luftfeuchtigkeit. Genutzt wurde dafür der im MMBasic-Beispiel vorgestellte Sensor "DHT22". Der ist recht preiswert und soll laut Datenblatt ordentlich genau sein.
Beim ersten Test mit dem entsprechenden Prog-Schnipsel lief nichts. Aha, da gabs so eine eher beiläufige Erwähnung, man sollte doch mal in einer best. Readme-Datei nachschauen. Dort der Hinweis, dass die Routine, rsp. der Befehl, welcher zum Auslesen dieses Sensors gebraucht wurde, aus der aktuellsten MMBasic-Version raus gekegelt worden wäre - früher stand er drin!   Nun müsse man eine "dort" (Link) zu findende Datei down laden und irgendwo in sein Prog einfügen. Das war dann eine sehr opulente Datei, ein Subroutine in "C" geschrieben. Na gut, ab dem Einfügen lief es wirklich sehr einfach weiter: Prog starten und schon standen da auf eine Dezimalstelle genau die Werte für Temp und Feuchte.

Die stimmten allerdings nicht mit Vergleichswerten anderer Geräte in meinem Arbeitsraum überein. Anstelle von 17,8° C (unsere Regierung mag das so!) wurden über 22° C angezeigt. Heute, also einen Tag später stimmten die beiden Werte aber sehr genau mit denen der Vergleichsgeräte überein. Muss mal ein Weilchen beobachtet werden.
Unterm Strich war die Nutzung im MMBasic erschütternd einfach. Wenn ich da so in einen anderen Fred hier im Forum über die stolprige Inbetriebnahme eines TempSensor lese, ne, geh' mir wech'.... Da ist dieses MMBasic schon was Feines, zumindest wenn man an die Einfachheit der Inbetriebnahme diverser Geräte denkt.
Allerdings hoffe ich, dass dieser "C"-Schnipsel den Speicherplatz nicht zu arg belastet.
Grüße, picass