De l'Arduino au langage C standard avec AVR Studio

[invite3c199cf9]

Bonjour Jean-Marie45,
Merci pour ce lien intéressant.
J'ai AVR Studio 4 et 6.1, mais pas la 5.
Avec la version 4 l'AVRISP MKII est bien reconnu pour la programmation ISP, mais pas pour le mode PDI.
La version 6.1 autorise les deux modes.
-----

[laveplusblanc]

Bonjour,
Je ne sais plus très bien quel est l'objectif de ce post :comprendre les mutex ou apprendre le c ou transformer un usbasp en ISP mkII (quel intérêt?...).

Je peux cependant recommander un très bon livre que j'ai acheté il y a quelques années : http://www.elektor.fr/programmation-...isc-avr-french . Sur cette page, vous prouvez télécharger un zip qui contient les programmes expliqués dans le livre.
L'auteur se base sur un atmega 32 (par exemple la carte à 5€ de jean marie au poist #177), c'est vrai un peu vieux, et une sonde jtag ice 7€ (mon post #80) avec studio 4 et cela fonctionne aussi sous linux/wine.
Les périf des atmega sont assez compatibles, donc un code atmega 32 sera très facilement porté sur 328 ou 1284

LVPBL

[invite3c199cf9]

Bonjour,
Je ne sais plus très bien quel est l'objectif de ce post :comprendre les mutex ou apprendre le c ou transformer un usbasp en ISP mkII (quel intérêt?...).

En ce qui concerne le programmateur, c'est moi qui ai ajouté une verrue à ce fil en attirant l'attention sur son choix. Je dis juste que quitte à se lancer dans ce projet, il vallait peut-être mieux choisir un programmateur compatible PDI si les gens veulent ensuite évoluer vers les ATXmega. C'est tout, cette parenthèse peut être refermée !

[invitedca01a58]

Hello lpt1com2
Juste avant de refermer la parenthèse du clonage de l'AVRisp mkII, j'ai préparé un dossier expliquant comment s'y prendre et contenant les fichiers de firmware nécessaires. Lien en message privé.

Hello laveplusblanc
Merci pour ton lien vers le livre. Cependant, la pub dit ceci: "Attention, ce livre n'est pas un ouvrage d'initiation à la programmation en C. Il permet à un programmeur en C de s'attaquer à des microcontrôleurs."
J'ai l'impression que le livre renseigné par Mourad correspond mieux aux débutants en C que nous sommes. De nouveau, lien en message privé.
Bonne idée de rappeler que l'ATmega32 peut être programmé et débuggé avec une sonde JTAG pour même pas 6€. Malheureusement, l'ATmega328 de l'Arduino UNO ne le permet pas. Je crois que cela vaut la peine de s'initier au debugging in situ avec une sonde JTAG. L'ATmega32, sa petite platine et cette sonde JTAG constituent la solution la plus abordable financièrement. Les autres platines ne sont pas beaucoup plus chères mais la sonde JTAG renseignée ne fonctionne pas sur les µC plus gros, ni sur Studio6. Personnellement, je serais d'accord de démarrer sur l'ATmega32.

[laveplusblanc]

Bonsoir, Jean Marie

Je pense qu'il y a deux deux concepts dans la dénomination "apprendre à programmer les AVR en C":
1. Apprendre le langage C en tant que tel (type de variables, syntaxe, fonctions, etc ...). Le C étant quelque chose d'assez standardisé, on trouve ne nombreux cours d'initiation (en français) sur le net. Et si vous utilisez déjà arduino, vous devez déjà en avoir des bonnes notions. De plus, le C utilisé pour les µC ne fait pas appel à des fonctionnalités avancées (pas de "printf" ou de "malloc" ou..). Le C n'est pas spécifique à un CPU.
2. Apprendre à configurer et utiliser les périphériques ( Ports, ADC, TWI, timers, uart, interruptions, ...) en C pour divreses applications pratiques et structurer correctement les programmes, ce qui je pense est le sujet des deux livres. D'autre part, je ne vois pas que le livre de Mourad aborde avrstudio et le debug.
Cette "mise en garde" du livre élektor était due au fait que nombreux débutants croyaient apprendre les notions de langage C avec ce livre, alors que il traitait de l'application spécifique de ce ce langage aux AVR.

Finalement, pour ce qui concerne l'AVRISP mkII, rappelons qu'il ne fait pas de debug, et si l'USBasp n'est pas supporté par avrstudio, il existe un avrdude qui est un excellent utilitaire de programmation standalone et utilisé par de très nombreux amateurs.
J’utilise aussi Avarice comme serveur GDB avec des sondes JTAG ICE mkI et MKII.

LVPBL

[mkh.mourad]

Hello lpt1com2
Juste avant de refermer la parenthèse du clonage de l'AVRisp mkII, j'ai préparé un dossier expliquant comment s'y prendre et contenant les fichiers de firmware nécessaires. Lien en message privé.

bonsoir Jean-Marie, je suis interessé par le clonage de USbAsp vers un AVRisp.
j'ai fais une commande d'un USBAsp, et d'un programateur universel MiniPro TL866CS, Arriveront la fin du mois.
j'aime bien savoir ta methode de faire.
merci

[invitedca01a58]

Hello laveplusblanc

Chaque personne inscrite à ce thread a un taux variable de connaissance en C standard et en configuration des périphériques des Atmegas. Personnellement, ce sont plus les connaissances générales en C qui me manquent, mais également certaines connaissances spécifiques aux ATmegas.

---

J'ai mis ma bibliothèque AVR en ligne. A ceux qui sont intéressés, j'enverrai le lien en message privé.

---

Je viens de recevoir mon nouveau USBasp. Celui-là je ne vais pas le transformer en AVRisp mkII mais le conserver comme USBasp pour permettre de faire des expériences avec les deux programmateurs.

Pour utiliser un USBasp sous Windows, il faut installer un Driver.
Si on veut pouvoir utiliser à la fois l'USBasp et l'AVRisp mkII, l'installation des drivers est un peu plus délicate. Des informations sont données sur une page de mon blog, sur une page d'AVRfreaks et sur une page d'aide de BASCOM (faire "search" libusb).

[invitedca01a58]

Hello Mourad
Que vas-tu faire avec un MiniPro TL866CS ? J'imagine que ce n'est pas seulement pour programmer nos petites expériences sur ATmega.

[mkh.mourad]

Le Tl866cs est un tres bon programmateur universel qui programme une large gamme de memoire eprom et eeprom ansi que les microcontroleurs et autres circuit intégré programmable. Mon principal usage serai l'archivage de eeprom et de eprom utilisées dans les manoeuvres d'ascenseurs. C'est un usage professionnel, mais ca n'empêche pas qu'il m'aiderait à la programmation de mes avr ou eeprom personnels.
Il a un tres bon rapport qualité prix, ca reste du chinois mais bien fait.

[invitedca01a58]

J'avais commandé une petite platine de conversion 10 pin --> 6 pin pour programmer mon Arduino avec l'AVRisp mkII. Je viens de la recevoir. Cette platine fonctionne à merveille et remplace avantageusement le petit adaptateur que je m'étais fabriqué.
Donc, pour programmer le µC de l'Arduino à l'aide de Studio, j'utilise la série suivante : Port USB du PC --> clone AVRisp mkII --> câble plat à 10 brins --> adaptateur 10 pin - 6 pin --> prise ICSP de la platine Arduino.
La platine reçoit maintenant son alimentation par la prise ICSP et cela ne cause aucun ennui.

[invitedca01a58]

Aujourd'hui, j'ai installé (avec quelques difficultés) le driver libusb0 pour l'USBasp, ainsi que le filtre libusb0 pour l'AVRisp mkII.
Après cela, j'ai vérifié que l'AVRisp mkII était toujours bien reconnu par Studio.
J'ai également vérifié que le logiciel AVRdude est capable de se servir de ces deux programmateurs pour lire et écrire les mémoires de l'ATmega328P de mon Arduino UNO par la prise ICSP. Tout cela fonctionne sans problème.

Il y a un petit temps, je suis tombé sur un logiciel sympa qui se débrouille très bien pour mettre AVRdude en oeuvre sous windows. Il s'agit de AVRDUDESS – A GUI for AVRDUDE. Il est capable d'accepter des quantités de programmateurs, et en particulier USBasp et AVRisp mkII et détecte lui-même le nom du µC. Il peut évidemment écrire et relire toutes les mémoires, y compris les fuses. Cerise sur le gâteau, il est gratuit.

[invitedca01a58]

AVRDUDESS est même capable d'envoyer votre fichier .hex compilé dans le µC de la même manière que l'IDE Arduino, c'est à dire directement par le port USB de la carte Arduino (mais 10 x plus vite). Voici comment faire pour l'Arduino UNO R3.

1. Choisir "Arduino" comme programmateur (cfr photo ci-dessous).
2. Indiquer le Port de la carte Arduino
3. Cliquer sur "Detect" pour lire le nom du µC
4. Indiquer quel fichier vous voulez flasher et cocher "write"
5. Choisir de degré de verbosité (= détail des actions effectuées)
6. Cliquer sur "Program!"

Au fur et à mesure que vous précisez des paramètres, ils s'inscrivent dans le fenêtre située sous "Program!". Ce sont les paramètres qui seront transmis en ligne de commande à AVRdude. Dans mon cas, les paramètres sont -c arduino -p m328p -P COM5 -U flash:w:"D:\Mes Documents\Assembleur\INIT\INIT .hex":a
La fenêtre noire indique les actions effectuées, leurs résultats et les erreurs éventuelles.

C'est grâce aux indications de ce site que j'ai réussi à flasher un fichier compilé par Studio avec AVRDUDESS. De cette manière, un programmateur externe n'est pas nécessaire (à condition que le bootloader d'Arduino soit toujours présent).

