/home/totofweb/homepage
Christophe Le Lann's Homepage v0.8
 

Base PC USB-CAN auto-alimentée

Date d'initialisation : Août 2008
État actuel : Terminé

Sommaire

Base PC USB-CAN auto-alimentée

Description générale

L'objectif de ce montage est de permettre de visualiser l'activité d'un bus CAN sur le port USB un PC (compatible à la fois avec Windows, Linux et Mac), et de pouvoir envoyer des messages sur le bus par la même occasion.

Pour ceux qui ne connaîtraient pas, un bus CAN (Controller Area Network) est un bus de terrain permettant à divers composants électroniques intelligents de communiquer entre eux grâce à seulement deux fils (ligne différentielle). Le grand avantage de ce bus par rapport à des communications par I2C, SPI ou série (UART) est son extrême fiabilité. Là où des erreurs de transmission sont possibles pour ces autres modes de transmission de données, le bus CAN intègre en hardware des vérifications de validité de trame (CRC, stuff error, etc...), si bien qu'il est quasi-impossible d'avoir des messages corrompus (le taux d'erreur résiduel est de 4.7x10-11 !).

Le bus CAN est nativement multi-maîtres et gère très bien les priorités de messages. En cas d'erreur de transmission (parasite, etc...), le hardware se charge tout seul de retenter jusqu'à réussir à envoyer le message aux destinataires sur le bus. La vitesse de transmission peut aller jusqu'à 1Mb/s. C'est ce qui équipe l'immense majorité des véhicules pour faire communiquer les différents organes électriques internes en toute sécurité et en limitant le câblage au strict minimum.

Ce module est donc là pour vous apporter une aide dans le développement et le monitoring de modules électroniques dialoguant sur un bus CAN. Il est composé d'un transceiver Microchip MCP2551 (servant d'interface électrique à l'instar d'un MAX232 pour une liaison série), d'un Atmel AT90CAN32 comme contrôleur CAN et microcontrôleur central, ainsi qu'un classique FT232 pour s'interfacer simplement sur le port USB d'un PC (et s'alimenter dessus par la même occasion) tout en étant compatible à la fois Windows, Linux et Mac.

Du point de vue du PC, le module sera reconnu comme une liaison série. Cela signifie que n'importe quel programmeur sachant utiliser une liaison série pourra développer ses propres petits scripts (par exemple en langage PERL, mais la quasi-totalité des langages de programmation sont utilisables du moment qu'ils peuvent dialoguer avec un port série) afin d'analyser le bus selon ses besoins propres. Pour des besoins plus basiques, un simple terminal série, comme Minicom sous linux ou l'Hyperterminal sous Windows suffit pour visualiser les trames, et même pour émettre des données.

Le tout est intégré dans un joli boîtier Hammond disponible chez Farnell sous la référence 4272936. Le circuit intégré peut être commandé chez Futurlec à très bas prix (en fournissant le fichier .brd téléchargeable plus bas sur cette page). En tout et pour tout, cette interface -avec sa finition complète- revient à environ 70€, sachant que les modules commerciaux équivalents (sans compter le prix du logiciel d'analyse associé) reviennent entre 2 et 5 fois plus cher. Si vous souhaitez baisser au maximum le prix, vous pouvez toujours ne pas acheter de boîtier, ne pas vernir le circuit imprimé (voire le faire vous-même) et utiliser un connecteur RJ45 simple (au lieu d'un connecteur double) ou bien un connecteur DB9 (se référer à la norme DS102 du CAN-CiA), auquel cas le montage vous reviendra à moins de 40€.

Photos


