PIC-Microcontroller

Befinde mich in einem unbefriedigenden Zustand und dem einer Verwirrung:
irgendwie hakt es beim Assemblern: erst die Entdeckung der Flag-Unzuverlässigkeit, dann der tückischen und realen Möglichkeit, sich Rechenfehler einzufangen, und das Wichtigste: das Rechnen überhaupt, wenn es sich nicht gerade um eine 8-bit-Addition oder Multiplikation handelt. Das sollte nicht wirklich so weiter gehen, sich wochenlang mit solchen Probs abkämpfen zu müssen. Also mal den Blick auf Anderes gerichtet.
Für Micro-Basic gab es ja mal einen Anlauf. Der scheiterte aber gleich daran, dass sich kein komplettes Programm, rsp. eine einzige Anleitung auftreiben ließ, welche zumindest zu einem ersten Erfolgserlebnis führte. Zudem: 270 Dollar und dann wohl noch mal einen Hunderter für ein Programmiergerät etc. auszugeben, das ist in einer Zeit, in welcher es Vieles günstig bis umsonst gibt, doch sehr an User gerichtet zu sein, die mit Programmieren Geld verdienen wollen.

Aus dem Heise-Verlag und durch mein Abbo der "c't" werde  ich laufend auf Alternativen hingewiesen. Habe mir gerade mal ein Sonderheft von "Make:" gekauft über bestimmte Micro-Prozessor-Grundlagen. Dem Heft liegt als Beifang ein 32-bit-Prozessor PI PICO bei. Um den ging es mir weniger, aber im Heft gibt es Anleitungen für den Einstieg mit C++, Basic und Phyton. Um die beiden letzten Anleitungen ging es mir.

Nun rotiere ich mal wieder und "... bin so klug als wie zuvor...." (Goehte/Faust).
Für übersichtliche Steuerprogramme reicht ja so'n 8-bit-PIC und da bin ich auch so involviert, dass ich auch dabei bleiben möchte und werde. Aber es muss für Projekte, in welchen mathematische Formel abzuarbeiten sind, wohl aus zwei Gründen was anderes her: zum einen die Begrenztheit des 8-bit-Raumes und zum anderen die Möglichkeit, eine moderne, gepflegte, vor allem aber LEICHT zu lernende Programmiersprache nutzen zu können.
Werde mich in den nächsten Tagen da mal neu aufstellen wollen und hoffe auch auf eure Meinungen, rsp. Kommentare.
Wichtig ist mir, dass der Einstieg ohne tückisches Gestrampel vonstatten geht. Beim Assemblern hat MicroChip das sehr gut vor exerziert, wie man Anfängern in den Sattel helfen kann. Was zumindest ich bräuchte, wären gute Anleitungen und - ach ja - zumindest für den Anfang wäre eine Anleitung in Deutsch ein gutes Argument.
Bin voll ratlos, leider.... :(
Grüße, picass

Hallo
Warum willst du jetzt den Compiler wechseln ? Mach doch da weiter wo du mit MikroBasic aufgehört hast.
Mit einem anderen Compiler wirst du auch nicht viel weiter kommen denn die Probleme die du
vorher hattest bleiben. Du verstehst immer noch nicht das es Compiler Befehle gibt und Befehle
die der Prozessor hat. Und wenn man mit einem neuen Compiler anfängt dann fängt man mit einem
einfachen Beispiel an und nicht direkt mit internen Takt und eine Frequenz von 32kHz.
Denn um das zu erreichen müssen mindestens 1 bis 2 Prozessorbefehle gesetzt werden, die man am
Anfang überhaupt nicht kennt und dafür das Datenblatt durchsuchen muss.
Da ist das scheitern schon vorprogrammiert. Man fängt ganz einfach an, indem man einen Controller nimmt
dort einen Quarz z.B mit 8MHz dran hängt und eine LED dran macht. Je nachdem welchen Prozessor du verwendest
brauchst du nun zuerst einmal dich nicht um die internen Befehle des Controllers zu kümmern. Sondern du
kannst dich auf die internen Befehle des Compilers konzentrieren und mit dem Programmieren beginnen.
Wie gesagt fang ganz unten an zu programmieren ohne irgendwelche Sondersachen dann kommt man
mit jedem Compiler mal schneller mal langsammer zum Ziel.

Zitat von: picass in 17.12.2022, 12:23:17 CETBeim Assemblern hat MicroChip das sehr gut vor exerziert, wie man Anfängern in den Sattel helfen kann. Was zumindest ich bräuchte, wären gute Anleitungen und - ach ja - zumindest für den Anfang wäre eine Anleitung in Deutsch ein gutes Argument.

Falls du dich auf das PICkit3 Starter mit dem LPC beziehst, das hatte ja auch Beispiele in "C". Wie die Assembler Beispiele funktionieren die mit dem aktuellen Compiler natürlich nicht mehr. Wäre aber im Rahmen einer Neugestaltung sehr wenig Aufwand die Beispielprogramme anzupassen. Wollte ich ja eh machen ;-)

"C" ist für mich immer noch der Standard für 8-Bit Controller. Weiß jetzt aber nicht inwieweit der User Guide zum Starter Kit da auch eine Einführung in C darstellt. Müsste ich mal nachschauen. Python kannst du getrost erst mal vergessen, das braucht ganz andere Kaliber als 'nen 8-Bitter.

"Aktuelle" deutsche Anleitungen wüsste ich jetzt leider keine.
Das Zeug von Nico war nicht schlecht, aber die Seite gibt es ja leider nicht mehr :-(

picass schrieb:

Zitat von: picass in 17.12.2022, 12:23:17 CETZudem: 270 Dollar und dann wohl noch mal einen Hunderter für ein Programmiergerät

Ja, die Compiler von Mikroelektronika sind vom Preis her keine Schnäppchen...
Ich habe meine Dongle-Version gekauft, als die noch reichlich 100EUR kostete.
Aber das Programmiergerät "mikroprog" ist nur dann erforderlich, wenn man Hardware-Debugging benötigt. Von Vorteil ist natürlich auch, dass der Compiler direkt mit dem Programmiergerät kommuniziert.
Ansonsten kann man jeden Programmer benutzen, indem man das vom Compiler generierte HEX-File in den PIC brennt. Ich habe dazu lange Zeit einen Brenner von sprut benutzt, warum sollte da nicht auch das PICkit funktionieren?

Gruß
PICkel

Warum benutzt Du nicht den kostenlosen C-Compiler? Ich arbeite mit den alten C18 Compiler, für zeitkritische Interrupt Routinen usw. nehmen ich Assembler. Hier kann ich die Taktzyklen ausrechnen. Der Linker fügt die Programmteile dann automatisch zusammen.

So, Jungs, nu' bin ich ein klein wenig weiter, rsp. auf dem Weg raus aus der µC-Programmier-Sackgasse. Das  ,,c't  MAKE:" Sonderheft des Heiseverlages mit dem Titel ,,PI PICO Spezial" hat mir einen Weg gewiesen.

Sich auf den Weg zu machen, sprich: sich nun doch eine Hochsprache anzueignen, muss jetzt sein. Warum? Die Sackgasse: wie im Vortext beschrieben. Dann: mein Alter: wenn nicht jetzt, wann dann noch? Die Dauer für Konzentrationsphasen und wohl auch das Verständnis für – aus eigener Sicht – komplexe Zusammenhänge wird abnehmen. Auch das noch: es ist Winter-Beginn und Vorweihnachstzeit. Also jetzt!

Im Heft gibt es kaum zu übersehende Empfehlungen für MicroPython. Das wäre nicht nur einfach ,,angesagt", das wäre leichter zu erlernen, würde von einer wachsenden Community stark unterstützt und es gibt schon sehr viel zusammen passende und sehr preiswerte Hardware. Und: keine Summen an Investitionen nötig! Das wäre nun auch meine Wahl.... gewesen. Leider fand ich auf der HP von Microchip schlicht die ,,leere Menge" unter dem Stichwort. Und ein Forum, welches ,,Python" und ,,PIC" in Namen trug, ist 2018 eingestellt worden, sein Nachfolger auf Github scheint nicht wirklich lebendig zu sein – das muss ich nochmal prüfen, vielleicht täuschte der erste schnelle Blick. Schade, das wäre die liebste Wahl gewesen!

Aber dann! Dann las ich in den Artikeln über die drei alternativ beschriebenen Prog-Sprachen für Basic dieses, wörtliche Zitate:
,,Was viele vielleicht nicht wissen, ist, dass BASIC über die Jahrzehnte weiterentwickelt wurde, so dass heute viele Dialekte existieren, die über moderne Eigenschaften verfügen und auf aktuellen Microcontrollern sogar verblüffend effizient sind."
Und:
,,Altgedienten Programmierern mag es zuerst schwer fallen, sich auf BASIC einzulassen, aber es lohnt sich, vorurteilsfrei an die Sache ran zugehen. MMBASIC ist nicht das BASIC, das so mancher noch aus den Heimcomputer-Tagen kennt, sondern eine topmoderne Programmiersprache, die den PicoMite in eine komfortable und effiziente Entwicklungs- und Laufzeitumgebung verwandelt."
Zitatende

PicoMite ist eine Sammelname. Es geht um das MicroprozessorBoard mit dem Namen RP2040, auch als ,,PICO" benannt, mit der ARM-CPU Vortex-M0+. Wenn der µC auf diesem Pico-Board mit Basic läuft, dann wird das alles als ,,PicoMite" bezeichnet. Es gibt zwei BASIC-Versionen und die etwas neuere nennt sich MMBasic, geistiger Urheber Geoff Graham und die aktuelle Version von Peter Mather.

Die Beschreibung der Installation und ersten Inbetriebnahme haben mich veranlasst, diese Schritte als erstes zu gehen. Das führt zunächst vom PIC weg. Ist so, damit werde ich erst mal zu leben versuchen. Aber..... zu meiner Freude fand ich auf der HP für diese Basic-Version Hinweise, dass diese B-Version ursprünglich für einen 32-bit-PIC entwickelt worden wäre. Die scheint auch noch unterstützt zu werden, jedenfalls gibt es da eine extra an die PIC-Hardware angepasste BASIC-Version mit eigenem Namen.

Und so stelle ich mir das jetzt vor: Weil in dem Heft für diesen PICO alles so schön beschrieben ist und – TUSCH – es auch eine Anleitung in Deutsch geben soll und – TUSCH2 – von Kosten auf dieser HP nicht die Rede war, werde ich versuchen, ein paar Schritte mit dem PicoMite zu gehen. Meine PICs landen erst mal auf einer Bank, rsp. im Hintergrund. Sollten sich diese ersten Schritte auch um zweite oder dritte erweitern lassen – will sagen: Anschluss eines Displays und Auslesen von z.B. I²C-Sensoren - , dann versuche ich, das auf einen PIC32 umzusetzen. Zwischen den beiden Basic-Versionen würde ich keine grundlegenden Unterschiede erwarten. Wenn das auch klappen sollte, dann geht es mit der PIC-Version weiter – oder mit beidem..... TUSCH3: habe gerade entdeckt, dass es den für die PIC-Basic-Version genannten PIC32MX170F256B-50 I/SP bei Mouser vorrätig gibt, für gut 5 € netto!

Nein! Die 8-bit-PIC-Welt werde ich – egal, ob das anstehende Wagnis klappt oder ich mich übernehmen sollte – auf jeden Fall im Auge behalten. Da ist zu viel investiert und meine lieben, kleinen Steuer-PICs werden für einfache Aufgaben sicher auch weiter eingesetzt werden.

Aber nu' breche ich mal zu einem neuen Ufer auf. Das muss sein... und zwar jetzt!
Grüße, picass

Nachtrag: im Bild der neue µC und ein altes, sehr altes, eines meiner ersten Netzteile! Aber die zwei mögen sich schon, hat das NT doch einen IC-Regler, welcher auf Spannungen von 1,5 bis 6 Volt spezialisiert ist. Die beiden 3055-Top-Veteranen werden allerdings zur Stromversorgung eher weniger gebraucht werden. >:D

Grüße vom anderen Ufer !

Dieses wurde soeben erreicht. Nach dem Download und Installieren des MMBasic, eines VT-100-Terminalprogs, dem Abnicken der seriellen Daten-Einstellungen wurde das Board via USB-Kabel angestöpselt  - dabei eine Taste auf dem Board gedrückt – und voila: der Windows-PC und das Pico-Mate-Board waren betriebsbereit!
Is klar: print ,,hello" // print 2/7  // einstellen und anzeigen lassen der internen Uhr // anzeigen des internen Temp-Sensors // blinken lassen einer externen led – dabei in blitzes-eile die Blinkfrequenz ändern – und nun zum ersten und krönenden Schluss das Berechnen  und Ausdrucken des Wertes einer Quadratwurzel !
Letzteres war ja einer der Gründe für die Abkehr vom Assemblieren! Das hätte wohl eher später als gar nicht unter Assembler geklappt und schon überhaupt nicht wäre das derart blitzschnell berechnet worden und – ach ja – wohl eher nicht mit 8 Nachkommastellen-Genauigkeit !

Mal anders formuliert: der Weg über den Strom brachte eine Änderung von 32,5 kHz auf 125 MHz, so bildlich gesprochen und der Vergleich hinkt noch enorm. Da bin ich gespannt, wie und ob das weiter geht. Eine kleine OLED-Anzeige ist bestellt, morgen beginnt der Versuch, ein erstes Prog auf die Beine zu stellen.
Nur am Rande noch erwähnt: es war für diesen Erfolg nicht notwendig, aber irgendwie doch sehr entspannend, eine einhundertfünfundachtzig-seitige technische Dokumentation mal nicht in Englisch lesen zu müssen.
Grüße, picass

Schreibe bis auf Weiteres mal hier weiter!

Für euch wohl selbstverständliche Praxis, für mich ist die Inbetriebnahme dieses winzigen (0,9") OLED-Displays ein Schritt auf dem Mond.

Die Abarbeitung der Formel zur Berechnung für den Taupunkt und die Anzeige der aktuellen Parameter wie Temp und Feuchte waren die beiden Knackpunkte, an denen es für mich unter Assembler nicht weiter ging. Hier nun das erstmalige Nutzen der Anzeige in 20 min. Hätte auch weniger sein können, irgendwas ist da noch komisch. In der Anleitung steht, die Steuerbefehle (3 Zeilen) könnten nicht im Programm, sondern nur in der Console genutzt werden. ??? Etwas Zeit braucht es also doch noch, aber der Bann ist gebrochen.
Dazu zählt auch, dass ich kein tagelanges Studium des Protokolls einer i²C-Verbindung aufnehmen muss. Es ist nicht mal notwendig, eine Bibliothek irgendwo zu suchen, down zu laden, zu implementieren. Die ist im Basic enthalten. Zwei Zeilen Initialisierung und dann können gleich die Nutzdaten geschrieben werden. Ich glaube, ich hänge mir 3 ausgedruckte Blätter mit dem I²C-Protokoll einige Tage übers Bett, um dann hoch entspannt und mit mildem Lächeln mich auf den Schlaf einzulassen.
Gleiches Procedere gilt auch für die SPI-Anbindung. Es mag sein, dass man z.Z. nicht die unendliche Auswahl an Displays hat, sondern auf einige wenige Modell-Typen angewiesen ist, zumindest, wenn man es so einfach haben möchte. Egal, wurscht, wei'n interessiert's?, u.s.w...

Die beiden 32-er PICs sind auch schon auf dem Postweg hierher. Inzwischen sehe ich die Chancen, die tatsächlich auch genauso oder zumindest ähnlich nutzen zu können, wieder ein Stück weit als gewachsen an. Die Basic-Version auf denen muss ja nahezu identisch sein. Wenn das mit den integrierten Bibliotheken dort auch klappt, dann lässt sich das ,,Feuchte-Keller"-Projekt ja vielleicht wirklich mit denen umsetzen. Wär' ja irre...., zumal das echte PICs sind, die wenig Strom benötigen, sich zum Sleepen schicken lassen, etc...
Ich träume schon wieder. Aber es mehren sich die Zeichen, dass sich dieser beschriebene feuchte Traum realisieren lassen könnte.
 8)  >:D
Grüße, picass

Scheine mal wieder an einem Scheideweg angekommen zu sein. Nachdem die letzten Projekte recht gut mit Assembler zu erledigen waren - auch wenn am jeweiligen Ende der übliche Kampf gegen den üblichen Floh hart werden konnte - , sehe ich jetzt bei dem Versuch, sich in serielle Datenübermittlungen wie I²C einzuarbeiten, einen recht riesigen Gordischen Knoten beim Assemblieren. Der Aufwand scheint irre zu sein und das für so was vermeindlich Einfaches, wie das eine und andere Datenbyte rüber zu schieben.

Wenn ich das nicht falsch sehe, läuft das in Hochsprachen komplett anders: die eigentliche Arbeit wird in fertigen Bibliotheken abgelegt, die mit einem kurzen Statement eingebunden werden. Dann sind im Programm nur ein paar Parameter wie: welcher Portpin?, welche Geschwindigkeit?, etc. kurzerhand anzugeben und los geht es.
Frage 1: ist diese Annahme richtig? Ist das wirklich so viel einfacher?

Dann leide ich schon seit Jahren unter der zumindest theoretisch vorhandenen Vielfalt der Auswahl von Hochsprachen und konnte mich für keine bislang erwärmen. "C" ist die wohl Komplizierteste, zudem schrieb @vloki in seinem Script, dass C18 gänzlich schrottigen Code erzeugen würde. Dann wäre dieses Basic von MicroElektronika (oder wie die heißen), aber das wird gerade abgekündigt und jetzt noch auf einen toten Gaul zu steigen und das evtl. noch für viel Geld, scheint allein aus diesem Grund fraglich. Voll im Trend soll MicroPython sein. Die Jungs und Mädels der Zeitschriften "c't" und "MAKE!" aus dem Heise-Verlag schwören drauf, u.a., weil es so einfach wäre und deshalb gerne in Schulen für Jugendliche verwendet würde. Aber ach..., diese Sprache scheint an der PIC-Welt komplett vorüber zu gehen. Eine Inet-Suche in der Kombination führte nahezu nur zu "leeren Mengen", auch bei Microchip.

Frage 2: Watt' nu?
Grüße vom desorientierten picass

Ich programmiere von Anfang an den Pic in C und in Assembler. Assembler nehme ich hauptsächlich im Interrupt und bei zeitkritschen Unterprogrammen, wo ich die Takzyklen abzählen muss. C war für mich etwas gewöhnungsbedürftig wegen der Pointer. Man kann nicht einfach irgendeine Variable zurückgeben, sondern muss dies mit Pointer (Zeigern) machen.

Ich arbeite immer noch mit dem alten C18 Compiler. Ich habe mir mit der alten MPLAB.IDE den erzeugten Code angezeigen lassen. Dieser war eigentlcih sehr gut, so wie ich es auch in Assembler programmieren würde.

Zitat von: picass in 03.11.2024, 13:40:13 CETArbeit wird in fertigen Bibliotheken abgelegt

es gibt fertige Liberty. Da bracht man nur, z.B. bei der Schnittsellen Open Port usw angeben, mit write_spi oder read_spi lesen und schreiben.
Das machen viele so, ich schreibe immer meine eigene Unterprogramme, welche dies erledigen. Bei der fertigen Liberty muss man genau die Syntax kennen. Übrigens gibt es auch eine Liberty für die LCD Anzeigen, da kann man den Port einstellen, oder 8 Datenleitungen, wieviele Zeilen und Spalten usw. Das habe ich aber auch noch nicht benutzt.

Zitat von: picass in 03.11.2024, 13:40:13 CET"C" ist die wohl Komplizierteste, zudem schrieb @vloki in seinem Script, dass C18 gänzlich schrottigen Code erzeugen würde.

Mein Zitat war leider falsch. vloki bezog seinen Kommentar auf den neueren C-Compiler "XC8" in der Free-Version.
Grüße, picass

Zitat von: picass in 03.11.2024, 18:38:53 CETvloki bezog seinen Kommentar auf den neueren C-Compiler "XC8"

Galt zur Zeit als XC8 "neu" war. Ist inzwischen auch nicht mehr so dramatisch. Kann man mit leben ;-)
Mein "Skript" habe ich übrigens inzwischen in GitHub gelagert. Wird auch gelegentlich aktualisiert.
( https://github.com/VSK-THU/uCQ_DOKU )

Da liegt auch ein kleines I2C Slave Beispiel in C zum angucken. https://github.com/VSK-THU/uCQ_I2C_Slave.X
Ein kleines I2C Master Beispiel wäre in https://github.com/VSK-THU/uCQ_THU_AddOn.X (Konfiguration SHT21)

Den Rest hatten wir schon. (Micro Python oder Circuit Python sind für kleine 8bit Controller absolut ungeeignet)

Bei den Bibliotheken in C ist meist nicht viel dahinter. Könnte man genauso in Assembler schreiben, bzw. hat bestimmt schon jemand gemacht.
Sind eigentlich nur einige Zeilen Code, welchen man immer wieder braucht, und deshalb als Bibliothek angelegt hat.

Fein..., dass es dein Script noch gibt. Schaue morgen dort mal rein. Danke auch für  die Links.

Zitat von: vloki in 04.11.2024, 09:26:03 CETDen Rest hatten wir schon. (Micro Python oder Circuit Python sind für kleine 8bit Controller absolut ungeeignet)

Der "Rest"....:
Bin an einem Punkt angelangt, an welchem mir die Controller nicht egal, aber fast egal sind. Habe nichts gegen einen 32-Bitter - auch nichts gegen andere µC-Preise, wenn sich solch µC in einer Sprache programmieren lässt, welche mir das Programmieren ermöglicht, ohne mich 2 Wochen um ein einziges Detail abquälen und jedes Rad neu/nach erfinden zu müssen. Schaue gerade, ob da nicht doch was mit dem vermeindlich einfach zu lernenden MicroPhyton gehen könnte.
Grüße, picass

Hänge das Zitat von Volker aus einem anderen Fred mal hier rein und schreibe auch hier weiter, weil der Inhalt hier besser zum Thread-Thema passt:

Zitat von: vloki in 20.11.2024, 11:41:42
"Wenn ich mal wieder länger Zeit habe, werde ich mich auch nochmal in CircuitPython vertiefen ;-)
https://circuitpython.org/"
Zitat-Ende

Au man, das hätte nicht passieren sollen. Nu' hatte ich mich nach Laaaaaaangem endlich für das Erlernen einer Hochsprache entschieden, und schon gibt es einen Hinweis auf eine Alternative. Sogleich heben die Zweifel an, was denn nun passender wäre.

Nach kurzer Inet-Recherche und sicher verkürzt und als grober Überblick hier wieder gegeben, scheinen MicroPython (MP) und CircuitPython (CP) recht ähnliche Geschwister zu sein. Es hieß, dass CP eine Abspaltung von Mp wäre und dass – Tusch – diese Abspaltung entstanden wäre, weil sich da zwei Parteien [mal wieder] nicht einigen konnten. So was hatte ich bereits vor dem Lesen solchen Kommentares vermutet. Wie auch immer, beide ,,Dialekte" werden als anfänger-freundlich gepriesen. MP soll vorwiegend von der eigenen Community gepflegt und entwickelt werden, CP würde vornehmlich von Adafruit propagiert und gefördert plus ebenfalls eigener Community. In CP wären viele Bibliotheken bereits enthalten und auch für Treiber gäbe es ein gutes Paket.

Selbst fiehl mir gestern auf, dass bei Adafruit von MP wenig bis gar nicht die Rede ist, während für CP gleich auf der Produkt-Übersichts-Seite vorne eine Hauptrubrik existiert. Entsprechend werden dann wohl die angebotenen Sensoren von Adafruit umfänglich versorgt werden.

Schwitz.....! Schon wieder Rückfall ins Grübeln?
Habe mich entschlossen, zu versuchen, den eingeschlagenen Weg in Richtung MP solange weiter zu gehen, wie es klappt. Will sagen: es wird für die Mitglieder hier kein Geheimnis sein, dass es mein Traum ist, eine Luftentfeuchtungs-Anlage – genauer gesagt: das Programm – selbst zu erstellen. Dafür werden 2 Sensoren je für Temp und L-Feuchte benötigt, ein LCD-Anzeigemodul mit 20 Zeichen pro Reihe und 4 Reihen, und wohl noch ein Licht- und ein Regen-Modul. Wenn ich die unter MP zum Laufen bekomme, bleibe ich erst mal bei MP. Klappt das nicht, versuche ich diese Sensoren unter CP in Betrieb zu nehmen.
Mag mir nicht vorstellen, dass es gravierende Unterschiede zwischen beiden Sprachen gibt. Man muss sehen...... In den nächsten Tagen also Sensor-Training.
Grüße, picass

Zitat von: picass in 06.12.2024, 10:46:44 CETden eingeschlagenen Weg in Richtung MP solange weiter zu gehen, wie es klappt

Ich würde nur bei einer Sprache bleiben, diese erst mal richtig lernen. Sonst kommst Du mit den verschiedenen Syntaxen durcheinander. Wenn Du eine Sprache richtig beherrscht, dann kannst Du immer noch eine zweite dazulernen. :)

