Discussion :

[danieldou]

Salut,

Je voudrais savoir comment monter soi même une clé USB, j'ai cherché de la doc et apparemment les composants principaux d'une clé USB sont : la mémoire flash; le microcontrôleur; l'USB mâle, c'est bien ça ? j'aurais donc voulu comprendre comment faire un montage avec ces composants (et d'autre peut être aussi) afin de créer une clé USB avec une particularité : qu'elle soit reconnue\alimentée par le PC (comme une clé normale) mais que le système sur lequel elle sera branché, ne puisse pas accéder aux fichiers se trouvant dedans, mais qu'un logiciel spécialement développé, oui. en quelques sortes, restreindre l'accès aux fichiers de sorte a ce qu'ils soient accessibles uniquement depuis le logiciel (un peu comme fait iTunes, il donne l'accès aux photos depuis l'explorateur mais le reste n'est accessible que par iTunes). je me disais que ça se programme peut être au niveau du microcontrôleur mais j'aurais besoin de quelques éclaircissements sur le sujet ^^

Merci d'avance

[Vincent PETIT]

Salut,
Alors, je vois deux manières de faire qui pourrait répondre a ton besoin, la première est très simple et la seconde un peu plus compliqué.

1) La première solution très simple.
Le constructeur FTDI (http://www.ftdichip.com/FTProducts.htm) propose des composants "bridge" USB vers UART ou I2C ou SPI. Ce genre de composant, tu en as forcément entendu parler. Si tu achètes un adapateur USB/RS232 pour avoir un port série sur un PC (portable) qui n'a que des ports USB et rien d'autres alors il y a 95% de chance que cette adaptateur possède simplement ce genre de composant qui n'est qu'une passerelle ! Lorsque tu branches cette adaptateur, ton PC le reconnait comme un port série virtuel. Maintenant, tu peux imaginer un truc tout simple : un composant bridge USB/I2C que tu connectes a une mémoire I2C et le tour est joué.
Côté PC il te faut faire un logicel qui accède à la mémoire I2C via ce protocole. Inconvénient : Un dump (pour aller fouiner dans ta pseudo clé USB) est assez simple a faire puisque le protocole I2C est connu, à mois que ton logiciel PC crypte les infos qu'il met dans la pseudo clé USB et qu'il décrypte lors d'une lecture et au quel cas tu as la parade ! Même si un fouineur fait un dump de la pseudo clé USB en lisant l'intégralité de la mémoire I2C, il n'y comprendra strictement rien puisque c'est crypter !

2) La seconde solution plus complexe.
Prendre un micro-contrôleur avec un port USB (Atmel, Microchip, Texas Instrument ou n'importe quelle autre) télécharger la stack USB du fabricant.
Au hasard : Texas http://uglyduck.ath.cx/PDF/TexasInst...30_USB_API.pdf (certain vont croire que j'ai des actions chez eux )
Avec celle ci, tu peux implémenter les protocoles CDC/PHDC/HID/MSC.

Bien sur il ne faut pas implémenter le MSC puisque c'est le Masse storage Class (c'est la clé USB) mais plutôt HID ou CDC (c'est celui des claviers/souris/...) et tu devras faire une application plus complexe côté PC pour accéder aux microcontroleurs.


Il y a surement d'autres solutions mais là tout de suite, ceux sont cela que je trouve les plus simples.

[danieldou]

Merci pour la réponse super complète

Alors pour la première solution, je vais m'y pencher pour voir si faire comme ça suffirait a ce que je dois faire

Pour la deuxième, c'est sûr que c'est plus dur mais ça aura l'avantage d'être "propre" ^^ (mais qu'est ce que tu entend par "microcontrôleur avec un port USB" ?)
T'a répondu à plusieurs choses que je me demandais quand a cette méthode, mais j'aimerais avoir quelques précisions supplémentaires, par exemple : est ce que t'aurait une idée du genre de logiciel que sera ce "logiciel complexe" ? qu'est ce qui devra être mis en place exactement ?

Et je pousse la complexité même un peu plus loin : est ce que cette deuxième (ou première) méthode, si j'implémente HID par exemple, donc Windows ne le reconnaîtra pas en tant que stockage de masse et donc ne l'affichera simplement pas dans l'explorateur, les fichiers seront donc accessibles depuis un logiciel complexe (je compte sur toi pour m'expliquer en quoi il consisterait ) ça je l'ai bien compris, ma question est donc : est ce que cette méthode peut aussi être poussée vers une utilisation mobile ?
Je m'explique : on voit récemment des sorties de clé USB compatibles iPhone\Android (ou l'utilisation de clés normales mais avec un adaptateur), est ce que tu pense que la solution que tu m'a donné, permettrait de rendre les fichiers inaccessibles depuis le système de fichiers de Android\iPhone et de développer une application rendant l'accès aux fichiers possible via son utilisation ? en gros : mettre en place le même système que tu m'a dit (qui fonctionne sur Windows) mais sur mobile.

Merci

[Vincent PETIT]

Pour la deuxième, c'est sûr que c'est plus dur mais ça aura l'avantage d'être "propre" ^^ (mais qu'est ce que tu entend par "microcontrôleur avec un port USB" ?)

Ceci par exemple, parmi tant d'autres, est une carte de démonstration d'un micro-contrôleur qui possède un port USB (hôte ou esclave) et aussi plein d'autres périphériques (ADC, SPI, I2C, UART, GPIO, ...) elle coûte 12€

Texas instruments a mis 2 programmes de démonstrations dedans par défaut et lorsque tu l'as connecte sur ton PC, elle est vue de la même manière qu'une clé USB mais de 80ko (de mémoire.) En réalité dans ce micro il y a une implémentation d'un programme USB / MSC.

T'a répondu à plusieurs choses que je me demandais quand a cette méthode, mais j'aimerais avoir quelques précisions supplémentaires, par exemple : est ce que t'aurait une idée du genre de logiciel que sera ce "logiciel complexe" ? qu'est ce qui devra être mis en place exactement ?

Alors tout dépend de ce que tu vas implémenter dans le micro-contrôleur.
Hypothèse 1 : Tu implémentes dans le micro-contrôleur le protocole USB (CDC) pour que le PC reconnaisse le micro-contrôleur comme un port série virtuel. Dans ce cas précis, le logiciel PC qui va dialoguer avec le micro-contrôleur est relativement simple a faire puisque tu as a gérer un port série. Sur le net, tu trouves plein d'exemples et de tutoriels pour gérer le port série avec n'importe quel langage de programmation (C, Java, C#, Phyton etc...)

Hypothèse 2 : Tu implémentes dans le micro-contrôleur le protocole USB (HID) pour que le PC ne reconnaisse rien du tout dans un premier temps. Dans ce cas précis, le logiciel PC qui va dialoguer avec le micro-contrôleur est nettement plus compliqué a faire puisque tu as a gérer un port USB. J'ai essayé de trouver des tutoriels pour faire de la communication USB HID en C et je peux te dire que c'est pas de la tarte !

Et je pousse la complexité même un peu plus loin : est ce que cette deuxième (ou première) méthode, si j'implémente HID par exemple, donc Windows ne le reconnaîtra pas en tant que stockage de masse et donc ne l'affichera simplement pas dans l'explorateur, les fichiers seront donc accessibles depuis un logiciel complexe (je compte sur toi pour m'expliquer en quoi il consisterait ) ça je l'ai bien compris, ma question est donc : est ce que cette méthode peut aussi être poussée vers une utilisation mobile ?
Je m'explique : on voit récemment des sorties de clé USB compatibles iPhone\Android (ou l'utilisation de clés normales mais avec un adaptateur), est ce que tu pense que la solution que tu m'a donné, permettrait de rendre les fichiers inaccessibles depuis le système de fichiers de Android\iPhone et de développer une application rendant l'accès aux fichiers possible via son utilisation ? en gros : mettre en place le même système que tu m'a dit (qui fonctionne sur Windows) mais sur mobile.
Merci

Pour te répondre j'ai besoin de savoir si un téléphone portable sait gérer l'USB hôte ? Je ne le sais pas...
Lorsque je branche mon S4 sur mon PC, le S4 est en USB esclave et le PC en USB hôte mais est ce que si je brancherai une clé USB sur mon S4, serait elle détectée ?

[danieldou]

Ceci par exemple, parmi tant d'autres, est une carte de démonstration d'un micro-contrôleur qui possède un port USB (hôte ou esclave) et aussi plein d'autres périphériques (ADC, SPI, I2C, UART, GPIO, ...) elle coûte 12€

