Discussion :

[kenzokenza]

Bonjour,

Je débute dans la programmation des microcontrôleurs . J'ai un système comporte deux microcontrôleurs STM32, un qui sert à faire des acquisitions de données d'un capteur de température et de tension (microcontrôleurs de travail) et l'autre utilisé pour faire de la maintenance .

Ma problématique consiste à charger le code existant dans le microcontroleur de maintenance réalisant certaines taches bien précise vers le microcontrôleur de travail sans passer par une sonde JTAG. je voudrais savoir comment mettre à jour le code dans le microcontroleur de travail au démarrage du système , en d'autres termes comment les deux microcontroleurs communiquent entre eux.

j'ai regardé dans pas mal de forum et je n'ai pas trouvé la réponse à ma problématique et j'espère en avoir ici. Merci d'avance

[Vincent PETIT]

Salut,
Je ne connais pas bien la famille ST mais comme tous les microcontrôleurs fonctionnent de la même manière, il faut que tu programmes un bootloader dans le microcontrôleur de travail.

Un bootloader est un programme, déjà fait par le constructeur, qui se loge dans un endroit précis du micro. Ce programme est souvent à l'affût d'un changement d'état d'une broche I/O ou d'une donnée particulière arrivant sur le port série (l'UART de ton micro). Une fois cet événement détecté par le micro, celui-ci va lancer le bootloader qui a pour rôle de prendre les données arrivant par le port série, entend par là un programme, et le met dans la mémoire flash. Un coup de Reset et le micro redémarre en exécutant le programme que tu viens de lui envoyer. Si tu réactives l'événement particulier, le bootloader reprendra la main et écrasera la mémoire flash avec ce que tu lui enverra sur son port série.

Aujourd'hui beaucoup de micro ont des bootloader UART ou USB.

Je pense que tu trouvera ce qu'il faut ici :
http://www.st.com/content/ccc/resour...CD00167594.pdf

J'ai déjà utilisé des bootloader mais sur des micro Texas Instruments (en plus ce n'était pas des architectures ARM) mais jamais sur du ST.
A+

[kenzokenza]

Merci beaucoup de votre retour.

Cependant une fois qu'un évènement sur les I/o est détecté par le micro , celui ci va lancé le bootloader et le programme que j'enverrai se retrouvera dans la mémoire flash. Vous parlez bien du microcontroleur de travail j'imagine?

Vu que j'utilise un microcontrôleur( de maintenance) qui normalement devrait contenir le programme que doit exécuté le microcontrôleur de travail, je ne comprends pas comment ce programme lui sera envoyé au démarrage?

Est ce qu'il existe un schéma de câblage pour réaliser cette fonctionnalité? Merci

[Vincent PETIT]

[...]Cependant une fois qu'un évènement sur les I/o est détecté par le micro , celui ci va lancé le bootloader et le programme que j'enverrai se retrouvera dans la mémoire flash. Vous parlez bien du microcontroleur de travail j'imagine?

En effet c'est bien le microcontrôleur de travail qui doit avoir un bootloader en interne pour pouvoir être reprogrammer sans sonde JTAG.

Vu que j'utilise un microcontrôleur( de maintenance) qui normalement devrait contenir le programme que doit exécuté le microcontrôleur de travail, je ne comprends pas comment ce programme lui sera envoyé au démarrage?

C'est à toi de réaliser tout ça, si vraiment c'est ce que tu souhaites faire. (D'ailleurs j'ai une question là dessus voir plus bas) Les bootloader sont prévus pour être embarqué dans les microcontrôleurs afin que ces derniers puissent être reprogrammer a volonté depuis un PC sans aucune sonde de prog/debug JTAG. Très souvent, pour ne pas dire toujours, le fabricant du micro fourni le bootloader et aussi le logiciel PC qui va bien. Toi tu as choisi d'avoir un microcontrôleur à la place du PC. Il va donc falloir que tu trouves un moyen pour que le micro de maintenance se comporte comme un PC, vu du micro de travail !

Est ce qu'il existe un schéma de câblage pour réaliser cette fonctionnalité? Merci

Malheureusement non. Dans le lien que je t'ai donné, ST dit que son bootloader peut lire des données arrivant par l'USB, L'I2C, Le SPI, l'UART et le bus CAN pour les mettre en mémoire flash donc tu as du choix concernant le câblage ! C'est toi qui voit.
Ce que je peux te dire, c'est que le plus simple et le plus souvent utilisé dans l'industrie c'est l'UART pour des raisons historiques (port série des PC).

Je trouve cette configuration a deux microcontrôleurs, très suspect et très bizarre ! La seule et unique fois où j'ai vu ça c'est dans un système devant répondre une norme bien spéciale (sécurité de fonctionnement SIL II.)

- Est ce qu'on t'a imposé les deux micros ?
- Pourquoi est ce que tu veux reprogrammer le micro de travail ?
- Es tu sur que ce ne sont pas de simples paramètres qu'il te faut mettre a jour ? Car la solution est radicalement différente.
- En électronique, le hard étant fixe et le soft allant de paire, il est rare de devoir reprogrammer complétement le micro sauf bug dans le programme.
- Tu pourrais m'expliquer le contexte qui justifie cela ?


A+

[kenzokenza]

Mon STM1( microcontroleur de travail) fait continuellement une acquisitions de données des drivers ,les transmet vers un esclave ethercat par le protocol SPI et ensuite toutes ces données seront envoyées vers un maitre ( un automate programmable) à travers le protocole ethercat. (Voir le schéma joint)

Cette tache doit s’exécuter périodiquement pendant une très durée. Cependant vu que toute les données récupérées n'arrivent pas au maitre avec le temps que je me suis imposé, je voudrais alors les stocker dans un autre microcontrôleur STM2 qui possède une carte mémoire, entendez par la mon programme.

Donc ce que je veux faire c'est de mettre à jour mon programme dans le STM1 en utilisant le STM2.

Le choix de deux microcontroleurs ne m'est pas imposé. C'est une première approche sur lequel je me suis basé. Mais si vous avez toute autre solution je suis preneur.

Merci

[Vincent PETIT]

Mon STM1( microcontroleur de travail) fait continuellement une acquisitions de données des drivers ,les transmet vers un esclave ethercat par le protocol SPI et ensuite toutes ces données seront envoyées vers un maitre ( un automate programmable) à travers le protocole ethercat. (Voir le schéma joint)

Cette tache doit s’exécuter périodiquement pendant une très durée.

Ok pour ça !
Tu peux préciser cette durée ? Ou nous en donner une bonne approximation.

Cependant vu que toute les données récupérées n'arrivent pas au maitre avec le temps que je me suis imposé, je voudrais alors les stocker dans un autre microcontrôleur STM2 qui possède une carte mémoire, entendez par la mon programme.

Là il y a une ambiguïté.

Tout d'abord si je comprends bien, STM1 echantillonne les données en entrée plus vite que l'automate ne peut les absorber ?

Donc tu veux stocker le surplus de données quelque part pour ne pas en perdre. Tu as donc choisie un autre microcontrôleur, STM2 + une carte mémoire pour jouer le rôle de tampon ?

Donc dans cette carte mémoire, ce n'est absolument pas un programme qu'il y a dedans mais des données issues de STM1 qui n'ont pas eu le temps d'aller dans l'automate (car STM1 est trop rapide)

Est ce que je comprends bien ?

Donc ce que je veux faire c'est de mettre à jour mon programme dans le STM1 en utilisant le STM2.

Si j'ai bien compris ci dessus alors ce que tu veux c'est, non pas mettre à jour le programme en lui même, mais remettre les données dans STM2 dans le tuyau. Cest à dire dans STM1 pour que tout parte dans l'automate ?

C'est ce que tu souhaites faire ?

C'est très important que l'on parle de la même chose et surtout qu'on utilise les mêmes termes. Car pour moi, mettre à jour un programme dans un microcontroleur c'est changer le code source par un autre (mémoire flash). Ce qui est différent de mettre à jour des données car on ne change pas le source pour ça.

