Tu veux hacker un dongle ? Quel est le debit des donnees, et sur combien de bits ? Une heure c'est long, ca fait combien d'octets en tout ? Avec un PIC ou tout autre uC tu peux entrer les I/O du port sur des pins d'entree du uC mais il te faut la quantite de memoire necessaire. Tu dois aussi pouvoir enregistrer le trafic directement en interne sur le PC.
bonjour à tous connaissez vous un montage (à base de pic) capable d'enregistrer l'activité sur le port parallèle (pendant 10 à 60 mn) puis de le reproduire? sinon comment est ce faisable?
Je doute que le programme envoie toujours les memes sequences, et donc que le dongle repondra toujours les memes sequences : si c'etait le cas la protection serait totalement inefficace, et dans le cas contraire cette methode ne fonctionnera pas.
Voyons si j'ai bien compris : tu enregistres les donnees emises par le PC sur son port parallele, puis plus tard tu renvoies ces meme donnees vers un peripherique avec port parallele ?
S'il s'agit bien de cela, le probleme qui peut se presenter est que le programme qui tourne sur le PC et pilote le port parallele echange des signaux de controle avec le peripherique : Lors de l'enregistrement, ces signaux doivent etre emules par l'enregistreur pour que le programme du PC fonctionne correctement. Lorsque tu vas rejouer la sequence enregistree, il faudra emuler ces signaux avec un vrai algo de controle en fonction du peripherique utilise. C'est pourquoi je doute que cela fonctionne si tu te contentes simplement d'enregistrer puis de rejouer la sequence.
Pourquoi ne peux-tu mettre le PC a cote du traceur ?
Il faudrait aussi que tu precises le volume total des donnees en bits ou en octets, cumule sur une heure : meme avec un debit de 9600 bps ca totalise plus de 30 Mo. A moins de compresser les donnes a la volee lors de l'enregistrement, (ce qui demande une vitesse de traitement assez elevee) il faudra beaucoup de RAM sur ton uC, ou une RAM externe.
Soit avec la doc de ton peripherique, soit avec un oscilloscope.
Non, ce n'est pas systematique car cela depend du peripherique : les signaux de controle sont utilises seulement quand le peripherique ne peut traiter les donnees a la vitesse ou elles sont envoyees par le PC, et dans le cas d'un traceur il est tres probable que ce soit le cas.
Pour le debit binaire, il existe une limite maximale pour le periph. Pour le debit des blocs de donnees avec des signaux de controle, ce debit est justement soumis a la vitesse de travail du periph :
(1) Le PC demande au peripherique s'il est pret a recevoir. (2) Quand il est pret a recevoir, le periph previent le PC. (3) Le PC envoie une certaine quantite de donnees au periph. (4) Quand le periph en a assez, il le dit au PC, qui attend. (5) Si le PC a encore des donnees a envoyer, retour a l'etape (1) (6) Plus aucune donnee a envoyer : fin de transmission.
D'autre part, certains peripheriques necessitent une phase d'etablissement de protocole avec le programme du PC : si c'est le cas, alors il faudra que le programme du uC gere tout cela, aussi bien lors de la phase d'enregistrement que lors de la phase de restitution.
Sinon, tu ne veux vraiment pas nous dire la quantite totale de bits sur une heure ?
enfin on commence à parler du probleme serieusement
comment verifier si presence de signaux de controle, est ce automatique pour toute transaction sur port parallele?
pour le debit, qui le fixe? l'ordinateur ou le traceur ?
"Jean-Christophe" a écrit dans le message de news: snipped-for-privacy@j21g2000yqe.googlegroups.com... On Jul 27, 11:36 am,
Voyons si j'ai bien compris : tu enregistres les donnees emises par le PC sur son port parallele, puis plus tard tu renvoies ces meme donnees vers un peripherique avec port parallele ?
S'il s'agit bien de cela, le probleme qui peut se presenter est que le programme qui tourne sur le PC et pilote le port parallele echange des signaux de controle avec le peripherique : Lors de l'enregistrement, ces signaux doivent etre emules par l'enregistreur pour que le programme du PC fonctionne correctement. Lorsque tu vas rejouer la sequence enregistree, il faudra emuler ces signaux avec un vrai algo de controle en fonction du peripherique utilise. C'est pourquoi je doute que cela fonctionne si tu te contentes simplement d'enregistrer puis de rejouer la sequence.
Pourquoi ne peux-tu mettre le PC a cote du traceur ?
Il faudrait aussi que tu precises le volume total des donnees en bits ou en octets, cumule sur une heure : meme avec un debit de 9600 bps ca totalise plus de 30 Mo. A moins de compresser les donnes a la volee lors de l'enregistrement, (ce qui demande une vitesse de traitement assez elevee) il faudra beaucoup de RAM sur ton uC, ou une RAM externe.
J'avais fait une appli à ce sujet et le transfer de données était très simple. Mais c'était il y a très longtemps et je n'ai plus que de vagues souvenirs.
En gros le PC plaçait les données sur le port (un octet) et envoyait un signal dont un des fronts (montant ou descendant ?) validait la présence des données. Ensuite les données restaient là (indéfiniment ?) jusqu'à ce que le périphérique envoie un signal dont un des fronts indiquait que la donnée avait été lue et que le PC pouvait envoyer la suivante.
Quelques infos ici:
formatting link
C'est donc enfantin comme protocole et c'est le périphérique qui rythme la vitesse de réception des données à sa convenance.
Maintenant dans ton cas il y a peut-être aussi une couche logicielle avec un protocole particulier pour le traceur. Mais s'il s'agit de stocker simplement des données pour les ressortir telles quelles je pense que ce sera transparent.
a écrit dans le message de news: 4a6d949f$0$17777$ snipped-for-privacy@news.orange.fr...
reflexion : il existait il n'y a pas si longtemps des "buffers centronics" ) Black box qui se mettaient entre PC et imprimante.
Si ton probleme n'est que d'acquerir du byte sur db25 //, le probleme n'est pas tres compliqué, reste effectivement une reponse à la question : quel volume '"d'archivage" ? accessoirement : quelle alimentation dispo pour le systeme d'acquisition ? contrainte physique de placement (encombrement ) ?
N'oublions pas que la Centronics est bidirectionnelles (en données) depuis déjà pas mal de temps, et comme c'est devenu un standard, énormément de périphériques (imprimantes, scanners, traceurs...) "dialoguent" avec l'UC. Et ça ça va être très chiant à reproduire.
Rare son les equipements de type traceurs ou imprimantes qui sortent du // centronics standard. le mode EPP ou ECP est tres rarement utilisé par ce type de peripherique qui restent en mode IEEE 1284 basique La levée de doute est facile à faire, le BIOS de la plupart des PC offrant l'ECP/EPP permet de desactiver ses modes Ehanced. Rvl
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.