Skip to content
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.

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

push critical fixes to the core v1 (since core v2 is not always possible to use, due to its overhead, so core v1 still is relevant) #458

Open
jerabaul29 opened this issue Mar 29, 2022 · 4 comments

Comments

@jerabaul29
Copy link

I see that there have been quite some discussions about some issues that have been fixed, and that the fixes have been pushed to the core v2 in a recent pull request.

Would it be possible to push the "critical fixes" to the core v1 too, if / when they are relevant? There are some cases when one does not want to pay the memory and CPU overhead of using the MbedOS RTOS (spoiler: I am one of these people), and then the baremetal core v1 is the one to use. As the core v1 does have some use cases that are not covered by core v2 (ie when the overheads of the v2 are too expensive), it would be great that, even if the core v1 does not undergo further development, at least it gets bugfixes :) .

@Wenn0101
Copy link
Contributor

Wenn0101 commented Mar 29, 2022

This is where some of the difficulties of maintaining 2 versions can really come back to bite you. It is hard for me to keep track of which fixes are even relevant to the v1 core (since many parts of the v2 core utilize mbed or were re-written when the v2 core was made), and it is a bit of a judgement call which fixes are "critical" fixes.

I am always happy to review a PR into the v1 core, and will make sure I keep a better mind out for which changes may also affect the v1 core.

Are there any specific changes you were hoping for the v1 core?
I am trying to think of a better way to track issues for the v1 core. Perhaps I will create a discussion topic on the matter, or I maybe just open a new repo solely for tracking the issues.

@jerabaul29
Copy link
Author

I wonder is some of the I2C / SPI issues that were fixed on core v2 are actually also on core v1. @nigelb @adamgarbo ? :)

Agree, this is where switching to MBedOS v6, which can be used with both an RTOS and a bare metal profile, while sharing code and components, may make things much easier :) .

@adamgarbo
Copy link
Contributor

Hi @jerabaul29,

Thanks for creating this issue. I'm exclusively using v1.2.3 of the core these days, as I don't believe v2.x is yet stable enough to rely on for my research.

I'm currently not aware of any critical I2C/SPI issues on v1.x. As far as I know, these were specific to Mbed/v2.x.

That being said, I'm sure there are likely a few minor housekeeping issues that could be addressed in v1.2.3 @Wenn0101 if you're happy to get a v1.2.4 candidate going.

Cheers,
Adam

@jerabaul29
Copy link
Author

Thanks @adamgarbo :) .

Yes, agree with you regarding core v1 vs core v2. Interesting to see that we are at least a couple of "heavy duty semi professional users" who prefer to stick to v1 :) .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants