Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ENHANCEMENT] Increase I2C M260 buffer size #4343

Closed
me25542 opened this issue Dec 14, 2024 · 4 comments
Closed

[ENHANCEMENT] Increase I2C M260 buffer size #4343

me25542 opened this issue Dec 14, 2024 · 4 comments
Labels
enhancement Improvement proposal based on existing features. good first issue Good first issue for new developers.

Comments

@me25542
Copy link

me25542 commented Dec 14, 2024

Printer model

All that support I2C

Describe the enhancement

The current implementation of the M260 command is great, and allows users to communicate with external devices. However, the maximum buffer size of 32 bytes can be limiting. I don't know if this is a hardware restriction, or in software. I did look in the STM32F427ZIT6's datasheet, and couldn't find anything. If this is a hardware limitation, let me know and close the issue.

Expected functionality

The print file would be able to add, say, up to 256 bytes to the buffer, and send it all in one command.

@me25542 me25542 added the enhancement Improvement proposal based on existing features. label Dec 14, 2024
@CZDanol CZDanol added the good first issue Good first issue for new developers. label Dec 14, 2024
@bkerler
Copy link
Contributor

bkerler commented Jan 9, 2025

As we are discussing internally if sending 256 bytes in one round does make any sense instead of sending 8*32 byte packets in sequence, can you please let us know your specific use case ?

@me25542
Copy link
Author

me25542 commented Jan 9, 2025

I have a custom "smart" enclosure connected to the printer via I2C, and for most commands from the printer to the enclosure 32 bytes is enough. But, for setting a print name to be displayed on the enclosure, 32 bytes is often too short. I have implemented a workaround for this, enabling the data to be split into multiple 32-byte packets. However, it would be easier to send a single larger packet. This is low priority since implementing the workaround on my enclosure, but it would be nice. ☺️

@me25542 me25542 closed this as not planned Won't fix, can't repro, duplicate, stale Jan 10, 2025
@bkerler
Copy link
Contributor

bkerler commented Jan 10, 2025

Thanks. PR is already written, let's see how the dev gods will decide :D

@me25542
Copy link
Author

me25542 commented Jan 11, 2025

ok lol

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Improvement proposal based on existing features. good first issue Good first issue for new developers.
Projects
None yet
Development

No branches or pull requests

3 participants