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.
Tu es bon en hard, mais tu n'es pas la moindre notion de conception de système embarqué ? C'est ça ? Le fait de lisser sur 1 ou 10 cycles,est un choix de conception, qui peut arriver bien après la conception du hard.
Dans ce genre de système, tu as des taches à vitesse fixe. 1 khz a été choisi par beaucoup d'équipe e=m6, car c'est en gros la vitesse qu'il faut pour qu'un PID soit assez réactif, et tout mettre en commun permet de faire bien plus (asservissement 2D ou plus, détection de glissement, de choc,...).
Si tu veux faire complexe, tu peux toujours avoir une tache à 1kz qui dialogue avec une autre à 10Hz, si tu as besoin de plein de temps cpu.
« 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 ???
sauf que tu oublis les fils liant ta carte fille et les capteurs. Donc tu as tout les fils d'avant, plus les fils numériques, sauf si tu mixes la carte puissance et la carte capteur.
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.
C'est pareil, si tu manques de lien spi.
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é.
Il faut voir si la latence du cycle complet est assez rapide. En général, ce genre d'architecture est lente, (tu n'utilises pas de SPI à 40Mhz à travers des fils de base, si ?)
Cela existe des composants spi avec ADC + PWM en sortie ?
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3. Dernière modification le 10 juillet 2014 à 09:37.
Tu es bon en hard, mais tu n'es pas la moindre notion de conception de système embarqué ? C'est ça ? Le fait de lisser sur 1 ou 10 cycles,est un choix de conception, qui peut arriver bien après la conception du hard.
Dans ce genre de système, tu as des taches à vitesse fixe. 1 khz a été choisi par beaucoup d'équipe e=m6, car c'est en gros la vitesse qu'il faut pour qu'un PID soit assez réactif, et tout mettre en commun permet de faire bien plus (asservissement 2D ou plus, détection de glissement, de choc,...).
Si tu veux faire complexe, tu peux toujours avoir une tache à 1kz qui dialogue avec une autre à 10Hz, si tu as besoin de plein de temps cpu.
sauf que tu oublis les fils liant ta carte fille et les capteurs. Donc tu as tout les fils d'avant, plus les fils numériques, sauf si tu mixes la carte puissance et la carte capteur.
C'est pareil, si tu manques de lien spi.
Il faut voir si la latence du cycle complet est assez rapide. En général, ce genre d'architecture est lente, (tu n'utilises pas de SPI à 40Mhz à travers des fils de base, si ?)
Cela existe des composants spi avec ADC + PWM en sortie ?
"La première sécurité est la liberté"