Bonjour,
quel composant utilisez vous en compteur decompteur ?
bULBot wrote: Si je me souviens bien, le PIC18 ne permet pas à une interruption de se faire réinterrompre même si la nouvelle est d'un niveau supérieur : il ne fera l'appel que lorsque l'interruption en cours se termine, et choisira la plus prioritaire. C'est possible sous dsPIC/PIC24 en revanche, sous le nom de Nested Interrupts.
+1antoine_cvra wrote:Pour le Raspberry Pi, je pense que ça risque d'être compliqué, non pas au niveau interfaçage avec la motorisation / les codeurs (le Pi possède un port SPI), mais plutot au niveau temps réel si tu veux faire de l'odométrie ou de l'asservissement, tu risques d'avoir de la peine à avoir une fréquence fixe, Linux n'étant pas prévu pour.
Effectivement c'est le dilemme de Raspberrry. Il y a des portages d'OS temps réel tel que FreeRTOS et là tu as la maitrise de ta clock. Le problème c'est que pour le moment, du fait de l’architecture (électronique bas cout pondu par des softeux) de la Raspberry tu perds tout l'intérêt de la board en terme de périphérique. Pour exemple le LAN est monté sur un chip extension USB, donc il faut développer une stack USB et communiquer avec ce chip pour avoir du LAN. Bref Raspberry=temps réel c'est pas encore tout ça tout ça pour le moment.antoine_cvra wrote:Pour le Raspberry Pi, ... plutot au niveau temps réel ...Linux n'étant pas prévu pour.
Je suis entièrement d'accord avec vous, l'utilisation du RaspberryPi ne servirai qu'a remplacer la partie CMUcam et ajouter une partie débug (par liaison série probablement). J'ai créé ce fil de discution car je cherche à concevoir notre nouvelle carte à microcontrôleur (et vous m'avez déjà donné des bonnes piste la dessus !). Je suis plutôt persuadé qu'un OS sur un processeur n'est pas adapté :Nirgal wrote:Effectivement c'est le dilemme de Raspberrry. Il y a des portages d'OS temps réel tel que FreeRTOS et là tu as la maitrise de ta clock. Le problème c'est que pour le moment, du fait de l’architecture (électronique bas cout pondu par des softeux) de la Raspberry tu perds tout l'intérêt de la board en terme de périphérique. Pour exemple le LAN est monté sur un chip extension USB, donc il faut développer une stack USB et communiquer avec ce chip pour avoir du LAN. Bref Raspberry=temps réel c'est pas encore tout ça tout ça pour le moment.antoine_cvra l wrote: Pour le Raspberry Pi, ... plutot au niveau temps réel ...Linux n'étant pas prévu pour.
La demande de SuPerBaLoO m'a échappé, il s'agit du ls7366.Keuronde wrote: Comme SuPerBaLoO, je serai curieux de connaître les composants utilisés par RCVA pour la lecture des capteurs incrémentaux !
(J'ai déjà l'intention d'acquérir le gyroscope présenté par RCVA, alors pourquoi ne pas continuer avec un autre composant)
GARGAMEL wrote:La demande de SuPerBaLoO m'a échappé, il s'agit du ls7366.Keuronde wrote: Comme SuPerBaLoO, je serai curieux de connaître les composants utilisés par RCVA pour la lecture des capteurs incrémentaux !
(J'ai déjà l'intention d'acquérir le gyroscope présenté par RCVA, alors pourquoi ne pas continuer avec un autre composant)
7366 R version DIP
7366 R-S version SOIC
Quelles que soient les préférences de chacun, on retombe toujours sur ce genre de problématique. On s'aperçoit toujours qu'il est préférable de répartir les différentes tâches de l'électronique numérique en deux ensembles :Nirgal wrote:+1antoine_cvra wrote:Pour le Raspberry Pi, je pense que ça risque d'être compliqué, non pas au niveau interfaçage avec la motorisation / les codeurs (le Pi possède un port SPI), mais plutot au niveau temps réel si tu veux faire de l'odométrie ou de l'asservissement, tu risques d'avoir de la peine à avoir une fréquence fixe, Linux n'étant pas prévu pour.
Le raspberry Pi est souvent plus séduisant qu'efficace pour faire du temps réel...
A moins de chercher à y grimper un OS temps réel (et préemptif tant qu'à faire)... et là, on tombe sur un autre problème : on manque d'interfaces et de broches d'entrées/sorties...
Si vous voulez profiter de cette carte... intuitivement je dirais qu'elle se prête bien aux algos 'haut niveaux'.. à condition d'y adjoindre une carte micro très temps réel à coté... (moteurs, codeurs, acquisitions...)
A noter qu'il existe d'autres cartes du même acabit que la RPi, par exemple la BeagleBone Black qui présente plus d'entrées sortie, et certains types de bus directement. Une RPi est plus axée sur du traitement multimedia (pour faire un petit serveur à la maison par exemple), alors que la BeagleBone Black est plus pour faire du traitement de données, plus adaptée pour les robots je pense. Par contre, intégrer un RTOS sur une BBBlack, jamais entendu parler (jamais cherché, non plus, remarque)Nirgal wrote:+1antoine_cvra wrote:Pour le Raspberry Pi, je pense que ça risque d'être compliqué, non pas au niveau interfaçage avec la motorisation / les codeurs (le Pi possède un port SPI), mais plutot au niveau temps réel si tu veux faire de l'odométrie ou de l'asservissement, tu risques d'avoir de la peine à avoir une fréquence fixe, Linux n'étant pas prévu pour.
Le raspberry Pi est souvent plus séduisant qu'efficace pour faire du temps réel...
A moins de chercher à y grimper un OS temps réel (et préemptif tant qu'à faire)... et là, on tombe sur un autre problème : on manque d'interfaces et de broches d'entrées/sorties...
Christophe Blaess en à fait une bonne analyse ici, avec tous les avantages/inconvénients de chacune de ces 2 cartes : http://www.blaess.fr/christophe/2013/05 ... -a-ronger/Chbi wrote:A noter qu'il existe d'autres cartes du même acabit que la RPi, par exemple la BeagleBone Black qui présente plus d'entrées sortie, et certains types de bus directement. Une RPi est plus axée sur du traitement multimedia (pour faire un petit serveur à la maison par exemple), alors que la BeagleBone Black est plus pour faire du traitement de données, plus adaptée pour les robots je pense.
Tu peux même mettre Xenomai sur RaspberryPi (patch temps réel pour linux), ce qui te permet de garder la souplesse de Linux et d'avoir des tâches temps réel dur (il mesure des latences inférieurs à 50 µs pendant ses tests): http://www.blaess.fr/christophe/2012/08 ... pberry-pi/Chbi wrote:Par contre, intégrer un RTOS sur une BBBlack, jamais entendu parler (jamais cherché, non plus, remarque)
Effectivement, faut pas prendre le résultat au pied de la lettre. L'objectif était de dire que ça existait, que c'était pas forcement trop dur à faire, et que ça reste assez performant.Archi'Tech wrote:Attention, il l'a dit lui même, les charges appliquées lors des tests de latence n'étaient peut être pas bonne. Il n'a d'ailleurs apparemment pas relevé les taux de cache miss, TLB miss, etc... déterminer le worst case est assez compliqué.
Salut Nirgal,Nirgal wrote:Salut "la poutre"...
Une petite question à propos de ton retour d'expérience sur ces connecteurs 'rouges'...
Qu'en penses-tu ?
Fiable ? Solide ? Maintenu ?...
Avez-vous eu des soucis avec... ?
Merci !