ApacheCon North America 2020, project participation
Hi, folks, (Note: You're receiving this email because you're on the dev@ list for one or more Apache Software Foundation projects.) For ApacheCon North America 2019, we asked projects to participate in the creation of project/topic specific tracks. This was very successful, with about 15 projects stepping up to curate the content for their track/summit/event. We need to know if you're going to do the same for 2020. This informs how large a venue we book for the event, how long the event runs, and many other considerations. If you intend to participate again in 2020, we need to hear from you on the plann...@apachecon.com mailing list. This is not a firm commitment, but we need to know if you're, say, 75% confident that you'll be participating. And, no, we do not have any details at all, but assume that it will be in roughly the same calendar space as this year's event, ie, somewhere in the August-October timeframe. Thanks. -- Rich Bowen VP Conferences The Apache Software Foundation @apachecon
Re: Question about mynewt Single mode
Hi Nicola, On Fri, Sep 27, 2019 at 04:48:18PM +0200, Nicola Bizzotto wrote: > Hi, > I'm currently using an Espruino Puck.js device. I'm programming it with a > Segger J-Link programmer. I have already experience with mynewt OS (I used > it with a Bluefruit nRF52 Feather) and now I want to use it also with the > Puck.js. I also would like to use 'Single' image setup, which is described > here: https://mynewt.apache.org/latest/os/modules/split/split.html. > By now I've always used 'Split' mode. > I searched on your site but failed to find some information about the setup > and use of 'Single' mode. Can you give me some help, or point me to some > useful resources? Mynewt doesn't offer any "direct" support for the single image setup, but I believe it is still possible to use (it definitely used to work). I don't believe there is any documentation for the single-image setup, so here are some (untested) thoughts on how you should proceed: 1. (bsp.yml): In your BSP's flash map, shrink the `FLASH_AREA_BOOTLOADER`, `FLASH_AREA_IMAGE_1`, and `FLASH_AREA_IMAGE_SCRATCH` flash areas down to one sector each. You might be able to remove the "image 1" and "image scratch" areas entirely (I'm not sure), but you definitely need to keep the bootloader area. 2. (bsp.yml): Set the `FLASH_AREA_IMAGE_0` area's offset to 0 and increase its size as needed. Your single image will reside in this area. 3. (bsp.yml): Set the `FLASH_AREA_BOOTLOADER` area's offset to something other than 0. Make sure it doesn't overlap any other areas. 4. Fix up the BSP linker script. Copy the normal linker script and modify its `FLASH` memory region so that it matches the `FLASH_AREA_IMAGE_0` flash area (set `ORIGIN` to 0; set `LENGTH` to the size of the flash area). That should be it. You might run into issues if some of your target's dependencies expect all these flash areas to exist. For example, you will have to ensure you aren't pulling in `mgmt/imgmgr`. Chris
packed structs for HCI
Hi, This is something I was working on few past few weeks: using packed structs for building and parsing HCI commands in NimBLE stack. For easier transition I decided to have one big commit affecting both controller and host (mind the size of change!:). In general this follows similar changes done already for SMP and ATT. Packed structs are used for accesing and creating protocol ordered data. While parsing, unchanged data is passed up in stack as much as possible, so there are some API constifications required due to that. As usual, rule of thumb is that protocol data is accessed via packed structs, and host ordered (parsed) data is (if needed) passed as unpacked structs. I decided to leave unit tests "as is", which means some defines were moved there and tests are stil using byte-by-byte parsing and contructions. I think this is fine since it provides additional cross checking for implemention :) There are serveral benefits of this approach: - less source code - 4470 insertions(+), 6137 deletions(-) - easy to map where host and controller use same command/event - last but not least, less code size. Sample numbers for optimized build with most features enabled: nimble_controller.a 55602 -> 55246 nimble_host.a 68001 -> 65285 Note that while PR is ready to be merged (no regressions in our tests), there is stil place for improvements: using packed structs for ACL, HCI transports, some cleanups in generic code for HCI handling etc. This will be work on later on. PR implementing this is pending review at https://github.com/apache/mynewt-nimble/pull/507 Comments are welcome. -- pozdrawiam Szymon Janc
