7 replies to this topic

[Luc Wuyts]

There doesn't seem to be support for multiple SPI devices on the same SPI interface in this framework.
It is possible to do your own CS (chip select) managing, but i prefer the way the SPI class manages this.
So i've made a little factory for making it easy to switch between spi devices.

Use:

byte spiIdDisplay = SpiFactory.AddConfig(new SPI.Configuration(PIN_LCD_CS
                                                  , false
                                                  , 0
                                                  , 0
                                                  , false
                                                  , true
                                                  , 10000
                                                  , SPI.SPI_module.SPI1
                                                  ));

        byte spiIdTouch = SpiFactory.AddConfig(
                                                new SPI.Configuration(PIN_TOUCH_CS
                                                  , false
                                                  , 1
                                                  , 1
                                                  , false
                                                  , true
                                                  , 590               
                                                  , SPI.SPI_module.SPI1
                                                  )
                                              );

and when you want to use a SPI device:

   SPI spi = SpiFactory.GetSPI( spiIdTouch );
....

/// <summary>
    /// De SPI interface kan meerdere devices aansturen, maar het MF heeft hiervoor geen voorziening.
    /// 
    /// Ik kies ervoor om verschillende configuraties te gebruiken, en het SPI object telkens te herconfigureren.
    /// 
    /// Static class gebruikt omdat dit vermoedelijk minder ruimte inneemt dan een Singleton
    /// </summary>
    public static class SpiFactory
    {        
        static ArrayList Configurations = new ArrayList();

        static SPI currentSPI = null;

        // Er zullen nooit 256 devices zijn !
        static byte currentId = 0xFF;


        /// <summary>
        /// de ID van de configuratie wordt teruggegeven, zodat dit later 
        /// gebruikt kan worden om een nieuw SPI object te configureren.
        /// </summary>
        public static byte AddConfig( SPI.Configuration  config )
        {          
            Configurations.Add(config);
            return (byte)(Configurations.Count - 1);
        }

        public static SPI GetSPI(byte spiId)
        {
            if (currentId == spiId)
                return currentSPI;
            if (currentSPI != null)
                currentSPI.Dispose();
            SPI.Configuration config = (SPI.Configuration)Configurations[spiId];
            currentSPI = new SPI(config);
            currentId = spiId;
            return currentSPI;
        }





    }

[demonGeek]

There doesn't seem to be support for multiple SPI devices on the same SPI interface in this framework.
It is possible to do your own CS (chip select) managing, but i prefer the way the SPI class manages this.
So i've made a little factory for making it easy to switch between spi devices.

The SPI class represents the master device (the Netduino).

Each slave device on the SPI bus is represented by a separate SPI.Configuration and since you can only have one active device at a time, you simply need to switch the configuration when you want to select a different device:

SPI.Configuration slaveDevice1 = new SPI.Configuration(Pins.GPIO_PIN_D10, false, 0, 0, true, true, 500, SPI_Devices.SPI1);
SPI.Configuration slaveDevice2 = new SPI.Configuration(Pins.GPIO_PIN_D9, false, 0, 0, true, true, 500, SPI_Devices.SPI1);

SPI spi = new SPI(slaveDevice1);

spi.Config = slaveDevice2;

I think that the NETMF terminology is a bit confusing in this regard. I would have preferred something like SPI.SlaveConfiguration which makes the relationship a bit clearer. It would also have been nice to have a Configuration collection within the SPI class itself.

- Adam

[Stefan]

The SPI classes in .NETMF are indeed a bit confusing, I wrote my own (slightly different) MultiSPI class in which I took the SS-pin in my own hands as well. Lets hope it will be implemented better in .NETMF 4.2. By the way, nice to read the Dutch comments I normally write my comments in English, but that's also because my code will be available for the general public and Dutch isn't a common language (anymore).

[hanzibal]

I have some really bad experience with programmatic CS (chip select) management, it seemed to cause small sporadic errors in data that was hard to track down. I reverted to firmware functionality for CS wich requires multiple SPI.Configuation instances to swtich between. Btw, I'm a Swede and find Dutch writing quite understandable, when spoken I can't really cope though The Borers (ancient Dutch people I think) sailed the world and so for instance, Afrikaans is practically Dutch. If I recall correctly, the famous Table Mountain in Cape Town Soutch Africa is called "Taffelberge" in Afrikaans.

[Mario Vernari]

*** OFF TOPIC ***

Btw, I'm a Swede and find Dutch writing quite understandable, when spoken I can't really cope though The Borers (ancient Dutch people I think) sailed the world and so for instance, Afrikaans is practically Dutch. If I recall correctly, the famous Table Mountin in Cape Town Soutch Africa is called "Taffelberge" in Afrikaans.

I am italian, I have learn german and I am using english for my job, but I have hard time reading dutch. However I was in Holland years ago and I loved it so much! I never been in Sweden, though.
I guess we should use english-american for world-wide communications.
*** OFF TOPIC ***

[Stefan]

True that. I know a bit Swedish as well. Went to Stockholm and Gävle once. But this is getting offtopic Indeed if the firmware supports multiple SPI devices well, that should be the best way to handle things. I just hope .NETMF 4.2 makes it more clear/easier to understand then it currently is.

[Mario Vernari]

I just hope .NETMF 4.2 makes it more clear/easier to understand then it currently is.

Yep: I am seriously thinking that the first real firmware/framework could be the 4.2. At the moment we have more problems than benefits.
OK, no more comments on that way on this thread.
Cheers

[Luc Wuyts]

The SPI classes in .NETMF are indeed a bit confusing, I wrote my own (slightly different) MultiSPI class in which I took the SS-pin in my own hands as well.
Lets hope it will be implemented better in .NETMF 4.2.

By the way, nice to read the Dutch comments
I normally write my comments in English, but that's also because my code will be available for the general public and Dutch isn't a common language (anymore).

I wrote this originally for my own use, and since this is very easy to understand, i didn't think it would be nessecary to translate it first.

I think i'll add some object to this class, wich can be used to lock() and prevent other threads from using the spi bus while busy.