Vous n'êtes pas identifié.
Pages: 1 2
Bonjour. Je projette de faire un logiciel de transfert de lecteur pour Graph100+ sous mac (comme Flash 100 ou Flash Edit, mais en moins complet pour le début).
J'ai pris contact avec 2 auteurs de logiciel destiné à cela, sous PC, qui m'ont donné aimablement leurs codes sources. Je l'ai en remercie.
Seulement, je pense que je n'ai pas pris le bon chemin. Effectivement, ces logiciels, ce sont eux qui les ont fait. Il est donc beaucoup plus facile de comprendre le code source. Alors que pour une personne tiers (moi en l'occurrence) qui ne connaît pas le code, il faut d'abord que je le maîtrise, et que je le traduise pour le langage que je veut utiliser, et pour le mac. C'est long, et fastidieux. Un peut trop. C'est pour ça que je me suis dit qu'il fallait que j'aille à la "source" du problème.
Est ce que donc quelqu'un pourrait me faire un descriptif, pour le moment (j'en demanderait plus après), de ça :
- le protocole d'envoie/réception d'un fichier .lec à un "lecteur" d'une graph 100 +
Il faut faire abstraction du langage de programmation, donc par exemple ce genre de descriptif (les < sont les réceptions calculette/ordi, les > sont les envois ordi/calculette) :
>je veut envoyer un fichier .lec
<ok, t'est autorisé. sur qu'elle lecteur ?
>le lecteur M
<ok, tu peut y aller
>[contenus sous forme de texte d'un fichier .lec]
> j'ai finit
< ok, c'est bien passé
>ciao
<ciao
Évidement c'est qu'un exemple. Il me faudrait le protocole d'origine (pour graph 100 + je le répète), avec le texte réel à utiliser (code ASCI, code hexa de confirmation, ...)
Il me semble qu'il y à 2 câble possible pour relier une graph 100 (+) ... Qu'elle est la différence entre les 2 ? Dans le protocole ? Dans la configuration du port de communication ?
- le même protocole mais pour envoyer un fichier .cfx (je ne sait pas si le protocole change...)
- le format d'un fichier .lec (les .cfx je m'en fiche...) :
par exemple un fichier .lec avec trois fichier : un .exe, un .bmp et un .txt à réunir dans ce .lec
le format :
(FICHIER .LEC)
//Ajouter- En tête fichier
// boucle (for) jusqu'au nombre de fichier à ajouter dans mon .lec
//Ajouter- contenus fichier index i
//Ajouter- séparation de fichier
// fin de boucle
//Ajouter- Pied du fichier
(/FICHIER .LEC)
Évidement, c'est un exemple.
Merci beaucoup d'avance pour votre aide...
PS : j'ai fait une recherche sur le forum et je n'ai pas trouvé tout ça, mais évidement si une info est déjà présente mais qu'elle m'a échappé, donnez moi le lien du message...
dsl, je ne te répondrais pas à la question, mais juste dire qu'il me semble que, d'après ce qu'avait dit dada66, avec la librair qt il y a possiblité de le porté directement sous mac.
Hors ligne
Je sait bien, il m'a filé les sources. Et effectivement, j'ai téléchargé QT. Mais QT, c'est fait pour tout (ou presque) SAUF la transmition via un port de communication.
Les appelle ToolBox n'étant pas pareil, ça me gonfle de de voir inspecter le code pour savoir comment remplacer ça par ça pour que ça marche sous mac.
C'est plus simple pour moi de tout reprendre à 0
De plus, QT marche pas sous les mac 68k (uniquement sous PPC). Or les nouveau mac on uniquement des ports USB pour la communication (il n'y existe pas réellement de bonne solution de câble USB<>Casio). Et finalement, j'aimerais que mon logiciel, à défaut d'être compatible avec les nouveau mac (à cause du USB donc), soit compatible avec tous les vieux mac (ppc ET 68k). Le code PPC n'étant pas lisible sur 68k, mais l'inverse si, il faut que je face du code 68k... Tu me suit ?
Voilà voilà.
Hors ligne
ou la, c'est un vieux que tu as !!!
Hors ligne
Moi j'en ai 2 : un PB Titanium 153 1 Ghz et un mac lc 475, qui est, c'est bien vrais, vieux.
Mais c'est bien connus, c'est avec les vieux ordi qu'on peut mieux bidouiller...
Hors ligne
ba les USB2SERIAL marche pas ? je croyais que Superna avait un adaptateur et que ca marchait
Hors ligne
Oui mais il est pas facile à faire (composant dur à trouver).
Bref, moi ce qui m'intéresse, c'est surtout la question que j'ai posé en haut...
Je sait que c'est peut long à donner comme réponse, mais si vous avez, ne serait-ce qu'un site web, un lien, de la doc .pdf (ou autre), alors faite moi en part !
Hors ligne
non, je parle pas de mon schéma USB2CASIO, mais le USB2SERIAL, il est dans le commerce
pour ton PB de code source, je pense que tu devrais regarder celui de FlashEditor, il est en Visual Basic, donc facile a comprendre !
mais les sources de F100 sont encore plus clair !
Hors ligne
oui il y a juste l'init du port à refaire ainsi qu'utiliser les fonctions de port comme pour mac. En fait tu devrais demander conseil à Superna qui s'y connaît beaucoup en MAC.
Hors ligne
Algo pour Recevoir un lecteur.
[
InitCasioCom();
request:
SendRequestImportDrive(nDrive); //demande le lecteur de 0 à 6 [inclus]
SendStart();//Demande que le transfert commence
Recevoir les 131072 envoyés par la G100
si on vt un autre lecteur retourner à 'request' sinon on passe à la ligne en dessous.
CloseCasioCom();
]
bool SendStart()
{
Envoyer 1 octet de valeur 6
attendre le retour d'un octet
(retourne vrai si tout ok.)
}
Regarde le code dans F100 InitCasioCom doit s'appeler InitCom, ca initialise le port+envoi de paquet.
Pareil pour CloseCasioCom c CloseCom (envoi 40 octets + ferme le port)
Si jamais tu comprends tjrs pas je px aller plus en détail, mais la je suis un peu occupé.
Hors ligne
Ok. Merci. Je vait voir ça demain ou ce soir. A mon avis je vait revenir
Ps : oui, j'ai le code source aussi de FlashEdit, mais je connais pas trop le VB. J'essaye de comprendre ET la syntaxe VB ( le & c'est pour concaténer 2 chaine de charactères ?) ET le fonctionnement du code.
Pour Flash 100, il se trouve que le logiciel est assez énorme, donc pour trouver les liaison de fonction à traver les différentes classes des différents fichier, c'est un peu galère. Mais si dada66 m'aide à suivre le bon chemin, ça devrait aller.
Hors ligne
Ah oui, c vrai que tu n'as pas VC++, je comprends que tu sois un peu en galère.
il faut regarde les fichiers .h et .cpp de "Protocol" et "CasioProtocol" et "GComm".
Protocol étant la classe mére regroupant les messages d'erreur, l'init du port com,...
Hors ligne
Bon. Dada66 t'on avant dernier messages était parfait . J'ai pu refaire le protocole de réception d'un lecteur. Y'a quand même un hic : l'initialisation marche (j'envoie la chaine de caractère et la calculette me renvois bien le code ASCII 19 )
Mais quand je lui demande ensuite "ImportDrive" la calculette m'affiche une erreur et elle coupe la communication. (ps : je ne peut donc pas arriver à la fonction SendStart). J'ai essayé pour les 7 lecteurs et ça ne marche pour aucun. Je me dit que c'est peut être parce que ma calculette ne contient aucun lecteur ?
En tout cas, peut tu me refaire le même type de descriptif que en haut, mais cette fois pour l'envois d'un .lec (est ce que c'est le même protocol pour les .cfx ?) ???
Merci beaucoup (encore) d'avoir la patience de reprendre avec moi ce gros projet...
Ps : j'ai configuré mon port comme ça, ça convient ?
Baud = 38400
Bits = 8 bits de données
Parity = aucune
Stop = 1 bit de stop
XON, CTR, DTS désactivé
Hors ligne
Je pense que ton pb c plutot que tu envois trop vite les octets.
Regarde bien dans mon code mais g mis un wait juste après avoir configurer le port série.
Ensuite as-tu envoyé les 40 octets symbolisant le départ avant d'envoyer les 40 octets d'importation d'un lecteur sur le PC?
Pour l'exportation
[
InitCasioCom();
Send40octets(export_drive[nDrive]); // envoi les 40 octets pour dire quel lecteur on veut
Receive(1);
//ensuite plus complexe.
faire
Envoyer la valeur 58 (1 octet)
Envoyer 1024 du lecteur
Envoyer le checksum (1octet) //regarde sur f100 pour le calcul
Receive(1) != 6;//erreur
tant que le nbre d'octets envoyé est inférieure à 131072.
ensuite soit tu renvois un lecteur soit tu stop avec CloseCasioCom()
Pense à mettre des wait comme g mis sur f100 car LINK rame un peu par moment et aime pas trop qu'on le brusque.
Par contre si tu vx aussi etre compatible avec GComm 1.00, tu n'as pas besoin de wait et d'ailleurs tu devrais avoir moins de pb.
]
Pour le format cfx, c juste un systeme de communication. Le procole reste le meme. C à toi d'être intelligent en fait. Du demande dans un premier tps à la g100 de t'envoyer son systeme, après tu lui demandes c lecteur (au choix) analyse c lecteur (vide ou utilisé) ensuite tu renvois le systeme modifié et les nouveaux lecteurs. En tout cas si tu croyais que le prog LINK de casio ajoutait tout seul les icones et bien tu te trompes, lol.
Hors ligne
Bon. Et bien là j'ai un big problème.
Pour le commencement je me suis répartis les différentes étapes de la réception d'un lecteur en Bouton (interface) de manière à suivre plus facilement le déroulement de la transmition.
Je clique donc sur init. Le logiciel envoie ASCII 22. La calculette me renvois ASCII 19. Chouette !
Je lui envoie (par mon deuxième bouton) la chaine de 40 caractères de l'init. La calculette me renvoie une chaine de 40 caractère (":MDL1GY351..."). Youpi, ça à l'air de coller !
Je clique sur le troisième bouton (requète d'un lecteur). Mon app envoie une chaine de 40 caractère pour spécifier à la calculette le lecteur que je veut. Mais là, paf, ma calculette m'affiche un beau transmition error et mon app attend pour recevoir des infos de confirmation (qu'elle ne reçoit pas d'ailleur... évidement puisque la calculette coupe la communiocation d'un coup).
Je pense donc que ça vient pas d'un wait (que j'ai mit) car l'init à l'air de marcher. De plus, comme c'est moi qui exécute tâche après tâche par des boutons, alors on peut pas dire que ce soit très (trop) rapide... Le problème vient donc certainement de la fonction de réception... Mais pourquoi ???? Je ne sait pas. Je cherche, mais c'est l'erreur invariable. J'ai beau ralentir la transmition (un wait entre chaque char, ralentissement des baud, ...) rien y fait ! Y'a que l'init qui passe.
Ps : Je redit -> j'ai pas eu le temps d'envoyer le code ASCII 6 de la fonction SendStart, puisque cette fonction vient après la demande d'un lecteur (et c'est cette demande qui fait planter la calculette, donc...)
PPs : dada66, merci pour ta méthode d'envoie. Mais pour l'instant, faut que j'essaye de faire marcher la fonction la plus simple : la réception ... :cry:
Hors ligne
n'oublie pas que dans la fonction InitCasioCom il faut envoyer 1 octets, recevoir 1 octets, envoyer 40 octets, recevoir les 40 octets (ca apparement tu le fais) et aussi appeler SendStart dans cette méthode (c peut être ca que tu as oublié)
Par contre fait attention, car tu utilises plusieurs bouton pour la comm et donc toi tu as un délai de réponse assez lent, le prog LINK a un timeout assez court a des endroit de l'init.
Mais si tu as oublié d'appeler SendStart dans initcasiocom c ca qui merde.
Hors ligne
Y'a un SendStart dans l'init ??? Y'en à donc 2 en tout dans le protocole (un à l'init, et un après envoie du driver qu'on veut recevoir) ? J'ai du louper la ligne dans ton code... (car moi, je faisait pas de sendstart dans l'init mais après la requète d'un lecteur uniquement...)
Je regarde ça ce soir quand je suis chez moi.
Ps : un autre nom conviendrait mieux alors pour SendStart 'plutôt Validate ou un truc dans le genre)
Merci en tout cas. (je sens que ça va marcher... )
PPS : désolé si je répond pas plus souvent, mais c'est que je suis chez moi que le soir, et j'ai pas de temps libre pendant la journé pour aller au cybercafé du coin...
Hors ligne
Bon, ben je suis happy. J'ai finit par faire fonctionnait la chose (c'était bien le SendStart dans l'init). Je récupère donc mon .lec (j'ai pris le lecteur 0/6). J'arrive même à fermer correctement la communication (vous moquer pas derrière !)
Mais j'ai quand même un problème (faut bien). Le lecteur reçut (mis à part que c'est lent à recevoir) ne pèse que 128 493 octets alors qu'il devrait apparemment peser 131 072. Soit un manque de 2 579 octets... C'est normale ?
Ps le fichier .lec reçus commence par ":"+ série de char de code hexa FF puis finit par "àá0". C'est peut être donc parce qu'il n'y a pas de charactère de remplissage de code hexa FF à la fin qu'il est plus légé ?
[EDIT]
Le fichier contient plein de lettres et de nom de fichier (DOS BIOS c-a-d le nom de l'OS, ...) je suppose donc que le lecteur 0/6 est le système ?
Hors ligne
la première chose que tu recois est le lecteur A:+le menu, donc oui, le système.
Hors ligne
non c pas normal ! (en quelque sorte). Il faut absolument que tu recoives 131072 octets, la caltos envoit tjrs 131072 pour un lecteur de la flash, que ce soit le systeme ou un lecteur (L à Q).
Le fait que tu n'es pas tous les octets vient du faites que le protocole casio ne vérifie pas si tu recois bien les octets (il s'en fout!) et les envoi en masse. Donc si ton prog est lent ou le pc à une petite absence c suffisant pour rater des octets.
C pour ca que gcomm ne peut pas écrire directement sur le systeme recu par LINK dans un lecteur, GComm ne voyait qu'autour de 70Ko.
Hors ligne
Bon, j'ai optimisé le code. J'ai essayé de recevoir un lecteur que j'avais envoyé (oui j'ai réussi à implémenter l'envoie. ça à l'air de marcher nikel. merci dada66). Total 131075 octets... Pas moyen de tomber sur du 131072 bordel de m*rd* ! Après inspection du fichier, il c'est avéré que les 3 octets de trop venait d'un ":" au début du fichier et de 2 char de code ASCII 6 à la fin. ça doit être des caractère de confirmation de début et de fin de réception du fichier que j'ai pas traité et que j'ai envoyé dans le fichier...?
Mise à part ça, je voudrais passer au choses sérieuses Je voudrait ajouter une icône à mon menu qui pointe vers un fichier .exe (un explorateur par exemple). D'après ce que j'ai compris, il faut récupérer le lecteur système ("A")... Mais comment l'éditer ensuite (ou plutôt qu'est ce qui faut modifier dedans ?) ?
Tout ça parce que je croyait que les .cfx était traité automatiquement par LINK...
Hors ligne
Code source de F100 !!! regarde les fichiers functionsystem.cpp et .h
ensuite regarde le code dans CFXWindow.cpp dans la méthode StartCom ou un truc comme ca.
Hors ligne
Bon. J'ai finit par implémenter la gestion système (pour l'instant ça reste basique, juste pour l'ajout d'un menu). ça marche, à un problème près : l'icône ne s'affiche pas. On peut exécuter le menu ajouté (on peut aller dessus. C'est un cadre blanc, qui devient noir lors de la sélection).
Dans le lecteur envoyé, j'ai le logiciel (qui s'exécute correctement) et l'image (qui n'apparaît pas ...)
Pour la structure, j'ai mis pour mon premier menu (il n'y en avait pas d'autre à part celui par défaut) avec ces valeurs :
struct{
char number; = $0F (le dernier menu,"SYSTEM", affiche $0E. Donc j'ai incrémenté de 1)
char bmp; = 2 (apparament, d'après tes sources dada66, c'est constant)
char version[4]; ="1.00" (pas d'importance apparament)
char vide; =$00 (null)
char name[13]; = "FICH.EXE"
char lecteur[13]; = "L:"
char image[13]; = "FICH1.BMP"
char arg[20];= "EXPLO" (ça a une importance ? j'ai mis ça au pif)
};
D'où vient le problème ? Du "number" ?
Hors ligne
je crois qu'il ne faut pas mettre d'argument, sauf pour les jointx.exe de la G100+
Hors ligne
Hum, non, apparament c'est pas ça...
Hors ligne
Pages: 1 2