Zephyr RTOS port #2481
Comments
|
@daniel-thompson : FYI |
Sounds good! Would you consider putting it in ports/zephyr, as per ideas in #2401? |
Thanks!
I don't know, it may be a somewhat complicated to land it under ports/ directly, especially that there're 2 diverged trees for Zephyr support. Perhaps, move it after everything is landed? |
I guess that's ok. It's just, now that we are going to have a few more ports landing (zephyr, and hopefully samd21 soon) it would be good to decide (soon, but not immediately) and commit to a decision on how to structure the repo going forward. For example, if we want to clean up the top level dir we can move logo/ to a separate repo (it doesn't really belong here), and put some parts from drivers/ into lib/, and the rest from drivers/ could go in micropython-lib, or a new drivers repo. Anyway that's a bit off topic. Would be good to see Zephyr support and I can try it out! |
I guess the most productive way to go forward with this is to create a ticket "Prepare for 2.0 release" and list/discuss all the pending changes of that sort, like: moving ports under ports/, changing "mp_" prefix, changing "Micro Python" to "MicroPython" consistently, etc., etc. Well, I personally don't find anything of that critical at this time, so would leave people interested in that to drive that (creation and maintenance of the ticket above), or approach that closer to the end of the year, with the outlook to release 2.0 some time in the new year (Q1 tentative). |
I agree with you. So this issue is not hijacked, and we give everyone a chance to prepare for breaking changes, I've created #2486. |
|
From #2946 (comment)
Thanks for the report, confirmed. The Zephyr port build system does have few issues. And it's not exactly easy to solve some, because the idea is that it should follow in interface of Zephyr's build system whenever possible, but then I try to make the other things work like in other MicroPython ports, and that doesn't work well together. I'm going to look into ways to fix that. |
Fixed in 40e5410 by introducing a make warpper script to build/run "minimal" zephyr port. Another issue, that any make invocation caused a full rebuild, was fixed in 736a8a8. There's still a known issue that switching to build for second BOARD= after you built first one requires explicit "make clean" inbetween. |
Thanks, that works for me.
That's also a good fix, although it's still a bit annoying that it needs to relink (which is slow) each time you just want to run the emulator (eg ./make-minimal qemu). Also, I get "UART buffer overflow - char dropped" when in paste mode if the paste has moderate size (roughly 300 bytes). |
Slow as "not instantaneous"? Well, that's how Zephyr build system works I believe, I'm not even sure if it relinks, or just checks whether some stuff needs to be updated. I'll double-check, but I believe other apps work in the same way, so little can be done on uPy side. And well, you didn't check "make clean" - after a git pull, that'll start with recompiling Kconfig before proceeding to clean something, but not all (that's what "clean" means in Z land). That's what I call "slow". That behavior was contributed and I'm losing patience with it (I literally do rm -rf outdir manually instead), so will submit a patch to revert to normal uPy behavior soon. @daniel-thompson: ping ;-).
Well, that's why there a UART buffer at all. Does esp8266 work better for such pastes? No idea how to fix that, that would involve digging in Zephyr task priorities and scheduling to make sure uPy thread gets a chance to run inbetween data being pumped into circular buffer. |
|
On 14/03/17 07:55, Paul Sokolovsky wrote:
Slow as "not instantaneous"? Well, that's how Zephyr build system works
I believe, I'm not even sure if it relinks, or just checks whether some
stuff needs to be updated. I'll double-check, but I believe other apps
work in the same way, so little can be done on uPy side.
Currently the micropython side forces a relink by unconditionally
bydeleting zephyr.elf because zephyr build system adds the micropython
libraries as custom linker flags and therefore cannot run the proper
dependancy chain.
Agree that relinking to run an emulator is somewhat annoying. We could
perhaps improve this if the command to remove zephyr.elf only ran when
we relink that micropython library.
And well, you didn't check "make clean" - after a git pull, that'll
start with recompiling Kconfig before proceeding to clean something, but
not all (that's what "clean" means in Z land). That's what I call
"slow". That behavior was contributed and I'm losing patience with it (I
literally do rm -rf outdir manually instead), so will submit a patch to
revert to normal uPy behavior soon. @daniel-thompson
<https://github.com/daniel-thompson>: ping ;-).
For a normal Zephyr application "clean" removes the object files (i.e.
things that can be automatically recreated) whilst "mrproper" removes
everything (including files that may have been customized by the user
such as the config). It would really suck if micropython definition of
"clean" removes files that it cannot reconstruct. That will annoy people
much more!
If you *insist* on tolerating build system bugs[1] then consider copying
zephyr approach and using mrproper for this!
[1] The "make clean" habit is usually a consequence of insufficient
dependency tracking ;-)... although I'll happily concede that the
unconditional link above is an example of over-zealous dependency
tracking.
|
I can reliably paste up to 1k of data into esp8266 paste-mode (it has a 256 byte buffer). |
@daniel-thompson: Thanks for the quick reply, sorry, I went on vacation on missed to reply. Well, it seems that you know/remember how uPy/Z build system works better than me ;-) And I guess the best reply is switching to proper use of "make exports", long overdue: #2980
I see, no response again re: "make clean" trying to build Kconfig ;-). But ok, consider me convinced for next few months still, and I didn't include any "make clean" changes in #2980 (my idea was to make Z's version of clean to be available via "make z_clean", and have old good unconditional clean where up front).
Why not the other way around - make clean cleans, and make-something sub-cleans, and Zephyr adopting it? :-P |
If you want a whole of uPy solution you don't have to copy the mrproper... you could use distclean or pristine instead ;-). That said, IIUC, most of uPy doesn't care about this distinction because the configuration settings are mostly hard coded for each device and therefore zephyr makes things harder because it is a platform rather than a single device (and the unix port doesn't get into these tangles because very few people try to compile features out of the C library to save space). Anyhow, I think the prior art of a variety build systems (autotools, cmake, etc) is on my side in suggesting that "good old clean" is not the name of a rule that nukes things that cannot be reconstructed automatically. Unfortunately what there isn't is total consensus on what the name of a super-clean rule should be :-( . |
|
Hi, aronno@DESKTOP-FHE7SAF ~/micropython/ports/zephyr The cmake-policies(7) manual explains that the OLD behaviors of all -- Found PythonInterp: C:/Users/aronno/AppData/Local/Programs/Python/Python36/python.exe (found suitable version "3.6.5", minimum required is "3.4") -- Configuring incomplete, errors occurred! |
|
The Zephyr port was added some time ago. Further issues with it can be discussed in independent issues. |
I've been working on Zephyr RTOS port for some time now, as part of prototyping/proof of concept work at day job: https://github.com/pfalcon/micropython/tree/zephyr. Over the last week, I met/was contacted by 5-6 people who expressed interest in hacking on it, and actually, there's already a parallel fork (initially based on my branch) which implements more functionality.
My initial concern with Zephyr port was whether I will be able to to support/maintain it going forward, and I got confirmation that I will be able to spend at least some basic time on it as part of my day job. Based on this, I'd like to start gradually spooling my changes to the master, for it to serve as a common base for everyone interested in this port.
The text was updated successfully, but these errors were encountered: