Outils de développement ARM Cortex-M3?

Je prévois de migrer vers l'architecture NXP Cortex M3 et je suis un peu perdu entre les outils de développement existants.

Keil est cher et je ne sais pas si ça vaut le coup. Quiconque a essayé un compilateur peut donner un conseil?

J'ai trouvé ce compilateur http://www.code-red-tech.com/red-suite-2.php il semble bon et pas cher. Toute personne qui a essayé ou sait à ce sujet peut me donner plus d'informations?

Je joue depuis peu avec mon STM32 (également Cortex M3) et j'utilise la distribution CodeSourcery de GCC, qui a plutôt bien fonctionné.

Un collègue qui a travaillé avec ARM micros de manière professionnelle dans le passé m'a dit qu'il était satisfait de la panoplie d'outils IAR, bien que je ne connaisse pas le coût ni le support Cortex.

J'utilise les compilateurs croisés CodeSourcery (Lite) pour Linux pour programmer les microcontrôleurs TI Stellaris . Ils travaillent avec n'importe quel Cortex-M3. Ils sont complètement gratuits, avec des binaires pour Windows et Linux.

Voici une courte recette (Debian / Ubuntu) à installer:

Téléchargez le toolchain (n'importe quelle version fera l'affaire, mais j'utilise celle-ci)

Installez Java Runtime Environment (pour le fichu installateur)

sudo apt-get install sun-java6-jre ia32-libs

Installer

chmod 755 arm-2009q3-68-arm-none-eabi.bin
./arm-2009q3-68-arm-none-eabi.bin -i console

Ajouter le répertoire bin du compilateur croisé à votre PATH

echo 'export PATH=$PATH:~/CodeSourcery/Sourcery_G++_Lite/bin/' >> ~/.bashrc 
. ~/.bashrc 

Pour charger le code et déboguer, vous aurez besoin d’ OpenOCD et de gdb ou de l’une des interfaces graphiques.

Vous aurez également besoin d'un adaptateur JTAG .

J'ai commencé à utiliser l'un de ceux-ci (carte de développement MBED). Les principaux arguments de vente pour moi étaient que je pouvais coder en C ou C ++, une connexion directe vis-à-vis USB et un environnement de développement en ligne fluide (aucune installation d'outil local n'est requise!).

http://mbed.org/

Cinq minutes après l'ouverture de la boîte, j'ai eu un exemple de programme blinky (le «monde bonjour» du monde intégré) qui s'exécute comme suit:

#include "mbed.h"

DigitalOut myled(LED1);

int main()
{
    while(1)
    {
        myled = 1;
        wait(0.2);
        myled = 0;
        wait(0.2);
    }
}

C'est ça! Ci-dessus, le programme complet!

Il est basé sur ARM Cortex M3, une mémoire rapide et abondante pour les projets intégrés (100 MHz, 256 Ko de mémoire vive et 32 ​​Ko de mémoire vive). Les outils de développement en ligne ont une très bonne bibliothèque, de nombreux exemples et un forum très actif. Beaucoup d'aide sur la connexion de périphériques à MBED, etc.

Même si j'ai beaucoup d'expérience avec les systèmes embarqués (ARM 7/9, Renases M8 / 16/32, Coldfire, Zilog, PIC, etc.), j'ai quand même trouvé ce système rafraîchissant et facile à maîtriser tout en ayant de grandes capacités.

Après avoir initialement joué sur une maquette de base, j'ai acheté une base de ces types: http://www.embeddedartists.com/products/lpcxpresso/xpr_base.php?PHPSESSID=lj20urpsh9isa0c8ddcfmmn207. Cela a une pile de périphériques d’E / S (y compris une OLED miniature et un accéléromètre à 3 axes). Sur le même site, j’ai également acheté l’une des cartes de processeur LCPExpresso, qui est économique, moins d’énergie / mémoire que la MBED, mais qui convient parfaitement aux petits travaux (détruit toujours les processeurs PIC / Atmega). La carte de base prend en charge le LCPExpresso et le MBED. L’achat de la carte processeur LCPExpress m’a également apporté un débogueur JTAG attaché et un environnement de développement hors connexion (kit de développement basé sur GCC / Eclipse de Code Red). C’est bien plus complexe que l’environnement de développement MBED en ligne, mais c’est une progression logique une fois que vous avez acquis de l’expérience avec MBED.

En ce qui concerne mon point de départ, notons que le contrôleur MBED est beaucoup plus capable que le contrôleur LPCExpresso BUT est beaucoup plus simple à utiliser et à apprendre.

code source lite est bon, ou utilisez emdebian. Si vous avez besoin d’une bibliothèque complète C ou gcc, c’est encore faisable mais un peu plus difficile. au début, vous n'aurez pas besoin d'un compilateur capable de numériser avec les données de thumb2, ce dernier fera en sorte que vous recherchiez une chaîne d'outils que vous aimez.

llvm en est un autre bon (utilisez clang not llvm-gcc !!), je sais que le côté des bras s’améliore constamment, la version 27 produisait du code plus rapide que le gcc actuel pour un test particulier. J'ai trouvé un bogue du côté du pouce lors de l'utilisation de mon émulateur de pouce (thumbulator.blogspot.com) qui a été rapidement corrigé. La meilleure partie de llvm est qu’il s’agit par défaut d’un compilateur croisé, aucun travail supplémentaire ni expérience de la construction n’est nécessaire. Dans les années à venir, je les vois couper plus profondément dans gcc et passer gcc pour la compilation / intégration croisée.

J'ai essayé l'outil code-rouge une fois avec la carte lpcxpresso, le résultat final est que je n'utilise certainement jamais de code-rouge et je me demande si nous devons également ajouter la liste noire lpc. ymmv. Si vous devez utiliser un outil de paiement, je n’utiliserais Keil que parce qu’ils ont été achetés par arm et que le compilateur Rvct fait partie du paquet. Bien sûr, le code source est une maison payante si vous ne respectez pas les limitations légères ou si vous choisissez d’obtenir une assistance, étant donné que gcc dispose de la meilleure assistance, de loin de tous les compilateurs. Il n'y a pas si longtemps, lorsque j'ai été capable de les essayer, les outils et les outils de bras ont fait voler en éclats gcc en ce qui concerne la qualité du code produit. Certaines versions de 3.x génèrent un meilleur code que 4.x, elles ne semblent pas s'améliorer à chaque version, mais elles l'ont fait ou peut-être que la source de code a ajouté le support de thumb2 il n'y a pas si longtemps, ce que les versions 3.x ne font pas Je n'aurai pas.

J'utilise le logiciel Rowley pour le développement ARM et MSP430:

http://www.rowley.co.uk

C'est excellent. Cortex-M3 est pris en charge.

J'utilise le débogueur edu Yagarto + Eclipse + J-link. (Chaîne d'outils Gnu)

