Either:
Use pin 6, as defined in the Spec as the CS pin, when no CS pin is given to in initializer
Or remove the CS pin definition from the Gadgeteer Module Designers Spec.
This may have some of the needed bases but VLAN needs a lot more than that. Not sure the large work loaded for this would make sense for embedded devices.
Iād love a way to release modules in Gadgeteer if for no other reason then recovering memory. Even better would be a way to let me switch which modules are loaded, canāt get that wifi connection, drop the module and load a ethernet module, but then again I wonder how much memory that would save (if I could load stuff off a SD card I could save buckets, but then that starts to feel like a full blown OS).
Powering down unused modules wold be great given battery is king, long live the king.
Hereās what I wantā¦ Iāve mentioned it several times in the past but I guess itās worth repeating. Letās get rid of installing the modules drivers as an SDK and start using Nuget. This could be done very easily. Iām not sure how you would register new items in the toolbox with the current model. That may require some VS changes but a big first step would be to have the toolbox registration only know where the Nuget package exists rather than just giving you what came with the SDK. This would allow core SDK upgrades to happen on the schedule that GHI & Microsoft want but at the same time would allow driver updates to occur more rapidly and could give a more unified way of adding drivers from an increasingly diverse list of module sources. In the long run, ideally, if you wanted to add a module to the designer/toolbox then you would just go to the Nuget catalog and search for it and have it added to your project. The current model is very 1990āsā¦
+one million on NuGet. Distributing an SDK makes less and less sense these days. GHI needs to host a package source and be done with it. Probably, even the GHI SDK could be NuGet packages. Youād only need the base NETMF SDK actually installed.
Think how many ādoesnāt workā threads end with āupdate the SDKā, that would all go away.
I havenāt used the Gadgeteer stuff too much so far, but I like the idea of not having a SDK installed (or not a single one).
Here comes why:
If we have several NETMF products out at multiple customers, then we have a V4.2.9 here, a V4.3.2 there and may be a V5.42 somewhere else.
Now I need a small bugfix in my software for āthereā, so I install V4.3.2. The next day I have some bugfix āhereā, so install V4.2.9, in parallel I need to prepare the next big release, so I have to switch back to V5.76 beta.
I can have multiple pices of Hardware with the necesary FW on it, but currently I can only have one SDK on my computer.
So: The SDK could be just a FW updater, FW files, and docs, and should be allowed to be installed in parallel to other SDK versions.
The NETMF dllās should then come from NuGet or whatever. In my Company we have our own solution for managing dependencies which allowes quick Version switching in a Project. I just Need to have all dllās in some folder on a Server or localy.