Iām currently working on @mcalsyn (Martin Calsyn)'s excellent driver for use with our G120/ESP8266 board and NETMF 4.2, 4.3 and 4.4.
Martin has put a lot of work into it, all kudos to him!
It only took some minor changes to get it basically working with the much more recent version of the AT command set on the ESP12-F modules I just received. You can get those updates from my fork of his project, in the cborn-1 branch. https://github.com/c-born/serialwifi/tree/cborn-1
However there are a few issues which are causing it to lock up or delay for long periods, I was about to address them tonight - but as Iām writing this instead it may be a job for tomorrow!
As for adapting it to TinyCLR, Iām sure that wouldnāt be a lot of work - maybe it is something Martin has already done?
Good work, Iāll take a look (once Iām set to test TinyCLR! )
Which version of the AT command set are you running?
Iāve got quite a few updates Iām getting ready to push, which could help. Iāve been stress-testing the code for things like fast recovery after fail to connect (bad password, SSID not found, etc), as I want to be able to run quickly through a list of possible APs.
Also looking at light-sleep (which requires another port to do the wake-up trigger)
Any reason you didnāt fork the original repo and add a branch for the TinyCLR mods? Would make it much easier to merge in any updates I (or others) make to the code, and would let us PR back to the original.
Sorry, I meant to do that MUCH earlier, but Iāve been struggling with a problem that turned out to be a wedged directory - āOnly on Windowsā TM!
My ESP12 modules are running AT 1.3.0.0 Jul 14, 2016
I havenāt re-flashed them with the latest version, are there any must-have updates in the more recent versions? I know the ESP32 modules have a lot extra in their AT set, including more encryption options.
The original Pervasive code was written for the AT set 0.41.0.0, with a later update for 0.5.x.x, I modded the version detection to use the 0.5.x.x command set for 1.x.x.x as well.
Iāve just pushed an update to my fork, in the cborn-1 branch, with some faster fail detection and a callback event for various information messages, but Iām actively working on the library now and it may change. There are still problems in SoftAP mode, which Iām ignoring for now as I donāt need it yet. Looks like it could be the spurious "DNS Failā problem Espressif was meant to have fixed back in 2014 but I havenāt followed that up. Perhaps it is fixed in your version?
i just converted as is PERVARSIVE and done changes for UART to be able to use TinyCLR also
faced problem with CircularBuffer GetEnumberation() at end of source so i make a slight changes to work that
and mostly code is as is no changes or very small changes ā¦
next step from Driver above iām trying to squize more and Networking Stuff
to replace with GHI.TinyCLR.Device.Network / System.Net ones to be able to use as is
(one of the good libraries still remain inside Utilities one I Like it ā¦)
Wow. I take my eyes off the forum for a couple weeks and look what happens! I would be MORE than happy to take PRs into the original codebase, especially for new AT versions and TinyCLR support! Iām happy to work with you on working those into the codebase and creating new nuget packages.
Ghi have all network needed things ,
I like to create an proper driver for (AT version of) esp.xx (esp8266,esp32) as wifi
that are compatible with ghi network related libraries.
and to expand existing libraries for .net micro (esp32 related to ssl and certificates)
So, thatās probably a great idea. The new TinyCLR stack means that you can integrate right into their networking framework. The serialwifi network API was really there just to bridge that gap and TinyCLR does that for you now. I could even imagine doing it as a native code component.
Unfortunately, I have a few too many things in the pipeline right now so I wouldnāt likely get to that in any short amount of time. Most of my time right now is eaten up on an industrial controller project (and contributing related changes and bug fixes to the TinyCLR library).
I am not sure if you can route everything to use your drivers. But I curious to find out. Our internal drivers, like WINC1500 and ENC28 has internal native hooks to work the the internal TCP/IP and TLS stack. Your ESP drivers uses its own stack and its own security. I am certain you can make something work but this is not going to be secure.
Yeah, if there are internals that need to be hooked then its hard and probably impossible. Maybe itās best to keep ESP as a separate serial device, but I wonder about the overall applicability of the ESP for TinyCLR designs given that thereās better support for the TinyCLR-supported wireless and wired hardware.
I would love to see esp drivers but with clear expectations so users are not confused. This should not be for commercial use and our networking examples and tutorials will not work on it.
We did allow for internal graphics to be used with any display but networking is a sensitive security subject and we canāt just open it up.