13 replies to this topic

[Pankaj21]

Can anyone help me understand how the pins on a Netduino Mini are multiplexed on functionalities? I mean how are the GPIO pins and other functions allocated on the same pins ? Thanks Pankaj

[Chris Walker]

Hi Pankaj,

Can anyone help me understand how the pins on a Netduino Mini are multiplexed on functionalities?

I mean how are the GPIO pins and other functions allocated on the same pins ?

Are you asking how it works internally inside the microcontroller...or which features are available on each pin?

Chris

[soshimo]

Can anyone help me understand how the pins on a Netduino Mini are multiplexed on functionalities?

I mean how are the GPIO pins and other functions allocated on the same pins ?

Thanks

Pankaj

Cpu.Pins is just an enumeration that maps a human readable value (like GPIO10) to a physical pin on the device. Some pins have multiple functions on many cpus, depending on what mode is selected. Maybe that is what is confusing you? I don't know about any actual multiplexing going on though and looking at the schematic I can't see where it could.

[Paul Newton]

Hi Pankaj, The multiplexing is done internally by the ARM microcontoller. It has two banks of IO called PA and PB. Most of the IO pins have two functions and by setting a bit in the PA and PB modules the software selects which function to use. As a C# or VB programmer, this is all done for you. When you ask for a PWM, a switch is automatically thrown for you. The data sheet for the ARM is on a link from the hardware pages, take a look at the block diagrams of the hardware. Have fun - Paul

[cys]

I think the ARM block diagram sort of addresses my question in another thread about referencing pins 1 and/or 2 on the mini.

Page 9 of 683, table 4-1, in the ARM document shows the 100-lead LQFP pinout where 73, 74 and 75 are PA27, PA28 and PA29. But, then, the 100-ball TFBGA pinout on the next page gives PA27 as G3, PA28 as H2, and PA29 as J1. Will any of these translate to a (Cpu.Pin) identity? Pins 1-3 are not assigned a GPIO. Tried using 74 and got a Microsoft.SPOT.Hardware.dll system argument exception.

Hi Pankaj,

The multiplexing is done internally by the ARM microcontoller.
It has two banks of IO called PA and PB. Most of the IO pins have two functions and by setting a bit in the PA and PB modules the software selects which function to use.

As a C# or VB programmer, this is all done for you. When you ask for a PWM, a switch is automatically thrown for you.

The data sheet for the ARM is on a link from the hardware pages, take a look at the block diagrams of the hardware.

Have fun - Paul

[soshimo]

I think the ARM block diagram sort of addresses my question in another thread about referencing pins 1 and/or 2 on the mini.

Page 9 of 683, table 4-1, in the ARM document shows the 100-lead LQFP pinout where 73, 74 and 75 are PA27, PA28 and PA29. But, then, the 100-ball TFBGA pinout on the next page gives PA27 as G3, PA28 as H2, and PA29 as J1. Will any of these translate to a (Cpu.Pin) identity? Pins 1-3 are not assigned a GPIO. Tried using 74 and got a Microsoft.SPOT.Hardware.dll system argument exception.

The enum for Pins (on the Mini) looks like this:

    public static class Pins
    {
        public const Cpu.Pin GPIO_NONE = -1;
        public const Cpu.Pin GPIO_PIN_10 = 11;
        public const Cpu.Pin GPIO_PIN_11 = 1;
        public const Cpu.Pin GPIO_PIN_12 = 0;
        public const Cpu.Pin GPIO_PIN_13 = 12;
        public const Cpu.Pin GPIO_PIN_14 = 17;
        public const Cpu.Pin GPIO_PIN_15 = 16;
        public const Cpu.Pin GPIO_PIN_16 = 18;
        public const Cpu.Pin GPIO_PIN_17 = 51;
        public const Cpu.Pin GPIO_PIN_18 = 52;
        public const Cpu.Pin GPIO_PIN_19 = 53;
        public const Cpu.Pin GPIO_PIN_20 = 54;
        public const Cpu.Pin GPIO_PIN_5 = 59;
        public const Cpu.Pin GPIO_PIN_6 = 60;
        public const Cpu.Pin GPIO_PIN_7 = 61;
        public const Cpu.Pin GPIO_PIN_8 = 62;
        public const Cpu.Pin GPIO_PIN_9 = 10;
    }