http://www.yagarto.de/

J'ai eu un bon succès en utilisant les chaînes de compilation / débogage IAR pour mon développement ARM. Ils offrent des outils de développement relativement stables avec un environnement Embedded C ++ (ce qui semble plutôt rare). - En fonction de la taille de votre base de code, ils proposent également d'excellents "kits KickStart" matériels / logiciels avec des versions limitées en taille de code de leurs outils.

IAR est excellent, et si vous travaillez dans de petits projets, il existe une édition gratuite de kickstart limitée à 32K de la taille du code. Les mises à niveau de taille sont cependant un peu chères je crois. Ils viennent également avec des tonnes de bons exemples de projets, généralement plusieurs pour chaque famille de processeurs.

J'ai passé les deux derniers jours à bien configurer la chaîne d'outils GNU CodeSourcery pour le micro EFM32G sous OS X. Cela en valait la peine. Comparé à de nombreux débogueurs basés sur une interface graphique que j'ai essayés (principalement basés sur Eclipse); Makefiles, GCC et GDB sont un rêve devenu réalité; De plus, tout fonctionne à partir de mon terminal Linux ou Mac.

L'adaptateur J-Link intégré à la carte est le seul élément qui pèche. Le programme GDBServer Windows et Linux de J-Link est une source fermée. Pire encore, la version Linux est BEAUCOUP plus en retard. Donc, pour que GDB fonctionne, je dois exécuter une image Windows VMWare dont le seul but est d’exécuter le GDBServer (car celle Linux est en panne).

Et en plus de ne pas fonctionner correctement, le serveur GDB basé sur Linux de J-Link se lie à 127.0.0.1 et écoute UNIQUEMENT les paquets avec cela comme destination; il faut donc jouer avec iptables et le transfert pour le connecter à partir d’une machine distante. Ridicule; Segger doit se débrouiller.

J'utilise QtCreator et GNU Tools ARM Embedded. Fonctionne bien.

Avantages:

• Totalement gratuit (et open source)
• QtCreator est un excellent IDE C ++ moderne avec complétion de code, hyperliens de symboles, refactoring, etc.
• QtCreator prend en charge le débogage sans système d'exploitation (oui - vous pouvez placer graphiquement des points d'arrêt, un code d'étape et des variables d'inspection). (Nécessite un lien JTAG ou SWD vers votre MCU, mais ce n’était pas aussi difficile que je le pensais.)
• Pas basé sur Eclipse ou Eclipse.

Désavantages:

• Le support Baremetal est très nouveau et j'ai eu quelques problèmes avec lui - surmonté éventuellement avec l'excellente aide de l'auteur sur la liste de diffusion QtCreator.
• Peut-être un peu plus difficile à configurer que Keil ou le code rouge.

Lorsque tout est configuré correctement, je peux cliquer pour créer un point d'arrêt dans mon code, puis cliquer sur le bouton "déboguer". Il compilera, clignotera, exécutera et mettra en pause le point d'arrêt dans environ 5 secondes (et vous rendra simultanément furieux si vous devez revenir à l'IDE "Arduino").

Je travaille actuellement sur un didacticiel expliquant comment configurer cela avec une autre puce ARM - le nRF51822 basé sur Cortex-M0.

J'utilise des outils CooCox, il est excellent mais gratuit à utiliser, pas de code limité. http://www.coocox.org/

J'utilise arm-eabi-gcc et la chaîne d'outils qui l'accompagne, installée via le script de chaîne d'outils Summon Arm . Le script configure l'environnement pour effectuer du travail à nu sur le système ARM. Son source libre et ouverte et tout cela et a fonctionné de manière fiable pour moi. J'ai aussi utilisé IAR pour cela, et c'est certainement mieux car cela vous permet de faire un débogage beaucoup plus convivial et de faire les choses à la manière IDE, mais dans l'ensemble, je me sens plus à l'aise avec gcc, si ce n'est pour aucune autre raison ne devez justifier la dépense à personne.

(Je n'ai jamais vraiment travaillé sur l'utilisation de gdb, mais je n'ai jamais été vraiment habitué à utiliser un débogueur ou à en avoir un de toute façon, alors je ne suis pas sûr d'être qualifié pour en juger.)

J'utilise Emprog ThunderBench . C'est excellent, probablement le meilleur que j'ai jamais utilisé.

Ce que j’aime le plus, c’est qu’il s’agit, en même temps, d’un compilateur de cortex C / C ++ ARM , d’un débogueur et d’un IDE.