Go Down

Topic: Différences entre USB natif et serial via CP 2102 sur Arduino Mega (Read 176 times) previous topic - next topic

inryjo

Bonjour à tous,

J'ai fait une appli C# qui communique avec un arduino mega.
Lorsque j'utilise l'USB intégré à la carte (donc transitant via le Atmega16U2) tout se passe au mieux en termes de vitesse.
Lorsque je passe par les pins TX0 et RX0 reliées à un adaptateur USB TTL sur CP2102, tout est beaucoup plus lent.
Pourriez-vous m'expliquer pourquoi ?
Une histoire de buffer ?

Merci d'avance

J-M-L

Please do not PM me for help,  others will benefit as well if you post your question publicly on the forums
Pas de messages privés SVP

_pepe_

Bonjour

Si l'on constate une baisse de débit avec une même vitesse paramétrée (baud rate), alors la différence est certainement imputable à l'adaptateur, à la liaison USB entre lui et le PC, ou au pilote qui le prend en charge (du fait de son mode de fonctionnement ou de son paramétrage).

inryjo

Tout à fait, le code est identique dans les 2 cas donc le baud rate reste le même dans les 2 cas, seule la connexion physique change.
J'ai essayé la mise à jour du pilote sans grand changement, j'ai commandé un convertisseur USB TTL sur FT232, on verra si ça change quelque chose.

fdufnews

TX0 et RX0 sont les broches qui sont connectés à l'Atmega16U2 donc il y a conflit.
Il faudrait utiliser l'un des autres ports série.

inryjo

TX0 et RX0 sont les broches qui sont connectés à l'Atmega16U2 donc il y a conflit.
Il faudrait utiliser l'un des autres ports série.
Je ne pense pas au conflit car j'ai aussi ce problème sur un PCB maison à base d'atmega 2560 qui n'embarque pas de 16U2 et que je programme directement via l'adaptateur USB TTL

trimarco232

Quote
Je ne pense pas au conflit car j'ai aussi ce problème sur un PCB maison à base d'atmega 2560 qui n'embarque pas de 16U2 et que je programme directement via l'adaptateur USB TTL
Bonjour,
pas très scientifique comme raisonnement ...

inryjo

Bonjour,
pas très scientifique comme raisonnement ...
Euuh ça me semble pourtant logique vu que fdufnews me dit qu'il y a conflit avec le 16U2, remarque tout à fait pertinente. Donc s'il y a effetivement conflit avec ce µC, la logique voudrait qu'on essaie sans. Ce qui est dans mon cas possible dans la mesure où j'ai une carte faite maison qui n'embarque pas de 16U2 que je programme directement. Or sans 16U2 comme intermédiaire j'ai toujours le problème de base ce qui m'a permis de conclure à un autre problème.
Où mon raisonnement serait-il erroné ?

trimarco232

Bonsoir,
les 2 problèmes peuvent coexister, donc la mise en évidence du 2ème ne permet pas d'écarter le 1er
c'est en effet peu probable, mais crois moi, déjà vu !

Go Up