Logging changes, part 2 - Module-mapped logging
Hello all, In my previous email, I mentioned some proposed logging changes that I was less sure of. In particular, there are these two PRs that I submitted: (1) log/modlog - Module-mapped logging (https://github.com/apache/mynewt-core/pull/1174) (2) sys/log/full: Allow min-level per module (https://github.com/apache/mynewt-core/pull/1179) I think the changes are sufficiently described in the PRs themselves, so I won't repeat that here. My concern with (1) is: the logging API is getting pretty crowded. If we add this feature, there really won't be room for much else in the future, so I just want to be sure this is the logging API we want. Re: (2) - I wanted a user-friendly way to configure individual log levels on startup, and to turn up or down log levels while debugging. My concern is that this would be the *fourth* place where logging is supressed based on level. The other three are: 1. The compile time `LOG_LEVEL` setting. 2. Each log object as a minimum log level (`l_level`). 3. (1) above adds a minimum log level per module-mapping. My feeling is that this won't be an issue in practice: `LOG_LEVEL` feels different from the others, and I don't see people ever changing `l_level` or module-mapping levels. Please feel free to share any thoughts, suggestions, criticisms, etc. Thanks, Chris
Logging changes, part 1 - Separate header and body
Hello all, I have submitted a few logging related PRs to the core repos. I think I like the changes, but I have a nagging feeling they miss the point somehow. I wanted to get the community's opinion on these changes as well as start a discussion on minimizing backwards compatibility breakage. I plan to split this into two emails. This email concerns this PR: https://github.com/apache/mynewt-core/pull/1196 This email is a bit easier than the next one, because I am mostly convinced that this change is good. The PR addresses some awkwardness in the logging API. Specifically, the old API requires the user to know that each log entry starts with a header, and to know the offset of the message body within a log entry. This burden is imposed on the user as follows: 1. log_append() - User supplied buffer must contain sufficient padding to accommodate a log entry header at the start (described in more detail here: https://github.com/apache/mynewt-core/issues/1173). 2. log_read() - The offset argument is relative to the start of the log entry, not to the start of the message body. Reading from offset 0 retrieves the header; reading from offset (0+hdr_size) retrieves the body. 3. log_walk() - Length passed to walk callback indicates the size of the entire entry, not just the size of the body. The callback has to adjust the length and offset to read the message body. I think these are all deficiencies in the logging API. The user should not need to know how log entries are structured and where the message body begins. However, I think the most important issue is the padding requirement of `log_append()`. The PR referenced above addresses these issues by introducing some new funtions: * log_append_body * log_append_mbuf_body * log_read_hdr * log_read_body * log_read_mbuf_body * log_walk_body The PR description goes into more detail about these functions. I think these functions are an improvement over the existing ones, because they are less error-prone without sacrificing any power (but please voice any disagreements). That said, I don't think it is necessary to break backwards compatibility. While the new function names are not quite ideal, it doesn't seem llike too much of a burden for users to include the "_body" suffix when accessing the log API. All comments welcome. Thanks, Chris
HCI comms
All: I'm using a BroadCom(Cypress)43438 Bluetooth chip that receives a 4 wire HCI. What would be a good example tutorial to use to just get my BT actually advertising. Jeff
Odd errors
All: Has anyone seen these errors before: Error: arm-none-eabi-gcc: error: CreateProcess: No such file or directory And rebuild required; different command Trying to build the blinky project for the STM32F4-Discovery. This is the sequence of errors I got when I tried to "newt build stm32f4disc_boot" Compiling src in base directory: C:/Users/jbelz/AppData/Roaming/SPB_Data/dev/myp roj/repos/apache-mynewt-core/util/mem/src C:/Users/jbelz/AppData/Roaming/SPB_Data/dev/myproj/repos/apache-mynewt-core/apps /boot/src/boot.c - rebuild required; different command C:/Users/jbelz/AppData/Roaming/SPB_Data/dev/myproj/repos/apache-mynewt-core/boot /bootutil/src/image_ec.c - rebuild required; different command C:/Users/jbelz/AppData/Roaming/SPB_Data/dev/myproj/repos/apache-mynewt-core/boot /bootutil/src/bootutil_misc.c - rebuild required; different command C:/Users/jbelz/AppData/Roaming/SPB_Data/dev/myproj/repos/apache-mynewt-core/boot /bootutil/src/image_ec256.c - rebuild required; different command Error: arm-none-eabi-gcc: error: CreateProcess: No such file or directory Thanks all
Re: Bluetooth certification
> > Runtime has qualified the NimBLE host stack just released (version 1.0.0). > The QDID is 64 and you can use it for your product listing. > https://launchstudio.bluetooth.com/ListingDetails/59050 < > https://launchstudio.bluetooth.com/ListingDetails/59050> > Cool. This is Very Cool, and should probably get some sort of publicity. It should make Nimble (and MyNewt) much more attractive to a wider range of developers. Thanks for the update. -- The State Belt Railway of California zoo @ statebeltrailway.org