A+

[Bktero]

Tu as MCU qui échantillonne des données. Tu as besoin de stocker ces données. Tu t'es dit que la meilleure solution serait d'avoir une carte SD connectée à un autre MCU et d'envoyer les données à cet autre MCU par une liaison filaire.



Dis comme ça, ça me parait aberrant ! La bonne solution serait de stocker dans la RAM de ton MCU. Si elle est trop petite, utilise une RAM externe ! Dans ton cas, il faut le temps d'envoyer les données + de stocker dans la carte ; dans l'autre cas, il faut juste le temps d'envoyer les données. On peut même se demander pourquoi la carte mémoire n'est pas sur ton MCU, pourquoi la connecter à un autre MCU ?

Ton problème est sans doute mal expliqué pour que j'arrive à un tel constat ^^

[kenzokenza]

Ok pour ça !
Tu peux préciser cette durée ? Ou nous en donner une bonne approximation.


Là il y a une ambiguïté.

Tout d'abord si je comprends bien, STM1 echantillonne les données en entrée plus vite que l'automate ne peut les absorber ?

Donc tu veux stocker le surplus de données quelque part pour ne pas en perdre. Tu as donc choisie un autre microcontrôleur, STM2 + une carte mémoire pour jouer le rôle de tampon ?

Donc dans cette carte mémoire, ce n'est absolument pas un programme qu'il y a dedans mais des données issues de STM1 qui n'ont pas eu le temps d'aller dans l'automate (car STM1 est trop rapide)

Est ce que je comprends bien ?


Si j'ai bien compris ci dessus alors ce que tu veux c'est, non pas mettre à jour le programme en lui même, mais remettre les données dans STM2 dans le tuyau. Cest à dire dans STM1 pour que tout parte dans l'automate ?

C'est ce que tu souhaites faire ?

C'est très important que l'on parle de la même chose et surtout qu'on utilise les mêmes termes. Car pour moi, mettre à jour un programme dans un microcontroleur c'est changer le code source par un autre (mémoire flash). Ce qui est différent de mettre à jour des données car on ne change pas le source pour ça.

A+

C'est bien cela que je souhaite faire Vincent!!

STM1 échantillonne les données venant du driver et les envoie à un esclave ethercat. La communication entre le stm1 et l'esclave ethercat se fait par SPI comme le mentionne la figure. Et ensuite l'esclave ethercat envoie ces données vers l'automate, le maitre, par le protocole ethercat. celui-ci peut décider d'arrêter le système en cas d'erreur ou envoyer d'autre commande vers STM1 toujours à travers l'esclave ethercat.

Alors je precise que cette tache (d’échantillonnage des données et d’envoi des données vers le maitre) doit s'effectuer chaque 250microsecondes.
Mais Vu que le protocole SPI est assez lent par rapport au protocole ethercat qui lui est très rapide, toutes les données du STM1 ne pourront pas être transférées à l'automate pendant la durée de 250microsecondes. Je veux donc stocker le reste des données quelque part et aller les chercher pour les envoyer au maitre.

Est ce que ma solution d'utiliser un autre microcontroleur (STM2) est bonne?

[Vincent PETIT]

[...]Alors je precise que cette tache (d’échantillonnage des données et d’envoi des données vers le maitre) doit s'effectuer chaque 250microsecondes.
Mais Vu que le protocole SPI est assez lent par rapport au protocole ethercat qui lui est très rapide, toutes les données du STM1 ne pourront pas être transférées à l'automate pendant la durée de 250microsecondes. Je veux donc stocker le reste des données quelque part et aller les chercher pour les envoyer au maitre.

Nous sommes tous d'accord.
Questions :

• Combien d'échantillon envois tu vers le maitre dans les 250ms (1 échantillon ou un paquet de combien d'échantillon) ?
• 250ms c'est assez lent comme période, ça fait un transfert à raison de 4kHz et ton STM32 tourne a quelle fréquence juste pour comparer ?
• As tu une doc de ton esclave ethercat, je voudrai voir a quelle vitesse il peut recevoir les données arrivant par le SPI ?

