Débutant en série: pourquoi ne puis-je pas simplement brancher les fils?


14

J'essaie de transmettre d'un ATtiny85 à un PC en utilisant du code Arduino-esque sur un convertisseur USB-série sans comprendre grand chose. J'ai été choqué et consterné que cela n'ait pas fonctionné.

J'ai confirmé que le petit scintille la tension sur l'une de ses broches, mais lorsque je connecte cette broche pour transmettre ou recevoir sur le câble série USB et essayer d'écouter à l'aide d'un programme de terminal, je n'obtiens rien.

Je ne sais pas comment dire quelle partie est cassée.

Ai-je besoin de plus de VCC, GND et TXD pour transmettre en série?


Détails:

Le code pour le petit est écrit dans l'environnement Arduino et un code similaire clignote avec succès les 4 broches "PORTB", au moins selon les LED. J'utilise le code de HLT et Saporetti pour me permettre d'utiliser le dialecte Arduino de C ++ pour le programmer. Le programme est toujours sous un K.

#include <SoftwareSerial.h>

SoftwareSerial s(0,1); //receive on "0", and transmit on "1" aka "PB1" aka pin 6

void setup() { s.begin(4800); } // assuming 1Mhz, 4800 baud
void loop() { s.println(millis()); } // transmit something at every opportunity

Il y a beaucoup de traduction impliqué, mais le code est assez basique. Le code qui définit le débit en bauds semble supposer 1 MHz, mais heureusement, mon attention a des fusibles par défaut et fonctionne à 1 MHz. En tout cas, la broche 6 clignote sa tension en fonction de la LED.

J'utilise donc les petits fils pour connecter l'extrémité "ftdi" du convertisseur série USB FTDI au minuscule: noir à GND, rouge à VCC, orange à 6. J'ouvre le programme "minicom" sur le PC, règle le baud taux à 4800 et attendez, rien. Lorsque je parle à mon Boarduino , cela ne pose aucun problème.

Le câble convertisseur FTDI a le brochage suivant: le noir est GND, le brun est "CTS", le rouge est VCC (+ 4,98 V), l'orange est "TXD", le jaune est "RXD", le vert est "RTS".

Si je veux transmettre du minuscule au PC, dois-je faire clignoter la tension sur "TXD" ou "RXD"? En d'autres termes, le fil de transmission doit-il transmettre de l'esclave à l'hôte ou de l'hôte à l'esclave?

En fait, j'ai essayé les deux, ni travaillé. J'ai frit moins d'un dollar d'équipement jusqu'à présent, et je deviens arrogant, alors je branche simplement des fils dans le câble. Peut-être que je ne suis pas censé ignorer les fils "CTS" et "RTS"?

Dois-je utiliser d'autres fils? Est-ce que RTS et CTS font quelque chose?

Le matériel est un ATTiny85-PU (boîtier DIP-8, fonctionnant à 1 MHz, évalué à 20 MHz) alimenté par USB à 4,98 V. Le PC hôte est un MacBook, et il fait avec succès tout ce qui est arduino, y compris en utilisant ArduinoISP pour programmer l'ATtiny pour qu'il clignote son petit cœur.

Réponses:


9

Vous pouvez certainement transmettre des données en utilisant uniquement TX & GND.

Tout d'abord, vous voulez connecter la ligne ATtiny85 TX à la ligne FTDI RX (jaune sur le TTL-232R). Assurez-vous que l'adaptateur USB peut gérer 5V - je suis assez sûr que même le 3,3V TTL-232R est tolérant à 5V.

Selon l'exemple de page pour SoftwareSerial , vous devez définir la direction des lignes TX et RX dans votre fonction de configuration:

// include the SoftwareSerial library so you can use its functions:
#include <SoftwareSerial.h>

#define rxPin 2
#define txPin 3
#define ledPin 13

// set up a new serial port
SoftwareSerial mySerial =  SoftwareSerial(rxPin, txPin);
byte pinState = 0;

void setup()  {
  // define pin modes for tx, rx, led pins:
  pinMode(rxPin, INPUT);
  pinMode(txPin, OUTPUT);
  pinMode(ledPin, OUTPUT);
  // set the data rate for the SoftwareSerial port
  mySerial.begin(9600);
}

La vitesse de transmission sera de 4800 dans votre cas. La bibliothèque SoftwareSerial ne semble pas prendre en charge CTS et RTS, alors assurez-vous simplement que vous ne les utilisez pas sur le logiciel hôte.

Vérifiez page de référence pour plus de détails, où ils parlent de certains problèmes de synchronisation potentiels qui peuvent être exacerbés si vous exécutez à 1 MHz en utilisant l'oscillateur interne sur le petit.


Merci! La page de référence indiquait clairement que 4800 était trop rapide, donc je suis tombé à 300 bauds et les choses vont "mieux". Le pinMode n'affecte pas la transmission, mais je l'ai quand même ajouté pour rendre les choses plus claires. J'essaie maintenant de ralentir la modification du délai entre les bits jusqu'à ce que quelque chose soit reçu. Minicom vient de montrer? marques en ce moment. Pire cas, mes oscillateurs 16 MHz et 20 MHz arrivent vendredi.
Jack Schmidt

Pensez-vous que cela pourrait être le problème de tension? Ajuster le timing n'a toujours pas fonctionné, et je reçois beaucoup de points d'interrogation, donc quelque chose est transmis. Puis-je le réparer simplement en abaissant le Vcc au minuscule à 3V, c'est-à-dire, puis-je simplement le brancher à certaines batteries au lieu d'USB? Dois-je connecter la masse à la fois à la masse USB et à la masse de la batterie?
Jack Schmidt

