[Solved] USB Serial without DTR

[Tazzi]

Ok so, Im using a F303 and F446 with USB CDC Serial and both seem to have the the DTR option enforced.

The issue I am facing is I am designing a tool to interface with generic software which usually connects to a standard Serial Port which does not utilize DTR or RTS.

I can create the exact situation in my own software, where I will not receive data from either board unless I do SerialPort.DtrEnable = true;

I understand the purpose of DTR is to ensure data is not missed/lost, but in this circumstance it does not matter. The old Roger USB implementation did work without DTR, which is what I would like to try have achieved on the new ST core

Anyone have experience with this?

[Tazzi]

Solved.

I commended out all the DTR coding in usbd_cdc_if.c, and set linestate = 1.

This now has the exact desired effect where DTR is no longer required. Hope that helps someone else!

[fpiSTM]

OK

[mrburnette]

OK

I really think this is NOT OK. It is OK that the Op is skillful enough to work around the core and libraries to get the behavior s/he wants, but is there really a need that cannot be managed by another avenue? If such things are required, it would seem that the library should be overloaded such that necessary behavior can be controlled, when appropriate. It just makes the best business sense to tell end-users to stay out of the core and provided libraries and to have provisions implemented to ensure you can back that up by giving an example of the proper work-around technique.

Ray

[Tazzi]

Im sure I could raise a request on the github repo to have it looked into.
Generally the forums are designed for people to ask questions around how to use current libraries or where they are having issues.

The team unfortunately can't be expected to know the core inside/out as its massive, and making tailor made changes for every user will result in a huge mess

I always put my findings cause it means anyone looking to do the same can easily enough copy. And I can quickly double check what I changed when updating to newer core revisions

[fpiSTM]

OK

I really think this is NOT OK. It is OK that the Op is skillful enough to work around the core and libraries to get the behavior s/he wants, but is there really a need that cannot be managed by another avenue? If such things are required, it would seem that the library should be overloaded such that necessary behavior can be controlled, when appropriate. It just makes the best business sense to tell end-users to stay out of the core and provided libraries and to have provisions implemented to ensure you can back that up by giving an example of the proper work-around technique.

Ray

@mrburnette
when I said OK, this means "OK, you find a workaround". I could not implement all nor check all. This is a community project and any contribution are welcome. User can provide easily a PR to add a new method to handle USB DTR management or use a define to disable it. I didn't check how to do this and I will not as I've around more than 300 tasks to handle... So the fact Tazzi found a way to unblock his use case is fine and it is also fine he shares the way to "solve" it quickly.

[fpiSTM]

I've made an API to manage DTR usage. See https://github.com/stm32duino/Arduino_C ... /pull/1382

[ag123]

hi fpistm, thanks, though i've not actually gotten down to verifying it. the emulation of DTR probably caused confusion as some serial terminals did not implement the protocol to signal DTR. hopefully, that'd resolve some problems.
but that literally without verifying if a 'host' is connecting, the only solution is to discard output (to the host) if the circular buffer is full or things will 'hang' / stall. it is up to the sketch to make a 'reliable' comm with the host, e.g. some kind of send / ack thing above the Serial.print() layer.
or like such so called 'blocking' implemenntation (the sketch have to do it themselves)
viewtopic.php?p=6705#p6705