Is setup() being called even when the STARTUP() macro is used?

Cloud
1

Hi there. I was digging around in the documentation today, and noticed the Wifi.selectAntenna() call. A couple of my devices are equipped with external duck antennas, and I hadn’t realized that it must be selected manually. So I added the following right before the setup() method declaration:

STARTUP(WiFi.selectAntenna(ANT_AUTO));

Compiling the code and re-flashing the device worked fine, and it comes online shortly after. I have two of these devices with duck antennas, and I re-flashed both (running different code), and one of them seems to work like before, but on the other device, the variables that I’m monitoring don’t seem to be updated after I re-flashed the board. I’m not near the device so I can’t troubleshoot through the serial port. Is there any way of logging any potential errors in the setup() or loop() functions to the cloud? Does the firmware automatically revert to the internal antenna if for some reason the selectAntenna() call fails? Thanks.

2

To the question in the title: "Yes, setup() will be called with or without STARTUP() being set or not"
Next WiFi.selectAntenna() is a “sticky” setting. So even if you don’t set it again after you had set a specific type, the next time that antenna will be used again (or ANT_AUTO will do its job).
I’d recommend explicitly selecting ANT_EXTERNAL or ANT_INTERNAL as ANT_AUTO used to play up sometimes (might be corrected by now, but I usually know if my devices have an ext antenna or not ;-))
Having said this, that should also answer the “fallback” question. If a subsequent selection attempt fails, the previous setting will persist.

And finally unfortunately there is no remote-debugging unless you programmed it into your code.

1 Like
3

Thanks @ScruffR. Yeah, I guess I could have picked a more descriptive title :smile:
I’m wondering if for some reason using the STARTUP() macro somehow makes something else in my code fail? The particular board that is having problems is mounted to one of the SparkFun OLED breakout boards and I’m using a couple of external libraries for the OLED and a DS18S20 temperature sensor.

// This #include statement was automatically added by the Particle IDE.
#include "spark-dallas-temperature/spark-dallas-temperature.h"

// This #include statement was automatically added by the Particle IDE.
#include "OneWire/OneWire.h"

// This #include statement was automatically added by the Particle IDE.
#include "SparkFunMicroOLED/SparkFunMicroOLED.h"

// Make sure to use the external antenna
STARTUP(WiFi.selectAntenna(ANT_EXTERNAL));

char line[10];
// Connected to pin 4 on the Maxbotix. Normally low. When high, it enables the sensor. 
// Currently not used.
int enablePin = D3;
MicroOLED oled;
int startPos = 0;
int yCursor;
int FONT_TYPE = 0;

#define ONE_WIRE_BUS D2
OneWire oneWire(ONE_WIRE_BUS);
DallasTemperature sensor(&oneWire);
// Used as a 3.3V power source for the pullup resistor for the DS18S20 1-wire pin.
int pullupPin = D6; 
int waterLevel = 0.0;
double temperature = 0.0;
char resultstr[64];

void setup() {
    // pinMode(enablePin, OUTPUT);
    // digitalWrite(enablePin, LOW);
    pinMode(pullupPin, OUTPUT);
    digitalWrite(pullupPin, HIGH);
    Serial.begin(115200);
    Serial1.begin(9600); // Serial port for Maxbotix
    sensor.begin();
    oled.begin();    // Initialize the OLED
    oled.clear(ALL); // Clear the display's internal memory
    oled.display();  // Display what's in the buffer (splashscreen)
    delay(1000);     // Delay 1000 ms
    oled.clear(PAGE); // Clear the buffer.
    oled.setFontType(FONT_TYPE);
    printTitle("init", FONT_TYPE, true);
    delay(1000);
    yCursor = 0; // Reset Y axis cursor to start printing from first line. 
    Particle.variable("Temperature", temperature);
    Particle.variable("WaterLevel", waterLevel);
}

void loop() {
    oled.clear(PAGE);
    sensor.requestTemperatures();
    double tmpTemp = sensor.getTempCByIndex(0);
    
    // Sometimes the sensor returns strange negative values, so just discard those.
    if (temperature < -50) {
        return ; 
    }
    
    temperature = tmpTemp;
    sprintf(resultstr, "T:%.2fC", temperature); 
    Serial.println(resultstr);
    printTitle(resultstr, FONT_TYPE, false);

    if (! readMaxbotixSensor2(line)) {
        Serial.println("Nothing to read from Maxbotix");
        printTitle("W:R-err", FONT_TYPE, true);
    } else { 
        printTitle(line, FONT_TYPE, true);
        Serial.print("Distance is: ");
        Serial.print(line);
        Serial.println(" cm");
    }
    
    delay(2000);
}
4

Now this is really bizarre. If I move the Particle.variable() calls to the top of setup(), things work. Of course, since I’m not where the device is, I can’t see if the OLED display is working. But I get proper reads from the variables now. I guess maybe something in the OLED init code fails?

5

That's not that bizzare once you know that registration of Particle.variable()s/Particle.function()s has got a time frame.
And doing extra stuff before that consumes some of that time.

1 Like