Wie kurz angedeutet sollten MicroPython und CircuitPython - vergröbert gesagt - identisch sein, rsp. jeweils nur eine Art Dialekt, denn das Eine ist eine Abspaltung vom Anderen.
Mittlerweile sind meine Zweifel deutlich größer geworden. Für den Einsatz von MP fehlte mir noch die Ansteuerung eines üblichen LCD-Displays. Erst fand ich kaum was und der erste "Treffer" war ein Riesen-Schlag ins Wasser. Der Verfasser des eher kurzen Progs schaffte es zunächst, in seiner Übersichts-Zeichung für den Anschluss des Raspi Pi Picos an so'n Display von gesamt 8 Verbindungsleitungen genau die Hälfte falsch darzustellen. Das Prog selbst erschien schon seltsam, gleich die ersten beiden Zeilen passten nicht und in der vierten hing das Prog dann endgültig mit Syntax-Fehler. Ist ggf. eine stonealte Version oder die war nie auf Funktion getestet.
Es macht mich inzwischen auch stutzig, dass in all den 3 Sonderheften und einem Anfängerbuch für MP kein einziges Beispiel für so'n Einfach-LCD-Display zu finden ist. Das halte ich inzwischen nicht mehr für einen Zufall.

Das nächste Stirnrunzeln kam, als bei Adafruit, der Firma, welche als die Mutter von Angeboten an diesen modernen MicroControllern gilt, weil sie u.a. ganz besondere Pflege betreibt, indem sie Librarys erstellt und anbietet, zu MP nichts zu finden war. Hingegen habe ich gerade eben für CircuitPython dort eine irre Riesen-Sammlung an Beispielprogrammen und Librarys gefunden, genau gleich zwei davon. Eine Irre von Adafruit und eine ähnlich Irre der Community. Wohlgemerkt passend zu der angebotenen Hardware.