Circuit interne sans son boîtier.
circuit.jpg
Circuit interne sans son boîtier.
Côté droit du boîtier, avec le connecteur USB et le bornier CAN.
cote1.jpg
Côté droit du boîtier, avec le connecteur USB et le bornier CAN.
Côté gauche du boîtier, avec le connecteur CAN au format RJ45 répliqué deux fois pour s'insérer en milieu de chaîne si besoin.
cote2.jpg
Côté gauche du boîtier, avec le connecteur CAN au format RJ45 répliqué deux fois pour s'insérer en milieu de chaîne si besoin.
Face inférieure du boîtier, dont la sérigraphie rappelle le pinout des connecteurs.
dessous.jpg
Face inférieure du boîtier, dont la sérigraphie rappelle le pinout des connecteurs.
Vue globale du boîtier sérigraphié.
global.jpg
Vue globale du boîtier sérigraphié.
Le boîtier final câblé et en fonctionnement. On distingue bien le bouchon du bus CAN (connecteur sans câble).
insitu.jpg
Le boîtier final câblé et en fonctionnement. On distingue bien le bouchon du bus CAN (connecteur sans câble).

Schéma et Circuit Imprimé


Aperçu du schéma au format PNG.
schema.png
Aperçu du schéma au format PNG.
Aperçu du typon au format PNG.
typon.png
Aperçu du typon au format PNG.
Typon du circuit sous Eagle.
usb-can.brd
Typon du circuit sous Eagle.
Schéma du circuit sous Eagle.
usb-can.sch
Schéma du circuit sous Eagle.

Code source


Ensemble des quelques fichiers en C permettant de faire fonctionner la carte. Le code est encore en développement, mais suffit déjà pour un fonctionnement basique.
code.zip
Ensemble des quelques fichiers en C permettant de faire fonctionner la carte. Le code est encore en développement, mais suffit déjà pour un fonctionnement basique.

Commentaires des visiteurs

Laisser un commentaire

Par totokick le 06/09/2008

Joli projet, on sent le professionnalisme!
Pour avoir déjà pensé à réaliser ce type de convertisseur, je m'étais imaginé pouvoir écouter tous les messages circulant sur un bus CAN d'une voiture. Pour par exemple retranscrire la vitesse du véhicule sur un écran LCD...
As-tu songé à ce genre d'utilisation? Sinon quels utilisation en ferais-tu?
Merci

Par Totofweb le 06/09/2008

totokick> Il est effectivement envisageable de relier cette interface au bus ODB d'une voiture pour exploiter les informations disponibles sur le bus (mais dans ce cas, je conseille de configurer le contrôleur pour se mettre en mode "listening" et être sûr de ne pas intervenir sur le bus).
L'autre utilisation possible (celle à laquelle cette interface est destinée) est le développement de robots dont les divers éléments communiquent via un bus CAN, qui est particulièrement adaptés pour les conditions difficiles (grande résistance aux erreurs en tous genres) tout en étant très puissant (l'identifier des messages peut servir d'adressage, on peut avoir un grand nombre d'intervenants sur le bus, la vitesse de transmission est élevée, le hardware se charge de la gestion des erreurs, etc...).

Par tyseb le 04/02/2009

Bonjour j analyse votre schéma et je voit les résistance R8 et R10 que veut dire 0 NC et 120 NC ?en faite il n y a pas de résistance physique c est le circuit imprimer qui est fait résistance  ???de plus je voudrait savoir le type des résistance et des condensateur si possible.Merci.Cordialement.seb.

Par tyseb le 04/02/2009

Bonjour j analyse votre schéma et je voit les résistance R8 et R10 que veut dire 0 NC et 120 NC ?en faite il n y a pas de résistance physique c est le circuit imprimer qui est fait résistance  ???de plus je voudrait savoir le type des résistance et des condensateur si possible.Merci.Cordialement.seb.

Par tyseb le 04/02/2009

Bonjour j analyse votre schéma et je voit les résistance R8 et R10 que veut dire 0 NC et 120 NC ?en faite il n y a pas de résistance physique c est le circuit imprimer qui est fait résistance  ???de plus je voudrait savoir le type des résistance et des condensateur si possible.Merci.Cordialement.seb.

Par Totofweb le 05/02/2009

