sudo modprobe cdc-acm
Appuyer sur le bouton RESET du FPGA ne reset pas l'AVR !
Attention, sur le pinout, c'est pas parce qu'un pin a un numéro d'équivalence (par exemple D21) qu'il est effectivement controllable par l'AVR !
Ne pas oublier que le FPGA doit driver ARD_RESET à 1 pour que l'AVR reste allumé !
Essayer de programmer le FPGA avec les ports 7 et 8 en inout, assignés à 1'bZ (haute impédance). Sinon le FPGA drive les ports LOW.
Le plus simple que j'ai trouvé est un protocole série sur deux pins communs. Malheureusement, j'ai l'impression que l'AVR ne supporte pas le SoftwareSerial par défaut. J'ai donc utilisé une version minimaliste de SoftwareSerial (https://code.google.com/p/arduino/source/browse/trunk/libraries/?r=1119)
Coté FPGA, j'ai utilisé le “RS-232 RX and TX module” de fpga4fun.com
Ca marche plutot bien à 9600 baud, mais pas trop au-delà (sans doute à cause du soft serial de l'Arduino)
La datasheet est ici : http://www.issi.com/WW/pdf/61-64WV5128Axx-Bxx.pdf
Ouhlà, il n'y a pas plus simple ? Non.
Vérifier que le fichier de contraintes .ucf est bien lié au module courant dans ISE. Pour le déplacer dans la hiérarchie : * Project → manual compile order * Clic droit-propriétés sur le .ucf et changer le “module association” * Décocher Project → manual compile order
* Vérifier que le .ucf est bien associé au module courant * Enlever toute charge du pin. Le drive est très faible, s'il y a besoin de résistance de PULLUP, utiliser au moins 100KOhm (je pense)
J'ai eu ce problème. Workaround : sélectionner le port FPGA et utiliser AVR- No USB - ISP. Cela permet d'utiliser le FPGA comme programmateur au lieu de passer par le cable de l'AVR
Je n'ai pas réussi à le faire… Les pins TX/RX (1/0) ne communiquent pas directement avec l'USB mais passent par une puce cheloue…
Par contre, ça marche très bien avec le cable FTDI en utilisant le module “RS-232 RX and TX module” de fpga4fun.com On peut aussi parler à l'AVR en serial puis le laisser répéter via le cable serial “normal” (le cable microusb)
L'avantage est qu'il n'y a pas besoin de cable supplémentaire (FTDI), par contre ça limite le baudrate à 9600 et c'est plus lourd à mettre en place (et ça monopolise quasiment l'AVR)
Parfois il est nécessaire de convertir les sorties 3.3V en sorties 5V avec un transistor, mais (de ce que j'en ai vécu) c'est surtout source de problème. N'utiliser cette solution qu'en dernier recours (vous êtes _SURS_ que ça marche pas en 3.3V ? Souvent les pins de contrôle sont compatibles 3.3V, même si l'alim demande 5V)
Verilog est un langage puissant et certaines de ses fonctions (par exemple la division ou le délai (#)) ne sont pas synthétisables, elle ne sont utiles que pour débugger…
Changer de cable