Werde gleich mal ausgewählte Prog-Beispiele testen. Bin schwer gespannt, ob das besser funktioniert.
Grüße, picass

Zitat von: picass in 07.12.2024, 17:09:53 CETMP fehlte mir noch die Ansteuerung eines üblichen LCD-Displays

vielleicht kannst Du damit was anfangen. https://github.com/rdagger/micropython-charlcd/blob/master/LCD.py
Ich habe mir mal den Code angeschaut, vieles ist verständlich, einige Sachen sind wohl Python spezifisch.

Das ist auch eine interessante Seite. https://wolles-elektronikkiste.de/micropython-umstieg-von-arduino
Hier ist auch ein interessantes Beispiel:
a = [1,2,3]
b = a
b[0] = 42

Ergebnis von a = [42, 2, 3]

das ist auch interessant:
for i in range(len(led)):
    led[i] = Pin(led[i], Pin.OUT)
der Vorteil von Python ist, das du das Prog. direkt ausführen und die Parameter abfragen kannst.  Ich vergleiche es mal mit dem Basic der 80er Jahre. Da konnte man auch a=2: Print a eingeben.
Der Nachteil zu C könnte die Programmgeschwindigkeit sein, da der Code nicht kompiliert wird.
C macht hier einen sehr guten Maschinen - Code

