Aymos

[mmm999]

bonjour chère membres futurien science
aprés une petite experience que j'ai eu de la programmation des microcontrolleurs(STM32 + PIC). j'ai pensé à écrire une petite OS que je le nomme AYMOS. mais pourquoi faire, j'ai constater que lors de l'écriture d'un programme pour faire fonctionner une périphérique exemple lcd alphanumériques qu'on nomme le driver, que celui ci présente des problème de portabilité, par exemple lors de migration d'un pic à un autre ou vers une autre architecture comme stm32 on doit réecrire le code
mais les avantages que j'ai vue lors de réeriture de drivers que certain fonction peut être copier coller, ces fonctions ne contient pas des apels à des registres spécifique mais juste des apel à d'autre fonction.
donc je me souvient des OS comme windows et linux qu'il présente une couche HAL qui va identifier matériel par exemple SPI, I2C, I/O, USART,USB ... et donne des noms standart. j'ai pensé à cette point donc pourquoi tous le monde écrit les drivers et réecrit et réecrit, pourquoi pas n'écrire le code une seule fois, le partager dans une comminité. et même si'il a changer driver il n'a que de réecrire la couche HAL. juste on donne une documentation précis pour l'écriture de l'AYMOS. donc je suis basé sur un OS coopérative. le TIMER sert comme une horloge système
tous ce que je veux des conseils/des idées et merci
pour quoi pas on partage pas des codes ici
-----

[mmm999]

j'ai pensé à ajouter des services comme X-modem, bibléothèque graphique, moteur d'évenement

[invite89303051]

Bonjour,

Pourquoi pas, mais il existe des projets déjà bien avancés tel que LUA
Cordialement

[mmm999]

je sais pas pourquoi lorsque on distribue le code gratuitement la documentation est payante comme le cas de LUA et freertos.

[A voir en vidéo sur Futura]

[invite89303051]

Bonjour,

Toute la documentation de base est disponible en ligne et gratuitement. Des livres sont disponibles, mais payant. (ce qui est un peu normal).
C'est un peu comme pour programmer un micro-contrôleur (a part le C Party ), il existe des tas d'outils, de compilateur gratuit et de la documentation en ligne, mais les livres sont payants.
Après, il faut également payer la location des serveurs Web, l'alimentation, la bande passante etc...

Cordialement

[invite936c567e]

Bonjour

L'idée est intéressante, mais je doute qu'elle soit bonne.

En effet, elle me semble être plutôt destinée à des développeurs débutants, qui préféreront programmer en se référant à une librairie de fonctions, comme on le fait sur de gros systèmes, plutôt que d'écrire (ou recopier depuis les docs) le code adapté à la situation.

Il me paraît important de rappeler qu'un OS consomme nécessairement des ressources et réduit les possibilités offertes par le matériel en imposant la manière de l'utiliser (comme notamment ici la réservation du TIMER). Or, l'intérêt principal d'utiliser de petits micro-contrôleur est justement de se limiter au strict minimum, de sorte que certains paramètres du projet (coût, consommation électrique, ...) soient optimisés.

On risque de devoir choisir une machine surdimensionnée (plus rapide, avec plus de mémoire, etc.) uniquement pour apporter quelques simplifications aux développeurs inexpérimentés, en les privant au passage de la possibilité de détecter et de régler certaines situations de conflit.

[invite2d7144a7]

Bonjour,

Entièrement d'accord avec PA5CAL et RicounetZap.

Les sites ne manquent pas, ni les exemples de codes, disponibles gratuitement pour la plupart, alors ...

Maintenant, si tu y tiens, fais-le. Ce sera au moins un bon exercice.

[invitee05a3fcc]

Pour votre culturation ...... je vous conseille de regarder ça : http://forums.futura-sciences.com/el...lai-stm32.html

[invite29971eb1]

Pour info, on trouve aujourd'hui des micros puissants (notamment les Cortex-M0) moins chers que les vieilles brouettes 8 bits. On est doucement en train de migrer vers le tout 32 bits et il semblerait que ARM devienne la norme sur toute la gamme de micros (du 8 au 1200 broches) pour quelques années voire dizaines d'années.

