PIN²IDE : Interface Haut Niveau + moteur graphique

[damien d.]

C'est COOL tout ca :D

Tu pourrais pas nous faire une petite video de demo pour l'instensité lumineuse? J'en bave déja :P

[romain]

Salut Pascal,

pour commencer, c'est assez osé de mettre le compilo en cause... J'ai déjà fait plusieurs montages où le PIC se sert des 3 bank de mémoires et je n'ai jamais eu aucun souci. Il faut savoir que PICC est utilisé dans des milieux professionnels et à mon avis il doit être assez éprouvé comme ça
Pour la FIFO non circulaire, elle l'était, mais vu les merdes que j'ai eu (peut-être à cause de la RAM, interférences, etc...) j'ai préféré simplifier au max le code.

Pour le protocole c'était un truc vraiment optimisé, mais pas pratique pour faire du debug c'est vrai... J'aurai peut-être du voir plus facile et moins "rapide", bien que je ne pense pas que la vitesse de la liaison influe tant que ça en fin de compte (à partir de 38400 bien entendu, ne comparons pas à 9600).

Pour la vitesse de la liaison série, il semble que ce soit le PIC qui ne supporte pas plus que 38400baud. J'ai tenté 56000, comme toi, mais l'erreur de calcul du baudrate est vraiment trop importante et lors de gros envois, la liaison se désynchronise.

Tu parles de la vitesse de l'I²C : tu peux la remonter à 1Mbps sans problème (c'était la configuration d'origine); je l'ai diminuée pour les mêmes raisons qui m'ont poussées à brider tout mon code.

Avec ce que tu as fait, il ne manque plus que les bobines et nous pourrons envoyer un proto fonctionnel (en réalisant 2-3 belles cartes) à Damien afin qu'il commence de son côté un beau plateau

[Papo06]

C'est osé, mais c'est comme ça

Je me doute bien qu'il y a un truc qui va pas quelque part, soit au niveau config du chip (déjà le compilo quand ont veut utiliser les banques 2 et 3 il gueule et ça c'est super louche)

J'ai fait un petit programme ultra con on ne peut plus simple:

bank1 char buffer[80];

dans main:

80 x envoi('*');
80 x transmission => sortie nickelle de 80 étoiles.

ensuite le même code excatement mais dans l'interruption sur char reçu ou timer :

80 x envoi('*');
80 x transmission => sortie nickelle d'environ 30 étoiles suivie d'un tas de merdre suivi d'étoile.

Le délire...

Pascal

[damien d.]

Avec ce que tu as fait, il ne manque plus que les bobines et nous pourrons envoyer un proto fonctionnel (en réalisant 2-3 belles cartes) à Damien afin qu'il commence de son côté un beau plateau

Mais tétoitoi!! J'était content jusque la ca avancais et je bossai pas! Z'allez pas comploter pour me mettre au boulot nan!!

Blague de feignasse a part, c'est clair que j'adorerai jouer avec ce truc

[Papo06]

C'est osé, mais c'est comme ça

Je me doute bien qu'il y a un truc qui va pas quelque part, soit au niveau config du chip (déjà le compilo quand ont veut utiliser les banques 2 et 3 il gueule et ça c'est super louche)

J'ai fait un petit programme ultra con on ne peut plus simple:

bank1 char buffer[80];

80 x envoi('*');

dans main:

80 x transmission => sortie nickelle de 80 étoiles.

ensuite le même code excatement mais dans l'interruption sur char reçu ou timer :

80 x transmission => sortie nickelle d'environ 30 étoiles suivie d'un tas de merdre suivi d'étoile.

Le délire...

Pascal

Et j'ajoute: suivi d'un reboot...