[invitee2def47b]

Bonjour Jean-Marie,

Superbe travail !!! Merci beaucoup pour les explications très claires.
Du coup, y-a-t-il encore un intérêt à transformer l'USBasp en AVRisp mkII?

[mkh.mourad]

Bonjour,
AS6 accepte que AVRisp mkII cloné et non le USBASP. Je vois que AVRisp mkII est supporté plus que le usbasp.

[invitee2def47b]

Bonjour Mourad,

Merci pour ta réponse.

> AS6 accepte que AVRisp mkII cloné et non le USBASP

On ne peut pas générer les fichiers .hex avec Atmel studio 6 puis programmer avec AVRdude?

Si ce n'est pas le cas, je vais donc commander 2 USBasp et en transformer un.

[mkh.mourad]

C'est le compilateur avr-gcc qui génère le fichiex hex, que tu sois sous AS4 ou AS6 ou même directement en ligne de commande, tu aurais en sortie final un fichier .hex pour le flash et un autre pour l'eeprom interne.

[invitedca01a58]

C'est vrai que AVRisp mkII est commandé depuis Studio (aussi bien 4 que 6). USBasp n'est pas intégré à Studio. Mais, comme tu le proposes, Adam, Studio compile de son côté le programme en fichier hex et rien n'empêche d'avoir AVRDUDESS ouvert derrière Studio. Si on veut flasher le programme dans le µC, on clique en bas de l'écran sur l'icone de AVRDUDESS et il apparaît à l'écran à la place de Studio. Après flashage, on reclique sur l'icone de Studio et on revient dans le programme C. Je ne vois donc pas de grande différence entre les deux programmateurs. J'ai l'impression qu'ils sont capables de faire exactement les mêmes tâches.

