mbedos5, generate_pins.py doesn't work for NXP targets

[KillingJacky]

Traceback (most recent call last):
  File "tools/generate_pins.py", line 247, in <module>
    main()
  File "tools/generate_pins.py", line 237, in main
    pins = enumerate_pins(pins_file, ['./tools'] + list(includes), defines)
  File "tools/generate_pins.py", line 158, in enumerate_pins
    return visitor.visit(parsed_ast)
  File "tools/generate_pins.py", line 107, in visit
    value = value or self.visit(child_node)
  File "tools/generate_pins.py", line 107, in visit
    value = value or self.visit(child_node)
  File "tools/generate_pins.py", line 103, in visit
    value = self.visit_typedecl(node)
  File "tools/generate_pins.py", line 134, in visit_typedecl
    pins[pin.name] = evaluator.eval(expr.strip())
  File "/usr/local/lib/python2.7/site-packages/simpleeval.py", line 274, in eval
    return self._eval(ast.parse(expr.strip()).body[0].value)
  File "/usr/local/lib/python2.7/site-packages/simpleeval.py", line 285, in _eval
    return handler(node)
  File "/usr/local/lib/python2.7/site-packages/simpleeval.py", line 378, in _eval_name
    raise NameNotDefined(node.id, self.expr)
simpleeval.NameNotDefined: 'LPC_GPIO0_BASE' is not defined for expression 'LPC_GPIO0_BASE'

The empty cmsis.h in targets/mbedos5/tools comments the defination for LPC_GPIO0_BASE out.

Tried to delete this empty cmsis.h and add targets/mbedos5/mbed-os/cmsis into the include directories in generate_pins.py, LPC_GPIO0_BASE can then be evaluated though but the way of defining PinName for NXP makes the script impossible to evaluate the enum constant in preprocess phase.

typedef enum {
    // LPC Pin Names
    P0_0 = LPC_GPIO0_BASE,
          P0_1, P0_2, P0_3, P0_4, P0_5, P0_6, P0_7, P0_8, P0_9, P0_10, P0_11, P0_12, P0_13, P0_14, P0_15, P0_16, P0_17, P0_18, P0_19, P0_20, P0_21, P0_22, P0_23, P0_24, P0_25, P0_26, P0_27, P0_28, P0_29, P0_30, P0_31,
    P1_0, P1_1, P1_2, P1_3, P1_4, P1_5, P1_6, P1_7, P1_8, P1_9, P1_10, P1_11, P1_12, P1_13, P1_14, P1_15, P1_16, P1_17, P1_18, P1_19, P1_20, P1_21, P1_22, P1_23, P1_24, P1_25, P1_26, P1_27, P1_28, P1_29, P1_30, P1_31,
    P2_0, P2_1, P2_2, P2_3, P2_4, P2_5, P2_6, P2_7, P2_8, P2_9, P2_10, P2_11, P2_12, P2_13, P2_14, P2_15, P2_16, P2_17, P2_18, P2_19, P2_20, P2_21, P2_22, P2_23, P2_24, P2_25, P2_26, P2_27, P2_28, P2_29, P2_30, P2_31,
    P3_0, P3_1, P3_2, P3_3, P3_4, P3_5, P3_6, P3_7, P3_8, P3_9, P3_10, P3_11, P3_12, P3_13, P3_14, P3_15, P3_16, P3_17, P3_18, P3_19, P3_20, P3_21, P3_22, P3_23, P3_24, P3_25, P3_26, P3_27, P3_28, P3_29, P3_30, P3_31,
    P4_0, P4_1, P4_2, P4_3, P4_4, P4_5, P4_6, P4_7, P4_8, P4_9, P4_10, P4_11, P4_12, P4_13, P4_14, P4_15, P4_16, P4_17, P4_18, P4_19, P4_20, P4_21, P4_22, P4_23, P4_24, P4_25, P4_26, P4_27, P4_28, P4_29, P4_30, P4_31,

    // mbed DIP Pin Names
    p5 = P0_9,
    p6 = P0_8,
    p7 = P0_7
...
}PinName;

I think a real but simple compilation is needed to properly generate the pins.

[fbmrk]

Hi @KillingJacky
Could you please share the exact command or the method of building your program, which caused the traceback?

[KillingJacky]

very simple:
gulp --target=ARCH_PRO

[KillingJacky]

First, I think there is an obvious bug. The empty cmsis.h in targets/mbedos5/tools deletes the declaration of LPC_GPIO0_BASE out. Look at the PinName define in https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_NXP/TARGET_LPC176X/TARGET_ARCH_PRO/PinNames.h#L34 We need LPC_GPIO0_BASE.
And all the NXP targets define PinName this way.

2nd, all other targets except NXP define PinName enum item with exact number. e.g. https://github.com/ARMmbed/mbed-os/blob/master/targets/TARGET_Freescale/TARGET_KLXX/TARGET_KL46Z/PinNames.h You can check all PinName.h in TARGET_XXX directories, they all define enum without using the auto-increment feature of enum except NXP targets. The NXP targets' PinName item will not get its real value until it hits the compiler. Your TypeDeclVisitor implementation doesn't have support for handling auto-increment eventually.

[akosthekiss]

Could someone please confirm whether this issue still persists?

[fbmrk]

I could still reproduce it.

[elchinillo]

Has anyone being able to workaround this issue?