• I appreciate all the help and suggestions.

    The main source of frustration was the unpredictability of it -- sometimes things would init and work, sometimes not. However, after reading through all the referenced forum threads, and what @Robin mentioned about a delay setting up SPI, I thought maybe I'm expecting too much from the little guy on startup.

    I am starting WiFi, connecting to a router, starting a simultaneous AP, starting a SPI device, initiating an MQTT module and connecting it to a broker. There are quite likely several opportunities for conflict in there. Sometimes, however, things did happen to start and finish with such timing that it all works. Usually though, that was not the case.

    What I tried is to wrap every startup/connection/instantiation in a delay setTimeout. Is this overkill? Maybe, but it does seem to work, and only delays the complete initiation by a few seconds. But best of all, it now starts up with success every time, all the time, whether on battery, or hooked to USB.

    Thanks again for the advice.

  • Sun 2020.01.19

    Glad it is all working @ScottyMT

    Clarification here

    'mentioned about a delay setting up SPI'
    'to wrap every startup/connection/instantiation in a delay setTimeout. Is this overkill?'

    While it may not have been entirely clear, the reference to a delay in post #5 was directed at setting up SPI after the WiFi init taking time, not a delay in the setup of SPI. As you astutely pointed out "There are quite likely several opportunities for conflict," the WiFi module would have to be fetched, the connect task and setup of the AP would take a bit of time, and at the same time SPI setup, and MQTT broker init were being performed.

    It may not have been clear that using multiple setTimeout()'s was the intent. The pseudo code: Within the init function, start SPI, inside one timeout task, init and start the AP, inside a separate timeout, init and start the connection to the MQTT broker. In that way, each timeout could be tweaked to get the optimum start delay minimum.

    Remember that Espruino will execute the setTimeout() code lines sequentially immediately, that is there is no wait for the timeout to occur before the next code line will execute, so each subsequent timeout value will have to be slightly longer, so they actually stagger an actual half second or so later.

About

Avatar for ScottyMT @ScottyMT started