RA Coding standards and contribution

[KRavEN]

Okay, So I've been doing a lot of updates and such on my own code but I'm ready to re-integrate back to the standard RA dev branch on github so I can get updates you guys have been making instead of being off on my own little fork. I would like to contribute to the project. I'm hoping you guys are receptive to this.

Are you okay with the standard github way of doing things? I fork, make my changes, push them into my fork, and then submit pull requests?

I'm using Jan Baeyens eclipse arduino plugin http://blog.baeyens.it/#home. The newest version is working really well for me. To make this work with git I cloned my fork, created a new general eclipse project pointing to the clone folder, and then created a new arduino sketch using the eclipse plugin. Then I add the required RA libraries from the general project via the arduino plugin interface. When I need to push or pull I will do that via the general project. I think this should work out okay.

What I'm wondering is do you have particular set of coding standards you are using for the RA libraries? If so I can setup the eclipse code formatter to those standards and make my life easier.

So far it looks like tabs instead of spaces. Also looks like method and control statement opening braces on a new line. That is what I usually use for my symfony php coding so I'm used to that. I usually do opening braces on the same line with C and javascript though. 6 to one, half dozen to the other, doesn't matter to me, just need to know how you guys want things formatted and I'll submit my pull requests like that.

[rimai]

Awesome!!!
There is no real standard
But we have been trying to be consistent with what you mentioned above.
But, you will see that there are places where spaces were used instead of tabs... So, don't get upset if you see such thing
github is where we keep the repo.
The best approach I think would be this:
Fork the repo.
Fetch the latest dev brach everytime before you start changing to be up-to-date. This is the working branch, where the merges will happen and that's the one that will be merged into master when we are ready to release.
Create a new issue on github.
Create a new branch with the same name as the issue number. For example call the branch issue109.
Make the changes
Submit pull request.
Let me know if this works for you

[KRavEN]

Sorry, I meant spaces instead of tabs!

From what I've seen so far it's mostly spaces with just a few tabs. I prefer spaces instead of tabs if that's okay.

[rimai]

That's fine

[rimai]

I got the pull request and noticed that it was made for merging into master.
The problem is that I have made a whole lot of changes into the dev branch to separate code that is shared among the different controllers and the code that is specific to one controller.
So, when I tried to merge against dev branch, I got a ton of errors.
Also, another thing I noticed is that this library was introduced straight into the base code.
You have to keep in mind that we have the standard RA board, which does not have much memory.
So, things have to be coded as features.
The Arduino IDE we use is a modified version of the official one. The main difference is that we have an auto-detect of features built-in on the IDE.
When you compile/upload a code, the IDE actually scans the entire INO code for keywords and if it finds the keyword, it writes the #define for that feature into ReefAngel_Features.h file.
That file is rewritten on-demand everytime you hit compile/upload.
The entire list of keywords and their #define and description, is located at \Documents\Arduino\update\feature.txt
Let me give you an example:
If you add this line into your INO code:

Code: Select all

ReefAngel.AddDateTimeMenu();

It will trigger the IDE to write this into the ReefAngel_Features.h file

Code: Select all

#define DateTimeSetup

The above line will instruct the pre-processor to include everything that has #ifdef DateTimeSetup.
You will notice that each line in the features.txt file has 3 parts, separated by a comma.
1st part: The #define you want to add to ReefAngel_Features.h file
2nd part: The keyword that the IDE will be searching for.
3rd part: The description that the IDE prints at the bottom log when compiling.
So, your code would have to have something like this in the features.txt file

Code: Select all

SUNLOCATION,ReefAngel.AddSunLocation,Sun Location

Then, you add the AddSunLocation() to ReefAngel class and everytime you are using your library, you must use #ifdef SUNLOCATION
If you don't do that, people with the standard RA will get their code increased, even if they don't want to use this feature.
If you don't feel comfortable doing the #ifdef and creating the feature stuff, that's fine... I can add that in with no problem, but the pull request has to come from the latest dev branch.
Also, if you can make the clean up and the feature two separate pulls, it will make things much easier
The main reason I couldn't merge is because you've made a lot of cleanups and I did too, which caused code comparison to think that everything was changed , so I couldn't determine what was your real code and what was clean up to try to reverse track and manually merge it.

[KRavEN]

Okay, I can do that. I realized after that I branched master instead of dev. I'm re-adding to the dev branch and I'll do another pull request.

I have another pull request for adding BayTech power distribution switch support. I'll modify it to take advantage of the features.txt functionality too. The BayTech switches are pretty cool. They have solid state relays and you can get power usage statistics from them too.

I need to do a pull request for the CIE Luminance methods too.

I'm also working on support for the ENC28J60 ethernet connected via SPI to take the place of the Wifi.

[rimai]

How did you access the SPI bus?

[KRavEN]

On my RA I had planned to use ICSP header and then ATO high for slave select. I've been developing on a standard 2560 board though.

[rimai]

Cool