Reprise du message précédent :
Clair
Quand on est habitué aux langages "haut niveau" on se sent légèrement dépaysé avec ces contrôleurs  .
Vais chercher, mais il doit surement y avoir des librairies toute faites pour me simplifier la tâche.

Ben techniquement, si t'as déjà ta SPI qui fonctionne (ce qui semble être le cas vu que tu la vois saturer), t'as juste à configurer tes vecteurs d'interruptions avec l'adresse de tes fonctions de traitement et virer ta boucle d'attente (les vecteurs sont donnés dans la datasheet, ce sont de simples adresses à utiliser comme pointeurs dans lesquels tu vas mettre l'adresse de ta fonction de traitement).
Il faut aussi activer tes interruptions d’événements sur la ligne SPI (des bits à passer à 1), mais la majeure partie du boulot est faite vu que tu sembles avoir écrit un driver. Comme ça, à chaque événement de fin de transmission, ta fonction de renvoi d'une nouvelle commande sera automatiquement appelée. Si tu veux plus d'infos, files le modèle du pic que tu vises.

J'ai encore rien codé .
 
J'en suis à la réalisation sous Eagle du PCB, or j'ai peur de saturer le bus avec autant de driver led.
 
Du coup je vais peut-etre directement incorper des pic au PCB, pour délester l'unique bus I2C prévu dans un premier temps (adapateur usb-i2c)

Bon je suis lourd avec toutes mes questions    
 
Mais dans le tableau comparatif des PIC, ils font la différence entre:
 
- I2C
- SPI
 
et
 
MSSP (I2C/SPI)
 
 
C'est quoi la différence?????

Tu peux configurer le MSSP pour fonctionner soit en I2C soit en SPI (et pas les deux en même temps bien sûr) tandis qu'un port I2C fait seulement I2C.

Gaffe à la liaison SPI aussi, il faut que tu prévoies un chip select par crabe que tu voudra contrôler sur tes lignes, l'I2C est un peu plus lourd mais pour un grand nombre de composants, t'as pas besoin de plus de fils!

Par contre le SPI ca peut aller bien plus vite que de l'I²C.

Ah ben des qu'on envoie pas des tonnes de foutoir verbeux ça gagne, c'est sûr  
 
edit : et le spi, mine de rien, c'est robuste! J'ai fait une mission ou les mecs arrivaient à tourner en SPI à 1Mega sur 100m de câble en environnement perturbé. Bon, c'était bourré de selfs de filtrage et y avait de l'overshoot partout, mais ça discutait

