No longer need to call `conf_load()`
Hello all, I am about to merge a PR (https://github.com/apache/mynewt-core/pull/1075) which eliminates the need to explicitly call `conf_load()`. Nothing bad will happen if your app continues to call `conf_load()`, but the call can be safely removed after the PR is merged. Background- The `sys/config` package is used for persisting data across reboots. To restore all the persisted data from flash, an app had to manually call `conf_load()`, typically from `main()`. It would be preferable for the data to get loaded automatically during system initialization, but this is not possible; the underlying storage containing the config data is not ready for use until the application explicitly initializes it in `main()`. Typically, config data is stored in a flash circular buffer (fcb), something which sysinit and syscfg know nothing about, and which must be manually initialzed by the app. Thus, `conf_load()` during sysinit would fail. The PR referenced above causes `conf_load()` to be called automatically, but it delays the call until the default event queue begins being processed. Typically, the default event queue is processed in an infinite loop at the end of `main()`, so delaying the call to `conf_load()` to this point gives `main()` the opportunity to initialize FCBs and other storage first. Issue- Packages may attempt to access persisted data before `conf_load()` has been called. This issue has always existed, but the referenced PR exacerbates it. This issue can arise in a number of ways: (1) Package tries to use persisted data during sysinit. (2) High priority task tries to use persisted data as soon as it starts running. (3) Package that runs in the default task tries to use persisted data immediately after sysinit completes. (1) and (2) were always an issue. (3) is a new issue that arises if an app takes advantage of the automatic call to `conf_load()`. If your app uses a package which tries to use persisted data immediately on startup, then you may want to continue calling `conf_load()` from `main()`. Thanks, Chris
Re: Renaming BSP for Nucleo-F767zi board
Awesome! Been meaning to do that as well, thanks! -- Sent from myMail for Android Wednesday, 16 May 2018, 03:25AM -07:00 from Fabio Utzig ut...@apache.org : >Hello, > >Just a heads up, I have a PR (https://github.com/apache/mynewt-core/pull/1092) >that renames the Nucleo-F767zi BSP which might break some existing targets >that might be using it. This updates it follow a standard that was used for >all other STM32 Nucleo boards (nucleo-f303k8, nucleo-f303re, nucleo-f401re, >nucleo-f413re, nucleo-f413zh). > >Best, >Fabio
Renaming BSP for Nucleo-F767zi board
Hello, Just a heads up, I have a PR (https://github.com/apache/mynewt-core/pull/1092) that renames the Nucleo-F767zi BSP which might break some existing targets that might be using it. This updates it follow a standard that was used for all other STM32 Nucleo boards (nucleo-f303k8, nucleo-f303re, nucleo-f401re, nucleo-f413re, nucleo-f413zh). Best, Fabio
Re: linking woes with weak linkage
Hi, Since every mynewt package built as standalone library, possibly this is the case: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka15833.html Anyway, IMO, it would be better to avoid use of weak linkage. It's a bit confusing. May be the better choice is to add some kind of stm32_cpu_specific_setup() call to stm32_common package. BR, Andrey On 16.05.2018 05:35, markus wrote: I'm sure it's just my newt kung-fu that isn't strong enough, here is what I'm trying to do: in the package hw/mcu/stm/stm32_common there is a function called (let's say): stm32_hal_timer_get_freq for specific processors I want to overwrite that function, so I implement the same function in package hw/mcu/stm/stm32f3xx. Now I tought if I make the implementation in stm32_common a weak symbol the linker would pick up the processor specific version if one was supplied. As it turns out that's not the case. The reason seeming to be that stm32_common is linked before stm32f3xx, so the linker resolve the symbol from stm32_common. If I rename the package "stm32_common" to "~stm32_common" it gets linked after "stm32f3xx" and the linker picks up the correct implementation. Is there a better way of telling newt to link one library before another one? Note that the stm32f3xx package has a dependency on the stm32_common package