tyseb> "NC" signifie "Non Connectée". Tout simplement, la résistance de 120R est la résistance bouchon potentielle (documente-toi sur les bus CAN, il est nécessaire de mettre deux résistances de 120R en bouchon aux deux extrêmités du bus).
La résistance de 0R est un potentiel shunt qui sert à relier les alimentations de l'interface USB-CAN au reste du montage. Tu peux alors alimenter ton montage s'il ne consomme que quelques mA (pour des tests basiques) ou bien alimenter l'interface depuis ton montage (à condition alors de ne pas relier la sortie d'alimentation du FT232).
Les résistances et condensateurs sont du type que l'on rencontre classiquement au format CMS 0805 : carbone couche épaisse pour les résistances, céramique multicouche pour les condensateurs.

Par tyseb le 05/02/2009

Bonjour,Merci des infos, le SV2 sa correspond a quoi?je n'arrive pas savoir quel est ce composant.Merci.Cordialement.SEB.

Par Totofweb le 05/02/2009

tyseb> Regarde sur la photo du circuit monté. SV2 n\'est pas un composant, c\'est le connecteur de reprogrammation. Un connecteur HE14 à 2x5 point est utilisé.

Par tyseb le 05/02/2009

excuse moi encore, 1/le connecteur, tu le connecte comment pour reprogrammer?.2/as-tu des infos sur la reprogrammation du at90can32?si tu as des liens internet ou des infos si tu prefere envoie moi par mail.merci des réponse il est vrai que je ne suis pas un pro de la programmation.Merci.Cordialement.Seb

Par Diego Armando le 12/04/2010

Salut,
Tout d'abord félicitations, c'est du beau travail.
J'ai juste une petite question concernant le placement des leds sur l'AT90CAN. Que veut dire "error LED","Recording LED" et " Match LED" ? Pourquoi les connectees au pins 5,6,7 ? qu'est ce qui différencie ces pins ? pour moi elles sont identiques (échangeables). Je ne sais pas si je me suis fait comprendre.

Merci d'avance

Diego

Par Totofweb le 14/04/2010

Diego> Ces leds sont pilotées par l'AT90CAN (dont les pattes sont effectivement interchangeables, c'est un choix arbitraire fait au moment du schéma, qu'il suffit de répercuter dans le code), et peuvent représenter ce que vous voulez. Par exemple, "error led" indique lorsque le contrôleur CAN se met en mode "bus error", c'est-à-dire qu'il détecte tellement de trames erronées qu'il se met en mode passif (la cause la plus probable étant un mauvais branchement). Les leds "match" et "recording" ont en réalité été renommées sur la façade que vous pouvez voir en photo : je m'en suis servi pour montrer les réceptions et émissions CAN, mais puisque tout ça se décide dans le code, vous pouvez leur faire représenter ce que vous voulez.

Par Youn le 12/06/2010

Bonjour,

Pourriez vous un peu plus détaillez a quoi servent vos fonction "redhex" et "printf". Pourquoi n´utilisez vous pas les registre UDR pour l´UART ?.

Dans votre fichier main, vous declarer un "unsigned char mob" mais vous ne lui donner aucune valeur (enfin je crois)
Voila ca fait beaucoup de question mais je voudrais comprendre.

Par Totofweb le 12/06/2010

