Mynewt FAQ - Drivers and Modules¶
Drivers in Mynewt¶
Q: Is this a correct assumption about Mynewt, that if there exists no driver implementation for a specific SoC,
in hw/drivers/, then it is not supported. For instance, there exists a flash driver for at45db, this implies
that the Nordic nRF52 SoC is not supported at the moment?
A: at45db is SPI, and any SPI would work. You send SPI configuration info when initializing. SPI drivers are below
the hw/mcu/ tree. hw/drivers/pwm and hw/drivers/adc are SoC specific. In general, drivers are for peripherals
that aren’t universally supported. Features that all (or nearly all) MCUs support are implemented in the HAL. For example,
internal flash support is a HAL feature. Visit the HAL Documentation for more information.
Module Argument in Mynewt Logging Library¶
Q: Can you tell me what the purpose of the module argument is in the Mynewt logging library? It looks like it just
takes an int. Is this just to assign an integer ID for each module that logs?
A: It is just an integer which accompanies each log entry. It provides context for each log entry, and it allows a client to filter messages based on module (e.g. “give me all the file system log entries”).
Log Name vs. Module Number¶
Q: So, what is the conceptual difference between a log name, and a module number? It seems like a log type would be
assigned the same name as the module that is using it, and that the module number is just a numerical ID for the module.
Basically, I don’t understand what the purpose of storing the name into the log type is, and passing the module number
in as part of LOG_<LEVEL> macro.
A: A log just represents a medium or region of storage (e.g., “console”, or “flash circular buffer in 12kB of flash, starting at 0x0007d000”). Many parts of the system can write to the same log, so you may end up with Bluetooth, file system, and kernel scheduler entries all in the same log. The module ID distinguishes these entries from one another. You can control level per module, so you can say, “give me all bluetooth warnings, but only give me system level errors”.
Q: Okay, so for something like console logging, we would likely register one log for the entire application, and give each module an ID?
A: I think the thought is that would be the debug log, and during development you could pipe that to console. In production, that might go in the spare image slot. I’m not sure if we support it yet, but we should make sure the log can write to multiple handlers at the same time.