Allow external definition of TU_CP210X_PID_LIST

[LarssonOliver]

Describe the PR

Currently, only devices with product IDs 0xEA60 and 0xEA70 are recognized by the cp210x driver. I've had some success with one of the other ids from this list.

Optimally, it would be better if this is managed internally, but by allowing customization of the list at compile-time this may be more easily tweaked and experimented with in the meantime.

Additional context

[hathach]

look ok, but for configurable settings, this should be rename to follow the convention to CFG_TUH_CDC_CP210X_PID_LIST. I could make the change if you are not familar with the codebase. Also please let me know which PID you succesfully test with, so that it can also be added to default list (which is list of tested devices).

[LarssonOliver]

I was able to make it work with PID = 0x800A. I've not tested all the edge cases so I'm not 100% sure if everything works, but it seems to. And to be honest, I'm too unfamiliar with the protocol and the standard to be able to confidently do so either. Receiving and sending serial bytes works.

You are of course right with the naming convention. The reason I did it this way was so that the change was as unintrusive as possible and to not encourage the use of other PIDs that may or may not work. The change did the trick for me as I could compile with:

target_compile_definitions(<redacted> PUBLIC TU_CP210X_PID_LIST=0x800A)

If you think this should be a public config option (i.e. CFG_TUH_CDC_CP210X_PID_LIST), I'll change it, test it, and update the PR.

Let me know what you think.

[hathach]

for user configurable macros, it must be renamed to CFG_TUH_CDC_CP210X_PID_LIST. you also need to move the default value #ifndef from cp210x.h to tusb_option.h right after the CFG_TUH_CDC_CP210X. If you are not confident, also the 0x800A seems not very popular serial device (from your list is SPORTident), we can skip adding it to the default. Thanks.

[LarssonOliver]

also the 0x800A seems not very popular serial device

My thoughts too.

I'll follow your suggestions and update the PR 👍

[LarssonOliver]

@hathach Updated now.

Not sure if there would be value in allowing external definition of FTDI PIDs too, but that should probably be its own PR.

[hathach]

look good, thank you

[hathach]

@hathach Updated now.

Not sure if there would be value in allowing external definition of FTDI PIDs too, but that should probably be its own PR.

yeah, if you happen to work with FTDI, please submit PR as well if possible.