Discussion :

[robotzeus]

bonjour, j'aimerais débuté l'écriture d'un programme en assembleur sur orange PI mais je ne sais pas par ou commencer.

comme première objectif j'aimerais faire clignoté une led sur une Orange PI zero qui a l'avantage d’être open-hardware

mon souci c'est que je ne sais pas comment commencé et qu'elle sont les outils dont j'aurais besoin.

brièvement je pense au étape suivante (n'hésitez pas a rectifier)

(1) écriture des ligne en assembleur
(2) compilation en langage machine
(3) copie du code sur la carte SD
(4) test

idéalement il faudrait codé un compilateur sur la carte SD pour que je puisse avoir simplement a modifier un fichier texte mais la aussie je ne sais pas par ou commencé

en ce qui concerne mes compétences elle sont principalement électronique mais j'ai déja suivi des cours et TP sur les noyau et les processeur logique.

PS je ne souhaite pas utilisé d'OS pour des raisons apprentissage et de temps réel (sa évolua sans doute vers la réalisation d'un OS RT dédié dans un premier temps)
PS 2 je ne sais absolument pas commencé et je vous remercie d’être indulgent pour mon novisme passagé

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
edit : fil d'actualité pour suivre l'avancement sans tout lire (lorsque je met a venir c'est que je n'ai pas encore l'information donc si il y en as qui savens ou trouvé ca fera toujour ca en moin a chercher)

-vu la complexité du projet j'ai commencé l’écriture d'un document de travail
- les schéma récupéré et datasheet sont récupéré
- le schéma utilise un H3 comme empreinte au lieu d'un H2+, un comparatif pin a pin est en cour et un descriptif sera ajouté devant chacune des pin (en cours)
- recherche des fichier source dans la NAND h2+ (a venir)
- recherche de document complémentaire autre que schéma et datasheet (a venir)
- recherche des outils pour programmer la NAND (a venir)



Cordialement

[chrtophe]

Ben bon courage.

Il te faut déjà te documenter sur l'assembleur du CPU du Orange Pi. Il te faut ensuite connaitre le fonctionnement des communications IO de la carte.

Je te recommandes d'essayer déjà de faire un code que tu pourras lancer depuis un OS opérationnel sur le Orange Pi.

Pour ton type de besoin, on utiliserai plutôt un microcontrôleur, comme l'Arduino par exemple, et même là, on utilise le C.

[robotzeus]

en faite j'ai déja la doc du composant (l'avantage de l'orange PI étant d'etre open hardware j'ai a ma disposition toutes les datasheet du composant )
le procceseur est un arm H2+ et est facilement récuperable
les micro contrôleur je connais déja mon but n'ai pas de faire clignoté une led mais de me familiarisé avec l'environnement (une sorte d hello world)

c'est vrai qu'une étape intermédiaire faisant clignoté la led en assembleur pourrais être intéressante (je l'ai deja fait avec la Raspberry y a 2 ans mais pas avec l'orange)

en ce qui concerne la programmation assembleur sur microcontrôleur, j'ai deja l'habitude, mon souci c'est ici je dois mettre le code sur la carte SD et c'est la que je bloc et que j'aimerais bien avoir un exemple

les objectif suivant seront :
-la création de librairie de fonction (implémentation d'un langage de niveau intermédiaire shell C C2 ou autre)
-affichage graphique sur E-ink (pas besoin de rafraichissement, donc ideal pour travaillé sur du temps réel
-utilisation du clavier sourie
-utilisation des support de stokage
-utilisation du réseau
....

PS je ne dit pas que je ferais tous tous seul, le but etant surtout de mettre en pratique les compétences,

[Vincent PETIT]

Salut,
Comme dit par Christophe la doc du micro ARM n'est pas suffisante, il te faut le schéma électronique de tout le reste.

Il faut que tu saches comment tout est connecté et où est ce que c'est connecté (sur quels port(s) de ton micro) ensuite tu vas devoir éplucher la datasheet du micro pour trouver les modes de boot que ton micro supporte. Bien souvent ils peuvent booter sur de la mémoire eMMC, SD, Flash, NAND etc... et parfois le micro possède un peu de mémoire pour y mettre le bootloader et qui ira faire pointer le compteur programme du micro dans la SD card par exemple. Enfin il faudra regarder tous les registres a configurer pour initialiser toute l’électronique correctement avec le risque de cramer quelque chose pendant les essais. A moins que tout marche du premier coup

Si vraiment tu veux démarrer de zéro tu es partie pour un long temps d'étude avant de pouvoir coder la première ligne d'assembleur.

[robotzeus]

Merci ,
si j'ai choisi l'orange PI c'est parce que tout est disponible schéma datasheet.... d'ou le terme Openhardeware que j'ai utilisé.

Aprés j'avoue que je souhaite un coup de pousse pour démarrer. car il y as bien quelqu'un ici qui a plus de compétence que moi sur le sujet


Les objectif étant multiple. :
-mettre en pratique les compétences
-crée une communauté francophone sur le sujet
-réalisé ses propre cartes de développement .... (la je pourrais un peu plus aidée puisque c'est mon cœur de compétences)

[Vincent PETIT]

Alors le problème c'est qu'en souhaitant partir de zéro on ne peut pas parler de coup de pouce ou alors il faut que celui qui t'aide ait un très gros pouce.

Comme tu as visiblement déjà bosser avec des microcontrôleurs tu sais que lors du démarrage tous les registres sont dans un certain état, qui est toujours l'état de sécurité. Les broches d'entrées/sorties sont par défaut en entrée, l'horloge par défaut est celle interne au micro même si tu as un quartz dehors, les DMA sont désactivés ainsi que tous les périphériques alternatifs. Ça veut dire que tu as tous les registres internes a configurer en fonction du hard externe. Mettre les broches du micro en entrée lorsqu'elles sont reliées à des sorites du hard externe et vis versa, régler l'horloge sur le quartz externe de 24MHz (sur la Orange Pi) puis configurer la PLL pour augmenter fortement la fréquence interne etc... et quand je dis etc... ça peut aller jusque 100 registres et dans chacun d'eux il faut comprendre ce que fait chaque bit et comment il fait réagir le micro

Pour ça, y a pas d'autre choix que de lire la doc et pour info la doc d'un SITARA comme sur la Beagleboneblack fait 5000 pages

C'est possible mais celui qui va t'aider est partie pour un coup de pouce qui va durer 1 an ou plus suivant ces compétences.

Regarde le schéma de la carte, il y a déjà plein de question a se poser sur la mémoire flash qui est reliée au micro. Il faut éplucher la datasheet du micro pour savoir si par défaut il est configuré pour aller chercher son programme dans la mémoire flash (fort probable) ensuite, qui y a t-il dans cette flash ? Moi je ne serai pas surpris d'y trouver U-Boot, le bootloader Linux, qui démarre le micro, le configure et lui dit d'aller chercher son programme principale dans une carte SD et à une certaine adresse. En démarrant de zéro peut être qu'il faut commencer ton premier programme dans cette mémoire Flash ? Tout ça il faut aussi y regarder en plus du hard et de la configuration de chaque périphérique du micro (sachant qu'on parle d'un ARM Cortex A7 et pas du tout des petits ARM Cortex Mx comme les STM32, SAMD ou MSP432)

[Kannagi]

en ce qui concerne la programmation assembleur sur microcontrôleur, j'ai deja l'habitude,

Enfin le ARM Cortex-A7 est plus complexe qu'un simple Arduino par exemple
Si je conseillerai le C sur ce genre de bécane , c'est parce que le ARM Cortex-A7 est un processeur dit in order Superscalaire, ça veut dire que si tu code en assembleur dessus (et que tu veux pas avoir les performances réduites par 16 !) , il faudra alors te soucier de la pipeline CPU et des instructions compatible entre elles , et un petit changement de ton code peut t'obliger à re-écrire une bonne partie parce que la pipeline à était chamboulé pour atteindre la sacro sainte 2 instructions/cycles , par contre tu peux bien sur ne pas t'en soucier et donc fort probable que ton code fera du 1 instruction/8 cycles :p
Ou alors tu prend un bon compilo qui te fait ça , et au pire écrire les parties critiques en assembleur (mais par expérience , c'est long et fastidieux sur un proc in order , 100-200 lignes peut te faire des jours / une semaine de boulot).
Bien sur il y'a aussi une mémoire cache à optimisé , et les processeurs ARM ont tendance d'avoir une ligne de cache sur 64 octets (contre 32 sur x86)

Je précises que sur un AVR atmel tu n'as ni mémoire cache , ni pipeline donc forcément assez facile (surtout que tout fais 1 cycle par défauts sauf le mul et le jmp ) et sur du x86 , c'est le CPU qui optimisera la pipeline de façon automatique donc là aussi tu ne dois pas t'en soucier.

Je rejoins bien sur mes collègues , je rajouterai que bon il faudra juste apprendre à lire toutes les I/O , à bien connaître ta memory map et ensuite exploité tout ça , bref ça demande du temps j'imagine vu qu'on a pas affaire à une petite machine qui est avec seulement 20-30 I/O pour contrôler le tout

[robotzeus]

Alors le problème c'est qu'en souhaitant partir de zéro on ne peut pas parler de coup de pouce ou alors il faut que celui qui t'aide ait un très gros pouce.

Comme tu as visiblement déjà bosser avec des microcontrôleurs tu sais que lors du démarrage tous les registres sont dans un certain état, qui est toujours l'état de sécurité. Les broches d'entrées/sorties sont par défaut en entrée, l'horloge par défaut est celle interne au micro même si tu as un quartz dehors, les DMA sont désactivés ainsi que tous les périphériques alternatifs. Ça veut dire que tu as tous les registres internes a configurer en fonction du hard externe. Mettre les broches du micro en entrée lorsqu'elles sont reliées à des sorites du hard externe et vis versa, régler l'horloge sur le quartz externe de 24MHz (sur la Orange Pi) puis configurer la PLL pour augmenter fortement la fréquence interne etc... et quand je dis etc... ça peut aller jusque 100 registres et dans chacun d'eux il faut comprendre ce que fait chaque bit et comment il fait réagir le micro

Pour ça, y a pas d'autre choix que de lire la doc et pour info la doc d'un SITARA comme sur la Beagleboneblack fait 5000 pages

C'est possible mais celui qui va t'aider est partie pour un coup de pouce qui va durer 1 an ou plus suivant ces compétences.

Regarde le schéma de la carte, il y a déjà plein de question a se poser sur la mémoire flash qui est reliée au micro. Il faut éplucher la datasheet du micro pour savoir si par défaut il est configuré pour aller chercher son programme dans la mémoire flash (fort probable) ensuite, qui y a t-il dans cette flash ? Moi je ne serai pas surpris d'y trouver U-Boot, le bootloader Linux, qui démarre le micro, le configure et lui dit d'aller chercher son programme principale dans une carte SD et à une certaine adresse. En démarrant de zéro peut être qu'il faut commencer ton premier programme dans cette mémoire Flash ? Tout ça il faut aussi y regarder en plus du hard et de la configuration de chaque périphérique du micro (sachant qu'on parle d'un ARM Cortex A7 et pas du tout des petits ARM Cortex Mx comme les STM32, SAMD ou MSP432)

merci je vais regardé de ce coté en revanche cela me fais soulevé 2 question.
esce que les 600 page de datasheet son suffisante il il me faut des d'autre document (et dans ce cas quel document me manque t'il)?
ensuite en ce qui concerne le schema il est indique que la Nor flash est en option mais c'est effectivement la Nand du H2+ qu'il faut que je programme.
d'ou les question :
-quel outil doit-je utilisé ?
- es-que je dois vraiment modifier cette partie si mon but est de "simplement " faire clignoté une led sans m'occupé du démarage?
-y a t'il des source lisible concernant ce qu'il y as d’inséré dans la nand de l'Orange ?

je pose les question mais je vais aussi cherché les réponses si au fur et a mesure

[robotzeus]

Enfin le ARM Cortex-A7 est plus complexe qu'un simple Arduino par exemple
Si je conseillerai le C sur ce genre de bécane , c'est parce que le ARM Cortex-A7 est un processeur dit in order Superscalaire, ça veut dire que si tu code en assembleur dessus (et que tu veux pas avoir les performances réduites par 16 !) , il faudra alors te soucier de la pipeline CPU et des instructions compatible entre elles , et un petit changement de ton code peut t'obliger à re-écrire une bonne partie parce que la pipeline à était chamboulé pour atteindre la sacro sainte 2 instructions/cycles , par contre tu peux bien sur ne pas t'en soucier et donc fort probable que ton code fera du 1 instruction/8 cycles :p
Ou alors tu prend un bon compilo qui te fait ça , et au pire écrire les parties critiques en assembleurs (mais par expérience , c'est long et fastidieux sur un proc in oder , 100-200 lignes peut te faire des jours / une semaine de boulot).
Bien sur il y'a aussi une mémoire cache à optimisé , et les processeurs ARM ont tendance d'avoir une ligne de cache sur 64 octets (contre 32 sur x86)

Je précises que sur un AVR atmel tu n'as ni mémoire cache , ni pipeline donc forcément assez facile (surtout que tout fais 1 cycle par défauts sauf le mul et le jmp ) et sur du x86 , c'est le CPU qui optimisera la pipeline de façon automatique donc là aussi tu ne dois pas t'en soucier.

Je rejoins bien sur mes collègues , je rajouterai que bon il faudra juste apprendre à lire toutes les I/O , à bien connaître ta memory map et ensuite exploité tout ça , bref ça demande du temps j'imagine vu qu'on a pas affaire à une petite machine qui est avec seulement 20-30 I/O pour contrôler le tout

je suis totalement conscient de l'exercice déja a 16ans je m'amusais a réalisé des fonction édition et autre fonction avec des porte logique.
ensuite c'est le démarrage qui sera le plus long car je compte bien utilisé des macro et faire un générateur de code a coté. automatisé certaine partie.
En terme de planning j'aimerais bien pouvoir faire mon premier clignotement d'ici Juillet.

j'ai pour le moment une formation en électronique et en mécatronique. je suis en train d'ajouté un double cursus ingénieur informatique a mon bagage. a terme j'aimerais bien développé des appareil de réalité augmenté avec une niveau de programmation bas niveau

[chrtophe]

Pour brancher un clavier/une souris, sans OS,il te faut maitriser les communications USB (à moins que tu utilise un autre type de connectique plus simple, je ne connais pas le orange Pi.. Pour communiquer avec un écran, si c'est un afficheur de type 7 segments ça reste envisageable, pour une communication avec un écran, un énorme travail.

Sans OS, tu pars sur un truc sans fin.

[robotzeus]

Pour brancher un clavier/une souris, sans OS,il te faut maitriser les communications USB (à moins que tu utilise un autre type de connectique plus simple, je ne connais pas le orange Pi.. Pour communiquer avec un écran, si c'est un afficheur de type 7 segments ça reste envisageable, pour une communication avec un écran, un énorme travail.

Sans OS, tu pars sur un truc sans fin.

c'est bien ca l'idée (et y augmenté la complexité progressivement)
l'Orange PI c'est comme la Raspberry niveau entrée sortie par contre c'est plus open que la rasberry, le seule avantage de la Raspberry c'est le faite qu'il y ai une grande communauté

concernant l'orde des etapes a franchir elle sont les suivant
etape 1 faire clignoté une led
etape 2 faire allumé la led suite a l'appuit sur un poussoir
etape 3 commandé une E_INK 3 couleurs
etape 4 intégré des fonction texte
etape 5 lecture du clavier via le protocole HID
etape 6 géré l'espace mémoire de la carte SD
etape 7 utilisation des interruption et des piles
etape 8 émission de son
etape 9 utilisation de périphérique de stockage USB
etape 10 enregistrement micro sur périphérique USB
etape 11 envoie et réception de message sur le réseau Ethernet
etape 12 faire en sorte que les ligne de code en C puisse être utilisé

j’exclue l'utilisation du Wifi au profit d'une communication LIFI
j’exclue l'utilisation d’écran dynamique (avec l'E-Ink j'ai besoin d’envoyé seulement les nouvelles information et s'est plus écologique)

en terme de planning j'aimerais me fixé 18 mois pour faire les 12 étape

[Delias]

Bonsoir à tous

Je rejoins à 100% Kannagi, ce travail est à faire en C pas en assembleur!
Sans OS, le travail est quasi identique avec la nécessité de traiter l'entier du démarrage du micro en configurant à la pelle les registres. Et un compilateur actuel sera, de manière certaine, un meilleur optimisateur qu'un développeur seul.

Et déjà pour le démarrage c'est le datasheet du micro qui fait fois, dans la doc tout devrait être décrit!
J'ai une petite expérience avec deux DSP de Ti et pour le forum j'ai déjà consulté la doc d'un ARM simple où le boot est encore bien décrit. La suite c'est de tête pas envie de retourner chercher:

Il peut y avoir plusieurs possibilité de boot cela est configuré soit par quelques pattes de la puce, soit par des fusibles internes (un fusible c'est juste un bit en EEPROM).
Sur un mémoire flash c'est généralement direct, le micro commence à exécuter les instructions à partir d'une adresse donnée. La première tâche c'est de copier la base de la flash dans la RAM pour aller plus vite. Ce code devra ensuite être capable d'accéder à la Flash pour charger les sous-programmes à faire tourner. Sur une carte SD c'est pareil sauf qu'il peut y avoir la vérification d'une signature en début de la zone lue (pour éviter de démarrer sur une carte n'ayant pas un code exécutable sur le micro en question).

La doc de 600 pages ce n'est pas au complet, c'est les spécificités du micro, mais il doit y avoir plusieurs renvois vers des docs plus généraliste couvrant les sous-systèmes de la famille de microprocesseurs (c'est assez généralement une docs par périphérique interne, sauf les plus basiques). Par contre il peut y avoir des périphériques non documentés où le constructeur se contente de fournir un driver pour tel et tel OS embarqué... (et là inutile de dire que cela sera très difficile voir impossible)

Bonne suite

Delias

[Vincent PETIT]

En effet, 600 pages ne peuvent pas expliquer comment fonctionne le micro. Voir par exemple la vraie doc d'un SITARA AM3358 de chez Texas Instuments (c'est le micro ARM Cortex A8 de la Beaglebone Black)
http://www.ti.com/lit/ug/spruh73p/spruh73p.pdf

Il se peut que Allwinner ne donne pas accès à sa datasheet comme Broadcom au début du Raspberry et c'est le cas de la grande majorité des fabricants exotiques de SoC ARM. Raspberry était open hardware dans le sens du schéma mais pas du tout d'un point de vu du SoC. Broadcom n'avait pas ouvert la doc de la partie vidéo mais en échange il fournissait un driver et depuis il semblerait que toute la doc soit accessible (je n'ai pas vérifié)

en terme de planning j'aimerais me fixé 18 mois pour faire les 12 étape

C'est beaucoup trop ambitieux si tu ne maîtrises pas le processeur et pire encore si tu démarres de zéro en assembleur.

Pour te donner une idée ; regarde ce sujet https://www.developpez.net/forums/d1...2l4-blink-led/ c'est un membre qui voulait faire clignoter une LED en bare metal et en langage C sur un micro ARM Cortex M4 mais regarde plus attentivement le poste #6 où je montre comment on configure directement les registres du micro. Et bien même si je sais très bien configurer un micro ARM Cortex M à partir de rien, je suis sur et certain qu'il me faudrait au moins un an en bare metal et en langage C pour faire clignoter un LED sur un ARM Cortex A car le niveau est plus haut (c'est pas vraiment ça le soucis) mais surtout il y a tellement à lire/comprendre/essayer/configurer qu'il me faudrait beaucoup de temps pour y arriver. Et dit toi bien que le moindre petit exemple comme faire clignoter une LED va demander au préalable des 100aine de lignes de codes juste pour démarrer correctement la carte.


Avantage :
Te lancer dans une telle aventure sera très formateur, c'est sur et certain. Je ne te dissuade donc pas d'essayer.

Inconvénient :
Pour un premier essai une telle plateforme et trop complexe, le plus grand risque est de ne jamais parvenir à faire clignoter une LED car au moindre registre mal configuré, rien ne fonctionnera. Il faut bien intégré ça.



Si demain je veux apprendre à maçonner en réalisant un pont routier, c'est sur que ça va être formateur mais le plus grand risque c'est au final de ne jamais terminer le pont. Je parle d'expérience car quand j'avais 17 ans j'ai voulu faire un compilateur C pour un vieux microcontrôleur Motorola 68HC11, j'ai acheté un super bouquin très épais et je me suis lancé dans l'écriture en C, d'un compilateur C pour 68HC11. J'ai rarement autant appris en si peu de temps, la théorie des arbres, les analyses lexicales et syntaxiques via les outils Yacc et Bison, des tas d'algorithmes dont certain assez balaises mais je n'ai jamais terminé ce compilateur car la montagne était bien trop haute pour ma si maigre expérience.

[bifur]

tu as une liste d'étape bien arrêté mais je pense qu'il vas falloir en ajouter quelques unes, par exemple l'étape 9
9.1 tu vas devoir apprendre comment fonctionne le protocole USB
9.2 tu vas devoir apprendre comment fonctionne le contrôleur USB
9.2 tu vas devoir apprendre a lire un secteur sur disque USB
9.3 tu vas devoir apprendre a détecter le partitionnement d'un disque
9.4 tu vas devoir apprendre le fonctionnement du system de fichier FAT (au moins une des variantes)
9.5 tu vas devoir apprendre a lire/écrire un cluster FAT
9.6 tu vas devoir apprendre a lire/écrire une entrée de de la table FAT
9.7 tu vas devoir apprendre a lire/écrire les métadonnée d'un fichier sous FAT
9.8 tu vas devoir apprendre a créer un ficher sous fat
9.9 tu vas devoir apprendre a lire/écrire dans un fichier sous FAT

j'ai pas faite ça pour un disque USB mais pour un controleur IDE et je peut dire que ça prend pas mal de temps (et que toutes les étapes sont utiles)

je ne saurais pas dire combien de temps ça vas te prendre mais je pense que 18 mois c'est très optimiste

le meilleur moyen de simplifier tout ça c'est d'utiliser une sorte d'os pour cette carte, vu que tout semble open pour cette carte ça doit être trouvable

[robotzeus]

La doc de 600 pages ce n'est pas au complet, c'est les spécificités du micro, mais il doit y avoir plusieurs renvois vers des docs plus généraliste couvrant les sous-systèmes de la famille de microprocesseurs (c'est assez généralement une docs par périphérique interne, sauf les plus basiques). Par contre il peut y avoir des périphériques non documentés où le constructeur se contente de fournir un driver pour tel et tel OS embarqué... (et là inutile de dire que cela sera très difficile voir impossible)

Bonne suite

Delias

j'ai beau cherché (ou mal cherché) je n'arrive pas a trouvé de doc supplémentaire. En revanche contrairement a la raspberry PI il n'y as pas de périphérique non documenté, et c'est bien pour cela que j'ai choisi cette plateforme.

Je conçoit parfaitement le concepts d'optimisation du C. mais cette optimisation n'est pas absolue et je souhaite resté au plus proche de la machine quitte a réalisé mon propre compilateur.

après si il y a la possibilité de faire ce que je veux en C(etape 1) et que derrière je puisse lire le code assembleur généré je pense que cela pourrais me faire gagner du temps car je partirais d'un exemple qui fonctionne pour en comprendre le fonctionnement .

Bien sur je ne vais pas tout écrire en assembleur dans le sens ou je vais utilisé des macro et sans doute une application après l’étape 3 pour aidé a coder en comptant les cycle utile.
De plus arrivé a se niveau ont pourra commencer a se mettre a plusieurs pour codé des fonctions. (je souhaite bien documenté les 3 première étapes car a partir de la je voie pas mal d'amateur de robotique se lancé dans l’aventure)

[robotzeus]

je ne suis pas totalement novice j'ai deja programmé (a petite dose) du microchip et utilisé le protocole HID pour faire passé le microcontrôleur pour un clavier. j'ai fait de l' ATMEL de l'arduino du 68HC11 et 68HC12, du FPGA altera et Xilinx et fait des TP sur DSP TMS320C.
j'ai 10 ans d'experience en R&D électronique et je suis actuelement de cours au cnam pour passé plusieurs diplôme d’ingénieur ( 9 UE validé l'année dernière, 9 UE validé au premier semestre de cette année et j’espère encore en valider 9 au second semestre).

En gros je suis en phase accéléré apprentissage et je veux profité de l'occasion pour mettre en pratique les cour de noyau et réseau que j'ai passé.
Je suis conscient de la difficulté engendré par le faite que personne ne se lance dans se genre sentier aventureux et que par conséquence c'est tres peu documenté mais je suis également certain qu'une fois les 2 premiere étape franchie le sentier se transformera en route pour de nombreuse personnes

@bifur si j'utilisais un OS il n'y aurais plus de probleme , je suis électronicien mécatronicien, je ne fait pas de programmation haut niveau et je n'ai aucun intérêt de faire tourné un OS dessus, ma conception de la choce c'est qu'il faut 2 carte dans un système , une pour faire l'interface utilisateur et l'autre pour faire fonctionné les différent organe d'une machine en temps réel sans que cette dernière ne soit pourrie par les requête utilisateur. a cela je rajouterais des µC et des CPLD pour servir de tampon

[chrtophe]

je ne suis pas totalement novice j'ai deja programmé (a petite dose) du microchip et utilisé le protocole HID pour faire passé le microcontrôleur pour un clavier.

Ca c'est un point positif. Mais de là à être capable de recréer un driver disque USB fonctionnel...

je veux profité de l'occasion pour mettre en pratique les cour de noyau et réseau

Dans ce cas, il te faut utiliser un noyau justement.

Je serais toi, je commencerais à utiliser un OS, quitte à t'en abstraire petit à petit. Cela te permettra si tu sèches de passer sur une autre partie et revenir sur celle bloquante ultérieurement et ne pas te décourager.
Tu auras l’avantage de pouvoir utiliser des pilotes existants en parallèle aux tiens le temps du développement et même de t'inspirer du code source des pilotes existants pour comprendre comment ça marche, surtout que tu risques de manquer de docs comme indiqué.

Commences par faire clignoter une LED depuis un OS, puis d'afficher quelque chose avec les fonctions systèmes, puis en direct, etc.

Tu auras déjà une idée de l’ampleur du travail.

[Kannagi]

Je conçoit parfaitement le concepts d'optimisation du C. mais cette optimisation n'est pas absolue et je souhaite resté au plus proche de la machine quitte a réalisé mon propre compilateur.

Est ce que tu as lu mon pavé sur ARM Cortex A7 ?
J'explique bel et bien pourquoi ton expérience sur des proc comme le ATMEL /68HC11 est bien mais assez inutile sur un proco comme celui là
Faire un compilo C sur ce genre de plateforme , c'est pas mettre des add, mov , sub , cmp , et voilà fini
Si tu veux mon avis d'expérience , les compilo C optimise déjà assez bien , par exemple ils utilisent pas mal de technique comme :
-le dépliage de boucles
-precalculer au possible
-réduire les instructions
-privilégier les instructions SIMD
-ainsi de suite

ah et une autre chose que j'ai remarqué sur les compilo C , c'est qu'il a tendance à optimiser la mémoire cache.
(et c'est vraiment pas rien comme optimisation).

Donc tu devra faire tout cela en terme d'optimisation (et c'est que le début).
Je ne vais pas réécrire mon pavé sur la pipeline , mais franchement ça change complètement ta façon d'écrire du code asm et c'est surtout super long , enfaite je n'ai jamais fait un programme full asm dessus (encore heureux ).
Oui sur des proco simple , c'est facile de faire du full asm , faire du full asm sur du AVR c'est facile les I/O sont pas complexe et pas trop nombreuse , ça ce gère encore , par contre quand on va sur des machines plus complexe il te faut un peu plus d'outils.

en faite si tu veux faire un compilo C , je pense que le mieux c'est d'utiliser clang et de remplacer LLVM par ton propre compilo , mais si tu as aucune notion sur les proco moderne et l'optimisation asm alors compte facile 2 ans de' taff (avec l'utilisation de clang)

Bien sur je ne vais pas tout écrire en assembleur dans le sens ou je vais utilisé des macro et sans doute une application après l’étape 3 pour aidé a coder en comptant les cycle utile.

Les macro en asm , ça aide effectivement à coder rapidement mais pas que , je code en full asm que quand j'ai ces conditions remplis :
-macro puissante
-preprocesseur pouvant avoir des IFDEF/etc etc
-label temporaire
-gestion complexe de la mémoire (enum /structure entre autre).

ah oui , par contre :
en comptant les cycle utile
Cela confirme que tu n'as rien lu , il est difficile de compter des cycles sur un processeur in order (mais plus facile que sur du Out of Order), tu peux te baser que sur le pire cas.
Déjà savoir si tu as un cache miss ou pas (enfaîte c'est impossible de le savoir en lisant une macro ou même une fonction , d’où dépend si il y'a eu accès a cette adresse avant ou pas) et dans le pire des cas tu considère que as un cache miss sur les premières affectations , si tu te base dessus alors tu dois au mieux coder pour réutiliser ce petit bloc mémoire d’accès rapide.
Et connaître le cycle de cache miss est complexe parce que dans le cas du A7 il a deux cache , donc d'où dépend s'il accède ou pas au cache L2.

L'autre étant la pipeline stall , impossible de savoir si la première instruction à un pipeline stall dans une macro, de plus comme il est superscalaire , c'est difficile de savoir les instructions compatible entre elle si juste avant l'appel de ta macro tu as une instruction compatible avec ta première instruction de ta macro.
Enfaite c'est simple , le meilleur moyen c’est de mettre ça dans une fonction , au moins tu es sur que la pipeline recommence à zéro et que ton optimisation d’exécuter 2 instructions soit bel et bien respecté (sinon ça peut crée un décalage qui ne sera pas forcément correcte avec ce que tu souhaitais faire).
Bref faire une appli pour ça , me semble là aussi long et fastidieux comme taff :p

Et donc tu imagine que faire un compilo performant sur un proc pareil c'est très compliqué , enfaite c'est pour cela que ce genre de proc est évité sur les machines à "haute performance" parce que même les meilleurs compilo n’optimise pas toujours super bien la pipeline (mais plus qu'un simple novice c'est certain) , on préfère les proc Out of order , les compilo sont plus simple à faire et le proco optimise lui même la pipeline.
(Enfin je pense que si cela n'existe pas de compilo "ultime" pour ce genre de proc c'est que la tache est trop grande pour le peu de gain que ça apporte , sachant que si tu optimise pour le proc A7 , ça sera pas pour un autre proc qui à une pipeline différente, donc refaire l'optimisation pour chaque proc X ).
Bien sur je sens que tu vas me dire que tu vas faire mieux , j'ai hâte de voir ça

j'ai 10 ans d'experience en R&D électronique et je suis actuelement de cours au cnam pour passé plusieurs diplôme d’ingénieur ( 9 UE validé l'année dernière, 9 UE validé au premier semestre de cette année et j’espère encore en valider 9 au second semestre).

C'est très bien , mais je pense que tu te surestime un peu sur la tache à accomplir

@Vincent Je confirme que Broadcom a bien filer leur doc pour RasPi, je l'ai lu

[robotzeus]

Bonjour je prend bien sur en compte toutes vos remarques. mais je ne reviendrais pas sur l'objectif de programmé la carte en assembleur .
En revanche je suis ouvert a des étape intermediere pour y arrivé.

Lorsque l'on me parle de me familiarisé avec les OS existant je dit pourquoi pas mais comment m'en servir pour retourné a l'objectif si je ne sais pas comment lire l assembleur généré par les OS existant.

en étape intermediere je veux bien faire un programme en C mais sa soulevè les même problème qu'au dessus, Je ne sais pas si c'est faisable mais si j'avais accée au code assembleur ca pourrait déjà facilité grandement la tache

ce qui me gene avec les OS c'est qu'il prend la main pour géré tout un tas de truc que je n'ai besoin

Si je résume il me faut :
-un environnement de travail , pour cela j'ai télécharge ARM développement Studio
- le schéma de la carte (12 page)
- implantation des connecteur (j'ai)
-la doc du NOR FLASH mxic mx25l1606e ( option presente j'ai)
-la doc de composant EMAC pulse h1102nl ( elle sert pas a grand chose mais j'ai)
- la doc du composant wifi XR819 (J 'ai même si je ne veux pas utilisé le wifi)
-la doc Dram 4G k4b4g1646e (j'ai)
-les doc du H2+ (617 page)
-technical Reference Manual Cortex A7 (269 page)

je sais qu'il me manque encore des document mais je ne sais pas quoi (après j'ai de quoi potassé donc je vais faire une pose)


@kannagi le seul pavé que j'ai vu c'est le document de 5000 page sur TI, en ce qui concerne les message du forum je les ais tous lus 3 fois (la troisième c’était pour rechercher ton pavé mais si il s’agit d'un des message alors oui il a été lu et pris en considération. comme déjà dit j'ai une connaissance théorique sur les fonctionnement matériel des processeur et des micro contrôleur. j'ai également eu quelque TP sur le DSP TMS320C.

[Delias]

Bonjour Robotzeus

En lisant tes messages depuis ma dernière participation, j'ai l'impression que tu confonds programmer sans OS avec programmer sans "compilateur" (entre guillemet car l'assembleur reste un compilateur simple).
Tes contraires c'est plus de ne pas dépendre d'un OS, ou alors éventuellement à la mode DOS sans service d'arrière plan... (je caricature et je simplifie). Et heureusement il est parfaitement possible de faire cela en C et d'autres langages compilés. Par contre c'est parfois avec des limitations, (bon là on arrive à la limite de mes connaissances, j'ai fais du DSP sans OS et de l'OS sans les contraintes de temps réel, mais pas de l'entre-deux).

Bonne suite

Delias