@felmue @mlindholm I recently had the same problem with I2C on an M5STAMP C3U. The appropriate solution seems to be the @mlindholm one, but its sample code was a bit incomplete Here is a working example in the context of a DS3231 RTC A TwoWire structure needs to be inititalised specifically, then referenced by the used I2C library (if any ; RTC library in my case). No need for pullup resistor (in my case) #include <Wire.h> // Declare alternate I2C pins #define I2C_SDA 5 #define I2C_SCL 4 // Setup the TwoWire instance (static memory !) TwoWire I2CM5 = TwoWire(0); void setup () { ... // Initialise the TwoWire instance I2CM5.begin(I2C_SDA, I2C_SCL, 400000); // Ask the library to use this setting // (most I2C libraries accept a TwoWire object as argument of begin) rtc.begin(&I2CM5); ...

@iorex I’ve had partial success using the Roller485 with the pwrCan module. Your setup looks similar to mine, except I’m using a Core3, so my pin numbers are different. First, check whether your motor is in RS485 mode. The screen on the back should show COM: 485. Second, make sure the motor ID is set to 1. The third line on the motor screen should read ID: 0x01. Lastly, confirm that the motor’s baud rate is 115200 (this is the default). If all of the above is correct, you can move on to the pwrCan module. Did you flip the resistor for RS485 to the ON position? Are the DIP switches configured correctly? I was able to control motor speed over RS485, but I still get the error: “Unexpected response length: 32, expected: 17.” It looks like there’s a communication issue from the motor back to the pwrCan module. As an alternative, you can power the motor using the power pins on the RS485 terminal and send commands via I²C. It requires more wiring, but it works with much less hassle.

@felmue That did it! Thanks a lot!

@dov I think I ran in to the same thing if I understand your question. See if this post helps. It works for my situation https://community.m5stack.com/topic/7458/midi-synth-unit-with-din-trs-connectors-sam2695?_=1760294339690

@felmue Dear Felix, Actually, we have done nearly the same thing. We have connected this module: HopeRF RFM95W to the connectors on the back of the Core2. That works great. We have no idea why the LoRa module does not work with the Core2. Maybe a SPI conflict somewhere deep in the background, maybe a power issue or maybe, and more likely, we are lacking some understanding. Anyway, we have decided to use a Proto board, solder the LoRa module on it and place that on the backside of the Core2. We have to do that for 35 devices, but it is fail save. Thanks for all the effort Regards

@martincollett said in M5Stack 4IN8OUT connectors: M5Stack 4IN8OUT those are not usual ones [image: 1758003924007-2pterm0.png] [image: 1758003924022-2pterm.png]

I have determined that this is a problem in the library. Probably a buffer overrun. It reads exactly 10 bytes at a time, always, and uses a fixed-length buffer (char data;). If more data is pending, it might clobber/lose lines. Almost all I2C read code in the library cannot cope with variable-length GRBL output. I am rewriting those parts of the library.

@kuriko thank you for that useful information