Chalut chalut, vu que c'est les vacances et que j'ai du temps libre, j'ai eu l'idée de faire un projet : surfer reddit sur ma casio (en perme, ou en maths).
Pour ceux qui ne connaissent pas, reddit c'est un genre de forum avec plein de sous-forums sur différents thèmes, enfin c'est un peu dur à expliquer vu qu'il n'y a aucun équivalent français. (si vous voulez voir, c'est http://reddit.com/)
Le but sera d'aller sur un add-in qui serait l'équivalent d'une application reddit sur téléphone : on pourra aller entre les posts, et regarder les commentaires. C'est que du texte donc ce serait pas trop trop difficile à afficher, surtout que le format est très simple.
Donc le fonctionnement du truc :
-Une appli sur mon tel (android) se connecte à reddit.com via ma 3g (ça consommera ma 3g mais je m'en fous c'est que du texte, ça bouffe rien) et, après avoir filtré l'html inutile genre la sidebar etc (ça aidera à la transmission étant donné que si j'ai bien compris il y a des limites de transmission assez basses), transmet l'html filtré à la calculatrice via bluetooth
-La calculatrice reçoit l'html via bluetooth et l'affiche avec l'add-in
-L'add-in transmet les commandes de l'utilisateur (afficher une page, etc) via bluetooth
-Le téléphone reçoit les commandes de l'utilisateur et fait une requête web en conséquence
-etc
Donc voilà, si quelqu'un veut aider (dans le dev de l'appli android ou dans le dev de l'add-in) qu'il soit le bienvenu mais pour l'instant ma seule question est : où brancher l'adaptateur bluetooth sur ma casio 95 SD ? Je le branche sur les piles comme pour l'adaptateur wifi, ou je le branche autre part ?
Merci d'avance
Edit: Pour les gens du futur qui s'intéresseraient à ce projet :
- Le projet a été terminé et fonctionne :
- Le code est ici : http://git.planet-casio.com/Zezombye/caddit/tree/master
Il faut compiler l'addin (avec le SDK sous windows ou GCC sous linux, il y a des tutoriels sur le forum) et l'application android avec Android Studio.
- À noter que ça bug un peu, j'ai retesté récemment et les titres des posts bugent (le reste marche plus ou moins, il y a un petit bug après 10000 octets).
- Concernant le hardware (le module bluetooth) voici un schéma + photos :
Hardware
Hardware
Toutefois si vous voulez vous lancer dans ce projet je vous déconseille de faire comme j'ai fait au niveau du port 3-pin femelle (les fils se barrent et le scotch ne tient pas, donc niveau discrétion c'pas top si on doit passer 5 mn à remettre les fils en place).
Pour l'instant on cherche à alimenter le module avec une pile externe comme ça on risque au moins pas de cramer l'arduino du coup c'est p'têt pas pour aujourd'hui non plus, on verra de toute façon, j'ai les vacs dans une semaine
Ajouté le 22/04/2016 à 19:21 :
Il y a de la magie vaudou dans mon code et j'aimerais m'en débarasser.
Quand on initialise l'appli ça donne ça :
Le string complet est :
<t This is the text post kek.> <1 Another top lvl comment > <1 Top lvl comment, with word wrap > <2 Second level comment with word wrap> <3 Third level comment with word wrap too> <4 Top-level comment that is very long like verrry long daufq> <2 Another second lvl comment>
Donc on peut constater plusieurs erreurs :
- Au niveau du text post : quand je ne mets pas un espace avant le >, ça met toujours le mot sur une nouvelle ligne. On peut constater ce comportement avec certains commentaires certaines fois. Le plus bizarre est que le bug qui met le mot sur une nouvelle ligne (alors qu'il ne devrait pas) prend quand même en compte la hauteur... sauf dans le text post. En toute logique la fonction dispStr() devrait retourner la valeur exacte de la hauteur vu qu'elle retourne la différence entre la hauteur initiale (donc là où on lui a demandé d'afficher le string) et la hauteur finale (là où elle a dessiné le dernier pixel), et comme elle a dessiné ces pixels elle aurait du en toute logique incrémenter la hauteur...
-Au niveau du 1er commentaire : il y a une ligne ajoutée à la fin, pour je ne sais quelle raison. Mais le plus bizarre est qu'en appuyant sur une touche (donc en appelant la méthode une deuxième fois), la ligne ajoutée à la fin s'auto-corrige, et reste auto-corrigée même en réappuyant.
-Au niveau du 2nd commentaire : il y a une ligne ajoutée à la fin, pour je ne sais quelle raison. Le plus bizarre est qu'avant c'était le 1er commentaire, et qu'il faisait le comportement de celui qui est maintenant le 1er (mais le comportement inverse : c'est à dire qu'en appuyant sur une touche, il ajoutait la ligne), mais en voulant débugger, j'ai changé le texte du text post (qui pour je sais pas quelle raison a une influence sur le texte du commentaire, alors que ces textes sont envoyés séparément à la fonction d'affichage...?), et quand je l'ai changé il ajoutait tout le temps la ligne. J'ai remis le texte du text post exactement comme avant, et là il ajoute tout le temps la ligne, au lieu de ne pas l'ajouter la 1ère fois.
Donc en gros il y a des comportements pas consistants du tout dans mon code, dont je n'ai aucune idée d'où ils viennent, et qui n'ont aucune logique. o_o
Si vous voulez tester l'addin, le voilà (il faut monochromelib) :
Bon, je m'excuse d'avance mais je n'ai pas lu en détail le code. Ayant vu des choses bizarres du même ordre avec WebCalc, j'ai peut-être des idées pour les problèmes d'algo :
Au niveau du text post : quand je ne mets pas un espace avant le >, ça met toujours le mot sur une nouvelle ligne.
T'es sûr que la longueur du dernier mot est calculée correctement ? Je me demande si le calcul de longueur ne dépasse pas le caractère '>'. Dans ce cas, l'espace forcerait le calcul à s'arrêter et renverrait le bon résultat.
Au niveau du 1er commentaire : il y a une ligne ajoutée à la fin, pour je ne sais quelle raison.
Ton algorithme de word wrap ne doit ajouter des fins de ligne que lorsqu'il y a encore du texte à afficher. Est-ce que voyant que la ligne est pleine, tu ne serais pas revenu à la ligne en incrémentant tes compteurs, pour arrêter ensuite le dessin en te rendant compte qu'il n'y a plus rien à afficher ?
J'ai l'impression que le dernier cas est sensiblement identique au deuxième.
Au passage ton code ne modifie pas les chaines de caractères, n'est-ce pas ? Bon, ben déclarer les en const char *, ça t'évitera des risques.
T'es sûr que la longueur du dernier mot est calculée correctement ? Je me demande si le calcul de longueur ne dépasse pas le caractère '>'. Dans ce cas, l'espace forcerait le calcul à s'arrêter et renverrait le bon résultat.
Le calcul de longueur ne dépasse pas le caractère '>' sinon il serait affiché. En fait je déclare un char post[30000], donc logiquement il y a que des \0 dedans, ensuite je mets le contenu du string strCmt dans le post jusqu'à ce qu'il rencontre un '>'. Il appelle ensuite la fonction d'affichage, avec comme string post et comme longueur le nombre de caractères stockés.
Donc la fonction d'affichage elle reçoit "This is the text post kek.\0\0\0". À chaque espace elle calcule la longueur de chaque caractère après l'espace, jusqu'à rencontrer un autre espace ou un '\0'. Donc logiquement elle devrait traiter le \0 après le '.' comme un espace. Après le '.' la longueur est finie donc il n'essaie plus d'afficher.
Non, le truc qui m'embête le plus c'est que ce comportement n'est pas consistant. Si à chaque fois mon algorithme d'affichage me faisait ce bug alors je saurais que c'est ça. Mais là, quand j'affiche le text post, ça me fait un comportement différent que quand j'affiche un commentaire ou quand j'affiche la liste des posts. Par exemple on voit que le 3e commentaire est totalement normal alors que je n'ai pas mis d'espace avant le '>'. Mais le 2ème commentaire, je dois mettre un espace avant le '>' sinon il m'affiche tout le temps une nouvelle ligne. Et le 1er commentaire, je dois mettre un espace avant le '>' sinon il m'affiche tout le temps une nouvelle ligne, mais uniquement après avoir appuyé sur une touche (donc rappelé la méthode).
Donc le dernier cas est un peu similaire au deuxième, sauf qu'il fait exactement le contraire (l'un corrige la ligne, l'autre la rajoute), et le 2e cas n'apparaît pas à l'initialisation. C'est même pas mon truc de word wrap (comme on pourrait le penser) parce que quand je modifie le texte du text post, ça modifie le comportement des commentaires, parfois irréversiblement (cad: je modifie le texte, là la ligne apparait tout le temps, je le remets comme avant, le comportement ne se remet pas comme avant), et logiquement le text post ne devrait avoir absolument aucun rapport avec les commentaires vu qu'ils sont envoyés séparément à la fonction d'affichage.
En fait je déclare un char post[30000], donc logiquement il y a que des \0 dedans
Non. Le tableau là n'est pas initialisé, il n'y a n'importe quoi dedans. Si tu veux l'initialiser, il faut le faire explicitement. Par chance, si l'on veut remplir un tableau de 0, il y a une solution facile :
char post[30000] = { 0 };
Attention, cela ne fonctionne qu'avec la valeur 0 ! Si une autre valeur est indiquée, seule la première case sera initialisée.
Du coup ce que tu dis dans le second paragraphe n'est plus vrai et tu retombes sous mon hypothèse.
Non, le truc qui m'embête le plus c'est que ce comportement n'est pas consistant.
Passe les pointeurs en const ! Vérifie l'initialisation de toutes tes variables et simule tranquillement l'algo dans ta tête.
Il y a quelque chose qui change d'un appel à l'autre. Contenu du texte, valeur de variable modifiée, argument différent ? Vérifie bien, il y a forcément quelque chose.
Fife86 a écrit : Non ça ne met pas à 0. Pour mettre à 0, tu peux créer une boucle qui parcours tout le tableau en mettant les valeurs à 0.
Oui, c'est-à-dire :
memset(array, 0, 30000);
Mais en fait l'initialisation à zéro existe déjà, sous la forme que j'ai déjà citée :
char array[30000] = { 0 };
Inutile donc de faire une boucle.
Zezombye a écrit : (mais heu quand on fait char post[30000] c'est pas censé réserver 30000 octets qui sont donc initialisés à 0? pourquoi ça fait pas ça ?)
Parce que souvent il n'y a pas besoin d'initialiser les tableaux, donc on ne le fait pas parce que c'est coûteux.
Bref donc maintenant l'affichage marche parfaitement, v'la une petite démo :
J'ai reçu le matos pour le bluetooth et la connexion marche parfaitement avec serial monitor, on peut faire la communication casio-téléphone
Par contre j'arrive pas à implémenter les fonctions pour le port série sur mon addin: le SDK ne reconnait pas les fonctions Serial_WriteByte, Serial_ReadByte, Serial_Open, etc, qui sont dans les sources de serial monitor. De plus je m'aperçois que sur la doc de simon lothar il n'y a absolument aucune mention de serial_writebyte ou serial_readbyte (par contre il y a mention de serial_open). Du coup je pourrais faire comment pour implémenter le port série (sachant qu'il me reconnaît pas non plus Serial_ReadNBytes etc)? Et aussi, elles sortent d'où les fonctions Serial_WriteByte/ReadByte ?
Ça fait une semaine que j'ai l'impression de renvoyer que des liens du sites dès que quelqu'un a un problème. Sérieusement, il suffit de chercher un peu avant de dire "j'y arrive pas…".
D'autant plus que le site a une barre de rechercher, et que si on tape "Serial_WriteByte" dedans, le tuto est le troisième lien.
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Donc sinon j'ai réussi à mettre tout le montage dans une boite qui tient dans ma trousse, ce qui était assez chaud parce que les fils ne s'emboitaient pas correctement, on a fini par mettre des fils de led dans les ports pour que les pins tiennent mieux. (et du scotch )
Du coup la communication casio/tel est totalement finie, grand merci à Darkstorm pour m'avoir aidé au niveau du montage
Après quelques ptits essais, la réception a l'air de marcher aléatoirement (il voulait pas du tout afficher le string, je le réinstalle, maintenant il veut bien o_o) mais bon pour l'instant ça marche toujours, ptêt que j'avais installé une ancienne version.
Par contre pour la transmission (addin -> tel) ça marche à moitié et j'ai aucune idée de pourquoi. J'ai testé ces 2 méthodes là :
void sendSerial(unsigned char* code, int length) {
int i;
/*for (i = 0; i < length; i++) {
Serial_WriteByte(code[i]);
}
Serial_WriteByte('\n');*/
Serial_WriteBytes(code, length);
}
Elles produisent des caractères bizarres (du genre si j'envoie TestTransmission il affiche Tes?Q/\??????????) et ce n'est pas du tout exploitable. J'ai pensé au début que c'était le port RX qui était mal branché mais je pense pas parce que quand j'envoie avec Serial Monitor ça marche parfaitement, aucun caractère n'est mal transmis. Une idée ?
Le scroll par bloc, c'est parce que sinon c'est super lent et si je fais comme dans webcalc (c'est à dire n'afficher uniquement que les paragraphes à afficher) la vitesse fluctue ce qui rend la lecture assez chiante
J'utilise le tuto de Darkstorm c'est pour ça que c'est assez bizarre serial monitor utilise exactement les mêmes méthodes (même header et fichier .src). Sinon j'ai déterminé que c'est pas l'émetteur bluetooth le problème mais bien mon addin, en envoyant sur une autre calculette ça affiche toujours du wtf.
Les deux méthodes affichent la même chose ? Est-ce que l'une des caltos est overclockée ?
Ajouté le 01/05/2016 à 23:56 :
Ah, et au passage c'est Dark Storm, Darks, Darkyz, Darky', mais pas Darkstorm
(Sauf sur LeekWars, et encore c'est en CamelCase, donc DarkStorm)
Finir est souvent bien plus difficile que commencer. — Jack Beauregard
Nope aucun overclock, et les deux méthodes affichent plus ou moins la même chose (enfin ce qui est affiché varie, mais c'est toujours du wtf).
Je pense qu'en fait la calculette envoie les octets plus vite que 9600/sec, ce qui explique pourquoi le premier octet est toujours reçu mais pas toujours les autres, je vais essayer en faisant Sleep(1) avant chaque envoi d'octet (comme dans Serial Monitor).
Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd
mais pour l'instant ma seule question est : où brancher l'adaptateur bluetooth sur ma casio 95 SD ? Je le branche sur les piles comme pour l'adaptateur wifi, ou je le branche autre part ?
Citer : Posté le 27/03/2016 15:07 | #
Ça devrait marcher en effet
On attend la réponse !
Citer : Posté le 28/03/2016 07:12 | #
Pour l'instant on cherche à alimenter le module avec une pile externe comme ça on risque au moins pas de cramer l'arduino
Ajouté le 22/04/2016 à 19:21 :
Il y a de la magie vaudou dans mon code et j'aimerais m'en débarasser.
Quand on initialise l'appli ça donne ça :
Le string complet est :
Donc on peut constater plusieurs erreurs :
- Au niveau du text post : quand je ne mets pas un espace avant le >, ça met toujours le mot sur une nouvelle ligne. On peut constater ce comportement avec certains commentaires certaines fois. Le plus bizarre est que le bug qui met le mot sur une nouvelle ligne (alors qu'il ne devrait pas) prend quand même en compte la hauteur... sauf dans le text post. En toute logique la fonction dispStr() devrait retourner la valeur exacte de la hauteur vu qu'elle retourne la différence entre la hauteur initiale (donc là où on lui a demandé d'afficher le string) et la hauteur finale (là où elle a dessiné le dernier pixel), et comme elle a dessiné ces pixels elle aurait du en toute logique incrémenter la hauteur...
-Au niveau du 1er commentaire : il y a une ligne ajoutée à la fin, pour je ne sais quelle raison. Mais le plus bizarre est qu'en appuyant sur une touche (donc en appelant la méthode une deuxième fois), la ligne ajoutée à la fin s'auto-corrige, et reste auto-corrigée même en réappuyant.
-Au niveau du 2nd commentaire : il y a une ligne ajoutée à la fin, pour je ne sais quelle raison. Le plus bizarre est qu'avant c'était le 1er commentaire, et qu'il faisait le comportement de celui qui est maintenant le 1er (mais le comportement inverse : c'est à dire qu'en appuyant sur une touche, il ajoutait la ligne), mais en voulant débugger, j'ai changé le texte du text post (qui pour je sais pas quelle raison a une influence sur le texte du commentaire, alors que ces textes sont envoyés séparément à la fonction d'affichage...?), et quand je l'ai changé il ajoutait tout le temps la ligne. J'ai remis le texte du text post exactement comme avant, et là il ajoute tout le temps la ligne, au lieu de ne pas l'ajouter la 1ère fois.
Donc en gros il y a des comportements pas consistants du tout dans mon code, dont je n'ai aucune idée d'où ils viennent, et qui n'ont aucune logique. o_o
Si vous voulez tester l'addin, le voilà (il faut monochromelib) :
main.c http://pastebin.com/QENDLAu0
fonts.h http://pastebin.com/LPe1QaAe
Si vous pouviez me trouver ce bug ce serait assez sympa svp
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 22/04/2016 20:11 | #
Bon, je m'excuse d'avance mais je n'ai pas lu en détail le code. Ayant vu des choses bizarres du même ordre avec WebCalc, j'ai peut-être des idées pour les problèmes d'algo :
T'es sûr que la longueur du dernier mot est calculée correctement ? Je me demande si le calcul de longueur ne dépasse pas le caractère '>'. Dans ce cas, l'espace forcerait le calcul à s'arrêter et renverrait le bon résultat.
Ton algorithme de word wrap ne doit ajouter des fins de ligne que lorsqu'il y a encore du texte à afficher. Est-ce que voyant que la ligne est pleine, tu ne serais pas revenu à la ligne en incrémentant tes compteurs, pour arrêter ensuite le dessin en te rendant compte qu'il n'y a plus rien à afficher ?
J'ai l'impression que le dernier cas est sensiblement identique au deuxième.
Au passage ton code ne modifie pas les chaines de caractères, n'est-ce pas ? Bon, ben déclarer les en const char *, ça t'évitera des risques.
Citer : Posté le 22/04/2016 20:28 | #
Le calcul de longueur ne dépasse pas le caractère '>' sinon il serait affiché. En fait je déclare un char post[30000], donc logiquement il y a que des \0 dedans, ensuite je mets le contenu du string strCmt dans le post jusqu'à ce qu'il rencontre un '>'. Il appelle ensuite la fonction d'affichage, avec comme string post et comme longueur le nombre de caractères stockés.
Donc la fonction d'affichage elle reçoit "This is the text post kek.\0\0\0". À chaque espace elle calcule la longueur de chaque caractère après l'espace, jusqu'à rencontrer un autre espace ou un '\0'. Donc logiquement elle devrait traiter le \0 après le '.' comme un espace. Après le '.' la longueur est finie donc il n'essaie plus d'afficher.
Non, le truc qui m'embête le plus c'est que ce comportement n'est pas consistant. Si à chaque fois mon algorithme d'affichage me faisait ce bug alors je saurais que c'est ça. Mais là, quand j'affiche le text post, ça me fait un comportement différent que quand j'affiche un commentaire ou quand j'affiche la liste des posts. Par exemple on voit que le 3e commentaire est totalement normal alors que je n'ai pas mis d'espace avant le '>'. Mais le 2ème commentaire, je dois mettre un espace avant le '>' sinon il m'affiche tout le temps une nouvelle ligne. Et le 1er commentaire, je dois mettre un espace avant le '>' sinon il m'affiche tout le temps une nouvelle ligne, mais uniquement après avoir appuyé sur une touche (donc rappelé la méthode).
Donc le dernier cas est un peu similaire au deuxième, sauf qu'il fait exactement le contraire (l'un corrige la ligne, l'autre la rajoute), et le 2e cas n'apparaît pas à l'initialisation. C'est même pas mon truc de word wrap (comme on pourrait le penser) parce que quand je modifie le texte du text post, ça modifie le comportement des commentaires, parfois irréversiblement (cad: je modifie le texte, là la ligne apparait tout le temps, je le remets comme avant, le comportement ne se remet pas comme avant), et logiquement le text post ne devrait avoir absolument aucun rapport avec les commentaires vu qu'ils sont envoyés séparément à la fonction d'affichage.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 22/04/2016 20:45 | #
Non. Le tableau là n'est pas initialisé, il n'y a n'importe quoi dedans. Si tu veux l'initialiser, il faut le faire explicitement. Par chance, si l'on veut remplir un tableau de 0, il y a une solution facile :
Attention, cela ne fonctionne qu'avec la valeur 0 ! Si une autre valeur est indiquée, seule la première case sera initialisée.
Du coup ce que tu dis dans le second paragraphe n'est plus vrai et tu retombes sous mon hypothèse.
Passe les pointeurs en const ! Vérifie l'initialisation de toutes tes variables et simule tranquillement l'algo dans ta tête.
Il y a quelque chose qui change d'un appel à l'autre. Contenu du texte, valeur de variable modifiée, argument différent ? Vérifie bien, il y a forcément quelque chose.
Citer : Posté le 22/04/2016 20:49 | #
...tu viens de régler tout mon problème o_o
(mais heu quand on fait char post[30000] c'est pas censé réserver 30000 octets qui sont donc initialisés à 0? pourquoi ça fait pas ça ?)
merci lephe
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 22/04/2016 21:13 | #
Non ça ne met pas à 0. Pour mettre à 0, tu peux créer une boucle qui parcours tout le tableau en mettant les valeurs à 0.
- Kirby's DreamLand : Gobe , Gobe , Gobe !!!
- L'invasion Seanchans : Détruit la flotte ennemis a bord du "Danseur des vagues".
Citer : Posté le 22/04/2016 21:15 | #
Non ça ne met pas à 0. Pour mettre à 0, tu peux créer une boucle qui parcours tout le tableau en mettant les valeurs à 0.
Oui, c'est-à-dire :
Mais en fait l'initialisation à zéro existe déjà, sous la forme que j'ai déjà citée :
Inutile donc de faire une boucle.
(mais heu quand on fait char post[30000] c'est pas censé réserver 30000 octets qui sont donc initialisés à 0? pourquoi ça fait pas ça ?)
Parce que souvent il n'y a pas besoin d'initialiser les tableaux, donc on ne le fait pas parce que c'est coûteux.
merci lephe
Je t'en prie
Citer : Posté le 23/04/2016 20:44 | #
Bref donc maintenant l'affichage marche parfaitement, v'la une petite démo :
J'ai reçu le matos pour le bluetooth et la connexion marche parfaitement avec serial monitor, on peut faire la communication casio-téléphone
Par contre j'arrive pas à implémenter les fonctions pour le port série sur mon addin: le SDK ne reconnait pas les fonctions Serial_WriteByte, Serial_ReadByte, Serial_Open, etc, qui sont dans les sources de serial monitor. De plus je m'aperçois que sur la doc de simon lothar il n'y a absolument aucune mention de serial_writebyte ou serial_readbyte (par contre il y a mention de serial_open). Du coup je pourrais faire comment pour implémenter le port série (sachant qu'il me reconnaît pas non plus Serial_ReadNBytes etc)? Et aussi, elles sortent d'où les fonctions Serial_WriteByte/ReadByte ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 23/04/2016 21:04 | #
Encore une fois, il suffit de chercher pas si loin que ça : http://www.planet-casio.com/Fr/programmation/tutoriels.php?id=54
Ça fait une semaine que j'ai l'impression de renvoyer que des liens du sites dès que quelqu'un a un problème. Sérieusement, il suffit de chercher un peu avant de dire "j'y arrive pas…".
D'autant plus que le site a une barre de rechercher, et que si on tape "Serial_WriteByte" dedans, le tuto est le troisième lien.
Citer : Posté le 24/04/2016 13:53 | #
Ha j'avais oublié qu'il était là ce tuto :x
Donc sinon j'ai réussi à mettre tout le montage dans une boite qui tient dans ma trousse, ce qui était assez chaud parce que les fils ne s'emboitaient pas correctement, on a fini par mettre des fils de led dans les ports pour que les pins tiennent mieux. (et du scotch
Du coup la communication casio/tel est totalement finie, grand merci à Darkstorm pour m'avoir aidé au niveau du montage
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 24/04/2016 17:34 | #
Ça commence à ressembler à quelque chose, c'est bien.
Citer : Posté le 25/04/2016 16:09 | #
Bien joué, ça avance c'est génial
C'est quoi le composant à gauche sur la deuxième photo ?
Citer : Posté le 25/04/2016 16:24 | #
Un jack femelle je pense
Pour pouvoir brancher un câble facilement.
Citer : Posté le 30/04/2016 13:40 | #
Après quelques ptits essais, la réception a l'air de marcher aléatoirement (il voulait pas du tout afficher le string, je le réinstalle, maintenant il veut bien o_o) mais bon pour l'instant ça marche toujours, ptêt que j'avais installé une ancienne version.
Par contre pour la transmission (addin -> tel) ça marche à moitié et j'ai aucune idée de pourquoi. J'ai testé ces 2 méthodes là :
int i;
/*for (i = 0; i < length; i++) {
Serial_WriteByte(code[i]);
}
Serial_WriteByte('\n');*/
Serial_WriteBytes(code, length);
}
Elles produisent des caractères bizarres (du genre si j'envoie TestTransmission il affiche Tes?Q/\??????????) et ce n'est pas du tout exploitable. J'ai pensé au début que c'était le port RX qui était mal branché mais je pense pas parce que quand j'envoie avec Serial Monitor ça marche parfaitement, aucun caractère n'est mal transmis. Une idée ?
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 30/04/2016 14:13 | #
Un problème d'encodage, peut-être ? Les caractères sont encodés en quoi du côté de la transmission, et du côté de la lecture ?
Mon blog ⋅ Mes autres projets
Citer : Posté le 30/04/2016 14:17 | #
Nope c'est pas un problème d'encodage vu que je reçois une partie des lettres et ce que je reçois est variable.
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 30/04/2016 16:35 | #
L'add-in a l'air pas mal. Pourquoi avoir scrollé par blocs comme ça au lieu d'y aller tranquillement au pixel ?
Simplement, si Serial Monitor fonctionne... utilise ses sources
Citer : Posté le 30/04/2016 17:25 | #
Le scroll par bloc, c'est parce que sinon c'est super lent
J'utilise le tuto de Darkstorm c'est pour ça que c'est assez bizarre
Ecrivez vos programmes basic sur PC avec BIDE
Citer : Posté le 01/05/2016 23:55 | #
Les deux méthodes affichent la même chose ? Est-ce que l'une des caltos est overclockée ?
Ajouté le 01/05/2016 à 23:56 :
Ah, et au passage c'est Dark Storm, Darks, Darkyz, Darky', mais pas Darkstorm
(Sauf sur LeekWars, et encore c'est en CamelCase, donc DarkStorm)
Citer : Posté le 02/05/2016 11:46 | #
Nope aucun overclock, et les deux méthodes affichent plus ou moins la même chose (enfin ce qui est affiché varie, mais c'est toujours du wtf).
Je pense qu'en fait la calculette envoie les octets plus vite que 9600/sec, ce qui explique pourquoi le premier octet est toujours reçu mais pas toujours les autres, je vais essayer en faisant Sleep(1) avant chaque envoi d'octet (comme dans Serial Monitor).
Ecrivez vos programmes basic sur PC avec BIDE