Accessibility Flare Check-in #5

Bristlemouth Core Dev
1

The weekly open meeting starts in 90 minutes. All are welcome!

Accessibility Flare Check-in #5
Thursday, August 15 · 10:30 – 11:00am
Time zone: America/Los_Angeles
Google Meet joining info
Video call link: https://meet.google.com/hzp-wzvh-vyh
Or dial: ‪(US) +1 470-705-3628‬ PIN: ‪895 825 778‬#
More phone numbers: https://tel.meet/hzp-wzvh-vyh?pin=5448892616717

2

I mostly worked on drafting some API docs this week, which I walked the group through. They’re very rough for the moment, and we’re working through the decision-making process.

We went back and forth on whether to use C or C++. There are good arguments for both sides. The decision mostly hinges on what plans we make for future support of other languages. If the core libs are in C, then other languages can create wrappers around the C bindings pretty easily. On the other side, the API can be more expressive with better type checking in C++, so the compiler can save users from more types of errors. None of could name any realistic, recent case of tooling not supporting C++, though we know this has been an issue in the past.

We’re pretty confident in having separate code repositories for the following cleanly encapsulated sets of behavior:

  • A driver for the ADIN2110
  • A simple, functional BCMP packet parser and serializer, only dealing with BCMP payloads, not the IP frame
  • The core library, which acts as a service, with an init function you call once and an update function that you call repeatedly. This knows about network devices, routing, the neighbor table, and more.
  • A middleware library with functions for publish, subscribe, create a service, make a request to a service, and send a service reply
  • (Lower priority) A code generation tool for msg and svc files, following the example of ROS, where we generate the CBOR encode and decode functions as currently done in the bm_common_messages repo.

Oh! I’m just remembering a thing I meant to talk about this morning and forgot to bring up! @vsowa12 @spiderkeys Does anyone have strong opinions about the package management aspects of Bristlemouth? Like when an OEM creates their own firmware app for their own device that depends on the libraries mentioned above, in particular the Bristlemouth core library, what should be our recommended best practice for the dependency? The top 2 candidates that come to mind for me at the moment are:

  • Include the core library as a git submodule (or in-repo folder for other source control systems)
  • Defining in the build a path to the Bristlemouth core library which could be elsewhere on the building machine
3

I guess defining the path to the lib is more flexible and could be used regardless of whether it’s a submodule or not, eh?

I imagine we’re going to need some additional runtime-accessible data about which version of Bristlemouth (or versions of particular components) this app was built with — the type of stuff we print out in response to the info command.

1 Like
4

This week I have been documenting each the functions within BCMP with a goal of identifying the connections and dependencies between the different parts of BCMP and how BCMP connects to LWIP and FreeRTOS. I currently still documenting it all out, but my goal is to identify the various dependencies BCMP has and then analyze them to answer questions like:

  • How does the current BCMP code connect to platform code and IP code?
  • What are the dependencies that are currently being used?
  • Are they used throughout, or just in this one location?
  • Can we consolidate the dependencies? Can the dependencies be removed from certain locations?
  • What will be the minimum platform and IP requirements of BCMP in order for it to run?
  • What functions will need to be abstracted so BCMP can run on different platforms?

Once I am done listing out all of the functions and what there dependencies are I will start to map out the relations between the layers, identify commonalities and begin trying to answer some of these questions - or answering questions I haven’t thought of yet!