search

robert-hh / micropython

MicroPython - a lean and efficient Python implementation for microcontrollers and constrained systems
https://micropython.org
Other
14 stars 4 forks source link

w60x port README.md updates/clarifications based on experience building from scratch #17

Closed LexxM3 closed 1 year ago

robert-hh commented 1 year ago

I'm not sure about the note for the compiler version. That's what I get:

~/Downloads/MicroPython/micropython/ports/w60x$ arm-none-eabi-gcc --version
arm-none-eabi-gcc (15:8-2019-q3-1+b1) 8.3.1 20190703 (release) [gcc-8-branch revision 273027]
Copyright (C) 2018 Free Software Foundation, Inc.
LexxM3 commented 1 year ago

I don't think that's the compiler your README.md references and links to. I strictly followed your documentation, both the link and the statement that 4.x was the latest supported by the SDK. Those aren't my changes to the notes, those are original and the instructions I followed.

Did you actually end up using a more modern cross compiler regardless the README.md documentation? That might explain the 64 vs 32 bit thing. I'll investigate that path further tomorrow.

robert-hh commented 1 year ago

The version 8 is my default, that came with the debian OS. I installed as well manually Version 10.3, 11.2 and 11.3. All expect for version 11.3 allow building the w600 port including the WM_SDK. But V11.3 has hiccups with other port as well. The README.md file is old, and I do not recall having touched it. The git data is Apr 2020. I started working on the port at about that time. Edit: Most of the time I use Version 10.3 by adding that path in a GNUmakefile.

LexxM3 commented 1 year ago

Ok, I think I am now understanding the state of all of this better. It wouldn't have really changed anything, but for some reason I had inadvertently assumed this was cleaner and more figured out than it is. That's ok and what you've done already is critical. I'll spend more time with the compilers, SDK, and Makefiles and will try to bring the instructions up to more modern accuracy.

This would be easier to keep modern going forward if the w60x port was part of the core MicroPython development and the regular release image generation. Have you discussed that with the maintainers? What would that take?

One does wonder if Winner Micro has abandoned the device, however (and the w8xx devices aren't even Arm). How do we get them to actually respond and tell us whether that's the case? Because if they've stopped fabbing silicon and what's out there is just last remaining stock, then no wishful thinking or software support would matter.

robert-hh commented 1 year ago

Thanks a lot that for your work to make things more consistent. I do not know how many people use that port at all, of if people just take the prebuilt binaries. It is a great help.#

This would be easier to keep modern going forward if the w60x port was part of the core MicroPython development and the regular release image generation. Have you discussed that with the maintainers? What would that take?

The maintainers had been asked by Winner if the would integrate this port into the main line, and it was rejected. See: https://github.com/micropython/micropython/pull/4679 Partly because Winner did not want to promises long term support for the SDK & port, partly because the structure of this port is and was very different to the other ports and would have required a lot of review/change iteratioms from the maintainer and Winner. That's the reason why I did not make an attempt to do so. The maintainers know that the port exists.

One does wonder if Winner Micro has abandoned the device

I do not know it it is still manufactured. But I got a note that there is no further development for the product.

About you PR: I changed a few files, so there are conflicts now. If you changed only README.md, I can take just this files and merge it.

LexxM3 commented 1 year ago

About you PR: I changed a few files, so there are conflicts now. If you changed only README.md, I can take just this files and merge it.

Yes, I only updated the README.md, so you can just grab that and I'll sync my fork to yours afterwards. Attached for convenience. While I now know that the README.md is not really fully modern, it is better than previous version and its instructions as stated do work today, so I think it is worthwhile to incorporate as is for now, and keep in sync later with the modernization effort. README.md

robert-hh commented 1 year ago

A few notes on the README:

LexxM3 commented 1 year ago

The maintainers had been asked by Winner if the would integrate this port into the main line, and it was rejected. See: micropython#4679 Partly because Winner did not want to promises long term support for the SDK & port, partly because the structure of this port is and was very different to the other ports and would have required a lot of review/change iteratioms from the maintainer and Winner. That's the reason why I did not make an attempt to do so. The maintainers know that the port exists.

I do not know it it is still manufactured. But I got a note that there is no further development for the product.

I've gone through that thread and I don't think I get quite the same vibes as you do. True enough that WM did not appear to generate sufficient effort to demonstrate their commitment to the port, but I didn't get a sense the lack of commitment was explicitly stated.

In any case, wdyichen responded to my rather direct question to him and WM on that thread just now and his assertion is that WM is still manufacturing and still "supporting" the chip. That's better than nothing, although yes, it would now be valuable to get some details on those plans to see if they are credible. But it might be enough of a "commitment" for a hobby i.e. separate port that you've started and are maintaining.

LexxM3 commented 1 year ago 
* I'm pretty sure that the note about requiring the 4.x version of arm-none-eabi-gcc is wrong. I never needed it, and compiled ot today with version 10.3 and 11.2. Version 11.3 failed.

I've now also tried all of v4.9, v9, v10.3, v11.2 -- all these work, but interestingly, the image gets bigger with each newer version. And I also confirmed 11.3 and 12.2 don't compile, bit it seems that it wouldn't be hard to fix up in the SDK with a some attention if there is interest.

So yes, the note re: 4.x is inaccurate/incomplete, but at least it doesn't lead someone trying make a new build environment astray either.

robert-hh commented 1 year ago

Damien is usually very polite. But still the repository would require a huge rework. It is for instance required that there are no compiler warnings in the build process. The SDK compile creates tons of them. Anyhow: I will keep the port recent, as long as it is not too much work. Please stay tuned as well. About the compiler note: If it is not required, it should either be dropped or changed in a way, that the compiler version 4.x is recommended, but newer versions work as well. b.t.w.: you mentioned that the binary got larger with every version: What are the numbers? I had with other ports the opposite experience in that newer versions created smaller code. Not huge differences, but reproducible.