yodalesage a écrit 7 commentaires

  • # réponse à question etrange

    Posté par  . En réponse au message priorité kernel thread vs user thread. Évalué à 3.

    L' application embarqué sur laquelle je travaille utilise un driver qui utilise une requeste irq ce qui inclut un kernel thread.
    De plus cette application à l'obligation hiérarchiser ces threads. Certain thread comme la sauvegarde, la gestion d'acquisition doivent absolument être plus prioritaire que l'ihm. Et ça ce n'est qu'une petite partie. Enfin le driver en question est le driver de base de l'acquisition donc comme les thread acquisition coté USER il doit aussi être prioritaire vis à vis d'autre thread comme L'IHM (d'ou la question un thread kernel vis à vis d'un thread user).

    L'idée à la base était de tous passer l'application en mode SCHED_FIFO (coté user) ce qui permettait de contrôler complètement la hiérarchisation. Mais ça ne marchais pas exactement comme je le souhaitais si l'ihm avait un gros travaille je voyais que l'acquisition flanchait.Au début j'ai cru à un problème d'inversion de priorité avec les mutex mais ce n'était pas cela. Et c'est en regardant le driver d'acquisition (que je n'ai pas conçu) que j'ai compris lui aussi utilisait un thread. Et c'est de la que sont venu toutes mes questions. Donc je pense que le problème vient de cette creation de thread et de ce changement de priorité tardif. Mais j'ai résolu autrement mon problème en mettant tous les thread de très faible priorité en mode SCHED_OTHER. Mais bon je posais toutes ces questions pour vraiment sur. Et c'était aussi pour ma culture personnel.
    Merci de ta réponse bonne journée.
    Yodalesage.

  • [^] # Re: suite irq sauvegarde

    Posté par  . En réponse au message IRQ gpio sauvegarder pendant une disable_irq comment faire pour les reseter avant un enable_irq. Évalué à 1.

    bonjour,
    Déjà merci à tous pour votre aide
    Comme je le disais je n'ai pas encore le fpga. Mais j'ai suivi vos conseil et je me suis adapté à mon environnement. J'ai eu plusieurs problème mais en gérant mieux mes spin lock ainsi que mes couple disable irq et enable irq (et oui faut pas oublier que si on fait deux disable_irq il faut bien faire deux enable irq ). En suivant le conseil de teddyredm3cl (je regarde toujours l'état de la pin etat fifo à la fin de l'étape 2).
    Tout semble bien fonctionner.
    Merci encore
    Et bonne journée.
    yodalesage

  • [^] # Re: suite irq sauvegarde

    Posté par  . En réponse au message IRQ gpio sauvegarder pendant une disable_irq comment faire pour les reseter avant un enable_irq. Évalué à 1.

    Bonjour
    Je suis d'accord avec toi normalement il n'y de queue je comprend pas pourquoi j'en ai deux. Peut être ai je mal vu à revoir ce point peut etre que ça cache quelque chose.

    Sinon si cela me pose problème d'avoir une it sauvegardé. Je suis en flux tendu avec le fpga en faite il me transmet des images. Je transfert toujours la même quantité de donnée 20 lignes par 20 ligne je n'ai aucune solution pour savoir quel quantité il reste dans la fifo à vider (c'est toujours 20 ligne). Donc si j'ai
    des its sauvegardé je crois qu'il y a 20 lignes à vider alors que c'est pas vrai.

    Je sais pas si j'ai bien expliquer mais voilà mon problème…….

  • # suite irq sauvegarde

    Posté par  . En réponse au message IRQ gpio sauvegarder pendant une disable_irq comment faire pour les reseter avant un enable_irq. Évalué à 1.

    Au final ce que je souhaite faire transferer des donnés via un bus eim entr un fpga et un imx6dl
    En utilisant le sdma du imx6.
    Pour l'instant je n'ai pas le hard du fpga.
    Le fpga me donnera des top d'une fifo à vider via une pin out. Cette pin out en faite représente quand le niveau de remplissage de moitié (niveau threashold) est arrivé dans la fifo. Donc l'idée mettre cette pin out en temps qu'irq et lorsqu'elle à état bas transférer les données.
    Il est tout à fait possible dans ce cas que lorsque le micro lis les données à travers le bus eim le niveau threashold soit de nouveau à bas car de sont coté le fpga reçoit lui aussi des donnée en continue. Or je ne dois pas prendre en compte cette interruption. C'est seulement qu'une fois que j'aurais fini de lire mes données que le micro pourra de nouveau regarder les its.

    Tout ça c'est le fonctionnement final. Pour l'instant je simule tout ça en faisant un transfert en interne d'une mémoire à une autre (comme un memcpy mais à travers le sdma). Pour etre plus explicite on va dire que j'ai un thread fpga (simulation) qui ecrit des données dans une zone mémoire kernel à travers mon module puis qui bouge une pin out qui est connecté à la pin out threashold. De l'autre coté j'ai un thread ReadData qui lui est en attente bloquante sur le read de mon module. Donc à chaque fois que je fais bouger la pin out je recois bien les irq dans mon module et le transfert ce fait bien. Pour faire des teste j'ai volontairement fais bouger cette irq pendant que les it était masqué et c'est la que j'ai vu le problème.

    Je sais pas si j'ai bien été claire moi voilà mon problème donc oui je suis vraiment obligé de nettoyer les it avant de les reconnecter.

    Merci d'avance

  • # merci pour toutes ces info

    Posté par  . En réponse au message système multi thread vs multi process dans un système multi core. Évalué à 1.

    Merci à vous tous pour toutes ces info très utiles. Nous avons finalement opter pour du multi thread d'autant que nous portons une appli d'un os temps réel appelé lepton vers linux.
    Merci à tous.

  • [^] # Re: Mon feedback

    Posté par  . En réponse au message choix micro (puissance utile) pour linux embarqué. Évalué à 1.

    Merci d'abord pour ta réponse, effectivement certaine questions ne peuvent pas avoir de réponses. Mais en faite ce que je recherche c'est un retour d’expérience sur l'utilisation de linux embarqué avec une ihm évolué à travers un écran VGA et qu'elle puissance a été nécessaire .
    Et suivant la puissance micro qui a été choisis. A t'il fallut optimisé l'affichages? Est ce que le reste de l'application hors affichage n'a t'il pas été trop ralenti.

    Par contre je te rejoint totalement sur l'évolution de la famille imx6 c'est un gros atout pour choisir cette base.
    Maintenant j'ai aussi des contraintes de coût et de conso.

  • [^] # Re: je vais dire une betise mais...

    Posté par  . En réponse au message choix micro (puissance utile) pour linux embarqué. Évalué à 1.

    Le faite n'est pas de remettre linux en question linux tourne sur un arm7.
    Mais c'est de savoir à travers l’expérience de personnes qui ont déjà développés sur du linux embarqué avec de l'affichage et une librairie graphique évolué q'elle est la puissance dont il ont eu besoin.