A handheld controller can show changing motion numbers on a laptop and still miss the movement that matters to its user. If your prototype must recognize a quick gesture while updating a screen, the question is no longer whether the sensor responds. You need to know what happens to the readings while the rest of the program is busy.
On our bench we connected a GraftSense KX132-1211 accelerometer module to a GraftPort-RP2040 board, read it from MicroPython and recorded three-axis output. This note follows that setup, then identifies the change needed for a continuous motion record. Our example did not use the sensor's FIFO, a small queue that can hold readings until the controller collects them.
Start with the connection you can actually test
The module plugs into the board's I2C0 socket with a four-wire cable: GP4 carries SDA, the data signal, and GP5 carries SCL, the clock. The module schematic feeds its regulator from 5 V and pulls the data lines up to 3.3 V. That describes the module, not permission to apply 5 V directly to the accelerometer chip.
Resolve one address mismatch before copying any code. Our board drawing labeled the address choices 0x18 and 0x19, but the KX132-1211 documentation gives 0x1E and 0x1F, and our scan found 0x1F. Trust the scan and the device documentation over the drawing labels.
We used MicroPython v1.23.0 and version 1.0.0 of a KX132 driver based on Jose D. Montoya's MIT-licensed MicroPython_KX132. Keep the driver version with the project so the example can be inspected later.
Reproduce the simple reading before adding more work
This version keeps the 400 kHz bus and the repeated acceleration read, and passes the address explicitly to the constructor. Changing only the scan target would leave the constructor using its default address.
i2c = I2C(0, scl=Pin(5), sda=Pin(4), freq=400000)
address = 0x1F
if address not in i2c.scan():
raise RuntimeError("Expected accelerometer address not found")
sensor = kx132.KX132(i2c=i2c, address=address)
while True:
x, y, z = sensor.acceleration
print("x:{:.2f}g, y:{:.2f}g, z:{:.2f}g".format(x, y, z))
time.sleep(0.1)
Our terminal repeatedly showed about x:0.02g, y:0.39g, z:0.91g, where g is acceleration relative to standard gravity. That is a useful communication and orientation baseline. It is not a recording of a gesture or a vibration test.
Keep the board's axes in mind when reading that baseline. Turning the module changes how gravity appears on X, Y and Z. The KX132-1211 is an accelerometer; it is not a gyroscope and does not measure rotation rate directly, whatever a module label may suggest.
Three rates hide behind those changing numbers
The sensor produces measurements at its configured output data rate. The program reads the current output registers at a second rate. The terminal displays values after formatting and transmission, a third. A fast sensor setting does not make the last two keep up.
In this loop, sleep(0.1) alone adds 100 ms per iteration, and bus reads and printing add more, so the loop is not an exact 10 Hz sampler. Our test program also did not explicitly set the sensor's output data rate. Adding a screen refresh to the same loop would stretch the time between reads further.
For a slow tilt indicator, occasional current readings may be enough. For the shape of a gesture, missing the middle of the movement can change the result. A MicroPython developer discussion from July 2024 describes this gap: single-value drivers are convenient, but concurrent work makes continuous acquisition harder. That is the problem to solve, not a reason to abandon MicroPython.
Use a queue when the motion history matters
The KX132-1211 specifications from ROHM/Kionix describe a 512-byte buffer that keeps collecting data while it is being read. With the right configuration and driver, the sensor can retain a sequence while the controller handles other work. Its capacity is finite, though: a controller that waits too long still loses data.
Our driver reads the current acceleration registers and exposes configuration properties, but it does not set up the FIFO, check its fill level or drain a batch. That is additional work. The module schematic also leaves the chip's interrupt outputs unconnected, so there is no ready-made interrupt wire on the four-pin socket. A polling buffer reader or a hardware change would need its own design and test.
Before commissioning that work, describe the movement you need to capture and the longest period the controller may be busy. Choose a sample rate, range and filter setting suited to that movement. Then test a known, repeated motion with the display and communication running, record any overflow, and compare the number of samples collected with the number expected. We have not run these follow-up tests.
The decision for the product brief
This becomes a clear choice. Keep simple current-value reads if the application only needs a slow indication. Ask for buffered acquisition if the sequence between reads matters. A working sensor module is where that decision starts; it is not evidence that every movement is already being captured.