So it looks like pin 74 isn't mapped to anything. I don't have the source in front of me, but I would be willing to bet that whatever function you are calling with the invalid pin number is doing some error checking on the parameter. The fact that it's a System.Argument exception is the first clue to that. I would just use the convenient Pins enumeration specific to your hardware platform (mini, go, plus). Now, if you are looking to use it as a low cost ARM dev board then you need to get out the soldering iron and bring some of the other pins out. At that point it's best to just forgo the .net framework and drop down to C or ASM.

[cys]

Cool, thanks. All clues/info much appreciated.

What I'm trying to do is access mini pins 1-3 that have no GPIO pin enumeration per the specific suggestion by CW in this thread here. Per the info that you and CW provided, DTXD, DRXD and DTR could well be (Cpu.Pin)27-29. This would follow suit with TXO -- i.e., TXO is J4/PA1/PGMEN1 and ARM pin#82, *but* (Cpu.Pin)1 and GPIO pin 11. So, *I guess* DTXD which is H2/PA28 and ARM pin#74 could be (Cpu.Pin)28. It's just that when I tried making (Cpu.Pin)28 an output port, there was no change in the status of mini pin1. I was looking deeply at the mini board with a soldering iron nearby, yesterday. Somehow there must be a way to use the rs232 mini pins with no GPIO assignment. At this time I have the outputs of mini pins 1 and 2 connected to a home brewed rs232 to ttl converter on my pcb.

The enum for Pins (on the Mini) looks like this:

    public static class Pins
    {
        public const Cpu.Pin GPIO_NONE = -1;
        public const Cpu.Pin GPIO_PIN_10 = 11;
        public const Cpu.Pin GPIO_PIN_11 = 1;
        public const Cpu.Pin GPIO_PIN_12 = 0;
        public const Cpu.Pin GPIO_PIN_13 = 12;
        public const Cpu.Pin GPIO_PIN_14 = 17;
        public const Cpu.Pin GPIO_PIN_15 = 16;
        public const Cpu.Pin GPIO_PIN_16 = 18;
        public const Cpu.Pin GPIO_PIN_17 = 51;
        public const Cpu.Pin GPIO_PIN_18 = 52;
        public const Cpu.Pin GPIO_PIN_19 = 53;
        public const Cpu.Pin GPIO_PIN_20 = 54;
        public const Cpu.Pin GPIO_PIN_5 = 59;
        public const Cpu.Pin GPIO_PIN_6 = 60;
        public const Cpu.Pin GPIO_PIN_7 = 61;
        public const Cpu.Pin GPIO_PIN_8 = 62;
        public const Cpu.Pin GPIO_PIN_9 = 10;
    }

So it looks like pin 74 isn't mapped to anything. I don't have the source in front of me, but I would be willing to bet that whatever function you are calling with the invalid pin number is doing some error checking on the parameter. The fact that it's a System.Argument exception is the first clue to that. I would just use the convenient Pins enumeration specific to your hardware platform (mini, go, plus). Now, if you are looking to use it as a low cost ARM dev board then you need to get out the soldering iron and bring some of the other pins out. At that point it's best to just forgo the .net framework and drop down to C or ASM.

[CW2]

You've got the pin numbers right, but PA27 and PA28 are not connected directly to DTXD, DRXD pins (#1, #2), they go through RS232 level converter (see U2 in the schematics); DTR is wired as input only (U4 transistor).

[Pankaj21]

Hi Pankaj,


Are you asking how it works internally inside the microcontroller...or which features are available on each pin?

Chris

Originally I had meant to ask just about which features are available on which pins.
But with so many inputs now I have more questions.

Let me be a bit specific...

