Pi Pico startet nicht selbstständig (Autostart)

  • Hallo,

    ich bin neu hier und habe gleich eine Frage.

    Bin dabei eine Luftfeuchtemessung /-steuerung zu entwickeln. Bei Verbindung mit Thonny funktioniert es, wenn den Pico ohne Rechner starten will, startet der Pico nicht. Erst nach dem ich dann wieder mit Thonny gestartet habe, läuft es wieder. Quellcode ist als main.py gespeichert.

    Danke schon mal !

    Hier der Code:

  • Guten Tag highhatcompy,

    und herzlich willkommen.

    Wenn du in Thonny bist, die Ansicht Datei über das Menü "Ansicht" aufrufen.
    Dort die Datei boot.py öffnen und in der letzten Zeile den Eintrag machen
    import <Programmname.py>

    Falls die Datei noch nicht auf dem Flash Device vorhanden sein sollte, einfach eine neue Datei erstellen und den Inhalt eintragen und auf dem PICO abspeichern. Die Endung .py nicht vergessen. Falls dies Autostartfunktion nicht mehr benötigt wird, mit einer # diesen Eintrag auskomentieren.

    Einfach abspeichern und das Programm wird automatisch gestartet. Falls du wieder eine Verbindung mit Thonny herstellen willst, aber offensichtlich nichts passiert nur die Tastenkombi STRG + C drücken, dann connectet er wieder, und du kannst an deinem Programm weiter herumfeilen ;)

    es grüßt euer
    Willy

    Einmal editiert, zuletzt von WillyR_aus_C (15. August 2022 um 10:34)

  • WillyR_aus_C

    Dein Tipp mit der boot.py ist unnötig und es wird oft auch davon abgeraten, dort irgendwas zu ändern, zumal es bei einem Update auch weg sein könnte.

    Die Datei als main.py zu benennen reicht völlig aus und sollte funktionieren.

    Wenn das nicht funktionieren sollte, liegt ein anderer Fehler vor.

    highhatcompy
    Ich habe mal versucht das Skript auf meinem Pico W zum Laufen zu bekommen.

    Da startet es nicht mal in Thonny.

    Fehlermeldung:

    TypeError: unsupported types for __gt__: 'bound_method', 'int'

    Angemeckert wird Zeile 13.

    ;) Gruß Outi :D
    Pis: 2x Pi B (Rente) / 1x Pi B+ (Rente) / 1x Pi 2 B (Rente) / 2x Pi 3 B (RaspberryMatic / Repetier Server) / 2x Pi Zero 1.2 (B. Lite) / 2x Pi Zero 1.3 (B. Lite) / 2x Pi Zero W 1.1 (B. Lite) / 1x Pi Zero 2 (mal so, mal so) / 1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (BW Lite (Webserver)) / Pi 400 (BW) / 1x Pi 5 (BW) / 2x Pi Pico / 2x Pi Pico W
    Platinen: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT
    Kameras: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

    4 Mal editiert, zuletzt von Outlaw (16. August 2022 um 18:08)

  • Guten Abend Outlaw,

    dem würde ich so widersprechen wollen.
    Unabhängig des Codes der aus anderen Gründen wahrscheinlich nicht läuft, was jedoch der TO immer noch nicht so bestätigt hat, gibt es auch klare Aussagen bezüglich der Verwendung von boot.py und main.py .

    Nutzt man zB eine IDE auch mit einer Debugging Erweiterung hat man ein gewaltiges Problem wieder mit der IDE auf das Pico zuzugreifen, wenn über main.py ein Autostart ausgeführt wird.
    Wenn das Programm fertig ist und steht, sowie keine weiteren Änderungen anstehen, steht der Methode mit main.py nichts im Weg.

    Dann versuchen sie mal ein PICO via USB und GPIO via OpenOCD an eine Raspi mit Thonny anzuschließen, und darüber Dateizugriff auf den Flash zu erhalten. Selbst die Tastenkombination STRG + C bringt sie hier nicht weiter. Jedoch mit dem Umweg über boot.py und der Startzeile import <Programmnam.py> können sie nach dem Betätigen von bootsel wieder mit dieser Tasten-Kombi und auch über anderen IDEs auf das PICO zugreifen.

    Ebenso, wenn man über diese Thonny IDE ein Versions-Update von µPython durchführt, ist danach der gesamte Flash leergeräumt. Danach findet man kein einiges Programm mehr darauf, was zuvor evt. schon gelaufen war oder ist. Den Fehler habe ich auch schon einmal gemacht. Damit war dann meine beschwerliche Arbeit von fast einer Woche weg. Seit dem sichere ich vor und jedem IDE Zugriff die aktuelle Datenbestände des Flashs extern.

    Ist ja nicht nur Zeile 13 ;) Alle Zeilen die d. enthalten sind fehlerhaft ;)

    es grüßt euer
    Willy

  • Guten Abend Outlaw,

    dem würde ich so widersprechen wollen.
    Unabhängig des Codes der aus anderen Gründen wahrscheinlich nicht läuft, was jedoch der TO immer noch nicht so bestätigt hat, gibt es auch klare Aussagen bezüglich der Verwendung von boot.py und main.py .

    ....

    Du kannst dem ruhig widersprechen aber die Foundation empfiehlt selbst für Autostart Skripte diese main.py zu benennen und alle anderen Dateien in Ruhe zu lassen.
    Zudem gibt es in deren Forum einen langen Thread dazu mit dem selben Fazit.

    Wie dem auch sei, die boot.py Datei wird als erstes abgefragt, danach main.py und boot.py kann man zwar verändern, sollte aber, wenn möglich, immer zuerst die Autostartdatei main.py benennen.
    So habe ich es auch vor Längerem in der Doku gelesen und seit dem nie Probleme damit gehabt.

    ;) Gruß Outi :D
    Pis: 2x Pi B (Rente) / 1x Pi B+ (Rente) / 1x Pi 2 B (Rente) / 2x Pi 3 B (RaspberryMatic / Repetier Server) / 2x Pi Zero 1.2 (B. Lite) / 2x Pi Zero 1.3 (B. Lite) / 2x Pi Zero W 1.1 (B. Lite) / 1x Pi Zero 2 (mal so, mal so) / 1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (BW Lite (Webserver)) / Pi 400 (BW) / 1x Pi 5 (BW) / 2x Pi Pico / 2x Pi Pico W
    Platinen: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT
    Kameras: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • Hallo,

    ich bin wieder mal hier und habe gleich eine Frage zu

    Adafruit CircuitPython 7.3.3 on 2022-08-29; Pimoroni Tiny 2040 (8MB) with rp2040

    Bin dabei eine xy Positionierung zu entwickeln. Bei Verbindung mit Thonny funktioniert es, wenn den Pico ohne Rechner starten will, startet der Pico nicht. Erst nach dem ich dann wieder mit Thonny gestartet habe, läuft es wieder. Quellcode ist als main.py und code.py gespeichert.

    Danke schon mal !

    Hier mein Code:

    import usb_hid

    import time

    from adafruit_hid.mouse import Mouse

    import board

    import digitalio

    mouse = Mouse(usb_hid.devices)

    MX = 0

    MY = 0

    zahl = 127

    def Mauspos( x, y):#funktion OK

    mouse.move(-2560, -1440)

    time.sleep(0.1)

    MX = x

    MY = y

    print(MX)

    print(MY)

    while MY >= zahl:

    mouse.move(y= zahl)

    time.sleep(0.01)

    MY -= zahl

    else:

    if (MY <= zahl) and ( MY >0):

    mouse.move(y= MY)

    time.sleep(0.1)

    MY -= MY

    if (MY == 0) :

    while MX >= zahl:

    mouse.move(x= zahl)

    time.sleep(0.01)

    MX -= zahl

    else:

    if (MX <= zahl) and ( MX >0):

    mouse.move(x= MX)

    time.sleep(0.1)

    MX -= MX

    bt5 = digitalio.DigitalInOut(board.GP2)

    bt5.switch_to_input(pull= digitalio.Pull.DOWN)

    time.sleep(1)

    while True:

    while(bt5.value == True):

    print("bt-vor")

    time.sleep(2)

    Mauspos( x= 1100, y= 1500 )

    time.sleep(2)

    Mauspos( x= 1100, y= 1500 )

    time.sleep(10)

    time.sleep(1)

    Bei Eingabe STR-D kommt das:

    (weicher reboot

    Automatisches Neuladen ist aktiv. Speichere Dateien über USB um sie auszuführen oder verbinde dich mit der REPL zum Deaktivieren.

    code.py Ausgabe:

    Hello World!

    Programm wird ausgeführt.

    Drücke eine beliebige Taste um REPL zu betreten. Drücke STRG-D zum neuladen.)

  • Moinsen,

    Ich weiss zwar nicht weil es sich offensichtlich um Micropython handelt, sondern CircuitPython handelt, wie das dort geregelt ist.
    Auch ist deine Codeansicht eher suboptimal.

    Aber wenn du diese boot.py verwendest, falls das von CircuitPython unterstützt wird, dann steht in der letzten Zeile dieser import <Programmdateiname>.py

    Falls hier noch irgendwelche Bindungen zu beachten sind, kannst du dort auch ein:

    Python
    #boot.py
    from utime import sleep
    sleep(5) # für 5 Sekunden 
    import mouse.py 

    einfügen, damit erst nach 5 Sekunden dein CircuitPython importiert und ausgeführt wird.

    Ebenso dürfen keine Print Anweisungen enthalten sein, weil diese eine Serielle- oder USB- Verbindung voraussetzt. [</>] ist in dem Thread-Menü zu finden.


    Und dann würde ich nur die Bibliothek importieren, die du auch wirklich benötigst.

    Siehe import time wird dann zu from time import sleep so kann man sehr viel des ohnehin knappen RAM sparen.

    Benutzte bitte die Codeansicht für deine zukünftigen Posts !

    Franky

  • Eine Funktion aus einem Modul importieren statt das Modul zu importieren spart RAM? Dann würde sich MicroPython & Co aber deutlich anders als CPython (und wohl auch alle anderen Implementierungen) verhalten. Auch wenn man nur einzelne Namen im importierenden Modul bindet, wird ja trotzdem das gesamte importierte Modul geladen und ausgeführt.

    “Dawn, n.: The time when men of reason go to bed.” — Ambrose Bierce, “The Devil's Dictionary”

  • Moinsen,

    Darf dich __blackjack__ mal auf folgenden Umstand hinweisen ?

    Die Zeile import time belegt 11 Zeichen. Hingegen die längere Version from time import sleep immerhin 22. Ein einzelner Aufruf des sleep Befehls time.sleep(2) immerhin schon einmal 13 Zeichen. Das gleiche in der Verkürzten Version sleep(2) nur 8 Zeichen. Das heißt jeder Aufruf in der Kurzversion spart 5 Zeichen.
    Damit rein mathematisch schon die dritte Zeile in der ein sleep so in der Kurzform vorkommt spart damit RAM, auch wenn es hier erst einmal nur 4 ( vier ) Zeichen wäre. Und gerade bei den µC wie ESP oder RasPi Pico kann man somit einiges an Byts einsparen weil der resultierende Programmcode im ohnehin knappen RAM kürzer wird.

    Reduziert man das Programm auf die betreffenden Zeilen sieht das so aus:

    Und nun darfst du die große Rechnung aufmachen :angel: 50 Zeichen zusätzlich - hingegen nur 11 Zeichen mehr in der Import-Zeile.

    Gut bei diesem Programm hat das noch keine wirkliche Auswirkung, aber auch Kleinvieh macht Mist ;)

    Franky

  • Franky07 Das belegt jetzt nicht die Aussage, Zitat: „sehr viel des ohnehin knappen RAM sparen“; Hervorhebung von mir. So knapp ist das RAM ausserdem auch wieder nicht. Das Beispiel spart beim Pico etwas mehr als 0,1‰ des Arbeitsspeichers. Bei weitem nicht mal ein Promille. Zeig mal einen realen Fall bei dem das *wirklich* Auswirkungen hat.

    Zumal wir hier vom Quelltext reden. Der belegt nur kurz RAM und das nicht mal in der Textform wie er geschrieben wurde und nicht auf einmal komplett am Stück, denn der wird zu Bytecode kompiliert, wo Namen normalerweise als Index in ein Array mit den Namen als Zeichenkette übersetzt werden und damit dann nur noch einmal tatsächlich die Länge der Zeichenkette im RAM belegt wird, auch wenn die dann über den Index an mehreren Stellen im Bytecode referenziert wird. Die Rechnung, dass da jedes mal 5 Bytes benutzt werden, weil das im Quelltext 5 Zeichen mehr hatte, geht so nicht. Es sind am Ende nur 14 statt 50 Bytes (599 vs. 585 Bytes kompiliert für das gesamte Modul). Es sind pro Aufruf 2 Byte weniger bei 8 bis 9 Bytes vs. 6 bis 7 Bytes pro Aufruf.

    Wenn man Arbeitsspeicher sparen will, kompiliert man die Module in Bytecode bevor man sie auf das Zielsystem überträgt. Wenn man die in den Micropython-Interpreter integriert, kann man den Bytecode sogar im ROM speichern und die Namen selbst belegen gar kein RAM, weil die dann auch im ROM abgelegt sind.

    Falls solche Mikrooptimierungen tatsächlich den Unterschied machen ob das läuft oder nicht, hat man aber das grundsätzlichere Problem, dass Python sehr dynamisch mit dem Speicher umgeht und man immer deutlich Luft im Arbeitsspeicher haben will, wegen der Speicherverwaltung. Zum einen weil Speicher der nicht mehr verwendet wird, nicht sofort freigegeben wird — Micropython verwendet nicht wie CPython Referenzzähler wo der Speicher oft sehr zeitnah freigegeben wird. Und zum anderen könnte Speicherfragmentierung ein Problem werden.

    Wenn diese Luft nicht da ist, sollte man eine andere Programmiersprache verwenden, oder mehr RAM.

    “Dawn, n.: The time when men of reason go to bed.” — Ambrose Bierce, “The Devil's Dictionary”

  • Moinsen,

    Das hast du ganz fein gemacht, das alles bis aufs letzte Bit auszurechnen. Ich hatte aber auch geschrieben, dass dieser Umstand in diesem Beispiel nicht viel bis gar nichts ausmacht.

    Gut bei diesem Programm hat das noch keine wirkliche Auswirkung, aber auch Kleinvieh macht Mist

    Danke aber trotzdem für deine Mühe :bravo2:

    Nur wird diese Bit-Fuchserei dem TO nicht weiterhelfen, warum sein Programm nur mit einer USB-Seriell-Verbindung sich aus der IDE heraus starten lässt, und nicht im Autostart-Modus, wozu es hier auch schon Abhandlungen gibt #5, die aber auch nicht zur Problemlösung beigetragen haben.

    Aber ja ich hatte schon den Fall, wo mir diese Bit Fuchserei den aller Wertesten gerettet hat, denn auf dem PICO Board einen zusätzlichen NVRAM nachzurüsten - dafür fehlen mir die technischen Mittel ;)

    Franky

  • Was hat das alles mit dem Autostart des TE zu tun ?!?!

    ;) Gruß Outi :D
    Pis: 2x Pi B (Rente) / 1x Pi B+ (Rente) / 1x Pi 2 B (Rente) / 2x Pi 3 B (RaspberryMatic / Repetier Server) / 2x Pi Zero 1.2 (B. Lite) / 2x Pi Zero 1.3 (B. Lite) / 2x Pi Zero W 1.1 (B. Lite) / 1x Pi Zero 2 (mal so, mal so) / 1x Pi 3 B+ (Tests) / 1x Pi 4 B 4GB (BW Lite (Webserver)) / Pi 400 (BW) / 1x Pi 5 (BW) / 2x Pi Pico / 2x Pi Pico W
    Platinen: Sense HAT / HM-MOD-RPI-PCB / RPI-RF-MOD / PiFi DAC+ V2.0 / TV HAT / Pi 5 Kühler HAT
    Kameras: orig. Raspberry Pi Camera Module V1 & V3 / PS3 Eye

  • Ich habe mich mit dem Problem nun auch fast 2 Tage rumgeärgert und 3 Ursachen gefunden (ohne irgendwelche Bugs in Thonny oder der Firmware etc. zu beachten):

    1. Wenn fertiger Code von irgendwo her in deinen Editor kopiert wurde kann es sein, dass (bei mir Thonny) nicht mit den scheinbaren Leerzeichen einer Zeile klarkommt. Die eingerückten Zeilen enthalten vermutlich ein Steuerzeichen für einen TAB, das den Editor durcheinanderbringt. Das hatte bei mir zur Folge, dass das Programm nicht startete oder Thonny Fehler in der Zeile anmerkte, die keine Sinn ergaben. -> Lösung: alle Leerzeichen vor und nach der Zeile löschen und neu im Editor eingeben.
    2. Das Laden von Bibliotheken oder das Initialisieren von Pins kann u.U. 1-2 Sekunden dauern und in den folgenden Codezeilen steht die benötigte Varbiale dann noch nicht richtig bereit. -> Lösung: utime imprtieren und utime.sleep(2) direkt nach der "langsamen" Zeile einfügen. So bekommt der Pi Zeit für die Verarbeitung. (das habe ich auch in einem englischsprachigem Forum gefunden aber bei mir waren dann noch Problem 1 und 3 vorhanden)
    3. Die Spannungs-/Stromquelle, über die der Pi extern und somit eigenständig laufen soll, muss auch das Ausliefern von sehr geringem Strom unterstützen, ansonsten "denkt" das Netzteil, dass es nur Kriechstrom ist und schaltet sich ab bzw. startet nicht mit der Versorgung der notwendigen Energie. Wobei es hier vermutlich auch sein kann, dass der "Kriechstrom" zwar ausreicht, den Pi zu starten aber nicht, damit der Pi das Wlan-Modul starten und eine Verbindung aufbauen kann (oder irgendein anderes Modul steuern oder rechenintensive Aufgabe erfüllen kann). Bei mir war es so... über das Verhalten der Onboard-Led konnte ich ablesen, dass der Pi zwar an war aber in der Schleife des Verbindungsaufbaus hängen blieb. -> Lösung: mehrere Netzteile durchprobieren (was echt nervig sein kann...)

    Ich hoffe das hilft! :)

  • Moinsen,

    jetzt mal die direkte Frage wie wird das PICO versorgt ?

    Um das Pico W ( mit WLAN Modul ) überhaupt soweit zu bringen dass es sicher startet, und das auch die WLAN Funktion zur Verfügung steht, musst du über VBUS ( Pin 40 ) mind. 350 mA bereitstellen, wenn du auch noch Lasten über die GPIOs hat.
    Also mal einen L4940 nehmen, mit einem schönen fetten Eingangskondensator 4,7mF aufwärts, und die Ausgangsseite des Spannungsreglers auf den VBUS Pin bringen. Dabei darf dann die Eingangspannung vor dem L4940 ruhig etwas mehr sein ;) Es muss auch keine wirklich saubere Gleichspannung sein, aber das dürfte das Stromversorgungsproblem lösen, falls es noch besteht. Es gibt auch andere Alternativen, aber um hier zu einem schnellen Ergebnis ohne große Lötarbeiten zu kommen.

    Franky

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!