Youn> J'ai créé des fonctions readhex et printf qui servent d'abstraction de haut niveau pour la manipulation de registre (via une couche intermédiaire, un driver d'uart). Regarde par exemple dans drivers/uart0.c et uart0.h, tu trouveras le code du driver qui sert d'abstraction au registre UDR et permet une bufferisation des envois. Ensuite, les fonction readhex et printf sont encore une surcouche à ce driver pour factoriser du code et le rendre encore plus lisible et propre.
Dans le main, le "unsigned char mob" sert dans une boucle for, quelques lignes après son initialisation, et sert aussi dans pas mal d'autres boucles for par la suite. J'aurais pu créer une variable générique "i" comme on le fait souvent, mais ici "i" aurait toujours représenté le numéro d'un "Message OBject" de l'avr, donc j'ai préféré un nom plus explicite.
N'hésite pas à me demander si tu as d'autres questions.

Par Youn le 13/06/2010

Bonjour,

Et merci d´´avoir été si rapide.
Pourquoi divisez vous la frequence du CPU par 16000 ?
Que represente "chan_active_flag " ?

Par Totofweb le 13/06/2010

Youn> chan_active_flag est un flag actionné par une commande envoyée par le PC. Il sert au mécanisme qui permet de changer l'état du contrôleur CAN interne, soit en mode actif soit en mode muet.
La division de F_CPU par 16000 n'intervient qu'au moment du calcul du baudrate, dans la fonction can_setbaudrate(). Je vous suggère de vous reporter au code de cette fonction ainsi qu'à la datasheet des AT90CAN : la division par 1000 est là parce qu'on manipule des kbps et non des bps, donc c'est une mise à l'échelle, et la division par 16 intervient car on se place non pas au niveau d'un symbole mais d'un "Time Quantum" du protocole CAN (il y en a 16 par symbole).

Par Émilie le 14/06/2010

N´avez vous pas eu de problemes pour visualiser vos trames sur l´hyperterminal ? J´ai essayé votre code sur une stk600 avec une f de 20MHz. Mais je ne peux pas écrire dans la fenetre, celle ci reste blanche. Peut etre avez vous déjà rencontré un tel pb.

Par Totofweb le 14/06/2010

Émilie> Quel microcontrôleur utilisez-vous avec le STK600 ? Ce montage est destiné à être implémenté dans un microcontrôleur avr disposant d'un contrôleur CAN interne, donc dans un AT90CANxx ou bien dans l'un des tous nouveaux AtMegaC1 ou AtMegaM1, mais aucun d'entre eux n'est conçu pour fonctionner à plus de 16MHz.

Par Émilie le 14/06/2010

Le microcontrolleur que j´utilise est un AT90CAN32 comme le votre.Et je suis tout a fait d´accord avec vous en ce qui concerne la frequence, elle ne doit pas depasser 16MHz.

Mais non tuteur de stage en allemagne m´a dit de monter jusqu´a 20 mhz, (l´entreprise ne disposant que de quartz a 20 MHz, ils ne voulaient pas en commandé juste pour moi !). Donc ceci pourrait etre la cause de mes problemes. Je vais essayer demain. En tout casm je vous remercie beaucoup !

Par Émilie le 16/06/2010

Il parait que l´on peut faire fonctionner un at90xx a 20Ghz, simplement Atmel ne prend aucune garantit au dela de 16Mhz.hmm...ca sent mauvais ca.Je suppose que le problème doit se trouver ailleurs.

Si je saisie bien votre code, on ecrit ce que l´on veut sur l´hyperterminal, par exemple 't' pour recupérer une trame de donnees sur 11 bits ou une autre lettre telle que définie dans le fichier principale. c´est bien ca ?

Et si par exemple je désire envoyer un un message sur 11bit, sous quel format je dois l´ecrire sur l´hyperterminal ? Je sais je sais...il y´a juste analyser votre code, mais j´avoue que c´est un peu difficile a comprendre. Merci d´avance.

Par Totofweb le 16/06/2010

Émilie> "20GHz"... j'ai la certitude que non... 20MHz c'est une autre histoire, mais dans tous les cas même s'il est possible que certains exemplaires le supportent, ce n'est pas une donnée garantie par le fabricant. Certains supporteront 22MHz, d'autres seulement 16.5MHz, tout ce que l'on peut savoir est que TOUS sont garantis pour fonctionner jusqu'à 16MHz.
Quant au terminal série... il est bien évident que rien ne peut fonctionner si vous utilisez le mauvais quartz, puisque le baudrate généré sera alors faux : l'avr et l'ordinateur communiquent à des fréquences différentes, cela ne peut marcher.

Par Émilie le 16/06/2010

Oups oui oui excusez moi je voulais dire 20Mhz(c´est la fatigue).
J´ai deja reglé mon quartz sur 16Mhz(avec le stk600 on peut regler la frequence directement depuis AVR studio) mais le probleme reste inchangé.
Je vais essayer de reflechir un peu ;) En tout cas merci.