Say for eg. pin 5 on the Mini is shown as, both a Digital I/O as well as an Analog Input.
1. The mode in which we use it ... Digital I/O or Analog Input depends on how we assign it inside the program. Right?
2. If that is so, then what happens if we connect an analog signal to the pin on the hardware side but in the software we assign it as a Digital I/O? Could this potentially damage the device in certain conditions?
3. Is it possible to externally multiplex this pin between the two types of inputs (analog and digital) using an SPDT relay and periodically switching the relay while simultaneously changing the pin assignment inside the program (evenutally helping us increase the number of I/Os)?

Pankaj

[cys]

You've got the pin numbers right, but PA27 and PA28 are not connected directly to DTXD, DRXD pins (#1, #2), they go through RS232 level converter (see U2 in the schematics); DTR is wired as input only (U4 transistor).

Yes, pins 1 and 2 go through the rs232 level converter. I'm looking to take the rs232 signal to pin 1 or 2 and then process it on my pcb back to TTL and then use it that way. So far no change in the rs232 signal at pin 1 based on assigning (Cpu.Pin)28 as an output port. I see a static -6V on pin 1, and so far this hasn't changed as a function of assigning (Cpu.Pin)28 as an output port, true or false -- hence I started to down the path of questioning if mini pin 1 is indeed (Cpu.Pin)28. The level converter on the mini is an Analog Devices ADM3101EACPZ and I have it spotted on the mini... right now I want to resist hacking with it directly.

[cys]

PA27/DRXD is (Cpu.Pin)27 and PA28/DTXD is (Cpu.Pin)28 based on the mini source code.

