Et un BGA tient les 500 broches, si le PCB est petit cela ne devrait pas être trop couteux.
Je veux surtout un truc pas trop chère
Euh, ouais, mais ce qui coûte, ça risque de ne pas trop être le PCB1 et ses couches, mais d'une part (dans le cas de quelques protos) de faire souder la cochonnerie de BGA, et d'autre part dans tous les cas ce qu'il y a dans le composant et à combien d'exemplaire il est produit. Quand j'évoquais un gros Zynq à prix déraisonnable, c'est un composant qui va taper dans les 3000 à 5000,ドル pareil pour les FPGA les plus puissants ; quand aux processeurs/contrôleurs, s'ils sont vraiment spécialisés dans une petite niche, ils peuvent coûter plusieurs centaines d'€. Donc bon, si on devait être dans ce genre de cas, le prix des connecteurs serait accessoire :-)
si tu as 2 puces, tu as 30 pattes pour communiquer entre les 2.
J'entends bien qu'il faut « ajouter » des pattes mais ce n'est pas très grave dans la mesure où ce n'est pas trop difficile à router tant que c'est juste entre 2 composants. À partir de 3 ça serait plus pénible. Cependant, j'ai mis « ajouter » entre guillemets parce que les interfaces et les pattes sont de toutes manières généralement présentes sur les SoC, donc à moins de vouloir et pouvoir affecter les pattes correspondantes à une autre fonction, ça ne va rien changer (du moins, côté SoC).
C'est pas faux. En même temps, 8 ou 10 bits c'est suffisant, et 1 000hz, c'est que dalle.
Ça me soucie un peu ça. OK, les signaux analogiques à mesurer sont quasi-statiques, donc on devrait pouvoir les filtrer à mort. Sauf qu'il y a cette histoire de réactivité qui m'ennuie à double titre. D'abord parce que du coup on n'a plus le droit de retarder des masses le signal, ni d'affecter sa valeur, ce qui limite la possibilité de filtrage. Ensuite parce que si on veut capter le peu de mouvement possible en 1/1000e de seconde2, il faut pouvoir mesurer des variations très faibles avec une très bonne précision, parce que sinon ça ne sert à rien de capter& réagir toutes les millisecondes ; et donc ça veut dire un signal très propre, sans bruit, et des ADC dont les derniers bits sont fiables.
Et avec tout ça, on se trouver avec un filtre qui risque de ne pas filtrer la fréquence des PWM qui sont juste à côté, alors qu'on ne peut pas tolérer de bruit.
Au contraire il me semble qu'il faut réduire le nombre de fils en multiplexant les infos sur de simples lignes numériques.
Si tu as un robot de 50 cm, tu ne gagnes rien. Et tu as une pelleté de mini carte en plus, et de connecteurs (c'est chère les connecteurs).
Dans la mesure où le composant magique à 500 pattes n'existe pas, pour la carte de base il faut de toutes manières ajouter plusieurs μC ou CAN et même si l'on opte pour la solution FPGA, il faut quand même un étage pour l'adaptation des entrées analogique à la gamme demandée par les CAN et pour le filtrage.
Implanter ces composants sur la carte de base est plus coûteux que de les implanter sur plusieurs petites cartes séparées identiques. La surface prise sur la carte du SoC est du 6/8 couches, alors que la carte séparée est en 2/4 couches et on en fabrique plus d'exemplaires.
Avoir des modules est généralement une bonne idée. Déjà pour le développement, ça permet de tester séparément les fonctions, de ne pas les faire en même temps, etc. Ensuite, ça peut éviter, en cas de problème, de griller l'ensemble. Enfin, avoir de modules permet de s'adapter à différents projets, soit en changeant le nombre de modules connectés, soit en remplaçant les modules par d'autres ayant des fonctions variant en nombre ou en nature. Ça évite de devoir reconcevoir et refaire une carte à 800€...
De plus, tant qu'à avoir des modules, autant les déporter, ça arrangera bien les éventuels problèmes de qualité des signaux analogiques.
Le SPI est un peu pourris, cela bouffe beaucoup de cpu. J'ai vu des CAN spi qui avait des attentes actives,
Tu peux préciser un exemple de composant problématique ?
même si, pour sortir 200 à 400 fils, les connecteurs vont consommer pas mal de place ! ↩
j'ai du mal avec cette histoire de devoir mesurer des déplacements et réagir aussi rapidement dans le même cycle, alors que si on prend une voiture allant à 100 km/h en photo au 1/1000, on la voit arrêtée, sans pouvoir discerner de mouvement. Alors, pour des mouvements encore moins rapides... ↩
[^] # Re: embarqué ?
Posté par gnx . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 1.
Euh, ouais, mais ce qui coûte, ça risque de ne pas trop être le PCB1 et ses couches, mais d'une part (dans le cas de quelques protos) de faire souder la cochonnerie de BGA, et d'autre part dans tous les cas ce qu'il y a dans le composant et à combien d'exemplaire il est produit. Quand j'évoquais un gros Zynq à prix déraisonnable, c'est un composant qui va taper dans les 3000 à 5000,ドル pareil pour les FPGA les plus puissants ; quand aux processeurs/contrôleurs, s'ils sont vraiment spécialisés dans une petite niche, ils peuvent coûter plusieurs centaines d'€. Donc bon, si on devait être dans ce genre de cas, le prix des connecteurs serait accessoire :-)
J'entends bien qu'il faut « ajouter » des pattes mais ce n'est pas très grave dans la mesure où ce n'est pas trop difficile à router tant que c'est juste entre 2 composants. À partir de 3 ça serait plus pénible. Cependant, j'ai mis « ajouter » entre guillemets parce que les interfaces et les pattes sont de toutes manières généralement présentes sur les SoC, donc à moins de vouloir et pouvoir affecter les pattes correspondantes à une autre fonction, ça ne va rien changer (du moins, côté SoC).
Ça me soucie un peu ça. OK, les signaux analogiques à mesurer sont quasi-statiques, donc on devrait pouvoir les filtrer à mort. Sauf qu'il y a cette histoire de réactivité qui m'ennuie à double titre. D'abord parce que du coup on n'a plus le droit de retarder des masses le signal, ni d'affecter sa valeur, ce qui limite la possibilité de filtrage. Ensuite parce que si on veut capter le peu de mouvement possible en 1/1000e de seconde2 , il faut pouvoir mesurer des variations très faibles avec une très bonne précision, parce que sinon ça ne sert à rien de capter& réagir toutes les millisecondes ; et donc ça veut dire un signal très propre, sans bruit, et des ADC dont les derniers bits sont fiables.
Et avec tout ça, on se trouver avec un filtre qui risque de ne pas filtrer la fréquence des PWM qui sont juste à côté, alors qu'on ne peut pas tolérer de bruit.
Dans la mesure où le composant magique à 500 pattes n'existe pas, pour la carte de base il faut de toutes manières ajouter plusieurs μC ou CAN et même si l'on opte pour la solution FPGA, il faut quand même un étage pour l'adaptation des entrées analogique à la gamme demandée par les CAN et pour le filtrage.
Implanter ces composants sur la carte de base est plus coûteux que de les implanter sur plusieurs petites cartes séparées identiques. La surface prise sur la carte du SoC est du 6/8 couches, alors que la carte séparée est en 2/4 couches et on en fabrique plus d'exemplaires.
Avoir des modules est généralement une bonne idée. Déjà pour le développement, ça permet de tester séparément les fonctions, de ne pas les faire en même temps, etc. Ensuite, ça peut éviter, en cas de problème, de griller l'ensemble. Enfin, avoir de modules permet de s'adapter à différents projets, soit en changeant le nombre de modules connectés, soit en remplaçant les modules par d'autres ayant des fonctions variant en nombre ou en nature. Ça évite de devoir reconcevoir et refaire une carte à 800€...
De plus, tant qu'à avoir des modules, autant les déporter, ça arrangera bien les éventuels problèmes de qualité des signaux analogiques.
Tu peux préciser un exemple de composant problématique ?
même si, pour sortir 200 à 400 fils, les connecteurs vont consommer pas mal de place ! ↩
j'ai du mal avec cette histoire de devoir mesurer des déplacements et réagir aussi rapidement dans le même cycle, alors que si on prend une voiture allant à 100 km/h en photo au 1/1000, on la voit arrêtée, sans pouvoir discerner de mouvement. Alors, pour des mouvements encore moins rapides... ↩