ESP32 Command Station

Atani Dec 10, 2017

  1. Atani

    Atani TrainBoard Member

    1,081
    662
    22
    If you have the console output from before the flash erase I can look at why you needed to do the reset. It is usually a case of a corrupted data file and I'd like to correct any occurrences of that if I can before v1.5.0 is out.
     
  2. John Flanagan

    John Flanagan TrainBoard Member

    28
    4
    4
    I do not, sorry. It was in a constant reboot loop.
     
  3. Atani

    Atani TrainBoard Member

    1,081
    662
    22
    Ok, if it reproduces please capture a snippet of the console showing why it is rebooting and I can take a look further at it.
     
  4. Gregory Gee

    Gregory Gee New Member

    3
    2
    2
    Yes, both ESP boards I have say ESP8266.

    Does it matter if it is WROOM-32D ? I'm looking online, and see many ESP32 Uno D1 R32. When I zoom into the image, I see ...32D on the chip. From what I can search, they should be the same.


    https://usa.banggood.com/LILYGO-TTG...lopment-Board-p-1163967.html?cur_warehouse=CN

    Greg
     
  5. Atani

    Atani TrainBoard Member

    1,081
    662
    22
    That will be fine, the WROOM-32D is an updated version of the WROOM-32 SoC.
     
  6. John Holdsworth

    John Holdsworth New Member

    8
    1
    2

    there always seems a lot of confusion with what pins are actually being used for SDA and SCL in ESP32 since they are configure-able. My handy tip is to use Serial.print(SDA) and Serial.print(SCL) which will send the actual configured values to the serial port. Maybe insert these two print statements into void setup() after running the esp32 command station and see what you've got?

    eg
    void setup(){
    .
    .
    .
    .
    Serial.print("sda pin: ");
    Serial.print(SDA);
    Serial.print("scl pin: ");
    Serial.print(Scl);
    .
    .
    .
    }
     
  7. Atani

    Atani TrainBoard Member

    1,081
    662
    22
    was that via the web interface? I found a bug yesterday related to a reset dialog not showing up on the web interface and fixed that last night, however, I just spotted an issue with the current factory reset code when invoked from the web (it would clear LCC and WiFi config only). I'll be pushing a fix in a short bit to correct the factory reset code to clear all config and not just LCC/WiFi config.
     
  8. John Flanagan

    John Flanagan TrainBoard Member

    28
    4
    4
    I did it from the WEB interface and saw nothing happen. I expected a reset and didn't see it. And once I reset the board it came back up with the WiFi values still in place. I have moved this board through lots of your updates. I don't expect that your code to have to handle that sort of operation. It makes sense to have to erase the board every now and then.

    John
     
  9. Atani

    Atani TrainBoard Member

    1,081
    662
    22
    Hmm, it should have popped up a dialog showing a pending reset. Sounds like it crashed before it could pop that up or something else...

    Hopefully things will be stable for a while with IDF v4.0. I've been testing with IDF v4.2 (master) and there are a few areas that will break and after about an hour of poking around I gave up on moving up to that for now but I will need to revisit it further very soon as arduino-esp32 is moving up to 4.2 for ESP32-S2 support and I will need to get OpenMRN working on top of that (some works now).
     
  10. FlightRisk

    FlightRisk TrainBoard Member

    311
    103
    5
    @Atani, BTW, did you buy the dso138 kit or find one fully assembled?
     
  11. Atani

    Atani TrainBoard Member

    1,081
    662
    22
    I bought it assembled, I wouldn't recommend the older model one like I have. @Shdwdrgn picked up a dso138mini recently and it has a number of fixes over the one I have. The biggest problem with all of the dso138 line of products is the noise that will show up in the graph, I don't know of a good way to really eliminate it but you can reduce it some with the adjustment screws.
     
  12. John Flanagan

    John Flanagan TrainBoard Member

    28
    4
    4
    I tried to compile you code with the current master just to see what would happen. I knew from your previous post that it would fail. What I didn't know what how much has changed at level 4.1. What is the usual/normal way folks handle changes like the Ethernet stack or event loops. Two ways that I have done that are with #ifdef >4.1 new else current in the code itself. Or to create an abstraction layer to hide the #ifdef code and migrate that way when < 4.1 stops being an issue.

    What is the open source usual way? Both are messy and both make the code less readable. The abstraction layer tends to start adding arguments that are unneeded and messy.

    A third way is two separate files and either have #ifdef's around the whole file for use build tools to select the file.
     
  13. Atani

    Atani TrainBoard Member

    1,081
    662
    22
    IDF v4.1 (and master which is 4.2) has changed considerably in the wifi stack, specifically tcpadapter has been replaced with esp_netif... I'm working through the diffs now so OpenMRN (and OpenMRNLite) will work on 3.3, 4.0, 4.1 and 4.2... I should have it all sorted over the weekend. I need to get this done as I now have an ESP32-S2 in hand for testing of the new arduino-esp32 which will be very soon packaging ESP-IDF master (as arduino-esp32 v2.0). There will be a few "missing" features in the first version of OpenMRN for the ESP32-S2 (mainly TWAI [aka CAN]).

    IDF v4 supports the new esp_event library and that is the direction I'm taking currently but maintaining backward compatibility in the one area that needs it (Esp32WiFiManager). All other areas of the CS have been shifted over to esp_event consumption directly (pending commit and push still).

    yes, with the bulk of the events being processed only in Esp32WiFiManager I'm opting to have all abstractions in there instead of sprinkling it all over since the CS currently depends on IDF v4.0 anyway.
     

Share This Page