It appears there’s no way to leverage a RS21 wifi module with a Raptor running TinyCLR. What exactly would be required to acheive this? Is this very challenging or something an experienced developer could attempt?
If I fork your gadgeteer modules repo, could I use the old RS21 code as a starting point?
This page lists all modules .NET Gadgeteer Modules
And for this specific module it explains that it is not an option due to NDA.
@Gus_Issa - Hi,
Yes I did see that and really didn’t understand what it ultimately means (you did support it with Gadgeteer hence my confusion if we’re just changing the hosting environment).
So my next question what WiFi module options do I have? Wi-Fi RN171? Is that something I can still purchase from GHI?
I’ve been reading many of the forum posts here and numerous articles and it isn’t clear to me how I can get a Raptor (G400S) board to support WiFi with TinyCLR.
This https://www.ghielectronics.com/tinyclr/features for example states this:
“Secure Wireless Networking, through ST’s SPWF04SA WiFi.”
Many thanks.
We have support for the ST WiFi module. Sadly, ST decided to discontinue it and we are looking into other alternatives.
But either way there is no plan on making a gadgeteer module. You can check with distributors to see if they have RN171 modules or to can use s breakout to wire in any serial WiFi module.
This is only to give you options but gadgeteer has been discontinued for years.
Hi, so “gadgeteer” here more or less means a device that can connect to the sockets present on the Raptor - is that more or less what you mean?
You also mention “wire in any serial WiFi module” but I’d still need some low level software to manage the module wouldn’t I? and if that is feasible then why couldn’t I do this with the RS21 device I have here?
I’m pretty unfamiliar with a lot of the stuff here as you can tell so apologies if some questions seem dumb!
I’m very interested indeed in the architecture you guys are working toward, for example is there anything conceptually like a “device driver” (as in OS device driver) and a device driver interface (like that found within full blown Windows).
I can see we have the processor (in my case a G400S) then I can see that that processor module loads and runs TinyCLR and within that we can run “application” code.
But to interact with a device requires a) general support for that class of device (that is not specific to a device) and then b) a device specific “bit of code” that interfaces between the generic support and the device specific support.
If this is generally the case then developers are either writing
Is this the architecture?
Thanks!
Simply, the driver can be implemented by you or by us. The driver can be very simple, just see the many gadgeteer examples. And it can be very complex. In the electronics world, every device is different and every driver is different. But what is nice is that once the work is done, you have a driver that can be easily used by anyone.
Hi, here is a project using the ESP8266 WiFi module that - as I guess - could be easily adapted to the Raptor under TinYCLR. I didn’t try it but it seems very promising.
-https://github.com/kirklynk/Lynk.Gateway
Thanks @RoSchmi - I’m just playing around at this stage but a bit frustrated that numerous boards I purchased are not readily usable with the new TinyCLR environment. I think though that getting this RS21 to work on my G400 would be a very good learning experience for me.
What’s bothering me though is that I can’t find any detailed documentation stating exactly what the architecture is of TinyCLR, what the design strategy is for integrating devices and developing “drivers”.
I do not rally know what the GHI defintion of “driver” is here, is a driver something that implements some standard .Net interface or is it just an informal term for code that abstracts a device in any way that the developer wants?
I can see that the RS21 simply houses this chip and exposes it through a standard 10 pin connector. It’s also clear that interaction with the device relies on SPI.
But that’s pretty much what I know, I don’t know for example if TinyCLR includes an abstraction for SPI communication nor do I see any documentation for the numerous nuget packages that GHI have published.
I can (if I use the VS object browser) look inside the various assemblies, for example I can see this which looks neat:
But there’s no documentation for these classes (so far as I can tell) nor are there any articles that explain what these classes are intended for and not intended for. Sure anyone who’s worked in this area for some time will probably have a good understanding but frankly these classes should be documented.
Why do GHI not add XML documentation to these things and then convert that XML to a nice formatted set of HTML Pages with a tool like Doxygen or something?
In fact even that is not necessary because so long as the generated XML doc file is included within the nuget package we’d get intellisense for a lot of the assemblies.
For example if I hover over the class name ReadOnlyCollection in this project, then click goto defintion, we get this: (Visual Studio reflects on the assembly extracts all this info).
then I can expand the nodes and see the XML documentation which is a great help, especially for specialized libraries:
But I can’t do this for any of the TinyCLR assemblies but this alone would be a huge help for developers that are new to this area and new to TinyCLR.
GHI is still working on a complete documentation. For today a good starting point is to look in the tutorials page on GitHub:
-Docs/software/tinyclr/tutorials at dev · ghi-electronics/Docs · GitHub
an example for a wifi driver for the SPWF04Sx can be found here:
-https://github.com/ghi-electronics/TinyCLR-Drivers/tree/dev/STMicroelectronics/SPWF04Sx
Writing a (TinyCLR) driver for the WiFi RS21 Module is not advicable (my opinion). The NETMF driver for this module was not open source. If you want to use this module you can stay with NETMF/Gadgeteer. The RN171 driver only supports a http server (as far as I know). Adapting this driver to TinyCLR should be quite easy. If the purpose is only hobby I would go with the SPWF04S because there is a open source driver. Hand soldering of the module to use it with the raptor should not be to hard or you could perhaps use a STM X-Nucleo-IDW04A evaluation board.
@RoSchmi - Thanks for this info. It seems that ultimately getting the raptor to support WiFi under TinyCLR is quite problematic.
We have the RS21 which conveniently uses gadgeteer connectors but has no software support for TinyCLR.
Then we have SPWF04S that does have TinyCLR support but that’s not easily connected to a Raptor connector but comes built-in on the red FEZ board.
All I wanted was to get the Raptor onto my wifi network so I could really doe some interesting stuff!
Thanks for the replies though, much appreciated.
then why change? Netmf is as capable with the G400 and RS21 as it was when you bought your kit, so you can safely and happily stay there if you choose. TinyCLR is new and evolving, and that means it’ll have different goals to what your Raptor was built for.
To be ultra clear, a “driver” is the same as what a traditional driver for a peripheral on a PC is. It is the software required to make it perform as it needs. This is NOT SPI though - SPI is the communication method, and the hardware layer in the TinyCLR handles exposing SPI from the chip to external peripherals. Think of this like a USB printer on your PC - your PC knows how to deal with USB devices, but the driver is needed to be able to take output from a program (using a standard API to generate the print) to get it to output on the printer.
The RS21 has always been a “sticky point” device. To write a driver for the wifi you need the datasheet. The only way to get that datasheet is to have an NDA with Red Pine. The only way to get the NDA is to not disclose your software (driver) internals, which means you can’t publish your code, and you therefore will never see an open source version of the driver. So for the RS21 module, you need to either put it aside and ignore it (in case GHI ever decide to write a closed source driver) and find an alternative, or go back to netmf… or you could always approach Red Pine and try to get the documentation that would let you develop a driver for the RS21…
As for many of your other points - TinyCLR is a developing product, that has just hit release 1.0.0. GHI will do things that make sense to their users, including commercial customers as well as us community users.
@Brett - Thanks for the reply Bret, much appreciated and it has given me more insight.
Thx
@Brett - I’ve just searched for and found this RS9110-N-11-22 but is this the same data sheet you refer to?
Thx
I don’t have a RS21 module so can’t/won’t look it up. It may be…
Edit: I will say that this http://old.ghielectronics.com/catalog/product/282 shows the Red Pine module(s) that the module used… whether the datasheet you showed is the correct one is up to you to decide, and figure out if this is sufficient to build your own driver…
I may dig into this, it will certainly expose me to the technical details and that can be instructive, but before I decide to try and write anything I need to do a lot more reading!
PS: That datasheet does (on Page 27) refer to the very same model - RS9110-N-11-22-04 - that the GHI device page refers to and that my specific device has on the chip itself.
