8000 Port to Frosted OS by danielinux · Pull Request #2634 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Port to Frosted OS #2634

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
wants to merge 16 commits into from
Closed

Port to Frosted OS #2634

wants to merge 16 commits into from

Conversation

danielinux
Copy link

This PR adds support for ⛄ Frosted ⛄
Please comment on this pull request and/or consider for inclusion upstream.

Frosted (https://github.com/insane-adding-machines/frosted) is a Free embedded OS providing POSIX calls.

For this reason, this initial port has been initially based on the existing UNIX port. The idea is to extend the support later on to have full working sockets and threads.

  • minimal configuration compiles and works fine
  • sys module OK
  • usocket/socket modules loading fine, with still some minor glitches to fix (Allocation on socket.bind())

How to test:

@dpgeorge
Copy link
Member

Thanks for the submission. Unfortunately this kind of thing is really outside the scope of the current plans for MicroPython. See #2602.

There is already preliminary support for uPy on top of Zephyr, and see also #2501 for another RTOS.

What are the benefits of frosted and how does uPy fit into its "ecosystem" and its vision/long-term plans?

@pfalcon
Copy link
Contributor
pfalcon commented Nov 15, 2016

I think that hearing about Frosted port is great, and I would provide more detailed review and suggestions a bit later, due to #2602 quoted by @dpgeorge .

@danielinux
Copy link
Author

@dpgeorge , @pfalcon thanks for the comments. Let me try to provide some background. Insane-adding-machines is a small community that has been developing frosted for 18 months now.

Unlike most embedded OSes targeting the same devices (Cortex-M), we focus on hard kernel/userspace separation, memory safety and full POSIX compliance.

Kernel space code is GPL, but our libC has a permissive license that allows linking applications and libraries as separate binaries. uPy runs in userspace and would be distributed with its original license.

We already maintain a small set of userspace tools including a shell, some unix utilities and network configuration tools.

The final goal of this preliminary port would be to have a usable python interpreter in userspace, with a strong focus on networking (socket), and support for pthreads as our kernel already provides both for C programs at this time.

I should have checked #2602 myself and realize that such a PR this is not in line with your current development cycle. I understand that this PR as is introduces quite some duplication from the unix port, as that's what it is based on, as we already provide the syscalls needed for the minimal interpreter to run "unix-style". There is on the other hand some interest from the community to expand this port by providing specific support for sensors drivers etc. Moreover, the unix port seems to be sized for more powerful platforms, while we want to be a bit closer to the resources needed by the stm-hal port.

For these reasons we started an off-tree, self-contained port which allows for more fine-tuned configuration and gives some flexibility to change platform-specific code. In our plans, the /frosted dir will see some clean-up for modules that are currently not in use, and later on, the addition of a few OS-specific features.
Perhaps an effort on a different direction could have been heading to modify the unix port to include frosted support, but we thought that a separate makefile and a single set of mpconfigport.* would make the build process cleaner for frosted users, and less prone to configuration errors.

The only modification currently needed to compile our port against the upstream code is the define in py/emitglue.c for the definition of mp_raw_code_load_file. This is also marked in the code as "TODO" that asks for a better abstraction, so perhaps when this is resolved, the port will be completely self-contained.

The goal for this PR was to hear from you folks about the technical choices we've taken so far and receive some hints on how to proceed. While the code is pretty much self-contained in the frosted directory it is easy to follow upstream development, so we have no urge for an inclusion, but it would be appreciated if we could receive more pointers so that when this project is in a better state and more in line with your vision and goals, it would probably allow for a cleaner PR which I expect to come in the near future.

If you want to know more, continue this discussion or just chat with us, we're always on IRC (#frosted channel on freenode), so feel free to pass by and say hello.

Meanwhile, thanks again for checking this submission at its early stage, and apologies for the long reply.

@dpgeorge
Copy link
Member

@danielinux thanks for the detailed reply.

The only modification currently needed to compile our port against the upstream code is the define in py/emitglue.c for the definition of mp_raw_code_load_file. This is also marked in the code as "TODO" that asks for a better abstraction, so perhaps when this is resolved, the port will be completely self-contained.

Yes, this bit was always temporary and overdue for a proper clean up (basically to make the lexer and the precompiled-bytecode loader use the same back-end file-reading code). I've now done that in 6b239c2 (and other surrounding commits), so you should be able to have a completely self-contained patch for the frosted port.

@danielinux
Copy link
Author

Thanks @dpgeorge - our branch is now updated, and the current patch is completely self-contained.
I will keep you posted on the progress of our port. ⛄ ❤️ 🐍

@danielinux
Copy link
Author

Just an update on this. Since this PR has been submitted, Frosted has added support for pthreads, hence it is possible to enable threading in our branch now. A small os module is provided, as well as some functionality of the time module. We are now looking into adding threading on top of _thread, as mentioned on IRC and the forum.

We'll keep you posted.

⛄ ❤️ 🐍

@pfalcon
Copy link
Contributor
pfalcon commented May 20, 2017

@danielinux : Here's a comment I wanted to give long ago: as far as I understand, FrostedOS strives to be POSIX-compliant, and we have a POSIX port of MicroPython under unix/. It may be interesting for you to see how much of real-world POSIXy code you can run, and for us, how much of beyond-POSIX stuff we have there ;-).

So, feel free to see what it would take to make unix port to build/run on Frosted. Otherwise, I'm not sure if it's practical to have another port of 5000+ lines, majority of which is just duplication of existing code. And if you seriously think about upstreaming, you should also think about CI support (that's necessary, but not sufficient condition; see travis-esp8266 branch for a CI setup which includes adhoc toolchain requirements, etc.).

@danielinux
Copy link
Author

Starting the port on Frosted helped us a lot indeed to complete and improve (part of) our POSIX system call API. I agree with you that a more valid approach could have been to adapt the unix/ code instead of starting from a copy.

We've chosen to go this way mostly to try and be less invasive and avoid tampering with the unix port. Also, unix/ is optimized to run "out-of-the-box" on higher-end machines without worrying about resources and size (e.g. Linux targets), while our target are typically Cortex-M3/4/7, so in the range of the pyboard (the pyboard itself is supported natively by frosted).

Here are a few open points we would need to address when moving our integration under unix/:

  • huge stack size
  • specific toolchain (arm-frosted-eabi-) with specific CFLAGS
  • specific binary format (bFLT vs Elf) which would be non-trivial to integrate into the build
  • specific implementation of readline in input.c

Keeping a separate port has allowed us for a much simpler compile-time configuration (most of the parameters are hardcoded), customized feature shrinking, rapid merge back (which is important due to your current high commit rate). Moreover, some code from the unix port is still in frosted/, but unused, and some parts of the modules can be cleaned up to compile on a smaller embedded target. In other words the frosted port is supposed to be even slimmer than this and could use some cleanup at some point.

We appreciate the heads-up about the upstream inclusion process. I'd say we continue our research on a separate directory for now, and we'll ensure to get our port up to your quality standards if/when we are moving back to unix/, but certainly before upstreaming.

FYI, The current size of a micropython binary compiled for frosted :
text data bss dec hex filename
130412 33860 1436 165708 2874c micropython.gdb

Thank you for taking the time to check and comment.

@pfalcon pfalcon changed the title Port for frosted OS Port to Frosted OS Sep 12, 2017
@dpgeorge
Copy link
Member

Thanks again for this PR. Unfortunately it's not possible to support/maintain this new port in this repository, and the zephyr port already provides similar functionality with a lot of hardware/boards supported.

It would be great to see this Frosted OS port continued as an out-of-tree (ie not in this repo) port, using MicroPython as a submodule. This is now made a lot easier to do in the past few years.

@dpgeorge dpgeorge closed this May 11, 2021
@danielinux
Copy link
Author

Hey @dpgeorge thanks for taking the time to comment on this PR. We haven't been following frosted for while now, but we are still proud of our custom micropython port with threading on Cortex-M. We'll be keeping our off-tree module as suggested.

@dpgeorge
Copy link
Member

We'll be keeping our off-tree module as suggested.

Sounds good! Please do mention it at https://forum.micropython.org and link from the wiki at https://wiki.micropython.org

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@danielinux @dpgeorge @pfalcon
0