Si on utilise une carte Arduino pour les expérimentations, l'AVRisp mkII ne peut programmer que par la prise ICSP. Cette programmation efface le bootloader. Si on veut charger un programme avec l'IDE Arduino (par exemple un programme trouvé sur Internet), il faut d'abord recharger le bootloader.
Si on travaille avec AVRDUDESS et l'USBasp, c'est pareil. Le bootloader est effacé.
Si on travaille avec AVRDUDESS sans l'USBasp, donc directement par la prise USB, le bootloader est préservé. On peut donc passer directement d'un programme compilé dans Studio à un programme Arduino compilé dans son IDE sans rien faire de spécial. Le revers de la médaille est que le bootloader occupe une (petite) partie de la mémoire flash.

---

Vous vous souvenez que j'ai un Atmel-ICE, c'est à dire une sonde de débugging in situ. Je n'ai pas encore pu l'expérimenter car je n'ai pas de platine d'expérimentation avec un ATmega comportant une fonction JTAG. C'est pour cette raison que j'avais fait un petit tableau de comparaison de divers ATmegas.
La platine pour ATmega32 me plaisait bien car elle a un connecteur ZIF qui permet d'échanger très facilement les µC. La platine MEGA2560 me plaisait aussi beaucoup car c'est le µC le plus puissant. Par contre, je me suis trompé dans les pin I/O. Il y a bien 86 pins I/O sur le chip mais Arduino n'en a câblé que 54 vers les connecteurs. Donc, pour les pins, la 2560 est quasi équivalente à la platine ATmega128.