La question ne se pose pas sur les gros modèles ou, sauf cas particulier, on va utiliser un OS type Linux, Android ou Tartempion, mais si on veut utiliser un "OS" sur les Cortex-M0 à M4, le CMSIS est tout indiqué pour ça.

De plus, créer un OS compatible à la fois avec un PIC16 et un STM32 (pour citer les deux que tu cites), ça revient inévitablement à rabaisser les performances et les possibilités du STM32 au PIC16, ce qui est quand même un beau gâchis. Il y a tellement de différences entre les deux que mis à part quelques cas particuliers qui se codent en 5 minutes, les librairies n'auront rien à voir.

Ajoutons à ca la tendance de plus en plus forte des fondeurs à intégrer les drivers en ROM (comme sur les nouveaux LPC), et la pertinence d'un tel OS "universel" est de plus en plus mince.

[mmm999]

oui vous êtes raison.

Il me paraît important de rappeler qu'un OS consomme nécessairement des ressources et réduit les possibilités offertes par le matériel en imposant la manière de l'utiliser (comme notamment ici la réservation du TIMER). Or, l'intérêt principal d'utiliser de petits micro-contrôleur est justement de se limiter au strict minimum, de sorte que certains paramètres du projet (coût, consommation électrique, ...) soient optimisés.

j'ai pensé à cette coté. on faite aprés lancement de nom et de premier prototype d'un OS (version 0.0.1). j'ai constater que je m'oriente vers l'idée de projet GNU : dévelloper les ressources, les modules sans dévelloper le kernel. mais pourquoi faire, lorsque je développe par exemple un système électronique permet d'afficher une image couleur sur un écran avec la date et une belle horloge. au lieu de reprogramer tous à 0. j'accède à la commité AYMOS je télecharge le drivers de I2C(pour RTC), UART(pour lien avec ordinateur) ,GPIO'pour LCD) pour former couche HAL. pour je télecharge le driver de LCD couleur qui va s'en servir des fonctions de HAL sans voire le matériel et c'est ici l'avantage, je télécharge le driver de RTC. pour stocker l'image sur mon système j'utilise le protocole X-modem donc je télecharge le protocole. pour les fonction graphiques je télecharge le service graphique pour la couche middle war. s'il me manque qlq chose j'écrit les ressources manquants et je l'envoi à la commité pour qu'un autre soit servir la prochaine fois.
le ssytème d'exploitation utilisé est coopérative. pas d'existance de kernel donc on peux même installer sur des petites système même qu'elle ne contient pas des liasons spécifiques car HAL AYMOS contient des liasons virtuel qui sert comme des vrai liason comme soft SPI, soft RC5.
DAUDET78 : oui j'ai demander ça car je ne connais pas tous. pourquoi tu m'attaque. si tu as la solution allez y partage là

[invite936c567e]

Pour info, on trouve aujourd'hui des micros puissants (notamment les Cortex-M0) moins chers que les vieilles brouettes 8 bits. On est doucement en train de migrer vers le tout 32 bits et il semblerait que ARM devienne la norme sur toute la gamme de micros (du 8 au 1200 broches) pour quelques années voire dizaines d'années.

Attention, il ne faudrait pas que l'énoncé de cette tendance deviennent le moteur d'un mouvement total de disparition des soi-disant "vieilles brouettes" (terme que je réfute) et de domination sans partage des ARM.

N'oublions pas que les ARM ne sont pas exempts d'inconvénients, tant du point de vue technique que commercial, et que les autres architectures ont (ou devraient avoir) encore droit au chapitre dans les cas où ces premiers ne représentent pas le choix optimum.

Dans les années 90, on a connu une quasi-disparition de certains modèles de circuits jugés prématurément dépassés (... ou plus assez rentables). Cette erreur a conduit à rendre durant un temps beaucoup plus difficile la résolution de certains problèmes particuliers d'ingénierie, alors qu'on disposait encore dix ans auparavant de réponses simples, sûres, efficaces et bon marché. Cela a été un bel exemple de régression technologique, et il ne faudrait pas recommencer.

[Gérard]

Peux-tu déjà montrer quelques lignes de code de ton OS ?

[mmm999]