Par Émilie le 17/06/2010

Bonjour, désolée c´est encore moi ;)
Je cherche a savoir comment envoyer un message sur 11 ou 29 bits. Cela correspond a votre case CMD_IN_SEND_EXT.Pourriez vous expliquez ce que vous tester dans le if (avec tous les read_checkhex()) ? Sous quel format doit etre envoyé le message ? En vous remerciant d´avance.

Par Totofweb le 17/06/2010

Émilie> Le protocole de communication ressemble beaucoup à celui du CANUSB : www.canusb.com/documents/canusb_manual.pdf

Par Diego le 20/06/2010

ok pour le protocole de communication.
Mai si je ne m´abuse, il n´a pas de possibilites de recevoir de trame et de les visualiser sur un terminal. Dans votre main.c, il n´y a pas de code prévu pour les CMD_OUT . C´est dommage car quand on concoit un circuit, on aimerait visualiser les trames recus, par exemple avec un can analyser qui envoit les données.

Par Totofweb le 20/06/2010

Diego> Analysez le code un peu mieux : le circuit fait les deux simultanément, il permet d'envoyer des trames et d'en recevoir tout comme le ferait un module commercial. Je pense que vous avez simplement regardé la liste des commandes analysées par le "switch" du main(), et il est tout à fait normal de n'y retrouver que les commandes qui vont du PC vers l'interface. Regardez dans can_int_mob(), la fonction appelée par interruption sur réception de trame CAN, vous y trouverez ce que vous cherchez.

Par Emilie le 22/06/2010

Ah oui effectivement, merci.
Avez vous pris des dispositions particulieres pour paramatrer le terminal(mises a part le nombre de bits, la parité) ? Parce qu´en principe, on devrait pouvoir visualiser les trames recues a l´execution du code.Que fait la fonction print_hex8()? Que réalise le fichier Vt100 ?

Par Totofweb le 23/06/2010

Émilie> Les trames peuvent être affichées via un terminal série classique. Le baudrate par défaut est de 115200baud. Si vous n'arrivez pas à voir les trames, c'est que vous avez un problème de paramétrage d'oscillateur (mauvais quartz, mauvais fusibles) : vérifiez à l'oscilloscope quel est le baudrate réel. La fonction print_hex8 affiche un octet avec deux caractères ascii en représentation hexadécimale (un octet valant 128 sera affiché "80" dans un terminal série)

Par Diego le 29/06/2010

En principe on peut se passer de la resistance Rs(slope resistance input) sur le transceiver, pas vrai ? Parce que sur mon avr dragon, je recois des trames que si je met cette resistance. Si je l´enleve, c´est le silence radio. Pouvez vous me donner votre avis la dessus ?

Par Totofweb le 29/06/2010

Diego> La résistance Rs a un nom très explicite : elle sert à adoucir les transitions de manière à diminuer les émissions EM. La contrepartie est que le débit maximal est alors plus faible. Par contre, si vous l'enlevez il faut obligatoirement faire un court-circuit à la masse (la transformer en une résistance nulle), sinon cela revient à mettre le transceiver en mode veille. Je vous conseille de laisser 10k pour une application amateur, c'est une valeur assez bonne tout en conservant des débits élevés.

Par Coyotito le 10/07/2010

Pourriez vous justifier une telle différence dans la taille de vos buffers ?

Pourriez vous nous éclairer un peu plus sur cette fonction : void can_int_mob(unsigned char mob).Il s´agut d´une interruption pas vrai ? Vous réutiliser cette fonction ensuite dans le main juste aprés initialisation du can et de l´uart (can_int_mob_enable(can_int_mob)). Que se passe t´il a ce niveau ? Ne faudrait il pas placer le sei() avant cette instruction ?