Est ce que ma solution d'utiliser un autre microcontroleur (STM2) est bonne?

Non, elle complexifie grandement le problème qui n'est autre que du Timing avec une mémoire tampon.
La solution de Bktero est la plus simple, la plus efficace et la plus rapide. C'est cette solution que j'aurai aussi choisie.

J'attends les réponses pour pouvoir aller plus loin dans l'explication.
A+

[kenzokenza]

Tu as MCU qui échantillonne des données. Tu as besoin de stocker ces données. Tu t'es dit que la meilleure solution serait d'avoir une carte SD connectée à un autre MCU et d'envoyer les données à cet autre MCU par une liaison filaire.



Dis comme ça, ça me parait aberrant ! La bonne solution serait de stocker dans la RAM de ton MCU. Si elle est trop petite, utilise une RAM externe ! Dans ton cas, il faut le temps d'envoyer les données + de stocker dans la carte ; dans l'autre cas, il faut juste le temps d'envoyer les données. On peut même se demander pourquoi la carte mémoire n'est pas sur ton MCU, pourquoi la connecter à un autre MCU ?

Ton problème est sans doute mal expliqué pour que j'arrive à un tel constat ^^

En fait j'ai testé mon application qui tourne normalement dans le STM1 en deboggant et en envoyant le code source à travers un JTAG.

Maintenant mon système doit fonctionner sur un site et je veux utiliser un second microcontroleur STM2 où je veux mettre une nouvelle version de mon application qui est stocké dans une mémoire.