Dans mon petit tableau, j'ai oublié de mentionner un µC : l'ATmega1284. Il est pratiquement équivalent à l'ATmega128 sauf quelques différences : Le 1284 existe en package 40 pins PDIP et il comporte 16 Ko de mémoire RAM (pour les variables) au lieu de 4 Ko mais le 128 est capable de commander en plus 64 Ko de mémoire externe.
Rien n'empêche de mettre un ATmega1284 sur la petite platine de l'ATmega32 car les pins sont identiques, mais à y regarder de plus près, je pense que les pins AREF et AVCC n'ont pas de connecteur externe. Si nécessaire, il n'est pas impossible de bricoler quelque chose. Je crois que je vais donc me commander cette petite platine pour mettre en oeuvre un ATmega1284. Une alternative possible est cette petite platine qu'on peut commander comme PCB nu et lui souder alors un support ZIF mais je crois que je vais en rester à la platine de l'ATmega32

[laveplusblanc]

Bonsoir, Jean Marie

Tout d'abord félicitations pour le blog qui se remplit de jour en jour (et d'autant plus que j'ai grandi - soit une vingtaine d'années- à Arlon).
Je me posais aussi la question de l'intérêt de modifier un usbasp en ISP MKii mon post n°?) sachant qu'il y a des programmes (avrdude, avrisp, ..) qui font très bien le boulot.
Autres commentaires :

• Je ne vous conseille pas la petite platine RKAT40c, il n'y a pas de prise Jtag, donc je ne vois pas l'intérêt.
• C'est vrai qu'un mega 1284 se met très bien sur une platine de test Atmega32. J'ai déjà fait la manip, ayant cette platine ci
• Atmel-ICE ne fonctionne pas avec AVR Studio 4.
• Je ne pense pas qu'Atmel-ICE soit supporté par AVaRice (serveur GDB)
• avr-gcc ne produit pas de fichier hex, mais ELF. Cependant, l'utilitaire avr-objcopy permet de changer facilement de format. Apparemment, AVRdude accepte les "elf" mais je n'ai pas essayé.
• Attention quand vous ferez un premier essai de debug de bien s'assurer qu'il y a l'option -gdwarf-2 à la compilation

Finalement, de mon opinion personnelle, je ne pense pas que les µC 8 bits sur-vitaminés (atxmega, atmega256, ..) soient de bons choix. Les µC 8 bits ont leurs limites, et quand on commence à être confronté à des problèmes de mémoire ou de puissance de calcul.. il vaut mieux passer directement à des µC 32 bits plutôt que de perséverer dans des voies sans issues.

Mon matériel personnel: AVR Jtag ICE mkI, AVR Jtag ICE mkII, AVR ISP Mkii, USBasp, diverses cartes de test et je travaille sous linux/Eclipse (non recommandé pour les débutants).

LVPBL

[invitedca01a58]

Hello laveplusblanc

En fait, je n'habite pas Arlon même, mais un petit village que tu connais sûrement à la frontière luxembourgeoise : Sterpenich. Heureusement qu'il y a Internet car j'aurais peu de chance de rencontrer des amateurs de µC dans le village.

Pour la platine d'expérimentation, c'est vrai que c'est facilement faisable soi-même, du moins si on a ce qu'il faut pour graver un PCB. J'ai de quoi graver mais je ne peux probablement pas battre le prix des chinois. Je commande donc la petite platine de l'ATmega32.

Pour Atmel-ICE, j'ai encore tout à découvrir. Je n'ai encore aucune idée de son fonctionnement. Donc, le moment venu, un petit coup de main ne sera sûrement pas superflu.
C'est pareil pour les "elf". Je ne sais pas à quoi ça sert en-dehors du "Seigneur des Anneaux"

