I haven’t updated the firmware of the WIFI, only the FEZ itself. I received the board last week from Mouser, so I’m not sure what version it is supposed to have.
I saw that the WIFI module is now end of life. so I will stay tuned on GHI steps on that matter.
About GitHub, I was able to download the repos (tinyclr-ports, tinyclr-samples and tiniclr-drivers) but I was expecting a full repo that has all the components in a single repo. At this moment I am not able to run my project and includes the drivers (it still use nuget).
I will read carefully the link you send and play around that,
So to work with the source for the Wi-Fi driver, you only need the drivers repo. You can just add the SPWF04Sx project to your own solution, then add a reference to that project in your project (you may need to uninstall then reinstall the NuGet packages). Alternatively, just take the source files for the Wi-Fi and add them to your project.
Just want to set expectations here… but I am an outsider, I don’t represent GHI…
Just because a part becomes EOL, does not mean GHI will do anything about current inventory or already produced units. Those are what they are, they’re complete and in the market. They may also have completed a purchase of more inventory of wifi modules waiting to be assembled, which again doesn’t change anything for anyone. GHI have shown over the years that they stand behind their products as long as possible, longer than many others, and so I expect you will see continuing support for Fez devices with that wifi module on in TinyCLR for some time to come, at a software level. You as a new owner just need to realise that sometime in the future GHI will release a new product with a new wifi module, that will be different to your current one. No problem really, but there will be nothing for you or GHI to do, no “steps on that matter”
I need your opinion, I started to write a few queries to get variables value (like the MAC or the serial number).
please let me know what you think of the 2 functions below.
basically I was thinking of 3 options :
create a function per variable
or create a generic function that cover all variable and return an array
or alternatively, return only the value of the variable we pass in parameters. (we have to keep in mind some are int and some are strings
what would you think ?
thanks !
public string QueryMACAddr()
{
var cmd = this.GetCommand()
.AddParameter(“nv_wifi_macaddr”)
.Finalize(SPWF04SxCommandIds.GCFG);
this.EnqueueCommand(cmd);
cmd.ReadBuffer();
var str = string.Empty;
while (cmd.ReadString() is var s && s != string.Empty)
str += s;
this.FinishCommand(cmd);
return str.TrimEnd('\r', '\n'); ;
}
public string QuerySerialNumber()
{
var cmd = this.GetCommand()
.AddParameter("nv_serial")
.Finalize(SPWF04SxCommandIds.GCFG);
this.EnqueueCommand(cmd);
var result = cmd.ReadString().Split('=');
//string serialnb = result[1];
//serialnb = serialnb.TrimEnd('\r', '\n');
cmd.ReadBuffer();
this.FinishCommand(cmd);
return result[1].TrimEnd('\r', '\n'); ;
}
So if I were adding this I’d probably do it like so:
public delegate void CommandCallback(SPWF04SxCommand cmd);
public void ReadConfiguration(string variable, CommandCallback callback) {
var cmd = this.GetCommand()
.AddParameter(variable)
.Finalize(SPWF04SxCommandIds.GCFG);
this.EnqueueCommand(cmd);
callback.Invoke(cmd);
this.FinishCommand(cmd);
}
public string ReadSerialNumber() {
var res = "";
this.ReadConfiguration("nv_serial", cmd => {
res = cmd.ReadString();
cmd.ReadBuffer();
});
return res.Split('=')[1].TrimEnd('\r', '\n');
}
I’ve not actually ran the above code, but it’s the rough idea. If we had generics the delegate could be generic over the return type and I could return directly instead of using shared state like I do.
I give a new try with TinyClr-Drivers (lastest changes) and all seems working very well with new firmware (171117-0328fe3-SPWF04S) !
Good job as usual at GHI. Now I can reach my http site.
Our driver currently only supports the DER format (which is usually found on Windows with a crt extension). The Wi-Fi module itself supports PEM, but our driver does not.
In the common case you only need to load the root certificate (the module also supports client authentication, but our driver currently does not). For example, if you were trying to connect to our main site, the SSL cert you’d want from our chain is DigiCert Global Root CA with a SHA1 fingerprint of A8:98:5D:3A:65:E5:E5:C4:B2:D7:D6:6D:40:C6:DD:2F:B1:9C:54:36.
@John_Brochue thank you for this.
I have implemented this code and apart from having to change void to string in the declaration of ReadSerialNumber() it works.
I just acquired two FEZ boards from Mouser and needed to update the firmware on the WiFi module. All the instructions on the GHI site for updating the WiFi firmware (https://docs.ghielectronics.com/hardware/components/spwf04sa.html#flash-the-wi-fi-module) are correct except for one missing step. Right before you plug the FEZ back into to the computer (use the computer for power via USB) after clearing the FEZ (Tinyclr Config works great), hold the reset button on the FEZ down, then plug in the USB power for the FEZ, then plug in the USB/Serial (TTL) cable, then start the ST Demonstrator GUI program. Keep holding the button until the ST Demonstrator GUI connects to the WiFi module which requires a few ‘Next’ button presses, then release the reset button and one can then program the WiFi with the newer code. In the GHI instructions, this button press and hold would be right below the picture of the serial wiring on the FEZ board. User’s choice, but I always check the verify download. The process took just a bit more than 15 minutes. Once I reprogrammed the WiFi, I was able to run the test programs and was able to pull down a webpage from Google using an unsecure access via port 80. No issues whatsoever with the WiFi or the board, so far… Still working on secure access.
Still working on secure access.