3 replies to this topic

[DaveKR]

Hi,

I´m a german teacher preparing myself right now for working with netduino plus 2 in class. (I already ordered 15 of them ;-)
I figured out that the device will become unusable in class(no ping response, no connection in MFDeploy, reflash of Firmware is the only solution) when using the following lines of Code:

private static OutputPort StatusLED = new OutputPort(Cpu.Pin.GPIO_Pin11, false);
private static OutputPort AccessGrantedLED = new OutputPort(Cpu.Pin.GPIO_Pin12, false);
private static OutputPort AccessProhibitedLED = new OutputPort(Cpu.Pin.GPIO_Pin13, false);

The deployment process in VS will take very long and will fail. If I press the reset button on netduino my mashine goes completely down (bluescreen). I have to boot in DFU mode and erase/reflash the latest Firmware to get it to work again.
If I Change the code like this:

private static OutputPort StatusLED = new OutputPort(Pins.GPIO_PIN_D11, false);
private static OutputPort AccessGrantedLED = new OutputPort(Pins.GPIO_PIN_D12, false);
private static OutputPort AccessProhibitedLED = new OutputPort(Pins.GPIO_PIN_D13, false);

everything works as expected.

The problem here is somewhat IntelliSense related. When students start to work with netduino and use IntelliSense with OutputPort(..., they will get the suggestion to use the Cpu.Pin enumeration :-(

Are you guys at secret labs are aware of this problem ?

My Environment:
- Windows 8 Prof., 64 bit
- VS 2010
- Micro Framework 4.2
- SL SDK 4.2
- Netduino FW is Netduino Plus 2 (v4.2.1.2) by Secret Labs LLC

P.S: When you try different CPU.Pin enumeration members you will not always crash the device completely, sometimes all you get is an unhandled exception in SPOT.Hardware.

Greetings from Germany,

David

[NooM]

its because the pins have a different enumeration on the netduinos. thats no bug or something. Pins.GPIO_PIN_D11 != Cpu.Pin.GPIO_Pin11 it will work if you look what cpu pin is routed to the gpio_d11 pin (goto definition of pins enumeration, its kinda weird, but has to be that way) thats not only for outputports, but also for pwmchannels and analogchannels, input/interrupt-ports. just tell your student that intellisense is wrong in that case. to make intellisense work correct secretlabs has to "abstract" all classes to only accept their enumeration and forward it to normal netmf classes.

[Chris Walker]

Hi David, I do wish that we could just turn off Intellisense for the Cpu.Pin enumeration sometimes. It would make things simpler This is actually how NETMF was designed to work. In brief: 1. Cpu.Pin refers to the physical pin #s on the microcontroller itself. By connecting to CPU pins 11-13, you're taking over the USB pins of the microcontroller. 2. The Pins.GPIO_### enumeration refers to the pin headers on the Netduino Plus 2. These are mapped internally to the microcontroller pins. Hopefully we can turn any potential confusion into something which can be a good teaching point: explaining how the connections on the blue headers are physically attached to the microcontroller pins, and how students are interacting directly with the microcontroller. Sorry for any confusion. It may be possible for us to throw an exception for Ports trying to use reserved pins, to protect against this; I'll put that on my list of potential enhancements that we can add in NETMF. Welcome to the Netduino community, Chris

[DaveKR]

Hi Chris,

first of all let me say thank you for your effort in pushing .NET MF for µC´s ! I really enjoy working with netduino and C#. I believe this combination has a lot of potential. It will bring "software" software developers and "hardware" software developer closer together, and both parties will benefit. It´s really cool to use technologies like OOP,MVC,ASPX,... to control some piece of hardware.

Hi David,

I do wish that we could just turn off Intellisense for the Cpu.Pin enumeration sometimes. It would make things simpler

Well, that is really a problem here.I always teach students to RTFM, and somehow intelliSense is a manual too.

This is actually how NETMF was designed to work. In brief:
1. Cpu.Pin refers to the physical pin #s on the microcontroller itself. By connecting to CPU pins 11-13, you're taking over the USB pins of the microcontroller.
2. The Pins.GPIO_### enumeration refers to the pin headers on the Netduino Plus 2. These are mapped internally to the microcontroller pins.

Thank you for clarification, that is exactly what I guessed. That is the problem of enumerations, they are all just integer values and therefore we are not type-safe here :-(

Hopefully we can turn any potential confusion into something which can be a good teaching point: explaining how the connections on the blue headers are physically attached to the microcontroller pins, and how students are interacting directly with the microcontroller.

Yes, but I would like to avoid negative experiences from the beginning on. If only two of my students brick their netduinos that easy they will be demotivated. (And probably the other 20 will try this right away ;-) )

Sorry for any confusion. It may be possible for us to throw an exception for Ports trying to use reserved pins, to protect against this; I'll put that on my list of potential enhancements that we can add in NETMF.

That sounds good ! :-)I have the Feeling that it´s not enough to block some pims but also some critical combinations of pins

Welcome to the Netduino community,

Chris