Best practice for multiple target projects

[thatguy-jaysenodell]

This may be an esoteric problem that I'm creating for myself (meaning I will accept an response of "not a Sloeber qustion, go bother eclipse people").

I have a multi-device project (3d printer enclosure lighting, heating, ventilation, automation). I'm using varying micros and varying "boards" (several I'm building from scratch) on the project. So far I have been using multiple projects within a workspace for each unique target. As my project is growing I'm trying to manage my project/code under a single project for each functional group (lighting project, heating, etc). In a nirvana state, this all lands in git as a single repo.

Because target boards are defined at the project level, the only way I see to manage this as single code set is starting with a generic C++ project then add sub-projects for each parent function, then the Sloeber projects as sub projects to these subprojects. The tree would look something like

Enclosure (c++)
|- Lighting (c++)
|-- frontend (Sloeber esp)
|-- controler (Sloeber avr)
|- Ventilation (c++)
|-- fan controller (Sloeber avr)
|-- sensors/comm (Sloeber avr)
|- etc (c++)
|-- sub 1 (Sloeber unk)
|-- sub 2 (Sloeber unk)

Is there a "better way" to do this? I'm not seeing a different way but ... I figure asking is better than not.

Thanks!

[jantje]

Because target boards are defined at the project level,

Nope
Target boards are defined at the configuration level,

What I do is create a new configuration for each "target" and use defines where the code is "target specific"
You can create as many configurations as you want but you can only have one active configuration at the time.

Note that switching configuration may mean

1. adding new libraries
2. removing libraries
3. pointing to different libraries

This process is error prone in the current Sloeber. It is one of the things I'm trying to improve in the new version I'm working on.

[thatguy-jaysenodell]

To make sure I understand the idea..

Use ifdef in code such as this bad example

#ifdef esp
#include espdefault.h
#else
#include arv.defaults.h
#endif

void setup(){
  #ifdef esp
   espDefaultBegin(); // assume this is in the espdefault.h/cpp
  #else
   avrDefaultBegin(); // assume this in the avrdefault.h/cpp
  #endif

  OUTPUT.println("Setup complete");
} 

void loop() {
  // stuff
}

Then setup an AVR config and an ESP config where I set those defines in the gcc command line as well as we up the board type.

If I move all the core networking components out to separate files that would get me most of the way there. I'm pretty tight on memory in the AVRs but this "shouldn't" add any additional code unless I mess something up. This is an interesting idea!

[jantje]

That is basically it yes.
However I prefer business level defines and I instantiate classes (that implement a interface) as global variables for the hardware components.
That way "the code" remains mostly the same.

For instance this is a extract from my mowrobot

#elif defined MOWER_PWM
#include "MotorPWM.h"
#define MOWMOTOR_SPEED_PIN  9
#define MOWMOTOR_DIRECTION_PIN 13
#define MOWER_AMP_PIN A14
#define MOWMOTOR_ENABLE_PIN A12  //HIGH = DISABLED LOW = ENABLED
#define MOWMOTOR_ENABLE_ENABLED HIGH //HIGH = DISABLED LOW = ENABLED
#define MOWMOTOR_SERIAL_REGISTER F("Mower.Driver")
MotorPWM myMowMotor(MOWMOTOR_SPEED_PIN, 0, MOWMOTOR_DIRECTION_PIN, true);
CurrentSensorAnalog myMowAmpMeter(MOWER_AMP_PIN);

#elif defined POT_MOW_MOTOR
#include "DigitalPotmeterMCP413.h"
#include "MotorPotmeterDirection.h"
#include "CurrentSensorAnalog.h"
#define MOWMOTOR_ENABLE_PIN A12  //HIGH = DISABLED LOW = ENABLED
#define MOWMOTOR_ENABLE_ENABLED LOW //HIGH = DISABLED LOW = ENABLED
#define MOWMOTOR_DIRECTION_PIN A13
#define MOWMOTOR_SPEED_SLAVE_PIN 49
#define MOWMOTOR_AMP_PIN A14
DigitalPotmeterMCP413 myMowDigitalPot(255, MOWMOTOR_SPEED_SLAVE_PIN, true);
CurrentSensorAnalog myMowAmpMeter(MOWMOTOR_AMP_PIN);
MotorPotmeterDirection myMowMotor(MOWMOTOR_DIRECTION_PIN, myMowAmpMeter, myMowDigitalPot);
#define MOWMOTOR_SERIAL_REGISTER F("Mower.Driver.pot")

As you can see here I have a implementation of a motor that is driven by PWM and one with a potmeter (I have plenty of others)
If I add -DPOT_MOW_MOTOR on the command line the code will use the potmotor (and include the MotorPotmeterDirection headers) but more importantly create the global variable myMowMotor
MotorPotmeterDirection myMowMotor(MOWMOTOR_DIRECTION_PIN, myMowAmpMeter, myMowDigitalPot);
If however the comand line contains -DPOT_MOW_MOTOR the code will create a different myMowMotor
MotorPotmeterDirection myMowMotor(MOWMOTOR_DIRECTION_PIN, myMowAmpMeter, myMowDigitalPot);
But because they have the same interface (which I do by using a interface class -but that is not needed-) simply changing the global variable is all that is needed.

And this is what the loop looks like

uint32_t loopMillis;
void loop()
{
    loopMillis=millis();
	myCommunicator.loop();
	myRobotSensors.loop();
	MyDriveMotorEnable.loop();
	MyMowMotorEnable.loop();
	myMower.loop();
	TheSkidDriver.loop();
	MyRCModule.loop();
	MyGPSModule.loop();
	MyPowerManager.loop();
	myBrains.loop();
	myPlayer.loop();
	//ApplicationMonitor.IAmAlive();
}

It is that easy because all my classes have a setup and a loop method. Of course this means you can not use delay but it also means reuse is very easy.
There are only 3 robot specific classes here

• myRobotSensors
• MyPowerManager
• myBrains

myRobotSensors is just because I grouped a couple of temp meters together with some settings (ok; turn on fan; to hot)
MyPowerManager is very similar but for the battery.
myBrains is a variable I have in nearly all my programs. Here is where the specific program logic resides.

loopMillis is something I use so all time triggered actions use the same timestamp.

As you can see I normally never change a value on the set call. I save it and set it during the loop.
https://github.com/jantje/ArduinoLibraries/blob/2948767a3a8c0bd42976e86139b94381f61ff0e6/MotorBLDC/MotorBLDC.h#L54
And yest many of these libs are public domain ;-)

[thatguy-jaysenodell]

That's exactly was I was thinking in my "bad example". Note that OUTPUT as I'm using it here, is currently defined in each header to be Serial, Telnet or some other method that handles print, println, and a simple printf. My one thought is that my loop() will be very unique for each system though. The ESP systems are primarily managing direct HID, HTTP. REST and telnet interfaces while the AVR are managing realtime tasks (thought the ESP RTOS would be more logical, I need the AVR ability to manage the IO timing tightly for ws2812 strips).

The real code set is already delay-less and runing state machine style (some interupt driven for door switches and themal safety). It was because of the timing sensitivity of several components I needed to segregate the frontend code from the real work. the esp8266 couldn't manage the WiFi + LCD + ws2812 without messing up the ws2812 timing. My move was to just slide the anything that needs the LED classes to an AVR and let things be happy.

Let me see how I can get this working for my little project. Thanks again for both Sloeber and the help with my questions.