Yesterday, the mighty Stefan, pointed me a problem about the SPI. After some experiment, I realized there's something not properly working...
Suppose having two different SPI configurations: different SS, and different port (SPI1 and SPI2).
SPI.Configuration Config1 = new SPI.Configuration(Pins.GPIO_PIN_D0, false, 0, 0, false, false, 1000, SPI.SPI_module.SPI1); SPI.Configuration Config2 = new SPI.Configuration(Pins.GPIO_PIN_D1, false, 0, 0, false, false, 1000, SPI.SPI_module.SPI2);Although the SPI2 is not available on both Netduino mini and standard, on the Plus version is used for the SD.
So, when I'm trying to use the ports, the actual behavior is the follows:
using (var s = new SPI(Config1)) { } using (var s = new SPI(Config2)) { } //trows NotSupportedExceptionThat's because the 2nd SPI is not available.
However, Stefan noticed that the following trick is easily accessible, and it *seems* working fine.
SPI Spi1 = new SPI(Config1); Spi1.Write(buffer); Spi1.Config = Config2; Spi1.Write(buffer);The first Write uses the SPI1 (and pin #0), while the second write seems using the new configuration: SPI2 and pin #1.
BTW, the MF code (at least the managed!) is pretty clear: the ports involved in the SPI usage are reserved in the constructor of the "SPI" class, then released in the "Dispose" pattern.
Always continuing the latest snippet, when the SPI instance would be disposed you'll get an exception:
Spi1.Dispose(); //throws NotSupportedExceptionThat's because the SPI2 is not supported. Probably by restoring the initial config, the exption won't be raised. At this point, I wonder what would happen, if I try to use the file-system (which uses the SPI2)...
Anyway, the proof that something was not used correctly is the attempt to use the "unused" port.
When I switch the config to the SPI2 (pin#1), I should be able to use the "old" pin#0: isn't it?
var p = new OutputPort(Pins.GPIO_PIN_D0, false); //throws ExceptionBut, obviously throws, because there's no disposal of the port.
I'm *NOT* sure at all, and I warmly ask to someone to take a look at the code (maybe the native section). Anyway, it seems to me that this ability to re-set the configuration when the SPI has been opened, it much harmful than safe.
For instance, once you switch to "Config2" then back to "Config1", how do you release the SPI2 ports?
Well, either this is a bug (i.e. the Config property must be read-only), or there's still something that I don't know.
Feel free to experiment, dig, and suggest some other trick to test...
Thank you all.
Cheers
EDIT: I forget to point that I've checked with the scope the "ability" to switch between SPIs. Once you change the config, the SPI handshake will switch lines also.
Edited by Mario Vernari, 06 December 2011 - 06:34 AM.