Texas instruments a mis 2 programmes de démonstrations dedans par défaut et lorsque tu l'as connecte sur ton PC, elle est vue de la même manière qu'une clé USB mais de 80ko (de mémoire.) En réalité dans ce micro il y a une implémentation d'un programme USB / MSC.

Donc en gros ça me donne une sorte de clé USB fonctionnelle mais entièrement (du moins, le microcontrôleur) programmable par moi même c'est bien ça ?

Alors tout dépend de ce que tu vas implémenter dans le micro-contrôleur.
Hypothèse 1 : Tu implémentes dans le micro-contrôleur le protocole USB (CDC) pour que le PC reconnaisse le micro-contrôleur comme un port série virtuel. Dans ce cas précis, le logiciel PC qui va dialoguer avec le micro-contrôleur est relativement simple a faire puisque tu as a gérer un port série. Sur le net, tu trouves plein d'exemples et de tutoriels pour gérer le port série avec n'importe quel langage de programmation (C, Java, C#, Phyton etc...)

Hypothèse 2 : Tu implémentes dans le micro-contrôleur le protocole USB (HID) pour que le PC ne reconnaisse rien du tout dans un premier temps. Dans ce cas précis, le logiciel PC qui va dialoguer avec le micro-contrôleur est nettement plus compliqué a faire puisque tu as a gérer un port USB. J'ai essayé de trouver des tutoriels pour faire de la communication USB HID en C et je peux te dire que c'est pas de la tarte !

A voir les deux hypothèses sous cet angle, n'importe qui choisirais la première :p mais est ce que la deuxième, même si elle est plus complexe, présente un avantage quelconque ?
(En fait vu comme ça, la 1 serait mieux dans tout les domaines (1. plus facile. (2. vu que ça peut se programmer avec n'importe quel langage, dont java, Android ou iPhone seraient donc envisageables, je me trompe ?)
(Si tu a les liens des tutos et exemples en question, je suis preneur )

Pour te répondre j'ai besoin de savoir si un téléphone portable sait gérer l'USB hôte ? Je ne le sais pas...
Lorsque je branche mon S4 sur mon PC, le S4 est en USB esclave et le PC en USB hôte mais est ce que si je brancherai une clé USB sur mon S4, serait elle détectée ?

Et bien en partant du fait que l'on trouve sur internet des adaptateurs permettant de lire une clé USB sur son télephone, j'en déduit que le téléphone doit pouvoir prendre en charge une clé USB, ma question tenait surtout sur la mise en place de l'inaccessibilité via le système de fichiers etc... t'en pense quoi du coup vu que apparemment une clé USB peut être lue sur un téléphone ?

Merci

[Vincent PETIT]

Oui tout à fait. Une fois connecté au port USB, le PC voit se micro comme une vraie clé USB (tu peux ouvrir ton explorateur, aller dedans et il y a même 3 fichiers textes dedans en guise de démo.) Bien sur la taille de cette espace est petite : 80ko mais comme c'est bien toi qui programme le micro-contrôleur, tu peux agrandir cette espace et faire bien d'autres choses.

A voir les deux hypothèses sous cet angle, n'importe qui choisirais la première :p mais est ce que la deuxième, même si elle est plus complexe, présente un avantage quelconque ?
(En fait vu comme ça, la 1 serait mieux dans tout les domaines (1. plus facile. (2. vu que ça peut se programmer avec n'importe quel langage, dont java, Android ou iPhone seraient donc envisageables, je me trompe ?)
(Si tu a les liens des tutos et exemples en question, je suis preneur )

La solution 1 est bien plus simple a mettre en oeuvre si tu as un besoin uniquement de stockage puisque ça consiste a faire ça :

Les périphériques I2C sont des mémoires pour stocker ce que ton logicel PC a besoin.

Exemple de composant réalisant cette fonction de Bridge USB/I2C



Il faudrait que je regarde en détail mais le premier schéma de chez FTDI doit être reconnu en tant que Port série Virtuel (USB CDC si je ne m'abuse). Le second, de chez Cypress, est vu comme du USB HID.

Pour la solution numéro 2 avec un micro-contrôleur, elle presenterai une meilleur solution si tu avais autres chose a faire. Ce micro possède des convertisseurs analogique/numérique, des Timers, UART, des ports SPI et I2C des sorties PWM, des broches à utilisation générales etc... mais si tu n'as que faire de tout ça alors je ne vois pas d'intêret de mettre un micro là où il n'y a pas lieu d'en mettre un ? Si ce n'est de compléxifier le projet car tu auras 2 softs a faire (1 sur le PC et 1 embarqué dans le micro et qui plus est qui n'exploitera que quelque % de sa capacité)

Ok pour les clés USB sur les téléphones portables donc ils font bien hôtes USB. Un téléphone portable peut reconnaitre ce genre de composant dans ce cas.

Pour des tutos, c'est là que je rencontre un soucis car je n'en trouve pas beaucoup (même pas du tout) qui explique comment causer en USB HID/CDC côté PC !
Par contre pour causer via un port série virtuel (USB déguisé) là tu en trouvera dans la rubrique C de ce forum, j'ai vu pas mal de réponse sur ces sujets.

Après, la carte de Texas Instruments que j'ai posté, je l'ai acheté et reçu il y a deux semaines et pour l'instant je me bagarre avec les outils de développement pour faire tourner le micro. Texas fourni gratuitement un environnement de développement basé sur Eclipse (pour faire du débug pas à pas sur le micro) et ça fonctionne parfaitement bien sous Windows sauf que moi je suis sous Linux et c'est plus compliqué.... les outils existent mais tous les paramètrages sont plus délicats et à l'heure où je te parle, j'arrive a programmer cette carte sans soucis mais je n'arrive toujours pas à lancer le débuggeur pour faire des points d'arrêt / du mode debug pas à pas etc... (je suis en pleine recherche)

[danieldou]

Donc pour résumer :

1. La première solution consiste à acheter une carte comme celle que tu m'a montré, qui va convertir I2C en USB (USB déguisé donc)et afficher USB sur l'explorateur de Windows.
2. La deuxième solution consiste à acheter un microcontrôleur et le programmer pour qu'il utilise le protocole HID\CDC, ainsi l'ordinateur le prendra pour un périphérique qui n'est pas censé disposer de stockage, donc n'affichera rien dans l'explorateur.

J'ai tout juste ?

Sauf qu'il faut prendre en compte le fait que je cherche a faire un prototype que j'améliorerais ensuite (plus petit, mieux monté etc...), du coup, la carte que m'a montré, elle permet de faire ce dont j'ai besoin mais uniquement avec une carte comme celle ci, alors que le microcontrôleur lui, me donnera la possibilité de l'intégrer dans un vrai montage électronique (plaque d'essai sans soudure pour commencer par exemple).
Et puis c'est vrai que ta première solution est plus facile mais limité dans le développement, je serais obligé de rester dessus.

Si ce n'est de compléxifier le projet car tu auras 2 softs a faire (1 sur le PC et 1 embarqué dans le micro et qui plus est qui n'exploitera que quelque % de sa capacité)

En gros je devrais programmer le microcontrôleur pour qu'il implémente le protocole HID\CDC puis programmer un logiciel permettant de lire les données via les broches USB (en C), c'est bien ça ?

Ok pour les clés USB sur les téléphones portables donc ils font bien hôtes USB. Un téléphone portable peut reconnaitre ce genre de composant dans ce cas.

Et donc tu pense que le système de clé non accessible depuis l'explorateur mais depuis un programme dédié, peut se programmer sous Android ?

(Pour l'instant j'ai donc acheté un microcontrôleur PIC 16F877-20/P www.selectronic.fr/micrrocontroleur-pic-16f877-20-p.html et un programmateur USB www.selectronic.fr/programmateur-de-pic-usb-px200.html, une piste pour l'exploiter pour ce dont j'ai besoin donc ?)

Et puis même pour le montage dans un circuit électronique je pense que ça me poser problème, on m'a dit que le schéma électronique d'une clé, change selon le microcontrôleur utilisé, et que y en a pas 2 ou 3...

Tu pense quoi de tout ça ?

Merci encore pour ton aide

[Vincent PETIT]

Donc pour résumer :

1. La première solution consiste à acheter une carte comme celle que tu m'a montré, qui va convertir I2C en USB (USB déguisé donc)et afficher USB sur l'explorateur de Windows.
2. La deuxième solution consiste à acheter un microcontrôleur et le programmer pour qu'il utilise le protocole HID\CDC, ainsi l'ordinateur le prendra pour un périphérique qui n'est pas censé disposer de stockage, donc n'affichera rien dans l'explorateur.

C'est l'inverse

La première solution conciste à ne pas mettre de microcontrôleur (un simple composant de chez FTDI ou Cypress de type Bridge USB vers I2C, c'est une solution intégrée, et derrière ce composant intégré mettre de la mémoire I2C), dans cette solution il n'y a aucun programme a faire côté pseudo clé USB puisqu'elle est composée simplement d'un Bridge intégré et de la mémoire.

La seconde solution, c'est la justement la carte électronique rouge que j'ai posté. Cette carte comprend un micro-contrôleur avec différents péripheriques dont l'USB mais que tu dois programmer. Sur cette carte, le micro est au milieu et tous les autres composants servent au débuggage et à l'apprendissage car c'est une démo board du micro MSP430F5529. Ils ont mis quelques LED, quelques boutons poussoir, un dégugger intégrer pour aider à la programmation etc...

En gros je devrais programmer le microcontrôleur pour qu'il implémente le protocole HID\CDC puis programmer un logiciel permettant de lire les données via les broches USB (en C), c'est bien ça ?

Pour la seconde solution oui !

Sauf qu'il faut prendre en compte le fait que je cherche a faire un prototype que j'améliorerais ensuite (plus petit, mieux monté etc...), du coup, la carte que m'a montré, elle permet de faire ce dont j'ai besoin mais uniquement avec une carte comme celle ci, alors que le microcontrôleur lui, me donnera la possibilité de l'intégrer dans un vrai montage électronique (plaque d'essai sans soudure pour commencer par exemple).

Justement cette démo board a été faite pour faire du prototypage rapide. Après effectivement, il faut refaire un circuit imprimer en retirant les LED, Bouton poussoir, le débugger et garder juste le micro avec les composants vitales dont il a besoin.
Néanmoins cela te permet de valider un principe (ton idée). Le petit hic c'est vu la tronche du micro il ne sera pas possible de le placer sur une plaque d'essai car il est balaise et a un boîtier très petit !

Et puis c'est vrai que ta première solution est plus facile mais limité dans le développement, je serais obligé de rester dessus.

En effet, la première solution n'est qu'une mémoire en quelque sorte sauf que c'est assez subtile. Imaginons que tu voudrais que ta pseudo clé stock des fichiers issus du logiciel PC et qu'en plus, elle puisse mesurer une température ou acquérir un signal analogique ou générer un signal analogique ou allumer des LED ou RELAIS etc.... alors sache qu'il exite beaucoup de composant I2C qui répondent a ces fonctions.

Avec la première solution, tu peux très bien avoir en tête le bridge USB/I2C et juste derrière : de la mémoire I2C, un capteur de température I2C, des ports d'entrées sorties I2C, un convertisseur analogique numérique I2C, un convertisseur numérique analogique I2C, un capteur de pression I2C, un capteur gyroscopique I2C,......

Et donc tu pense que le système de clé non accessible depuis l'explorateur mais depuis un programme dédié, peut se programmer sous Android ?

Oui je pense.

(Pour l'instant j'ai donc acheté un microcontrôleur PIC 16F877-20/P www.selectronic.fr/micrrocontroleur-pic-16f877-20-p.html et un programmateur USB www.selectronic.fr/programmateur-de-pic-usb-px200.html, une piste pour l'exploiter pour ce dont j'ai besoin donc ?)

Et puis même pour le montage dans un circuit électronique je pense que ça me poser problème, on m'a dit que le schéma électronique d'une clé, change selon le microcontrôleur utilisé, et que y en a pas 2 ou 3...

Tu pense quoi de tout ça ?

La je te fais une réponse ce soir ou demain. Je pense qu'avec un petit schéma tu comprendra mieux (je quitte mon boulot là)
A toute à l'heure, je ne t'oublie pas !

[Vincent PETIT]

Pour répondre a ta dernière question.
Il y a plusieurs possibilités :

1 - avec un micro-contrôleur en tête de clé USB (dans ce cas le micro doit avoir un périphérique USB intégré et tu dois le programmer à l'aide d'une Stack USB, qui est toujours fourni par le fabricant)
2 - sans micro-contrôleur (c'est la solution de facilité mais qui peut être aussi efficace suivant ton application)
3 - avec un micro-contrôleur plus en background (ce sera le cas si tu utilises un petit micro comme le PIC 16F877 qui ne possède pas de périphérique USB)

Exemple 1

Dans cette exemple, il y a 1 micro USB avec éventuellement de la mémoire, que je n'ai pas représenté sur le schéma, si tu as besoin de plus de stockage. Cette solution nécessitera 2 programmes, l'un dans le micro avec de l'USB HID ou CDC (au choix) et l'autre côté PC avec gestion de l'USB HID ou CDC en fonction de se que tu implémentes dans le micro-contrôleur.


Exemple 2

Utilisation de composants dédiés. La passerelle USB/I2C (voir les fabricants FTDI ou Cypress) sont directement fonctionnelles. En réalité se sont des composants programmables sauf que le fabricant te le vend déjà programmé pour qu'il fasse la fonction USB->I2C. Lorsque tu connectes ce genre de composant sur ton PC, celui ci le reconnaît. Chez FTDI il me semble que le PC le verra en tant que port série viruel mais Cypress je ne sais pas (en HID probablement.) Sur le schéma j'ai représenté plusieurs composants I2C sachant que chacun a une adresse différente et le programme PC/Tablette/Téléphone n'a plus qu'a interroger celui qu'il veut pour le lire ou écrire dedans.

Exemple3

Solution avec ton micro. Celui ci n'a pas de périphérique USB en revanche il a un UART, SPI et I2C, dans ce dernier cas le micro PIC peut très bien être un périphérique I2C comme dans l'exemple 2 et être piloter/interroger/lu/écrit par le programme PC.


A mon sens, je dirai qu'il faut déjà savoir si un téléphone support l'USB CDC ou HID
Ensuite faire le choix d'un micro USB si il y en a besoin, le cas échéant un composant bridge (passerelle) fera l'affaire en prenant garde tout de même à la manière dont il sera reconnu (CDC ou HID)
Puis faire le programme PC en s'assurant de sa portabilité vers une tablette ou un smartphone.

D'un point de vu électronique, oui le schéma de la clé dépendra du micro-contrôleur et des composants qu'il y aura autour mais aussi des autres périphériques dont tu as besoin (LED, bouton, mémoire supplémentaire, etc...)

Ce projet n'est pas simple, il représentera du temps de lecture de datasheet, d'analyse et de mises au point mais il est faisable !
Normalement en implémentant de l'USB autre que MSC l'explorateur Linux/Windows/Android/IOS ne pourra pas aller lire la clé, il ne la prendra pas pour un répertoire externe.
Qu'elle est la finalité du projet au juste.

A+

[danieldou]

Merci pour ta réponse détaillée

Donc si je comprends bien, 2 solutions consistent a utiliser I2C, l'une avec le microcontrôleur que j'ai acheté, et l'autre avec une passerelle USB/I2C, et la troisième avec le microcontrôleur de Texas Instruments, c'est bien ça ?

J'ai eu un peu de mal à bien comprendre tes solutions mais je pense avoir compris, corrige moi si je me trompe :

En gros le microcontrôleur que j'ai acheté ne pourra pas fonctionner pour une clé USB (je me suis fait avoir... j'avais bien expliqué au vendeur pour quelle utilisation j'en avais besoin et c'est ce qu'il m'a conseillé... :/)
Je peux donc soit utiliser le microcontrôleur de Texas Instruments (mais comme je te l'avais dit, pas adapté si je veux réaliser un vrai prototype)
Ou je peux donc utiliser des microcontrôleurs qui prennent en charge I2C (comme le mien) pour la mémoire puis les faire passer par une passerelle USB/I2C.

C'est bien ça ?

Perso j'opterais pour la solution la plus "propre" qui est selon moi d'acheter un microcontrôleur prenant en charge l'USB (tu pense quoi du PIC PIC18F4550-I/P ? il me semble qu'il prend en charge l'USB) et le programmer pour qu'il soit en HID/CDC (reste a savoir si c'est possible), après théoriquement j'aurais qu'a trouver un schéma de clé USB et l'adapter selon le microcontrôleur que j'aurais acheté ("juste" une question de broches je pense non ?).

Si selon toi le projet en lui même est faisable, est ce que la solution "propre" que j'évoque (purement théorique bien sur, c'est pourquoi j'ai besoin de ton avis pour savoir si c'est réellement faisable ^^) te parait envisageable ou j'ai tout faux ?

En fait pour le moment c'est juste un projet personnel qui me permettrait de me fabriquer une clé qui m'offrirait plusieurs avantages, par exemple sécurité des fichiers en principal, après vu que je voudrait pouvoir accéder à ceux ci via un portable, j'y ajouterais quelques éventuelles améliorations électronique ^^
Après je me dit même que vu le gros travail, une fois que j'aurais un prototype de clé USB montée sur une plaque d'essai (contrairement à celles qu'on achète déjà soudées), les possibilités d'améliorations seraient quasi-infinies tu pense pas ? après certains pourraient penser que c'est pas forcement important mais c'est comme ça que j'apprends, je me fixe des objectifs et je les lâche pas tant que j'ai pas atteins le résultat attendu, du coup l'avantage avec un projet comme ça c'est que après je maîtriserais beaucoup mieux le domaine de l'USB et des microcontrôleurs (et par la même occasion, une fois le projet terminé, partager avec la communauté de l'électronique, comme je le constate, c'est pas super bien documenté ce genre de sujet, du coup un cours/tuto la dessus serait le bienvenu je pense )

Merci encore pour ton aide

[Vincent PETIT]

Donc si je comprends bien, 2 solutions consistent a utiliser I2C, l'une avec le microcontrôleur que j'ai acheté, et l'autre avec une passerelle USB/I2C, et la troisième avec le microcontrôleur de Texas Instruments, c'est bien ça ?

C'est tout à fait ça, évidemment il n'y a pas que Texas qui fait des micro-contrôleurs USB.

En gros le microcontrôleur que j'ai acheté ne pourra pas fonctionner pour une clé USB (je me suis fait avoir... j'avais bien expliqué au vendeur pour quelle utilisation j'en avais besoin et c'est ce qu'il m'a conseillé... :/)
Je peux donc soit utiliser le microcontrôleur de Texas Instruments (mais comme je te l'avais dit, pas adapté si je veux réaliser un vrai prototype)
Ou je peux donc utiliser des microcontrôleurs qui prennent en charge I2C (comme le mien) pour la mémoire puis les faire passer par une passerelle USB/I2C.

C'est bien ça ?

C'est exacte, en ce qui concerne le vendeur, je suis quasi sur qu'il voyait une solution comme on vient d'en parler. C'est à dire un bridge USB et derrière, ton micro 16F877 qui causerai avec le bridge et je peux te dire d'expérience que même dans l'industrie électronique c'est très souvent la solution du bridge USB/UART (port série en gros) qui est choisi. Pour la bonne est simple raison que côté PC c'est un port série virtuel et que du coup le développement logiciel PC et micro est largement plus simple (pas de stack USB a implémenter des 2 côtés car il y a un bridge qui s'occupe de ça.) Cette technique est équivalente à relier un micro-contrôleur et un PC par le port série RS232 et les faire causer ensemble et c'est nettement moins de boulot.

Perso j'opterais pour la solution la plus "propre" qui est selon moi d'acheter un microcontrôleur prenant en charge l'USB (tu pense quoi du PIC PIC18F4550-I/P ? il me semble qu'il prend en charge l'USB) et le programmer pour qu'il soit en HID/CDC (reste a savoir si c'est possible), après théoriquement j'aurais qu'a trouver un schéma de clé USB et l'adapter selon le microcontrôleur que j'aurais acheté ("juste" une question de broches je pense non ?).

Cette solution est la moins encombrante, la plus souple si d'un coup tu veux ajouter un périphérique, une nouvelle tâche etc... et la plus riche en terme d'expérience mais d'un autre côté c'est celle qui te demandera le plus de boulot. Oui le PC18F4550 prend bien en charge l'USB après il faut juste trouver la Stack USB sur le site de Microchip pour voir ce qu'elle est capable de faire. Personnellement je n'ai jamais trouvé de schéma de clé USB, je ne pourrai donc pas te répondre. En revanche, si tu ajoutes de la mémoire à côté du micro-contrôleur sache que plus elle sera grande et plus le boîtier du composant "mémoire" va tendre vers du petit (genre le micro Texas) et donc impossible de mettre ça sur une plaque d'essai pour faire un prototype. Malheureusement dans l'électronique plus ça va et plus c'est petit !

Si selon toi le projet en lui même est faisable, est ce que la solution "propre" que j'évoque (purement théorique bien sur, c'est pourquoi j'ai besoin de ton avis pour savoir si c'est réellement faisable ^^) te parait envisageable ou j'ai tout faux ?

Oui c'est envisageable là dessus j'ai aucun doute. Le seul problème, comme je le disais plus haut, ceux sont les boîtiers des composants. Le PIC18F4550 est disponible en boîtier P-DIP ou DIP et ce genre de boîtier est très pratique pour une plaque d'essai car ça rentre dedans pile poils. Par contre est ce que tu arrivera à trouver tous les composants nécessaire au prototype avec des boîtiers qui vont biens ???

En fait pour le moment c'est juste un projet personnel qui me permettrait de me fabriquer une clé qui m'offrirait plusieurs avantages, par exemple sécurité des fichiers en principal, après vu que je voudrait pouvoir accéder à ceux ci via un portable, j'y ajouterais quelques éventuelles améliorations électronique ^^
Après je me dit même que vu le gros travail, une fois que j'aurais un prototype de clé USB montée sur une plaque d'essai (contrairement à celles qu'on achète déjà soudées), les possibilités d'améliorations seraient quasi-infinies tu pense pas ? après certains pourraient penser que c'est pas forcement important mais c'est comme ça que j'apprends, je me fixe des objectifs et je les lâche pas tant que j'ai pas atteins le résultat attendu, du coup l'avantage avec un projet comme ça c'est que après je maîtriserais beaucoup mieux le domaine de l'USB et des microcontrôleurs (et par la même occasion, une fois le projet terminé, partager avec la communauté de l'électronique, comme je le constate, c'est pas super bien documenté ce genre de sujet, du coup un cours/tuto la dessus serait le bienvenu je pense )

Alors ça c'est clair que c'est un bon exemple pour apprendre. Tu vas toucher à tout et tu pourra améliorer. Je reconnais que sur le thème USB dans le domaine de l'électronique on ne trouve quasi aucun tuto (je constate un peu la même chose côté PC aussi), il faut quand même avouer que les fabricants se battent pour palier à ça. Leurs but à eux c'est que ce soit le plus simple d'utilisation possible pour qu'ils vendent du composant. Je comptais essayer le micro Texas USB (la petite carte de développement rouge à 12€ en haut de mon poste) et voir un peu comment tout ça fonctionne.

[danieldou]

C'est exacte, en ce qui concerne le vendeur, je suis quasi sur qu'il voyait une solution comme on vient d'en parler. C'est à dire un bridge USB et derrière, ton micro 16F877 qui causerai avec le bridge et je peux te dire d'expérience que même dans l'industrie électronique c'est très souvent la solution du bridge USB/UART (port série en gros) qui est choisi. Pour la bonne est simple raison que côté PC c'est un port série virtuel et que du coup le développement logiciel PC et micro est largement plus simple (pas de stack USB a implémenter des 2 côtés car il y a un bridge qui s'occupe de ça.) Cette technique est équivalente à relier un micro-contrôleur et un PC par le port série RS232 et les faire causer ensemble et c'est nettement moins de boulot.

Donc, comme tu dit, c'est comme si on reliait le microcontrôleur au PC par le port série RS232 et les faire communiquer, comme ça ça résout le problème de l'explorateur Windows et ça facilite la mise en place, mais est ce que le microcontrôleur peut communiquer des données (de sa mémoire flash, très petite oui, mais en théorie ?) via le port série RS232 ? comme une clé USB quoi (via le logiciel développé pour ça, bien entendu).
Question toute bête : le programmateur USB que j'ai acheté indique qu'il est compatible pour toutes les familles de PIC allant de 10F a 32F, je suppose que le PC18F4550 sera donc compatible ?

Cette solution est la moins encombrante, la plus souple si d'un coup tu veux ajouter un périphérique, une nouvelle tâche etc... et la plus riche en terme d'expérience mais d'un autre côté c'est celle qui te demandera le plus de boulot. Oui le PC18F4550 prend bien en charge l'USB après il faut juste trouver la Stack USB sur le site de Microchip pour voir ce qu'elle est capable de faire. Personnellement je n'ai jamais trouvé de schéma de clé USB, je ne pourrai donc pas te répondre. En revanche, si tu ajoutes de la mémoire à côté du micro-contrôleur sache que plus elle sera grande et plus le boîtier du composant "mémoire" va tendre vers du petit (genre le micro Texas) et donc impossible de mettre ça sur une plaque d'essai pour faire un prototype. Malheureusement dans l'électronique plus ça va et plus c'est petit !

Par le plus de boulot tu entend quoi ? tu pourrait me lister les étapes par lesquelles il faudrait passer pour mettre en place cette solution ?
Après pour la mémoire c'est vrai que c'est embêtant... il n'y a aucune solution de mettre du CMS sur une plaque d'essai..? donc si j'opte pour cette option, si j'arrive a faire fonctionner tout ça, de toutes façons je ne pourrais pas ajouter de mémoire et je devrais me contenter de l'extrêmement basse mémoire déjà incluse dans le microcontrôleur, c'est ça ?
T'a jamais trouvé de schéma de clé USB ? quand tu tape "usb key schematics" sur Google images, ce ne sont pas de bons schémas ?

Oui c'est envisageable là dessus j'ai aucun doute. Le seul problème, comme je le disais plus haut, ceux sont les boîtiers des composants. Le PIC18F4550 est disponible en boîtier P-DIP ou DIP et ce genre de boîtier est très pratique pour une plaque d'essai car ça rentre dedans pile poils. Par contre est ce que tu arrivera à trouver tous les composants nécessaire au prototype avec des boîtiers qui vont biens ???

Et bien mis a part la mémoire, je pense que tout les composants se trouvent en taille assez grande pour une plaque d'essai (résistances, condensateurs etc.) je me trompe ?

Alors ça c'est clair que c'est un bon exemple pour apprendre. Tu vas toucher à tout et tu pourra améliorer. Je reconnais que sur le thème USB dans le domaine de l'électronique on ne trouve quasi aucun tuto (je constate un peu la même chose côté PC aussi), il faut quand même avouer que les fabricants se battent pour palier à ça. Leurs but à eux c'est que ce soit le plus simple d'utilisation possible pour qu'ils vendent du composant. Je comptais essayer le micro Texas USB (la petite carte de développement rouge à 12€ en haut de mon poste) et voir un peu comment tout ça fonctionne.

D’où l'importance de réussir ce projet

Merci

[Vincent PETIT]

Donc, comme tu dit, c'est comme si on reliait le microcontrôleur au PC par le port série RS232 et les faire communiquer, comme ça ça résout le problème de l'explorateur Windows et ça facilite la mise en place, mais est ce que le microcontrôleur peut communiquer des données (de sa mémoire flash, très petite oui, mais en théorie ?) via le port série RS232 ? comme une clé USB quoi (via le logiciel développé pour ça, bien entendu).
Question toute bête : le programmateur USB que j'ai acheté indique qu'il est compatible pour toutes les familles de PIC allant de 10F a 32F, je suppose que le PC18F4550 sera donc compatible ?

Il existe beaucoup de solution pour répondre a ton besoin mais pour faire un choix il faudrait que tu ais un cahier des charges plus précis. Par exemple, pour l'histoire du bridge USB/UART qui se situe entre le PC et le micro-contrôleur, et tu l'as bien compris, le PC voit de son côté un port série virtuel (et non pas une clé USB) et de l'autre côté le micro contrôleur lui voit aussi un UART. En réalité ce bridge est complètement transparent et ni le micro-contrôleur, ni le PC ne s'aperçoivent qu'ils communiquent aux travers de l'USB, ils ont tous les deux l'impression de communiquer via un câble série RS232.
Pour ta réponse concernant la mémoire interne flash ou ram ou eeprom, oui, le micro y a accès et sait très bien la lire ou l'écrire ou l'envoyer sur un périphérique.

Mais sans cahier des charges c'est dur de faire un choix ! Premièrement si tu choisie de mettre un bridge USB/UART est ce qu'un téléphone sait reconnaître un port série virtuel ? Un PC oui mais un téléphone portable ? Et une tablette ?
Et si tu décides d'implémenter directement ce bridge dans ton PIC18F4550 afin de ne pas avoir de composant intermédiaire entre entre le PC et le micro, quant est t-il si tu connectes ça à un téléphone portable ? Admettons que la réponse soit "oui ça marche aussi" : Est ce qu'une application mobile sur Android ou IOS (peut importe en quel langage) peut gérer un port série virtuel sachant que, si je n'abuse, aucun téléphone portable a de port série ?

Après il existe d'autres bridges USB/SPI, USB/I2C, le quel est le mieux pour ton projet ? Bien sur le PIC18F4550 peut aussi implémenter lui même ces bridges.

Si tu as besoin de gérer beaucoup de fichier dans ta futur clé, ne vaudrait il pas mieux implémenter de l'USB/MSC dans le PIC18F4550, au quel cas le PC va prendre ton micro pour une clé USB, et établir des règles d'accès pour interdire quiconque de lire ou écrire ?

Si tu n'as que quelques octets (genre 200) a sauvegarder dans cette clé alors peut être que d'autres solutions seront plus adaptées.

Concernant le programmateur, il est bien mais il ne te permettra pas de faire du débuggage et ça risque d'être bloquant. Si tu avais pris un Pickit3, tu aurais pu dérouler ton programme en mode pas à pas, mettre des points d'arrêts, voir tes registres en temps réel et lors d'une mise au point ça aide. La avec un simple programmateur, tu balances le programme dans le micro et puis tu serres les fesses pour que ça marche du premier coup et si ça marche pas, je te raconte pas la galère pour trouver le problème ! (toi et moi savons que ça ne marche jamais du premier coup)

Par le plus de boulot tu entend quoi ? tu pourrait me lister les étapes par lesquelles il faudrait passer pour mettre en place cette solution ?
Après pour la mémoire c'est vrai que c'est embêtant... il n'y a aucune solution de mettre du CMS sur une plaque d'essai..? donc si j'opte pour cette option, si j'arrive a faire fonctionner tout ça, de toutes façons je ne pourrais pas ajouter de mémoire et je devrais me contenter de l'extrêmement basse mémoire déjà incluse dans le microcontrôleur, c'est ça ?
T'a jamais trouvé de schéma de clé USB ? quand tu tape "usb key schematics" sur Google images, ce ne sont pas de bons schémas ?

Et bien mis a part la mémoire, je pense que tout les composants se trouvent en taille assez grande pour une plaque d'essai (résistances, condensateurs etc.) je me trompe ?

Par boulot, j'entends pas là :

1 - Implémenter la stack USB (CDC ou HID ou MSC selon ce que tu souhaites faire) côté micro
2 - Il y aura sûrement un peu de gestion FAT32 mais cela dépendra de l'USB que tu choisiras (si c'est du MSC alors oui il faut gérer le FAT32 pour qu'un PC prenne cette clé pour un répertoire compréhensible mais si c'est en HID ou CDC alors ça n'a aucune importance puisque le PC ne voit pas la clé comme un répertoire, il l'a voit comme un appareil connecté (genre souris, clavier, une carte électronique, ...)) déjà on voit tout de suite que le point 2) va dépendre du point 1) et tant qu'on ne sait pas qu'est ce qu'on implémente en USB alors impossible de savoir le boulot à faire derrière.
3 - Faire le soft côté PC qui implémentera le même USB que le micro (il faut d'abord choisir le point 1) avant)
4 - S'assurer que l'application est portable vers une tablette et téléphone portable (c'est le point 1) encore une fois, qu'il faut voir pour s'en assurer)

Je pense que pour démarrer sainement il faut décrire clairement ce que doit faire cette clé USB et choisir l'implémentation USB la plus adaptée.

Imaginons que tu veuilles une clé sécurisé de 1Go alors c'est clair que c'est l'USB MSC qui s'y prête le mieux, restera à trouver la parade pour que personne n'y ait accès sauf toi. Mais si d'un coup tu veux allumer des LED via le logiciel alors le MSC ne va plus vraiment convenir
Imaginons que tu te tournes vers HID alors pour allumer des LED via le soft c'est nickel mais pour gérer des fichiers/dossiers alors ça va être un peu plus compliqué car là c'était bien MSC le plus adapté.

C'est hyper compliqué de répondre.
Pour les composants CMS sur une plaque d'essai c'est pas évident et malheureusement dès que tu voudra de la mémoire tu ne trouvera pas composant en boîtier DIP, qui va bien pour une plaque d'essai. Tu as raisons pour tout ce qui est quartz, résistance, condo là oui aucun soucis.

Pour des schémas de clé je n'ai pas regardé, tu pourrai me donner quelques liens que tu as vu ?

D'un point de personnel et si j'étais amené à faire ce projet.
J'aurai commandé une démo board (un peu comme la carte rouge tout en haut de ces messages) mais de chez Microchip si tu veux prendre ce fabricant, je sais qu'ils en ont car il y a quelques années j'avais acheté la démo board USB mais c'était pour autres choses que je m'en étais servis. Grâce a cette démo board j'aurai testé plusieurs classe USB (HID/CDC/MSC) pour voir ce qui correspondrait le mieux à mon besoin. Et surtout j'aurai essayé de branché ma démo board sur une tablette ou téléphone portable pour voir si elle est détectée. (attention, il faut bien choisir la démo board USB pour voir si elle correspond bien et si elle a un peu de mémoire pour faire des essais) Généralement les fabricants fournissent plein de démo et même des logiciels PC pour que tu apprivoises leur micro. Par exemple, la carte Texas Instruments et afin que tu sois séduit par ce fabricant, ils ont mis 2 programmes de démonstration dedans, donc quand tu la reçois elle est déjà programmée. Le premier programme est l'USB MSC et des que tu connectes cette petite carte à 12€ sur ton PC, tu vois apparaître une clé USB et dedans il y a 3 fichiers textes. Le second programme se lance lorsque tu appuis sur un bouton,il change la pile stack en mémoire et la transforme en USB CDC (clavier USB). Dans le bouquin de la démo board il te demande d'ouvrir note/gédit/word etc... et d'appuyer sur le bouton, lorsque tu le fais tu vois du texte apparaître, lettre par lettre comme ci tu tapais au clavier. Bien sur Texas, en plus de te montrer 2 moyens de faire de l'USB, te donne leur source de démonstration afin de te facilité la vie. Je ne suis pas inquiet, Microchip fait pareil et d'autres fabricants aussi.

Si tu arrives a faire ce que tu veux alors le principe sera validé et il restera a choisir la gamme du micro à mettre en place car souvent sur une démo board, il te mette un micro super balaise mais si c'est pour qu'il soit utilisé à 30% autant mettre le petit frère de la même gamme, souvent moins volumineux et moins cher et par moment avec de la chance, il est disponible dans un boîtier qui convient à une plaque d'essai. En revanche, concernant la mémoire, je suis quasi sur que tu aura beaucoup de mal à trouver une grosse mémoire qui peut être placée sur une plaque d'essai !

[Vincent PETIT]

Voici un lien très intéressant qui répond a des questions que je me pose juste au dessus :
http://www.ti.com/lit/an/slaa630/slaa630.pdf (Android Applications With MSP430 ™ USB on Mobile Devices)

petite erreur dans ce que j'ai écrit (clavier, souris, joystick USB) c'est plutôt USB HID et non CDC, il faudrait vérifier.

[danieldou]

A vrai dire, mon cahier des charges est déjà extrêmement précis, je sais exactement ce dont j'ai besoin, le problème c'est de savoir comment le mettre en place.
Je résume :

Je voudrais mettre en place un prototype de clé USB de minimum 1Go.
La clé doit pouvoir être compatible Windows\Mac\Android\iPhone (via un adaptateur).
Elle ne doit pourtant pas être lisible depuis l'explorateur de fichier du système sur lequel elle est branchée.
Je dois programmer en parallèle (vu que l'un dépend de l'autre, je dois d'abord boucler le problème de la clé avant de m'attaquer au programme) un programme permettant de lire les fichiers présents sur la clé (je compte développer en C pour Windows et Mac, Java pour Android et Objective-C ou Swift pour iPhone).
(Petit + pas forcement indispensable, je voudrais que la clé aie un micro USB de type B femelle à l’arrière, vu qu'une clé doit consommer pas mal sur un téléphone, c'est peut être accessoire mais ça pourrait être pas mal d'y inclure ça).

C'est aussi "simple" que ça.

Au début quand j'ai commencé a ce petit projet, j'ai cherché un moyen d’empêcher la lecture d'une clé USB depuis l'explorateur Windows, et la seule chose qui m'est venu en tête, c'est que Windows n'affichera quelque chose dans l'explorateur que s'il sait que c'est du stockage, alors que si on programme le microcontrôleur pour qu'il se fasse passer pour du matériel autre que du stockage, Windows ne se posera même pas la question de l'explorateur. Problème résolu, restait plus qu'a voir si c’était faisable.
Mais c'est sûr que si on programme le microcontrôleur en tant que HID ou autre alors qu'il doit faire passer des fichiers, j'imagine bien que le développement du coté du programme sera pas simple, et puis j'avais pas pensé que ça pouvait poser problème au niveau du téléphone... du coup c'est sûr qu'une solution qui nécessiterais moins de travail serait plus envisageable... le problème principal est de trouver comment empêcher Windows de lire un périphérique de stockage (sans qu'il y ait besoin d'un intervention quelconque sur le PC, bien entendu).
Je viens de penser a une éventuelle solution, j'avais vu quelques fois des clés proposant de sécuriser la clé via un mot de passe configurable via un logiciel intégré dans la clé (quand on va dans l'explorateur alors qu'on a pas rentré le mot de passe, Windows affiche la clé mais quand on l'ouvre, vide), du coup si on suit la logique, le programme de sécurisation par mot de passe se trouve dans le microcontrôleur (sinon n'importe qui formaterait la clé pour le supprimer), le programme doit surement fonctionner comme ça : il propose à l'utilisateur de configurer un mot de passe, l'utilisateur le fait, le programme entre donc dans une condition "Si l'utilisateur a rentré le mot de passe; Alors on autorise l'accès aux fichiers; Sinon; On empêche Windows d'afficher les fichiers via l'explorateur". ça voudrait donc dire qu'il y a moyen de programmer une fonction empêchant a Windows (ou a tout autre système de fichier j’espère, sinon la solution ne marchera pas pour les téléphones) l'accès aux fichiers se trouvant sur la clé même s'il la reconnait en tant que clé. Cette solution résoudrait donc le problème des transferts de fichiers (les transferts seront facilement faisables puisque le microcontrôleur sera programmé en tant que MSC) et celui de l'accès aux fichiers via l'explorateur de fichiers du système.
On pourrait même imaginer un fonctionnement comme celui ci : Un programme se trouve dans le microcontrôleur; ce programme invoque une fonction semblable a celle des clé sécurisées par mot de passe, il bloque l'accès aux fichiers depuis l'explorateur de fichiers à part si un mot de passe est fourni; Un autre programme se trouve sur le PC; ce programme fourni le mot de passe demandé par le microcontrôleur, et libère alors l'accès uniquement via le programme en question (qui se trouve sur le PC). Théoriquement il me semble que c'est faisable... ça pourrait être la fameuse "parade". T'en pense quoi toi ?
(ou encore une autre solution, impossible je pense mais peut être que tu en sait surement plus que moi alors peut être que tu me dira le contraire ^^ ça serait de tout simplement acheter une clé USB normale et essayer de la programmer exactement comme on l'aurait fait sur le prototype, l'avantage serait que ça lèverait le problème de la mémoire CMS... mais il me semble que reprogrammer une clé déjà faite n'est pas possible non ?)

Après je te rassure, ce que je veux que la clé fasse, c'est uniquement son rôle de clé USB, le transfert et la gestion des données, pas de contrôle du matériel (comme une LED) via le logiciel, du coup c'est sûr que MSC est adapté, mais seulement si on trouve la parade pour la sécurisation...

Du coup pour le point 1... assez compliqué de savoir ce qui conviendra le mieux comme USB, ce qui est sur c'est qu'il FAUT que ça marche sur téléphone, du coup logiquement (comme tu l'a dit) ça m’étonnerais que les téléphones prennent en charge HID/CDC...

Un exemple de schéma (j'ai pas vérifié s'il correspond vraiment à un périphérique de stockage, mais à première vue oui) http://baron.bologrew.net/usbkey-sch.jpg

Pour les composants CMS, une petite question que je me suis toujours posé (en théorie bien sûr), la difficulté à souder des composants CMS est la taille de leurs pattes, si on regarde bien, les pattes ne sont que faites de métaux conducteurs, du coup si on "rallonge" ces métaux, techniquement on devrait pouvoir les poser sur une plaque d'essai sans soudure non ? un petit bricolage certes, mais il me semble que c'est pas infaisable non plus, je me trompe ?

Pour la carte démo de Microchip, tu en a une à me conseiller ?

Merci beaucoup

[Vincent PETIT]

Je viens de penser a une éventuelle solution, j'avais vu quelques fois des clés proposant de sécuriser la clé via un mot de passe configurable via un logiciel intégré dans la clé (quand on va dans l'explorateur alors qu'on a pas rentré le mot de passe, Windows affiche la clé mais quand on l'ouvre, vide), du coup si on suit la logique, le programme de sécurisation par mot de passe se trouve dans le microcontrôleur (sinon n'importe qui formaterait la clé pour le supprimer), le programme doit surement fonctionner comme ça : il propose à l'utilisateur de configurer un mot de passe, l'utilisateur le fait, le programme entre donc dans une condition "Si l'utilisateur a rentré le mot de passe; Alors on autorise l'accès aux fichiers; Sinon; On empêche Windows d'afficher les fichiers via l'explorateur". ça voudrait donc dire qu'il y a moyen de programmer une fonction empêchant a Windows (ou a tout autre système de fichier j’espère, sinon la solution ne marchera pas pour les téléphones) l'accès aux fichiers se trouvant sur la clé même s'il la reconnait en tant que clé. Cette solution résoudrait donc le problème des transferts de fichiers (les transferts seront facilement faisables puisque le microcontrôleur sera programmé en tant que MSC) et celui de l'accès aux fichiers via l'explorateur de fichiers du système.
On pourrait même imaginer un fonctionnement comme celui ci : Un programme se trouve dans le microcontrôleur; ce programme invoque une fonction semblable a celle des clé sécurisées par mot de passe, il bloque l'accès aux fichiers depuis l'explorateur de fichiers à part si un mot de passe est fourni; Un autre programme se trouve sur le PC; ce programme fourni le mot de passe demandé par le microcontrôleur, et libère alors l'accès uniquement via le programme en question (qui se trouve sur le PC). Théoriquement il me semble que c'est faisable... ça pourrait être la fameuse "parade". T'en pense quoi toi ?

Là c'est clair, net et précis ! La solution me paraît très propre et très adapté !

(ou encore une autre solution, impossible je pense mais peut être que tu en sait surement plus que moi alors peut être que tu me dira le contraire ^^ ça serait de tout simplement acheter une clé USB normale et essayer de la programmer exactement comme on l'aurait fait sur le prototype, l'avantage serait que ça lèverait le problème de la mémoire CMS... mais il me semble que reprogrammer une clé déjà faite n'est pas possible non ?)

Malheureusement tu as raison, quasiment tous les micro-contrôleur possède un fusible anti-lecture/ecriture. Je suis sur à 100% que toutes les clés sont protégées.

du coup logiquement (comme tu l'a dit) ça m’étonnerais que les téléphones prennent en charge HID/CDC...

Dans mon poste précédent, Texas instruments vient de me prouver le contraire ! Visiblement tout est pris en charge !

Un exemple de schéma (j'ai pas vérifié s'il correspond vraiment à un périphérique de stockage, mais à première vue oui) http://baron.bologrew.net/usbkey-sch.jpg

Si tu regardes bien la référence du composant c'est le FT8U232AM donc voici la description : http://www.ftdichip.com/Products/ICs/FT8U232AM.htm ce n'est qu'un bridge USB/UART et non une clé USB. Ce genre de bridge c'est vu comme un port série virtuel.

Pour les composants CMS, une petite question que je me suis toujours posé (en théorie bien sûr), la difficulté à souder des composants CMS est la taille de leurs pattes, si on regarde bien, les pattes ne sont que faites de métaux conducteurs, du coup si on "rallonge" ces métaux, techniquement on devrait pouvoir les poser sur une plaque d'essai sans soudure non ? un petit bricolage certes, mais il me semble que c'est pas infaisable non plus, je me trompe ?

Ayant travaillé 12 ans dans l'industrie électronique et 6 ans dans un labo de R&D à faire du développement... lors de mes débuts comment crois tu que je faisais lorsque je me plantais dans la réalisation de mes circuit imprimés ? Genre, je créais une emprunte pour un nouveau composant dans mon logiciel de CAO et pas de bol j'inverse des broches ! Bah oui je faisais ça aussi pour ne pas mettre le prototype à la poubelle. Je soulevais mon composant CMS (par un exemple un petit micro-contrôleur) et avec du sang froid je soudais du fin fil a wrapper pour allonger les broches et recâbler correctement le micro sur le circuit imprimé. Par contre c'est faisable à condition où le boîtier le permet... quand les broches sont trop rapprochés là c'est mission impossible. Moi j'ai réussi sur un boîtier TSSOP (0.5mm entre broches) en deçà, avec un fer à souder, ça relève presque de l'exploit !

Je vais jeter une idée en l'air avec ton idée que je trouve très bien et en m'appuyant sur la carte Texas que j'ai justement devant moi. Comme Texas montre comment, via un simple bouton poussoir, changer d'un coup de MSC en CDC (et mon Linux n'y voit que du feu) je me posais la question suivante :

Qu'est ce qui t’empêcherait d'implémenter HID et MSC dans le micro qui est dans la clé ? Texas Instruments l'ont fait !
Au démarrage c'est HID qui se lance dans le micro (le PC ne verra pas de répertoire amovible) et tu fais un programme PC USB HID qui demande un mot de passe.
Ce mot de est envoyé du PC au micro pour vérification (toujours en HID)
Mot de passe ok ! Le micro bascule en MSC et d'un coup le PC le verra en tant que clé USB !

Pour la carte démo de Microchip, tu en a une à me conseiller ?

Je regarderai demain mais je ne pourrai pas être sur de mon coup car je ne sais pas si la stack USB Microchip permet de faire exactement.

[danieldou]

Heureux que t'approuve ma solution ! :p
Du coup ça serait top puisqu'on resterait en MSC tout en bloquant l'accès aux fichiers

(Désolé t'avais posté ton dernier message pendant que j’écrivais le mien, du coup je l'avais pas vu )

Je vais essayer de mieux chercher pour le schéma, je t'en envoie si j'en trouve un valable.
En attendant j'ai trouvé celui la qui utilise le PIC18F4550 http://users.wfu.edu/rollins/pic/PIC...-schematic.gif

Pour ton idée de faire basculer la clé de HID vers MSC selon la condition "mot de passe ou pas", je trouve que l'idée est bonne mais malheureusement elle présente une faille au niveau de la sécurité (n'oublions pas que le fait que je veuille rendre les fichiers accessibles uniquement depuis un programme spécialement développé, est pour créer une sécurité maximum). En fait, vu que l'explorateur de Windows est en quelques sortes "standard", j'entend par la que ses fonctions telles que copier/renommer/etc. ne sont pas administrables, si on donne l'accès aux fichiers via l'explorateur, l'utilisateur pourra en faire ce qu'il veux (il pourra même copier ses propres fichiers dedans, n'importe qui pourra y inclure des Malwares par exemple), alors que si l'accès n'est autorisé uniquement via un logiciel spécialement développé, toutes les éventuelles actions que quelqu'un pourra y faire, seront gérées par ce logiciel, autrement dit : si je veux que la personne ne puisse que lire ces fichiers, j'aurais le pouvoir de lui restreindre d'autres actions, de même pour toute la gestion des fichiers.
C'est pourquoi l'idée de faire basculer de HID vers MSC pose problème a ce niveau la, tu voit ce que je veux dire ?

Mais dans l'idée donc, moi je vois les choses comme ça : le programme du microcontrôleur bloque l'accès aux fichiers via l'explorateur et ne les débloquera que si le mot de passe est fourni, cette partie est claire.
La question que je me pose est : est ce que lorsque le programme valide le mot de passe et débloque donc l'accès, est t'il obligé de donner l'accès au système (l'explorateur) ou bien peut il le laisser bloqué via l'explorateur mais le débloquer pour le programme spécialement développé uniquement ?
Pour répondre à cette question, on pourrait suivre deux logiques :

1. Le programme effectue quelque chose de semblable a l'idée que tu a donné, en gros il fait passer la clé en MSC uniquement lorsqu'il obtient son mot de passe.
2. Le programme fonctionne comme ça : le microcontrôleur a constamment l'accès aux fichiers (donc il est constamment en MSC), sauf qu'il est programmé avec une fonction qui lui permet de restreindre l'accès via le système (donc n'importe quel explorateur présent dans l'ordinateur), lorsqu'on lui fourni le mot de passe demandé, il rend l'accès au système (dans ce cas, la question est de savoir est, est ce qu'il peut rendre l'accès uniquement a un programme, en occurrence celui qui lui a fourni le mot de passe, qui lui est en lien direct avec le microcontrôleur, donc peut accéder a ses fichiers, contrairement au système, qui lui ne sait rien du microcontrôleur).

Si le programme fonctionne selon la première logique, a priori, ça ne résous pas le problème de la sécurité (comme je l'ai dit plus haut).
Par contre s'il fonctionne comme la deuxième, la y a une chance d'avoir ce qu'on veux ^^

T'en pense quoi ?

Merci

[Vincent PETIT]

Je vais essayer de mieux chercher pour le schéma, je t'en envoie si j'en trouve un valable.
En attendant j'ai trouvé celui la qui utilise le PIC18F4550 http://users.wfu.edu/rollins/pic/PIC...-schematic.gif

ok pour celui là tu peux t'en inspirer, il est bien.

Pour ton idée de faire basculer la clé de HID vers MSC selon la condition "mot de passe ou pas", je trouve que l'idée est bonne mais malheureusement elle présente une faille au niveau de la sécurité (n'oublions pas que le fait que je veuille rendre les fichiers accessibles uniquement depuis un programme spécialement développé, est pour créer une sécurité maximum). En fait, vu que l'explorateur de Windows est en quelques sortes "standard", j'entend par la que ses fonctions telles que copier/renommer/etc. ne sont pas administrables, si on donne l'accès aux fichiers via l'explorateur, l'utilisateur pourra en faire ce qu'il veux (il pourra même copier ses propres fichiers dedans, n'importe qui pourra y inclure des Malwares par exemple), alors que si l'accès n'est autorisé uniquement via un logiciel spécialement développé, toutes les éventuelles actions que quelqu'un pourra y faire, seront gérées par ce logiciel, autrement dit : si je veux que la personne ne puisse que lire ces fichiers, j'aurais le pouvoir de lui restreindre d'autres actions, de même pour toute la gestion des fichiers.
C'est pourquoi l'idée de faire basculer de HID vers MSC pose problème a ce niveau la, tu voit ce que je veux dire ?

Oui je vois très bien et vu sous cet angle tu as raison ça ne résoud en rien le problème.

Mais dans l'idée donc, moi je vois les choses comme ça : le programme du microcontrôleur bloque l'accès aux fichiers via l'explorateur et ne les débloquera que si le mot de passe est fourni, cette partie est claire.
La question que je me pose est : est ce que lorsque le programme valide le mot de passe et débloque donc l'accès, est t'il obligé de donner l'accès au système (l'explorateur) ou bien peut il le laisser bloqué via l'explorateur mais le débloquer pour le programme spécialement développé uniquement ?
Pour répondre à cette question, on pourrait suivre deux logiques :

1. Le programme effectue quelque chose de semblable a l'idée que tu a donné, en gros il fait passer la clé en MSC uniquement lorsqu'il obtient son mot de passe.
2. Le programme fonctionne comme ça : le microcontrôleur a constamment l'accès aux fichiers (donc il est constamment en MSC), sauf qu'il est programmé avec une fonction qui lui permet de restreindre l'accès via le système (donc n'importe quel explorateur présent dans l'ordinateur), lorsqu'on lui fourni le mot de passe demandé, il rend l'accès au système (dans ce cas, la question est de savoir est, est ce qu'il peut rendre l'accès uniquement a un programme, en occurrence celui qui lui a fourni le mot de passe, qui lui est en lien direct avec le microcontrôleur, donc peut accéder a ses fichiers, contrairement au système, qui lui ne sait rien du microcontrôleur).

Si le programme fonctionne selon la première logique, a priori, ça ne résous pas le problème de la sécurité (comme je l'ai dit plus haut).
Par contre s'il fonctionne comme la deuxième, la y a une chance d'avoir ce qu'on veux ^^

T'en pense quoi ?

Ce problème est très intéressant... le but est d'avoir une communication en mode tunel entre ton programme et le micro, tunel que le PC ou l'explorateur ne peut pas emprunter ! J'aurai tendance à dire que finalement MSC n'est peut être pas adapté. C'est très compliqué. Dans un de mes exemples j'avais soumis l'idée d'utiliser USB/I2C et là cétait vite régler car l'explorateur ne sait pas gérer l'I2C par contre ton programme aurait du savoir gérer les données en brut dans la mémoire I2C (image de tes répertoires, fichiers, etc...) et cétait beaucoup de boulot !

Je me demande si un administrateur système n'aurait pas une solution pour cette gestion des accès.

Quelques part ça me fait penser à une connexion ftp sur un serveur. Lorsque tu as un site web, personne ne peut créer de fichiers ou de répertoires ou uploader sans avoir tes identifiants de connexion au serveur (ftp ou autres) par contre tout le monde peut lire les fichiers (les .html ou .php etc...) Est ce qu'une solution n'est pas envisageable de ce côté là ?
Je n'ai pas assez de connaissance dans tout ce qui est "informatique PC" pour te répondre.

[danieldou]

Le problème principal reste donc au niveau de la programmation du microcontrôleur si je comprends bien ?

Et niveau électronique (matériel) ? comment je peux concrètement trouver comment exactement une clé USB en bonne et due forme ?

Nous avons donc, un premier problème, au niveau de la sécurité des fichiers, qui relève de la programmation du microcontrôleur (et du programme, qui devra établir une communication exclusive avec le microcontrôleur).
Un deuxième qui relève du montage électronique de la clé, car le microcontrôleur est certes important, mais sans le montage qui va avec, il ne sert à rien.

Très complexe comme projet...

Ta conclusion dans tout ça..? faisable ou pas ? et si oui vers ou je devrais me diriger ? :/

Merci ^^

[Vincent PETIT]

Le problème principal reste donc au niveau de la programmation du microcontrôleur si je comprends bien ?
Et niveau électronique (matériel) ? comment je peux concrètement trouver comment exactement une clé USB en bonne et due forme ?

Pour la programmation micro je ne suis pas trop inquiet et je pense (du moins j'espère) que tu seras agréablement surpris par les stack USB que les fabricants de micro fournissent. Moi j'ai regardé la mienne de chez Texas, très rapidement hier soir, elle a l'air vraiment simple d'utilisation et il n'y a pas 50 fonctions, ils ont l'air d'avoir mâché le travail mais alors vraiment fort !!!! Il faudrait que j'y regarde de plus prés lorsque j'aurai le temps.

D'un point de vu électronique, une chose est sur c'est qu'aucun micro-contrôleur ne possèdera 1Go de Flash.

Il faut que je regarde le source de ma carte Texas car eux ils ont implémenté l'USB MSC et mon Linux voit bien un répertoire où je peux lire/écrire.
Donc c'est qu'ils ont réussi a créer un espace au format FAT dans la mémoire du micro pour que le PC ne s'y perde pas.

Deux cas de figures :

1 - Soit dans le source du micro, je vais voir de la gestion FAT quelque part avec un emplacement mémoire bien défini.
2 - Soit c'est la stack USB de chez Texas qui gère ça toute seule, lorsque tu implémentes MSC, peut être qu'une des fonctions de la stack USB MSC de demande un emplacement mémoire ?

Si tu veux 1Go de mémoire alors quelque soit le cas de figure au dessus ce n'est pas bien grave.

Soit ton micro est relié à une mémoire Flash (j'en ai vu à 1Go chez Mouser Electronics, c'est là où je m'approvisionne) ce qui implique de rediriger simplement la fonction que gère la zone FAT vers la mémoire extérieure et non intérieure. Ca concistera en une fonction intermédiaire à mettre en place entre : (la stack USB ou la gestion FAT) et la mémoire extérieure.

Soit gérer une petite carte microSD ou SD en guise de mémoire mais dans ce cas c'est génant dans le sens où elle peut être retiré par l'utilisateur.

Tout ça va dépendre de comment la stack USB est faite.

Nous avons donc, un premier problème, au niveau de la sécurité des fichiers, qui relève de la programmation du microcontrôleur (et du programme, qui devra établir une communication exclusive avec le microcontrôleur).
Un deuxième qui relève du montage électronique de la clé, car le microcontrôleur est certes important, mais sans le montage qui va avec, il ne sert à rien.

Très complexe comme projet...

Ta conclusion dans tout ça..? faisable ou pas ? et si oui vers ou je devrais me diriger ? :/

Pour l'électronique de la carte, ça ne va pas être bien compliqué (1 micro avec ce qui va avec pour qu'il tourne et quelques mémoires associées) après c'est beaucoup de soft pour gérer le tout !
Pour moi c'est faisable.

Laisse moi un peu de temps pour regarder la partie hard de tout ça.
A+