Network and boot diagnostics

[enfieldcat]

First of all thanks for an interesting project. I think this has potential to introduce many to DCC by way of its ease of construction and low cost. It also has appeal to people like me who just want a simple controller for their work bench to program and test locos.

I'd like to suggest some changes to ESP_DCC_Controller.ino

• Add boot diagnostic to show pin assignments. This has helped me find where I had assigned multiple functions to a single pin.
• Only start AP or STA interfaces if a SSID is assigned to them
• Only adjust the AP IP address if not using the default 192.168.4.1 address

The following file should show the changes I've made locally: ESP_DCC_Controller.txt

There are also a few suggestions that I've not looked into:

• The STA MAC address in web configuration page appears to be in reverse byte order
• Having a "reboot on update" check box in the "hardware Settings" page would be nice. This could run ESP.restart(); once the EEPROM has been updated.

[computski]

Thanks for your suggestions, I think I will implement all of them, so watch out for another code update. The MAC address - I simply dumped it out but never checked, it may well be in reverse order so thanks for checking And I could not get the AP mode working so parked it a couple of months back whilst I focused on the hardware board options. the objective was to allow the unit to run both STA and AP simultaneously.

Finally, I did try reboot on update originally but I found ESP.restart(); did not reliably cause a restart. the unit would often hang.
Did you test this yourself? I'd be interested in what you found.

Appreciate the feedback and its glad you find the project useful. I certaintly learnt a lot of new techniques as I developed it - from C vectors through Websockets and JSON etc.

[enfieldcat]

Glad you found my suggestions helpful.

No I've not tested the ESP.restart() myself. I've used the esp32 equivalent successfully in my HydraFerret project, see https://conferred.cf or my git page for details. I've not had too much interaction on esp8266, and esp32 has some interesting things other than just more I/O pins: dual core, up to 240 MHz CPU speed and spinning off independent tasks. You can set up message queues to allow tasks to communicate with each other using freertos. I also store persistent variables in NVRAM as name value key pairs, quite different to the EEPROM usage in ESP_DCC.

I probably won't have much time over the next few weeks to look at ESP_DCC code in too much detail.

Regards T

On Sun, 5 Dec 2021, 3:37 PM computski, @.***> wrote:

Thanks for your suggestions, I think I will implement all of them, so watch out for another code update. The MAC address - I simply dumped it out but never checked, it may well be in reverse order so thanks for checking And I could not get the AP mode working so parked it a couple of months back whilst I focused on the hardware board options. the objective was to allow the unit to run both STA and AP simultaneously.

Finally, I did try reboot on update originally but I found ESP.restart(); did not reliably cause a restart. the unit would often hang. Did you test this yourself? I'd be interested in what you found.

Appreciate the feedback and its glad you find the project useful. I certaintly learnt a lot of new techniques as I developed it - from C vectors through Websockets and JSON etc.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/computski/ESP_DCC_Controller/issues/2#issuecomment-986155191, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIXKLEGRYAV3SO4UAZGBLVDUPLF6TANCNFSM5JL6HF2A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[computski]

Yup, I had a quick look at your site - Hydra-Ferret is quite advanced in terms of all the communications flows so I might borrow a few techniques..

I will at some point port the 8266 code to an ESP32 using a Wemos D1 R32. And yes, quite a lot of differences. Dual core should be useful though, the DCC signal timing can go into one core and all the other comms into regular core (i.e. Arduino uses core 1).

BTW, I just uploaded a youTube video on the project - for the 2 board combo of L298 shield + WeMos D1. this is the most simple version possible, even more simple than the NodeMCU based variants. Check the Computski channel https://www.youtube.com/results?search_query=computski