Is it possible to assign an output port to a (Cpu.Pin) identity based on an internal const? [I'm guessing not] Possibly the best bet could be to create a public const for the pins I want to add to SecretLabs.NETMF.Hardware.NetduinoMini in the NetduinoSDKSource.

// Specifies identifiers for hardware I/O pins.
    public static class Pins
    {
        internal const Cpu.Pin GPIO_PIN_A_0 = (Cpu.Pin)0; // PA0/RXD0
        public const Cpu.Pin GPIO_PIN_12 = GPIO_PIN_A_0; // PA0/RXD0
        //
        internal const Cpu.Pin GPIO_PIN_A_1 = (Cpu.Pin)1; // PA1/TXD0
        public const Cpu.Pin GPIO_PIN_11 = GPIO_PIN_A_1; // PA1/TXD0
        //
        internal const Cpu.Pin GPIO_PIN_A_10 = (Cpu.Pin)10; // PA10/TWD
        public const Cpu.Pin GPIO_PIN_9 = GPIO_PIN_A_10; // PA10/TWD
        //
        internal const Cpu.Pin GPIO_PIN_A_11 = (Cpu.Pin)11; // PA11/TWCK
        public const Cpu.Pin GPIO_PIN_10 = GPIO_PIN_A_11; // PA11/TWCK
        //
        internal const Cpu.Pin GPIO_PIN_A_12 = (Cpu.Pin)12; // PA12/SPI_NPCS0
        public const Cpu.Pin GPIO_PIN_13 = GPIO_PIN_A_12; // PA12/SPI_NPCS0
        //
        internal const Cpu.Pin GPIO_PIN_A_16 = (Cpu.Pin)16; // PA16/SPI0_MISO
        public const Cpu.Pin GPIO_PIN_15 = GPIO_PIN_A_16; // PA16/SPI0_MISO
        //
        internal const Cpu.Pin GPIO_PIN_A_17 = (Cpu.Pin)17; // PA17/SPI0_MOSI
        public const Cpu.Pin GPIO_PIN_14 = GPIO_PIN_A_17; // PA17/SPI0_MOSI
        //
        internal const Cpu.Pin GPIO_PIN_A_18 = (Cpu.Pin)18; // PA18/SPI0_SPCK
        public const Cpu.Pin GPIO_PIN_16 = GPIO_PIN_A_18; // PA18/SPI0_SPCK
        //
        internal const Cpu.Pin GPIO_PIN_A_27 = (Cpu.Pin)27; // PA27/DRXD/PCK3
        //
        internal const Cpu.Pin GPIO_PIN_A_28 = (Cpu.Pin)28; // PA28/DTXD
        //
        internal const Cpu.Pin GPIO_PIN_A_29 = (Cpu.Pin)29; // PA29/FIQ/SPI1_NPCS3 (DTR)
        //
        internal const Cpu.Pin GPIO_PIN_B_19 = (Cpu.Pin)51; // PB19/PWM0/TCLK1
        public const Cpu.Pin GPIO_PIN_17 = GPIO_PIN_B_19; // PB19/PWM0/TCLK1
        //
        internal const Cpu.Pin GPIO_PIN_B_20 = (Cpu.Pin)52; // PB20/PWM1/PCK0
        public const Cpu.Pin GPIO_PIN_18 = GPIO_PIN_B_20; // PB20/PWM1/PCK0
        //
        internal const Cpu.Pin GPIO_PIN_B_21 = (Cpu.Pin)53; // PB21/PWM2/PCK1
        public const Cpu.Pin GPIO_PIN_19 = GPIO_PIN_B_21; // PB21/PWM2/PCK1
        //
        internal const Cpu.Pin GPIO_PIN_B_22 = (Cpu.Pin)54; // PB22/PWM3/PCK2
        public const Cpu.Pin GPIO_PIN_20 = GPIO_PIN_B_22; // PB22/PWM3/PCK2
        //
        internal const Cpu.Pin GPIO_PIN_B_27 = (Cpu.Pin)59; // PB27/TIOA2/PWM0/AD0
        public const Cpu.Pin GPIO_PIN_5 = GPIO_PIN_B_27; // PB27/TIOA2/PWM0/AD0
        //
        internal const Cpu.Pin GPIO_PIN_B_28 = (Cpu.Pin)60; // PB28/TIOB2/PWM1/AD1
        public const Cpu.Pin GPIO_PIN_6 = GPIO_PIN_B_28; // PB28/TIOB2/PWM1/AD1
        //
        internal const Cpu.Pin GPIO_PIN_B_29 = (Cpu.Pin)61; // PB29/PCK1/PWM2/AD2
        public const Cpu.Pin GPIO_PIN_7 = GPIO_PIN_B_29; // PB29/PCK1/PWM2/AD2
        //
        internal const Cpu.Pin GPIO_PIN_B_30 = (Cpu.Pin)62; // PB30/PCK2/PWM3/AD3
        public const Cpu.Pin GPIO_PIN_8 = GPIO_PIN_B_30; // PB30/PCK2/PWM3/AD3
        //
        public const Cpu.Pin GPIO_NONE = Cpu.Pin.GPIO_NONE;
    }

[Pankaj21]

Repeating my last question... Let me be a bit specific... Say for eg. pin 5 on the Mini is shown as, both a Digital I/O as well as an Analog Input. 1. The mode in which we use it ... Digital I/O or Analog Input depends on how we assign it inside the program. Right? 2. If that is so, then what happens if we connect an analog signal to the pin on the hardware side but in the software we assign it as a Digital I/O? Could this potentially damage the device in certain conditions? 3. Is it possible to externally multiplex this pin between the two types of inputs (analog and digital) using an SPDT relay and periodically switching the relay while simultaneously changing the pin assignment inside the program (evenutally helping us increase the number of I/Os)? Pankaj

[Chris Walker]

Hi Pankaj, The mode the pin is in (digital IO or analog) is based on how you use it in software. They all start out in digital mode. If you connect an analog input, it's read as logic low (false) or logic high (true) by the InputPort class. As long as your analog input is in the range of 0.0-3.3V and is not injecting current into the board, you are generally good to go. You can certainly multiplex between multiple inputs using external circuitry. This is how A4/A5 work to hook up the extra two analog inputs. Just be sure to use a quality analog switch. Chris

[Pankaj21]

Hi Pankaj,

The mode the pin is in (digital IO or analog) is based on how you use it in software. They all start out in digital mode.

If you connect an analog input, it's read as logic low (false) or logic high (true) by the InputPort class. As long as your analog input is in the range of 0.0-3.3V and is not injecting current into the board, you are generally good to go.

You can certainly multiplex between multiple inputs using external circuitry. This is how A4/A5 work to hook up the extra two analog inputs. Just be sure to use a quality analog switch.

Chris

Thats exactly what I wanted to confirm

Thanks Chris