Chapeau pour linux/Eclipse. J'ai déjà essayé d’entrebâiller la porte de Linux, mais tout ce qu'il faut mémoriser comme paramètres à chaque fois qu'on veut lancer une commande me rebute. Si j'avais encore 30 ans, ce serait peut-être possible mais à mon âge, ça ne marche plus. Pourtant, l'idée d'Open source et de partage me plaît bien.
..... peut-être dans une autre vie

[invitee2def47b]

Bonjour à tous,

Tout d'abord merci pour vos réponses. Je sais maintenant ce que je vais commander, sauf au niveau de la platine. Est-il est toujours question d'une plateforme commune ou du moins d'un µC commun? Si oui, comment se met-on d'accord? Je propose que ceux qui souhaiteraient un même µC se signalent déjà pour qu'on puissent se recenser. Ensuite nous pourrions avancer chacun un classement par ordre de préférence avec quelques arguments si on le souhaite?

Sinon, je vous indique un petit lien vers un document qui met en lumière quelques aspects intéressant du C, notamment pour moi le 4) qui m'a permis de comprendre la déclaration des registres dédiés dans les fichiers .h Le reste est agrémenté d'exemples clairs et se lit bien, même en sirotant une margarita

[laveplusblanc]

Bonsoir, Adam

Changez votre margarita pour une bonne Orval, ce tutorial C est du pic et donc du n'importe quoi.

Le premier tutorial que trouve google est assez bien fait : astro.ens.fr/osae/ccc.pdf
et ma référence personnelle est : http://it-ebooks.info/book/971/ mais pas (si) facile à lire.

Regardez aussi la documentation gcc : https://gcc.gnu.org/ , celle de avr-libc : http://www.nongnu.org/avr-libc/user-.../overview.html

LVPBL

[laveplusblanc]

PS: Je ne vais pas racheter du matériel, ayant un peu de tout (quoique si Jean Marie me dit où il a trouvé son Atmel-ICE à 49€ ...) mais j’essaierai de vous faire part de mon expérience: par exemple compilation d'avr-gcc à partir e gcc, FreeRTOS sur avr, ..
LVPBL

[invitee2def47b]

Changez votre margarita pour une bonne Orval

Cher LVPBL,
Je ne suis sous l'influence ni de l'une ni de l'autre.

ce tutorial C est du pic et donc du n'importe quoi.

Je n'ai jamais dis que c'était un tutoriel. Je n'ai pas le recul nécessaire en C pour juger du bien fondé (ou de son contraire) de ce document, mais il me semble que vous jetez un peu le bébé avec l'eau du bain en le décriant dans son ensemble. Je n'ai regardé que les exemples du 2) qui sont assez parlants et surtout le 4) qui explique très clairement une syntaxe permettant d'allouer une adresse fixe à une variable. J'avais rencontré cette syntaxe (avec l'emploi de volatile en plus pour éviter tout tripatouillage du compilateur) en farfouillant les fichiers .h relatifs aux déclarations des registres dédiés qui ont bien entendu des adresses fixes, et je n'avais pas trouvé d'explication ailleurs à ce sujet. Ici c'est en français et expliqué pas à pas. Ça m'a donc semblé intéressant au moins à ce titre, ce que j'avais annoncé clairement: "...qui met en lumière quelques aspects intéressants du C".
J'ai bien vu que les exemples étaient basés sur un PIC (et avec un compilateur donné), mais lorsque des directives ne sont pas standard, l'auteur l'indique. Les exemples du 2) me semblent généralisables et les explications du 4) valides.
Pour le reste encore une fois je ne pourrai juger.

Merci pour les liens. Je les ai parcouru et ils m'ont l'air intéressants et synthétiques. Pour l'instant, je me limite au C pour les systèmes embarqués avec ce cours, mais il est plus fourni de sorte que je vais peut être changer mon fusil d'épaule.

[laveplusblanc]

Re-bonsoir Adam
Je ne vais pas polémiquer sur ce cours mais, si vous débutez en C, mon intention était de vous mettre en garde contre le nombreuses erreurs, raccourcis, imprécisions, etc de ce document qui peuvent durablement induire en erreur par exemple :

rom const unsigned int i =1234 ;