Der Start in das Lernen von MicroPython (MP) war ja fulminant, die vorige Horrorformel ließ sich in einer halben Stunde berechnen. Aber nun stecke ich seit einer Woche in Basics fest..., man glaubt es kaum. Als Zweites (nach der Formel) wurde versucht, Sensoren und Displays in Betrieb zu nehmen. Dazu gab es vermeintlich gute Beispiele in diversen Sonderheften des Heise-Verlages und auch ein Leerbuch "Raspberry Pi für Kids" wurde angeschafft. Aber alle Versprechungen über das vermeintlich leichte Einsteigen entpuppen sich schnell als Luftnummern. Ja, einige ganz wenige super-einfache Beispiele lassen sich tatsächlich in die Tat umsetzen, aber dann..., dann geht das Scheitern, rsp. das unerwartete Abplagen los. So hatte ich einen Raspi Pi Pico (Pico) nach einigem Bemühen dazu bringen können, den Bosch-Sensor BME280 auszulesen. Der generiert Aussagen über Temp, Luftdruck und Luftfeuchte. Aber schon da hakte es, weil der passende Treiber doch nicht auffindbar war und ein "Ähnlicher" genutzt werden musste. Na gut, das funkte. Also dann wacker weiter mit einfachen LCD-Anzeigen. Da ging gar nichts, dazu später. Aus diversen Gründen also zurück zum BME280 und den zwei weiteren Picos, welche in der Kiste schlummerten. Nichts leichter, als das Vorige dort zu wiederholen. Dachte ich und das war vor einer Woche. Unter exakt den identischen Bedingungen werden die drei - siehe Bild - µC's im Steckbrett betrieben - is klar, nacheinander - , aber während die erste Schaltung übers Inet noch den Ähnlichen fand, wollten die beiden Nachfolger schlicht nichts Passendes finden! Und bei Github ist ein solches Durcheinander und jeder scheint da irgendwas einzustellen und ganz schnell findet sich in der Spreu keinerlei Weizen. Jeder prumelt da an einer extra-Sonderlösung rum und die Basics sind nicht zu finden oder erst gar nicht vorhanden.

