Still, your design goals have fundamental conflicts and like. Small and support for net with net-based updates and app library? You run into the fact that for useful net support you need good-sized buffers which can take up a decent amount of SRAM by themselves before anything else applies.
I will give app support for user created apps, but those apps wonât be found on the app store.
You are getting ahead of yourself talking about app stores, since if anyone else does release software for your OS they will probably be releasing it via GitHub, not via any app store. Also, app stores are a very unfriendly model overall, as anyone who has tried to release apps via the Apple App Store or Google Play can attest, and I doubt anyone would want to go out of their way to release their software through a centralized app store if given the choice.
2 Likes
I assume he means an âapp centreâ rather than a store, an app that lists available apps like a âphone bookâ.
But in fact, it is so complex to comply with a platform that it would be more interesting to create a store that fetches the binaries directly from the repositories of the apps in question. Assuming that the code owner authorises republication.
I too would recommend directly fetching from GitHub⌠but one thing is you will have to consider everything that comes with implementing a sufficient HTTPS implementation with proper TLS support. The OP says they want their OS to use a maximum of 64 KiB of SRAM â I have major doubts as to whether their other goals can be readily achieved with that restriction in mind.
2 Likes
I donât remember⌠LWIP (the IP stack used with the pico-sdk) include the TLS layer? I think so, but Iâm not sure.
lwIP comes with an interface to wire in a TLS layer but does not implement TLS itself.
1 Like
Hi Astrox - I would very much like to see a spreadsheet app on the Picocalc! I helped developed a SS app for the SwissMicros DM42 calculator. See GitHub - zooxo/desk42: Spreadsheet, Text, Graphics and Games for the DM42
If you like, I would be happy to work with you on a SS for the PicoCalc. - Jim (UtahPilot)
2 Likes
For reference, Iâve played with TLS on the Pico-W and it needed 32Kb of heap just to run and only implements a subset of the security protocols in use. I failed completely to get SSL running over TLS so couldnât find a way to access a secure MQTT server.
1 Like
I can only quickly respond with a heart, so this reply is to respond with the 
of the realization of reality.
2 Likes
I just think the OP is getting way ahead of themselves here. If they want to create an OS, they should start with something like creating a lightweight multitasking kernel along with libraries for accessing the display, keyboard, SD card, and sound on the PicoCalc. This should be plenty of a project for them for starters.
1 Like
I agree with this. Before I can write any programs, I need a functioning OS, ABI/API I can work with and a tool chain, pretty much in that order. Without that, its just a wish list.
1 Like
Hi Jim! Awesome idea, Iâm happy to work with you for this.
Wifi capability will come either in full release or Version BETA not ALPHA
My mentor often tempered my ambition with his âknow your limitsâ advice. On the contrary, he encouraged me to push those limits!
Otherwise, yes, studying how FreeRTOS works, for example, seems like a good place to start.
No need for the entire real-time mechanism, just the skeleton of an OS: kernel, drivers and interface library should do the trick for the pico.
For the kernel, just the usual pico inits and the task/program loop.
Drivers for screen, keyboard, sound, PSRAM extension, etc.
The interface library will only be used to âaskâ the kernel to access devices/memory.
@Astrox Where are you currently at with a possible interface into your system?
Feel free to ask for help with the code too.
For your first milestone, I recommend having a functional kernel/main program with the screen and keyboard driver. Then you can focus on the interface library, and only after that can you create your app store, which will be a good example of how to use/test your interface library (since the app store will be a program).
1 Like
I recommend that @Astrox start with a preemptive multitasking kernel because this is something that will be very difficult to retrofit if they donât do it initially and decide later that they want it. But it neednât be an elaborate multitasking kernel per se.
After that I recommend writing a simple program that, say, writes to UART0 of the board, a âHello, world!â in essence. And after that I recommend expanding that program to demonstrate multitasking (e.g. the classic âAAAAAAAABBBBBBBBBAAAAABBBBBBBBBâŚâ demonstration of task switching as seen in Linus Torvaldsâ book).
Once their multitasking environment is all nailed down and working, I recommend that the OP develop libraries to interact with the peripherals of the RP2040 and RP2350. In many cases these can simply be wrappers around the Pico SDK to make it multitasking-friendly.
Next, I recommend implementing libraries for interacting with the hardware of the PicoCalc and abstracting it away. This will include low level drivers like a display driver, a keyboard/BIOS driver, an SD card driver, and a sound driver. This will also likely include things like a console abstraction, a filesystem layer, a terminal emulator, and so on.
One thing to consider here is where does the shell come into play. If they are implementing something like a Forth, I would recommend implementing the Forth language environment from the very start, at the same time as the multitasking kernel (much of the multitasking kernel could even be written in Forth!) However, if they are thinking more along the lines of a Unix system, where the shell is just a process like any other, I would wait until the core system and filesystem layer are sufficiently functional.
After all this is done then I would recommend moving onto things like networking. But mind you it will take quite a bit of work to get to that point, and I would not try to skip over or rush the work involved.
1 Like
Yes, indeed, it is better to implement multithreading from the outset, otherwise âit will be pretty hardâ.
Astralixi OS repo has been taken down.
This is because of accidental source code uploading which cannot be undone, so repository has been deleted.
Why are you afraid of us seeing your source code? To the contrary, I would think that it would demonstrate to those of us who are having doubts that your project actually exists and is not mere words, even if it is nowhere near being functional at the present.
3 Likes
The Pimoroni Pico Plus 2W board will be mandatory to use my OS. This is because of the extra ram and flash. This decision may change, but at the point, itâs certain.