Custom AT firmware

[davidcutting42]

I would be interested in developing custom ESP8266 AT firmware, based on the current source code, that could provide the following:

• A server for WebThrottle-EX
• Real mDNS support
• Possibly provisioning support in AP mode.

Any other capabilities that we would want? This is more of a stopgap solution before (hopefully) the ESP32 replaces the entire arduino/esp8266 mess come v4.0.0

Obviously, we would have to have an automated program that can set up the ESP with new firmware using the Arduino as a passthrough, and two (maybe just one) extra jumpers would be required.

[davidcutting42]

And just to be clear, the CS would still be compatible with stock AT firmware. Additional commands would be extras that could be discovered by the CS using a "discover" AT command

[Asbelos]

Its likely that custom firmware would be incompatible with existing wifi libraries as we would have multiple processes sending or listening on the wifi serial.

We could manage this if we control all AT traffic as we do now but this woukd conflict with @grbba s networking rewrite.

[FrightRisk]

That one firmware can do AT command OR networking commands, correct? When you say based on existing firmware, are you talking about the one that Atani wrote in BaseStation-EX?

…

On Sun, Nov 22, 2020 at 6:02 AM Asbelos ***@***.***> wrote: Its likely that custom firmware would be incompatible with existing wifi libraries as we would have multiple processes sending or listening on the wifi serial. We could manage this if we control all AT traffic as we do now but this woukd conflict with @grbba <https://github.com/grbba> s networking rewrite. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI36OWAFTEUE66VMVWV3MADSRDVU5ANCNFSM4T6FBHJQ> .

[grbba]

No you can't have both at the same time. Actually the library i use is based on the AT 1.7 or AT 2.0 firmware and then in the library provides the same API as the Ethernet library which make its use much simpler. The WiFi library then adds a lot of additional features such as AP setup delete preexisting settings etc etc ... I didn't yet implement those yet to recreate the existing flow but that will be the next to do item on my list.

So we could build a Sketch ( i don't call it firmware its not the same thing for me ) on the ESP which does the networking using the standard WiFi libraries from the ESP framework and then send data over serial to the Arduino. But as discussed in the beginning this idea wasn't going forward as that would have a user not only flash the Arduino with the CommandStation sketch but also the ESP with another sketch.

I wouldn't advise to build a custom firmware, albeit tempting, it adds just another layer of complexity, debugging, support etc etc for which we may not have the ressources, Just stick with what is available and don't reinvent the wheel.

[grbba]

@davidcutting42 Just for clarification ... What do you understand by firmware ? Difference with a sketch ? If the whole CommandStation would run on an ESP the only difference for me would be that i wouldn't have to rely on the current WifiEspAT library. The ESP Wifi library has the same API as the Ethernet one so no real code changes i would say except refactoring some class names i'd say.

[Asbelos]

If we stay with the CS wifi code we have now, then it's possible to integrate new AT commands into the ES code and handle them from the CS. if we plan on using a wifi library like adafruit on the CS, then we cant add AT commands without also modifying the library. On 22 Nov 2020 17:17, Fred <[email protected]> wrote: That one firmware can do AT command OR networking commands, correct? When you say based on existing firmware, are you talking about the one that Atani wrote in BaseStation-EX?

On Sun, Nov 22, 2020 at 6:02 AM Asbelos ***@***.***> wrote: Its likely that custom firmware would be incompatible with existing wifi libraries as we would have multiple processes sending or listening on the wifi serial. We could manage this if we control all AT traffic as we do now but this woukd conflict with @grbba <https://github.com/grbba> s networking rewrite. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AI36OWAFTEUE66VMVWV3MADSRDVU5ANCNFSM4T6FBHJQ> .

—You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[davidcutting42]

Yeah, so just to be clear, this is an extension of the AT firmware. We would basically be adding extra AT commands for things like taking care of the web server, etc. So it would be the same API as the current AT command set, with some extra commands. Am I making any sense?

[Asbelos]

If you are then going to use the standard wifi library on the arduino, you won't have a path down which to send your new AT commands. On 22 Nov 2020 22:08, Dave Cutting <[email protected]> wrote: Yeah, so just to be clear, this is an extension of the AT firmware. We would basically be adding extra AT commands for things like taking care of the web server, etc. So it would be the same API as the current AT command set, with some extra commands. Am I making any sense? —You are receiving this because you commented.Reply to this email directly, view it on GitHub, or unsubscribe.

[FrightRisk]

So we wrote our own ethernet too possibly. Has anyone looked at the WIFI code in the esp8266 folder of the previous version of DCC++ EX? That uploads to a thingie

[Asbelos]

It appears to me that the code is large and complex because it parses and recomposes <> commands sent from wifi clients before passing them on to the arduino. This suggests to me that it would be complex to maintain as every new command would have to be added to this code as well as the arduino code. Presumably this also doesnt support the withrottle protocol either.Apologies to Atani if I've got the wrong end of the stick. I appreciate the wish to make the wifi handling easier and build in web pages etc but we still have to consider the real world complexities of building,  documenting, maintaining, installing and supporting vs the anticipated gain to the end users.