This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
I2C port configurable
#1
Currently I'm using Openplotter on an Odroid.
Difference between Odroid and  Pi4 is mainly /dev/i2c-2 vs /dev/i2c-1 and the lack of integrated wifi.

I don't use Openplotter-Wifi since I can use the tools from the distribution for that.
The difference in I2C ports cause a lot of small nagging problems, which should not be there if the software was generic.
Hardcoding the I2C ports speeds up the development in short term, but I believe it will ultimately causes more problems then necessary.

With regards,
HR

==========
Of the Raspberry-only tools I guess the ones below should work with minimal changes:
- Xygrib
- I2C sensors
- Pypilot

I haven't tried the Moitessier HAT, 1W and analog sensors.
I2C works mostly if I make a softlink from /dev/i2c-2 to /dev/i2c-1, but the mpu9250 fails currently.

Canboat can be installed using "apt-get --build source ...".
With canboat, openplotter-can and signalK also work.
I expect Xygrib to work to work in the same way.

My current system is Ubuntu 18.04 with the extra packages from OpenPlotter as below:

openplotter-can                           2.1.0-stable
openplotter-dashboards              2.1.0-stable
openplotter-i2c                            2.1.0-stable
openplotter-pypilot                      2.0.7-beta
openplotter-settings                    2.2.0-stable
openplotter-signalk-installer        2.1.0-stable
canboat                                       1.2.4-stable
xygrib                                          1.2.7 (github)

The OpenCPN installer works generally, but I currently use OpenCPN from github with more and newer plugins than OpenPlotter can provide right now.
(Until the package manager from OpenCPN becomes fully operational I guess.)
  Reply
#2
As you know we are focused in RPi and never tested OP in others embedded cards. Those changes you propose would be easy if we have a method to detect the host system is an embedded system (RPi, Orange Pi, Banana Pi, Odroid...). Do you know a good way to check this?

We are ready for the coming OpenCPN and managed plugins but we will never add alpha and beta versions to OpenPlotter.
  Reply
#3
With "cat /proc/cpuinfo" or "i2cdetect -l" most information can be obtained. If you need more information, please ask.

Below you find:
- RPI4 (for reference)
- Odroid N2 (my target)
- RockPro64 (I probably won't use it with openplotter-i2c, but it was here).
I shortened the information a little since most data is simply the same information with a different core number.

I think more generic code for openplotter-i2c, openplotter-can and openplotter-pypilot is a good thing of itself. A configurable I2C port would be very helpfull even without explicit support for my system.

<off-topic>
My intended use would be the compass-only mode, providing pressure and heading from a MPU9250 + BMP280 to SignalK.

Currently RTIMULibDemoGL works without a problem with a MPU9250 (with SignalK in the background, being fed from from other sensors via openplotter-i2c and canboat). However when I try openplotter-pypilot the i2c-bus gets blocked.

I suspect I missed some i2c command while trying to get openplotter-pypilot to work. I will report it if I find the cause (even without support).
</off-topic>

==========
Raspberry Pi 4:
$ cat /proc/cpuinfo
processor : 0
model name : ARMv7 Processor rev 3 (v7l)
BogoMIPS : 270.00
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 3
..
Hardware : BCM2835
Revision : b03111
Serial : 100000002ad088c4
Model : Raspberry Pi 4 Model B Rev 1.1
$ i2cdetect -l
i2c-1 i2c bcm2835 I2C adapter I2C adapter

==========
The Odroid:
$ cat /proc/cpuinfo
processor : 0
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4
..
processor : 5
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd09
CPU revision : 2

CPU info : 290a4000010e1900000c303254524d50
Serial : 4682a6ca-f9ce-4159-b157-001e06423e0b
Hardware : Hardkernel ODROID-N2
Revision : 0400

(AmLogic S922X: 2x A53 like the RPI3 + 4x A73)
$ i2cdetect -l
i2c-3 i2c Meson I2C adapter I2C adapter
i2c-2 i2c Meson I2C adapter I2C adapter

Mostly the i2c-2 is used.
The second i2c-bus is used for the RTC (but is is also accessible through the 40pin header).

==========
The RockPro64:

$ cat /proc/cpuinfo
..
processor : 3
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd03
CPU revision : 4

processor : 4
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 2

processor : 5
BogoMIPS : 48.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x0
CPU part : 0xd08
CPU revision : 2

Serial : 0000000000000000

(RK3399: 4x A53 like the RPI3 and 2x A72 like the RPI4)

# i2cdetect -l
i2c-0 i2c rk3x-i2c I2C adapter
i2c-1 i2c rk3x-i2c I2C adapter
i2c-4 i2c rk3x-i2c I2C adapter
i2c-8 i2c rk3x-i2c I2C adapter
i2c-9 i2c DesignWare HDMI I2C adapter
i2c-10 i2c DP-AUX I2C adapter

I assume i2c-8 is available through the Pi2 40pins connector.
  Reply
#4
OK, thanks for this report, we will go into this soon (after the stable release is published)
  Reply
#5
I promised some update if I knew more:
- after getting an error of wrong ID (112) I replaced the MPU with another MPU9250
(exchanging the cheap noname MPU by a Sparkfun worked here).
- I hardcoded on every spot i2c-bus = 2 (as required by my hardware)
- the RTIMULib still uses some autoconfiguration, where a default i2c-bus of 1 is assumed
after setting the RTIMULib.ini the RTIMU also works correctly.

After these changes most Openplotter scripts work.
Since I have to give a password for sudo I needed some changes in sudoers to get everything working without auth.
And I did not use Openplotter by the book, but after openplotter-i2c-read and openplotter-pypilot-read were running
the configuration tools worked as well.

The problems with the IMU became visible after the umpteenth reinit when using pypilot_boatimu without options.

Most changes for openplotter-i2c where pretty straightforward replacements of the i2c-bus in python.
Configuring RTIMU made openplotter-pypilot work (and one changed i2c-bus in a i2cdetect call).

The reason to still ask you to implement the a configurable i2c port is that those features should be upstreamed when possible (and my coding style is quite bad).

Through it all I got one other feature request:
For pypilot the data needs to be obtained in realtime, when using the IMU in compass-only mode, could the measurement frequence drop to perhaps once every 1-10 seconds?
I think after accuracy powersaving gets more important for compass-only. Or perhaps this was allready requested?
  Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)