J'ai l'impression qu'il est complexe de se mettre d'accord sur la forme des meta-donnés pour une série de document qui implique beaucoup d'intervenant.
Est-ce qu'il n'existe pas de format de donné qui embarque leur propre description ? En gros, d'avoir un XML avec sa DTD ou équivalent dedans ?
L'open data semble avoir ce problème récurent de format. Si les meta données sont définis, faire des équivalences entre format ne devrait pas être difficile non ?
Je n'ai pas bien compris l'usage de Box, est-ce qu'il s'agit du même système d'expand de Lisaac, qui permet d'éviter les cochonneries de type natif de Java (int != Integer) ?
Dans Lisaac, c'était hyper puissant, de faire la différence entre un layout mémoire "en dure" et un arbre de pointeur tel que se présente une arborescence d'objet. Typiquement, cela permettait à l'OS Isaac de coder les pixels de l'interface graphique comme des objets, sans perte de vitesse par rapport au C.
Non, même si tu n'as plus de bus SPI séparé, tu peux rajouter d'autres sur le même bus, il faut juste pouvoir générer un CS par esclave (inconvénient du SPI par rapport à des « vrais » bus série).
Pourquoi ils ne font pas de vrai bus d'extension série, avec possibilité de chainage ? Si la partie d'adresse prend trop de place, il faut un encodage type UTF-8. Ensuite, il faut trouver un moyen de démarrer pour faire de l'allocation de zone mémoire, mais cela se fait depuis le PCI.
Mais avec un système numérique, chaque port est identique, interchangeable et complet : au lieu de devoir par exemple choisir x emplacements de borniers et x fils séparés pour aller vers tel membre ou tel moteur, et y vers un autre, tu peux utiliser un connecteur et un câble uniques pour chaque module.
Tu oublis les fils qui partent de chaque module pour aller vers les capteurs ou les moteurs.
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 ?
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.
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.
De plus, tant qu'à avoir des modules, autant les déporter, ça arrangera bien les éventuels problèmes de qualité des signaux analogiques.
C'est vrai que cela a du sens pour chaque moteur ou groupe de moteur, couplé à la partie puissance, mais il faut des cartes numériques stupides, pas d'asservissement par exemple.
Tu peux préciser un exemple de composant problématique ?
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à.
D'ailleurs, je n'ai jamais compris que personne n'est fait encore de bus d'extention série de µP avec adressage. Électriquement, cela peut être du SPI (2 ou 3 fils), mais ensuite, qu'il n'y ai rien besoin d'autre. Cela serait une sorte de mini PCI-express. L'I2C fait un peu ça, mais c'est lent, et l'espace d'adressage est petit, rarement inclus dans l'espace d'adressage du µP, et il faudrait du DMA.
Tu es conscient que tu cherches la quadrature du cercle ?
Oui et non, c'est surtout que les fabricants de puce n'ont pas vu d’intérêt pour la robotique.
Je suis conscient que les procédés de SoC ne sont pas adapté au ADC, et que les procédés de µP ai du mal avec le wifi. Mais bon, 160 Mhz, cela irait. Et un BGA tient les 500 broches, si le PCB est petit cela ne devrait pas être trop couteux.
tu voudrais un boîtier sans trop de pattes ?
Je veux surtout un truc pas trop chère et si tu as 2 puces, tu as 30 pattes pour communiquer entre les 2.
En plus tu ne veux pas optimiser en hiérarchisant les entrées/sorties ni en les multiplexant, du coup toutes au max de précision et il faut toutes les caser dans un bref laps de temps. => bouffage de ressources et restriction du choix.
Tu es un vrai hardeux qui croit que le soft est magique :) Si tu gère l'équilibre d'un robot humanoïde tout bouge en même temps et tous les moteurs sont ajustés.
Sans même parler de la tronche des signaux analogiques dans ce merdier.
C'est pas faux. En même temps, 8 ou 10 bits c'est suffisant, et 1 000hz, c'est que dalle. Un adc de base à 10 bits doit pouvoir tourner à plusieurs MHz, à multiplexer sur plein de lignes. Ensuite, souvent le signal est sur la tension, un pull-up pour avoir un peu d'intensité, permet de masquer le bruit.
Au contraire il me semble qu'il faut réduire le nombre de fils an 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).
Le SPI est un peu pourris, cela bouffe beaucoup de cpu. J'ai vu des CAN spi qui avait des attentes actives, c'était rédhibitoire, surtout pour une dizaine. Tu as donc besoin de truc spi qui fonctionne avec DMA, c'est pas évident. Il faudrait un CAN à ~4 entrées qui envoient en flux ses données, pour y gagner, et les pwm dans l'autre sens.
Non, c'est dans l'ordre de grandeur de ce qui existe déjà. Le problème est d'être sûr de pouvoir faire 17 mesure toutes les ms. C'est parfois très lent de changer de ligne, par exemple.
Par exemple, pour un seul moteur, il faut mesurer le courant, il faudrait mesurer la tension en entré, mesurer la position du moteur (pour un servomoteur) ou sa vitesse de rotation (pour un truc qui roule), et mesurer la position de l’élément mécanique (roue libre pour un déplacement, position d'un bras) pour mesurer les contraintes mécaniques (glissement, jeu,…). Ensuite, il faut 3 PWM pour un moteur synchrones.
C'est seulement pour un moteur. On peut ensuite ajouter des choses comme des télémètres, des capteurs de couleurs, une central inertiels, …. Il existe des blocs tout fait, mais cela serait bien plus compact et moins couteux d'interfacer la partie analogique directement avec le SoC.
Disons qu'en retro action mécanique, 10 ms est une réactivité basse, 4 ms est assez rapide, et 1 ms gère tous les cas.
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.
Si, tous, c'est bien trop compliqué sinon. Imagine une machine synchrone qui commande un robot humanoïde.
De mémoire, NAO a 25 moteurs. Il est pseudo statique, mais si tu avais besoin de faire l'équilibre du robot, il faudrait une rétro action complète de sa position. Tu as donc besoin de connaitre la position réels des articulations (genre un potentiometre avec un ADC derrière), plus une mesure du courant du moteur pour avoir une idée de la force déployée, une mesure de la vitesse de rotation du moteur ou de sa position (le but est de tenir compte du jeu de l'articulation), puis 3 PWM si tu as un moteur synchrone.
Donc ton programme pour gérer ce genre de chose, tourne entre 100 et 1000Hz, prend en entré tous les capteurs, et calcule ensuite toutes les sorties. Tu peux faire un peu de masquage de latence, avec la lecture au temps n, le calcul des données n-1, et l'écriture des données n-2. Mais dans ce cas, le cpu doit être libre.
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é).
Il y a des solutions ou un gros µP est maitre, et un PC est esclave. Mais cela reste une architecture un poil compliqué. Un truc sous Linux permet d'avoir le réseau (wifi ou filaire) qui permet de bien connaitre l'état interne du robot. Avec un simple µP, il faut + moins tout écrire : gestion de l'extraction des données vers un hote, affichage, etc… C'est quasi impossible d'avoir des logs à cause de la mémoire trop faible.
Un µP ne permet pas non plus de faire de la cartographie à cause de la taille de la RAM, ou du traitement d'images même léger. On peut aussi imaginer l'usage du Bluetooth.
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.
À partir de là, la solution est d'associer les 2, mais tu n'aimes pas.
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.
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.
Tu cherches quelque chose qui (pour ce que j'en connais) n'existe pas ou presque :
puissant comme un SoC pour faire tourner un Linux ;
des E/S analogiques d'un µC ;
un grand nombre d'E/S ;
monolythique.
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.
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à.
J'avais déjà regardé à l'époque et rien n'a changé. Dans ma description, je décris un moyen simple et pas chère de faire de la robotique issue de 10 ans de coupe e=m6 (ou presque) et une formation en ingénieur microélectronique. Et la carte que tu pointes ne répond pas du tout, à ce dont je parles.
Pas de CAN/ADC veut simplement dire pas d'entrée ! C'est ballot pour un robot ! Oui, tu peux rajouter une paquet de merde utilisant des I2C ou des UART, mais jamais tu pourras mettre des dizaines d'entrée lisible en quelques millisecondes sans pomper tout le cpu disponible.
Donc, toutes "IOS" dédié I2C, USB, UART, je m'en fiche complètement. Cela ne répond pas du tout à ce dont je parle au dessus. Tu devrais aussi mieux lire les demandes.
Pour les entrées, tu as bien une centaine d'IO du FPGA en 3.3V, ok. Il ne reste plus qu'à coder la centaine de PWM qui va avec, ce n'est pas le plus simple à faire !
Le bus interne 16 bit pour parler au FPGA semble assez rapide.
Par contre, attention, ça reste un module (auquel tu peux ajouter une carte de dév), pas quelque chose d'immédiatement prêt à l'emploi comme un SBC ou beaucoup de cartes µC.
Regarde des trucs genre intellij ou eclipse, tout en java, pas franchement lent (mais oui, ca met beaucoup de temps a demarrer).
Justement, je code un client RCP, et "rapide" est pas franchement le 1er qualificatif qui me vient à l'esprit.On a pu faire la comparaison de consommation mémoire entre 2 outils, l'un basé sur eclipse, l'autre maison en c++, pour la même quantité d'objet, il y a un facteur 10.
Tu fais du Zenitram. Regardes comment fonctionne openssl ou gpg pour encoder un fichier en AES, et arrêtes de te ridiculiser. PBKDF2 n'est (n'était ?) pas un choix.
Par contre ça n'a sans doute rien à voir avec une quelconque facilitation de brute-force de mots de passe.
Indirectement si. Le 2ième était très bon en soft, mais gros (pas lent) en hardware. Donc, mettre plein d'accélérateur de calcul de hash, aurait pris bien plus de place sur une puce, que pour l'algorithme choisi. Cela complique beaucoup la vie de ceux qui casse des mots de passe avec des paquets de FPGA.
En même temps casser un fichier AES ayant un mot de passe peut être rapide avec des trucs comme hashcat (~1Gkey/s).
Donc, si tu planques des trucs derrière AES contre la NSA, il faut au moins 100 bits d'entropie, cela fait 8 mots du dictionnaires, rare pour un mot de passe…
Il suffit de voir les critères pour l'attribution de sha3, un des algo finaliste a été écarté car il était trop lent en hardware, contrairement à celui choisi.
mouais. Il n'y a pas tellement d'IO, pas de ADC. Et j'imagine que tu dois tout faire tout même (VHDL + drivers), ce qui n'est pas si simple. La connection ARM-FPGA est parfois pas top (pseudo lien série lent).
Je ne peux rien pour toi si tu n'as pas le temps ou pas d'intérêt pour comprendre et suivre les règles du projet auquel tu veux contribuer.
J'ai suivi un MOOC sur les interfaces, donc, j'ai une vision déformé des choses. Mais il n'a jamais été question de changer les règles, simplement de changer l'interface, pour la rendre plus agréable et efficace.
Utiliser des images sous copyright est complexe, mais le cas des logos est très courant dans ce cas complexe. Il est facile de mettre une exception générique pour mettre le logo pour l'objet en question.
Je crois que tu te trompes, la majorité des boites codent maintenant en Java. Je ne sais pas si c'est Java qui est lent ou l’empilement de couche, mais une application java est lente.
Ton problème finale de faux partage n'est rien par rapport au problème de l'écriture sur le registre qui écrase les valeurs autour.
Les champs de bits avec une union sur un registre, j'ai souvent vu ça sur des mini drivers de µcontroller, c'est facile, car le compilo est toujours le même pour une cible donné. Il suffit de regarder ce que génère le compilateur et s'adapter.
[^] # Re: Ça tombe bien
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Simplification des démarches administratives. Évalué à 4.
"regarde les langues parlées : elles sont "bien définies","
Non, justement elles ne le sont pas.
"je bosse dans les meta-données venant de plein de format différents, j'en chie tous les jours sur ces "équivalences"."
Quel rapport avec leur définition embarqué dans le format ?
"La première sécurité est la liberté"
[^] # Re: Ça tombe bien
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Simplification des démarches administratives. Évalué à 1.
J'ai l'impression qu'il est complexe de se mettre d'accord sur la forme des meta-donnés pour une série de document qui implique beaucoup d'intervenant.
Est-ce qu'il n'existe pas de format de donné qui embarque leur propre description ? En gros, d'avoir un XML avec sa DTD ou équivalent dedans ?
L'open data semble avoir ce problème récurent de format. Si les meta données sont définis, faire des équivalences entre format ne devrait pas être difficile non ?
"La première sécurité est la liberté"
[^] # Re: tu as raison
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De l'approche ultra-légère de la sécurité sur linuxfr. Évalué à 2.
Ce qui, avec hashcat, est d'une très relative utilité.
"La première sécurité est la liberté"
[^] # Re: tu as raison
Posté par Nicolas Boulay (site web personnel) . En réponse au journal De l'approche ultra-légère de la sécurité sur linuxfr. Évalué à 7.
Si les mots de passe sont partis, c'est autrement plus gênant.
"La première sécurité est la liberté"
[^] # Re: pour le son ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Raspberry Pi B+: une évolution intéressante (sans être une révolution) . Évalué à 1.
Il n'y a pas des carte un poil plus chère qui font le boulot ?
"La première sécurité est la liberté"
[^] # Re: boxed/unboxed ou expansion
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Encore une couche de rouille avec Rust 0.11. Évalué à 3.
Disparu avec son créateur.
"La première sécurité est la liberté"
# boxed/unboxed ou expansion
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Encore une couche de rouille avec Rust 0.11. Évalué à 1.
Je n'ai pas bien compris l'usage de Box, est-ce qu'il s'agit du même système d'expand de Lisaac, qui permet d'éviter les cochonneries de type natif de Java (int != Integer) ?
Dans Lisaac, c'était hyper puissant, de faire la différence entre un layout mémoire "en dure" et un arbre de pointeur tel que se présente une arborescence d'objet. Typiquement, cela permettait à l'OS Isaac de coder les pixels de l'interface graphique comme des objets, sans perte de vitesse par rapport au C.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 2.
Pourquoi ils ne font pas de vrai bus d'extension série, avec possibilité de chainage ? Si la partie d'adresse prend trop de place, il faut un encodage type UTF-8. Ensuite, il faut trouver un moyen de démarrer pour faire de l'allocation de zone mémoire, mais cela se fait depuis le PCI.
Tu oublis les fils qui partent de chaque module pour aller vers les capteurs ou les moteurs.
"La première sécurité est la liberté"
[^] # 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é"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
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.
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.
C'est vrai que cela a du sens pour chaque moteur ou groupe de moteur, couplé à la partie puissance, mais il faut des cartes numériques stupides, pas d'asservissement par exemple.
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à.
D'ailleurs, je n'ai jamais compris que personne n'est fait encore de bus d'extention série de µP avec adressage. Électriquement, cela peut être du SPI (2 ou 3 fils), mais ensuite, qu'il n'y ai rien besoin d'autre. Cela serait une sorte de mini PCI-express. L'I2C fait un peu ça, mais c'est lent, et l'espace d'adressage est petit, rarement inclus dans l'espace d'adressage du µP, et il faudrait du DMA.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
Oui et non, c'est surtout que les fabricants de puce n'ont pas vu d’intérêt pour la robotique.
Je suis conscient que les procédés de SoC ne sont pas adapté au ADC, et que les procédés de µP ai du mal avec le wifi. Mais bon, 160 Mhz, cela irait. 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 et si tu as 2 puces, tu as 30 pattes pour communiquer entre les 2.
Tu es un vrai hardeux qui croit que le soft est magique :) Si tu gère l'équilibre d'un robot humanoïde tout bouge en même temps et tous les moteurs sont ajustés.
C'est pas faux. En même temps, 8 ou 10 bits c'est suffisant, et 1 000hz, c'est que dalle. Un adc de base à 10 bits doit pouvoir tourner à plusieurs MHz, à multiplexer sur plein de lignes. Ensuite, souvent le signal est sur la tension, un pull-up pour avoir un peu d'intensité, permet de masquer le bruit.
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).
Le SPI est un peu pourris, cela bouffe beaucoup de cpu. J'ai vu des CAN spi qui avait des attentes actives, c'était rédhibitoire, surtout pour une dizaine. Tu as donc besoin de truc spi qui fonctionne avec DMA, c'est pas évident. Il faudrait un CAN à ~4 entrées qui envoient en flux ses données, pour y gagner, et les pwm dans l'autre sens.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
Non, c'est dans l'ordre de grandeur de ce qui existe déjà. Le problème est d'être sûr de pouvoir faire 17 mesure toutes les ms. C'est parfois très lent de changer de ligne, par exemple.
Par exemple, pour un seul moteur, il faut mesurer le courant, il faudrait mesurer la tension en entré, mesurer la position du moteur (pour un servomoteur) ou sa vitesse de rotation (pour un truc qui roule), et mesurer la position de l’élément mécanique (roue libre pour un déplacement, position d'un bras) pour mesurer les contraintes mécaniques (glissement, jeu,…). Ensuite, il faut 3 PWM pour un moteur synchrones.
C'est seulement pour un moteur. On peut ensuite ajouter des choses comme des télémètres, des capteurs de couleurs, une central inertiels, …. Il existe des blocs tout fait, mais cela serait bien plus compact et moins couteux d'interfacer la partie analogique directement avec le SoC.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
Disons qu'en retro action mécanique, 10 ms est une réactivité basse, 4 ms est assez rapide, et 1 ms gère tous les cas.
Si, tous, c'est bien trop compliqué sinon. Imagine une machine synchrone qui commande un robot humanoïde.
De mémoire, NAO a 25 moteurs. Il est pseudo statique, mais si tu avais besoin de faire l'équilibre du robot, il faudrait une rétro action complète de sa position. Tu as donc besoin de connaitre la position réels des articulations (genre un potentiometre avec un ADC derrière), plus une mesure du courant du moteur pour avoir une idée de la force déployée, une mesure de la vitesse de rotation du moteur ou de sa position (le but est de tenir compte du jeu de l'articulation), puis 3 PWM si tu as un moteur synchrone.
Donc ton programme pour gérer ce genre de chose, tourne entre 100 et 1000Hz, prend en entré tous les capteurs, et calcule ensuite toutes les sorties. Tu peux faire un peu de masquage de latence, avec la lecture au temps n, le calcul des données n-1, et l'écriture des données n-2. Mais dans ce cas, le cpu doit être libre.
Il y a des solutions ou un gros µP est maitre, et un PC est esclave. Mais cela reste une architecture un poil compliqué. Un truc sous Linux permet d'avoir le réseau (wifi ou filaire) qui permet de bien connaitre l'état interne du robot. Avec un simple µP, il faut + moins tout écrire : gestion de l'extraction des données vers un hote, affichage, etc… C'est quasi impossible d'avoir des logs à cause de la mémoire trop faible.
Un µP ne permet pas non plus de faire de la cartographie à cause de la taille de la RAM, ou du traitement d'images même léger. On peut aussi imaginer l'usage du Bluetooth.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 3.
Il y a tout le décodage à faire proprement et être sur que cela rentre. 100 compteurs 16 bits, cela n'est pas petit.
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.
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.
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.
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à.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 5.
J'avais déjà regardé à l'époque et rien n'a changé. Dans ma description, je décris un moyen simple et pas chère de faire de la robotique issue de 10 ans de coupe e=m6 (ou presque) et une formation en ingénieur microélectronique. Et la carte que tu pointes ne répond pas du tout, à ce dont je parles.
Pas de CAN/ADC veut simplement dire pas d'entrée ! C'est ballot pour un robot ! Oui, tu peux rajouter une paquet de merde utilisant des I2C ou des UART, mais jamais tu pourras mettre des dizaines d'entrée lisible en quelques millisecondes sans pomper tout le cpu disponible.
Donc, toutes "IOS" dédié I2C, USB, UART, je m'en fiche complètement. Cela ne répond pas du tout à ce dont je parle au dessus. Tu devrais aussi mieux lire les demandes.
Pour les entrées, tu as bien une centaine d'IO du FPGA en 3.3V, ok. Il ne reste plus qu'à coder la centaine de PWM qui va avec, ce n'est pas le plus simple à faire !
Le bus interne 16 bit pour parler au FPGA semble assez rapide.
Tu remarques enfin ce que je cherche vraiment ?
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Tu as des sources pour accélérer le lancement d'IDE basé sur eclipse et leur paquet de plugin ?
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Justement, je code un client RCP, et "rapide" est pas franchement le 1er qualificatif qui me vient à l'esprit.On a pu faire la comparaison de consommation mémoire entre 2 outils, l'un basé sur eclipse, l'autre maison en c++, pour la même quantité d'objet, il y a un facteur 10.
"La première sécurité est la liberté"
[^] # Re: pas forcément
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 6.
Tu fais du Zenitram. Regardes comment fonctionne openssl ou gpg pour encoder un fichier en AES, et arrêtes de te ridiculiser. PBKDF2 n'est (n'était ?) pas un choix.
"La première sécurité est la liberté"
[^] # Re: pas forcément
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 2.
Indirectement si. Le 2ième était très bon en soft, mais gros (pas lent) en hardware. Donc, mettre plein d'accélérateur de calcul de hash, aurait pris bien plus de place sur une puce, que pour l'algorithme choisi. Cela complique beaucoup la vie de ceux qui casse des mots de passe avec des paquets de FPGA.
"La première sécurité est la liberté"
[^] # Re: pas forcément
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 1.
Les clefs sont toujours hashé avant d'être utilisé. Cela détermine la vitesse du brute force.
"La première sécurité est la liberté"
[^] # Re: pas forcément
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Qu'un algo de chiffrement soit cassé, est-ce important pour nos PETITS secrets ?. Évalué à 0.
En même temps casser un fichier AES ayant un mot de passe peut être rapide avec des trucs comme hashcat (~1Gkey/s).
Donc, si tu planques des trucs derrière AES contre la NSA, il faut au moins 100 bits d'entropie, cela fait 8 mots du dictionnaires, rare pour un mot de passe…
Il suffit de voir les critères pour l'attribution de sha3, un des algo finaliste a été écarté car il était trop lent en hardware, contrairement à celui choisi.
"La première sécurité est la liberté"
[^] # Re: embarqué ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche L’arrivée du BananaPi. Évalué à 0.
mouais. Il n'y a pas tellement d'IO, pas de ADC. Et j'imagine que tu dois tout faire tout même (VHDL + drivers), ce qui n'est pas si simple. La connection ARM-FPGA est parfois pas top (pseudo lien série lent).
"La première sécurité est la liberté"
[^] # Re: Si, ce sont des images libres !
Posté par Nicolas Boulay (site web personnel) . En réponse au message logo dans wikipedia. Évalué à 2.
J'ai suivi un MOOC sur les interfaces, donc, j'ai une vision déformé des choses. Mais il n'a jamais été question de changer les règles, simplement de changer l'interface, pour la rendre plus agréable et efficace.
Utiliser des images sous copyright est complexe, mais le cas des logos est très courant dans ce cas complexe. Il est facile de mettre une exception générique pour mettre le logo pour l'objet en question.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 4.
Je crois que tu te trompes, la majorité des boites codent maintenant en Java. Je ne sais pas si c'est Java qui est lent ou l’empilement de couche, mais une application java est lente.
"La première sécurité est la liberté"
[^] # Re: suckless !! More is less !
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi un PC ralentit-il ?. Évalué à 2.
Ton problème finale de faux partage n'est rien par rapport au problème de l'écriture sur le registre qui écrase les valeurs autour.
Les champs de bits avec une union sur un registre, j'ai souvent vu ça sur des mini drivers de µcontroller, c'est facile, car le compilo est toujours le même pour une cible donné. Il suffit de regarder ce que génère le compilateur et s'adapter.
"La première sécurité est la liberté"