Je comprends pas trop pourquoi la SPI serait plus rapide. La limite c'est avant tout le temps de montée sur la liaison hard, ensuite c'est la fréquence du microcontroleur (pas possible d'avoir une sclk plus rapide que le microC). Pour le reste les protocoles sont différents mais sur le principe ça reste de la liaison série, le SPI est juste plus rapide pour l'adressage.

 
Pour anecdote j'ai bossé dans une boite où on s'imposait de tenir 2 fois les niveaux d'immunité des normes CEM. Un bête composant d'extension E/S I2C nous plantait la ligne au test des burst, il fallait mettre hors-tension le composant pour débloquer la carte. Solution: remplacer le composant I2C par un microcontroleur et surveiller les interruptions I2C avec un watchdog très serré au niveau timing, au final ça marchait plutôt bien et c'était même moins cher.

 
Ben en données transmises efficaces, c'est plus rapide vu que le protocole d'adressage est réduit au minimum? Après, ouais, en débit pur et dur, doit pas y avoir de différence.
 

 
La solution de bucheron    
 

 
Ouais  
Mais je vois pas comment c'était possible de faire autrement, quand un esclave I2C reçoit de la merde et force la ligne à l'état bas bah faut bien avoir un moyen pour le débloquer. Je serais bien curieux de voir ce que donne le test d'une vieille télé Philipps bourrée d'I2C, nous en tout cas le produit marchait parfaitement

 
Osef de l'adressage, ca monte surtout bien plus haut en fréquence.
L'I²C c'est 5 MHz (d'après la dernière norme), le SPI c'est juste 100 MHz et on peut avoir mieux en spécifique.
Et on parle de PIC mais c'est aussi sur des puces plus rapide. De l'ARM au chipset Z79. Donc c'est plus trop le SysClk qui bloque.    
 

 
Et un reset sur la puce ? En théorie ca devrait tout mettre d'aplomb.

 
Sur cette puce pas chère y'avait pas ça  

 
lulz !

 
Ah ouais, ça turbine en fait la SPI! J'avais pas ça sur les 68 000 à l'école

Sans parler du fait qu'une SPI c'est full-duplex

Ah ca parle débit.
J'hésitais pour pas flooder le topic de questions
 
Bon voilà mon projet (pour une façade de boitier serveur WHS home-made ou en autonome via Wifi):
http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
En gros ~32 Driver LED surtout.
 
Sachant que si je pilote toutes les LED en luminosité, j'en ai pour ~150bit par driver LED. Si je les pilote en on/off j'en ai pour ~50bit par driver. Donc en gros, dans le pire des cas ~5kbit pour tout le panneau. En supposant que le rafraîchissement est de 5-10hz, ca me ferait du 30-60kbit de data.
Pensez-vous que ca passe sans problème sur un bus I2C limité à 400kHz(kbit/s)?
 
J'hésite depuis quelque temps à passer au SPI mais le nombre de pin nécessaire pour le chip select m'effraye un peu.

Chouette facade, ça fait envie    
 
Du coup, ça simplifie grandement le problème. Pour piloter tes LEDs, tu peux utiliser des I/O expanders (dans le genre //fr.farnell.com/microchip/mcp23s08-e-ss/8bit-i-o-expander-spi-smd-23s08/dp/1292236) avec des transistors derrière pour piloter et polariser tes leds en fonction des couleurs. Du coup, on passe à 8 LEDs par crabe et grosso modo 1 bits par LED (puisque pour piloter ton crabe, tu vas envoyer un mot de 8 bits dont chaque bit sera la valeur on/off d'une led)!
 
Je compte à une vache près, 80 LEDs sur ta façade, ça fait donc que 10 crabes à adresser. Tu prends une fréquence de rafraichissement visuelle de 30Hz, 10 niveaux d'intensité (10 actualisation de led par période de persistance rétinienne) soit 300 rafraichissements/seconde. T'as 80 LEDs à adresser soit 300*80bits/secondes=24 000bits/sec, soit environ 24kHz d'horloge minimum, tu serais (très très) loin de saturer ta ligne. L'autre avantage, c'est qu'avec une liaison si peu pleine, tu dois pouvoir utiliser un arduino (sans doute beaucoup plus simple pour interfacer ta carte avec ton pc) avec toutes les librairies qui vont bien, reste juste à voir si tu peux avoir autant de chip select que tu veux avec un arduino!

Nan
 
C'est ~150 LED, mais c'est des mulitled RGB , soit 450 sous-LED à piloter . Comme ca je peux donner la couleur que je veux à tous les segments . Ca ne va pas être possible de mettre 450 transistors, déjà que j'ai beaucoup de mal à placer toutes ces puces (sans compter que ca ne va pas être possible de changer de luminosité et donc d'utiliser autre chose que les couleur primaires).
 
Actuellement dans mon design j'ai des driver LED TLC59116 (I2C). Pour piloter les LED en on/off les 16 sorties faut ~40-50bit de data.
Si je les pilote en luminosité j'en ai pour 150bit.
Pour l'SPI j'aime pas trop à cause des lignes chip select, déjà que je manque de place, si en plus il faut rajouter des lignes select .
 
 
 
Du coup j'ai pensé aux PIC.  
Alors la solution que j'ai actuellement, c'est d'inclure des PIC sur les 3 PCB, chacun ayant 2 I2C. Ces PIC seraient interconnecté entre eux en SPI et un d'entre eux en USB branché au PC pour la liaison avec le logiciel.
 
J'avais prévu cette intégration, mais comme je suis un noob en PIC, dans un deuxième temps seulement, mais là j'ai plus le choix.
Néanmoins dans un premier temps je vais essayer de piloter les LED en I2C via le PC, donc sans passer par les PIC.
 
Question
Donc les PIC seront branchés aux 2 I2C du PCB.
Via des pin j'arriverai à me brancher sur ces I2C avec un adaptateur USB pour piloter les driver LED avec le logiciel PC dans un premier temps.
Le PIC étant inutile à cette étape, je voulais le mettre en état de reset (MCLR). Mais du coup je me pose une question.
Est-ce que ca va perturber la communication I2C (ben oui le bus I2C est branché sur les pin du PIC qui lui est en état de reset)???
 
(Au début je voulais couper l'alimentation du PIC, mais j'ai lu que dans ce cas là il ne faut absolument rien branchwe sur les pin I/O du pic au risque de l'abîmer).

 
Ah ouais, au temps pour moi, j'avais pas vu ça comme ça, ça fait du lourd comme carte du coup! Sympa du coup le fait de pouvoir changer totalement les couleurs de ton tableau de bord!
 
Du coup, pour l'occupation de la ligne en pwm, j'ai 150bits/driver * 10 fois/seconde * 16 drivers par ligne I2C (adressage sur 4 bits) = 24000 bits/sec (modulo les bits de controle) en utilisant deux lignes I2C pour adresser les 32 drivers, on serait loin de la saturation.
 
Pour le reset, à priori, je pense que les lignes I2C doivent se mettre en haute impédance. Cependant, rien de sûr, il doit y avoir un chapitre Reset dans la datasheet du pic que tu veux utiliser qui doit préciser ce genre de chose. Si vraiment tu veux être sûr pour tes premières expérimentations, tu peux tout simplement mettre des ponts de soudure ouverts sur tes lignes I2C que tu ne soudera que quand tu choisira d'utiliser les PICs (et tu désoudera ceux du pc). C'est la solution propre et sûre (et pas dure )

 
Questions :  
 
Pourquoi utiliser des RGB ? J'ai pas tout lu ton topoc mais les barregraphe c'est des couleurs fixes en général. Je vois pas l'intérêt du multicolore.
 
Si tu passes en SPI, pourquoi vouloir avoir un CS sélectif ? Tu mets toutes les puces sur la même ligne CS vu que de toutes façons tu rafraichis tout en même temps. Avec des registres à décalage et des transistors CMS ca se fait facilement.
 
Mais si tu veux rester sur de l'I²C, je vois pas le problème. Tu peux segmenter avec plusieurs bus I²C (les pic à 3 contrôleurs sont une bonne idée sinon un bon vieux multiplexeur rapide) et fonctionner par grappe.

 
Ben sans chip select, tu vas affecter la même valeur à tous les drivers SPI non? L'intérêt de la SPI, c'est justement que l'adressage se fait par chip select et non par protocole non?

Pour plusieurs raisons:
- Plusieurs segments seront multifonction, genre le logo LAN sera blanc si tout ok, jaune si le lan est à 10/100Mbit et non 1Gigabit ou s'il n'y a pas de connexion internet, rouge si LAN HS.
- Je suis obligé d'utiliser des puces au format QFN ou TSSOP vu le nombre de LED, donc obligé de faire fabriquer le PCB, impossible de faire tout ca soi-même. Mais du coup il y a de la place pour toutes ces sorties LED RGB.
- J'arrive pas à me mettre d'accord sur les couleurs   . Du coup pour ne pas regretter mon choix, je préfère l'RGB comme ca j'ai toutes les couleurs dispo.
 
 
D'ailleurs j'en profite pour demander votre avis. Vous préférez quoi?
 
1. (sur la première photo) Le segment HDD (à gauche au milieu) ou le segments Ram (à droite au milieu)  ?
2. Avec du texte sous les segments (Transfert, Capacity, Ram, Swap, Core 1, Core 2, Up, Down) ou sans (je parle juste du texte pas le reste)?
3. Avec ou sans les traits blancs entre les segments et le logo associé?
 



 
 

C'est ce que je pensais aussi  

Bonne idée en effet    
 
EDIT:
Ou sinon des jumper, sans jumper j'y connecte le câble I2C vers mon adaptateur I2C-USB. Avec jumper je le relie au pic.
 
Le bus  ca ne craint pas les jumper n'est-ce pas?

 
Non pas du tout !
Autre solution: désactiver le bus I2C et configurer en entrée les pins correspondantes, pas de risque non plus.

 
Ça tiendrait qu'à moi, ce serait une LED rouge/verte par paramètre, mais j'aime bien le minimalisme, du coup, je pense pas que ce soit utile que je donne mon avis  
 
Sinon, je viens de voir (si tu veux pas t'emmerder avec un pic, le compilateur spécifique et la sonde de programmation) que le duemilanove propose une double liaison à 100kHz avec une librairie (non non, j'ai pas d'actions chez arduino )!

Trop gros
 
Non les PIC ca ne me dérange pas, j'avais envie de m'y mettre un jour ou l'autre.
C'est juste que je veux pas que ca m'empêche de faire fonctionner le bazar sans, le temps d'apprendre à programmer le PIC (parce que piloter tout ca avec C# ca sera assez simple).

Pas faux.  

Soa t'as envisagé du multiplexage pour tes LEDs ? Apparemment ton driver ne le fait pas, c'est dommage car il y aurait plein de connexions à économiser. Tu peux éventuellement trouver des exemples en cherchant des schémas qui gérent de multiples afficheurs 7 segments.

Sinon, par curiosité, pour ton plastron, tu dis utiliser du papier plastique, tu chopes ça où? Pour les fuites de lumière, tu as trouvé une solution, mais tu la donnes pas, tu la révélerais?

Tout dépend de ton bus :
En étoile, tu as besoin du CS sélectif pour adresser une seule puce.
En chainé, tu peux avoir un seul CS. Dans cette archi, il est par contre parfois nécessaire d'avoir un Strobe par puce si tu veux modifier une seule puce. Mais là autant faire du rafraichissement globale donc un seul CS et Str.

Ou prendre un CPU ARM. Il est déjà en QFN donc un petit STM32F1 via CooCox IDE et un clone STLink c'est pas cher et bien plus perf.
Perso j'ai jamais accroché avec les PIC. Je préfère les ATmega et HC08.

Ah j'avais pas pensé à cette éventualité.    
 
Ca doit être une horreur à implémenter au niveau logiciel :-S

J'y avais pensé aussi, en lisant une news de NXp qui venait de sortie un Coretex M0 ARM, mais on m'a dit que les outil de développement était plus compliqué et qu'il y avait moins d'info sur le net pour le débutant que pour les ARM M0

 
Tu veux dire quoi par multiplexage?

 
Bof non. Je dis ca parce que je l'ai mis en place dans un projet. 32 registres à décalage pour gérer des relais dans un appareil de mesure. L'avantage c'est que tu peux faire des mezzanines et en ajouter après coup. Une petite MAJ du logiciel et ca roule. Moins contraignant qu'un nouveau PCB.
 
Cela dit, j'ai approfondi ma lecture de ton topoc. Les drivers de LED c'est une bonne idée.
Donc je suggère de faire de la segmentation. Le pic avec les 3 contrôleurs semble une bonne piste.

 
Enfin là ça revient à tuer une mouche au bazooka. Je crois pas que Soa soit prêt à se taper du QFN sachant qu'il s'inquiétait d'avoir du TSSOP à souder... Puis niveau documentation technique à se taper c'est à vue de nez 4 fois plus de pages par rapport à un petit microcontroleur. PIC, ATmega et HC08 c'est un peu du pareil au même, mais AMHA pour un semi-noob les docs sont mieux foutus chez microchip.

 
Un truc dans ce style:

 
Tous les segments ne peuvent s'allumer en même temps mais la persistance rétinienne n'y voit que du feu  

 

Comparé à MPLAB, aucun IDE n'est compliqué.
L'avantage de certains c'est qu'ils sont complet dès l'installation (pas de lib à compiler, pas de toolchain à ajouter à la mains...). C'est le cas de CooCox comparé à une solution Eclipse + Zylin + CodeSourcery ou même MPLAB (la dernière fois que je m'en suis servit avec un compilo C c'était une horreur à intégrer).
Pour ce qui est de la doc, c'est identique.

 
C'est l'équivalent d'un CS en fait. Et inapplicable avec des contrôleurs de LED.

Ben c'est du banal filme plastique imprimable pour rétroprojector

Dispo en supermarché au rayon papier d'imprimante
Alors moi j'ai du l'imprimer plusieurs fois de suite pour que ce soit bien noir et opaque. Mais pas trop, sinon ca bave et ca sali les buses de l'imprimante.
 
Derrière le filme, il y a un plexi 5mm, surface brossée pour mieux étaler la lumière. Mais comme ca ne suffisait pas j'ai rajouter une feuille blanche par dessus. Du coup quand la LED est off, ben le segment semble blanc. Pas top.

Alors on le voit pas sur la photo, mais j'ai découpé des petit segments plexi, peint en noir les bordure pour éviter les fuite de lumière d'un segment à l'autre. Mais c'est pas top et ca prend un temps fou.
 
 
Pour le problème de fuite de lumière ce que je vais faire, c'est une plaque soit d'alu, soit en bois avec des trous pour délimiter les segments (un peu comme je l'ai fait pour le plexi plus haut, mais avec un matériau opaque à la base déjà ). Inutile de faire des trous avec la même forme du segment, ca, le filme plastique en façade s'en chargera.
Cette plaque sera prise en sandwich entre les LED et le filme plastique imprimé.
 
Après peut-être qu'il faudra que je rajoute un autre matériau pour mieux diffuser la lumière que le papier, avec le plexi ca sera trop compliqué vu le nombre de segment.