• [^] # Re: embarqué ?

    Posté par . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 2.

    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.

    L'avantage d'aller plus vite que la mécanique est aussi de pouvoir faire du filtrage numérique. C'est bien plus simple à modifier.

    Là aussi, c'est encore une solution de facilité (on acquiert les entrées aussi vite qu'on peut même si elles sont dégueulasses comme des bourrins et ensuite on verra bien comment on les filtre à l'intérieur) et on bouffe des ressources et ça explique qu'on ait besoin d'un gros CPU, de RAM, et de rentrer plus de données.

    Et du coup, le temps de réactivité annoncé est à moitié bidon, puisque on ne réagit qu'après avoir pris en compte les 10/20/30 derniers échantillons (et donc 10/20/30 cycles) et viré/lissé/filtré les mauvais. Il est flottant, en fait.

    Avoir des modules est généralement une bonne idée.

    Oh non. C'est une très très mauvaise idée. Je suis d'accord pour la facilité de développement. Mais au niveau de la fiabilité, cela n'est plus la même chose. Moins il y a de connections mieux on se porte.
    J'ai vu des archis de robot avec plein de μP chacun sur sa carte, c'est bien plus simple d'avoir une seul carte et tout dessus. Il y a bien moins de fils et bien moins de problèmes.

    « Bien moins de fils » avec un fil pour chaque entrée venant de chaque capteur et un fil allant à chaque commande par rapport à une liaison série à 1/2/3 fils qui transporte l'ensemble des infos de 15 capteurs et 15 sorties ???
    Bon, de toutes manières tu n'en démordras pas. Alors je te souhaite bien du plaisir à concevoir ta carte mère (utilise au moins un module CPU venant s'enficher dans la carte mère pour ton [(SoC/SoC+FPGA/Zynq)+RAM]) avec ses 200 ou 400 connections. Et le jour où tu auras besoin d'un de plus que ce que tu as prévu, ben tu refais toute une carte mère.

    J'en ai pris un au hasard http://www.ti.com/lit/ds/symlink/tlc1518.pdf . J'ai vu qu'il y a un mode "repeat" qui peut être intéressant pour 8 voies, mais j'ai l'impression que l'envoie est contrôlé par 3 bits externe (INT, CSTART, FS). C'est autant de bit pris sur le SoC. Et j'ai peur que pour gérer l'entrée, il faut commander ses bits, ce qui prend tout le cpu, pendant ce temps là.

    OK. Remarque : c'est un composant qui a plus de 15 ans. Il ne fait pas d'échantillonnage simultané (simultaneous sampling) et il ne sait pas enchaîner les différents canaux tout seul, donc il faut lui envoyer 1 coup de CS ou CSTART ou FS par canal en respectant des temps minimums (600ns/1,4μs). Ces temps d'attente sont perdus si tu ne sais pas faire autre chose en attendant. Par contre, le même signal peut servir à tous les TLC1518 présents sur la carte. Et la lecture, elle, ne pose pas ces problèmes d'attente (mais il faut des CS différents pour chaque TLC1518).

    Sinon, si je prend aussi au hasard un composant plus récent comme le MAX11060 : 4 voies seulement, mais il fait le simultaneous sampling, il gère un peu tout tout seul et tu peux même en mettre plusieurs en cascade sans avoir besoin d'interface supplémentaire.

    Note quand même qu'il va falloir une bonne quantité de ces CAN car il n'ont que 4 ou 8 entrées, alors qu'un μC peut gérer 16 voire 32 entrées et ce, en plus, pour un coût unitaire moindre. Faut les programmer, c'est sûr, mais si on ne leur fait faire que ça (lire leurs entrées analogiques, éventuellement signaler au SoC qu'elles sont prêtes, et envoyer les données quand le SoC leur demande), ce n'est pas bien compliqué.