Main Site Documentation

Spider ->spi and dio together


#1

Hello!

I am wondering if it makes any sense and/or is there a good way to
use general purpose i/o’s for multi-use within a application.

For example, I need a lot of dio’s and also need a lot of spi chip select.

I know I cannot do the following (tried it but get an exception):

    GT.Socket socket = GT.Socket.GetSocket(6, false, null, null);
     m_pin = socket.CpuPins[3];  // note - trying to use the same pin for 2 different things.
    
   m_SPI_Cfg = new SPI.Configuration(
            m_pin,                      // chip select
            false,                      // set low when accessing the chip
            0,
            0,
            true,                       // clock signal will be set to high while the device is idle
            true,                       // data is sampled on the SPI clock falling edge
            1000,
            SPI.SPI_module.SPI2);
    m_dio[0] = new OutputPort(m_pin, false);   //get exception here

===================
now, wondering would it make sense to configure for spi as shown above, then
whenever I want to use it as an i/o and not spi, just turn on or off the i/o by reconfiguring?
ie -
m_SPI_Cfg = new SPI.Configuration(
m_pin,
false,

later in the application, need to turn on the i/o so -> reconfig
m_SPI_Cfg=newSPI.Configuration(
m_pin,
true,

I’m sure this seems a little crazy, however, I will need 20 di/o’s and 20 spi channels and
will not be able to do this (40 i/o’s not avail on spider) unless I get creative…

Also, might look at multiplexing with 3 i/o’s for spi to get 24 channels, but not sure yet.
So, does anyone have an idea and do you see a problem with reconfiguring the spi channel everytime I need to turn on or off a dig. i/o?

thanks!

David


#2

As far as I know, it’s not possible to reuse the same pins — at least not in an easy and comfortable way.

However, EMX has some 70+ general purpose IOs, what makes you think you don’t even have 40?


#3

I should have been more clear -

Yes, you are correct there are 76 i/o’s but I am using them already for other things (ie SD card, usb serial, etc), so that there are only about 27 left.


#4

Hello David.

Instantiating a SPI.Configuration object doesn’t reserve (that what prevents the reuse) the pins.

Reservation of the pins happens when SPI object is instantiated with a given Configuration object. These pins will be releases when the instance of the SPI object is disposed. You can call Dispose method on the SPI instance to release the pins at will.

Keep in mind though, that if you switch configuration Property on the SPI instance (most likely when using multiple SPI devices) and will call the Dispose. It will try to release the current configuration pins and not the pins of the configuration objet the instance was instantiated with. (not a good design by the way)

You can also call Port.ReservePin manually without disposing of the objet, but you have to be careful with that.


#5

thanks for the info Architect -

This reconfiguring and disposing is not ideal -

I may decide to use 20 i/o’s for spi and chip select and then
create a bit pattern with 4 other i/o’s to be multiplexed for the
other 20 dig. i/o’s. (on/off).


#6

No problem.

I just did a quick test with Port.ReservePin call. It does work and allows to “trick” the system and use two managed objects with the same IO pin.


using System;
using Microsoft.SPOT;
using Microsoft.SPOT.Hardware;
using System.Threading;

namespace MFConsoleApplication1
{
    public class Program
    {
        static OutputPort port1;
        static OutputPort port2;

        public static void Main()
        {
            port1 = new OutputPort(Cpu.Pin.GPIO_Pin0, true);

            Port.ReservePin(Cpu.Pin.GPIO_Pin0, false);

            port2 = new OutputPort(Cpu.Pin.GPIO_Pin0, true);


            Debug.Print(
                Resources.GetString(Resources.StringResources.String1));

            Thread.Sleep(Timeout.Infinite);
        }

    }
}

This might work with simple primitives like ports, etc. but can be harder with more complex objects that use extra pin configurations and interrupts (hardware I2C, SPI, SerialPorts etc.)


#7

That is very interesting -

thanks for the code example!!

David