Gpio config from board to chip

[CezaryGapinski]

Changes related to discussion about enabling GPIO's clocks on chip::lowLevelInitialization() level and configuration via KConfig menus.

[FreddieChopin]

This is what I was talking about (; Conflicts... (;

I'll try to rebase the changes locally and see how well that goes.

[FreddieChopin]

Hello Cezary!

Please take a look here https://github.com/DISTORTEC/distortos/tree/CezaryGapinski-GPIO-Config-from-Board-To-Chip and let me know whether you accept the changes that I've made to your commits (you're listed as the author of all the changes).

Basically I've cleaned that up, rebased on top of master (actually with a git reset --mixed + new commits), fixed coding style (tabs, spaces, trailing whitespace, consistency, ...) and divided the commits to be more "logical" (at least according to my own logic [; ). I hope that's OK with you... Personally I prefer the commits to be as small as possible (with one "logic" change for single commit).

The data about which GPIOs are available for particular chips was taken from CubeMX's .xml files, as the info you've implemented was not completely correct.

If you're OK with what I've done, I'll merge that as soon as possible.

[CezaryGapinski]

What I can say... Next time I just try to make my changes in cleaner way. Thank you for your effort, now it looks more logical.

[FreddieChopin]

Well, you can say many things - for example that you don't like my attitude and that I should reevaluate my behaviour (; I know that I can be tough to cooperate with, so if you think my arbitrary "rules" are just stupid then say so!

[CezaryGapinski]

This is a very good rule :)! I'm still curious how did you create that merge? In first step you rebase it to new branch CezaryGapinski-GPIO-Config-from-Board-ToChip from master HEAD and then create the new commits based on my branch? I'm still one of the authors but commits are totally different... How do you do these commits? I would like to do the same with board_script branch, and it would save me many hours to searching for the answers.

[FreddieChopin]

One more thing - it would be good to also cherry-pick (or create a separate commit) the change where you remove the number of buttons/LEDs from the Kconfig files and generate that automatically as the last enum value.

An ideal situation - according to my own idea of course (; - with the generateBoard.py script would be if we could have a history more-or-less like that:

1. all the changes directly in distortos files to make them friendly for your script
2. the changes which add the script itself, its templates, integrates that with Makefile and so on
3. regeneration of all the board files

Now the most desirable thing here is that step 3 would only have very minor cosmetic changes to the files (maybe some formatting, changes in comments, ...), but no "functional" changes. To do this, we would have to manually make the files match the generated output - so step 1 above is generally about manual introduction of the changes required for step 3 to be as small as possible.

This will also simplify keeping the examples in sync, as currently they actually depend on the number of LEDs being a preprocessor macro. Having all the changes in the source as soon as possible would give me more time to implement the necessary modifications in other repository.

[FreddieChopin]

I'm still curious how did you create that merge? In first step you rebase it to new branch CezaryGapinski-GPIO-Config-from-Board-ToChip from master HEAD and then create the new commits based on my branch? I'm still one of the authors but commits are totally different... How do you do these commits? I would like to do the same with board_script branch, and it would save me many hours to searching for the answers.

Well... to be honest changes like that are very hard to rebase, that's why in this particular case I just took a shortcut and cheated a little bit. Your change was very hard to rebase because it had multiple conflicts with other changes that I've made in the meantime. But with the shortcut it was not that bad.

The first thing I did was git reset --mixed <commit-hash-on-which-your-branch-was based>. This effectively leaves all the modifications that you did in your branch, but erases the branch history. You can think of it as checking out the exact base commit which you used, deleting everything and pasting the files from your branch.

From there I've removed some changes which were not strictly necessary (all changes to distortosConfiguration.mk files, as these are generated automatically anyway, and all changes to Kconfigs for chip families, as they were not complete) and fixed whitespace issues. Now I stashed all these changes, checked out master branch and applied the changes doing a simple merge of conflicts (I don't remember now whether there were any). With your changes applied on top of master I've just recreated commits using your user name an e-mail.

It would be also possible in other ways, but it was much simpler that way. That's why I hope you're OK with what I've done, because - as you noticed - the commits are pretty different.

And that's one of the main reasons why I would recommend frequent merges in small parts - conflicts are unavoidable in such project (early stage of development, so a lot of changes in a lot of places), so when the change is small and focused it's much easier to rebase it and solve any potential conflicts.

When working on your own branches you can alter them in any way you like (either with mixed reset + new commits or by using interactive rebase), when you do that you can just do a "force push" of the new version of the branch to github, overwriting the previous one. I hope you won't get discouraged by the conflicts which you'll undoubtedly face during your rebases - if you have any problems, don't hesitate to contact me, I'll try to help.

Anyway - the script thing will be easier, as I think that we don't need the history of all your modifications to the main idea - it would be possibly enough to create one commit just adding new files (or several commits with new files, grouped in some logic way). There's also absolutely no point in trying to merge conflicts for generated files. As your change will be mostly that - bunch of completely new files + files that are generated automatically - it will be probably easier to recreate the commits when you're done with all the modifications.