Mon vrai problème est comment donc charger cette nouvelle version de mon application dans le STM1 (qui doit communiquer avec l'automate) au démarrage, sans avoir à utiliser un PC et une sonde JTAG qui nécessitera une présence humaine et ça j'ignore réellement comment faire.

[Vincent PETIT]

Pour moi c'est un problème différent et c'est à ça que sert le bootloader !

Sur certain micro, dont un que j'ai chez moi, le fabricant fournit un bootloader USB (car le micro a un périphérique USB OTG) et il démarre en activant sur une broche lors du démarrage micro. Comme tout bootloader, des qu'il est activé il prendra tout ce qui rentre par l'USB dans le cas présent, pour un nouveau programme. L'avantage de ce micro c'est que son USB est OTG donc il peut se comporter comme un hôte si jamais tu insères un clé USB (si tu y connectes un PC alors il repasse en esclave) bref, la possibilité qu'il offre c'est qu'il peut aller chercher ses données (son nouveau programme) lui même dans la clé USB pour se programmer.

Je comprends un peu mieux maintenant pourquoi tu voulais mettre en place un autre microcontrôleur bien que le problème restait entier car on tournait en rond ! Si c'est pour mettre une mise a jour figé dans STM2 (lors de la conception) à destination de STM1 alors autant programmer tout de suite STM1 avec cette mise à jour lors de la conception du produit et virer STM2.
Ensuite on aurait pu envisager une activation a distance de STM2 pour qu'il mette à jour STM1 mais là aussi, autant mettre à jour STM1 tout de suite où bien carrément implémenter tout le système de programmation a distante dans STM1.

Dans l'attente des réponses a mes questions

[kenzokenza]

Merci pour ces réponses bien détaillées.

pour repondre à vos questions j'envoie à chaque fois un paquet de 256octets pendant les 250microsecondes et mon stm peut tourner à une fréquence max de 72MHz. Voici le lien renvoyant vers le document de l'esclave ethercat.

http://www.ethercat.org/pdf/english/...ationGuide.pdf

Ensuite on aurait pu envisager une activation a distance de STM2 pour qu'il mette à jour STM1

C'est exactement ce que j'envisage de faire. et donc comment je peux faire ça? toujours avec le bootloader?
Merci

[Vincent PETIT]

pour repondre à vos questions j'envoie à chaque fois un paquet de 256octets pendant les 250microsecondes et mon stm peut tourner à une fréquence max de 72MHz.

Il y a un handshaking entre chaque octet (tu lis un registre dans l'esclave pour savoir si il est prêt a recevoir un nouvel octet) ? Ou bien tu balances 256 octets, les uns après les autres, dans l'esclave sans te préoccuper si il a eu le temps ou pas d'envoyer ça vers ethercat ?

Voici le lien renvoyant vers le document de l'esclave ethercat.
http://www.ethercat.org/pdf/english/...ationGuide.pdf

C'est un lien vers la norme, moi je voulais le lien vers le composant électronique pour voir si le composant avait déjà une mémoire tampon (buffer) et connaître la fréquence max du bus SPI. Le bus SPI est rapide, beaucoup plus que I2C par exemple, je suis donc surpris lorsque tu me dis que le bus SPI est lent sur le composant esclave ethercat !?

C'est exactement ce que j'envisage de faire. et donc comment je peux faire ça? toujours avec le bootloader

Oui c'est bien avec le bootloader qu'on fait ça. Le fabricant explique comment son bootloader est conçu, comment il s'active et comment le modifier pour faire un peu plus que la version d'origine. Il y a toutes les chances que le bootloader USB d'origine soit conçu par ST de tel sorte que :

• Il s'active via la modification d'une broche
• Qu'il configure le micro en esclave USB souvent HID.
• Pour y connecter via USB un logiciel PC qui permet de charger un fichier .hex

C'est le cas de Texas Instruments et il y a toutes les raisons de penser que ST a du faire pareil. Ton fabricant comme tous les autres, te donne toutes les infos que tu souhaites sur leur bootloader (documentation, source, logiciel PC + source, notes d'applications) afin que tu puisses le modifier selon tes besoins. En effet, il n'est pas rare que lors de l'activation du bootloader, tu veuilles faire des choses en plus, ne serait ce que allumer une LED pour prévenir l'utilisateur que le micro est en mode mise à jour et pas en mode fonctionnement normal.

L'idée pour toi serait que le bootloader fasse ça :

• Il s'active via la modification d'une broche (via un bouton poussoir par exemple)
• Qu'il configure le micro en hôte USB + prise en charge de la classe MSD (mass storage device = clé USB) + FAT32 (système de fichier).
• Pour y connecter une clé USB contenant un programme .hex
• Ton micro doit savoir a l'avance le nom du fichier a aller chercher, maj.hex par exemple et tu peux aussi gérer les numéros de version avec quelques artifices (maj1.0.hex ou maj1.1.hex etc il suffit que ton micro connaisse la version du soft qui est installée)

Tu vois l'idée ?
C'est du boulot quand même l'air de rien puisqu'il te faut comprendre le bootloader en lisant la doc souvent assez balaise, il faut expérimenter, il va aussi falloir apprivoiser l'USB qui est un sacré gros morceau et avant tout ça s'assurer que le STM32 est bien équipé d'un port USB OTG !

[kenzokenza]

C'est un lien vers la norme, moi je voulais le lien vers le composant électronique pour voir si le composant avait déjà une mémoire tampon (buffer) et connaître la fréquence max du bus SPI. Le bus SPI est rapide, beaucoup plus que I2C par exemple, je suis donc surpris lorsque tu me dis que le bus SPI est lent sur le composant esclave ethercat !?

Oh Oui vous avez raison je me suis trompé. voici le lien le datasheet de l'esclave.
http://ftp.beckhoff.com/download/doc...sheet_v1i9.pdf

Oui c'est bien avec le bootloader qu'on fait ça. Le fabricant explique comment son bootloader est conçu, comment il s'active et comment le modifier pour faire un peu plus que la version d'origine. Il y a toutes les chances que le bootloader USB d'origine soit conçu par ST de tel sorte que :

• Il s'active via la modification d'une broche
• Qu'il configure le micro en esclave USB souvent HID.
• Pour y connecter via USB un logiciel PC qui permet de charger un fichier .hex

C'est le cas de Texas Instruments et il y a toutes les raisons de penser que ST a du faire pareil. Ton fabricant comme tous les autres, te donne toutes les infos que tu souhaites sur leur bootloader (documentation, source, logiciel PC + source, notes d'applications) afin que tu puisses le modifier selon tes besoins. En effet, il n'est pas rare que lors de l'activation du bootloader, tu veuilles faire des choses en plus, ne serait ce que allumer une LED pour prévenir l'utilisateur que le micro est en mode mise à jour et pas en mode fonctionnement normal.

