We need to reassign the Serial3 to be an I2C bus. I found this post.
Can I get more details on how to use the Autopilot Parameters to disable serial3 in the autopilot parameters?
1 Like
We want to uses pins 4 and 5 on the 40 pin header to communicate with a battery pack over i2c. Dmesg shows errors when we attempt to impose this configuration on the system using the overlay syntax in /boot/config.txt
@patrickelectric do you have any insight on what we can do to get i2c #3 turned on?
see I2c bus 6 baud rate - #5 by MikeFair also
Hi @MikeFair -
Is there some reason the existing Navigator I2C breakouts do not work for your application?
@tony-white yes
Look, I understand the wisdom of asking a customer what the end goal is, since in many cases the vendor knows of a better way to accomplish the goal that what the customer’s question is implying. However, my personal preference is for the conversation to have two mini-threads: 1) the one suggested by - i.e. how can existing ports in /dev/i2c* be used and also 2) the how-to conversation requested originally.
Hi @MikeFair
Apologies if I offended you in some way?
It may not be possible to move the I2C pins to those used by that serial port - are you using a Navigator at all in your application?
I2C is a bus architecture communications protocol as you’re likely well aware, so multiple devices can be connected to the breakout that exists. The link I included in my initial response details how to access devices on the I2C bus. Please let us know how else we can assist!
Context, in terms of goals, your applications, and pictures, go a long way in making it possible to assist.
we need to talk to a multi-pack battery over Smbus, and we have the following perceptions about what this means for our port config
a) smbus is sensitive to extra traffic
b) smbus is sensitive to speed
c) all devices in /dev/i2c* using the stock blue robotics overlay are likely to have traffic on them for other devices.
d) we think the serial port (I think is #3) is not currently needed for anything (i.e. we have nothing plugged in to that connector on the navHat
Hi @MikeFair
Smbus in general is very sensitive! It’s like someone took the already finicky I2C and decided to make it even more prone to problems!
It may not be an elegant solution, but installing an Arduino (or Teensy?) to talk to your battery pack, and routing communications through it to the system via USB or Serial 3 (uart) is likely the easiest and most straightforward solution. Simply converting serial pins to be used as an independent I2C bus may be technically possible, but would require the addition of hardware pull-up resistors and can run afoul of BlueOS auto-configurations as you’ve already encountered.
We can handle the pullups. I wish we could use your suggested alternatives such as an additional CPU (if we did that, we would use ethernet for all our peripherals, so that we could avoid all the IO taken up by Blue). But I need i2c3.
It seems to me like serial port #3 is not currently being used by anything within Blue, other than the serial connector on the NavHat (which we are not using, at least not for a serial peripheral)