3 years ago.
pin=NC causes system halt, is the intented?
Checking the source files I found that all "pin_function" and "pin_mode" functions in the pinmap.c files contain following statement
<<code>> MBED_ASSERT(pin != (PinName)NC); <</code>>
This causes a program halt in any case that pin=NC. That shoudn't be intention, should it?
Question relating to:
3 years ago.
just checked that it's in pinmap.c for any given target. But that's the intented behaviour. pin_mode(PinName pin, PinMode mode) pin_function(PinName pin, int data)
require valid pin to operate on. NC is Not connected, you can not set it's function or mode. So the assert catches the wrong parameter and helps you fix the bug.
have fun, alex
4 months, 1 week ago.
Hi! Sorry to reactivate this old thread, but is this still unresolved?
I use the http://developer.mbed.org/teams/GraphicsDisplay/code/UniGraphic/ library and it halts wehn i use NC for some unused pins (reset,cs).
UC1608 myLCD(SPI_16, 10000000, p11, p12, p13, NC, NC, p16,"myLCD", 132, 64); // Spi 16bit, 10MHz, mosi, miso, sclk, cs, reset, dc
No lights of death, nothing! When i define any other pin for it, it works!
Why doesn't NC work anymore for SPI, DigitalOut?
2 years, 10 months ago.
Now I ran into the same problem. I use a graphics lib and my hardware has no reset pin, it was ok to call the constructor of the display with 'nc' for the reset pin. With an updated mbed lib I get now also the assertion and I'm not sure at which level I have to fix the problem. Is there any discussion in the forum about this subject?
To post an answer, please log in.