L'idée pour toi serait que le bootloader fasse ça :

• Il s'active via la modification d'une broche (via un bouton poussoir par exemple)
• Qu'il configure le micro en hôte USB + prise en charge de la classe MSD (mass storage device = clé USB) + FAT32 (système de fichier).
• Pour y connecter une clé USB contenant un programme .hex
• Ton micro doit savoir a l'avance le nom du fichier a aller chercher, maj.hex par exemple et tu peux aussi gérer les numéros de version avec quelques artifices (maj1.0.hex ou maj1.1.hex etc il suffit que ton micro connaisse la version du soft qui est installée)

Tu vois l'idée ?
C'est du boulot quand même l'air de rien puisqu'il te faut comprendre le bootloader en lisant la doc souvent assez balaise, il faut expérimenter, il va aussi falloir apprivoiser l'USB qui est un sacré gros morceau et avant tout ça s'assurer que le STM32 est bien équipé d'un port USB OTG !

Oui je comprends bien l'idée . Comme vous le dites il y'a vraiment de quoi faire. voici un document sur le bootloader du stm que j'ai pu trouvé. Je ne sais pas s'il est assez bien détaillé. (voir le lien ci-dessous)
http://www.st.com/content/ccc/resour...CD00167594.pdf

j'utilise un stm32f107. L'USB fait bien parti des périphériques disponible pour gérer le bootloader mais je vois que peux également utiliser d'autres périphériques comme usart1,USART2, CAN . Ce sera peut être plus simple de les utiliser non?

[Vincent PETIT]

Voici le lien le datasheet de l'esclave.
http://ftp.beckhoff.com/download/doc...sheet_v1i9.pdf

L'horloge du bus SPI peut aller jusque 20MHz il faut que tu calculs combien de temps il te faut pour envoyer 1 octet a cette fréquence d'horloge (sachant que le SPI impose un protocole, il faut envoyer l'adresse concernée, la commande lecture ou écriture, l'octet à lire ou écrire) Tout ça se calcul en fonction de cette doc. Il y a les chronogrammes.

Tu as fait ce calcul ?

Tu échantillonnes les données d'entrée a quelle fréquence ?

ps : je vais regarder de prés ce soir mais il me semble que ce composant a de la RAM interne qui peut faire office de buffer.

Oui je comprends bien l'idée . Comme vous le dites il y'a vraiment de quoi faire. voici un document sur le bootloader du stm que j'ai pu trouvé. Je ne sais pas s'il est assez bien détaillé. (voir le lien ci-dessous)
http://www.st.com/content/ccc/resour...CD00167594.pdf

j'utilise un stm32f107. L'USB fait bien parti des périphériques disponible pour gérer le bootloader mais je vois que peux également utiliser d'autres périphériques comme usart1,USART2, CAN . Ce sera peut être plus simple de les utiliser non?

Si tu veux insérer une clef USB alors c'est le bootloader USB qu'il te faut et c'est de loin de plus complexe a prendre en main.
Tu t'es déjà pencher sur comment fonctionne l'USB ?

Pour l'UART c'est sur que ça plus simple car c'est le bootloader qu'on rencontre le plus souvent en plus il existe des composants bridge genre le FTDI 232 qui est une passerelle USB/UART (le micro le voit comme un port série et le PC le voit comme un port série virtuel USB)

Le STM32F107 semble avoir un port USB OTG donc il peut devenir Hote si il détecte un esclave.