je n'ai jamais vu ça ("rom const") en C

En C le type des entiers naturels (integer) est codé sur 16bits

C'est pas vrai, le C ne spécifie pas la longueur de la représentation des variables.

L'inconvénient des variables globales "dynamiques" est leur temps d’accès.

Ce n'est pas vrai pour les uC qui ont un (adressage sur) pointeur de pile (avr par ex).

Le C ne sait pas traiter les interruptions. Lors de sa standardisation, la programmation événementielle était beaucoup moins développée qu’aujourd’hui

et ça c'est vraiment du n'importe quoi.

Bref, je ne continue pas, mais sur deux pages, ce n'est pas mal!

Par contre, le cours de developpez.net a l'air bien.

LVPBL

[invitedca01a58]

Hello Adam et laveplusblanc

Merci pour vos liens de documentation. Je rappelle que ceux qui seraient intéressés par ma bibliothèque AVR et C n'ont qu'à me le dire. Je leur enverrai en message privé le lien de mes documents pdf qu'ils pourront télécharger à leur guise.

En ce qui concerne les exercices et expérimentations que nous pourrons faire, il est évidemment pratique que nous travaillions sur le même µC. En effet, voici un exemple : il serait embêtant que quelqu'un propose un programme faisant appel à 2 timers 16 bits, alors que certains sont sur un µC qui n'a qu'un seul timer 16 bits. Donc, je pense qu'un µC commun est un avantage.. Une platine d'expérimentation commune a moins d'importance, à partir du moment où toutes les pins I/O sont accessibles. Par exemple, il est possible de mener les expériences sur breadboard mais c'est évidemment moins pratique qu'une platine qui dispose de son alimentation, d'un reset, d'un quartz, du ou des connecteurs de programmation (et éventuellement de débugging) et des connecteurs de ports I/O.

Pour ma part, je plaide pour l'ATmega1284. Mes arguments sont de 2 ordres :

