Netduino home hardware projects downloads community

Jump to content


The Netduino forums have been replaced by new forums at community.wildernesslabs.co. This site has been preserved for archival purposes only and the ability to make new accounts or posts has been turned off.
Photo

SPI Config setting (bug?)


  • Please log in to reply
3 replies to this topic

#1 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 06 December 2011 - 05:49 AM

Hello everybody.
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 NotSupportedException
That'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 NotSupportedException
That'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 Exception
But, 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.

Biggest fault of Netduino? It runs by electricity.

#2 Stefan

Stefan

    Moderator

  • Members
  • PipPipPip
  • 1965 posts
  • LocationBreda, the Netherlands

Posted 06 December 2011 - 09:05 AM

the mighty Stefan

Hihihi ;)

using (var s = new SPI(Config1)) { }
using (var s = new SPI(Config2)) { }  //trows NotSupportedException

// Works fine
SPI Spi1 = new SPI(Config1);
Spi1.Write(buffer);
Spi1.Config = Config2;
Spi1.Write(buffer);
I always thought that was the only good way, and it's the base of my MultiSPI class. The actual bug here I think is that the SPI class in the .NET Micro Framework should be a static class instead. But perhaps Microsoft decided not to do that due to memory usage. When you don't need SPI, why loading the SPI library.
"Fact that I'm a moderator doesn't make me an expert in things." Stefan, the eternal newb!
My .NETMF projects: .NETMF Toolbox / Gadgeteer Light / Some PCB designs

#3 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 06 December 2011 - 12:34 PM

The actual bug here I think is that the SPI class in the .NET Micro Framework should be a static class instead. But perhaps Microsoft decided not to do that due to memory usage. When you don't need SPI, why loading the SPI library.

Sorry Stefan, but it can't be static.
I encourage you to take a look at the C# (and even C++) code of the MF related to the SPI driver.
The SPI driver must be a dynamic class, because it acts as host for the output/input ports involved in the bus. Thus, when you use the SPI1, the driver allocates four ports: SCLK, MOSI, MISO and SS.
How could you do it in a static way?

BTW, the SPI-config class is correctly immutable, but leaving the "Config" property writable won't protect the hacking from dirty tricks.

Cheers
Biggest fault of Netduino? It runs by electricity.

#4 Mario Vernari

Mario Vernari

    Advanced Member

  • Members
  • PipPipPip
  • 1768 posts
  • LocationVenezia, Italia

Posted 06 December 2011 - 06:16 PM

I added this problem as an issue on CodePlex.
Cheers
Biggest fault of Netduino? It runs by electricity.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.