Contribution Guidelines for Prusa Firmware
Hey everyone,
I've been interested in contributing to the Prusa Firmware hosted here: https://github.com/prusa3d/Prusa-Firmware . However, there doesn't seem to be any contribution guidelines, or any support for people trying to dive in. I reached out on the Prusa Discord, but got no responses. I've got a ton of questions about getting started, but in a nutshell, I'm interested in knowing:
1. Is the repo linked above open for contributions? The extensive backlog of PRs from 2016 suggests that it is mainly an internal development project.
2. Are there resources available about testing modifications to the firmware? Is it safe to test modifications on my daily driver, or are there precautions that should be taken around modifying specific parts of the Firmware to prevent bricking a printer?
3. Several files in the Repo come close to 10k lines of code. I'd be more than happy to help split those up to keep the project manageable and organized. Is there a reason why this specific architecture is important to maintain?
And lastly, is there a more direct point-of-contact for those interested in helping contribute to the Prusa firmware than simply posting on the forums?
Thank you for any help.
Re: Contribution Guidelines for Prusa Firmware
As an outside observer, some of the code is - well - not in very good shape. Too many hands already touching it and not following normal commercial code practices. Also, some of the code comes from other places, e.g the Marlin base, it appears (I don't know this for a fact), keeping it as one huge file helps ensure people aren't breaking parts of it. Regression testing is expensive.
Another aspect is the lore and experience with the limitations in the hardware. Space is limited, and seems collisions in what is needed and what is usable happen and difficult tradeoffs must be made. 50 bytes is apparently enough to make or break the app. Unless you have some code minimization skills, even some assembly skills, this alone may cause issues.
And finally - the question of what experience in controlling hardware do you bring? Resume stuff. Can you describe the Trinamic features of a TMS5100 driver and determine an optimum correction table for a specific motor at a specific drive current?
Again - I have nothing to do with the firmware ... and just popping out some reasons why the landscape is what it is.
Re: Contribution Guidelines for Prusa Firmware
Also, some of the code comes from other places, e.g the Marlin base, it appears (I don't know this for a fact), keeping it as one huge file helps ensure people aren't breaking parts of it. Regression testing is expensive.
I figured that was at least part of the cause behind the base Marlin file...
And finally - the question of what experience in controlling hardware do you bring? Resume stuff. Can you describe the Trinamic features of a TMS5100 driver and determine an optimum correction table for a specific motor at a specific drive current?
Lol, no I certainly don't. I've got about 6 years of software development experience, and the modifications I'd like to attempt shouldn't need to involve any bare metal programming. A feature such as a build queue would be a nice addition, and should be possible while only calling functionality exposed by the base firmware. I'm not applying for a job here, I'm only looking to help out on a project I'm passionate about in any way I can. Certainly that's possible - even for a noobie - without the knowledge you suggested above.
Thank you for your insights.
Re: Contribution Guidelines for Prusa Firmware
An index for a queue may exhaust the available RAM ... uControllers are very limited in such resources, and the Einsy is right up there.
And, if you aren't in a position to understand what one part of the code is doing, the risk of breaking something else rises exponentially because the code is not what you'd call linear. Even IRQ handling looks randomly distributed (to me) and functions break one another if they don't do exactly the right things at the right times. Things like the filament sensor affecting positional and print state ... anyway; kinda-sorta scary to me. lol.
I think people grab their own copy of the code, do their own development for their personal needs, and if they come up with a great idea that they've made work, pitch it as a bug or enhancement request.