pinMode OUTPUT_AF_OD vs OUTPUT_OD

[Mapy542]

I recently ran into a knowledge issue regarding the utilization of pinMode on the Ch32v003. While writing a small script for a project, I wished to use the open drain IO mode for some communication pins. Intellisense autofilled OUTPUT_AF_OD over OUTPUT_OD for this selection for whatever reason. I wasn't aware the OUTPUT_OD declaration existed. I assume AF stands for alternate function.

pinMode() does not have the switch statement for handling this AF case, and triggers an error. Since to my knowledge there is no alternate mode for ch32v003 pins, I propose to either remove the macro for chips where it does not apply, or add a case to the pinMode function.

I wanted to post this issue to get maintainers opinon on which course of action would be best for a PR, or if I'm mistaken on the purpose of the macro why it functions as it currently stands. Thanks!

[maxint-rd]

Hello @Mapy542 - just a quick reply to set some expectations.

At the moment this core is not actively maintained by WCH. Improvements are submitted s PR's by a small community of people that are interested. These PR's are not incorporated by WCH into new official releases. There are no community members that can do this.
However, there are unofficial releases that may contain some or more of the PR's, such as this release by @DeqingSun as mentioned here.
Personally I'm a maker and contributed most of the changes that I needed for my projects. I try to answer to issues whenever I find some spare time.

At the moment I haven't looked into the pinMode() macro's you mention. None of the macro's mentioned are used in the standard Arduino core. In regular Arduino sketches one would use input mode to make the pin behave as open drain. The regular Arduino modes are: INPUT, OUTPUT or INPUT_PULLUP, so the various other OUTPUT_modes are CH32 specific.
This core supports multiple CH32 chips. The V003 is the smallest in the family, so perhaps the definitions mentioned relate to other CH32 members. Before removing anything you probably should make sure it doesn't break using them when compiling for other CH32 family members. I'm not sure if Intellisense applies the preprocessor when making suggestions, so I'm not sure if adding an #ifdef will help.

(As a general rule PR's should not break anything and improve compatibility with other Arduino cores as much as possible. )