[GCC] laisser une zone mémoire libre !

Je développe un système embarqué dans lequel des processeurs vont devoir communiquer : pour celà ils ont une mémoire “physiquement” partagée (DPRAM pour Dual Port RAM) qu’ils peuvent donc accéder facilement chacun de leur côté.

Là où ça se corse, c’est que cette même RAM est également la RAM principale du second processeur, pour cause de manque de resources. Alors ce que j’aimerais faire, c’est faire comprendre à mon système qu’il n’a pas le droit d’allouer de mémoire dans cette zone là pour quoi que ce soit, et moi j’irai m’occuper directement de ça en tapant dans les bonnes adresses qui vont bien !

Il me semble de “vague” mémoire que GCC (c’est avec lui que je bosse) permet ce genre de choses avec des fichiers .org et des pseudo instruction .skip … Quelqu’un connait-il ça ?

Comme il y a des gens ici qui font des trucs bien optimisés pour des plateformes bien précises (comme moi quoi :P) je pensais que peut-être ça vous dirait quelque-chose !

Merci bien !

ca va pas bcq t’aider mais là seule fois ou j’ai dus faire un truc du genre j’ai du utiliser l’assembleur. Ca m’en a dégotuer d’ailleur.

Mais en théorie si tu fais pas d’allocation dynamique de ressources (malloc) tu dois pouvoir spécifier où tu comptes mettre ton text, ton segment de mémoire partagé, ta pile etc …

Mais faudrait surtout que nous dise sous quel platform tu travailles je crois.

Je ne vais pas beaucoup t’aider mais j’ai déjà fait ça avec d’autres compilo. Avec Microtec (entre autre) on peut préciser de réserver une zone de mémoire en OFFSET par rapport à un symbole ou bien en absolu (regarder du côté .SECTION). Donc sans problème sur le principe mais encore faut-il maîtriser l’implantation. Tu n’as pas un autre moyen de dialoguer entre tes chips ? genre une boîte au lettre. J’ai fait ça aussi. Dans la phase d’init. Tu alloues une zone de mémoire (malloc) et tu communiques au travers de la BAL l’@ de cette zone à ton second CPU et zouuu. Je trouve ça plus propre.

Dis nous en plus…

[quote name=‘Longfield’ date=’ 6 Jan 2005, 11:27’]Là où ça se corse, c’est que cette même RAM est également la RAM principale du second processeur, pour cause de manque de resources. Alors ce que j’aimerais faire, c’est faire comprendre à mon système qu’il n’a pas le droit d’allouer de mémoire dans cette zone là pour quoi que ce soit, et moi j’irai m’occuper directement de ça en tapant dans les bonnes adresses qui vont bien !
[right][post=“319489”]<{POST_SNAPBACK}>[/post][/right][/quote]

Tu as un os embarqué ou juste ton application qui tourne sur tes cpu ?
Si tu as un os, c’est à lui de gérer tes allocations correctement en fonction de ta plateforme.
Tu peux aussi ajouter des mécanismes pour gérer correctement le partage de ta mémoire (soit en soft soit en hard).

De toute façon si tu n’as pas d’os et que tu as juste une appli / cpu tu peux très bien gérer la mémoire de manière explicite avec une adresse de départ codé en dur et une utilisation directe des ressources matérielles (à toi d’assurer la cohérence des données).

ils me semble que GCC te permet de specifier, a travers le crt0.s, un potentiel link script, et 2/3 "montype mavariable attribute (taqualemettrelaletruc) " de faire ce que tu cherches a faire.

Le truc, c’est que vu que tu as 2 CPU, ils va te falloir 2 Stacks, 2 scratchpads (memoire de travail) et le reste a departager entre les 2 CPUs.

La derniere fois que j’ai vu ca c’etait sur GBA entre fastram/ram et cartouche, et sur GC aussi (ils ont un memory mapping un peu bizarre).

cela dit, un peu plus de details sur ton environment (comme le disait Merlin) genre OS/pas Os/Quel OS, les CPUs utilises (ou au moins les type de cores) et le type de tache assigne a chaque CPU nous aideront plus a repondre a ta question.

(et moi, ce qui m’a degouter de l’assembleur x86, c’est l’assembleur ARM : PARCE QUE C’EST TELLEMENT MIEUX :stuck_out_tongue: )

merci les gars pour ces réponses !

Ok, alors je vais vous expliquer un peu mieux mon architecture et ça va pas mal vous éclairer je pense !

