Converted Pervarsive ESP8266 to TinyCLR 2.0 
but still face a problem with SOCKET …
0,CONNECT … (it appear as ALREADY CONNECTED) …
source available at :
1 Like
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.
1 Like
i am using latest version of firmware for esp8266 or esp32 and no chaanges from old code only uart part and curcularbuffer only
can you tell me what update-s you did to included
to include on this TinyCLR version also what firmware you are using too …
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?
1 Like
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.
2 Likes
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).
1 Like
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.
Please see this How Secure is Your IoT Device?
2 Likes
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.
idea is just as bridge to use ESP8266 (at managed side)
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.
i don’t want to touch anything on TinyCLR OS…
idea was just to use ip stack / tls as is as an inherited object.
and i didn’t know that wifi and ethernet hook that from inside (so in this case you are right),so as @mcalsyn said that is imposible
so i need to forget (integration with tinyclr) .
Correct. You can have a driver that can be used with tinyclr but it is independent from the internal networking stacks
1 Like
Looks like I missed some action here overnight!
I renamed the cborn-1 branch on my fork to develop , and it should do a clean merge back into master on Martin’s original. It is still a WIP though, as I’m concurrently working on our server-side gateway and only adding fixes/enhancements to the ESP8266 side as I need them.
If the mods required to support TinyCLR as well as Netmf 4.2, 4.3 & 4.4 are minor would it make sense to either incorporate them into the mainline code, or add as a parallel branch, so any improvements benefit all?
2 Likes
It would definitely be best to keep all the platforms in the same branch with common code in the .shared directories, and any per-platform changes in the 4.3, 4.4, and a new TinyCLR directory. That way any fixes in the common code benefit everyone.
I would love to see this code working on TinyCLR (though the ATWINC1500 solution supported by TInyCLR firmware would be my first choice for a new project).
1 Like
Ok, we can aim for that.
I can add my current develop as a PR on your Github repo so we don’t diverge too much, and look at adding in the TinyCLR changes @valon_hoti_gmail_com made.
One problem with the Espressif AT command set is that it keeps changing. We had the 0.41 and 0.5 differences, the latest releases seem to be mainly compatible with 0.5 but each release has it’s quirks. I was trying to stick with the latest version as delivered on my ESP12-F modules to I don’t have to reflash them all, but it seems they still have the “DNS Fail” bug in SoftAP mode, so the question is whether to add in a workaround or just require users to update to the latest release.
There are also differences between the ESP8266 and ESP32 versions of the AT set, the latter supporting additional features typically requiring more processing power.
2 Likes
This thread is awesome! It reminds me of the good old days when we used to join forces and make amazing things.
Community come back… Big time! 
4 Likes