Ganz arg ist das bei den LCD-Displays, dieser komplett neu vor 14 Tagen eingeführten Raketen-Technik! Nicht zu fassen, was für ein Durcheinander da herrscht. Da blicke ich schlicht nicht durch und alles hängt. Entgegen den rosa-roten Versprechungen verläuft Vieles schlicht im Sand. Man könnte ja auf die Idee kommen, sich wegen der Basics an einen anerkannten Fachmann zu wenden, in diesem Fall an Adafruit.com in den USA. Von dort liefern zu lassen, ist allerdings recht teuer. Also schaut man auf deren Lieferpartner-Firmen in D, von denen es mindestens 5 gibt und hofft, die Adafruit-Produkte dort kaufen zu können. Nix! Zumindest bei einfachen LCDs betreiben die ihre eigenen Wässer'chen. Und Adafruit selbst schreibt auf der eigenen Homepage, dass die wunderbaren Beispiele (Treiber,Micro-Progs) zu ihren Produkten nicht/nicht unbedingt auf ähnlichen Produkten laufen würden. Tolle Wurst, Ende Gelände.

Es kommt hinzu, dass NIEMAND in den vermeindlichen Einstiegs-Hilfen es geschafft hat, durchgängig den Einstieg ins Programmieren mit MP darzustellen. Die haben alle sich irgendwelche Teile raus gegriffen, aber immer fehlen Zwischenschritte, ohne die es leider nicht weiter geht. So soll z.B. die Programmierung ja u.a. mithilfe des Progs "Thonny" erfolgen, welches unter Win läuft. Das T enthält eine IDE, die dort geschriebenen Progs werden in den Pico geschoben und können gestartet werden. Aber wehe, wenn es Probs mit Treibern oder mit Librarys oder den Micro-Progs gibt. Dann zeigt sich z.B., dass der Pico doch nicht wie behauptet als Laufwerk sichtbar wird und leider keine einfachen Verschiebungen von Programmen oder das Kopieren funktionierender Treiber/Micro-Progs möglich ist.
Mag sein, dass ich in einigen Tagen beginne, diesen Troubel zu vergessen, aber einfach - nein, bestimmt nicht - ist da nichts. Die Dokumentationen sind viel zu lückenhaft und häufig habe ich den Eindruck, dass die nicht seriös erstellt wurden, sondern mehr Abgreiferei oder Effekthascherei betrieben wurde.
Grüße, picass
3xrp2040.jpg