• Il s'agit d'un AVR 8bits parmi les hauts de gamme, avec des mémoires flash, RAM et EEPROM confortables, des périphériques nombreux et 4 ports I/O 8bits complets (par comparaison, avec le 328 de l'Arduino UNO, seul le port D est complet. Le port B perd 2 pins pour le quartz et le port C n'a que 7 bits.
• Il existe en package PDIP, ce qui permet de l'insérer facilement sur une breadboard, un soquet ou un connecteur zif.

Il reste possible de travailler avec des µC différents. Il suffit de se limiter à n'utiliser que le PPCM (le Plus Petit Commun Multiple) et que chacun prépare son header file .h avec les #define pour que les variables utilisées dans le programme soient indépendantes de la configuration hardware.

@ laveplusblanc, j'ai acheté mon ATMEL-ICE chez Farnell (Belgique). Il existe également chez Farnell France. J'ai dû ajouter une autre fourniture pour atteindre 50€ car c'est la condition pour pouvoir commander et obtenir la livraison gratuite (en Belgique).
J'ai pris la version basic. Le câble fourni comporte un connecteur 2x3 broches femelle pour programmation ISP et un connecteur 2x5 broches femelle pour le JTAG. Problème : ce connecteur est au pitch 1,27mm. Du coup, je dois me bricoler un petit adaptateur pour passer au pitch 2,54mm. (la version avec tous les câbles est à 82€).

@ Adam, je viens de voir ton dernier message. Le livre que tu renseignes paraît intéressant. Je l'ai aussi ajouté à ma bibliothèque online, ainsi que les bouquins de laveplusblanc.

[laveplusblanc]

[

Pour ma part, je plaide pour l'ATmega1284. Mes arguments sont de 2 ordres :

J'en ai quelques uns. programmation/debug avec mon JTAG Ice mkii

J'ai pris la version basic. Le câble fourni comporte un connecteur 2x3 broches femelle pour programmation ISP et un connecteur 2x5 broches femelle pour le JTAG. Problème : ce connecteur est au pitch 1,27mm. Du coup, je dois me bricoler un petit adaptateur pour passer au pitch 2,54mm. (la version avec tous les câbles est à 82€).

Je me souviens en avoir vu sur ebay.

LVPBL

[mkh.mourad]

bonsoir tout le monde,
je n'ai pas la chance que vous avez en Europe, moi je suis au Maroc.
on as du mal à faire des commandes d'un fournisseur en dehors du pays, l'administration douanière impose beaucoup d'obstacle pour un simple particulier peut commander quoi que ce soit, 22.5% comme droit de douane et des procédures complexe pour l'envoie de l'argent en devise à l'étranger.
on dois attendre qu'une petite entreprise le fasse pour nous, ou un ami qui vient de l'étranger nous apporte ce que nous voulons avoir par de petites quantités non encombrantes pour que les douaniers ne le harcellent pas.
donc j'ai de la chance que j'ai une arduino mega2560. un petit commerçant fais des commandes de China, a travers USA, et il connais comment faire avec les douanes à accepter de m'apporter deux USBAsp et un MiniPro TL866CS.
donc pour moi je reste sur mon Arduino Mega2560 et je vais cherche dans la casse si je trouve un atmega32 ou autre avr. je vais continuer avec vous en respectant votre choix, et je vous promis de ne pas utiliser mes 4 TIMERS 16bits

[invitedca01a58]

Hello Mourad

C'est vrai que l'approvisionnement est plus facile en Europe.
Je ne sais pas si le courrier est surveillé entre l'Europe et le Maroc mais nous pourrons peut-être parfois t'aider en t'envoyant quelque chose que tu ne peux te procurer sur place.
Pour le 2560, c'est le plus gros des ATmegas. Tu devras te priver de certaines de ses capacités. Mais sur tes 4 Timers 16 bits, tu pourras au moins en garder 1 car même l'ATmega 8 en a un !
A ce propos, il ne faut pas rigoler de l'ATmega 8. Il va aussi vite que les autres. Il a autant de pins que l'ATmega328 et presque les mêmes périphériques. Bon, il a moins de mémoire, mais cela n'a guère d'importance pour une initiation. C'est d'ailleurs avec un ATmega 8 que j'ai démarré.

[invitee2def47b]

Bonsoir à tous,

Je suis partagé entre l'ATmega 2560 ( il y en a avec un kit de 30€ à 60€ selon le contenu) ce qui serait pratique parce que je ne sais même plus où est mon fer à souder, et le 1284 qui serait bien aussi parce que disponible en boitier non CMS.
Je vais me contenter de la simulation dans un premier temps, du moins si j'arrive à faire assez de place sur mon disque dur (et s'il tient parce qu'il donne des signes de fatigue) jusqu'à ce que je reçoive le nouveau et que je me décide pour un modèle, mais je crois que je vais me ranger pour le 1284 sur carte à support ZIF.

[mkh.mourad]

merci bien c'est très sympa,
si j'ai besoin je vais vous donner signe.
si vous me permettez de vous consigner le ATMega 2560. c'est très intéressant comme microcontrôleur 8bits sur l'arduino Mega, même si la carte Arduino ne permet pas l'acces a tous ces pins. mais on a au moins des ports IO digital complets de 8bits comme le PORTA,PORTB, PORTC, PORTL dont les deux port analogique complet :PORTF et PORTK.
en plus on a des port incomplet: le PORTH(6 bits), PORTG(4 bits) PORTE(5bits), PORTJ(2bits) , PORTD(5bits).
parmi les 100 pins physiques du µC, seul 16 qui ne sont pas connectés!
il y a sur la carte un Port CISP pour la programmation ISP direct du µc sans le biais du bootloader.
la cerise sur le gâteau: c'est que le ATMega accepte l'interface JTAG:
( il n ' y as pas de port dédié, il faut le concevoir )

Arduino Mega Pin # Dragon JTAG Pin #
+5v +5v : 4
GND GND : 2 ou 10
4 (PORTF4) TCK : 1
5 (PORTF5) TMS: 5
6 (PORTF6) TDO: 3
7 (PORTF7) TDI: 9
le 6,7 et 8 non connecté.

donc l'arduino méga est une très bonne platine, programmable par le USBAsp ou le AVRISP MK_II par le port ICSP et on plus on peut la debugger avec AVR Dragon ou AVR JTAG ICE ( il faut activer le fusible JTAGEN )
voila une expérience réussie de debug : http://forum.arduino.cc/index.php/topic,96401.0.html