J’utilise un SoC (System on Chip) de chez Altera qui s’appelle EPXA1. En gros dedans j’ai un ARM 922 (ouais, ARM c’est tellement mieux que x86) sur lequel j’ai un OS embarqué temps réel : eCos ! Mais ce proco et cet OS on un RAM bien à eux de 64 Mo pour bosser.

Dans le même chip j’ai une FPGA dans laquelle j’ai synthétisé un processeur softcore de chez Altera, le NIOS. Sur celui-là, pas d’OS, mais un simple programme avec lequel j’interface des capteurs, fais des communications avec des microcontroleurs, et aussi des calculs de régulation (ouais, c’est pour un robot). Ce proco softcore utilise la DPRAM comme mémoire « principale » !

Les deux procos doivent communiquer et la DPRAM est le seul moyen que j’ai pour faire ça de manière efficace pour des raison d’adressage mémoire (l’ARM bosse sur 32 bits et le NIOS sur 16 → incompatibilité). Et je suis vraiment obligé d’utiliser cette mémoire car le code que le NIOS exécute lui est envoyé par l’ARM pour automatiser la procédure de démarrage du système !

En gros mon problème « recadré » est le suivant : je dois garder une mémoire pour faire une sorte de buffer boite aux lettre pour que le NIOS et l’ARM puissent communiquer dans la mémoire DPRAM qui est également la mémoire pour le NIOS.

Donc le truc c’est pour le compilateur du programme du NIOS que je dois faire ce travail (qui est en fait une version de GCC un peu tunée par Altera) ! Evidement je peux prendre des adresses fixes pour bien des choses vu que j’ai pas d’OS, mais bon il me faut quand même une pile en tous cas ! Sinon pour l’ARM, vu qu’il n’utilise pas cette mémoire et que j’en connais les adresses, il n’y a aucun problème de ce côté-là !

Merci de votre aide ! Et vive les systèmes embarqués ! :stuck_out_tongue:

Sinon, c’est vrai que l’idée de Moktar est bonne : attribuer cette zone par un malloc et ensuite la balancer … mais comment la balancer la première fois ?

Longfield> tu n’as pas de système de boîte aux lettres de comm. entre ton ARM et ton NIOS ?? comment vas-tu les faire se synchroniser ? comment vont-il dialoguer ? je suppose qu’il y a un producteur et un consommateur (en mode stable, c.a.d pas en init.) donc il va bien falloir que le producteur “prévienne” le consommateur, non ?

Sinon, tu te fais ta BAL avec une zone de 64 octets (par ex) en dure qui sert de zone d’échange (en phase d’init) et tu te fabriques un set de messages. Dans ce set de messages il y en aura un qui servira à transmettre l’@ de la ram partagée et sa taille et … etc.

Mon avis.

[quote name=‘Moktar’ date=’ 7 Jan 2005, 13:44’]Longfield> tu n’as pas de système de boîte aux lettres de comm. entre ton ARM et ton NIOS ?? comment vas-tu les faire se synchroniser ? comment vont-il dialoguer ? je suppose qu’il y a un producteur et un consommateur (en mode stable, c.a.d pas en init.) donc il va bien falloir que le producteur “prévienne” le consommateur, non ?

Mon avis.
[right][post=“319903”]<{POST_SNAPBACK}>[/post][/right][/quote]

ben vu que j’ai une FPGA et que j’aime bien le hard : je pensais faire une interruption depuis le NIOS vers l’ARM pour le prévenir que des nouvelles données sont disponibles ! Enfin ça c’est pour la théorie : maintenant, étant donné que c’est un robot et que le monde est assez “continu”, pas si grave si je perds quelques mesures, et que j’ai des timers qui vont pas mal, un petit buffer pas très profond peut aussi très bien faire l’affaire !

Mais je pense que l’interruption du NIOS vers l’ARM va bien aller, notament au début pour la séquence de démarrage pour fournir l’@ du buffer et la taille par exemple … ensuite il me faut juste une adresse fixe pour l’adresse du “buffer” de communication ainsi que sa longueur !

@Moktar : dis-m’en plus sur ta “boîte aux lettre” ça m’intéresse !

edit : je viens de contrôler : je peux bien faire des malloc avec mon NIOS donc voici ma stratégie actuelle, largement inspirée de celle de Moktar (on ne parle pas encore pour l’instant du type de communication qu’il y aura entre les deux processeurs, mais simplement qu’il y en a une et qu’elle a lieu à une adresse donnée sur une longueur de mémoire donnée) :