Oh, merci aussi d'avoir souligné que le fil jaune est pour ma petite transmission. Le fil orange semble beaucoup scintiller (accroché à une LED du PC). Le PC transmet-il ou reste-t-il «allumé» la plupart du temps?
Jack Schmidt

Oui, devrait rester HI en mode veille et scintiller lors de la transmission - je ne sais pas si le FTDI est capable de fournir suffisamment de courant pour alimenter une LED. L'AVR ira bien, mais je retirerais la LED de la ligne FTDI-TX. Crystal devrait résoudre les problèmes de synchronisation (mais vous devez régler les fusibles pour qu'ils basculent de l'oscillateur interne).
Peter Gibson

J'y travaille toujours, mais je suis convaincu qu'il s'agit d'un problème de synchronisation ou d'un horrible problème logiciel Arduino-sur-ATTiny. Quelques 2-3 octets du milieu sont reçus (mais ne sont pas affichés) et les autres sont tronqués sous la forme 0x80. Je vais écrire ma propre (triviale) fonction d'envoi en série soft AVR pendant que j'attends le cristal. Existe-t-il un moyen simple / bon marché de voir ce qui est envoyé? 300 bauds est encore assez rapide pour mes vieux yeux.
Jack Schmidt

7

Donc, la réponse semble être: vous pouvez simplement brancher les fils, en fait juste GND (noir) et RXD (jaune), et tout fonctionne tant que le logiciel est bon.

Choses qui n'avaient pas d'importance:

  • L'oscillateur interne fonctionne très bien. Il semble relativement stable à mes tests limitatifs. À 9600 bauds, tous les problèmes rencontrés sont négligeables.

  • L'utilisation de l'alimentation USB sur les signaux fonctionne très bien. Vous pouvez utiliser une source de tension distincte (partageant une masse commune), mais le câble FTDI lit parfaitement les signaux 3V et 5V. J'ai connecté une batterie, - à GND à la fois du FTDI et du petit, + au VCC du petit, et cela a très bien fonctionné. Cependant, l'utilisation du VCC (rouge) du FTDI (alimentation USB 5V) est beaucoup plus simple et tout aussi efficace.

Choses que j'ai mal faites:

  • La ligne jaune FTDI "RXD" reçoit des bits du microcontrôleur, elle se connecte donc à la transmission sur le microcontrôleur. J'aurais pu comprendre cela moi-même en connectant les lignes de transmission et de réception (orange et jaune) à des LED ou à un Arduino et en vérifiant quelle tension scintillait lorsque je transmettais depuis le PC.

  • Ni SoftwareSerial ni NewSoftSerial ne fonctionnent prêts à l'emploi avec un ATtiny. Bien que l'ATmega328p et l'Attiny85 partagent de nombreuses similitudes, il existe suffisamment de différences pour que le simple fait de compiler l'ancien logiciel pour la nouvelle puce ne soit pas suffisant.

  • Des vitesses de transmission plus lentes ne guérissent pas les choses. 300 bauds nécessitent des routines de retard plus compliquées car le nombre de cycles entre les bits est nettement supérieur à un compteur 8 bits. 9600 bauds fonctionnent très bien, et des taux de bauds plus élevés sont réalisables.

  • Faites attention d'écrire le code critique de synchronisation en C, en particulier dans les fonctions en ligne. Le temps d'exécution dépendra de la façon dont le compilateur l'optimise. En particulier, lors de l'étalonnage du retard en le modifiant simplement de haut en bas, vous obtiendrez une réponse différente de celle utilisée avec un retard constant (temps de compilation détectable), car l'assemblage généré peut être assez différent. Ce n'est pas que C soit "lent", mais plutôt qu'il était trop rapide. À un moment donné, j'envoyais 1s plus vite que 0s (probablement ils sont plus aérodynamiques).

  • Pour démarrer une transmission, vous amenez la ligne LOW (le bit de démarrage), puis vous devez vous assurer que la ligne est à la bonne tension à chacun des 8 points d'échantillonnage suivants, puis assurez-vous que la tension est ÉLEVÉE au 9e échantillon . NewSoftSerial mentionne avoir fait un demi-retard sur le bit de départ, mais cela n'a pas bien fonctionné pour moi. J'ai utilisé un retard de 75% au début et un retard de 125% à la fin.

  • La vraie préoccupation concernant la tension pourrait être qu'une certaine "série" (en particulier RS232) est ± 12V, pas 0V / 5V. J'ai passé beaucoup de temps à essayer de comprendre comment je pouvais ajuster la tension de 5V à 3,3V, mais je pense que c'était complètement hors de propos.

En tout cas, la transmission en série est facile, mais obtenir le timing "parfait" semble assez important. Pour moi, il s'agissait simplement de coder la transmission en assemblage afin de pouvoir compter les cycles.


2
+1 pour 1 étant plus aérodynamique :) Le FTDI TTL232R émet des signaux uart de niveau logique (0-5V), si vous interfaciez directement avec un port série standard, vous auriez besoin d'un IC d'interface tel que le MAX232, qui convertit la tension niveaux dans les deux sens.
Peter Gibson

Félicitations pour l'avoir fait fonctionner. Merci pour votre message détaillé, j'espère que cela aidera beaucoup d'autres personnes avec leurs projets ATtiny.
davidcary
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.