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

Experimental support for CH340, FT232RL & CP2101 devices #460

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

tr1p1ea
Copy link

@tr1p1ea tr1p1ea commented Nov 19, 2023

Experimental support for CH340, FT232RL & CP2102 devices.

Tested with ESP8266 D1 mini clone, ESP-WROOM-32 board and FTDI232 boards.

Currently baud rates are table driven so baud rates are limited to: 9600, 19200, 38400, 57600 & 115200 but can be easily expanded.

@mateoconlechuga
Copy link
Member

Looks good to me!

@mateoconlechuga
Copy link
Member

Does the C header need updating?

@tr1p1ea
Copy link
Author

tr1p1ea commented Nov 30, 2023

I fixed an issue with CH340 clones and I'm adding CH341 today.

I'll also update the header file.

@mateoconlechuga
Copy link
Member

Is it good to merge?

Experimental support for CH340, FT232RL & CP2101 devices.

Tested ESP8266 D1 mini clone, ESP-WROOM-32 board and FTDI232 boards

Currently baud rates are table driven so baud rates are limited to: 9600, 19200, 38400, 57600 & 115200 but can be easily expanded.
Updated baud settings table to fix CH340 (clones should now work)
@adriweb adriweb marked this pull request as ready for review December 4, 2023 19:17
@adriweb
Copy link
Member

adriweb commented Dec 4, 2023

rebased and launched CI just to check

ring_buf_ctrl_t rx_buf;
ring_buf_ctrl_t tx_buf;
srl_error_t err;
uint8_t reserved[16];
Copy link
Member

@mateoconlechuga mateoconlechuga Dec 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little worried about this change - does this break out backwards compatibility with user allocated structures? @commandblockguy @tr1p1ea

The issue is someone using a program compiled for an old version of the lib, and using a newer lib.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could new fields be added at the end instead, and the reserved array shortened?

Copy link
Member

@mateoconlechuga mateoconlechuga Dec 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is why the structure should be big enough to support forwards compatibility and the addition of fields - also moving of fields breaks backwards compatibility for all programs too. See how fatdrvce handles this for reference.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adriweb no, because the structure is user-allocated. so using a newer library would corrupt memory.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Memory corruption could only happen if the total size of the struct changes, right?
In hindsight, yeah, it probably wasn't a good idea to make the internal structures visible - I mostly only did that to ease debugging, and didn't get around to removing them before actually releasing it.
Aside from the device field, I don't imagine that people have used the struct fields - it would probably be a good idea to deprecate them.

@mateoconlechuga
Copy link
Member

@tr1p1ea what is the status of this PR? Also @commandblockguy, which struct fields can we deprecate to make everything reserved?

@commandblockguy
Copy link
Member

We can probably deprecate everything except for the USB device handle.

@mateoconlechuga
Copy link
Member

Great :)

@tr1p1ea
Copy link
Author

tr1p1ea commented Jan 5, 2024

After testing I've come to the conclusion that there is some further work to do to improve compatibility with some devices.

Should I recall this PR until that's complete?

Also did you want the struct optimisation to be part of this too?

@adriweb adriweb marked this pull request as draft January 5, 2024 22:50
@mateoconlechuga
Copy link
Member

mateoconlechuga commented Jan 18, 2024

@tr1p1ea yes to the struct optimization and any fun new status updates for us :)

It's fine to just keep it in this PR

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

4 participants