merci pour vos conseils. je vais s'en servir de vos sites
pour les architectures on peux pas oublier les 8 bits car pour un 12F683 on peux pas y'avoir un MCU de 0.8 $ avec un taille assez réduit comme le cas des coeur 32 bit.
si quelqu'un veux m'aider sur AYMOS je serais vraiment content de me rejoindre. je vais descendre la première version avec une architecture HAL dévellopé sur 18F452. peut être je trouve des personnes intéressant qui peut donner l'aide. comme indiquer c'est pas un projet pour moi. c'est un projet qui va aider tous.
oublions mikro c qui caches ces ressources dans des fichier MCL et qui permet pas d'apprendre.
le but essentiel d'AYMOS est d'être éducatif.

[invite29971eb1]

merci pour vos conseils. je vais s'en servir de vos sites
pour les architectures on peux pas oublier les 8 bits car pour un 12F683 on peux pas y'avoir un MCU de 0.8 $ avec un taille assez réduit comme le cas des coeur 32 bit.

Ah bon? Tu devrais te renseigner un p'tit peu alors. Les prix démarrent maintenant autour de 0.50$ pour un Cortex-M0+ en 8 broches...et je crois que certains descendent vers les 0.30$.

si quelqu'un veux m'aider sur AYMOS je serais vraiment content de me rejoindre. je vais descendre la première version avec une architecture HAL dévellopé sur 18F452. peut être je trouve des personnes intéressant qui peut donner l'aide. comme indiquer c'est pas un projet pour moi. c'est un projet qui va aider tous.

Commence déjà par ouvrir les exemples de tes micros cibles. Tu n'as pas ouvert le blinky que tu veux déjà créer un OS universel. Tu n'as pas l'impression d'être à côté de la plaque?

oublions mikro c qui caches ces ressources dans des fichier MCL et qui permet pas d'apprendre.

Quel compilo universel vas-tu utiliser alors?

le but essentiel d'AYMOS est d'être éducatif.

Pour être éducatif, il faut que ce soit didactique, donc que tu saches transmettre tes connaissances. Mais visiblement, tu en as moins que le public que tu adresses....Commence par apprendre à tenir sur un tricycle avant de vouloir faire le Tour de France.

[mmm999]

merci ftorma ! c'est ça ce que je cherche ! des conseils

Quel compilo universel vas-tu utiliser alors?

j'été un peu vague ! je voudrais expliquer que même si on utilise le mikro c le code doit décrit tous et vous trouvez toutes les définition des fonctions !
un jour j'ai essayer de faire fonctionner le transmitter NRF24L01+. j'ai eu le code en mikro c ! aprés un recherche approfondie dans les fichier de projet sur les définition des fonctions pour comprendre le mécanisme de fonctionnement de nrf et les trames envoyer/reçue !
j'ai constater que tous est encapsuler dans un fichier .MCL (library) et des apels abstraite des fonctions !
pour le travail de AYMOS j'utilise MCC18 / Hitech
comme je le dit on doit adapter le maximum l'architecture sur des MCU et des IDE

Ah bon? Tu devrais te renseigner un p'tit peu alors. Les prix démarrent maintenant autour de 0.50$ pour un Cortex-M0+ en 8 broches...et je crois que certains descendent vers les 0.30$.

j'entend de vous cette info !! car leur de visite de ST chez notre école! ils ont parler des controlleur de 88 -> 108 pin. j'ai pas remarquer ces petite controller

[mmm999]

je suis vraiment deçue !
j'ai travailler sur un demo tournant sous AYMOS ! ce demo est un gradateur commander par une télécommande infrarouge qui peux commander la lumonisité de 6 lampes en //
alors j'utilisé un PIC 18F13K50 + circuit de triac. OS coopérative donc j'avais les machines à état fini pour un processus de diode qui clignote et un processus pour le controle de gradateur pour 50% de lumonisté.
j'ai configuré le TIMER0 d'avoir des periodes de 10 micro second. chaque interruption une varibale s'incrémente. cette variable sert comme horologe système d'AYMOS. c'est ici que chaque processuss connais le temps et mesure les délais. le problème que ce système présente un problème de stabilité (absence des impulsions parfois). le système envoi les impulsions régulier (1ere en 5 ms 2éme en 15 ms pour y'avoir 50% de tension moyenne) mais des impulsions ne sont pas émise ou émit avant le temps. je sais pas pourquoi. mais peut être que les pics ne préfères pas des fréquences élever sur TIMER0
des solutions? ou je doit oublier projet AYMOS

