No, I don't agree. In former versions of mbed lib it used to be possible to declare unused pins as NC, f. i.

<<code>>SPI spi(p5, NC, p7) <</code>>

in case of an output only spi, to use p6 for something else. This code doesn't work anymore.

Uwe

It should be but if you are hit by the assert there is a BUG somewhere else in the code. Looking at the SPI code it should work. It uses pinmap_pinout(PinName pin, const PinMap *map) and have a check to skip configuration of the NC pins. What target are you using?

I use a LPC1768.

I have two statements in my code with an "NC" that causes the ASSERT failing message. One is the SPI declaration, the other is an output only serial interface: Serial si(p28, NC); With older revisions of mbed lib (<=80) it used to work.

Uwe

The problem is at serial_init.c

diff --git a/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/serial_api.c b/libraries/mbed/targets/hal/TARGET_NXP/TARGET_L
index 7972eda..161089a 100644
--- a/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/serial_api.c
+++ b/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/serial_api.c
@@ -120,8 +120,12 @@ void serial_init(serial_t *obj, PinName tx, PinName rx) {
     pinmap_pinout(rx, PinMap_UART_RX);
 
     // set rx/tx pins in PullUp mode
-    pin_mode(tx, PullUp);
-    pin_mode(rx, PullUp);
+    if (tx != NC) {
+           pin_mode(tx, PullUp);
+    }
+    if (rx != NC) {
+           pin_mode(rx, PullUp);
+    }
 
     switch (uart) {
         case UART_0: obj->index = 0; break;

You can try this patch.

That alone won't fix it, the other issue is the pin_function which will be called (granted pin_mode is also a problem). You do have a point that it shouldn't call those functions in the first place if the pin isn't connected, on the other hand even though it needs to be fixed on all targets, I think it is easier and less prone to errors to handle it in the pin_function and pin_mode functions, than in the SPI and UART functions (I think those two are affected, since the only other multi-pin library is I2C, and using that with one pin as NC makes very little sense).

I simply have substituted the ASSERT statement in the "pin_function" and "pin_mode" functions bei

<<code>> if (pin == NC) return; <</code>>

in the pinmap.c for my plattform. This should solve all possible problems with NC pins.

Bests, Uwe

By the way: is it possible to get the source files of the former revisions ( e.g. #79) of the mbed lib. I'd like to see how it was coded there, when it used to work.

Okay, I did some research and found that until #226 of the mbed-src both function in the pinmap.c where coded exactly like this (if (pin == NC) return;) From #227 the MBED_ASSERT macro has been introduced insteed, not regarding all consequences.

In the mbed lib in version #86 the MBED_ASSERT macro was offically introduced, but is documented only for the gpio_read and _write functions not für pin_function and pin_mode.

Uwe

thats the same as my Problem: a NC pin must not be set. So for example like in protocols/spi8.cpp:

SPI8::SPI8(int Hz, PinName mosi, PinName miso, PinName sclk, PinName CS, PinName reset, PinName DC)
    : _CS(CS), _spi(mosi, miso, sclk), _reset(reset), _DC(DC)
{
    _reset = 1;

must check the optional Signal first:

if (reset != NC)
  _reset = 1;

Hi! Is this considerd as a bug? If not, a lot of packages have to be changed. Is there an easy workaround? Using other pins is no good solution for me.

What is the MBED_ASSERT good for? Just stop the program without any notification???

As I have mentioned in version #86 the MBED_ASSERT macro has been introduced in the mbed lib. Thus, you can either use an older Version of the lib or you can do like me and use the source and modify the code or you write an unused pin number instead of NC. I do not understand this massive encroachment in the library that leads to system halt after recompilation of ! working code ! It seems there is some confusion in the management of library coding - not really professionally.

full ACK, the goal for new lib releases should be to maintain the comaptibility. Allowing a NC for a pin is a basic feature, changing this makes the NC constant senseless. I'm a stupid user, I don't want to freeze my project with a special lib version and I don't want to use a private modified version. Other users will run into the same problem when you have to use an older or special mbed version :-(

Hello, can you describe your use of NC pin? there might be a missing condition for the target or your case is not covered. Please provide me details, I can look at it and see what we can do.

thanks for your help, I published my test project here: http://developer.mbed.org/users/JojoS/code/mbed_blinky/ In line #14/15 you see the working and not working use of NC. The target is a LPC1347 board, EzSbc2. It is not an original mbed board, so don't care the pin names.