Any Support in CHIBIOS for BMP390

ArduCopter
1

Is there any support for the BMP390 in ChiBios? I cant find it implemented.

2

  1. ChibiOS has nothing to do with barometers.

  2. BMP390 is likely handled with the BMP388 driver - at least I see that 390 is somehow recognized in the sources. This support was added around October 2022 according to Git logs.

(Check libraries/AP_Baro/AP_Baro_BMP388.cpp if you like to read source code)

3

It is supported. You have seen this before?
DevTypes {
DEVTYPE_BARO_SITL = 0x01,
DEVTYPE_BARO_BMP085 = 0x02,
DEVTYPE_BARO_BMP280 = 0x03,
DEVTYPE_BARO_BMP388 = 0x04,
DEVTYPE_BARO_DPS280 = 0x05,
DEVTYPE_BARO_DPS310 = 0x06,
DEVTYPE_BARO_FBM320 = 0x07,
DEVTYPE_BARO_ICM20789 = 0x08,
DEVTYPE_BARO_KELLERLD = 0x09,
DEVTYPE_BARO_LPS2XH = 0x0A,
DEVTYPE_BARO_MS5611 = 0x0B,
DEVTYPE_BARO_SPL06 = 0x0C,
DEVTYPE_BARO_UAVCAN = 0x0D,
DEVTYPE_BARO_MSP = 0x0E,
DEVTYPE_BARO_ICP101XX = 0x0F,
DEVTYPE_BARO_ICP201XX = 0x10,
DEVTYPE_BARO_MS5607 = 0x11,
DEVTYPE_BARO_MS5837 = 0x12,
DEVTYPE_BARO_MS5637 = 0x13,
DEVTYPE_BARO_BMP390 = 0x14,

4

I have, but I was unable to find the correct setings via the hwdef.dat file (@MaxBuzz which is why I specified chibios).

BARO BMP390 I2C:0:0x76

The name in the hwdef.dat seems to be translated to a class name like AP_Baro_BMP390 which doesn’t exist as far as I can tell.

It may be that the BMP390 has an equivalent interface to an existing sensor (such as BMP388), or it maybe it does not, I haven’t yet checked. I just wanted to see if there was something implemented before I did it myself.

5

I can see that the BMP388 is the class to use… and it should figure out the sensor type, either 388 or 390 by reading register 0x00

6

Ardupilot supports BMP390, code is right here, see below:

7

Thanks thats it.

It probably needs a define or new inherited class to enable a user to specify the correct part number, ie BMP390, on the hwdef.dat for clarity.

8

The default is supported unless you want to make a specific declaration of which ones to exclude.

Especially with the F4, if space is limited, some code can be trimmed. I searched and didn’t find any places that require specific declarations.

9

@lida2003 My suggestion is to support declaring BMP390 in the hwdef.

If you do so, my experience is that it will be compiled to look for an AP_Baro_BMP390 class, that doesn’t exist. The way I get it to compile is to declare my BARO as BMP388 and rely on the chip_id functionality to determine the correct sensor. I’m assuming there’s no real functionality difference between the BMP390 and BMP388 in the register mapping used in Ardupilot.

Is there an existing way to specify the baro as BMP390 in the hwdef.dat?

10

It’s the same driver. The only problem here is making no attempt to do even a cursory search of the source for BMP390, which would’ve made that obvious.

Writing and including a separate driver for a functionally identical IC is potentially at odds with your goal of using a minimally featured board in the first place…

If it’s really that bothersome, add a comment in the hwdef for clarification.

11

Calm down @Yuri_Rage.
I spent considerable time looking through the code trying to understand it, stop gaslighting people.

Nowhere does it say in the code that the BMP388 is functionally the same as the BMP390. Bosch semiconductor also doesn’t highlight this fact that it is a direct replacement.

If you don’t want to do a simple inheritance, fine, I don’t really care. Its just a suggestion to make the functionality better and tie the driver to an actual part number, instead of a different, obsolete, part number.

12

You’re also welcome to make a pull request.

EDIT:
I want to add that there really isn’t any gaslighting attempt here, though I will admit that my tone was blunt. I did a simple search of “BMP390” on the AP GitHub repo prior to making any assertion that a simple search would turn up results. When I saw this example, my suspicion was confirmed. I suppose I should’ve taken the time to explain as much in my earlier reply.

13

The reality is BMP390 is a kind of extension of BMP388 chip, so they share the same driver code with minor changes. In order to distinguish them, the chip verndor add chip id, and driver just add if-else statement for clarification.

PS: DPS310 is the same kind of extension chip of DPS280.

  • From code developer view, it’s NOT a big deal, and they can easily tell you which chip is supported.(WIKI is NOT always sync with code)

  • From configuration or firmware deployment view, there are a few ways to consider, which I think you are welcome to propose any idea about this.

e.g.

Use macros for configuration, and read configs and translate to actual code configurations, even link obj file on line when flashing the desinated hardware configuration, which can decrease the code space also.

  • SUPPORT_BARO_BMP388
  • SUPPORT_BARO_BMP390

I don’t know if there is any online custom build tool avaliable here. If there is kind of this cloud tool, then it’s pretty awesome.

PS: I think betaflight configurator is this kind of tool, which do hardware selection on configuration, do the trim with online build(link), and download predefined custom binary. It’s cool!