[HN Gopher] Piccolo OS, a Small Multitasking OS for the Raspberr...
___________________________________________________________________
Piccolo OS, a Small Multitasking OS for the Raspberry Pi Pico
Author : todsacerdoti
Score : 188 points
Date : 2024-12-19 01:14 UTC (21 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| bsimpson wrote:
| > Since the Internet seems to be full of people with way too much
| time on their hands, I would just like to kindly shoo away any
| C/C++ pedants out there. Yes, I am sure there are a million
| different ways to achieve many of the same results. Yes, I am
| sure there are some fine points of language semantics that could
| be argued about. Yes, I am sure you have a more efficient way of
| writing some of the functions.
|
| > To be honest, I am not interested.
|
| I respect this so much.
| andai wrote:
| >Piccolo OS [...] is designed primarily as a teaching tool.
|
| This means you must carefully balance teaching the right thing
| (a realistic system implemented skillfully) against teaching
| the right way (simplification for didactic purposes).
| KerrAvon wrote:
| You shouldn't. This is what hardware people always say, and
| then when the result is an unmaintainable mess, they want
| software people to bail them out.
| KerrAvon wrote:
| that said, there's not really a lot here, so I'm not sure
| what anyone would take issue with
| bsimpson wrote:
| It's a totally fine and respectable boundary to have: "I'm
| going to share some stuff I did for free for other people to
| learn from, but not if I get a bunch of bitchy/pedantic
| notifications about it."
| tredre3 wrote:
| > I respect this so much.
|
| You really shouldn't, Gary is extremely pedantic himself. He
| really really dislikes criticism or being corrected. For
| example on youtube, in many of his video comment's, he's
| engaged in long fights with anyone who claims that Arduino code
| is C++. In his mind it isn't, therefore that's that.
| nine_k wrote:
| In short: it's a toy OS built primarily for _teaching_ , and it's
| a _cooperative_ multitasking OS, without process isolation. So it
| 's more like Node.js (or win16, or macOS classic) than like what
| we usually call an OS.
| abelsson wrote:
| It's also running on a microcontroller with a few hundred kb of
| memory so even win16 or macOS classic would be a bit heavy.
| Someone wrote:
| > so even win16 or macOS classic would be a bit heavy.
|
| Speed-wise, both would run exceptionally well on that
| hardware.
|
| The first Mac had 128kB memory, about 32 of which were taken
| by its video and audio buffers. It ran at about 8MHz.
|
| The first version of Windows ran on similar hardware,
| requiring a 8088 and 256kB of memory.
|
| The pico has at least that amount of memory, at top speed 16
| times the clock frequency, and two cores.
| teejmya wrote:
| https://axio.ms/projects/2024/06/16/MicroMac.html
| rvense wrote:
| The Pico doesn't have an external memory bus, but something
| like MacOS Classic for an STM32 with a chunk of SDRAM and
| VGAish video would be fun.
| drrotmos wrote:
| The Pico 1 (i.e. the RP2040) doesn't. The Pico 2 (RP2350)
| does, albeit a fair bit slower (since it's QSPI PSRAM) than
| the internal SRAM.
| crest wrote:
| The RP2040 has a single QSPI controller channel, but with
| clever hacks you can multiplex that to boot from SPI and
| switch over to some other (Q)SPI peripheral, but iirc you
| can't write directly (can be emulated via MPU+DMA).
| What's also quite neat is that you can use the external
| flash cache as 16kiB SRAM tiled repeatedly over a 16MiB
| memory window. By abusing the MPU you can allow/trap
| accesses down to 256 byte granularity and implement
| virtual memory (allow only one alias address at a time,
| treat the 16kiB SRAM as a direct mapped cache, and demand
| page from QSPI, other SRAM banks, or whatever you can
| come up with).
| lproven wrote:
| > The Pico doesn't have an external memory bus
|
| I may be misunderstanding what you are saying here but if I
| read this correctly, you are wrong.
|
| The project to run Transputer code on the Pi Pico uses a
| memory expansion for the original Pi Pico. I described it
| here:
|
| https://www.theregister.com/2022/05/06/pi_pico_transputer_c
| o...
| rvense wrote:
| Impressive work! Of course you can access external RAM,
| but it comes with some compromises re: speed and
| usability. Other ARM microcontrollers have a full SDRAM
| controller on board in its normal address space with very
| little overhead compared to the internal memory. I'd
| imagine the SPI RAM here is an order of magnitude slower
| than the internal RAM, if not two?
|
| edit - that is one WILD codebase... it has both pi pico
| support but also (remnants of)... Mac OS 9 support!?
| `#ifdef __MWERKS__`??
| crest wrote:
| Well the RP2040 has a QSPI controller but it has only a
| single channel that is normally the "boot device". If you
| bootstrap via SWD (or USB) this device could be at least
| a QSPI RAM, but writes would have to trapped and
| implemented in the HardFault handler which is of course
| very slow compared to internal SRAM. The RP2350 adds a
| second QSPI channel with QSPI bus (just an additional
| chip select pin).
| vardump wrote:
| Not everything needs to run directly from RAM.
| kergonath wrote:
| That's a weird comment. Node.js is a stack that works on top of
| an OS. If you could just plop it on a SD card and boot a
| computer with it, it would be a OS. Things like DOS or MacOS 9
| were definitely operating systems. There is no reason to
| restrict the term to those with preemptive multitasking.
| TickleSteve wrote:
| "OS" in this context means "scheduler", i.e the code that
| coordinates your application tasks. That description can also
| apply to VMs such as JS, hence the comparison.
|
| You could consider this type of library OS even more tightly
| bound to the application than your typical JS app as its
| actually linked to the user code.
| msh wrote:
| A scheduler is part of a OS, but a scheduler alone does not
| make a OS.
| TickleSteve wrote:
| "Operating Systems" for microcontrollers such as this are
| frequently just schedulers as the Application typically
| contains drivers and hits the hardware itself. e.g.
| FreeRTOS.
| crest wrote:
| Even those implement communication primitives e.g. locks,
| semaphores, mailboxes, etc. as part of the OS. Some of
| the larger ones also define a driver model of sorts
| (which often just codifies the structure of the first
| driver for that type of peripheral e.g. USB, Ethernet,
| CAN, I2C, SPI, GPIO).
| vrighter wrote:
| And the scheduler decides which thread gets to run next. On
| a cooperative multitasking system, guess what the OS code
| you jump to when you yield from a thread does, and what
| it's called?
| TickleSteve wrote:
| That was my point.
| vrighter wrote:
| replied to the wrong coment, sorry
| MisterTea wrote:
| What context are we talking about here?
| kergonath wrote:
| > "OS" in this context means "scheduler", i.e the code that
| coordinates your application tasks
|
| If you define the context to mean it and then assume that
| everyone agrees with your implicit context, then maybe. In
| reality, OS and schedulers are not the same thing.
|
| It's also a leap from the "MacOS 9 was not an OS" GP
| position.
| rvense wrote:
| > It's also a leap from the "MacOS 9 was not an OS" GP
| position.
|
| That wouldn't be the first time I've heard that
| statement, even among classic Mac enthusiasts.
| 0x457 wrote:
| > "OS" in this context means "scheduler",
|
| That's essentially what OS is: some bootstrap, scheduler
| and some APIs for developers and some drivers.
| whobre wrote:
| By your definition, CP/M and DOS are not operating systems
| either
| jollerina wrote:
| struct { // ... } typedef piccolo_os_internals_t;
| int typedef Int; // also works.
|
| You always learn some new quirk of C. I guess typedef works like
| const, can put it on the left or the right.
| formerly_proven wrote:
| TIL and looked it up, typedef is indeed just a specifier like
| any other in a declaration.
| extraduder_ire wrote:
| Aren't those the same thing? <type> typedef <name>
|
| My c is pretty rusty, admittedly.
| akovaski wrote:
| The interesting thing being pointed out is that you can do
| both `typedef <type> <name>;` (the common way, I think) and
| `<type> typedef <name>;`.
| dariosalvi78 wrote:
| for a less toy example, it seems like FreeRTOS can be used also
| on the Rpi pico:
| https://freertos.org/Documentation/02-Kernel/03-Supported-de...
| pkphilip wrote:
| This is cool! works well as a way of understanding how to get an
| OS going on Pico
| rbanffy wrote:
| I remember Linux (and NetBSD) running on outrageously low-end
| hardware (even hardware without an MMU). While modern Linux is a
| no-go, would there any existing and relatively popular OS be
| viable?
| hackernudes wrote:
| You can run modern Linux without an MMU! But other popular
| embedded OSes I've heard about are FreeRTOS and Zephyr.
| jsheard wrote:
| And someone has in fact managed to get MMU-less Linux running
| on the newer Pico 2:
|
| https://github.com/Mr-Bossman/pi-pico2-linux
|
| That's with an 8MB external PSRAM though, fitting modern
| Linux in the internal SRAM is probably a step too far.
| joezydeco wrote:
| I used to work with a Cortex-M3 port of uCLinux, but it was
| kind of a pain to manage. The biggest problem being every
| executable had to be statically linked to all of its
| dependencies.
| crest wrote:
| You can run uC Linux without an MMU, but you won't get memory
| safety. Better microcontrollers (that includes the RP2040 and
| RP2350) have an MPU (memory protection unit) to implement
| memory safety, but almost no microcontroller has a real MMU
| (only the MIPS derived PIC32 come to mind). An MPU is far more
| visibly exposed to the programmer than a paging MMU that
| combines access control with address space virtualisation. To
| make it even more annoying the ARMv6M architecture isn't
| intended to recover from memory usage faults. You have to use
| really dirty tricks to "fake it" (return from the hard fault
| into an unimplemented exception, infer the address and cause
| the fault before you can recover), but it's possible. It's not
| even that slow. Depending on your usecase a fast warm-start of
| the whole chip may be preferable to restarting single tasks
| (e.g. just set the hardware watchdog countdown timer to 1 and
| spin until it happens).
| cmrdporcupine wrote:
| Guess it depends on your definition of popular. There's various
| RTOS products, some of which have POSIX APIs.
|
| If you're fine with obscure and retro, there's things like
| RISC-OS (ARM). Or EmuTOS (68k/ColdFire). Or FreeDOS etc (x86)
| rbanffy wrote:
| I wouldn't say RISC-OS or EmuTOS would be sensible options
| for new development unless the point is to develop for them
| (I wrote a couple programs to use Tektronix 4014 graphics the
| other day in order to use Tektronix 4014 graphics). I was
| thinking about reusing existing OSs and their stacks.
| jacobmarble wrote:
| I've been using protothreads on the RP2040 (Pico MCU) for task
| management.
|
| https://dunkels.com/adam/pt/
|
| The extensions available from Hunter Adams at Cornell are also
| very useful. In particular, PT_YIELD_INTERVAL() has been very
| useful for me.
|
| https://people.ece.cornell.edu/land/courses/ece4760/RP2040/C...
| fsiefken wrote:
| Fuzix works as well...
| https://www.reddit.com/r/raspberrypipico/comments/15si3ow/fu...
___________________________________________________________________
(page generated 2024-12-19 23:01 UTC)