Hallo, ich habe ein Problem mit dem Installieren der Raspberry Pi OS Images. Auf der offiziellen Seite sind ab dem 7.4.2022 nur noch Imgaes mit ca. 870MB vorhanden, die davor sind alle ca. 4GB groß. Versuche ich mit dem 870MB Image den Pi1 B+ zu booten, passiert gar nichts. Mit dem alten Image habe ich keine Probleme. Laut Seite sollten die aktuellen Images mit allen Versionen funktionieren. Weiß einer, was hier die Ursache sein könnte? Alex
:
Bearbeitet durch User
hier die Verzeichnisse für die Full-Versionen https://downloads.raspberrypi.org/raspbian_full/ https://downloads.raspberrypi.org/raspios_full_arm64/ https://downloads.raspberrypi.org/raspios_full_armhf/
Alex Z. schrieb: > Laut Seite Ach, diese eine Seite in diesem Internetz. Alex Z. schrieb: > der Raspberry Pi OS Images Details sind nicht so dein Ding? Alex Z. schrieb: > 870MB vorhanden, die davor sind alle ca. 4GB groß. Ich glaube der kleine Alex muss die Aeuglein etwas besser aufmachen..
Zumindest bei Ubuntu haben sie den uralten RPi 1 bereits rausgeworfen: https://ubuntu.com/download/raspberry-pi Debian bietet aber noch ein Image, das würde ich dir daher empfehlen: https://raspi.debian.net/tested-images/ Generell hat es aber seinen Grund wieso der RPi 1 vielerorts im Schrott landet...
Peter Pan schrieb: > Zumindest bei Ubuntu haben sie den uralten RPi 1 bereits rausgeworfen: Raspios bullseye 32-bit ist noch immer fuer alle freigegeben. Ob das Sinn macht kann ich nicht beurteilen. Bernd schrieb: > Dummheit wäre naheliegend. Sei nicht so hart. Ich tippe auf etwas Oberflaechlichkeit.
Thomas O. schrieb: > hier die Verzeichnisse für die Full-Versionen > > https://downloads.raspberrypi.org/raspbian_full/ > https://downloads.raspberrypi.org/raspios_full_arm64/ > https://downloads.raspberrypi.org/raspios_full_armhf/ Hallo Thomas, danke für die Links. Diese sind ja auf der Raspberry Pi OS Seite angegeben. Unter: https://downloads.raspberrypi.org/raspios_full_armhf/images/ habe ich bereits gesucht. Dort ist die aktuellste vom 22.9.2022, diese funktioniert leider nicht mit meinem Pi 1B+ Ich musste die Version vom 28.1.2022 nehmen, die ist auch ca. 0.6GB größer als die aktuelle. In den release Notes habe ich keinen Hinweis gefunden, dass der Pi nicht mehr unterstützt werden würde. Dann bleibt es wohl erstmal bei der Version die jetzt drauf läuft. Alex
Alex Z. schrieb: > Dann bleibt > es wohl erstmal bei der Version die jetzt drauf läuft. Wieso wechselst du nicht einfach auf Debian? Dort bekommst du eine gepflegte Distribution...
Alex Z. schrieb: > nur noch Imgaes mit ca. > 870MB vorhanden, die davor sind alle ca. 4GB groß. Du hast den Download schon dekomprimiert, bevor du ihn auf die SD-Karte geschrieben hast?
Raspberry Pi Modell 1A, erste Serie, noch mit 256MB RAM. Image armhf-lite vom 22.9., 1,8 GB nach entpacken. Funktioniert an Full-HD Monitor. An einem 27er WQHD Monitor ist zwar jedes getestete Image gestartet, von 2020 bis jetzt, lieferte aber nie ein Bild.
:
Bearbeitet durch User
Beitrag #7219842 wurde von einem Moderator gelöscht.
Peter Pan schrieb im Beitrag #7219842:
> Passenden HDMI Mode usw. in der config.txt eingestellt?
Das war ein q&d-Test gerade eben. Nur ob "geht" oder "geht nicht".
Weiter habe ich es nicht verfolgt.
:
Bearbeitet durch User
Alex Z. schrieb: > Versuche ich mit dem > 870MB Image den Pi1 B+ zu booten, passiert gar nichts. >... > Weiß einer, was hier die Ursache sein > könnte? Wie und womit hast du denn die SD Karte partitioniert und formatiert? Ich hatte früher, als ich das erste mal meinen Pi 3 ausprobieren wollte, das Problem, dass er von SD Karten, die ich mit gparted auf einem PC partitioniert und formatiert habe, nach der Installation des Images nicht booten wollte. Wenn ich mit so einer SD dann das booten auf dem Pi 3 versucht habe, hatte er ein ähnliches Fehlerbild, wie es du beschreibst. Abhilfe war, die Partitionen auf dem PC mit fdisk zu erstellen und dann mit
1 | sudo mkfs.vfat -n BEZEICHNER -c -v -F 32 /dev/DEVICENAME |
zu formatieren. BEZEICHNER und DEVICENAME musst du entsprechend ersetzen. Falls kein sudo eingerichtet ist, brauchst du root Rechte. Danach kannst du das Pi OS installieren. So hat es bei mir damals geklappt. Das ist jetzt aber schon etwas länger her. Heute gibt es natürlich neuere Konfiguriationsprogramme für den Raspi, mit denen du die SD vorbereiten kannst.
Nano schrieb: > Wie und womit hast du denn die SD Karte partitioniert und formatiert? Wozu? Image draufbügeln, beispielsweise mit dem "Raspberry Pi Imager", und fertig. Den Rest erledigt dieses Image beim ersten Start selber. Der Imager bietet obendrein ein paar nützliche Voreinstellungen des installierten Systems an. Versuche, die Partitionierung selbst durchzuführen, sind demgegenüber viel komplexer und fehlerträchtiger.
:
Bearbeitet durch User
Beitrag #7219989 wurde von einem Moderator gelöscht.
(prx) A. K. schrieb: > Nano schrieb: >> Wie und womit hast du denn die SD Karte partitioniert und formatiert? > > Wozu? Weil es damals bei mir notwendig war und nicht anders ging. Und ich weiß ja nicht, wie er es jetzt macht. Es wäre aber eine Erklärung für den Fehler und deswegen habe ich das erwähnt.
Peter Pan schrieb im Beitrag #7219989: > Wozu zur Hölle partitioniert man eine SD Karte für den Raspberry Pi > selbst? Es war damals in meinem Fall notwendig. Was der genaue Grund war, kann ich dir nicht mehr sagen, da ich es vergessen habe. Auf jeden Fall war es in meinem Fall erforderlich um den Raspi nutzen zu können.
Nano schrieb: > (prx) A. K. schrieb: >> Nano schrieb: >>> Wie und womit hast du denn die SD Karte partitioniert und formatiert? >> >> Wozu? > > Weil es damals bei mir notwendig war und nicht anders ging. Hm. Hatte ich nie Probleme mit. Es gibt spezielle IMAGE-Schreibe-Software für so Images. Die Formatiert die Karte + Partitioniert sie. Dann schreibt sie das Image auf die Karte und gut ist. z.B. RUFUS. https://www.raspberry-pi-geek.de/ausgaben/rpg/2017/08/images-auf-sd-karte-schreiben-unter-linux-mac-und-windows/ Zitat von Bild 5 : "Abbildung 5: Das Windows-Tool Rufus schreibt ebenfalls Raspberry-Pi-Images auf die Speicherkarte und akzeptiert dabei auch gepackte Abbilder." Das ist für Anfänger extra gemacht.
Nachtrag: Einige Images bringen auch eine EXE-Datei für Windows zum Schreiben des Image mit. Hab z.b. die : LibreELEC.USB-SD.Creator.Win32.exe Der gibt man das Image und wartet bis fertig. Dann FERTIG. ;)
Schlaumaier schrieb: > Es gibt spezielle IMAGE-Schreibe-Software für so Images. Die Formatiert > die Karte + Partitioniert sie. Dann schreibt sie das Image auf die Karte > und gut ist. Passt hier nicht. Man schreibt das Image direkt aufs Medium, ab Sektor 0 ohne Rücksicht auf bestehende Partitionen. Die sind auf dem Image schon mit drauf.
:
Bearbeitet durch User
Schlaumaier schrieb: > Es gibt spezielle IMAGE-Schreibe-Software für so Images. Die Formatiert > die Karte Nö, beim Schreiben eine Images wird eigentlich nichts formatiert - wozu auch. In dem Image ist "Formatierung" enthalten, da es sich um ein Abbild eines bestehenden Datenträgers handelt. Das wird einfach "Bit für Bit" auf das Medium geschrieben. Der Zieldatenträger hat dann aus Sicht des OS die gleiche Struktur wie die Quelle für das Image, selbst dann wenn er physikalisch größer ist.
Zeno schrieb: > Nö, beim Schreiben eine Images wird eigentlich nichts formatiert - wozu > auch. In dem Image ist "Formatierung" enthalten, da es sich um ein > Abbild eines bestehenden Datenträgers handelt. Diese Aussage ist MANCHMAL richtig. In den Anfangszeiten der Beere war das sogar 100 % richtig. Aber da 32 GB Karten unterster Standard sind... (Kleiner ist schwer zu bekommen). Das Zauberwort ist : GEPACKTES Image. In den Fall wird der Aufbau der "Festplatte" aus den Image entnommen. Dann wird entweder im Programm gefragt oder was häufiger der Fall ist, die letzte Partition des Image "aufgeblasen" auf die Größe der "Festplatte". Den Job des "aufblasen" muss das Image-Schreiben-Prg. übernehmen. Grund ist das die meisten User (inkl. mir) nicht in der Lage sind unter Linux die Partitionen zu verändern. So passt wird aus ein 850 MB Image locker ein 4 gb oder auch 16 GB o. Größer SD-Karte gemacht, OHNE das man was an Speicherplatz verschwenden. Unter Windows machen GUTE Backup-Programme das genau so. Sie fragen ab was mit den Rest der neueren meist größeren Festplatte passieren soll. Jedenfalls mein Acronis macht das. ;)
Schlaumaier schrieb: > Es gibt spezielle IMAGE-Schreibe-Software für so Images. Die Formatiert > die Karte + Partitioniert sie. Dann schreibt sie das Image auf die Karte > und gut ist. Das habe ich bereits oben geschrieben: "Heute gibt es natürlich neuere Konfiguriationsprogramme für den Raspi, mit denen du die SD vorbereiten kannst." Das war damals bei mir keine Option. Es ist gut möglich, dass es nicht im Repo war oder die Version im Repo fehlerhaft oder zu alt war, denn ich vermeide aus Sicherheitsgründen Sachen am Repo vorbei zu installieren, wenn es alternative Lösungen, wie bspw. manuelle Lösungen gibt. > Das ist für Anfänger extra gemacht. Die Frage, wie der TS es gemacht hat, hat er immer noch nicht beantwortet.
Nano schrieb: > Das habe ich bereits oben geschrieben: > "Heute gibt es natürlich neuere Konfiguriationsprogramme für den > Raspi, mit denen du die SD vorbereiten kannst." hihi. GENAU . Ich habe mich ja auch nur verteidigt. Gegen ZENO + A.K. .
(prx) A. K. schrieb: > Schlaumaier schrieb: >> Es gibt spezielle IMAGE-Schreibe-Software für so Images. Die Formatiert >> die Karte + Partitioniert sie. Dann schreibt sie das Image auf die Karte >> und gut ist. > > Passt hier nicht. Man schreibt das Image direkt aufs Medium, ab Sektor 0 > ohne Rücksicht auf bestehende Partitionen. Die sind auf dem Image schon > mit drauf. Es kann auch sein, dass die SD größer ist, als das Image, das erstellt wird. Wenn dann kein Tool verwendet wird, dass das anpasst, dann hätte man Platz verschwendet.
Schlaumaier schrieb: > Den Job des "aufblasen" muss das Image-Schreiben-Prg. übernehmen. Nein. Das macht das per "zu kleinem" Image installierte System seit 2016 beim ersten Start selbst. https://gijs-de-jong.nl/posts/raspberry-pi-file-system-resize-on-first-boot/ Bezogen auf die Größe der SD ist es deshalb egal, ob man das Image per Imager auf die SD schiebt, oder per "dd". Der Imager ist von Vorteil, weil er z.B. bereits für aktives SSH sorgen kann, nebst anderen Voreinstellungen.
:
Bearbeitet durch User
Peter Pan schrieb: > Generell hat es aber seinen Grund wieso der RPi 1 vielerorts im Schrott > landet... Dafuer ist er viel zu schade - der kann wenigstens noch als PiGFX-Terminal dienen oder Baremetal-Software laufen lassen, die sonst am Zero(W) laufen, der hat ja auch keine bessere CPU.
Angehängte Dateien:
-
Pi_Imager.png
16 KB
Εrnst B. schrieb: > Alex Z. schrieb: >> nur noch Imgaes mit ca. >> 870MB vorhanden, die davor sind alle ca. 4GB groß. > > Du hast den Download schon dekomprimiert, bevor du ihn auf die SD-Karte > geschrieben hast? Hallo, nein habe ich nicht, die .xz - Datei wurde automatisch mit dem Pi Imager asoziiert. Ich habe zuerst mit dem Pi Imager eine Version online runtergeladen --> ging nicht. Anschließend habe ich das Image von der Raspberry Pi OS Seite geladen und mit dem Pi Imager geschrieben --> ging auch nicht. Dann hab ich es mit dem Win32 DiskImager versucht --> Ebenfalls nada. Anschließend dann das alte Image von Anfang 2022 mit Win32DiskImager --> hat funktioniert. Ich hab jetzt nochmal das aktuelle Image von September geladen und mit 7-Zip entpackt, anschließend mit Win32DiskImager auf eine SD Card und nun geht es. Im Bild ist zu sehen, welche Formate der Pi Imager unterstützt. Hier unter anderem die .xz-Dateien. Wenn es dann vom Programm nicht automatisch entpackt wird, dann brauch ich mich auch nicht wundern, warum es nicht geht...
Angehängte Dateien:
Schlaumaier schrieb: > Diese Aussage ist MANCHMAL richtig. In den Anfangszeiten der Beere war > das sogar 100 % richtig. Aber da 32 GB Karten unterster Standard > sind... (Kleiner ist schwer zu bekommen). Das ist halt wie immer Schlaummaierkäse. Wenn man ein Image auf einen (beliebigen) Datenträger geschrieben wird, dann ist das immer ein 1:1 Abbild des Ursprungsdatenträgers. In einem Image ist auch immer der erste Sektor, allgemein als MBR bekannt, enthalten. Dieser enthält alle relevanten Daten zum Aufteilen des Mediums - die Partitionstabelle, sowie den Startcode. Zudem enthält ein Image eines (kompletten) Datenträgers auch sämtliche Partitionen inclusive der nötigen Verwaltungsdaten und die Daten selbst. Beim Schreiben des Images ist es völlig egal welche Größe der Quelldatenträger hat, solange er kleiner oder gleichgroß wie der Zieldatenträger ist. Das Vergrößern der Partition erfolgt nach dem Schreiben des Images i.d.R. beim ersten Start automatisch oder auch manuell angestoßen via raspi-config. Welches der beiden Verfahren benutzt wird hängt davon ab wie es auf dem Image, also dem OS selbst, hinterlegt ist. Man kann dies aber auch völlig problemlos mit den Tools fdisk und resize2fs selbst erledigen. Dauert nur wenig länger als der Automatismus und hat den Vorteil das man die Partitionierung selbst in der Hand hat. Das funktioniert schon, wie A.K. es richtig geschrieben hat, seit es den Raspi gibt. Würde prinzipiell auf jedem System funktionieren, wenn man die dazu nötigen Tools hat. Das schließt natürlich nicht aus aus das spezielle Imagewriter noch ein integriertes Tool haben, die das im Anschluß an das Schreiben des Images erledigen. Nötig ist das aber nicht man bekommt das Image mit dd (Linux) oder Win32DiskImager (Windows) problemlos auf die SD und der Pi startet danach auch. Die root-Partion ist dann halt etwas kleiner als maximal möglich wäre, aber dafür gibt es ja raspi-config. Gleich der erste Eintrag ist dafür vorgesehen (s.Bild) - bekommt sogar ein Anfänger hin. Schlaumaier schrieb: > Ich habe mich ja auch nur verteidigt. Gegen ZENO + A.K. . Ne Du hast Blödsinn erzählt: Schlaumaier schrieb: > Die Formatiert > die Karte + Partitioniert sie. Genau das macht die Imagesoftware eben nicht. Sie schreibt einfach nur das Image auf den Zieldatenträger und zwar die RAW-Daten. Nur so ist es überhaupt möglich mit einem OS (wie z.B. Windows) welches das Zielformat (in dem Fall ext4) nicht kennt das Zielformat zu schreiben.
Zeno schrieb: > Nur so ist es > überhaupt möglich mit einem OS (wie z.B. Windows) welches das Zielformat > (in dem Fall ext4) nicht kennt das Zielformat zu schreiben. Wie will ich ein Zielformat schreiben wenn ich nicht weiss wie die SD-Karte aufgebaut ist. Nach den Motto. "Ich weiß nicht war ein Sektor ist, aber klatsch mal irgendwo in die Speicherzelle ein paar Bytes." Cool was es nicht alles gibt. ;)
Schlaumaier schrieb: > Wie will ich ein Zielformat schreiben wenn ich nicht weiss wie die > SD-Karte aufgebaut ist. Ach herrje, übertreibs nicht mit der Ahnungslosigkeit. Die fängt mit Sektor 0 an, danach kommt Sektor 1 und so geht es brav weiter bis zum letzten Sektor. Wobei das dem "dd" sogar egal sein kann, das muss nur das OS wissen. Das Image wird genauso sequentiell vor vorne nach hinten draufgeschrieben wie auf einem Bandlaufwerk und das wars bei der "dd" Methode dann auch schon. Mehr geschieht da nicht. Irgendwelche vorherige Partitionierung ist völlig irrelevant, weil sowieso überschrieben. Nicht mal die Grösse vom Medium muss man wissen, denn wenn man hinten anstösst, weil zu klein, merkt man das ohnehin. Man sollte einzig beachten, dass nichts von der µSD gemountet ist, wenn man das macht. Das OS könnte sonst in die Suppe spucken. > Nach den Motto. "Ich weiß nicht war ein Sektor ist, aber klatsch mal > irgendwo in die Speicherzelle ein paar Bytes." Das trifft es in etwa ;-). Die Sektorgrösse sollte das OS kennen, aber die kennt die µSD selbst, die ändert sich auch nicht täglich, und teilt sie auf freundliche Anfrage dem OS mit. Dem "dd" wiederum ist sie egal.
:
Bearbeitet durch User
Schlaumaier schrieb: > Wie will ich ein Zielformat schreiben wenn ich nicht weiss wie die > SD-Karte aufgebaut ist. Das mußt Du nicht wissen. Weder eine HDD, eine SDD, eine SD, eine CD/DVD oder auch ein Magnetband, haben von Haus aus kein Format bzw. Dateisystem. Rein physikalisch sind das erst mal nur Medien die je nach Aufbau eine bestimmte Anzahl von Bit's seriell speichern können. Das Dateisystem ist OS spezifisch und wird erst von diesem erzeugt. Das OS kann dann die Daten auch entsprechend lesen oder auch schreiben. Für das Erstellen eines Images ist die Kenntnis des genauen Aufbaus des Dateisystems aber gar nicht nötig, da die Daten im RAW-Format ab dem ersten möglichen Speicherplatz bitweise gelesen oder geschrieben werden. Was die einzelnen Bits bedeuten ist dabei völlig irrelevant. Nur dieses Verfahren ermöglicht es ein Image von einem Datenträger zu erstellen bzw. zu schreiben. Es ist ohne weiteres möglich mit Linux ein Image von einem reinen Windowsdatenträger ohne das der Kernel mit FAT-Funktionaslität ausgestattet ist. Ebenso kann man mit Windows (z.B. dem Programm RAWRITE) ein Image einer Disk erstellen die ausschließlich Linuxdateisysteme enthält. Auf diesert Basis macht man z.B. auch Datenrettung. Man zieht vom Datenträger einfach ein Image und arbeitet dann nur noch auf dem Image. So stellt man sicher, daß man den Datenträger nicht weiter beschädigt. Lies mal was zu den Themen Dateisystem und Datenträger - Du wirst feststellen das zwischen beiden ein kleiner aber feiner Unterschied besteht.
Zeno schrieb: > Lies mal was zu den Themen Dateisystem und Datenträger - Du wirst > feststellen das zwischen beiden ein kleiner aber feiner Unterschied > besteht. Werde ich machen. Und ich werde wegen deiner Aussage mal was testen. Ich habe 2 SD-Karten die sich weigern sich formatieren zu lassen. Vielleicht kann ich die mit irgend ein Image beglücken und sie danach wieder normal formatieren.
es könnte sein das der interne µC die µSD Karten wegen zu hoher Fehlerzahl in read-only Modus versetzt hat(also Sie absichtlich nicht mehr beschreibt), hierzu müsste man den µC erstmal "überreden" das zu ändern sonst funktioniert auch keine Formatierung da wie gesagt read-only, wäre das gleiche wie der Schiebeschalter in einem µSD-SD Adapter wenn der auf Lock steht kann man nichts Löschen, Formatieren,...
Schlaumaier schrieb: > Ich habe 2 SD-Karten > die sich weigern sich formatieren zu lassen. Vielleicht kann ich die mit > irgend ein Image beglücken und sie danach wieder normal formatieren. Die Frage ist ob sich da das Image überhaupt schreiben läßt. dd bricht, zumindest beim Lesen, ab wenn Fehler auftreten. Wie es beim Schreiben aussieht kann ich nicht sagen. Wenn sich so eine SD nicht formatieren läßt, ist i.d.R. in den Anfangssektoren, also da wo die Partitionsdaten gehalten werden, was faul. Selbst wenn Du das Image drauf bekommst, befürchte ich wirst Du die Karte am Ende nicht lesen können, weil die Startsektoren defekt sind. Probieren kann man es aber. Ich würde da aber nicht viel Zeit verschwenden und (wichtige) Daten würde ich einer so wiederbelebten Karte auch nicht anvertrauen. Meisten halten solche Reparaturversuche nicht lange und die Karte ist nach kurzer Zeit wieder unbrauchbar. Was man versuchen kann von so einer defekten Karte noch Daten herunter zu holen. Es gibt ein fehlertolerates dd (ich meine das Ding heiß ddrescue), welches auch bei Lesefehlern weiter macht und ein halbwegs brauchbare Image erstellt. Auf das Image läßt man dann eine Datenrettungssoftware los. Ich habe mal mit testdisk einiges retten können.
Für Schlaumeier mal aus der Praxis Vorgestern gemacht: 32GB SD-Karte: Aus laufendem Raspberry 4 mit Raspberry OS 256GB SSD Platte: Aus Windows PC mit Win 10 drauf Image von SD Karte gemacht. Image auf SSD gespielt (mit USB Adapter). Raspberry auf USB Boot umgestellt. SSD mit USB Adapter an den Raspberry. Partition erweitert mit Raspi-config. Fertig. Ohne irgendwelche Partitionen oder Dateisysteme vorher zu ändern. Das Image erstellen und auf SSD spielen wurde am Win10 PC gemacht.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Der Imager ist von Vorteil, > weil er z.B. bereits für aktives SSH sorgen kann, nebst anderen > Voreinstellungen. IIRC kann man auch eine Datei "SSH" in /boot anlegen, damit der sshd gestartet wird.
M. P. schrieb: > Für Schlaumeier mal aus der Praxis https://en.wikipedia.org/wiki/GUID_Partition_Table Ich gratuliere, du hast soeben herausgefunden, dass die Partitionstabelle auch einfach nur Daten an einer bestimmten Stelle auf dem Datenträger sind.
Der Raspberry Pi bootet auch von einer GUID Disk?
:
Bearbeitet durch User
(prx) A. K. schrieb: > Der Raspberry Pi bootet auch von einer GUID Disk? https://wiki.aosc.io/aosc-os/installation/manual/arm-raspberry-pi/ "Raspberry Pi 4 supports USB boot and network boot out of box, this means you can install an OS into hard drive or SSD directly, just after upgrading your EEPROM. Also, you can use a GPT partition table in your media. This greatly reduces some limitation related to boot and partitioning." Geht wohl. Ob es sinnvoll ist ist natürlich eine andere Frage.
Ja. Der RPI4 kann direkt von einer SSD booten die per USB angeschlossen ist. Praktisch wenn auf dem Datenträger viel "herum geschrieben wird". SD Karten mögen das oft nicht gern.
Beitrag #7221745 wurde vom Autor gelöscht.
Peter Pan schrieb: > Generell hat es aber seinen Grund wieso der RPi 1 vielerorts im Schrott > landet Oder anstatt dem lahmen Linux mal was drauf machen was rennt ... https://www.riscosopen.org/content/downloads/raspberry-pi
Peter Pan schrieb: > Generell hat es aber seinen Grund wieso der RPi 1 vielerorts im Schrott > landet Ich sammele gerne solchen "Schrott" auf. Mit ein bisschen Ahnung kann der immer noch den JOB eines Arduino-Mega locker übernehmen. Ist bloß mit den Python was zickig.
Schlaumaier schrieb: > Ist bloß mit den Python was zickig Deswegen unter RISC OS mit BASIC https://www.riscosopen.org/wiki/documentation/show/GPIO%20for%20Raspberry%20Pi
Da ich gerade keine Zeit habe, das downzuladen und in meinen RPi0 auszuprobieren: Ist dieses BASIC bereits im RISC OS enthalten?
Peter Pan schrieb: > Generell hat es aber seinen Grund wieso der RPi 1 vielerorts im Schrott > landet... Also bei mir tut dieser Schrott als Rechner/Server seit nunmehr 8 Jahren für eine TFA Meteotime Duo und eine Vantage Pro2. Ausgelastet ist der mit den 2 Wetterstationen nicht wirklich.
Peter N. schrieb: > Ist dieses BASIC bereits im RISC OS enthalten? BASIC ist ein OS Modul, ist also im Image, und läuft auch ohne das was installiert wurde, geht auch ohne GUI, dann aber nicht sehr bequem: https://www.youtube.com/watch?v=wLRQ4UNKeZw Python muss installiert werden, über PackMan, braucht also Netzwerk. Wie langsam das auf einem Pi 1 ist weiss ich nicht, vermutlich ziemlich langsam.
Wenn man sich z.b. damit beschäftigt denke ich das der Pi-1 noch ne Menge Dinge machen kann. https://pi4j.com/documentation/providers/pigpio/
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.