Das Chaos nimmt seinen Lauf! Gestern funktinierte Board1, aber Board2 u 3 nicht. Heute funktionierte Board1 nicht, B2 ja, B3 nicht. Gerade eben funktinierte - Überraschung - kein einziges B.! Die Komplett-Install eines orig Paketes von Adafruit scheiterte krachend, auch der Versuch, die Unterschiede von CuircutPython [Adafruit] zu MicroPython zu eliminieren, half nichts. Wie war das noch? Einfach, eben auch für "Kids" geeignet? Voll der Brüller! >:(
Grüße, picass

Was funktioniert denn nicht? Die Verbindung zum Board - oder kannst Du den Fühler nicht auslesen?

Beim Fühler musst Du mal nachschauen, ob da Pull-Up Widerstände vorhanden sind. Der eigentliche Fühler benötigt bei I2C Beschaltung, was Du hier anscheinend hast, eine Verbindung von Pin6 VDDIO nach Pin2 CSB, sowie jeweils Pull-Up Widerstände  von VDDIO nach Pin3 SDI und Pin4 SCK. Außerdem bin ich mir nicht ganz sicher, ob Du noch Pin 5 SDO für die Slave-Adresse Bit 0 noch beschalten musst.
Das ganze kannst Du hier im Datenblatt nachlesen. https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bme280-ds002.pdf

Zitat von: pic18 in 13.12.2024, 20:29:56 CETDie Verbindung zum Board - oder kannst Du den Fühler nicht auslesen?

Danke, pic18, für dein Engagement. Du bist ja echt ein treuer Forenfreund!

Bei allen drei Boards lässt sich wiederholt und immer ein superkleines Testprogramm ausführen, welches die auf dem µC-Board serienmäßig installierte LED zum Blinken bringt. Also funktioniert die IDE von "Thonny", die Verbindung vom PC zum Controller und auch der RP2040 selbst prima. Das ist beliebig oft ausführbar und da gibt es auch keinerlei Ausnahmen. Sobald aber eines der Progs zum Auslesen des Bosch-Sensors aufgerufen wird, geht seit gestern nur noch die bekannte große rote Lampe an.

Aufgrund deiner Einstellung des PDFs für den BME280 habe ich mir gerade eben die Winzig-Platine angeschaut, welche sowohl den Sensor, als auch diverse R's und C's als auch die Anschlüsse enthält. In allen Einzelheiten entspricht die vorgefundene Bestückung exakt der Bosch-Vorgabe aus dem Datenblatt. Die R's haben je 10 kO, das liegt zwar am Rande, aber insgesamt noch genau im vorgegebenen Wertebereich. Bosch hat solche mit 4,7 kO eingezeichnet, aber fundamentales Versagen nach erstem längeren und wiederholtem Funktionieren muss andere Ursachen haben. Es braucht halt Treiber, Bibliotheken und das eigentliche Prog. Und das muss alles exkat zueinander passen und das dann auch noch zu den "sonstigen" Umständen wie Prog-Sprache, µC-Typ und natürlich der individuellen Verkabelung der Anschlüsse. Und der V-Spannung und was weiß ich noch was. Wahrscheinlich liegt der Hund bei Letzterem begraben. :-\
Diese Beschaltung entspricht auch der Vorgabe aus dem Datenblatt für die  I²C-Beschaltung. Diejenige für SPI ist anders. Danke nochmal für deine Teilhabe.
Grüße, picass
sensor1.jpgsensor2.jpg

sehe ich das richtig, dass am Pin 2,3,4,5 jeweils ein Pull-Up Widerstand ist. Dann mess doch mal die Spannungen, ob die Pegel stimmen. STI und CLK kannst Du nur mit Oszilloskop messen. An Pin CSB müsste Hi anliegen, da du STO nicht beschaltest hast müsste da auch HI anliegen. Das musst Du natürlich bei der Adressierung der Slave - Adresse beachten, sonnst reagiert dein Sensor nicht. Alternativ kannst Du mal STO gegen Masse schalten. Scheint ja auch ein IO Port zu sein.

Wir geraten hier mit Sicherheit auf eine falsche Fährte! Wenn die Beschaltung falsch wäre - was sie sicher nicht ist, denn sie entspricht exakt der Grundschaltung im Datenblatt des Herstellers - , dann hätte das Auslesen nie geklappt. Hat es aber. Es hat anfangs sogar sehr gut geklappt: das MicroPython-File wurde nach Vorlage direkt in den Flash-Speicher des RP2040 kopiert, und die (einzige) von der IDE "Thonny" gefundene Bibliothek für den BME280 wurde downgeladen und installiert, dann das micro-Progrämmchen geschrieben und schon gings mit dem Auslesen und Anzeigen los. Das ließ sich auch beliebig wiederholen und erfreute so richtig.
Der Trouble ging los, als ich auf die Idee verfiel, nun die LCD-Anzeige in Betrieb zu nehmen. Da sollte das BME280 ausgelesen und auf dem LCD angezeigt werden. Aus Platzgründen verlegte ich zunächst die Anschlüsse des BME280 an andere Port-Anschlüsse am µC und änderte das Prog entsprechend um. Aber das LCD wollte nichts anzeigen außer der Schwarzfärbung einer Reihe. Dann ging die große Suche nach Probs los.

Und "sicherheitshalber" wollte ich nun erst doch die beiden den anderen, noch ungenutzten RP2040-Boards in Betrieb nehmen, zunächst nur in der Grundschaltung mit dem BME280. Aber das klemmte von vornherein und der Ärger begann, als bei Anschluss dieser Boards das "Thonny" den notwendigen Treiber, den es im ersten Anlauf gefunden hatte, beharrlich nicht mehr finden wollte. Ab da wurde es übel: einfaches Kopieren war nicht vorgesehen, und beim Suchen nach Treibern und passenden Bibliotheken geriet ich immer mehr in den Strudel. Und da bin ich nun, tief unten am Grund des Strudels und derart durchgedreht, dass ich nichts Sinnvolles mehr zu Wege bringe.
Grüße, picass

Wie schon gesagt, ich würde zuerst einmal die Spannungspegel überprüfen. Das ist ja bei den 4 Pins überschaubar. Nicht dass eine Leitung keinen Kontakt hat. Danach würde ich die Software überprüfen. Besonders würde ich mal die Slave - Adresse überprüfen ob diese stimmt (STO Beschaltung). Du kannst auch mal die Chip - ID abfragen, die müsste 0x60 sein, im Register 0xd0.

Bei der LCD - Anzeige hatte ich oben diesen Link gestellt. https://github.com/rdagger/micropython-charlcd/blob/master/LCD.py
Hast Du dir das mal angeschaut? Wie sprichst Du denn die LCD - Anzeige an? Mit 4 Datenbit - oder über I2C

Ja, natürlich hatte ich mir das Beispiel angeschaut. Aber es half nicht weiter. Bevor es aber an den Einsatz einer LCD-Anzeige geht, muss davor aber geklärt werden, warum das Gerät, welches die anzuzeigenden Daten liefern soll, anfangs ja, aber nun nicht mehr funktioniert. Dazu auch gestern wieder kein Erfolg.
Grüße, picass

Von der Ferne aus ist es schwer ein Urteil sich zu bilden, wenn die Pegel passen, der I2C Bus läuft, dann kann es nur noch an der Adressierung liegen. Die LCD-Anzeige hat aber nichts mit dem i2C - Bus zu tun. Hast Du denn USB Verbindung zum Board?

@pic18
Du verharrst immer im Bereich der Hardware. Dabei war recht schnell deutlich, dass der Hund im Bereich der Software zu suchen sein müsste, denn an der Hardware wurde nach dem ersten Erfolg außer gelegentlichen Wechseln der Pin-Anschlüsse nichts geändert und es waren zuviele µC-Boards im Test. Die konnten nicht alle defekt sein. Und so kam es denn auch, dass.....

.....dass ab heute 18:40 Uhr zurück geschossen..... Ne, das nicht, aber Feuerwerk würde schon fast passen, weil das Auslesen und Anzeigen des Bosch Sensors BME280 eeeeeeeeeeeeeeeendlich wieeeeeeeeeeeeeeeeder klappt. Zwei-einhalb-Wochen hat der Kampf, besser Krampf gedauert. Den Erfolg führe ich darauf zurück, dass heute eine Anleitung gefunden wurde, welche für einen einfachen Mann des deutschen Volkes verständlich war. Es ließe sich allerdings auch so formulieren: endlich hatte ein Autor wohl mal jemand anderen zum Nachstellen und Ausführen der Anleitung verpflichtet, der nicht im Stande des Wissens, sonder ein echter Anfänger war. Will auch sagen: in der Anleitung waren wirklich alle notwendigen Schritte genannt und alle Teile funktionierten auch. Ist ja auch furchtbar kompliziert, sich in der Muttersprache so auszudrücken, dass man sich nicht nur selbst versteht, sondern dass ein anderer das auch verstehen kann.

Also nun eine passende Bibliothek gefunden, die nach Anleitung auch richtig installiert, dann die Beispiel-Datei für die Ausführung kopiert und ausgeführt und: NIX! Zwei Anpassungen ausgeführt, einen Fehler beseitigt und dann lief es wirklich. Das hat gleich mehrere Sätze runder Augen gekostet und so richtig mag ich das noch nicht glauben. Eigentlich müsste ich heute Abend mehrfach mit mir anstoßen auf diesen Durchbruch. Aber leider passt meine Frau genau auf und ich hatte heute Mittag schon etwas Portwein zum Kartoffelschälen. Wie fast immer im Leben: es gibt eine gute und leider auch eine schlechte Nachricht. Aber immerhinque.....

Obacht: wenn mir mal jemand über den Weg läuft, der behauptet, MicroPython wäre eine leicht zu erlernende Sprache, den ramme ich ohne ein Wort in den nächsten Sumpf! Wo fand sich die Anleitung? Auf einer Homepage, welche als einen Teil des Gesamt-Namens das Wort "Nerd" enthält! Noch Fragen?
Grüße vom picass, der nun endlich was über Temperaturen und Luftfeuchte sagen kann.

Freud mich, dass es läuft, ich überprüfe halt immer erst die Hardware wenn plötzlich etwas nicht mehr funktioniert. Läuft denn die LCD-Anzeige auch schon? Ich habe mit fertigen Bibliotheken meine Probleme, da ich nicht genau nachvollziehen kann was im Hintergrund abläuft. MicroPython scheint auch einigen Eigenarten zu haben. Ich hatte hier #16 auch schon einige Dinge erwähnt, die man wissen sollte um nicht plötzlich Überraschungen zu erleben. 

Dass nun wenigstens das Auslesen des Temp-Sensors wieder funktioniert, gereicht mir zu einer Atempause und der Erkenntnis: es muss sich ein Wunder ereignet haben. Je weiter ich als Anfänger der Sprache "MicroPython" in die Grundlagen rein schaue, um so mehr frage ich mich, was das für ein zusammen gestoppeltes Zeug ist, und umso mehr verstehe ich, warum es so schwer ist, sich in diese Sprache einzuarbeiten....., sofern man nicht alle benötigten Komponenten wie Anschluss-Schemata der individuellen Schaltung, Bibliotheken, Treiber und Programme individuell vorgebetet bekommt, wie z.B. in einem VHS-Kurs.
Eine Hochsprache...., da klingt mir vor allem das Wort "eins" sehr schräg im Ohr. Dasjenige Micro-Programm, welches den letzten Durchbruch ermöglichte, war ja in MicroPython geschrieben. Aber nun scheint es so zu sein, dass es für jeden oder doch zumindest einige µC-Boards noch "Dialekte" gibt oder zumindest so was wie Anpassungen unausweichlich sind. Dieses letzte Erfogls-Prog war für einen anderen µC - irgendwas mit ESP32 oder so - geschrieben und funktionierte auf meinem Pi Pico überhaupt nicht. Erst zwei "Anpassungen" und ein zu überwindender Prog-Punkt, den ich als Fehler bezeichnete, weil die IDE von "Thonny" in einer Zeile einen Fehler vermeldete, waren nötig, um eine Funktion zu erreichen. Wenn aber solche die Funktion verhindernden "Anpassungen" einzelner Befehle notwendig sind, nur, weil ein anderer Prozessor  verwendet wurde, was genau soll denn das sein? Für jeden µC eine eigene Version dieser Hochsprache?!

Nach dem Zwischenerfolg gönne ich mir eine kurze Schaffenspause und räume in dieser Zeit erst mal den µC-Arbeits-Tisch auf, will sagen: da hatte ich erst mal alle Prog-Leichen aus den misslungenen Versuchen gekillt. Es drohte, den Überblick zu verlieren. Also erst mal Ordnung schaffen. Dann kam die Kontrolle und Vorbereitung der Hardware für den anstehenden LCD-Test ran und das Neu-Ranschaffen evtl. brauchbarer Software. Heute gehts weiter....
Grüße, picass