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 opportunityIl 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.
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.
la source