P.S. Un grand merci pour vos fonction read_checkhex et print_hex..ca m´a été du grande utilité pour l´afichade de mes trames.

Par Totofweb le 10/07/2010

Coyotito> La différence dans la taille des buffers tient au fait que pour mon utilisation personnelle je n'envoyais presque jamais de commandes de l'ordinateur vers l'interface, je me contentais surtout d'observer le bus, donc j'ai préféré mettre l'accent sur le buffer d'émission plutôt que sûr celui de réception, mais libre à vous de changer les dimensions comme bon vous semble (attention quand même : dans libs/buffer.c, je gère la dimension avec un char pour aller plus vite, si vous souhaitez un buffer plus grand que 255 octets il faudra le changer en int).
La fonction can_int_mob() est effectivement appelée lors d'une interruption liée au bus CAN. Par contre, elle n'est pas appelée depuis le main() : il s'agit d'une autre fonction, "can_int_mob_enable()" qui elle se charge de (re)configurer un MOb en tant que MOb d'écoute avec déclenchement d'interruption sur réception de trame. Il est donc normal que la configuration des interruptions se fasse avant le sei().

Par Charlie le 19/07/2010

Bonjour,
J'ai vu que vous avez un code vraiment complet sur les timers. Est il possible de pouvoir régler a la fois le duty cycle et la fréquence et le nombre d'impulsions ?

Par Konrad freundenberger le 08/08/2010

Hi,

I find your programm fine, there are some tricks that I find very interesting. Well anyway, just that doesn´t work.

You cannot read CAN-messages because your programm never run into the CANIT interrupt. To do that you have to add something in your code that checks if RX is "completed". Else the programm doesn´t see your interrupt.


Par Totofweb le 08/08/2010

Konrad> I can guarantee that it works... it works very well for my two prototypes. The CANIT is triggered upon reception for MObs 0 to 7 and calls the function can_int_mob(). The CANIT interrupt is enabled for each of these MObs via the function can_mob_in_config(mob), which calls the function can_mob_irqon(mob) that I defined in the CAN driver file. It is also globally enabled during the initialization at startup via can_init() and can_int_mob_enable().
If you don't see any interrupt, maybe your bitrate is wrong?

Par kennely le 02/10/2010

Bonjour,

Serait-il possible d'avoir un schéma d'implantation des composants, la liste de ceux-ci, les dimensions du circuit imprimé, ainsi que la méthode pour sérigraphier le boitier ?

Merci

Par Totofweb le 05/10/2010

Kennely> Vous pouvez obtenir tout ça en ouvrant les fichiers de schéma/board avec Eagle (disponible gratuitement pour la version amateur sur www.cadsoft.de). Pour la sérigraphie du boîtier, il s'agit d'un film aluminium que l'on passe à l'imprimante normale et qu'on colle ensuite sur le boîtier à l'aide d'un fer à repasser par exemple. Je ne suis pas chez moi en ce moment donc je n'ai pas la référence avec moi, mais j'essaierai de la poster ici d'ici la semaine prochaine.

Par Erkoc le 21/01/2011

Bonjour
Déjà, très beau projet ... =)

J'ai réalisé la carte mais j'ai un petit soucis avec l'usb : lorsque je branche la carte, windows ne reconnait pas le périphérique (pas juste "périphérique inconnu" mais un problème de périphérique!)
Est-ce qu'il y a une procédure particulière à faire à ce niveau ?
Merci d'avance

Par Totofweb le 21/01/2011

Erkoc> Je vous conseille de vérifier très soigneusement la qualité de la soudure du composant CMS gérant la connexion USB (le FT232), car le problème vient vraisemblablement de là. Si vous avez toujours des problèmes, vous pouvez aussi essayer d'installer manuellement les pilotes depuis le site www.ftdichip.com, mais je ne pense pas qu'un "problème de périphérique" soit dû au pilote.

Par Erkoc le 21/01/2011

