no unless you take our VNC code and convert. Secure means the chip has no TCP or TCL and all that is done inside SITCore. Long story short, we have proper secure options that we have put years into perfecting them 
Anything outside that would be not secure, just like if you used ESP32.
1 Like
@Gus_Issa - yes, thatâs what I was planning. GHI namespace and a well-formed driver nuget following the patter of the other drivers.
I would also contribute an SPI bus manager nuget, since the wiz driver is designed to share a SPI channel with other devices and the manager prevents SPI bus collisions.
I agree with all that Gus has said above - this is just a way to add very basic networking to the SC13 with Wiznet - it is not equivalent to the built-in support that GHI provides for the SC20 series chips. This would be a satisfactory way to get networking on an SC13, but isnât equivalent to the built-in SC20 stuff.
And I would not use the wiznet libs on an SC20 because there are much better solutions available once you move onto that chipset.
Is this needed in TinyCLR? SPI has a controller and a device. You only need to provide the controller to the driver and it creates its own device. And if you use the built in chip select then thread switching will never be a problem.
We have had such need in the past when a customer needed 2 Ethernet connection. One was a real connection and that used the built in and the second was for simple internal use and that went over SPI bus.
Maybe it isnât. It was in netmf. If you create two devices on the same SPI controller, each with a different CS, does TinyCLR make sure that only one CS is asserted at a time? If so, then yes, this becomes much easier and the SPI manager isnât needed.
It should be fine, as WiFi and ENC use SPI bus at the same time you do.
1 Like
Ok - I will take my wiznet driver and modify it to use the TinyCLR paradigms and submit a driver nuget PR. The hardest part of the project will be finding my wiznet click. One of these boxes somewhereâŚ
I was thinking the same thing. I have it⌠Somewhere!!
@mcalsyn, @Gus_Issa
I apologize for being off topic, but since you are talking about drivers and multiple devices on one SPI controller, can I bring my two cents into the conversation?
In some of my projects, up to 12 peripheral low-speed SPI devices with different types of latching control are needed (for example, the 74HC595 uses a standard CS, and the 74HC4094 needs a latching strobe). In my case, I use CS expansion microcircuits, allocating only 1 instead of a set of CS. And 4 address wires. However, I wanted to get both direct SPI and addressable compatible drivers. Thus, I had to make the ISpiDevice interface completely repeating the SpiDevice structure. Then I wrap the SpiDevice implementing my ISpiDevice and get a MySpiDevice that repeats the SpiDevice completely. then from the resulting class MySpiDevice I inherit a new one with the address bus MySpiDeviceAddressed. This gives an extended SPI implementation, but it will only be compatible with my ISpiDevice implementation.
Why did I write this.
We need interfaces to sealed drivers. So that they can be painlessly extended, provided that it is impossible to inherit from the sealed driver.
Is this what you are looking for?
-https://drive.google.com/file/d/1uHf-OdQ8ZlJa0WVGH4ikHQ_s0veVHzln/view?usp=sharing
Given that the SpiDevice source is in a public repo (GitHub - ghi-electronics/TinyCLR-Libraries: Official Libraries supporting TinyCLR OS), you could just recompile that without âsealedâ and give it a try that way. If that doesnât break anything and you can achieve what you want, you might consider submitting a pull request.
I havenât tried such a change, but I donât immediately see any reason that it would break anything. I also donât work for GHI, so I canât predict whether that PR would get accepted, but they have been very generous about accepting anything that improves adoption without breaking anything.
Yup - thatâs the stuff. I have an updated version in my git repo and will get that converted to TinyCLR using the new Spi interface.
1 Like