Pour le bootloader, je n'ai ni de STM32 chez moi, ni les outils de développement pour tester, ni sonde JTAG et c'est un micro que je ne maîtrise pas. Donc à part de donner les grandes directions, je ne pourrai pas faire plus.

[kenzokenza]

Si tu veux insérer une clef USB alors c'est le bootloader USB qu'il te faut et c'est de loin de plus complexe a prendre en main.
Tu t'es déjà pencher sur comment fonctionne l'USB ?

Pour l'UART c'est sur que ça plus simple car c'est le bootloader qu'on rencontre le plus souvent en plus il existe des composants bridge genre le FTDI 232 qui est une passerelle USB/UART (le micro le voit comme un port série et le PC le voit comme un port série virtuel USB)

Le STM32F107 semble avoir un port USB OTG donc il peut devenir Hote si il détecte un esclave.

Avez vous un schéma de câblage correspondant à votre Texas Instrument que je pourrai adapter au mien.?

[Auteur]

Je regarde de loin la discussion, j'avoue ne pas avoir tout compris

J'ai plusieurs questions :
- connais-tu le programme de STM1 ? Car, à mes yeux, il serait plus simple de le reprogrammer et d'y ajouter une carte mémoire (comme le suggère Bktero) ? Là j'ai l'impression que tu ne sais pas trop ce que fait SMT1 et que tu essayes d'y ajouter quelque chose par dessus...

- je vois que STM1 et ton automate sont liés par le protocole Ethercat. Pourquoi ne pas insérer ta nouvelle carte à ce niveau, entre les 2 dispositifs ? C'est elle qui gérera les échanges entre les 2 systèmes notamment le transfert des données avec mémorisation des échantillons si nécessaire.

[kenzokenza]

Je regarde de loin la discussion, j'avoue ne pas avoir tout compris

J'ai plusieurs questions :
- connais-tu le programme de STM1 ? Car, à mes yeux, il serait plus simple de le reprogrammer et d'y ajouter une carte mémoire (comme le suggère Bktero) ? Là j'ai l'impression que tu ne sais pas trop ce que fait SMT1 et que tu essayes d'y ajouter quelque chose par dessus...

Oui je connais le programme de STM1 mais ce que je souhaiterai faire c'est de le reprogrammer (sa mémoire flash) lorsque j'ai une nouvelle version du programme sans utiliser un JTAG.

Mon système sera implanté sur un site de panneaux solaires, je ne pourrai donc pas venir à chaque fois avec un pc et un jtag pour charger un programme , donc je voudrais reprogrammer STM1 sans passer par un jtag. Tu vois un peu ce je souhaite faire ?

- je vois que STM1 et ton automate sont liés par le protocole Ethercat. Pourquoi ne pas insérer ta nouvelle carte à ce niveau, entre les 2 dispositifs ? C'est elle qui gérera les échanges entre les 2 systèmes notamment le transfert des données avec mémorisation des échantillons si nécessaire.

Cela remettrait en question l'architecture du système. je travaille sur ce projet que depuis trois mois et l'architecture a déja été validé.

[Bktero]

Il y a 2 problématiques qui n'ont rien à voir :

1. programmer un MCU sans JTAG
2. stocker des données

Dans les 2 cas, avoir 2 MCU ne sert à rien.

Cela remettrait en question l'architecture du système. je travaille sur ce projet que depuis trois mois et l'architecture a déja été validé.

C'est dommage, mais si ton architecture est mauvaise, il vaut mieux la changer maintenant que dans 2 mois de plus, quand tu auras essayé et que tu n'auras pas réussi.

[kenzokenza]

Il y a 2 problématiques qui n'ont rien à voir :

1. programmer un MCU sans JTAG
2. stocker des données

Dans les 2 cas, avoir 2 MCU ne sert à rien.


C'est dommage, mais si ton architecture est mauvaise, il vaut mieux la changer maintenant que dans 2 mois de plus, quand tu auras essayé et que tu n'auras pas réussi.

Oui je vois. Tu as certainement raison. Je vais revoir l'architecture et proposant cette soluti
Cependant aurai-tu une solution à la première problématique.?