dominicclifton wrote:tovrin wrote:What is to stop us from taking a page from his book and creating our own fork
Nothing, and git and github encourages this. However, rather than just merging into a new codebase from baseflight why not contribute to baseflight? As a baseflight developer I'd be happier if we all worked together to improve the overall quality of the code and thus the finished product rather than having another fork?
That would be great but unfortunately every project lead has their own ideas of direction and understandably so. The STM32 landscape is so fragmented right now it's confusing. There's baseflight, Harakiri, Taulabs, jihlean's FF32 work, multitudes of forks, support for the F3/F4 variants, etc. Finding a good project to stick to is not easy. One thing I like about Baseflight is the quality of dev's involved in the project and the group having a priority of ensuring only quality code gets included and it uses the right mechanism for devs to collaborate on it (using Git correctly). Not sure I'm impressed with the project lead's people skills but that's a minor point (<ducking behind my desk> ) Harakiri on the other hand, I'd love to try it more as it adds more features that could be fun to play with. But the way it's development collaboration is done and lack of any version control scares the sh.t out of me! Collaborative patches/updates done via upload to a form? A new repository for each development branch? yikes. It is his fork and he can do what he wants of course. I wish him all the best with it though. It has potential but I'll wait till it matures. Taulabs is overly complex and overkill for a simple controller IMHO and semaphores scare me
Awesome work that you are doing with the softserial code and adding more ports to the port starved little F1 board F3/F4 would solve that by adding more usarts but then that adds more cost and complexity to the little FC that could