Dec 13, 2016
Simplified and consistent system configuration and initialization
The updated system simplifies the process of creating an app by moving package initialization out of apps code (main()) into syscfg.yml files in the app and BSPs and auto-generated C code. It also enables an audit of the entire system configuration via the "newt config" command.
System initialization happens in two stages:
1. BSP init (bsp_init()): sets up everything that is BSP specific:
- Flash map
- Driver initialization: UART, ADC, SPI, etc.
2. sysinit (sysinit()): sets up all the libraries which aren't BSP or hardware dependent (os, msys, network stacks, etc).
The initialization code is implemented in the appropriate package. Newt generates C code which executes each package's initialization function.
Newt Tool enhancements
To refresh/recreate the contents of the project.state file locally. This is useful in two scenarios:
- When you are subscribed to a branch that might change (e.g. 0-dev)
- When you don't want to check-in the repos directory, but you want to exactly replicate the contents of project.state for known releases.
Displays valid values for the specified element type(s). Valid element types are:
newt pkg new
This command allows the user to create a new package from a template. The package template includes:
- src/ directory to place the source files,
- include/ directory to place the header files,
- pkg.yml containing the base definition of the package,
- README.md file
newt build: honors precedence hierarchy for flags
In the case of conflicting flags, the higher priority package's flag wins. See MYNEWT-323 - Newt - Build options precedence hierarchy Resolved for details. Package priorities are assigned as follows (highest priority first):
- app (if present)
- <library package>
newt error message fixed
Error message corrected when trying to load an image that does not exist. MYNEWT-362 - If you try to load an image that doesn't exist, newt says it succeeds Resolved
Log format changes
The initialization of logging resources has been moved from modules to application. The logging handler is chosen by application and uses standard log_handlers rather than having each app call the handler_init function. Per-instance log structure are declared and initialized in each app and are associated with the log calls by log_register.
Image manager improvements
The image upgrade manager utility (/mgmt/imgmgr/) now has a Command Line Interface (CLI) through which you can list images, tell it to boot to a specific version, and display info about currently running image.
Bootloader supports serial upgrade of images
A package has been added that can be conditionally included in bootloader to allow it to accept image upgrades over serial port. The code monitors a GPIO pin, and if it’s set to specific state during bootup, it will enter the serial downloader, awaiting these commands.
Host-only NimBLE stack
The host and controller portions of the NimBLE stack has been separated. The HCI (Host Controller Interface) allows the user to use only the host portion of the NimBLE code or the controller portion.
Several example BLE apps added
In addition to bletiny (which provides a basic interface to the NimBLE host), blehci (a BLE controller-only application that can interact with a different host e.g. BlueZ), Mynewt now comes with the following apps by default:
- bleprph: A basic peripheral device with no user interface. It advertises automatically on startup, and resumes advertising whenever a connection is terminated. It supports a maximum of one connection.
- blecent: A basic central device with no user interface. This application scans for a peripheral that supports the alert notification service (ANS). Upon discovering such a peripheral, blecent connects and performs the following actions:
- Reads the ANS Supported New Alert Category characteristic.
- Writes the ANS Alert Notification Control Point characteristic.
- Subscribes to notifications for the ANS Unread Alert Status characteristic.
- bletest: An application to test different BLE features, roles (advertiser, scanner, initiator), throughput, connections etc.
- bleuart: Implements a simple BLE peripheral that supports the Nordic UART / Serial Port Emulation service
A socket interface for WiFi chips has been added. Basic functions are supported e.g. scan, connect, disconnect. Configuration is currently through a console interface but additional management functions (e.g. AP profiles, saving config in flash etc.) are on the roadmap. Supported hardware are Arduino MKR1000 and Arduino's Wifi shield with WINC1500 on it.
Hardware Abstraction Layer (HAL) additions
An API has been implemented for a new HAL for SPI access for both master and slave: https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_spi.h
The API for an I2C bus can be seen here: https://github.com/apache/incubator-mynewt-core/blob/master/hw/hal/include/hal/hal_i2c.h . Currently, this is a master API allowing the Mynewt device to function as an I2C master. A slave API is pending for future release.
Allows you to set a recurring watchdog timer to fire no sooner than in 'expire_secs' seconds. Watchdog should be tickled periodically with a frequency smaller than 'expire_secs'. Watchdog needs to be then started with a call to hal_watchdog_enable().
A HAL timer API has been added to the OS. The user can declare multiple HW timer if desired. They are enqueued on a particular HW timer queue when the user calls the hal_timer_start or hal_timer_start_at API.
GPIO: MCU-specific API that maps port->pin
An MCU-specific define has been added that maps port/pin to a single number. Thus, for MCUs that have ports, MCU_PORTA(pin) returns that pin. For example, the defines for STM32F4 can be seen at https://github.com/apache/incubator-mynewt-core/blob/master/hw/mcu/stm/stm32f4xx/include/mcu/mcu.h
The full list of HAL API completed so far can be seen at https://github.com/apache/incubator-mynewt-core/tree/master/hw/hal/include/hal. The BSP specific parameters for the HAL can be found in the appropriate directory e.g. hw/bsp/nrf52dk/src/hal_bsp.c for Nordic nRF52 Dev Kit.
Newtmgr over BLE
This enables remote configuration, remote soft reset, and firmware upgrade using "newtmgr" protocol over Bluetooth Low Energy. A globally unique UUID is used for newtmgr.
Mynewt now offers a utility for recording information when the system crashes to facilitate troubleshooting. There are two options:
- full memory dump of all SRAM
- reduced footprint with only registers and stack of task creating the fault (optional)
Support for New BSPs
- FRDM-K64F from NXP
- STM32F4 from STMicroelectronics
- NUCLEO-F401RE from STMicroelectronics
- Nano2 BLE SoC from Redbear
- Blend2 from Redbear