[Gérard]

Tu n'as toujours pas répondu à #12.

Si tu pouvais faire un effort en français ...

[mmm999]

ok je partage les partis essentiel de mon code mais c'est un peu long.
parti horloge système

void update_base_time(void)
{
timer++;
}

unsigned long get_time(void)
{
return timer;
}

parti interruption

void interrupt HighISR(void)
{

//pour mise a jour de timer systeme
if(TIMER0_IF)
{

update_base_time();
TIMER0_IF = 0;

}

//synchronisation avec réseau du secteur et activation des machine d'état pour l'envoi des impulsions
if(INT0IF)
{
t1 = get_time();
TASK_pulse = DELAY_1_ALT;
INT0IF = 0;

}


}

parti HAL (configuration de microcontrolleur)

void TIMER0_init(void)
{
T0CON = 0x48;
INTCONbits.TMR0IF =1;
INTCONbits.TMR0IE = 1;
T0CONbits.TMR0ON = 1;
}

void INT0_init(void)
{
INT0IE = 1;
INTEDG0 = 0;
INT0IF = 0;
UNT0_I = 1;
}


void Activate_interruption(void)
{
INTCONbits.GIEH=1;
INTCONbits.GIEL=1;
}

void OscillatorConfig(void)
{
/* Configuration of the Oscillator */
OSCCONbits.IDLEN = 0; // Device enters Sleep mode on SLEEP instruction
OSCCONbits.IRCF = 6; // Internal Oscillator Frequency Select bits as 8 Mhz
OSCCONbits.OSTS = 0; // Device is running from the clock defined by FOSC<2:0>
OSCCONbits.IOFS = 1; // HFINTOSC frequency is stable
OSCCONbits.SCS1 = 1; // System Clock Select Internal oscillator block
}


void HAL_init(void)
{
OscillatorConfig();
TIMER0_init();
INT0_init();
ANSELbits.ANS4 = 0;
GATE_IO = 0;
Activate_interruption();
}

processuss de l'envoi des impulsions

#include <TASK1.h>
#include <HAL_PIC18F13K50.h>
#include <clock.h>
#include <delays.h>

task1 TASK_pulse = IDLE;

char x;

unsigned long t1;

long timing;

void TASK_pulse_thread(void)
{
static int i,j;
switch (TASK_pulse)
{
case IDLE:


break;



case DELAY_1_ALT:
if( (get_time() - t1) >= 1ms) TASK_pulse = PULSE1;


/*
Delay100TCYx(x);
GATE = 1;
Delay10TCYx(10);
GATE = 0;
Delay10KTCYx(2);


GATE = 1;
Delay10TCYx(10);
GATE = 0;

TASK_pulse--;
*/
break;

case PULSE1:
t1 = get_time();
GATE = 1;
Delay10TCYx(10);
GATE = 0;
TASK_pulse = DELAY_2_ALT;
break;

case DELAY_2_ALT:
if(get_time() - t1 > 10 ms) TASK_pulse = PULSE2;
break;

case PULSE2:
GATE = 1;
Delay10TCYx(10);
GATE = 0;
TASK_pulse = IDLE;
break;
}
}

je suppose que je partage l'essentiel de mon code

[mmm999]

bonjour a tous
j'avais crée une image pour simplifier l'architecture de cette OS. et pour mettre les points sur les 'i'.

couche application : les application à éxecuter
couche Middle War : les services offert par l'OS : graphic, traitement de données, protocole de commincation
couche Drivers : les drivers pour les appareils comme LCD
couche HAL : description matériel de l'environnement système : BUS SPI, BUS IC, GPIO
couche HARDWARE : matériel ou environnement externe
le timer sert comme une base de temps système
pour la couche d'abstraction, j'ai commencé par réécrire les fonctions d’accés au registre. je doit mettre des noms inchangeable pour le reste des couches. mais c'est fatiguant.
à propos : y'a pas un opérateur en langage c qui force le choix de l'adresse d'une variable déclaré. c'est à dire si je veux déclarer la variable A avec l'adresse 0xCFF. je prend le choix au lieux que le compilateur mettre dans n'importe ou dans la ram. microchip ajout l'opérateur @.

volatile char PORTB @ 0xA11