[enhancement] virtual COM for config purposes

[iDoka]

Hi and thanks for that great work.

It seems nice to have fourth COM port (virtual UART) for configuration purposes instead of jumper manipulation with PB5 pin.
The 4th COM doesn't required custom resources (like bandtwidth or latency) - will not affected to performance of remaining three UARTs.

Happy hacking!

[r2axz]

Hi, @iDoka and thanks for your interest in the project.

Unfortunately, adding a fourth UART will require taking some USB packet memory from one of the existing UARTS. Right now I only have 16 bytes of packet memory available, which I already allocated to enhance the control endpoint in #14

I am able to take some memory from INTERRUPT IN endpoints, but this will result in slower port status updates. I feel really uncomfortable when I permanently allocate resources to a function that is rarely used. I cannot take memory from BULK IN/OUT endpoints because this will limit the available bandwidth.

Plus, I am not so sure it is a good idea to have the configuration port always enabled. If you use the firmware in the context of an isolation or level-shifting circuit, wrong configuration may damage it. So actually, I deliberately made it a little bit difficult to active.

I am going to leave this issue open for a while to see if it gets more comments. Right now I am not sure if it should be implemented the way you suggested. Anyway, currently I am focused on implementing the TXA signal to control RS-485 transceivers and other improvements to the code.

Thank you!

[iDoka]

I accept. Justified reason.

[r2axz]

@iDoka Thank you. Anyways, let's leave it open for a while and see if we get more comments.

[xJurgen]

Personally I think it might be a good reason to have virtual COM just for config purposes or other GPIOs control, wiegand (in my use-case it's a must have)...

[r2axz]

@xJurgen there is a virtual com port for config purposes, it is just not activated until you ground PB5. Please read the docs. Or, if you meant you need it to be always active, please describe your use-case.

[xJurgen]

I meant always active. As I've written before, I need it for wiegand protocol communication

[r2axz]

@xJurgen and how exactly is it going to be used for wiegand protocol? Do you implement additional commands for that or what?

[xJurgen]

I need it as a Wiegand to UART communication translator. Nevertheless I can't use U(S)ART1-3 ports for it because I need them to be connected to some other peripherals so the virtual COM is the only option I have.

[r2axz]

@xJurgen, so, if I understand this right, you are going to implement some additional functionality (additional commands) specifically for the needs of the Wiegand to UART communication translator? At the same time, you need three UARTS, so you can not use PB5. Is that correct?

[xJurgen]

Yes, that's correct. I will have a Wiegand device connected to PB8/PB9 (I don't need DCD for UART2/UART3) and i need to read from it through USB (UART) protocol (that's the Wiegand to UART communication translator i mentioned before) - so the virtual COM is needed.
I can't use PB5 and also I would like to switch to config mode internally by using some sort of command.

[r2axz]

@xJurgen Thank you for the explanation.

PB8/PB9 are currently allocated for DCD lines of UART2 and UART3. I assume you are going to change this. Next, you are going to add functionality (Wiegand to UART), which is not part (and out of scope) of bluepill-serial-monster. For the above reasons, you are requesting a change to bluepill-serial-monster, which will degrade its performance (see above for endpoint sizes), but is not really "must have" for the original project. It is rather needed for your particular application.

In this case, I suggest you to fork the project (I assume you already did that), and change it as needed. I still fail to see how permanently enabled configuration port can be beneficial to bluebill-serial-monster given its original purpose (USB to UART converter).

[r2axz]

Looks like the majority of the users are happy with the current implementation. Given the justification in #15 (comment), I'm closing this issue.