# [GCC]   Erreur en compilation croisée.

## Jacqueline

Bonjour !

j'essaye de compiler un minikernel embarqué  pour une carte à processeur ARM ( c'est pour essayer avant de craquer pour une tite carte t lmes compils "embedded=y " durent moins longtemps   :Wink:   )

 Je compile avec suse : 2.6.18.2-34-default

 J'ai tiré les sources du dernier kernel ( tant qu'à faire   :Very Happy:   ) 

Pour pas mettre le binz  dans mon système ( on sait jamais  )  je compile ça dans un coin de ma /home

 Pas de problème pour compiler un mini x86-64, la compile va au bout ! , mais  l kernel est énorme ( c'était juste pour voir si ça marchait  )

pour essayer aussi ( sur un tuto ) j'ai voulu faire un mini i386 , la compile plante mais c'est pas la même erreur )

une arch  cris  pareil ! ( pb de toolchain  et j'ai du recompiler un GCCC avec d'autres trucs d'Axis  sans pb la recompil decris-gcc  le script teste tout  et reste plus qu'à changer de GCC et de réessayer  ( je sais pas changer de GCC  pour le moment il est dans /usr/local  )

 J'ai essayé avec une arch arm la compile plante encore..

 Avant j'ai fait un make clean  (avec ARCH=arm et sans : pour voir  ça fait pareil 

Je démarre le truc comme sur le tuto un peu light avec make ARCH=arm allnoconfig , pour céer le .congfig avec le mini minimum

puis make ARCH=arm menuconfig et je rajoute trois options .. et mon fichier est bien créé.

 *Quote:*   

> linux-6zgh:/home/jacqueline/microlinux/linux # make ARCH=arm clean
> 
>   CLEAN   .tmp_versions
> 
>   CLEAN   include/asm-arm/mach-types.h include/asm-arm/arch include/asm-arm/.arch

 

j'ai relancé ça avec -d   et j'ai pris tout ce  qui concerne un fichier cité ds les messages d'erreur 

linux-6zgh:/home/jacqueline/microlinux/linux # make -d ARCH=arm

GNU Make 3.81

Copyright (C) 2006  Free Software Foundation, Inc.

Ceci est un logiciel libre ; voir le source pour les conditions de copie.

Il n'y a PAS de garantie ; tant pour une utilisation COMMERCIALE que pour

RÉPONDRE À UN BESOIN PARTICULIER.

Ce logiciel est construit pour x86_64-unknown-linux-gnu

Lecture des makefiles...

Lecture du makefile « Makefile »...

Lecture du makefile « /home/jacqueline/microlinux/linux-2.6.22.1/scripts/Kbuild.include » (chemin de recherche) (pas de remplacement du ~)...

.

.

 ;j'ai censuré là !   :Very Happy: 

voilà le problème..

 ....

.

.

.

 Essai du schéma avec « Makefile.build » comme préfixe.

  Essaie de la dépendance implicite « scripts/Makefile.build_shipped ».

  Pas de règle implicite trouvée pour « scripts/Makefile.build ».

  Fin des dépendances du fichier cible « scripts/Makefile.build ».

 Inutile de refabriquer la cible « scripts/Makefile.build »..

Mise à jour des cibles visées....

Étude du fichier cible « __build ».

 Le fichier « __build » n'existe pas.

  Étude du fichier cible « include/asm-arm/asm-offsets.h ».

   Le fichier « include/asm-arm/asm-offsets.h » n'existe pas.

    Étude du fichier cible « arch/arm/kernel/asm-offsets.s ».

     Le fichier « arch/arm/kernel/asm-offsets.s » n'existe pas.

      Étude du fichier cible « arch/arm/kernel/asm-offsets.c ».

       Recherche d'une règle implicite pour « arch/arm/kernel/asm-offsets.c ».

       Essai du schéma avec « asm-offsets.c » comme préfixe.

       Essaie de la dépendance implicite « arch/arm/kernel/asm-offsets.c_shipped ».

       Pas de règle implicite trouvée pour « arch/arm/kernel/asm-offsets.c ».

       Fin des dépendances du fichier cible « arch/arm/kernel/asm-offsets.c ».

      Inutile de refabriquer la cible « arch/arm/kernel/asm-offsets.c »..

      Étude du fichier cible « FORCE ».

       Le fichier « FORCE » n'existe pas.  :Sad: 

       Fin des dépendances du fichier cible « FORCE ».

      Il faut refabriquer la cible « FORCE ».

      Refabrication du fichier cible « FORCE » réussie   :Very Happy: 

.

     Fin des dépendances du fichier cible « arch/arm/kernel/asm-offsets.s ».

    Il faut refabriquer la cible « arch/arm/kernel/asm-offsets.s ».

Ajout du processus fils 0x0068b070 (arch/arm/kernel/asm-offsets.s) PID 7503 à la chaîne.

Processus fils actif 0x0068b070 (arch/arm/kernel/asm-offsets.s) PID 7503

Récupération du statut de sortie du processus fils 0x0068b070 PID 7503

  CC      arch/arm/kernel/asm-offsets.s

Processus fils actif 0x0068b070 (arch/arm/kernel/asm-offsets.s) PID 7505

cc1: erreur: option "-mlittle-endian" de la ligne de commande non reconnue

cc1: erreur: option "-mapcs" de la ligne de commande non reconnue

cc1: erreur: option "-mno-sched-prolog" de la ligne de commande non reconnue

cc1: erreur: option "-mabi=apcs-gnu" de la ligne de commande non reconnue

Récupération du statut de sortie du processus fils 0x0068b070 PID 7505

make[1]: *** [arch/arm/kernel/asm-offsets.s] Erreur 1

Suppression du processus fils 0x0068b070 PID 7505 de la chaîne.

Récupération du statut de sortie du processus fils 0x006dee80 PID 7502

make: *** [prepare0] Erreur 2

Suppression du processus fils 0x006dee80 PID 7502 de la chaîne.[/quote]

 *Quote:*   

> linux-6zgh:/home/jacqueline/microlinux/linux # gcc -v
> 
> Utilisation des specs internes.
> 
> Target: x86_64-suse-linux
> ...

 

 *Quote:*   

> linux-6zgh:/home/jacqueline/microlinux/linux # make -v
> 
> GNU Make 3.81
> 
> Copyright (C) 2006  Free Software Foundation, Inc.
> ...

 

 voilà ce que j'ai comme fichiers dans linux-6zgh:/home/jacqueline/microlinux/linux/arch/arm/kernel

 *Quote:*   

> .              crunch.c        head-common.S    module.c           stacktrace.c
> 
> ..             debug.S         head-nommu.S     process.c          stacktrace.h
> 
> armksyms.c     dma.c           head.S           ptrace.c           sys_arm.c
> ...

 

 Dans la notice de GNU GCC     "ça  ressemble aussi  beaucoup .au problème  .. non ? "

 *Quote:*   

> 3.16 Specifying Target Machine and Compiler Version
> 
> The usual way to run GCC is to run the executable called gcc, or <machine>-gcc when cross-compiling, or <machine>-gcc-<version> to run a version other than the one that was installed last.
> 
> Sometimes this is inconvenient, so GCC provides options that will switch to another cross-compiler or version.
> ...

 

 je n'arrive pas à trouver ce qui met les options mal reconnues..comme : cc1: erreur: option "-mlittle-endian" de la ligne de commande non reconnue

 je ne sais pas si le GCC de ma Suse ( version gcc 4.1.2 20061115 (prerelease) (SUSE Linux))[/quote]a tout ! parce quec'est clicodromesque et les  arm et cris ne sont  pas leur préoccupation..

 si qqun peut me mettre sur les rails .. je le remercie d'avance.   :Smile: 

 jacqueline.

----------

## ryo-san

salut , 

je pense que l'erreur principale ici est d'essayer de compiler ARCH avec un compilateur qui n'est configuré que pour le X64.

Le principe de la compilation croisée debute avec un compilateur quelconque, avec lequel on compile une toolchain ARCH ( gcc , binutils , linux-headers )

on peut ensuite compiler avec cette toolchain le kernel et autres executables.

Je crois , mais c'est a confirmer , que l'on ne peut compiler directement ARCH comme tu essaies de le faire.

Il me semble que tu avais une gentoo sous la main : il y l'excellent "crossdev" qui est l'outil ultime pour compiler cette toolchain.

Pour changer de compilateur , tu peut faire un "CC=/chemin_compilo", il me semble que c'est comme ca que l'on procede, a la main.

Voila pour ma modeste contribution , je puise dans ma memoire car cela fais un petit moment que je n'ai plus fais ce genre de manips, j'espere ne pas avoir dit de c********

----------

## Jacqueline

Merci de ta réponse  ryo_san.

 Ca m'éclaire  bien pour  aborder le sujet.  Je crois que j'ai encore des choses à lire..  :Very Happy: 

 Je regardais encore ce matin  à tête reposée la doc de Casteyde le chapitre de GCC : ah les joies des distribs précompilées..( sans parler de faire de la compilation croisée.. c'est vraiment trop  demander..)

Si seulement les rares tutos qu'on trouve donnaient un petit avertissement avant d'envoyer les gens sur un truc qui va foirer neufs sur dix..

 Hier j'étais tentée d'essayer avec la gentoo, il y  avait tout ce qu'il fallait pour les compils de kernels ( faut que je finisse l'interface graphique  )

 Je donnerais des news.

 Jacqueline

----------

## Jacqueline

C'est compliqué pour Linux embarqué et tous ces modèles de microprocesseurs.

 j'ai trouvé la réponse et la méthode ici.. ( assez universelle  : on peut faire 

machine hote et build  i386 et machine cible x86-64 aussi  )

