Da die ursprüngliche Frage eigentlich gelöst ist, mache ich mal ein neues allgemeines Thema auf.
Ich habe an meinem Raspberry Pi Pico mit "Betriebssystem" PicoMite jetzt eine SD-Karte drangebastelt (nach der deutschen PicoMite-Anleitung).
Die SD-Karte ist 2GB groß und mit FAT32 formatiert.
Das funktioniert auch soweit...
Nur warum sehe ich die Dateien, die ich mit dem PC auf die SD-Karte geschrieben habe, nicht auf dem Pico,
und warum sehe ich die Dateien, die ich mit dem Pico draufgespeichert habe, nicht auf dem PC?
Ich habe ohne Laufwerksangabe mittels <save "name"> das Programm gespeichert.
Laut PicoMite-Anleitung speichert das auf SD-Karte.
Mit <files> wurde auch die Datei "name" angezeigt (nur die und bootcount) und eine Laufwerksgröße von 2GB. Also ist es die SD-Karte.
Im PC sind sind ein paar .h2w-Dateien und eine (andere) .bas-Datei auf der SD-Karte. Diese sind auf dem Pico nicht zu sehen, ebenso wie die Dateien "name" und bootcount desPico auf dem PC nicht zu sehen sind.
CWD$
Will return the current working directory.
EOF( #fnbr )
Will return true if the file previously opened for INPUT with the file number ‘#fnbr’ is positioned at the
end of the file.
LOC( #fnbr )
For a file opened as RANDOM this will return the current position of the read/write pointer in the file.
LOF( #fnbr )
Will return the current length of the file in bytes.
MM.INFO(drive)
Will return the current active drive – ie, "A:" or "B:"
MM.INFO(free space)
Will return how much space is left on the active drive
MM.INFO(disk size)
Will return the size of the active drive
Bitte schaue doch ins Forum The Backshed um dort direkte Infos zu
bekommen so wie Antworten auf Deine Fragen.
Für die Forenaktivisten hier, ist MMBASIC nur Spielerei.
Schade.
Für mich ist Basic (das ich vor 40 Jahren recht gut konnte) die einzige Möglichkeit den µC zu programmieren.
Mit den in PicoMite eingbauten Funktionen rücken etliche bisher zu den Akten gelegten Projekte wieder in greifbare Nähe.
Gibts irgendwo ein deutschsprachiges Forum zu PicoMite?
Bitte schaue doch ins Forum The Backshed um dort direkte Infos zu
Schade.
Für mich ist Basic (das ich vor 40 Jahren recht gut konnte) die einzige
Möglichkeit den µC zu programmieren.
Gibts irgendwo ein deutschsprachiges Forum zu PicoMite?
Es gibt ja weitere BASIC Dialekte, wie z.B. BASCOM (mcselec.com) oder mikroBasic (mikroe.com). Bei BASCOM gibt es ein deutsches Forum.
Erfahrungsgemäß sind die englischsprachigen Foren mindestens genauso gut. Klar, sprachlich könnte es eine Hürde sein. Es gibt aber gute Übersetzer - das geht schon. Vor allem eröffnet sich damit eine sehr breite Palette an Projekten in aller Welt, da ist fast jedes Problem schon einmal gekaut worden.
Hier im Forum kannst Du nach ASM & C fragen, alles andere ist suboptimal.
Es gibt ja weitere BASIC Dialekte, wie z.B. BASCOM
Wenn ich irgendwo auf BASCOM gestoßen bin, sah mir der Dialekt etwa so aus, wie der Unterschied zwischen Hochdeutsch und Bayrisch.
Laut einer kurzen Google-Nachfrage scheint es außerdem BASCOM nicht für den Pico zu geben.
Erfahrungsgemäß sind die englischsprachigen Foren mindestens genauso
gut. Klar, sprachlich könnte es eine Hürde sein
In Fremdsprachen war ich noch nie sehr gut, und inzwischen bin ich zu alt, um mehr als Datenblätter und kurze Beschreibungen auf Englich ohne Kopfschmerzen zu lesen.
Gerade die deutsche PicoMite-Anleitung hat mich dazu gebracht, erfolgversprechend mit dem Pico zu experimentieren.
Wenn die PicoMite-Anleitung wenigstens systematischer aufgebaut wäre, oder es Querverweise zu verwandten Befehlen gäbe.
Wie findet man denn darin, was man gerade braucht?
Wenn die PicoMite-Anleitung wenigstens systematischer aufgebaut wäre,
oder es Querverweise zu verwandten Befehlen gäbe.
Wie findet man denn darin, was man gerade braucht?
PDF Suche, ganz einfach
Uwe D. schrieb:
Hier im Forum kannst Du nach ASM & C fragen, alles andere ist
suboptimal.
Zumindest habe ich hier einige brauchbare Antworten bekommen.
Vielleicht lassen sich ja noch andere PicoMite-Fans anlocken...?
Vergiss es.
Ich bin ein Fan und war von Anfang an dabei.
Viele dort sind eit jenseits der 60.
Was Geoff/Peter da auf die Beine stellen ist einfach nur cool.
Jag es doch einfach beidseitig durch den Google Translator.
Das funktioniert einwandfrei und die Sprachbarriere ist beseitigt
Mach Dir einen Account in The Backshed.
Da helfen auch einige deutschsprachige gern, ich auch ;-)
Man muß halt mit der linken Maustaste dort draufdrücken.
Falls das zu komplex ist, an er Volkshochschule gibt es Computerkurse...
Ist das was halbwegs Offizielles, oder noch geheime Alpha-Version?
Wenn ersteres erinnert mich das an DD-WRT. Auf den offizellen Seiten findet man nur total veraltete Infos und Firmware, will man aktuelles, muß man tief in den Foren suchen...
Ist das was halbwegs Offizielles, oder noch geheime Alpha-Version?
Wenn ersteres erinnert mich das an DD-WRT. Auf den offizellen Seiten
findet man nur total veraltete Infos und Firmware, will man aktuelles,
muß man tief in den Foren suchen...
So langsam nervst Du.
Was soll das geschwurbel hier?
Lade das doch runter und probier es aus, dafür der Link!!!
Viele neue Sprachbestandteile von MMBASIC dienen ja auch nur
der Programmierung von Spielen. Da ist so eine Kritik ja
irgendwo auch berechtigt.
Wenn man selbst MMBASIC richtig benutzen will, muss man es sich
selbst bauen. Weil es an vielen Stellen gegenueber C oder
Assembler zu langsam ist, und man selbst entsprechende
Erweiterungen des Interpreters hinzufuegen muss. Ausserdem hat
man nur so den vollen Zugriff auf die symbolischen Adressen,
die sich zwischen den Builds natuerlich auch aendern koennen.
Ich benutze aber auch nur den alten Maximite in der Inkarnation
als Duinomite von Olimex. Auch dessen Dokumentation wat/ist
lueckenhaft und stellenweile unstrukturiert. Aber mit den
Quellen bei der Hand, kann man dann ja selber nachsehen, was
wo und wie gespielt wird.
Das besagte Forum war bei meinem letzten Besuch eher ein Desaster.
Informationen waren verstreut und selbst eine einfache Suchfunktion
gab es nicht. Der Forenbetreiber scheint auch gewisse Standards
bzgl. der Sicherheit nicht sehr ernst zu nehmen.
Erkennbar daran, dass nach einem Registrierungsversuch ploetzlich
Spam aus Australien bei meinem Emailkonto aufschlug.
Viele neue Sprachbestandteile von MMBASIC dienen ja auch nur
der Programmierung von Spielen. Da ist so eine Kritik ja
irgendwo auch berechtigt.
So ein Quatsch, wir reden hier von den aktuellen Systemen
Wenn man selbst MMBASIC richtig benutzen will, muss man es sich
selbst bauen. Weil es an vielen Stellen gegenueber C oder
Assembler zu langsam ist, und man selbst entsprechende
Erweiterungen des Interpreters hinzufuegen muss. Ausserdem hat
40000 Codezeilen pro Sekunde, langsam? Un C Funktionen kann man auch implementieren , oder auch die PIO Struktur auf den PI Pico's
man nur so den vollen Zugriff auf die symbolischen Adressen,
die sich zwischen den Builds natuerlich auch aendern koennen.
Ich benutze aber auch nur den alten Maximite in der Inkarnation
als Duinomite von Olimex. Auch dessen Dokumentation wat/ist
lueckenhaft und stellenweile unstrukturiert. Aber mit den
Quellen bei der Hand, kann man dann ja selber nachsehen, was
wo und wie gespielt wird.
Früher wurde Fett auch noch mit "O" geschrieben.
Das besagte Forum war bei meinem letzten Besuch eher ein Desaster.
Informationen waren verstreut und selbst eine einfache Suchfunktion
gab es nicht.
Man muss schon aktiv dabei bleiben, ja.
Der Forenbetreiber scheint auch gewisse Standards
bzgl. der Sicherheit nicht sehr ernst zu nehmen.
Erkennbar daran, dass nach einem Registrierungsversuch ploetzlich
Spam aus Australien bei meinem Emailkonto aufschlug.
Kann ich überhaupt nicht bestätigen.
Du solltest Deinen verseucheten Rechner mal neu aufsetzen
40000 Codezeilen pro Sekunde, langsam? Un C Funktionen kann man auch
implementieren , oder auch die PIO Struktur auf den PI Pico's
Wenn man auf dem Display z.B. ueber Messdaten ein Raster legen will,
sind 40000 Zeilen/s u.U. zu langsam.
Wenn man den/die AD-Wandler bzgl. ihrer Samplerate voll ausnutzen
will, sind 40000 Zeilen/s definitiv zu langsam.
Wie willst du fuer etwas C Funktionen schreiben, wenn du die
Adressen der Symbole gar nicht kennst?
Richtig, gar nicht.
Von den paar fixen Hardwareadressen mal abgesehen.
Soweit ich weiss, sind die MMBASIC Quellen fuer den Picomite
auch nicht frei verfuegbar.
So ein Quatsch, wir reden hier von den aktuellen Systemen
Selbst so ein alter MIPS schafft nativ einiges mehr als
40000 Codezeilen pro Sekunde
Ich bin mit dem Duinomite/Maximite deswegen sehr zufrieden.
Weil ich eben nicht ausschliesslich auf MMBASIC angewiesen bin.
Kann ich überhaupt nicht bestätigen.
Du solltest Deinen verseucheten Rechner mal neu aufsetzen
Aha. Das ist schoen fuer dich, aendert aber nichts an meiner
Aussage. Es war uebrigens nicht mein Rechner, den es nach
australischem Spam verlangt hat.
Viele neue Sprachbestandteile von MMBASIC dienen ja auch nur
der Programmierung von Spielen. Da ist so eine Kritik ja
irgendwo auch berechtigt.
Welches sind denn die "Spielebefehle"?
Ich habe die Befehle von PicoMite bisher nur grob überflogen, weil ich mich in erster Linie nur um das kümmere, was ich gerade brauche, aber es scheinen mir größtenteils normale Basicbefehle zu sein, die weitgehend dem C=-Basic 7.0 (das des C128) entsprechen.
Aufgefallen sind mir die extrem vielen Grafikbefehle, aber die scheinen ja für den Aufbau von Bedien-GUIs sehr sinnvoll zu sein.
Wenn man selbst MMBASIC richtig benutzen will, muss man es sich
selbst bauen.
Ich möchte den Pico als µC einsetzen um Signale von irgendwelcher Hardware zu verarbeiten und damit andere Hardware zu steuern.
Ich betreibe gerade Grundlagenforschung, welche meiner Hardware ich wie am Pico betreiben kann (etwas verwundert mich, daß es scheinbar keine eingebaute Abfrage für einen Drehencoder gibt...).
Daraus entstehen eine Menge kleiner Progrämmchen, die ich dann weiterverwenden kann. Irgendwie muß ich noch rausfinden, wie ich die als Funktionen in PicoMite einbinden kann...
Z.B. das Handling von "Sprites".
Der C64/C128 hatte die uebrigens ja auch.
Aber mit dem sollte/musste man ja auch spielen koennen :).
Aufgefallen sind mir die extrem vielen Grafikbefehle, aber die
scheinen ja für den Aufbau von Bedien-GUIs sehr sinnvoll zu sein.
Fuer die Bedienelemente einer GUI wird die Geschwindigkeit
schon reichen. Aber wenn man Messwerte darin darstellen will
fallen dabei schon komplexere Dinge an, wie z.B. ein Messraster
das ueber die Messwerte gelegt wird. Wie es ein Oszilloskop
ja auch tut. Und wenn man das mit den Basicbefehlen
zusammenstueckelt, wird es doch langsam. Fuer einen Prototyp
waere das noch O.K., aber in der Praxis auf Dauer doch stoerend.
Ich möchte den Pico als µC einsetzen um Signale von irgendwelcher
Hardware zu verarbeiten und damit andere Hardware zu steuern.
Solange dabei keine zeitkritische Dinge im Spiel sind,
wird das schon gehen. Du kannst es ja mal mit deinem
Drehencoder probieren, wie weit du damit in MMBASIC kommst.
Ich benutze selbst eine relativ alte Version des MMBASIC,
fuer das ich aber die Quelldateien habe. Ich habe mir mit
diesen Quelldateien ein MPLAB-Projekt erzeugt und kann damit
sehr einfach das MMBASIC um eigene Befehle ergaenzen.
Die laufen dann mit der vollen Geschwindigkeit einer echten
32 bit CPU (Microchip PIC32/MIPS 80 MHz).
Daher haelt sich mein Interesse am Picomite in Grenzen.
Als einfaches :) Beispiel der SYS Befehl der in MMBASIC fehlt:
1
// Main.c
2
void __attribute__ ((naked)) cmd_sys (void);
3
4
void __attribute__ ((naked)) cmd_sys (void) {
5
void (*cmd_ram_sys_ptr)();
6
__asm__ (" addiu $29,$29,-4");
7
__asm__ (" sw $31,0($29)");
8
cmd_ram_sys_ptr = 0xa0016000;
9
(* cmd_ram_sys_ptr)();
10
__asm__ (" lw $31,0($29)");
11
__asm__ (" addiu $29,$29,4");
12
__asm__ (" nop");
13
}
Diese etwas "spezielle" Version, startet den Code ab 0xa0016000.
Schade.
Für mich ist Basic (das ich vor 40 Jahren recht gut konnte) die einzige
Möglichkeit den µC zu programmieren.
Ist doch Unsinn. Als ob C so viel anders wäre dass man das niemals lernen könnte. Vor allem wenn man an sich schon programmieren kann. Für einfache Dinge, die man auch nicht mit Basic machen kann, reichen doch 2 Wochen bis man das in C auch kann.
Solange dabei keine zeitkritische Dinge im Spiel sind,
wird das schon gehen. Du kannst es ja mal mit deinem
Drehencoder probieren, wie weit du damit in MMBASIC kommst.
Bislang funktioniert das Testprogrämmchen recht gut:
Ist doch Unsinn. Als ob C so viel anders wäre dass man das niemals
lernen könnte.
Mit C habe ich abgeschlossen, dazu habe ich überhaupt keinen Draht.
Vielleicht versuche ich es später mal mit Phyton.
Ich hatte schon MicroPhoton auf dem Pico, aber nicht mehr als "Hallo Welt" und blinkende Led (nach Anleitung) zustande gebracht.
Ist doch Unsinn. Als ob C so viel anders wäre dass man das niemals
lernen könnte.
Mit C habe ich abgeschlossen, dazu habe ich überhaupt keinen Draht.
Vielleicht versuche ich es später mal mit Phyton.
Ich hatte schon MicroPhoton auf dem Pico, aber nicht mehr als "Hallo
Welt" und blinkende Led (nach Anleitung) zustande gebracht.
Python ist sehr gut lesbar, es gibt wenig Überraschungen… Im Web und im Handel finden sich für Einsteiger deutschsprachige Dokumente/Dokumente, die sich auch mit Hardware auseinandersetzen.
Bislang funktioniert das Testprogrämmchen recht gut
Na siehst.
Mit C habe ich abgeschlossen, dazu habe ich überhaupt keinen Draht.
C ist auf Controllern zumindest sinnvoll verwendbar.
Und auch weil die Syntax recht sparsam erscheint,
eigentlich in den Grundzuegen recht leicht erlernbar.
Vielleicht einfach nochmal versuchen. :)
Mit einem kleinen und uebersichtlichen Controller, was der
Pico aber definitiv nicht ist.
Der Wunsch nach schnellerer Ausfuehrung bestimmer Codeabschnitte
wird bei dir auch noch kommen. Und da waere die Alternative
Python nicht wesentlich besser, als was du schon hast und kennst.
Das war bei mir auf anderer Ebene, naemlich FPGAs und VHDL
genau so.
Falls das in meine Richtung war:
Ohne Quellen des Interpreters fang ich damit gar nichts an.
Da ist mir ein 80 MHz MIPS unter der Haube lieber, als der
"geile" Scheiss von heute.
Vielleicht versuche ich es später mal mit Phyton.
Ich hatte schon MicroPhoton auf dem Pico, aber nicht mehr als "Hallo
Welt" und blinkende Led (nach Anleitung) zustande gebracht.
Na ja, Python (oder irgend eine andere Programmiersprache) lernt man nicht auf einem Controller, sondern am PC. Das ist um ein Vielfaches bequemer.
Wenn man anschließend die Grundlagen beherrscht, dann ist der Sprung zum Controller deutlich einfacher.
Vielleicht versuche ich es später mal mit Phyton.
Ich hatte schon MicroPhoton auf dem Pico, aber nicht mehr als "Hallo
Na ja, Python (oder irgend eine andere Programmiersprache) lernt man
nicht auf einem Controller, sondern am PC. Das ist um ein Vielfaches
bequemer.
Also die Hürde für Peter ist Englisch denke ich, nicht MicroPython. Allerdings fand ich die Hardwareunterstützung schon sehr gut. Viele aus dem Arduino-Umfeld bekannten Sensoren/Baugruppen/Displays usw. sind entweder schon von einem der großen Anbieter implementiert worden oder lassen sich einfach übertragen.
Der ‚mitleidige Blick’ bei diversen Sprachen hier im Forum ficht mich nicht an, denn die setze ich ja mit Absicht ein. Und dabei spielt dann das Projekt und dessen Rahmenbedingungen eine wichtige Rolle.
Für eine simple Anwendung ohne Zwänge vergeude ich nicht meine Zeit, um 2k Flash zu sparen, 4ms schneller zu sein oder eine akademisch brilliante Meisterleistung abzuliefern. Zuverlässig, schnell, kostenorientiert.
Mit einem kleinen und uebersichtlichen Controller,
Da würde ich es eher mit Assembler versuchen. Etwas 6502 und
68000-Vergangenheit habe ich auch.
Da koenntest du dir beim Pico mit Assembler einen Bruch heben.
Wenn es ein aktueller und in D gut supporteter Controller sein
soll, kaemen mir am ehesten die STM-8 von ST in den Sinn.
Die sind von der Architektur dem 6502 nicht ganz unaehnlich.
Es gibt guenstige Eval/Testboards (STM8S-Discovery).
Fuer einen einfachen Einstieg gibt es funktionseingeschraenkte
aber kostenfreie IDEs. Das waere z.B. die Kickstartversion
der "IAR Embedded Workbench for STM-8".
Die zum Programmieren noetigen Adapter sind bei ST schon
Teil des Boards und lassen sich auch spaeter fuer eigene
Projekte nutzen.
Auch bei Freescale finden sich aktuell noch Abkoemmlinge
des 6800. Auch die 8 bitter von Renesas RL78 sind in der
Architektur eng an den 6800 angelehnt.
Problem sind da dann aber Entwicklungsumgebung und
Programmieradapter. Auch die Beschaffung der Controller
kann da schwieriger sein.
Mein Tipp: Sieh dir den STM-8 zumindest mal an.
Das waere auch eine gute Gelegenheit, den Gebrauch
des Fachenglich zu ueben. Der ist naemlich unabwendbar.
vergeude ich nicht meine Zeit, ... eine akademisch
brilliante Meisterleistung abzuliefern. Zuverlässig, schnell,
kostenorientiert.
Geruechteweise soll es auch Fachkraefte geben, die eine
akademisch brilliante Meisterleistung zuverlässig, schnell,
und kostenorientiert abliefern koennen.
Vermutlich ist aber dein moeglicher Aktionsradius ohnehin auf
MicroPython
beschraenkt. Fuer dein Gewurschtel zu Hause ist das ja ohne Belang.
Aber was meinst du, fuer wie viele Industrieprojekte
MicroPython
eine Ausgangsbasis ist?
Und auch im Hobby-, Bastler- oder Amateurbereich sehe ich
da noch keine ernstzunehmende Marktpenetration.
Es ist also nichts was sich irgendwie zwingend anbieten wuerde.
Ich habe gerade mal etwas mit I²C rumprobiert.
Funktioniert hat erstmal nichts, deshalb erstmal eine Grundsatzfrage:
Nutzt der Pico auf den I²C-Signalen seine internen Pullups, oder braucht er externe Pullups?
Ich habe gerade mal etwas mit I²C rumprobiert.
Funktioniert hat erstmal nichts, deshalb erstmal eine Grundsatzfrage:
Nutzt der Pico auf den I²C-Signalen seine internen Pullups, oder braucht
er externe Pullups?
Also mein Datenblatt gibt darauf eine zufriedenstellende Antwort.
Ich habe gerade mal etwas mit I²C rumprobiert.
Funktioniert hat erstmal nichts, deshalb erstmal eine Grundsatzfrage:
Nutzt der Pico auf den I²C-Signalen seine internen Pullups, oder braucht
er externe Pullups?
I2C sollte externe Pull Ups bekommen. Denn interne liegen im Bereich von 50k. 4,7k ist empfohlen. So werden die Flanken recht verschliffen und höhere Taktraten sind nicht möglich.
Verstehe auch nicht wieso man an zwei Widerständen sparen muss.
vergeude ich nicht meine Zeit, ... eine akademisch
brilliante Meisterleistung abzuliefern. Zuverlässig, schnell,
kostenorientiert.
Geruechteweise soll es auch Fachkraefte geben, die eine
akademisch brilliante Meisterleistung zuverlässig, schnell,
und kostenorientiert abliefern koennen.
Vermutlich ist aber dein moeglicher Aktionsradius ohnehin auf
MicroPython
beschraenkt. Fuer dein Gewurschtel zu Hause ist das ja ohne Belang.
Arrogantes Bashing. Wieviele Senior/Advisory/Architect Developer Anteil hast Du denn in normalen Teams - 80%?
Das Prinzip der Ökonomie verbietet „so gut wie möglich“.
Aber was meinst du, fuer wie viele Industrieprojekte
MicroPython
eine Ausgangsbasis ist?
Und auch im Hobby-, Bastler- oder Amateurbereich sehe ich
da noch keine ernstzunehmende Marktpenetration.
Es ist also nichts was sich irgendwie zwingend anbieten wuerde.
Sage Du es mir. Und vergiss die Beweisführung mit nachprüfbaren Zahlen nicht.
Wie oft haben Propheten die Bedeutungs- und Sinnlosigkeit von anderen vermeintlichen Spielzeugen a la RasPi oder Arduino verkündet, nur der Markt hält sich nicht dran…
Arrogant ist, wer auf einer grossen Baustelle nur mit einem Hammer
auftaucht, und die anderen am Bau Beteiligten wegen ihres verwendeten
Werkzeugs, als dumm diffamiert.
Und am Ende unverrichteter Dinge wieder abziehen muss, weil es
nun wirklich nichts zu nageln gab.
Nach dem 16.02.2023 um 16:49 ist der Thread entgleist, tot
und hat nichts mehr mit der Überschrift zu tun
Das war's, bye....
Nur weil nicht alle 10 Minuten jemand mit einer Frage auftaucht?
Ich bin aufgrund dieses Threads neugierig geworden, habe Picomite heruntergeladen und probiere es jetzt aus. Soll das jetzt heißen, daß ich für meine Anfängerfragen jedesmal einen neuen Thread aufmachen soll?
Gruß Klaus (der soundsovielte)
P.S. Eine lange Liste von Youtubevideos ist für mich völlig irrelevent, da ich an einer ziemlich dünnen Internetleitung hänge und alles Andere als Text ziemlich lange dauert. Habe ich da etwas Wichtiges verpaßt? (Liste vom 16.8.03 16:49)
Es schadet sicher nicht, wenn man sich die Historie der ganzen
*mites mal ansieht.
Der Urvater aller MMBASIC-Versionen lief auf einem PIC32, und es gibt
auch eine Version die auf PIC32 in einem 28 pol. DIL-Package laueft.
Der erstere war der Maximite und die kleinere Version der Micromite.
Die Quellen fuer den Picomite stehen tatsaechlich zur Verfuegung.
Vermutlich weil es gegen das unter GPL stehende Picomite-SDK
gelinkt wird.
Manche Frage die das Manual womoeglich nur unvollkommen beantwortet,
kann man fuer sich so beantworten.
Ja, einen Breitbandausbau.
Schaus Dir halt gepuffert an / Download über Nacht.
Die Videos geben Dir einen schnellen Überblick und
das Forum ist unerlässlich.
Die Videos geben Dir einen schnellen Überblick und
das Forum ist unerlässlich.
Habe gerade in meinen alten Unterlagen gewühlt. Mein erster Kontakt zum Maximite war im Juli 2012. Nachdem ich aber entdeckt hatte, daß die Pins, die für Ethernetkopplung (wenn man denn einen MX795 statt eines MX765 einbbauen würde) benötigt würden, auf isolierten Pads saßen, unbenutzt waren und von Massefläche umgeben waren, so daß das Anlöten von weiterführenden Drähten maximal erschwert wurde, schwand meine Begeisterung schlagartig. Damals habe ich das unter "brain-damaged" abgelegt. Heute bin ich nachsichtiger und sage "shit happens". VGA und Tastatur brauchte ich weder damals noch heute.
Der Picomite scheint die Dinge intelligenter anzugehen. Das große Plus des Pico sind für mich die PIOs, und deren Unterstützung scheint im Basic enthalten zu sein, das ist der Knackpunkt, der mich interessiert. Der Hinweis, daß das Forum unerläßlich ist, deutet aber eher darufhin, daß das Ganze immer noch eine ziemliche Bastlerlösung ist. Ich hoffe trotzdem, daß das nicht zutrifft. Bisher funktioniert alles wie beworben.
Wenn Du absolut aktuell, bei neusten Entwicklungen dabei sein willst, dann stimmt das so.
Momentan wird der Pico W um TCP/ WEB/ Telnet erweitert, Alpha Stadium, Downloads und „Doku“ nur hier.
Ansonsten bekommst Du auf der Webseite von Geoff Graham, die Firmware, Doku, Projekte und alles Weitere zu allen Plattformen auf welche portiert wurde, so wie Unterstützung.
Im Forum gibt es auch einen Lehrgang zu den Pio Funktionen.
Geoff Graham und Peter Mather treiben alles voran.
Der LM73 hat laut Datenblatt die Adresse &B1001 101x
Der Scanner findet den aber unter Adresse &B01001101 und &B11001101.
Wie kommt das?
Aufbau? Der Sensor ist schnell, wenn da längere Leitungen für CLK und DATA sind ("Steckbrett") klingelt es ggfs da was wo es nicht sollte, daher: Signale mit Oszi genauer anschauen, den Unterschied zw. SMB und I2C analysieren und vor allem im picomite-Forum fragen.
Das liest man immer wieder, wenn dem Autor nichts einfällt. Als nächstes soll dann ein Foto mit den Abblockkondensatoren gezeigt werden :-(
Mal ganz allgemein zu PicoMite: Ein Interpreter eignet sich dann, wenn man mal schnell ein Programm braucht, was nicht unbedingt viel können muß. Da stören dann weder Ausführungszeit noch die Feinheiten, eigene Funktionen einzubinden. Wenn man Daten vom Multimeter erfassen und umgerechnet anzeigen möchte, geht das recht schnell mit ein paar Zeilen Code.
Um Bilder auf einem TFT zu malen, ist ein Interpreter weniger geeignet, außer man gönnt sich die Zeit, dabei zuzusehen ;-)
Weiter mit I²C:
Der LM73 hat laut Datenblatt die Adresse &B1001 101x
Der Scanner findet den aber unter Adresse &B01001101 und &B11001101.
Wie kommt das?
I2C verwendet (ursprünglich) nur 7 Bit zur Adressierung (also 2^7=128 abzgl. 16 reservierter Adressen), das letzte Bit unterscheidet zwischen Lesen/Schreiben.
I2C verwendet (ursprünglich) nur 7 Bit zur Adressierung
Nee, es sind 8 Bit. Das unterste Bit gibt an, ob es sich um eine Lese-
oder Schreibadresse handelt ;-)
Wo ist da der Unterschied? Das Gerät wird mit 7 Bit adressiert… lassen wir das.
Der LM73 wird übrigens in zwei Versionen geliefert, -0 und -1. Dadurch kann über den Address PIN (Offen, Maße, Versorgungsspannung) und die zwei Versionen aus 6 möglichen Adressen ausgewählt werden.
Jeder, der das R/W Bit zur Adresse zählt und somit von 8 Bit spricht, stiftet nur unnötig Verwirrung. Die Adresse hat 7 Bit und das R/W Flag ist eine anderer Parameter. Das sollte jede API so wieder spiegeln.
7-Bit Addressing
The standard addresses used in these commands are 7-bit addresses (without the read/write bit). MMBasic will add the read/write bit and manipulate it accordingly during transfers.
Some vendors provide 8-bit addresses which include the read/write bit. You can determine if this is the case because they will provide one address for writing to the slave device and another for reading from the slave. In these situations you should only use the top seven bits of the address. For example: If the read address is 9B (hex) and the write address is 9A (hex) then using only the top seven bits will give you an address of 4D (hex).
Another indicator that a vendor is using 8-bit addresses instead of 7-bit addresses is to check the address range. All 7-bit addresses should be in the range of 08 to 77 (hex). If your slave address is greater than this range then probably your vendor has provided an 8-bit address.
Some vendors provide 8-bit addresses which include the read/write bit.
So am I.
Ein Blick in ein 24Cxx Datenblatt von Atmel zeigt die 8 Bit der Basisadresse inkl. R/W. Mir war 0xA0 schon immer sinnvoller und einprägsamer als 0x48.
Sehe ich ins Datenblatt eines PCF8583 von NXP (Philips), dann taucht auch dort die "slave address" mit Basis 0xA0 auf. Wiederum sind es 8 Bit.
Anders sieht es aus, wenn zum Beispiel ein LCD-Modul mit einer separaten data/cmd-Leitung adressiert wird. Dieses Signal ist dann von der Adresse abgekoppelt.
Das liest man immer wieder, wenn dem Autor nichts einfällt. Als nächstes
soll dann ein Foto mit den Abblockkondensatoren gezeigt werden :-(
Ach mei... ich hab in den letzten Jahrzehnten schon so viele Sünden am I2C gesehen das /das/ immer eine der ersten Fragen zum I2C ist. Clk & Data verdrillt und dann GND irgendwo anders weil Steckbrett.... und prompt sind die jeweiligen fallenden Flanken am anderen Signal zu sehen. Blöd wenn es eine grindige I2C-Statemaschine im Chip ist die sich dann verläuft und sich auch nicht mehr über irgendwelche CLK-Orgien resetieren läßt weil der werte Chipdesigner nicht daran gedacht hat das dies passieren kann und auch kein Resetpin vorhandne ist. Alles schon dagewesen...
Daher - sei so nett und spar Dir Deine Anpatzungen, Du hast das wirklich nicht nötig bei dem was Du sonst an Konstruktivem hier beiträgst....
Ach mei... ich hab in den letzten Jahrzehnten schon so viele Sünden am
I2C gesehen das das immer eine der ersten Fragen zum I2C ist.
Mag sein, aber hier ist es bei genauem Hinsehen die Interpretation der Adresse.
Im Datenblatt sieht man beim LM73 das 8 Bit "serial bus address byte" und die Software "läßt es nicht zu", dieses wie gezeigt zu verwenden.
Gerade bei hardware-naher Programmierung finde ich das recht ungeschickt.
Das mit den 7 Bit habe ich ich schon vermutet,
aber ich verstehe noch nicht, wie PicoMite das handhabt.
Die I²C-Adresse ist ja ein 8-Bit-Wort, bei dem das Bit 0 RW darstellt.
Oder anders ausgedrückt, gerade Adresse schreibt, ungerade Adresse liest.
Wie macht das PicoMite?
Übergebe ich bei I2C read/write eine 8-Bit Adresse und PicoMite ändert Bit 0 entsprechend Lesen/Schreiben,
oder ich übergebe eine 7-Bit-Adresse, PicoMite hängt Bit 0 dran (und verschiebt damit alle Bits 1 nach links)?
Die I²C-Adresse ist ja ein 8-Bit-Wort, bei dem das Bit 0 RW darstellt.
Nein!
Die I²C Adresse ist ein 7 Bit Wort. Danach wird das R/W Bit übertragen. Das sind zweierlei Parameter. Wie PicoMite das handhabt, sollte in dessen Doku stehen.
Da steht ganz klar "The standard addresses used in these commands are 7-bit addresses (without the read/write bit). MMBasic will add the read/write bit and manipulate it accordingly during transfers."
Da steht ganz klar "The standard addresses used in these commands are
7-bit addresses (without the read/write bit). MMBasic will add the
read/write bit and manipulate it accordingly during transfers."
Was ich bereits 8 Einträge davor geschrieben habe.
Niemand hört mehr zu, niemand liest…………
Alles nur Berieselung und jeder macht nen 1 er Abi…
Gibt es ein Ziel, daß Du mit PicoMite erreichen willst?
Das Ziel hatte ich bereits weiter oben erwähnt:
Ich will den Pico als Kontroller einsetzen, um Hardware abzufragen und andere Hardware zu steuern. PicoMite ist dabei (für mich) das ideale Mittel.
Momentan betreibe ich eine Art Grundlagenforschung:
Ich habe eine Menge Sensoren und andere Input-Geräte sowie Displays und andere Output-Geräte rumliegen. Diese versuche ich am Pico zum Laufen zu bekommen.
Im Moment ist der LM73 (um I²C zu lernen) dran.
Da ich aus vorhandenen Sources mehr lerne, als aus dem Manual, hätte ich nichts dagegen, wenn hier auch PicoMite-Source-Schnipsel veröffentlicht werden.
Spätere Projekte wären dann:
Doppelpuls-Punktschweißsteuereng für meine Pedelec-Akkus (momentan ist da ein China-Billigsteuerung drin).
Akkuentlader (zur Kapazitätsermittlung der Pedelec-Akkus).
Prekontroller fürs Pedelec (momentan zufuß aufgebaut).
DCF-Uhr.
Und eine Menge der Sensoren könnte man für eine Wetterstation verwenden.
Und dauernd fallen mir neue Sachen ein, die möglich wären...
Da steht ganz klar "The standard addresses used in these commands are
7-bit addresses (without the read/write bit). MMBasic will add the
read/write bit and manipulate it accordingly during transfers."
Dass die Adresse in der API 7 Bit groß ist und dass das R/W Bit nicht darin enthalten ist.
Also so wie sich das gehört. Auch die Arduino Leute haben das richtig umgesetzt. Mir ist völlig schleierhaft, wieso immer wieder Leute auftauchen, die mit ihren 8 Bit Verwirrung stiften. Das ist total unnötig.
Dass die Adresse in der API 7 Bit groß ist und dass das R/W Bit nicht
darin enthalten ist.
Also so wie sich das gehört. Auch die Arduino Leute haben das richtig
umgesetzt. Mir ist völlig schleierhaft, wieso immer wieder Leute
auftauchen, die mit ihren 8 Bit Verwirrung stiften. Das ist total
unnötig.
Und MMBasic das Lese-/Schreibbit selbst hinzufügt:
„MMBasic will add the read/write bit and manipulate it accordingly during transfers.“
Die Adresse des LM73 ist &B 1001 101 (in Datenblatt geschickterweise nur
binär angegeben).
Ist das nun &H 9A/9B oder &H 4D?
…
Also gebe ich die Adresse &H 4D an PicoMite und das sendet dann &H 9A/9B
an den LM73?
Also ich würde 4D übergeben. Das ist die Adresse des Chips am I2C Bus.
Ich will den Pico als Kontroller einsetzen, um Hardware abzufragen und
andere Hardware zu steuern. PicoMite ist dabei (für mich) das ideale
Mittel.
Und hast Du permanent ein Display und eine Tastatur angeschlossen oder geht alles über einen PC?
Interpreter sind dann interessant, wenn man auf dem Zielsystem direkt entwickeln will. Man sieht sofort, ob es geht oder sogar läuft. Änderungen/Ergänzungen sind fix erledigt.
Mal sehen, vielleicht werfe ich PicoMite mal selber an.
Mal sehen, vielleicht werfe ich PicoMite mal selber an.
Eine uf2-Datei draufkopieren und ein VT100-kompatibles PC-Programm heraussuchen, mehr brauchts nicht. Selten so einen unkomplizierten Einstieg gesehen.
Und hast Du permanent ein Display und eine Tastatur angeschlossen oder
geht alles über einen PC?
Zum Rumprobieren hängt der Pico per USB am PC und Ein/Ausgabe erfolgt über Terminalprogramm.
Später bei den Projekten läuft die Ein/Ausgabe entsprechend der Aufgabe.
Für die Schweißsteuerung und Akkuentlader z.B. brauche ich dann einen Drehencoder zur Eingabe und ein 2-zeiliges Display zur Ausgabe.
Interpreter sind dann interessant, wenn man auf dem Zielsystem direkt
entwickeln will. Man sieht sofort, ob es geht oder sogar läuft.
Änderungen/Ergänzungen sind fix erledigt.
Genau das ist ja das Praktische daran.
Ich kann Befehle direkt eingeben, oder Programmschnipsel schreiben und sehe sofort das Ergebnis.
Man beachte die Schreibweise im Datenblatt:
Bit 7-1, Bit 0 weggelassen.
Ist es da nicht verständlich, daß man nicht weiß, ob man Bit 7-1 verwendet und Bit 0 als "don't care", wie hier
Eine uf2-Datei draufkopieren und ein VT100-kompatibles PC-Programm
heraussuchen, mehr brauchts nicht. Selten so einen unkomplizierten
Einstieg gesehen.
Der 6502 hat 64k Adressvolumen.
Bei den CBM-Geräten (zu denen ich den PET auch mal zähle) wurde A15 zur Ram/Rom-Umschaltung verwendet, also maximale Rom-Ausbaustufe 32k.
Aber da war ja auch nur ein abgespecktes Basic drin.
To setup the display you use the BITBANG LCD INIT command:
BITBANG LCD INIT d4, d5, d6, d7, rs, en
d4, d5, d6 and d7 are the numbers of the I/O pins that connect to inputs D4, D5, D6 and D7 on the LCD module
(inputs D0 to D3 and R/W on the module should be connected to ground). 'rs' is the pin connected to the
register select input on the module (sometimes called CMD or DAT). 'en' is the pin connected to the enable or
chip select input on the module.
Beim Programmlauf wackeln alle Pins kurz,
danach bleibt RS und D6 high, alle anderen Low.
ist fuer eine Fehlersuche ja etwas duerftig.
Um das LCD als funktionierend zu testen, wuerde ich es
an einen anderen Controller der ein LCD richtig
initialisert, und darauf etwas ausgibt, anschliessen.
Das LCD hat ja nur Eingaenge, so dass Parallelbetrieb
nicht stoert.
Fuer eine weitere (dynamische) Fehlersuche waere dann
ein Oszi und ein Logikanalyzer noetig.
Damit kontrolliert man dann, ob die Signale dem entsprechen
was das Datenblatt des LCD so vorsieht.
Womit das LCD initialisert wird, findet man in den Quellen
des MMBASIC.
Kann es sein, dass die gelben LEDs auf deinem Board ohne Vorwiderstände
parallel zum Display an den I/O Pins hängen?
Ich gehöre nicht zu den "Leds an Konstantspannung"-Fans.
Die Leds (ca. 2V) liegen mit der Kathode an gnd und Anode geht über 1k an die GPIOs (die blauen Leds hängen an VBUS, VSYS und 3,3V).
Die ca. 1,3mA Querstrom sollten eigendlich nicht stören.
Da kann Dein fehlerhaftes Gebastel nicht mithalten, auch preislich nicht.
Hier sind übrigens alle Test LEDS an den Ausgängen über Mosfets von den Pico I/O Pins entkoppelt.
Warum wohl?
Merkmale:
1
Funktioniert out-of-the-box. Kein Löten!
2
Zugriff auf alle Pins des Raspberry Pi Pico über zwei 20-polige Stiftleisten
Sieht intressant aus, aber um da meine Picos reinzustecken,
brauche ich einen Adapter, den ich mir wieder "fehlerhaft zusammenbasteln" muß:
Für alle Module, die ich "IC-like" verwende (stecken in IC-Fassungen), benutze ich gedrehte Pinleisten. Die sind für die Pfostenstecker zu dünn.
Es ist mir bereits gelungen, etwas auf dem Display anzuzeigen.
Oftmals gibt es auch eine Fehlermeldung: "Display nicht konfiguriert" osä.
Wie kann ich rausfinden, welche Befehle für dieses Display geeignet sind, ohne alle durchzuprobieren?
In dem Link von Dir steht doch drin, dass es sich um ein Display mit
SSD1306 Controller handelt.
Ich habe auch geschrieben, daß ich bereits etwas auf dem Display angezeigt habe.
"Pixel" und "RBox" ergeben die Meldung "Error: Display not configured".
Bedeutet das nun, daß ich für das Display noch irgendwas einstellen muß, oder daß diese Funktionen vom Display nicht unterstützt werden?
Bei "Text" verstehe ich "Alignment" so, daß ich mit den ersten 2 Buchstaben den Text links/mittig/rechts und oben/mittig/unten ausrichte. Aber scheinbar bewirken diese nichts...
In dem Link von Dir steht doch drin, dass es sich um ein Display mit
SSD1306 Controller handelt.
Ich habe auch geschrieben, daß ich bereits etwas auf dem Display
angezeigt habe.
Sorry - habe ich „selektiv wahrgenommen“.
"Pixel" und "RBox" ergeben die Meldung "Error: Display not configured".
Bedeutet das nun, daß ich für das Display noch irgendwas einstellen muß,
Also die Displays mit SSD1306 gibt es mit verschiedenen Schnittstellen, von verschiedenen Herstellern, mit verschiedenen Auflösungen. Besonders letzteres müsste als Minimum angegeben werden. Zumindest ist das bei den von mir verwendeten Implementierungen Python, C, Pascal, … so.
Mit "Setpin gp7,intl,intsub,pullup" habe ich einen Pin als Interrupteingang definiert.
Obwohl ich den Pin extern auf low gezogen habe, und mit "print pin(gp7)" das auch angezeigt wurde, wurde die Interruptroutine nicht angesprungen.
Erst als ich vor der Pindefinition noch ein "Setpin gp7,din,pullup" davorgesetzt habe, wurde dann die Interruptroutine angesprungen.
Ist da in den Tiefen von PicoMite etwas verstellt?
gp0-15 werden nicht vom System benutzt.
Obwohl ich den Pin extern auf low gezogen habe, und mit "print pin(gp7)"
das auch angezeigt wurde, wurde die Interruptroutine nicht angesprungen.
Afaik triggered INTL auf eine fallende /Flanke/, d.h. er möchte einen high-low-Wechsel sehen. Wenn der Pin dauerhaft low ist, gibt es keinen Interrupt.
Afaik triggered INTL auf eine fallende Flanke, d.h. er möchte einen
high-low-Wechsel sehen. Wenn der Pin dauerhaft low ist, gibt es keinen
Interrupt.
Den Pin habe ich nicht dauerhaft auf low gelegt, sondern geschaltet.
Die Pinabfrage hat auch den jeweiligen Zustand des Pins korrekt angegeben, nur ein Interrupt wurde nicht ausgelöst.
Dieser Effekt hat sich inzwischen gegeben, aber eine Erklärung dafür habe ich nicht.
Ebenso, daß der Pico immer noch von Zeit zu Zeit seinen Inhalt vergißt...
Warum nicht? Ist der gleiche Prozessor, nur mit weniger verfügbaren Pins
und in dem Fall 2MB Flash…
Der Pico hat doch auch 2MB Flash?
Wenn man die Pins, die beim Pico intern benutzt werden dazuzählt, hat der RP2040zero sogar mehr Pins zur Verfügung.
Was mir negativ aufgefallen ist:
Die Led hängt an GP16 statt GP25
und VSYS geht direkt an +5V, ohne Trenndiode. Wenn man den RP2040zero extern mit 5V versorgt, besteht die Gefahr, daß man Strom in den USB-Port des PCs pumpt.
Ansonsten ist das Teil schön klein (1 Raster schmaler und halb so lang wie der Piko).
Wieder mal eine dumme Frage:
Gibt es bei PicoMite eine einfache Möglichkeit eine Zahl in Highbyte und Lowbyte zu zerlegen?
Also z.B. 258 wären 1 (HB) und 2 (LB) ...
Hier scheints nicht viele zu geben, die sich mit Basic auskennen?
Aus der PicoMite-Anleitung:
VAL( string$ )
Returns the numerical value of the ‘string$’. If 'string$' is an invalid
number the function will return zero.
This function will recognise the &H prefix for a hexadecimal number, &O
for octal and &B for binary.
VAL("1100") gibt die Zahl 1100 zurück.
Also muß ich VAL() sagen, daß der String eine Binärzahl enthält.
Aber wie setze ich das "&B" ein? Normalerweise kann ich das doch nur einer Zahlen-Konstante voranstellen?
Oder verstehe ich die obige Beschreibung völlig falsch?
Ist:
Pico W mit WebMite.
WLan aktiviert, aber keine Verbindung.
Option Autorun On
Bei Anschluß über USB läuft das Basicprogramm problemlos (steuert über SPI ein LCD an).
Bei Batteriebetrieb (3V, 1750mAh über Shottky-Diode auf VSYS) bleibt das Basicprogramm stehen (oder läuft gar nicht richtig los, auf dem LCD steht irgendwelches Zeugs, was noch vom vorherigen Einschalten stammen kann). Heartbeat läuft aber weiter.
Das Seltsame ist aber:
Starte ich den Pico über USB-Versorgung und ziehe dann den USB-Stecker raus, läuft das Basic-Programm einwandfrei weiter.
Woran kann das liegen, wie komme ich diesem Phänomen auf die Spur?
Warum nicht eine deutschspachige Zweigstelle aufmachen?
Weil Softwareentwickler und Elektroniker englisch können müssen. Die
Zeiten, wo man sich ohne englisch durch wurschteln konnte, sind lange
vorbei.
Ich bin weder Softwareentwickler noch (professioneller) Elektroniker, sondern Hobby-FuBa.
Da habe ich eben keine Lust >50% des Hobbys mit Englisch zu verschwenden, was definitiv nicht zu meinen Intressen zählt.
Das Englisch der Datenblätter ist genug!
Vermutlich laeuft der Picomite schon und das LCD ist mit seiner
"internen" Initialisierung noch nicht fertig.
Im Datenblatt des LCDs wird es sicher dazu eine Zeitangabe
geben, die sagt, wann nach einem POR man mit ihm reden kann.
Bau einfach eine Warteschleife an den Anfang deines Programss.
Die Displayinitialisierung muß ja durchlaufen weden, sonst würde das Display nichts anzeigen.
Ich habe jetzt eine Led an einem Portpin angeschlossen, die in der Programmschleife ein- und ausgeschaltet wird.
Die Led blinkt nicht, also steht das Programm.
Was denn nun? Ich fuerchte mal, dass du da selber suchen musst.
Klemm ein Oszi an die wesentlichen Stellen der Hardware und
vergleiche die Unterschiede.
Meinen "Duinomites" ist es egal ob sie ihre Spannung
aus einem Netzteil
einem Akku oder
vom USB
bekommen.
Wenn das bei den Picomites nicht ordentlich funktioniert,
solltest du die Entwickler fragen.
Die Displayinitialisierung muß ja durchlaufen weden, sonst würde das
Display nichts anzeigen.
Hast du an den Programmanfang eine Warteschleife gesetzt?
Also vor den ganzen Anweisungen die das Display einstellen?
Oder nicht?
The Raspberry Pi Pico W has a flexible power system.
The input voltage from either the USB or VBUS
inputs is connected through a Schottky diode to the
buck-boost SMPS (Switch Mode Power Supply)
which has an output of 3.3V. The SMPS will
accommodate input voltages from 1.8V to 5.5V
allowing the WebMite to run from a wide range of
power sources including batteries.
External circuitry can be powered by VBUS (normally 5V) or by the 3V3 (3.3V) output which can source up to 300mA.
For embedded controller applications generally an external power source (other than USB) is required and this
can be connected to VSYS via a Schottky diode. This will allow the WebMite to be powered by whichever supply is producing the highest voltage (USB or VSYS). The diodes will prevent feedback into the lower voltage supply.
To minimize power supply noise it is possible to ground 3V3EN to turn off the SMPS. When shutdown the converter will stop switching, internal control circuitry will be turned off and the load disconnected. You can
then power the board via a 3.3V linear regulator feeding into the 3V3 pin.
Die gewünschten GPIOs müssen erstmal mit dem Befehl "Option count" zugewiesen werden, bevor man die Pin-Konfigs "FIN", "PIN" und "CIN" nutzen kann (ist im Manual unter "Setpin" nicht erwähnt).
"Option count" führte dann zu "Pin in use", obwohl die GPIOs nur auf "din, pullup" gesetzt waren und ich irgendwann vorher mal die Interrrupt-Konfig benutzt habe.
Da ich schonmal seltsames Verhalten beim Umkonfigurieren von GPIOs hatte:
Werden eventuell die alten Konfigs beim Neukonfigurieren nicht (vollständig) überschrieben?
Wäre ein generelles "Setpin gpx, off" vor einer GPIO-Konfiguration sinnvoll?