Merci pour cette rapidité! =)
J'ai contrôlé les soudures cms grâce à une caméra grossissante et tout à l'air bon ...
Je ne pense pas non plus à un problème de drivers étant donné que le périphérique coince dès le début (sur les diodes : la ON s'allume bien, et la Rx/Tx usb clignotent 3 fois avant de s’éteindre définitivement)
Petite précision : le microcontroleur n'intervient en rien dans l'initialisation et l’installation de la passerelle usb/ttl ? (car j'ai quelques soucis avec ce dernier)

Par Totofweb le 21/01/2011

Erkoc> Non, le microcontrôleur n'intervient en rien. Le FT232 est un composant totalement indépendant. Je vous conseille d'essayer une fois depuis Linux (ne serai-ce que depuis un LiveCD), au cas où : il arrive que windows choisisse de mettre directement en veille le périphérique. En tapant "dmesg" dans une console vous aurez aussi quelques informations sur la nature du dysfonctionnement.

Par Erkoc le 22/01/2011

Déjà merci pour ces précisions!
J'ai contrôlé chacune des mes soudures au multimètre, tout est bon ...
En revanche, j'ai constaté un phénomène avec votre remarque : la patte /Sleep est à 1 lorsque je branche la prise usb et après quelques clignotements de Rx/Tx, elle passe à 0 (donc mise en veille) et windows affiche l'erreur précisément à ce moment.
Concernant linux, je ne suis pas un spécialiste et je suis bien incapable de décrypter les résultats : http://cokreyanPOINTfreePOINTfr/usbcan/
Encore merci! =)

Par Totofweb le 22/01/2011

Erkoc> Depuis Linux, essayez en désactivant l'auto-suspend avec la commande, depuis root, "echo -1 > /sys/module/usbcore/parameters/autosuspend". Ensuite, branchez l'appareil. Vérifiez alors que vous voyez apparaître le lien série virtuel dans /dev/ttyUSB0 (ou ttyUSB1, 2, ...), vous pouvez même envoyer des données vers le lien en tapant "echo 'Hello world' > /dev/ttyUSB0".
Si ça fonctionne bien, il est possible que le contrôleur USB désactive tout seul le module car il consomme légèrement plus que les 100mA par défaut : il est possible de configurer le FT232 pour qu'il annonce vouloir 500mA au port, ce qui laisserait beaucoup de marge.
Si ça ne fonctionne pas, il se peut que l'intégrité des signaux ne soit pas suffisante : essayez avec un autre câble, de préférence plus court. Essayez aussi en posant votre doigt sur les pattes du FT232 (pour adoucir les fronts et réduire les émissions EM).

Par Erkoc le 25/01/2011

Visiblement, même sans l'autosuspend, le module réagit pareil ... Je soupçonne fortement un problème du ft232 (de plus lorsque je l'alimente tout seul sur une alim labo, elle m'indique qu'il ne tire pas plus de 20mA)

Bref, dans un 1er temps, je vais le changer pour un classique max232 pour voir déjà si j'ai quelque chose!
En restant dans les questions : le makefile ne veut pas compiler (pb de chemin). J'arrive à obtenir un .hex en insérant à la main les fichiers, mais je bute un peu sur la config des fusibles : pour résumer, j'ai juste à configurer le micro en quartz externe crystal à 16MHz ou y-a t'il autre chose à modifier?
Merci pour ces réponses !

Par Totofweb le 26/01/2011

Erkoc> Le makefile est fait pour linux, je ne sais pas si AVRStudio saurait l'interpréter. Selon votre installation d'avr-gcc, vous pouvez le modifier pour changer "avr-gcc-color" en "avr-gcc" dedans. Je vous ai mis en ligne le log du make chez moi pour que vous voyiez les commandes censées être exécutées par le make : http://www.totofweb.net/projets/usb_can/make.log.
Les fusibles sont censés être 0xDF (high), 0xFF (low) et 0xFF (extended), soit à peu près une configuration de base et avec un quartz externe de haute fréquence et avec le plus grand délai de mise en route. Si vous utilisez AVRStudio, il vous confirmera la valeur hexadécimale en fonction des cases que vous avez cochées.

