Hier gibt es eine Anleitung, den Raspberry Pi ohne Betriebsystem zu betreiben: https://github.com/dwelch67/raspberrypi Linux oder ähnlich Betriebssystem brauchen immer längere Zeit um zu booten, das würde in obigem Beispiel wegfallen. Man könnte sich überlegen, die Arduino-Bibliothek zu implementieren, das gäbe dann den Super-Arduino.
chris schrieb: > Man könnte sich überlegen, die Arduino-Bibliothek zu implementieren, das > gäbe dann den Super-Arduino. nicht wirklich... schau dir mal an was der broadcom chip alles kann...da ist nichts mit schnellen gpio's oder so ..
chris schrieb: > Hier gibt es eine Anleitung, den Raspberry Pi ohne Betriebsystem zu > betreiben: > https://github.com/dwelch67/raspberrypi Ja klar, warum auch nicht... ist im Endeffekt ja auch "nur" ein ARM. > Linux oder ähnlich Betriebssystem brauchen immer längere Zeit um zu > booten, das würde in obigem Beispiel wegfallen. Andererseits frage ich mich was für Anwendungen du siehst, in denen es auf ein paar Sekunden Startup-Time ankommt und man gleichzeitig aber 700MHz braucht. Ich würde da mal wieder Cortex M sagen. Der hat auch >100MHz und ist alles in allem noch übersichtlich, was Peripherie, Startup-Code, usw. angeht.
>Andererseits frage ich mich was für Anwendungen du siehst, in denen es >auf ein paar Sekunden Startup-Time ankommt und man gleichzeitig aber >700MHz braucht. Meiner Meinung nach ist es nicht nur die schnelle Startup-Time. Auch die vielen Updates bei Betriebssystemen und deren Verwundbarkeit stören mich. >Ich würde da mal wieder Cortex M sagen. >Der hat auch >100MHz und ist alles in allem noch übersichtlich, was >Peripherie, Startup-Code, usw. angeht. 700 MHz und FPU sind da aber noch einmal eine Größenordnung darüber. Falls jemand einen Grafiktreiber inplementiert, könnte man einen HDMI-Monitor auch als Debug-Terminal nutzen.
Dominik S. schrieb: > ein paar Sekunden Startup-Time Und das bekommt man notfalls auch mit einem abgespeckten Linux hin. chris schrieb: > Falls jemand einen Grafiktreiber inplementiert, könnte man einen > HDMI-Monitor auch als Debug-Terminal nutzen. Das dürfte aber schon etwas Aufwand sein, den andere Leute (sprich OS-Entwickler) schon mal betrieben haben. Zum Lernen sicher gut, wenn man den Chip nur nutzen will, aber eher unnötiger Zusatzaufwand. chris schrieb: > Meiner Meinung nach ist es nicht nur die schnelle Startup-Time. Auch die > vielen Updates bei Betriebssystemen und deren Verwundbarkeit stören > mich. Die Updates musst du ja nicht anwenden. Wenn es ein alleinstehendes embedded-Projekt ist, spielen Verwundbarkeiten etc keine Rolle. Wenn du kein LAN o.ä. brauchst, schmeiß einfach den Treiber aus Linux raus ;-) Klar, man kann den Pi als reinen µC betreiben, aber mMn überwiegen in dieser Leistungs- und Komplexitätsklasse die Vorteile eines Betriebssystems. Lerneffekte etc natürlich mal außen vor gelassen.
Lohnt sich imo nicht, weil die GPIOs trotzdem relativ lahm sind, und Echtzeit kriegt man eh nicht hin. Der ganze Vorteil von dem Ding ist doch, dass man es als High-Level-Bastelkiste benutzen kann, um mal schnell ein paar SPI-Bauteile mit Python anzusteuern, ohne einen uC flashen zu müssen.
>Lohnt sich imo nicht, weil die GPIOs trotzdem relativ lahm sind, und >Echtzeit kriegt man eh nicht hin. Ich höre immer langsam: wie schnell sind sie denn konkret? >Der ganze Vorteil von dem Ding ist doch, dass man es als >High-Level-Bastelkiste benutzen kann, um mal schnell ein paar >SPI-Bauteile mit Python anzusteuern, ohne einen uC flashen zu müssen. Python ist ein Argument. Gibt es einen Python Interpreter ohne Betriebssystem?
chris schrieb: > Ich höre immer langsam: wie schnell sind sie denn konkret? > Sowas findet man im Datenblatt. > > Python ist ein Argument. Gibt es einen Python Interpreter ohne > Betriebssystem? Koennte ich mir jetzt nicht vorstellen, wie das gehen sollte. fonsana
Vieleicht ist das ein Anfang für den Echtzeitkernel http://linuxcnc.org/index.php/english/forum/18-computer/20514-emc2-running-on-raspberry-pi Gruss Bernd
Der PI bootet ja mittlerweise schneller als am Anfang. Wie schnell aktuell ohne zusätzliche Services weiß ich aber nicht da ich noch einiges mehr laufen habe. Es geht aber wirklich fix.
chris schrieb: > das > gäbe dann den Super-Arduino. Oh mann, immer die Leute die ne LED aufm Arduino zum blinken bekommen und dann meinen sie sind der König der Welt... Guck doch ersmal wie men nen kleineren ARM programmiert bisse dich an sonen großen SoC rantraust.
Martin Wende schrieb: > chris schrieb: >> das >> gäbe dann den Super-Arduino. > Oh mann, immer die Leute die ne LED aufm Arduino zum blinken bekommen > und dann meinen sie sind der König der Welt... wahre Worte. Hier mal das TRM des Cores: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0301h/DDI0301H_arm1176jzfs_r0p7_trm.pdf das wäre mal ein Anfang. Für das SoC gibts wohl leider noch kein Datenblatt aber zumindest das hier für die Peripherie: http://www.raspberrypi.org/wp-content/uploads/2012/02/BCM2835-ARM-Peripherals.pdf
chris schrieb: > Man könnte sich überlegen, die Arduino-Bibliothek zu implementieren, das > gäbe dann den Super-Arduino. Ist das dann für die Super-Deppen? Und normales Arduino für die normalen Deppen?
chris schrieb: > Hier gibt es eine Anleitung, den Raspberry Pi ohne Betriebsystem zu > betreiben: > https://github.com/dwelch67/raspberrypi > Linux oder ähnlich Betriebssystem brauchen immer längere Zeit um zu > booten, das würde in obigem Beispiel wegfallen. > > Man könnte sich überlegen, die Arduino-Bibliothek zu implementieren, das > gäbe dann den Super-Arduino. Das letzte Mal als ich dazu was gelesen hatte, waren Sachen wie HDMI und USB (und damit Ethernet) noch in weiter ferne. Imho ist das Projekt was für Hardcoreprogrammeiren die den ARM wirklich kennen lernen wollen. Für den normalen Bastler, insbesondere solche die (noch) in der Arduinoecke sind, ist und bleibt Linux auf dem Board die erste Wahl. Wenn dir das Linux zu langsam bootet, dann bau ein Image aus dem du alles, für dein Projekt, unnötige rausschmeißt. Wem das schon zuviel Arbeit ist, für den ist die bare metal Programmierung ARMs auf längere Zeit unerreichbar. Wie schon gesagt wurde, wer für den üblichen Arduinokram mehr Power braucht, sollte sich vielleicht mit den Cortex-M(0,3,4) auseinander setzten.
>Das letzte Mal als ich dazu was gelesen hatte, waren Sachen wie HDMI und >USB (und damit Ethernet) noch in weiter ferne. Es schreibt ja niemand vor, dass man HDMI, Ethernet oder USB benutzen muss. Das Raspberry hat ja auch noch andere Schnittstellen. >Imho ist das Projekt was für Hardcoreprogrammeiren die den ARM wirklich >kennen lernen wollen. Beschränkt man sich auf Audioprogrammierung, ist der Raspberry durchaus für mehr als nur Hardcoreprogrammierer geeignet, wie dieses Projekt zeigt: http://www.joebutton.co.uk/blog/baremetal-midi-lv2-raspberrypi/ Wenn ich es richtig gesehen habe, ist der Videotreiber auch schon weiter als Dein letzter Kenntnisstand. >Für den normalen Bastler, insbesondere solche die (noch) in der >Arduinoecke sind, ist und bleibt Linux auf dem Board die erste Wahl. Wieso? Wenn es die Arduino Lib gibt, lassen sich direct Arduino Programme ohne Änderung laufen lassen.
chris schrieb: > Ich höre immer langsam: wie schnell sind sie denn konkret? Über SPI kann ich ungefähr 15k Messwerte von einem 16bit AD-Wandler pro Sekunde lesen (der Wandler kann eigentlich 100k). Wenn man sich Mühe gibt, schafft man wohl einige Megahertz Takt an den anderen GPIOs. So in der Größenordnung. Aber: nicht in Echtzeit. Also, du kannst zwar was schreiben, was die GPIOs mit ein paar MHz umschaltet, aber da werden immer mal Aussetzer drin sein. Echtzeit wird auch mit Echtzeit-Kernel wohl auf der Architektur nicht gehen...
>Vieleicht ist das ein Anfang für den Echtzeitkernel >http://linuxcnc.org/index.php/english/forum/18-com... >Gruss Bernd Zumindest wäre der "bare metal" Ansatz für Echtzeitanwendungen sehr geeignet.
>Echtzeit wird auch mit Echtzeit-Kernel wohl auf der Architektur nicht >gehen... Ja das ist ein beliebter Fehler. Echtzeit: "Als Echtzeitsysteme werden Systeme bezeichnet, welche an sie gestellte quantitative Echtzeitanforderungen erfüllen." http://de.wikipedia.org/wiki/Echtzeit
Auf dem Raspberry Pi wird man, soweit ich weiß, keine Echtzeitanwendungen hinkriegen, auch nicht mit Bare Metal. Hat wohl damit zu tun, dass die Firmware vom Grafik-Controller sich ab und zu mal den Speicher krallt. Ganz genau weiß ich jetzt auch nicht bescheid, aber das ist die landläufige Meinung. ;)
chris schrieb: >>Echtzeit wird auch mit Echtzeit-Kernel wohl auf der Architektur nicht >>gehen... > Ja das ist ein beliebter Fehler. > > Echtzeit: > > "Als Echtzeitsysteme werden Systeme bezeichnet, welche an sie gestellte > quantitative Echtzeitanforderungen erfüllen." > > http://de.wikipedia.org/wiki/Echtzeit Wahre Worte. Noch kürzer sagte es ein Prof an meiner Alma Mater: "echtzeitig ist rechtzeitig". Auch ein System mit 10 Sekunden Reaktionszeit kann ein Echtzeitsystem sein. Sofern die Anforderungen so sind und es die 10 Sekunden auch garantiert einhält. XL
So wie ich immer ein Echtzeitsystem verstanden habe, muss dieses garantiert in einer bestimmte Zeit reagieren können. Sobald ich ein System habe, welches unkontrolliert mein Programm unterbricht und ich dies nicht abschalten kann, ist dies kein Echtzeitsystem. Wenn ich ein System habe welches immer garantiert in ein paar Sekunden reagiert ist dies echtzeitfähig, währen ein System was in Millisekunden reagieren kann, aber auch den Programmablauf unterbrechen kann kein Echtzeitsystem. Ein Commodore 64 ist wesentlich besser für ein Echtzeitanwendungen zu gebrauchen, als ein PC mit aktueller 16 Core CPU/GPU, unter Windows/Linux was auch immer.
fonsana schrieb: > chris schrieb: >> Python ist ein Argument. Gibt es einen Python Interpreter ohne >> Betriebssystem? > > Koennte ich mir jetzt nicht vorstellen, wie das gehen sollte. man könnte eine initrd bauen die dem kernel zur bootzeit als rootfs übergeben wird und in der nur python+script läuft - das würde dann per kernel parameter "init=/script.py" aufgerufen.
Hallo, nutze meinen RPi mittlerweile als TCP/IP Zugang vom Smartphone aus, um TWI Bausteine (auch MCs) als Slave anzusprechen. Das klappt allerbestens. Damit lässt sich elegant & vor allem preisgünstig das ganze Haus automatisieren. Subjektiv reagiert das System in Echtzeit. Hängt man sogar noch einen oder mehrere MC-Slave(s) daran, der Sub-Tasks abarbeitet oder auf Events reagiert und diese nach einer Vorverarbeitung an das RPi (Smartphone via WLAN) übergibt (zwecks Visualisierung), hat man Echtzeit! Anders macht es die Prozess/Automationsindustrie auch nicht! RPi ist einfach nur klasse - für mich eine kleine Revolution in der embedded Welt. Die verkauften Stückzahlen > 10**6 aprechen für sich. Gruß
Echtzeit bedeutet nicht, dass ein System in sehr kurzer Zeit reagieren kann. Auch wenn so ein Verhalten oft auch Echtzeit genannt wird.
Es ist schon irgendwie bemerkenswert, dass Geschwindigkeit und Reaktionszeit ja schon fast umgekehrt proportional zueinander sind. So ein kleiner ATMega kann locker in 100 ns auf was reagieren. Bei den ARMs wird das schon länger, und ein richtiges Linux-System braucht in der Regel schon einige µs. Bei 90% der Mikrocontrolleranwendungen ist das egal. Da reichen 100 ms als Reaktionszeit aus. Der große Vorteil vom Raspberry Pi ist halt, dass man das Teil sehr einfach debuggen kann, und auch sehr einfach vernetzen kann. Das sind Unixteile. Da kann man mit einer Zeile Shellcode herausfinden wie oft Fefe in seinem Blog facepalmt.
chris schrieb: > Es schreibt ja niemand vor, dass man HDMI, Ethernet oder USB benutzen > muss. Das Raspberry hat ja auch noch andere Schnittstellen. Da muß ich doch mal nachfragen: chris schrieb: > Auch die vielen Updates bei Betriebssystemen und deren Verwundbarkeit > stören mich. Warum meinst du, dauernd Updates machen zu müssen, und wogegen soll es verwundbar sein, wenn du die "großen" Schnittstellen allesamt nicht nutzt? Hast du Angst, daß jemand über GPIO einen Virus einschleust? Martin Bauer schrieb: > Sobald ich ein System habe, welches unkontrolliert mein Programm > unterbricht und ich dies nicht abschalten kann, ist dies kein > Echtzeitsystem. Es gibt aber für Linux auch Echtzeit-Erweiterungen, mit denen man Tasks Echtzeitpriorität geben kann. Dann werden die auch nicht unkontrolliert unterbrochen. > Wenn ich ein System habe welches immer garantiert in ein > paar Sekunden reagiert ist dies echtzeitfähig, währen ein System was in > Millisekunden reagieren kann, aber auch den Programmablauf unterbrechen > kann kein Echtzeitsystem. Man unterscheidet hier noch manchmal zwischen "harter" und "weicher" Echtzeit. Ersteres bedeutet, daß unter keinen Umständen jemals die Reaktionszeit länger als die Maximalzeit sein darf, während bei weicher Echtzeit eine kleine Überschreitung, die ab und zu mal auftritt, nicht weiter tragisch ist. Christian Berger schrieb: > So ein kleiner ATMega kann locker in 100 ns auf was reagieren. Bei den > ARMs wird das schon länger, und ein richtiges Linux-System braucht in > der Regel schon einige µs. Vor allem, wenn es dann ein PC ist. Der ist nicht auf kurze Reaktionszeiten, sondern auf hohen Datendurchsatz optimiert. Das führt dazu, daß es sehr schnell geht, wenn man Daten in großen Blöcken verarbeitet, aber gähnend langsam, wenn z.B. für jedes Byte einzeln ein Interrupt eintrudelt.
Hendrik L. (lbd) schrieb: >nutze meinen RPi mittlerweile als TCP/IP Zugang vom Smartphone aus, um >TWI Bausteine (auch MCs) als Slave anzusprechen. Das klappt >allerbestens. Ähm .. jetzt mit oder ohne Betriebsystem ( Linux )?
chris schrieb: > Ähm .. jetzt mit oder ohne Betriebsystem ( Linux )? Sicher mit. Einen Webserver aufzusetzen und per Shellskript auf Schnittstellen zugreifen geht in ein paar Stunden. Das ganze von Hand programmieren dauert ewig (ohne komplette Libs zu verwenden)
Christian Berger schrieb: > So ein kleiner ATMega kann locker in 100 ns auf was reagieren. Bei den > ARMs wird das schon länger, und ein richtiges Linux-System braucht in > der Regel schon einige µs. Womit kannst Du diese Behauptung belegen?
Sagen wir mal externer INterrupt: der xmega kann das per hardware eventsystem abhandeln oder guckt in die IRQ Vektortabelle und hat sofort die passende routine. beim arm wird ein IRQ für alle quellen ausgelöst, der muss erstmal gucken woher der eigentlich kam. bei nem OS, nunja ;)
Martin Wende schrieb: > beim arm wird ein IRQ für alle quellen ausgelöst, der muss erstmal > gucken woher der eigentlich kam. Cortex M zumindestens hat viele Interrupts und je nach Hersteller auch etwas wie das Eventsystem von XMega
Es gibt ja auch nicht DEN arm. Die meisten machens aber so wie beschrieben, atmel baut ja auch ne AIC (gückt für den kern schonmal nach aus welchem der sammelkanäle der kam) ein. trotzdem lahm der Interrupt. weil dann noch der einzelne interrupt vom sagen wir uart geprüft werden muss (also zB ob rxrdy oder txrdy) Ändert aber nichts daran, dass der Kern selbst nur IRQ und FIQ hat.
Uwe Bonnes schrieb: > Firma: TU Darmstadt ^^^^^^^^^^^^ > Womit kannst Du diese Behauptung belegen? Nicht so gut abgeschnitten, bei der Exzellenzinitiative? Ihr habt die Fragen, wir die Antworten.
Christian Berger schrieb: > So ein kleiner ATMega kann locker in 100 ns auf was reagieren. Ein ATmega mit 20MHz, d.h. 50ns pro Takt, braucht mindestens mal 4 Takte um zur ISR zu springen (200ns), und dann noch 2 für jedes Register-Push. Insgesamt inklusive PUSHen aller 32 Register also 3.4µs. > Bei den ARMs wird das schon länger, zB der Cortex-M4 braucht 12 Takte zum Interrupt-Eintritt, inklusive dem automatischen Pushen von 5 Registern, und dann noch k+1 Takte für k Register-PUSHes. Insgesamt inklusive PUSHen aller 13 Register also 21 Takte, zB beim STM32F4 Discovery mit 168MHz also 120ns. Wir sehen also dass der ARM 21 Takte und der AVR mind. 68 braucht, und aufgrund der höheren Taktfrequenz ist der ARM 28x schneller beim ISR-Eintritt. Außerdem macht der ARM in der Zeit die 1.6-fache Arbeit, da er 32bit-Register hat und der AVR nur 8bit-Register. Zusätzlich macht der Interrupt Controller (NVIC) des noch automtisch Interrupt-Priorisierung und Nested Interrupts, kann also in Spezialfällen nochmal extra schneller & flexibler als der AVR sein.
Was haltet ihr davon, wenn ihr mal anfangt zu Programmieren (nicht arduino-style) z.B. auf einem STM32F4. Da habt ihr ARM bis zum Umfallen und völlig ausreichend wofür man einen Mikrocontroller braucht. Bit-peeping und irgendwelche Zeitvergleich wielange der Sprung in die ISR dauert sind glaube ich da wenig zielführend. Für wen ist das wirklich (!) wichtig? Die meisten hier wissen nichtmal was beim IRQ auf den Stack gepusht wird. Die Arduinofraktion kennt ihn vermutlich nicht mal. Leute programmiert was ihr programmieren wollt aber bitte tut es und macht nicht nur rum was alles so toll wäre. Wenn euch der verwendetet µC ausgeht, dann nehmt einen größeren und wenn ihr beim STM32F4 angekommen seid, gut programmieren könnt und euch der ausgeht, dann garantiere ich euch, dass ihr dann so weit seid, dass ihr auch mit ARM vernünftig umgehen könnt. Dann kann man sich Gedanken machen wie man einen Raspberry Pi hart ansteuert. Zum Thema Echtzeit: "Als Echtzeitsysteme werden Systeme bezeichnet, welche an sie gestellte quantitative Echtzeitanforderungen erfüllen." zitiert aus unsicherer Wikipediaquelle. Da steht aber alles drin was man wissen muss. Ob ein System echtzeitfähig ist, das hängt von der Echtzeitanforderung ab. Wenn es die Anfordeurng so will, dann ist auch ein System mit 5 Minuten Totzeit/Latenzzeit ein echtzeitfähiges System.
Martin Wende schrieb: > Es gibt ja auch nicht DEN arm. > > Die meisten machens aber so wie beschrieben, atmel baut ja auch ne AIC > (gückt für den kern schonmal nach aus welchem der sammelkanäle der kam) > ein. > trotzdem lahm der Interrupt. > weil dann noch der einzelne interrupt vom sagen wir uart geprüft werden > muss (also zB ob rxrdy oder txrdy) > > Ändert aber nichts daran, dass der Kern selbst nur IRQ und FIQ hat. Genau wie du sagst. Es gibt nicht DEN ARM. Es gibt für jeden Zweck einen passenden. Wenn man einen Applikationsprozessor wie diesen ARM11 nimmt darf man sich nicht wundern wenn er eben kein komplexes Interruptsystem hat. Interrupts gehören ja sowieso grundsätzlich dem OS auf so einem System. Wenn man den fuer die Anwendung richtigen Core wählt, also einen ARM Cortex-M dann sieht es schon anders aus mit den Interruptverhalten. Hier findest du eine garantierte maximale Interruptlatenz von 12 Zyklen in einem komplexen Interruptsystem mit über 200 möglichen Interruptquellen und Prioritäten. Genug "Echtzeit"
Sven B. schrieb: > Lohnt sich imo nicht, weil die GPIOs trotzdem relativ lahm sind, und > Echtzeit kriegt man eh nicht hin Ist zwar jetzt schon länger her, aber hier trotzdem noch eine Antwort: RiscOS pico ist ein so "schmales" Singletask-Betriebssystem dass es als "Bare Metal" durchgehen kann. Damit ist Echtzeit möglich. Boot-Zeit < 0.5 sec. Kernel 2 MB. https://www.riscosopen.org/news/articles/2017/02/24/pico-embiggened-once-more chris schrieb: > Python ist ein Argument. Gibt es einen Python Interpreter ohne > Betriebssystem? RiscOS pico bootet in einen BASIC Interpreter mit Inline Assembler. SYS = Supervisor Call. Der ADC MCP3008 z.B. sieht mit "Bit-Bang" SPI so aus: CS = 8 MISO = 9 MOSI = 10 SCLK = 11 HIGH = 1 LOW = 0 SYS "GPIO_WriteMode", CS , %001 SYS "GPIO_WriteMode", MISO, %000 SYS "GPIO_WriteMode", MOSI, %001 SYS "GPIO_WriteMode", SCLK, %001 channel = 0 REPEAT SYS "GPIO_WriteData", CS , HIGH SYS "GPIO_WriteData", CS , LOW SYS "GPIO_WriteData", SCLK, LOW cmd = channel cmd = cmd OR %00011000 FOR index = 1 TO 5 IF (cmd AND %00010000) THEN SYS "GPIO_WriteData", MOSI, HIGH ELSE SYS "GPIO_WriteData", MOSI, LOW ENDIF SYS "GPIO_WriteData", SCLK, HIGH SYS "GPIO_WriteData", SCLK, LOW cmd = cmd << 1 NEXT index value = 0 bit = 0 FOR index = 1 TO 11 SYS "GPIO_WriteData", SCLK, HIGH SYS "GPIO_WriteData", SCLK, LOW value = value << 1 SYS "GPIO_ReadData" , MISO TO bit IF (bit = HIGH) THEN value = value OR 1 ENDIF NEXT index PRINT "Trimmer = " value timeact = TIME + 40 REPEAT UNTIL TIME > timeact UNTIL FALSE
Der picromite http://www.thebackshed.com/forum/uploads/matherp/2017-10-17_080857_mmbasic-stretch.zip
Stefan H. schrieb: > Wie schon gesagt wurde, wer für den üblichen Arduinokram mehr Power > braucht, sollte sich vielleicht mit den Cortex-M(0,3,4) auseinander > setzten. Er könnte z.B. einen Arduino mit dem SAM3X8E ARM Cortex-M3 Controller nehmen.
Und hier gibt es die "die Arduino-Bibliothek" fuer den PI ultibo.org
heinz schrieb: > Und hier gibt es die "die Arduino-Bibliothek" fuer den PI Das ist aber PASCAL warum auch immer. RiscOS pico mit BASIC ist wesentlich einfacher, praktisch wie BASCOM. Und da es < 2 MB ist passt es auch in einen Flash z.B. den vom Pi Compute Module - somit keine SD Karte erforderlich.
chris schrieb: > Python ist ein Argument. Gibt es einen Python Interpreter ohne > Betriebssystem? Ich habe es noch nicht ausprobiert aber es gibt MicroPython für Bare-Metal ARM u.a. https://micropython.org
>Das ist aber PASCAL warum auch immer
Deshalb die ""
ultibo ist im Moment sehr aktiv z.B. OpenGl auf dem Videocore usw. Pico
ist obsolet?
chris schrieb: > Man könnte sich überlegen, die Arduino-Bibliothek zu implementieren, das > gäbe dann den Super-Arduino. Klar, an einen Porsche könnte man auch eine Deichsel implementieren und hätte dann einen Super-Handwagen zum Flaschensammeln.
heinz schrieb: > Pico ist obsolet? Wie das? Ist doch erst eine neue Version rausgekommen. Und gibt praktisch täglich ein neues "Nightly beta development build" Und im Repository tut sich viel. https://www.riscosopen.org/content/downloads/raspberry-pi https://www.riscosopen.org/viewer/revisions
Mein Fehler https://www.riscosopen.org/content/sales/risc-os-pico The RISC OS Pico card has now been discontinued.
heinz schrieb: > RISC OS Pico Schon wegen dieser ARM Assembler NEON Demo von Michael Kübel lohnt es sich pico mal anzusehen.
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.