Gpio driver linux for new board/target

Hardware Linux
41 
alex@ubuntu:~/Copter-4.3$ sudo ./build/nxflight/examples/BARO_generic
Barometer library test
TOGCS: Calibrating barometer
Segmentation fault
alex@ubuntu:~/Copter-4.3$ sudo ./build/nxflight/examples/INS_generic
AP_InertialSensor startup...
Init Gyro***********

Accel Offsets X:0.00000000       Y:0.00000000    Z:0.00000000
Accel Scale X:1.000000   Y:1.000000      Z:1.000000
Gyro Offsets X:0.01069567        Y:-0.00608047   Z:0.01430683

Number of detected accels : 1
Number of detected gyros  : 1

Complete. Reading:

Menu:
    d) display offsets and scaling
    l) level (capture offsets from level)
    t) test
    r) reboot
r

this is with a mpu9250 breakout and the bmp280 connected via i2c

42

I was able to get ardupilot to run and connect to qgroundcontrol but then it disconnected. Need to see if I need to recompile arducopter to have it be more verbose to see what is causing this. Will still be looking at the icm board as well.

43

I believe your problem can be related to i2c
Check the dmesg log to see if there is a lot of i2c timeouts.
What you made to have the things working?

Regards

44

I am using the mpu9250 and bmp280 in i2c to get things to this point on the orin nano. Couldnt get the bmp280 working with the spi config not sure why. With the bmp280 connected via i2c the baro example segfaults after calibrating. When running arducopter I can definitely see it probing all the i2c busses. the bmp280 is configured to use bus 7 with address of 0x76 for the bmp280. this board has 12 i2c busses so not sure if there is a way to set the i2c busses that I want to use and not try to probe the others.

45

Have you checked the dmesg ?

the segfault in the Baro example is normal, and it’s an indication that is working.
With pocket beagle, I had to check, when was trying to read the i2c-1, that is used by power management system, the I2C test was not ok, and in the dmesg there was several i2c timeout messages and if I wait 25 minutes que ardupilot starts once the i2c probe was done.
Maybe once you know what is the bus, you can change the I2CDevice.cpp and in some point I was checking what was the bus and returning null when was the bus 1.

like this one:

Line 378,

46

in dmesg I was seeing it probing i2c busses while running arducopter. It uses bus 7 on the device and the config in ardupilot is set for that. so you are saying I should have a conditional for the board that would just return a nullptr if the bus is 7?

#if CONFIG_HAL_BOARD_SUBTYPE == HAL_BOARD_SUBTYPE_LINUX_NXFLIGHT
    if(b.bus == 7) {
        return nullptr;
    }
#endif
47

In true the opposite.
Just continue/use the bus 7.
Ignore all others.

48

Sorry. I read your thread, but I have a few questions.
How to implement Servo_out on GPIO, and where are they listed in hwdef?

49

I am still working on my project, but I have to move some webapps to gcp etc and helping with a startup. The fact that you mentioned hwdef does that mean you are using an stm32 based board? the hardware would be the first thing that needs to be known.

50

Servo outputs are PWM pulses, to use GPIO in some way you need to generate PWM pulses using GPIO.

As @awright424 said, the hwdef file is for stm32 boards with chibios, with linux you need to change the header for linux boards(https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL/board/linux.h)

51

Hi
Were you able to resolve this? I am in a similar position - I want to design a custom PCB with IMU, baro etc, so I decided to test various parts using OBAL and Ardupilot running on a Pi Zero W 2.

As recommended on the OBAL site, I first had good results using an MPU9250 breakout board, but this part is no longer manufactured, and the ICM-20948 offered in its place. I had a Waveshare PICO-10DOF_IMU on hand, so i tried that. Eventually I got it configured to connect on the I2C bus using (in linux.h):

// Waveshare Pico 10-DOF IMU Connection on I2C
    #ifdef HAL_BOARD_SUBTYPE_LINUX_OBAL_V1_PICO_10_DOF
        #define HAL_INS_PROBE_LIST PROBE_IMU_I2C(Invensensev2, 1, 0x68, ROTATION_NONE)
        #define HAL_MAG_PROBE_LIST ADD_BACKEND(DRIVER_ICM20948, AP_Compass_AK09916::probe_ICM20948_I2C(0, ROTATION_PITCH_180))
        #define HAL_BARO_PROBE_LIST PROBE_BARO_I2C(LPS2XH, 1, 0x5C)
    #endif

[please note: rotations may not be correct]

The artificial horizon in QGC looked weirdly laggy and wrong, however.
I wondered if this was because the ICM-20948 was running much more slowly over I2C, compared to the MPU9250 on SPI, so I hacked the Waveshare board to connect on SPI and used:

// ICM-20948 IMU Connection on SPI
    #ifdef HAL_BOARD_SUBTYPE_LINUX_OBAL_V1_ICM_20948_SPI
        #define HAL_INS_PROBE_LIST PROBE_IMU_SPI(Invensensev2, "icm20948", ROTATION_NONE)
        #define HAL_MAG_PROBE_LIST PROBE_MAG_IMU(AK09916, ICM20948, 0, ROTATION_NONE)
    #endif

So far, however, whoami() on the ICM-20948 is returning 0x00, so the IMU initialisation is failing.

I tested SPI on the Pi Zero using spidev-test (I didn’t know about it - thanks for that :grinning:) and it seems fine.

There seems to be a lot of code to support the ICM-20948, but it’s also NRND. It seems like 9 DoF sensors are getting harder to find since the chip shortages.