Question: status of this project?

[pengi]

Just thinking of the status of this project.

It's a great project, that I'm currently using in my pengi/arm_gdb

But there are both PRs (#100) that I need to fix some problems for me, and also a lot has happened since last release in 2016 that fixes a lot of issues. Also thinking of implementing new features if it would be possible to get merged (#170)

Is it intended to make more releases and get updates?

I'm just asking since I need to take a decision of how I should progress in fixing issues in my tool I'm making. I would like to use, and thus credit, this project. But I also thinking if an option to maintain a fork, which also would reduce the amount of work needed to keep this updated

[tdjastrzebski]

No new MPUs like STM32U5 are added

[pengi]

Yeah, that too. Ether that, or start supporting where there are external archives, since more and more controllers is developed.

That's one thing I was thinking of supporting with #170 to be able to download pack files from ARMs archive directly and just load:
https://developer.arm.com/embedded/cmsis/cmsis-packs

(pack files are zip files containing a lot of documentation, and the .svd file)

In any case, knowing the intention of the project would be helpful.

[VincentDary]

I am also very interested to know the intention of this project. Currently, I'm using this project in various contexts related to embedded system analysis and I plan to use this package extensively in the future.

I think it's better to keep this repository than to fork it, but due to the current situation, I'm also thinking about the fork option. If the only solution is a fork, I suggest we get organized together. Personally, I'm also very dependent on this project, and I'm open to investing time in its maintenance.

I'm currently maintaining a private fork, containing some of the latest pull requests, due to the current lack of support. Particularly since my last pull request #172, which proposes a number of modifications that solve a number of problems related to the current implementation. In my case, without the pull request #172, the tool isn't usable and doesn't meet my needs.

[pengi]

Yeah, totally agree of getting together to maintain one version that works well. I don't mind who maintains it as long as there is an updated version on pypi, that is possible to get bugfixes into.

[BenBE]

I think a good option may be to create an GH organization for this project. That way access to the repo can be shared easily and good access controls can be implemented. Managing the access control on PyPi is another sack of worms entirely, but it should be able to manage that too.

Apart from the plain management side, I think, given the size of the repo, it might be nice to split releases into a core component (just the parsing code) and individual packages per vendor (to keep downloads small and focused). No need to split the repo for that, though separating the main code into one repo and maintaining the SVD files in another one might be an option (related cf. #63).

[VincentDary]

Yes, the GitHub organization is probably the best way to make the transition. About Pypi, there may be an equivalent to test introducing-pypi-organization.

About spliting the code and SVD files, one more time yes, this is probably the first thing to do before publish a new package. Classify by vendor is probably a good idea, but maybe it is not necessary to create python packages, simple hosted tarballs which can be download by the cmsis-svd library is probably easier to maintain... to debate.

[posborne]

Hey all, sorry for the delay here, my Github notifications are pretty busy and things get buried with everything going on. I'm very open to adding more maintainers and potentially working with a set of maintainers to move the repo to its own organization on Github. I've done this with several projects which have moved to the rust-embedded wg.

As far as the python packaging goes, I agree with comments that we are probably best served by just having the python code, without any SVDs, be part of that and look into additional documentation or code to support pulling both from the repo and/or CMSIS packs or similar if they are available.

I will try to spend a bit of time this evening going through a few of the issues for this as it does require some attention short term and also put out a more formal request for additional maintainers.

[VincentDary]

Hello, @posborne, I have created a blank Github organisation cmsis-svd as the name of this tool, I send you an invitation with full access right. I hope this can be the first step towards a new life for this project. If this isn't the way you want to go, I'm also open to another process.

[posborne]

@VincentDary I transferred the repo over, existing references should auto-update with how Github handles that and issues like this one have of course migrated over. In the interim, I've taken over sole admin for the org but have put you on the core maintainer team which should have broad adminstrative rights on the org.

@odinthenerd Has at a time been a maintainer but I'm not sure is still interested in actively serving in that role, but I would like to add other maintainers. I will solicit some other contacts but consider the general window for maintainers to be open if there are others on this thread with a strong interest.

[posborne]

#180 pushes a few critical things to get the project toward where we can drop a 0.5 release to pypi. I'm proposing we move to no longer include the SVD with the python package directly as the size of that package is fairly over-the-top and many consumers may not be using any of the SVDs we distribute as part of the data provided as part of this package.

[ckudera]

Unfortunately, I missed this issue, and I'm a bit late to the party. I'm currently deeply involved in working with SVD files as part of a research project. During this, I've come across problems in the core logic. In my opinion, these issues aren't easily fixed in the existing code — there are problems with dim lists and naming. Also, nested clusters, a new feature in version 1.3 of the CMSIS-SVD standard, are not possible at all. There are some other minor issues as well. Furthermore, the current code doesn't use Python's type annotations and although there are tests, they are not sufficient in my opinion.

These issues, combined with the feeling that this project is no longer actively maintained, led me to develop my own parser. I plan to release it as an open-source project and a PyPi package.

Would you be interested in teaming up on this?

[VincentDary]

@posborne Thank you, yes I have broad administrative rights.

@ckudera, I am interested, how do you plan to organize ? your are not interested to drop a new design here ?

[posborne]

@ckudera Sounds interesting. The parser in tree here was never originally intended to be much more than a reference implementation and I think there's space for other implementations. With the changes to split the python package from the data itself, that may eventually go further to potentially split the python/data into separate repos (needs more discussion).

If there are other maintainers like @VincentDary and yourself (possibly some from other language ecosystems as well) that would find value, I think the org and maintainer set could expand to be a way to support several projects. The main value there would be that with a larger set of maintainers, it might be less likely that a single maintainer loses interest (as has admittedly been the case with me on this project for some time) and negatively impacts the project.

[ckudera]

Sorry, in my last post I forgot an important fact. I just submitted a proposal for a research project and the outlined parser is part of the project. I actually thought that the notification about the project funding would be quite fast, but I got the information today that the decision will be made only in 2-3 months. Until then, I can't publish any code.

However, I can document the limitations I noticed in case this is of interest.

[VincentDary]

Hi, @ckudera, yes, it is of interest, it can contribute indirectly to future improvements.