Skip to content

Conversation

ToSa27
Copy link
Contributor

@ToSa27 ToSa27 commented Sep 28, 2014

Split Application and Driver to simplify integration of other radio modules
Slightly Reduced Bootloader Size
Accept Time Broadcasts

changing few uint16 variables to uint8
NodeJsController sending Time broadcasts every few minutes.
Sensor accepting not just Time messages addressed to the specific
sensor.
@bblacey
Copy link
Contributor

bblacey commented Sep 29, 2014

ToSa27, why did you elect to remove the RF24_PA_LEVEL_GW from MyConfig.h https://github.com/mysensors/Arduino/pull/36/files#diff-4 ? We have seen cases where users need to use a different PA level for amplified high-gain radios on the gateway.

@henrikekblad
Copy link
Member

Thanks for the PR.

MQTT/Ethernet gateway uses other SS/CE gpios than serial and sensors (Ethernet library has "hardcoded" pins with conflicts with the default 9/10 we use).

One proposal is to change the default pis used by the library so that we don't have any conflict with Ethernet any more. Only problem is if people have designed their own boards they have to change their MyConfig setting back to the old values.

@ToSa27
Copy link
Contributor Author

ToSa27 commented Sep 29, 2014

@bblacey
Very valid point – the issue is that these settings are very radio module specific. So far the RF24_... defines were used in the sketch and that’s where either the “normal” or the “gateway” define was used based on the type of sketch.

For simplicity I would propose something like the defines below in “MyConfig.h” and then a check in the sketch that throws a compile error if e.g. in the serial gateway sketch the define is not “MYSENSORS_SERIAL_GATEWAY”…

// pick ONE of these - other board layouts can be easily added this way
#define MYSENSORS_SENSOR
//#define MYSENSORS_SERIAL_GATEWAY
//#define MYSENSORS_ETHERNET_MQTT_GATEWAY

#ifdef MYSENSORS_SENSOR
#define MYSENSORS_RF_NRF24
#define RF24_CE_PIN 9
#define RF24_CS_PIN 10
#define RF24_PA_LEVEL RF24_PA_MAX
#endif

#ifdef MYSENSORS_SERIAL_GATEWAY
#define MYSENSORS_RF_NRF24
#define RF24_CE_PIN 9
#define RF24_CS_PIN 10
#define RF24_PA_LEVEL RF24_PA_LOW
#endif

#ifdef MYSENSORS_ETHERNET_MQTT_GATEWAY
#define MYSENSORS_RF_NRF24
#define RF24_CE_PIN 5
#define RF24_CS_PIN 6
#define RF24_PA_LEVEL RF24_PA_LOW
#endif

#ifdef MYSENSORS_RF_NRF24
#include "MyDriverNRF24.h"
typedef class MyDriverNRF24 MyDriverClass;
#define RF24_CHANNEL 76 //RF channel for the sensor net, 0-127
#define RF24_DATARATE RF24_250KBPS //RF24_250KBPS for 250kbs, RF24_1MBPS for 1Mbps, or RF24_2MBPS for 2Mbps
#define RF24_BASE_RADIO_ID ((uint64_t)0xA8A8E1FC00LL) // This is also act as base value for sensor nodeId addresses. Change this (or channel) if you have more than one sensor network.
#endif

@ToSa27
Copy link
Contributor Author

ToSa27 commented Sep 29, 2014

@hek
Similar answer to the PA_LEVEL_GW discussion – if we want to keep the base code driver/hardware agnostic to e.g. support other radio modules in future, this type of setting can’t be driven by the sketches. Crazy example: think about an RF module that is connected via serial rather than SPI. Function parameters in the MySensor constructor like “CE-PIN / CS-PIN” don’t make sense but we would want to use the same sketches without rewriting all of them…

The easiest way to keep these settings away from the real code would be a more complex MyConfig.h that takes care about different board layouts. We could even create separate header files for each “board layout” and then include the one appropriate for the given build process (similar to what Arduino IDE does). See code snippet in reply to @bblacey ...

Adjusted all Gateway examples but only one sensor example so far
(DallasTemperature). Other sensor examples should get the same three
lines added (not mandatory but helps avoiding unnecessary debugging when
selecting the wrong setup)
@henrikekblad
Copy link
Member

If we NOT should have the same pin-assignements for both ethernet and normal sensors (what is your opinion on this?) I think we at least could afford to have separate set of defines for the Ethernet+MQTT-gateways. People will most certainly forget to go into MyConfig and uncomment the right define-statement when compiling their gateways.

Couldn't the MyDriverNRF24-constructor still take CS/CE arguments and default to RF24_CS_PIN /RF24_CE_PIN. But in Eth/MQTT they get overridden.

Would it also make sense to move all the NRF-config to MyDriverNRF24.h?

@ToSa27
Copy link
Contributor Author

ToSa27 commented Sep 29, 2014

Have a look at the additional commit. The three lines in e.g. EthernetGateway.ino ensure that the define is updated accordingly - otherwise the compilation fails with an appropriate error that guides the user immediately to MyConfig:

#ifndef MYSENSORS_ETHERNET_MQTT_GATEWAY
#error Please switch to MYSENSORS_ETHERNET_MQTT_GATEWAY in MyConfig.h
#endif

https://github.com/ToSa27/Arduino/commit/2647345c4def221e19a7de67b5622ea5fa162533

@henrikekblad
Copy link
Member

Ahh ;) missed that one.

@ToSa27
Copy link
Contributor Author

ToSa27 commented Sep 29, 2014

Missed your second point - I'll move the nrf24 specific defines to the driver to reduce the complexity of the MyConfig.h file.

@henrikekblad henrikekblad merged commit 2647345 into mysensors:development Oct 22, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants