Refactoring branch feature requests

[TD22057]

I'm looking forward to the results of the refactoring. So far it looks really nice. I thought it might be nice to capture any ideas people had for improvements to the system.

A big problem is the arduino IDE and it's re-writing of the code. That makes it difficult to have things like #defines before include files which is one good way to have local definitions of things. I use this technique http://gammon.com.au/forum/?id=12625 to get around that. It looks like maybe this is being addressed in the branch but I wasn't sure.

Right now, I'm in the hack/prototyping phase but I'm starting to think about my real build/deployments and how I want to manage the software for my various nodes. I think there are three levels of software that may need different types of management.

1. MySensors libraries. This will be the version of MS that I have on my nodes. It should be the core libraries, RF code, etc.

2. Site specific configuration. This contains the information that is common to all of my nodes. Things like network channel, encryption keys, etc.

3. Node specific configuration. This contains the information that is specific to the hardware/software of a single node. Pin identifiers, LED control, radio information, SOFT_SPI, etc.

Right now, a lot of these items are mixed together in a single file (MyConfig.h) which makes it more difficult to CM the site specific information and the sensor specific information in a nice way. I'm planning on running these nodes for several years (hopefully with no updates) once I deploy them and I need to insure my CM system has a record of exactly what was sent to each one in a way that I can understand when I'm not in the middle of working on them.

For example, I'm never going to remember to edit SOFT_SPI for my gateway in the common area when building it. I know to do that now, but, 3 years from now I won't remember any of this. So whatever we can do to make node specific configuration data in the node code would be an improvement.

Here's an example of what I'm thinking I'd like the code for a single node to look like:

// Define the hardware configuration for this node
#define MY_PIN_OTA_FLASH_SS 7
#define MY_PIN_RX_LED 4
#define MY_PIN_TX_LED 5
#define MY_PIN_ATSHA204 16
#define MY_PIN_SPI_MISO 15
#define MY_PIN_SPI_MOSI 16
#define MY_PIN_SPI_SLK 14

// Include site specific data (encryption keys, etc)
#include "MySiteConfig.h"

// Include the MySensors classes
#include "MySensor.h"

// setup(), loop() go here

Some of the examples in the refactoring branch look like they're doing something like this but I wasn't sure so I thought I'd post this for discussion.

Thoughts? Any other ideas for improvements to the infrastructure?

[hek]

The idea is that MyConfig.h just sets the default values (that not has been set by sketch). It checks this with #ifndef and never overrides anything previously set.

So you can have your own "MySiteConfig" include with your common node information.

I might rename/move the current MyConfig.h to a /core/MyDefaultConfig.h and leave an empty MyConfig.h in the root for common user overrides specific to users need.

[TD22057]

@hek I'm designing a main board and am going to have a single LED which may end up on an output shift register. I've been looking through the dev branch and I can't figure out how I would override the existing LED blinking behavior with a custom function of my own. It seems like I can have it either enabled or not but I can't figure out how I would write a custom blink routine other than removing the existing ones and re-coding them to be my own. Is that the best way to handle this case or am I missing some other way?

Thanks,
TD
ps: General question on the dev branch: It seems like the new system is hiding a lot of the code (which is good for new people, maybe not so good for people who like to access that stuff) and different implementations are provided via global variables in the library (rather than the sketch), free functions and #define's control which get used. Providing different implementations with a common API is pretty much what object oriented design was built for so I'm curious if you considered using a system of interfaces and derived classes for different implementations for this? (I'm not trying to criticize - just trying to understand).

[hek]

The blinking code takes place in MyLeds.cpp.

We used c++ interfaces/class structure in 1.5. It surely has its advantages. But the "executable" gets much larger than using plain c. I'm used to servers with Gb of memory from my day job, so it has been a journey for me to get used to these small embedded systems. Realising their constrains (memory vise) has led up to where we are now.

The new #define-based configuration in the dev branch is the only way I've found to control/include different parts of the system and have it easy accessible from the sketch itself (which also applies using in the CodeBender browser plugin). And yes, the whole idea with this project is to make this Electronics/DIY world easy for the newbies. The hard-core programmers always find their own way of doing things

But you should still be able to access (even more of the core) now that most of it is plain c. Worst case you have to extern declare things to access "hidden" things from sketch.

[TD22057]

Thanks - that makes sense. It's probably short lived - micro processors are coming with more and more memory all the time so in a few years it won't matter at all for most things.

Regarding the LED's - so does that mean the "approved" way to handle that is to just go in and edit the MyLeds.cpp file? I was hoping to avoid editing anything in the MS library because it becomes very hard to track source code configurations between different builds.