le NIOS réserve la longeur mémoire nécessaire à la communication dans sa RAM qui est la DPRAM avec un malloc, comme ça je suis sûr que je n’ai pas de soucis du côté du NIOS pour la pile etc … Maintenant le dernier problème à régler est de fournir cette adresse et (éventuellement) la longueur de cette zone mémoire à l’ARM : pour ce faire je mets ces deux informations à une adresse fixe en mémoire. D’où ma question : comment garantir que cette adresse ne va pas être bouffée, par exemple par mon malloc et qu’elle soit la même à chaque compilation (ce qui revient au même que la question initiale du post, sauf sur une bien plus petite zone de mémoire, ce qui est beaucoup mieux pour le comportement du NIOS) !

Merci

Oui tu as raison, une IT c’est ce qu’il faut faire. Tu n’as pas besoin d’une IT ARM vers NIOS (je pense que si) ?

Pour la BAL, en fait c’est une zone de mémoire fixe qui te servira pour faire discuter les deux appli tournant sur les CPUs différents. Tu n’as pas besoin d’une grosse zone. Elle pourrait être limité à un codage TLV (Type [Longueur] Valeur) x2 pour les deux sens de comm., genre (pas besoin de la longueur je pense) :

Type décrivant le message : charge à toi d’avoir différents messages. Par exemple dans le sens ARM → NIOS : Req (Type == Request, valeur==AllocRam+combien) et en retour tu aurais Type == Response avec comme valeur l’adresse de la zone allouée. Evidemment il faut avoir l’inverse (libération de cette zone).

Valeur : bah la zone « data » contenant des informations précisant le type. Dans l’exemple de la requête la valeur dans le sens ARM->NIOS est AllocRam + size et dans l’autre sens c’est « zone allouée » avec son @ (ou bien erreur avec un code).

La liste des types est limitée : Req (request), Res (Response), Evt (Event), … autre ? l’Event étant une information ne nécessitant pas de réponse (ça sert toujours)
Le contenu de la Valeur peut être codée, elle, en LTV. Si je reprends l’exemple ci-dessus Le LTV (contenu dans la Valeur, la zone data du message donc) serait:
L=lg du champ data, type=AllocRam, Value=nb d’octet

Bon, je crois que je ne suis pas clair mais je suis mort de fatigue alors je préciserai les choses au besoin. :stuck_out_tongue:

EDIT : pour la réservation d’une zone, regarde

A mon avis le plus fiable pour toi reste quand meme d’imposer l’endroit ou tu placerras ton segment de mémoire réservé à la communication.

A la base le malloc c’est util quand tu connais pas à l’avance la taille de mémoire à réserver. Exemple pour un tableau. Quand tu utilises une structure en mémoire de taille connue à chaque utilisation de ton programme un malloc ne se justifie pas du tout. C’est un peu le rouleau compresseur pour ramasser les fraises (dixit mon prof de méthode et conception de programme).

[quote name=‹ klimmrod › date=’ 8 Jan 2005, 08:58’]A mon avis le plus fiable pour toi reste quand meme d’imposer l’endroit ou tu placerras ton segment de mémoire réservé à la communication. 

A la base le malloc c’est util quand tu connais pas à l’avance la taille de mémoire à réserver.  Exemple pour un tableau.  Quand tu utilises une structure en mémoire de taille connue à chaque utilisation de ton programme un malloc ne se justifie pas du tout.  C’est un peu le rouleau compresseur pour ramasser les fraises (dixit mon prof de méthode et conception de programme).
[right][post=« 320206 »]<{POST_SNAPBACK}>[/post][/right][/quote]

Alors, pour la BAL oui il faut une zone fixe mais dans cette BAL tu peux faire en sortes de faire transiter des messages d’allocation/libération de message de façon à avoir, in fine, un espace adressable partagé entre les deux CPUs. La BAL est un tuyau de comm. qui, de cette façon, a une taille non déterminée, par le principe que ce sont des adresses de buffer que tu vas/peux y passer. Ce n’est pas une obligation et certains messages ne nécessiteront pas de buffers alloués mais restreindre la taille des données échangées : beuuurk ! en plus ça augmente la taille de la zone figée.

Ok, je suis d’accord sur le principe qu’il faut savoir adopter le dev adéquate et éviter de monter une usine à gaz m’enfin typiquement, un tuyau de comm. ne doit pas être négligé et mieux vos prévoir quelque chose de plus souple plutôt que d’être rapidement emmerdé dès qu’on veut passer un message plus gros que prévu initialement.

klimmrod> heuu il a quoi comme expérience dans l’industrie ton prof ? :stuck_out_tongue: