Quand tu en a codé 1 (ou recopié le code dispo ailleurs), que tu en instancies 2 ou 100, c'est le même travail.
Il y a tout le décodage à faire proprement et être sur que cela rentre. 100 compteurs 16 bits, cela n'est pas petit.
As-tu besoin d'une précision de 1/65536=0,0015% de période sur tes sorties ? et ce sur toutes tes sorties ?
De toutes façons, même si l'on compte pour être tranquille le double de ce qui doit être nécessaire, disons 32 bascules par compteur, ça rentre dans le plus petit des Spartan 6 qui en compte 4800, ou dans un Spartan 3A 200 qui en compte un peu moins.
De plus, utiliser n compteurs 16 bits pour n sorties, c'est la méthode bourrine calquée sur le fonctionnement des timers de μC. Pour obtenir la même précision, on peut par exemple utiliser 1 compteur principal (genre 8 ou 10 bits) et n compteurs plus petits (les bits qui manquent : 8 ou 6) ou n registres à décalages s'il manque peu de bits, en consommant de la RAM à côté (il y a plus de 200kb de RAM en blocs sur le plus petit des Spartan 6).
Il y a beaucoup de raisons à cela : lenteur des communications entre les 2. Mon but est de lire tous les capteurs puis tout écrire pendant un cycle. Un cycle dure entre 1 à 10 ms maximum (retroaction). Et pendant ce temps là le cpu doit être libre, ou presque pour faire des calculs (il existe des ADC sous I2C qui demande beaucoup de temps cpu pour du pulling).
Ensuite, si tu as un lien rapide entre les 2, cela sacrifie beaucoup d'IO, donc cela veut dire des gros package couteux. Lier un μP et μcontroller demande aussi de coder le μcontroller sans quasiement d'aide au debug, c'est bien plus long et complexe que sous un Linux, par exemple.
Cycle de 10ms dont 1ms consacrée aux E/S, donc ?
Si on prend une liaison SPI à 40 MHz et qu'on suppose arbitrairement qu'une lecture/écriture de message comporte 8 octets et qu'on doit attendre l'équivalent de 4 octets entre 2 messages ; ça nous fait un message toutes les (12x8=64)/40.106=2,4μs. On peut utiliser plusieurs bus SPI (un avec le SoC maître et l'autre avec le μC maître, par exemple).
Si on prend un bus // arthritique entre SoC et μC : 8 bits de données, quelques bits d'adresse, 10 MHz ; disons qu'un mot 32 bits est transféré en moyenne en 6 coups d'horloge; ça nous fait un message tous les 6/10.106=0,6μs.
Dans les 2 cas ça doit être suffisant pour lire 100 entrées et mettre à jour 100 sorties en utilisant un maximum de 0,5ms.
Si c'est un cycle de 1ms dont 100μs consacrée aux E/S, c'est plus tendu, mais s'il y a moins d'E/S que 100 et 100, ça peut rentrer.
Après si le boulot difficile est fait par le producteur de la carte pourquoi pas. Mais il faudra montrer que le driver Linux qui permet d’accéder au ADC ou au PWM d'un μcontrolleur à bien 1 ms de latence max, ou plus exactement que toutes les IO peuvent être lu/écrite en moins de 10 ms, sans prendre plus de 10% de cpu.
S'il faut tout tout fait, ça réduit encore les possibilités de solution :-)
Tu as listé combien d'entrées et de sorties il te faut, avec leur type, leur précision et leur vitesse/latence ? Ça sera plus pratique pour essayer de déterminer une solution que beaucoup/plein de/le plus possible :-) Pour la vitesse, on a ce total de 1 ms max, mais ça ne concerne peut-être pas toutes les E/S, il y en a probablement qui ne demanderaient pas à être actualisées à chaque cycle.
Les cortexM tourne à 70-100Mhz, j'ai commencé la robotique sous linux avec des Pentium 75. Il faudrait juste utiliser une plateforme de μC et y mettre un Cortex A7 ou lieu d'un M.
Ben j'ai l'impression (juste avec ce que tu as dit) que tu t'embarrasses d'un OS de type mammouth alors que ce que tu fais tourner dessus a le fonctionnement d'un automate et se contenterait d'un mini-micro-nano OS ou de pas d'OS du tout. Alors du coup t'as besoin d'une fréquence 10 fois supérieure.
Je ne sais pas s'il y a d'autres raisons pour ce choix que le fait du confort et de l'habitude de développer sur une plateforme riche et familière. Ces raisons sont parfaitement compréhensibles mais dans le cas présent, il est possible qu'elles conduisent à une impasse (en l'état des composants et des cartes toutes faites sur le marché).
les Vybrid VF6xx de Freescale que l'on trouve par exemple sur la carte Cosmic + de Phytec
Il y a 2 ADC sur 4 lignes, c'est très peu. Je n'ai pas vu de PWM. Mais l'idée est là.
Ah oui, merde, là c'est moi qui n'avait pas vérifié, m'étant dit que puisqu'il avaient mis un cœur de μC, ils avaient assurément mis aussi des interfaces de type μC. Bah non :-/
À voir chez d'autres fabricants.
[^] # Re: embarqué ?
Posté par gnx . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 1.
As-tu besoin d'une précision de 1/65536=0,0015% de période sur tes sorties ? et ce sur toutes tes sorties ?
De toutes façons, même si l'on compte pour être tranquille le double de ce qui doit être nécessaire, disons 32 bascules par compteur, ça rentre dans le plus petit des Spartan 6 qui en compte 4800, ou dans un Spartan 3A 200 qui en compte un peu moins.
De plus, utiliser n compteurs 16 bits pour n sorties, c'est la méthode bourrine calquée sur le fonctionnement des timers de μC. Pour obtenir la même précision, on peut par exemple utiliser 1 compteur principal (genre 8 ou 10 bits) et n compteurs plus petits (les bits qui manquent : 8 ou 6) ou n registres à décalages s'il manque peu de bits, en consommant de la RAM à côté (il y a plus de 200kb de RAM en blocs sur le plus petit des Spartan 6).
Cycle de 10ms dont 1ms consacrée aux E/S, donc ?
Si on prend une liaison SPI à 40 MHz et qu'on suppose arbitrairement qu'une lecture/écriture de message comporte 8 octets et qu'on doit attendre l'équivalent de 4 octets entre 2 messages ; ça nous fait un message toutes les (12x8=64)/40.106=2,4μs. On peut utiliser plusieurs bus SPI (un avec le SoC maître et l'autre avec le μC maître, par exemple).
Si on prend un bus // arthritique entre SoC et μC : 8 bits de données, quelques bits d'adresse, 10 MHz ; disons qu'un mot 32 bits est transféré en moyenne en 6 coups d'horloge; ça nous fait un message tous les 6/10.106=0,6μs.
Dans les 2 cas ça doit être suffisant pour lire 100 entrées et mettre à jour 100 sorties en utilisant un maximum de 0,5ms.
Si c'est un cycle de 1ms dont 100μs consacrée aux E/S, c'est plus tendu, mais s'il y a moins d'E/S que 100 et 100, ça peut rentrer.
S'il faut tout tout fait, ça réduit encore les possibilités de solution :-)
Tu as listé combien d'entrées et de sorties il te faut, avec leur type, leur précision et leur vitesse/latence ? Ça sera plus pratique pour essayer de déterminer une solution que beaucoup/plein de/le plus possible :-) Pour la vitesse, on a ce total de 1 ms max, mais ça ne concerne peut-être pas toutes les E/S, il y en a probablement qui ne demanderaient pas à être actualisées à chaque cycle.
Ben j'ai l'impression (juste avec ce que tu as dit) que tu t'embarrasses d'un OS de type mammouth alors que ce que tu fais tourner dessus a le fonctionnement d'un automate et se contenterait d'un mini-micro-nano OS ou de pas d'OS du tout. Alors du coup t'as besoin d'une fréquence 10 fois supérieure.
Je ne sais pas s'il y a d'autres raisons pour ce choix que le fait du confort et de l'habitude de développer sur une plateforme riche et familière. Ces raisons sont parfaitement compréhensibles mais dans le cas présent, il est possible qu'elles conduisent à une impasse (en l'état des composants et des cartes toutes faites sur le marché).
Ah oui, merde, là c'est moi qui n'avait pas vérifié, m'étant dit que puisqu'il avaient mis un cœur de μC, ils avaient assurément mis aussi des interfaces de type μC. Bah non :-/
À voir chez d'autres fabricants.