I found a library that has a conflict with another one.
I know how to solve it, but I wonder how to contribute to GitHub in the right way?
Of course I could create an issue and hope the maintainer reacts to it but, given the number of issues I fear the code could be no longer maintained.
Is there any simple and easy to understand guide how to get properly get started with the whole Git-thing? (Should I branch?) If possible, if an experienced user is willing to support me in getting started with the whole thing (PM?) ?
I use VC2019 combined with Sourcesafe for my own developments. I did write several libaries, so the Arduino / C++ + library aspect is covered.
If you want to go beyond reporting a problem and actually propose a solution, the way to do it is called a "pull request". Issues are for reporting bugs or making feature requests. They are not an effective mechanism for proposing specific changes to the repository content.
Although Git is the foundation of GitHub, you really don't need to know much, if anything, about Git to get started with using GitHub. You can make a simple contribution to a project entirely through the relatively easy to use GitHub web interface.
Git is very complex and a lot of the information you will find about it is not very approachable. Of course, gaining a proficiency with Git is extremely valuable, but if you gate a contribution on the need to be proficient with Git, it might not seem worth the effort. Although a traditional formal approach to this thing would be to learn the fundamentals of Git before ever considering the existence of GitHub, I think a lot of hobbyists and others taking the autodidact approach are jumping right in to doing basic tasks via the GitHub Web interface without any real understanding of what Git is, then once they get hooked by that experience, working back from there to learning the more complex aspects of version control and software collaboration as is required to accomplish their goals. That was my path. In the long run, it is not the most efficient path to gaining proficiency, but the most efficient path is not appealing to everyone, so a less efficient, but more approachable path might be the only way for them.
If you want to start with a more basic tutorial before jumping in to the pull request to the library repository, this is a good introduction to GitHub in general: https://guides.github.com/activities/hello-world
I copy the *.cpp and *.h files into my project (with a different name) to make changes to them.
Yes, as indicated, I know how to deal with the library aspect. Most of the time I first develop them in an environment on my PC where they run in a kind of MFC or WxWidgets test project. Then they move on to a separate file in the IDE and later they end up in the documents\Arduino\Library section.
Sometimes you might give others the opportunity to benefit from your work and then you are confronted with Git I believe.
Related topic:
Licensing:
If you do what you propose and the lib is LGPL, I think you can share/distribute what you made but a reference in the code to the original author seems fair.
But if it is GPL I think you must distribute the source as well in an open manner? In that case I assume but I am no expert that Git is the way to go?
Best regards,
Johi.
Can you give a link to the NeoHwSerial that you use ? Which are the other ones ?
Do you know that the NeoHwSerial in the Library Manager is a fork of the original NeoHwSerial ? I don't / can't / won't understand what the advantages are over the Arduino Serial library.
I don't know about licenses. If you fork someones repository, you get all the files including the LICENSE file. If you keep the same license and work within that, then it should be no problem.
@koepel,
There were several issues back then some minor some more important:
The first one was, if I tied to modify HardwareSerial, then a new release of the IDE, restored the original approach. Could be that there is a way out of this, could be not I de no not know. But for sure changing the original Arduino libs is a bad approach by definition.
Using the NeoHwSerial, this problem is not there.
Then the Profibus DP protocol is a very demanding as far as timing is concerned, Modbus is much easier. The most of the DP implementations rely on Asic's but for me it was a challenge to run it on a Mega in software.
I first started the analysis with a ALTERA DE2-115 FPGA board to timestamp all characters that went back and forth between the CPU and the Siemens IO and then I tried to do the same with the Mega.
This together with some protocol documentation helped me to reverse engineer what was going on.
Then I soon found out, that I needed to use dedicated interrupt handlers to make the whole thing work. Therfore I needed to rely on interrupt handlers. Some of the interrupts are exposed by handers of HardwareSerial, but not all of the Mega Uart capabilities are. One of them I needed to get the timing spot on.
One of my idea's is to further investigate this, and inspired by your reply and certainly the one by @pert, further investigate things and issue a pull request on the original lib. I will see where I and up.
