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.

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.
  
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