Add rotation support to CO5300 display driver, and BMI270 IMU support for M5AtomS3R targets

[kitazaki]

Summary

Add rotation support to the CO5300 display driver used by esp32/waveshare_amoled_206.

The driver now supports rotation values of 0, 90, 180, and 270, consistent with other Moddable display drivers.

Changes

• Added a rotation getter/setter to modules/drivers/co5300/co5300.js.
• Added native rotation state handling in modCo5300.c.
• Updated width and height getters for 90/270 degree rotation.
• Added validation for unsupported rotation values.
• Added software pixel rearrangement for 90, 180, and 270 degree rotation.
• Preserved the existing fast path for 0 degree rotation.

Notes

The CO5300 does not appear to provide a MADCTL-style row/column exchange mode suitable for 90/270 degree rotation. Non-zero rotations are therefore handled in software before pixel data is sent to the display.

Rotated modes may be slower than the default 0 degree mode, but existing behavior is unchanged when rotation is not set.

Testing

Tested on esp32/waveshare_amoled_206, which uses the CO5300 display driver.

Verified the following rotation values with examples/piu/cards:

• 0
• 90
• 180
• 270

[kitazaki]

Summary

This PR adds BMI270 IMU support to the M5AtomS3R target family.

Moddable SDK 8.1.0 added support for the BMI270 sensor device.
Since the M5AtomS3R family uses the same BMI270 IMU, this PR updates the corresponding target definitions.

Updated targets:

• esp32/m5atom_s3r
• esp32/m5atom_s3r_cam
• esp32/m5atom_s3r_m12

Changes

• Added the BMI270 sensor driver manifest to the M5AtomS3R target manifests.
• Added device.sensor.IMU definitions for M5AtomS3R targets.
• Added axis correction for m5atom_s3r so the IMU orientation matches m5atom_s3.
• Scaled BMI270 accelerometer values from m/s^2 to g for compatibility with existing AtomS3 IMU(MPU6886) examples.
• Updated examples/drivers/atoms3-imu to handle samples that may not include accelerometer or gyroscope data immediately.
• Added examples/drivers/atoms3r-imu-console for console-based IMU verification on displayless M5AtomS3R variants.

Testing

• examples/drivers/atoms3-imu with esp32/m5atom_s3r
• examples/drivers/atoms3r-imu-console with esp32/m5atom_s3r
• examples/drivers/atoms3r-imu-console with esp32/m5atom_s3r_cam
• examples/drivers/atoms3r-imu-console with esp32/m5atom_s3r_m12

Notes

M5Stack Core2 v1.3 also uses the BMI270 IMU. However, the Core2 hardware configuration changed between v1.1 and v1.3: the IMU changed from MPU6886 to BMI270
a separate PR for Core2 v1.3 after verifying the detection logic for these hardware differences.

[stc1988]

@kitazaki
Thank you for checking on multiple devices.

Added examples/drivers/atoms3r-imu-console for console-based IMU verification on displayless M5AtomS3R variants.

If it’s displayless and doesn’t depend on any specific device, you might try creating examples/drivers/sensors/bmi270. That location makes it easier to verify the driver from other devices as well.

https://github.com/Moddable-OpenSource/moddable/tree/public/examples/drivers/sensors/mpu9250 can serve as a reference. For this device, polling alone might be sufficient.

[phoddie]

The CO5300 does not appear to provide a MADCTL-style row/column exchange mode suitable for 90/270 degree rotation. Non-zero rotations are therefore handled in software before pixel data is sent to the display.

Are you sure about this? The controller appears to be rooted in MIPI. It has MADCTL (0x36), which seems like it might work. Please see section 7.5.29 of the data sheet. If it can work, it would be simpler and faster. Perhaps it is the absence of MV support that is limiting this? At least 180 rotations should be able to bypass the transformation buffer.

If the MADCTL really cannot be used for 90 and 270, we should optimize the transformation implementation because it could be faster. I can share some suggestions.

[kitazaki]

@phoddie

Thank you for pointing this out. I rechecked section 7.5.29 of the CO5300 datasheet.

MADCTL (0x36) is present, but the parameter only defines MY, MX, and RGB.
The MV bit does not appear to be defined for this controller, so I don’t think MADCTL alone can support 90 and 270 degree rotations because those require swapping row/column addressing.

However, I agree that 180 degree rotation should be possible using MY + MX.
I updated the implementation to use MADCTL for 180 degree rotation and keep the transformation path only for 90/270 degree rotations.

[kitazaki]

@stc1988

Thank you for your comment.
I moved the sample to examples/drivers/sensors/bmi270/poll and updated to use the BMI270 driver directly.
It uses device.I2C.internal when available and falls back to device.I2C.default, so it can be used from devices where the BMI270 is on an internal I2C bus as well as from external wiring setups.

[phoddie]

@kitazaki – The change for 180 looks good. I used Moddable Two, which has a MIPI display controller, to experiment with MY and MX to remind myself how those work. You are correct that without the MV we cannot do 90 and 270 purely at the display controller level. Too bad.

But... I think the 90/270 conversion can be improved. Each transaction is relatively expensive – starting/stopping a transaction takes some time. Consequently, fewer transactions have less overhead.

• I'm not certain, but in co5300SendRotated() it seems possible that co5300SetWindow() can be moved outside the loop, so it only happens once. It is fine to do multiple writes.
• The rotation buffer could be bigger. It is only two scan lines. We try to do more like 16 at a time. (Also, the driver could wait to allocate the rotation buffer until needed, so apps running at 0 or 180 don't lose that memory.)
• The loop assumes that it can write either one or two lines (rows = (lines > 1) ? 2 : 1;). But... the number of lines depends on the width of the lines as passed to co5300Begin(). Because Piu uses partial updates aggressively, often the width is much less than the full width. That means that the allocated rotation buffer can hold many more smaller lines than two full lines.
• It would be trickier, but you could have an asynchronous version of co5300SendColorSync(). That would allow some parallelism. I'm not sure how big a win it is compared to the complexity, but the 0 case is async and that helps nicely on Moddable Six (the driver that this code is modeled on).

[kitazaki]

@phoddie

Thank you for the detailed feedback.

I agree with your points. In particular, moving co5300SetWindow() outside the loop and increasing the rotation buffer size should reduce transaction overhead and improve performance for 90/270 rotation.

I will create a small benchmark sample program, test it on the actual device, and share the results. Based on that, I will try to update the implementation with the following improvements:

• Move co5300SetWindow() outside the loop if possible
• Increase the rotation buffer size
• Adjust the number of rotated lines dynamically based on the update width
• Consider allocating the rotation buffer only when 90/270 rotation is used

The asynchronous version of co5300SendColorSync() also sounds interesting, but I think I will first measure the simpler improvements above before adding that complexity.

Please give me a little time to test this.