[Grbl_Esp32 Issue#422] Can I configure/enable Wifi station mode at compilation time?

#1 – MitchBradley 于 2020-06-04

Look at CONNECTTOSSID and SSIDPASSWORD in config.h. If the former is defined, radio mode will default to station mode (see DEFAULTRADIO_MODE in the same file).

#2 – dakoner 于 2020-06-04

I’ve set those parameters, cleaned, and rebuilt (both Arduino IDE, and Platform.IO). It doesn’t work for me: it still tries to connect to GRBL_ESP (not the AP I defined), fails, then makes its own AP.

#3 – dakoner 于 2020-06-04

I tried again to verify. Looks like the firmware is actually using whatever was configured by the user via command line [ESP…] commands (saved to eeprom?), not what’s set in the defines.

#4 – MitchBradley 于 2020-06-04

There is a longstanding confusion with the way that EEPROM settings work. The defaults that are compiled into the code apply only when the EEPROM settings are invalid. The way it works is that, if the EEPROM settings are invalid, or if they are reset, then the new defaults are used to establish new EEPROM settings. You can clear out the old wifi-related settings with, for example, $RST=@ . $RST=* will clear everything, wifi and motor settings and whatnot.

This is going to change a little bit with the new settings framework that just landed in the Devt branch – not yet in master. In the new framework, settings that are at their default values are not actually stored in EEPROM, so if you change the default and recompile, you will get the new default automatically. But if you have changed the value from the default at runtime, the override will be stored in EEPROM, so a recompile with a new default will not trigger a clearing of the override.

#5 – MitchBradley 于 2020-06-04

The long-term goal with the new setting framework is that it will rarely be necessary to recompile. Nearly everything that you might want to do can be changed via settings. The idea is to have a single binary that can handle everything, configured for a user machine via a settings list.

#6 – MitchBradley 于 2020-06-04

We are looking for testers. Since you are familiar with both Arduino and platformio compilation, you are probably at the right skill level to live a little on the edge. We think that the new settings are reasonably solid, but only a few people have tested it so far.

#7 – MitchBradley 于 2020-06-04

The new format is described at the beginning of https://github.com/bdring/GrblEsp32/wiki/GrblESP32-Settings

#8 – dakoner 于 2020-06-04

OK, yes, the current method is a bit confusing. I’m fine with testing the new code. My ulterior motive is to modify grbl_esp32 for my own purposes (building an alt-az telescope platform that automatically points to the sun using GPS info), so I will be adding a custom machine (in my own branch). Sounds like the idea is that I’d fork Devt and work from there, filing Github issues for any Devt-specific problems here.

#9 – MitchBradley 于 2020-06-04

Yes that sounds good. But in the short term it is probably best just take Devt for a spin around the block and see if anything breaks. There will be a few tweaks to the settings before it hits master, so if you make machine-specific changes on top of Devt, be aware that a few things are likely to change.