Par Marty Brown le 24/02/2011

Well done ! You did a great job.
The Code is quite good, provides an easy-to-follow, step-by-step design framework for a wide variety of applications.

Perhaps would it be better if you create an appropriate graphical interface in C# or any .net that makes the programm easier to use. You know it's not complicated to do. Cause Hyperterminal is good for testing...well anyway..

Par Totofweb le 24/02/2011

Marty Brown> Actually, I didn't want to waste time doing an exhaustive generic graphical interface, but I make some dedicated perl scripts when I want to automate things. I find this solution more flexible (otherwise you would have to design a very complete interface like the Vector CANalyzer, which takes a long time to develop whereas one would rather concentrate one's spare time onto the real project development).

Par Bastet le 17/10/2011

Super boulot. Cependant je souhaiterai savoir pourquoi avoir fait le choix d'alimenter par le 5V de l'USB. n'y a t il pas possibilité de l'alimenter via l'alim du bus CAN? elle est plus puissante. dans mon cas d'utilisation, je souhaite isoler la partie CAN de l'USB en alimentant chaque partie par l'USB d'un côté et le CAN de l'autre en utilisant des optos. le hic c'est que je ne trouve pas les composants MCP et AT90 adns mes bibliotheques. pourriez vous m'aider?

Par Totofweb le 17/10/2011

Bastet> Le bus CAN normalisé ne contient pas d'alimentation. Si ton implémentation concrète se fait sur un câble qui contient aussi une alimentation, c'est hors norme, donc c'est à toi de voir comment s'en servir.
Pour l'optocouplage, le mieux est peut-être d'optocoupler au niveau de l'UART entre le microcontrôleur et le FT232RL.
Pour ce qui est des librairies, si tu utilises Eagle tu peux copier-coller les composants depuis mon schéma avec l'outil "cut".

Par fethi23 le 07/01/2012

merçi pour l'information

Par Le Débutant le 24/04/2013

Comme mon pseudo l'indique, je suis un vrai débutant.
Quelles specs il faut rentrer dans Futurlec pour avoir la bonne carte?
Peut-elle traduire le CAN vers un langage compréhensible par une nexus 7?

Cordialement

Jaques

Par Totofweb le 24/04/2013

Le Débutant> Il faut contacter le service de fabrication de circuits imprimés (PCB) de Futurlec en leur fournissant le fichier usb-can.brd téléchargeable sur cette page. Il est possible de faire appel à d'autres fabricants de circuits imprimés, mais d'après mon expérience Futurlec propose des prix très intéressants pour des cartes aussi simples.
En ce qui concerne la Nexus 7, je ne vois pas très bien ce que vous souhaitez faire, car cette tablette est plutôt conçue pour être ludique. Je ne pense pas qu'elle soit capable d'alimenter ce montage par son petit port USB, vous pourriez avoir besoin d'ajouter une alimentation externe (par un hub autoalimenté). Côté programmation, le montage est vu comme un lien série virtuel, supporté aussi par Android, mais il vous faudra bien sûr développer vous-même le logiciel correspondant à vos besoins et dialoguant avec le montage.

Par Roger le 20/10/2014

Bonjour,
Une petite question concernant la mécanique. Comment avez vous fait les trous sur le boitier ?
Quel matériel utilisez vous pour cela ?
Merci
JP.

Par Totofweb le 20/10/2014

Roger> Une simple perceuse a suffit pour percer les trous, en essayant de travailler le plus proprement possible.

Laisser un commentaire

Merci de ne poster ici que des questions ou commentaires concernant réellement le projet présenté sur cette page. Si vous recherchez de l'aide pour réaliser vos propres projets, merci de vous tourner vers des forums appropriés tel que celui de Planète-Sciences (où je suis très présent).


Pseudo
Mail (facultatif)
Votre message
erreur de génération du cryptogramme visuel. Veuillez recopier le cryptogramme visuel :