En fait ce qu'il se passe c'est que lorque l'interruption apparait, l'environnement de départ (registre, pointeur de retour etc) est sauvegardé dans la banque courante, que ça soit la 0 ou la 1 (c'est ce qui est écrit dans la doc du compilo) et normalement il réserve donc un emplacement à des adresses communes aux banques 0 et 1 pour que quand l'it apparait en théorie ça n'a pas d'impact.

jusque là tout va bien sauf que manifestement la pratique ne rejoint pas la théorie et le compilo laisse réserver un tableau en banque 1 aux mêmes adresses qu'il utilise pour sauvegarder l'environnement et ça c'est pas normal...

Pascal

[romain]

Salut Pascal,

tu as quelle version de PICC?? Si tu as PICC Lite, c'est une version de démo avec laquelle tu n'as pas accès aux bank 2 et 3; de plus la taille du code est limitée.
Il faut utiliser PICC 9.60 précisément (pas Lite).

Pour le délire des bank, ça mériterai de jeter un oeil dans le "Disassembly Listing" histoire de s'assurer que le compile prenne bien en charge le basculement en IT.
ça me paraît très bizarre comme problème, car c'ets la première fois que j'entend parler de ça. Mais comme j'ai aussi eu des soucis sur cette carte, je me dit que ce n'est pas impossible d'avoir une accumulation de facteurs qui fasse que...

[Papo06]

Je mets ma main à couper que tu devais déjà avoir les mêmes soucis de reboot aléatoire, car moi dès que le buffer était plein (environ 20 caractères) ça faisait rebotter le pic...

en gros le test est simple:

bank1 tab[80]

dans l'it:

for i 0 à 79 => tab = 0, en sortie d'IT: => ça reboot direct...

c'est bien le lite. mais bon poru l'instant j'ai plus aucun soucis j'ai totalement viré les interruptions et ça fonctionne parfaitement bien comme ça et j'ai pas besoin des banques 2 et 3 y a plein de place encore, c'était juste que je voulais essayer de mettre le buffer ailleur que dans la bank1

Je ne suis pas spécialement manchot d'habitude en programmation et j'ai passé quelques soirées à comprendre le merdier, je te garantie qu'il y a un truc pas clair et pas normal. bon comme j'ai dit je m'en fout car les it posent aussi un autre problème c'est que l'écriture sur l'i2c ça marchait pas non plus même avec les #pragma interrupt_level placé sur les fonctions (mais là j'ai pas cherché à comprendre), du coup passer par des flags dans les it pour après surveiller les flag dans le main je trouvais ça pas terrible. là le code est clair et net et tout petit je vais te le renvoyer tu va voir qu'il est simplissime

A la base tout est arrivé quand j'ai réécrit le buffer de sortie tournant, c'est là que j'ai détecté le problème, tu devais probablement avoir le même effet de bord qui t'a poussé à le réécrire en linéaire

j'ai ajouté un mini attract mode aussi pour utiliser la carte sans pc, une fois démarrée elle fait une petite anim de scan lignes/colonnes et quand on ferme un switch ça allume l'ampoule correspondante. pratique pour tester même sans pc

Pascal

[Papo06]

Bon, comme j'avais pas fait gaffe que le plateau que j'ai récupéré n'est pas matricé (gtb avec les lampes commandées individuellement) j'ai fabriqué en urgence une matrice à led, c'est beaucoup moins lourd à trimbaler

c'est court, mais ça donne une idée:

http://www.youtube.com/v/FPXvtTC0Csg

En fait même seulement 4 niveaux ma fois c'est pas mal.

Pascal

[romain]

Bon, comme j'avais pas fait gaffe que le plateau que j'ai récupéré n'est pas matricé (gtb avec les lampes commandées individuellement) j'ai fabriqué en urgence une matrice à led, c'est beaucoup moins lourd à trimbaler

haha tu t'es fait eu ! mais t'as raison, c'est un chouilla moins encombrant !
c'est bien beau toutes ces belles LED, beau travail!! continue comme ça et dans une semaine l'interface est prête

Je viens de repenser à un truc : les variables de gestions du buffer sont en bank0 alors que le buffer en lui même est en bank1! Si le compilo fait mal sa sauce, ça doit être un sacré merdier pour lui d'executer la fonction d'envoi!
Fais gaffe pour les fonctions utilisées dans la boucle principale car tu ne peux pas les utiliser dans les interruptions! C'est la raison pour laquelle tout avait été défini en #define et non en fonctions standard. De plus, faire de l'I²C en IT c'est assez cochon quand même
Le principe des flags c'est ce qui est utilisé pour garantir un fonctionnement rapide et capable de gérer les coups de bourre, ça joue le rôle de file d'attente tant que les IT sont appelées en boucle (pendant une grosse réception par exemple).

La méthode qu'on nous enseigne c'est d'en faire le moins possible en IT (copier les données reçues dans un buffer, placer des flags) puis de traiter tout ça quand on a le temps, donc en boucle principale. C'est peut-être un chouilla lent (et encore, je pense même pas) mais pour des loupiottes on s'en tape! Je continue de coder sur le même principe (pour mon robot actuellement) et ça marche du tonnerre.

@+ et encore beau boulot !

[Papo06]

Ben pour moi c'est bientôt fini, donc je ramène ça au salon pour montrer un peu aux copains, mais après si vous voulez je vous renvoie tout car je n'aurais plus de temps à y consacrer pour diverses raisons en particulier le fait que je change de boulot fin février.

Je ne vais rien faire de plus pour coder les règles etc ça sert à rien que je fasse quoi que ce soit puisque tout dépendra du flip futur, maintenant faut passer à l'étape whitewood, Damien c'est ton tour

Ah j'ai oublié de préciser que j'ai ajouté un double buffer en entrée pour les lampes, je ne met à jour la matrice qu'une fois que j'ai reçu la totalité des 16 octets de luminosité et en cas de chiure lors du transfert ça ne mets rien à jour, j'ai remis le buffer de sortie en fifo aussi même si c'est pas important vu la quantité ridicule qui transite du pic vers le pc (les switches modifiés...)

Sinon la boucle j'ai mesuré elle tourne 8000 fois/seconde, donc on peut recevoir jusqu'à environ 70000kbps sans perdre d'octet

pour les it le soucis c'est que les timers sont très rapides et quand tu vois les 3 tonnes de code pour sauver/restaurer l'environnement (j'ai regardé environ 13 instructions si je ne me trompe pas, sans compter celle qu'on ne voit pas interne au proc quand il sauve le pointeur de retour pour le rtie) plus du code de flags pour passer l'info au main franchement c'est totalement inefficace comparé à betement tourner en rond dans le main en vérifiant si le bit timeroverflow est mis ou pas en 1 instruction . mais ça, c'est chacun fait comme il veut :)

Pascal