http://kegel.com/crosstool/

Les combinaisons gcc glibc qui marchent  pour le kernel et le debuger gdb , pour chaque architecture sont ici :  http://kegel.com/crosstool/crosstool-0.43/buildlogs/

 Croostool , permet d'utiliser automatiquement les bonnes combinaisons et va downloader les sources correspondantes., parce que pour utiliser certaines librairies spéciales de l'embarqué on doit utiliser d'anciennes versions de kernel.. 

 Ils ont des outils aussi  ( Cygwin) qui permettent de compiler des linux embarqués sur des plateformes de développement Windaube..  :Rolling Eyes: 

----------

## kwenspc

 *Jacqueline wrote:*   

> C'est compliqué pour Linux embarqué et tous ces modèles de microprocesseurs.
> 
>  j'ai trouvé la réponse et la méthode ici.. ( assez universelle )
> 
> http://kegel.com/crosstool/
> ...

 

Ah dommage que je ne tombe que maintenant sur ce topic!

Crosstool est un bonne base de départ mais tu verras très vite que ça devient le boxon dès lors qu'il faut cross-compiler des applis qui possèdent pas mal de dépendances (bibliothèques de fonctions, sous-softs...). Disons qu'à part le kernel lui même...le reste c'est pas la peine d'y penser. (à moins d'y adjoindre certains outils plus évolué pour le linkage et tout)

Je sais pas si tu peux avoir accès à une Gentoo, mais si c'est le cas : fais le!

J'ai vus des collègues s'arracher les cheveux 3 semaines durant pour recréer  des bases rootfs (le baselayout, les softs de base et quelques autres plus particuliers etc...) sous ubuntu, debian, et autres alors que sous Gentoo j'y suis parvenus en moins d'1 journée.

Je te conseilles l'outil crossdev spécialement créer pour Gentoo.  (je parles bien de sys-devel/crossdev et non de https://crossdev.timesys.com/ ) [edit] ah bah oui tiens ryo_san l'a déjà proposé [/edit]

Avant même de créer ton cross-compilo renseignes toi sur la cible arm que tu as. (il a énormément de différences parfois, et le pire serait que tu tombes sur une cible qui ne supporte pas le calcul flottant en matériel. Là j'en ai un poil plus chi*** pour y arriver). 

Ensuite utilises l'excellente base de résultat ici (sur le même site que tu as trouvés, et que j'ai utilisés)  http://kegel.com/crosstool/crosstool-0.43/buildlogs/

Tu verras que toutes les combinaisons gcc/glibc ne sont pas forcément bonne, tout dépend du besoin sous-jacent. [edit bon j'ai vraiment lu les réponses en diagonales, vu que tu le proposais déjà. Ah oui mais nan ok, tu l'as réédité ensuite pendant que j'écrivais ma propre réponse. [/edit]

Ce lien peut aider -> http://hackndev.com/node/607 (même si il est peu détaillé et même très brouillon)

J'ai fais une doc plus détaillée sur la création from-scratch d'un rootfs, mais rien encore de "propre" à diffuser, cependant je peux te la faire parvenir si tu en ressens le besoin. Bon cette solution Gentoo+crossedev c'est bien pour ce type d'application, pour quelque chose de plus compliqué (comme l'intégration de kdriver, matchbox et tout) ça devient la croix et la bannière et seul OpenEmbedded (voir plus bas) est au poil pour ça.

Sinon un conseil: faire de l'embarque linux à partir d'un host windows... tu peux direct arrêter d'y penser. Toutes ces soi-disant solutions ça tient plus du "pourquoi faire bien et simple quand on peut sale et compliqué" que de la solution véritable. Bon après bien entendu si on t'oblige expressement à utiliser ce genre d'outils...  :Neutral: 

Le super panard après c'est de carrément travaillé autour d'OpenEmbedded. C'est un environnement de  dev (et non une distro) qui, une fois maîtrisé au prix de pas mal de jours de travail, est ZE outil pour faire de l'embarque sous nux. --> http://www.openembedded.org/

C'est simple : il n'y a pas mieux.

----------

## kwenspc

 *Jacqueline wrote:*   

> 
> 
>  Croostool , permet d'utiliser automatiquement les bonnes combinaisons et va downloader les sources correspondantes., parce que pour utiliser certaines librairies spéciales de l'embarqué on doit utiliser d'anciennes versions de kernel.. 
> 
> 

 

Quand bien même crosstool automatise certains processus, il foire sur pas mal de trucs et parfois faut aller patcher à la main gcc ou la glibc pour que ça roule. (j'ai notamment eu un problème assez lourd avec le couple gcc-3.4.6/glibc-2.3.6 )

----------

## Jacqueline

Merci de ces précieux conseils kwenspc, et du retour d''expérience..

 j'ai eu une mauvaise impression d'Open Embedded avec des noms de paquets bizarres, des outils bizarres.. Zaurus... ( c'est pour Sharp ! )  et je n'ai pas voulu me lancer là dedans..

 Crosstool, je l'ai trouvé ce matin..  Je suis en train de me baggarer avec un des scripts qui ne veut pas marcher.. 

 Mais je n'ai pas oublié crossdev, seulement  pour les gens qui n'ont pas de gentoo, je me disais que ça pouvait être  simple...

 Mais l'embarqué , c'est "hard" et vu le nombre de processeurs existants avec chacun leur particularité dans la même famille...  c'est déjà difficile de choisir.

 On va se limiter à une petite carte pas chère de amadeus  basée sur un freescale ARM9  ( mais elle est livrée avec un kernel en binaire d'un seul bloc, plus son boot..(  bien sûr ça marche , mais c'est con ! )

 Ce que je veux essayer , c'est d'abord  de faire un système et une appli embarquée normale sur cette carte ,  et ensuite une appli  temps réel..  ( c'était mon job, sur des gros calculos industriels, mais tout en assembleur  lol !  ) .Dans  le hard des processeurs, je m'y retrouve assez bien ( un à la fois bien sûr ! déjà il fallait choisir ! ) et puis le datasheet il faut le lire et le relire.. j'aime bien parce que c'est la combinaison des deux :  hard et soft... et puis ça sort des applis conventionnelles du PC.et  linux qui tourne dans un paquet de cigarettes..   :Very Happy: 

 Je me suis donc branchée sur eCos, j'ai trouvé pas mal de bonne doc ( mais c'est pas le bon proc )  et un copain s'est branché sur RTAI

 On a ouvert une rubrique linux embarqué  avec ce copain sur  Terranux ( lui a fait de la   programmation robotique )..Un truc gentil, sans prétention : on découvre avec Linux..

Mais c'est passionnant. !  et puis je me recycle parce que si on  lâche quelques années, ça va vite ...

 Axis a aussi une belle carte FOX ( chez ACME ), avec un très bon support, (presque trop facile ...   :Very Happy:   ) mais elle n'est pas orientée temps réel,  et surtout beaucoup plus chère avec la carte de développement.

 Freescale fournit des outils soft en Linux, si on s'inscrit, mais pas eu le temps d'essayer..

 Ce wek end il faut que je finisse ma Gentoo pour avoir un navigateur sympa à coté ( pour aller chercher de la doc...)  et  je regarderais  un peu  crossdev. Pas encore eu le temps..

 Rah !!! si j'étais encore à Toulouse j'aurais bien trouvé un  ( ou les )  DVD de LynxRTOS certifié aviation    :Laughing:   Ca ne devrait pas bugger !   :Very Happy: 

----------

## Untux

Salut Jack :] C'est marrant, à te lire j'ai l'impression de me retrouver sur mon premier forum GNU/Linux quand je comprenais un mot sur dix. En tout cas si tu as envie de poluer ton propre fil en nous parlant un peu plus de tous ces machins et ces bidules, et en nous expliquant ce que tu en fais... hésites pas... t'auras au moins un lecteur ! :)

----------

## kwenspc

 *Jacqueline wrote:*   

> 
> 
>  j'ai eu une mauvaise impression d'Open Embedded avec des noms de paquets bizarres, des outils bizarres.. Zaurus... ( c'est pour Sharp ! )  et je n'ai pas voulu me lancer là dedans..
> 
> 

 

Si tu as le temps, penches toi dessus tout de même. Open Embedded c'est résolument l'avenir pour Linux dans l'embarqué  :Wink: 

C'est une méta-distribution (oui, Gentoo a servie d'inspiration pour OE). Grosso-modo tu quelques fichiers de configs et les "paquets" eux-mêmes, qui sont en fait de peits fichiers comparable aux ebuilds et qui incorporent les patchs et jeux d'indépendance avec d'autres paquets là encore pour la(ou les) cible(s) voulue(s). Et le Zaurus de sharp est une des multiples cibles qui a été intégrés dans OE, il y en a tout un tas et surtout: il y en a tellement maintenant qu'à coup sûr tu peux tomber sur une cible qui a le même cpu que toi.

Pour faire simple: l'interêt de travailler avec OE c'est de bénéficier des configs et patchset (soft par soft etc...) qui ont déjà été fait et qui peuvent être compatible avec ta cible (et là je dirais que pour ARM9 y en a une floppée!)

Le seul défaut c'est que ça prend du temps à prendre en main (bitbake, les fichiers de confs, les "paquets", ...). Mais par la suite la maintenance de l'ensemble est si drastiquement simplifiée que le temps pris à maîtriser l'engin et nettement rentabiliser par la suite dans toute le cycle de vie du produit.

 *Jacqueline wrote:*   

> 
> 
>  Crosstool, je l'ai trouvé ce matin..  Je suis en train de me baggarer avec un des scripts qui ne veut pas marcher.. 
> 
> 

 

Oui y a moyen de s'arracher les cheuveux parfois. Pour résumé les bidouilles crosstool c'est l'assembleur, OE c'est un langage haut niveau.

Sinon pour le reste, c-a-d le temps réel, j'ai encore jamais eu l'occasion de travailler là dessus. 

Bon courage! Et tiens nous au courant de tes avancées ça m'interesse (le RT surtout).

(au fait le lien Terranux, peux tu le poster?)

----------

## Jacqueline

Après maintes investigations, avant de me lancer dans un apprentissage long et difficile, et d'acheter une carte..

 Open Embedded ,  j'ai parcouru le site et je n'ai rien vu qui ressemblait à du temps réel : autrement dit un "scheduleur"..

 le scheduleur , c'est un truc  hard ou soft, parfois les deux( on trouve toute la gamme), qui gère la priorité des têches de l'application temps réel  avec les interruptions  internes et externes.  d

Dans Linux embarqué temps réel, c'est un gros patch connecté au matériel : au dessus il y a l'application et à coté Linux qu'on connaît, mais c est un "agent de service " à coté de l'application.. parce que dans le temps réel l'application est prioritaire. mais ça ne veut pas dire qu'avec Linux on intervient pas dans le déroulement de l'application.. par contre si on a un exploitant pour gérer l'application  : il aura son clavier pour rentrer des valeurs numériques de consigne, un écran de supervision ( avec un controleur VGA  hi hi hi , c'est fait pour ça ! ) et  de beaux synoptiques  avec une boule roulante  un curseur pour viser une cde sur le synoptique et un bouton de validation , mais ça c'est l'appli temps réel, pas le Xorg de notre Linux.( qu'on ne pourra pas mettre dans un système embarqué de toutes façons... 

Puis à coté on a une console linux  branchée sur un autre port série, pour la maintenance du système..

 idem , si l'appli a besoin d'une connection ethernet pour aller chercher des mesures ou envoyer des ordres à une autre station de l'appli temps réel, elle aura la sienne et nous une autre connection pour faire de la maintenance à distance, mais pas du tout avec les mêmes priorités.. notre Linux ne va jamais voir une interrution de l'application.. (par exemple celles des timers .; alors que dans lembarqué normal , notre  Linux  va tout gérer..

 Un exemple pour illustrer qu'on ne peut pas gérer  une appli temps réel  avec linux tel quel  :

 Par exemple ,  toutes les dix secondes  notre appli  acquiert des mesures ou des positions d'organes.. d'une station distante par le réseau de communication ( la routine  ) l'opérateur envoie une commande  : avant de l'éxécuter on va la relire et la comparer avec celle qu'on a envoyé.. c'est bon !  on envoie la validtion, c'est pas bon il faut invalider la télécommnande tout suite.. mais c'est la même interruption hard du coupleur de communication,  sauf qu'elle va lancer des tâches soft de priotrités différentes , mais  on attend pas d'avoir fini une tâche avant de lancer une autre tâche  plus priotaire et lorsque celle là est finie, le sched  relance l'autre là où elles s'était arrétée en restaurant le contenu des registres au moment de l'interruption..qu'on a sauvegardés dans un zone mémoire réservée..

 idem en temps normal lorsque tout se passe bien que l'usine  ronronne en régime de croisière , on lit les positions de tous les organes toutes les x secondes,  mais si on veut modifier le  régime de fonctionnement,d'une machine  on va faire de l'asservissement de position super précis et lire sa position toutes les 10 millisecondes   et envoyer des ordres  gros au début , et de plus en plus fins au fur et à mesure que la machine approche de la position  souhaitée pour ne pas dépasser  la position de consigne, à cause de  l'inertie du système qu'on pilote, puis la ramener trop loin, repartir dns l'autre sens  et faire du pompage  incessant autour de la position de consigne .  

Mais c'est beau à voir marcher..  :Very Happy: 

 Pour le temps réel il reste eCos et RTAI, parce que RTLinux a arrété son développement en GPL au noyau 2.4 et commercialise la suite pour le noyau2.6 après bien avoir profité des développeurs bénévoles de  Linux pour mettre au point leur "machin"..

 Ce qu'on peut faire avec le temps réel dans les applications que je connais c'est  :

 - de l'automatisme  ( sans interet , j'ai rien à automatiser  chez moi même pas des volets électriques..) 

-  de la régulation :  

par exemple au niveau de la maison  : le chauffage, il y a des thermostats, mais on peut améliorer tout ça, le rendre plus convivial et  pilotable à distance par internet..  ( puis la régul de température avec des  radiants et des concteurs d'appoint, qui ont chacun leur thermostat , c'est pas triste..)

On trouve aussi toutes sortes de capteurs à raccorder sur  ces cartes ( que ce soit en numérique ou en analogique ) et à des prix très intéressants..  

Autant la régulation analogique c'est ch....   :Embarassed:    à mettre au point et de calculer les composants et de faire les réglages, autant  en numérique c'est simple et en plus on peut changer les lois facilement dans des situations particulières..sans faire une usine à gaz avec plein de composants et de relais etc.. 

On peut faire du traitement intelligent de capteurs, pour détecter les pannes, permanentes, intermittentes, travailler avec deux capteurs , ou un seul si l'autre daikonne. On peut faire du filtrage numérique sur les capteurs, on peut linéariser leur courbe de réponse.etc.. etc.. .

 - du traitement de signal ( n'importe quoi : son, vibrations, déplacements, force  )  

avec des convertisseurs analogiques numériques ( il y en a qui sont inclus dans les micro-processeurs ) mais pour faire des calculs , il faut une période d'échantillonage très  précise : si on a défini 10 ms, c'est pas une fois 8 et une autre fois 12 parce qu'il y a une appli qui traine..   

On fait bien un peu ça dans le PC, pour les cartes son et les cartes Tv : car il faut bien se synchroniser sur les  signaux de fin de ligne et de fin de trame  ,  c'est pour ça que parfois c'est confus entre le multitache  et le temps réel. 

Mais parfois ça coince et  l'image est figée pendant une demi seconde, et  c'est la salade interne des interruptions du PC, alors que le temps réel , c'est vu de l'application. mais si on peut affecter des interruprtions à chaque carte, on ne peut pas intercaler des tâches soft de l'appli entre deux interruptions hard , ni intercaler des interrupions externes de l'application entre les autres..

 dans les procs, le système d'interruption a souvent deux modes de fonctionnement : normal interupt ou fast interrupt : je pense que c'est ce qui correspond à l'option preempted ou pas dans la conf du kernel., mais c'est un truc que je découvre..  je n'ai vu que de l'hyperfast interrupt.. 

 - On peut faire  des asservissements de position et ça  va bien avec la robotique..il existe de la robotique iudique, pas trop chère, mais ce n'est pas mon  truc et mes enfants sont grands..

 eCos ça m'a paru moin bien que  RTAI..

 Ce qui m'a plu dans RTAI , c'est qu'on peut le coupler avec  un logiciel de simulation et de modélisation Opensource  SCICOS(   [url]http://www.scicos.org/ [/url] avec la version  RTAI Lab : 

https://www.rtai.org/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=8&MMN_position=23:23

https://www.rtai.org/RTAILAB/RTAI-Lab-tutorial.pdf

 Ca c'est d'enfer !  ( c'est l'équivalent de Mathlab et Symulink en version commerciale, mais un peu plus convivial au niveau de l'utilisation et de la doc..).

 Ca permet de simuler les sytsème qu'on va piloter, ainsi que notre appli temps réel pour la valider avant de la programmer, et de la tester en réel sur le système..  et après si onréalise vraiment le système  pour l'utiliser , on doit le refaire avec RTAI normal.

----------

## kwenspc

 *Jacqueline wrote:*   

> 
> 
>  Open Embedded ,  j'ai parcouru le site et je n'ai rien vu qui ressemblait à du temps réel : autrement dit un "scheduleur"..
> 
> 

 

Je précise là encore, OE étant une méta-distribution c'est au dev de créer sa config avec les patchs qu'il souhaite (ceux pour le noyau pour avoir du RT ou autre, et ceux au softs si besoin). 

Euh sinon même dans un OS non-RT y a un scheduleur (mais qui n'a pas, contrairement à un scheduleur RT, de contrainte par rapport au temps, genre garantir un temps maximum pour l'exécution de chaque appel système)

 *Jacqueline wrote:*   

> 
> 
>  eCos ça m'a paru moin bien que  RTAI..
> 
> 

 

Là encore petite précision, eCos est complètement indépendant de Linux. Comme dit sur le site: "eCos is not related to the Linux operating system".

Bon après j'y connais rien côté RT pour pouvoir juger des différences entre eCos et RTAI. (je suis sûr d'une chose: eCos est plus orienté pour de toutes petites cartes dédiées, amha. Mode console, sans UI sans rien, voir même mono-processus si on le souhaite)

----------

