Hi David,
On Fri, Jan 13, 2017 at 09:52:35AM -0500, David G. Simmons wrote:
> Before I file a bug in Jira on this, I thought I'd ask if this is expected
> behavior:
>
> From my project's syscfg.yml:
> UART_0_PIN_TX:
> description: 'New Pin Assignment'
> value: 23
> UART_0_PIN_RX:
> description: 'New Pin Assignment'
> value: 24
>
> Results in newt target config show air_q:
>
> * Setting: UART_0_PIN_RX
> * Description: TBD
> * Value:
> * Overridden: targets/air_q, default=5
> * Setting: UART_0_PIN_TX
> * Description: TBD
> * Value:
> * Overridden: targets/air_q, default=6
>
> So it picks up that the value was overridden, but it doesn't pick up the
> actual values. It looks like I have to go into
> hw/bsp/arduino_primo_nrf52/syscfg.yml and change it there for any effect to
> be seen.
It does look like there is a bug here. Newt should report an error when
it encounters the syscfg file. You may already know all this, but for
others' benefit- a syscfg.yml file can do two things:
1. Define new settings
2. Override existing settings
You define new settings with the "syscfg.defs" mapping, e.g.,
syscfg.defs:
UART_1:
description: 'Bitbanger UART'
value: 0
You override existing settings with "syscfg.vals", e.g.,
syscfg.vals:
UART_1: 1
That is, the description, value, and other fields are specified at the
point of definition. When a setting is overridden, only the new value
gets specified.
>From your email, it looks like the target's syscfg.yml is redefining
existing settings, which should cause newt to raise an error. I'll look
into this error reporting issue, but in the meantime, I would change
those UART pin overrides to use the syscfg.vals mapping rather than
syscfg.defs.
Chris
