Bonjour a toutes et a tous
comme le titre, qui peut me donner la difference entre le pic et l'atmel? je connais l'atmeg et travail avec mais le Pic?
Merci pour les reponses
Claude
-----
Bonjour a toutes et a tous
comme le titre, qui peut me donner la difference entre le pic et l'atmel? je connais l'atmeg et travail avec mais le Pic?
Merci pour les reponses
Claude
le meilleur des procs étant celui dont on sait se servir.....
continue avec l'Atmel !
Hallo Pixel, Tu veut dir ils sont pareil ?
pas du tout , c'est même un concept assez différent....
je ne fais pas de débat , que les modos n'apprécient pas.
pour comparer si tu connais ATMEL , voilà le site de référence sur les PICs :
http://www.abcelectronique.com/bigon....php?par=3250f
Surtout que Grochip et Atmel font aussi des micros modernes et pas seulement des fossiles comme les PIC16 ou dans une moindre mesure AVR, alors, de quel PIC ou Atmel tu parles ?...
Claude,
La question est : pourquoi veux-tu éventuellement changer ?
Si tu n'as aucune raison de changer, reste avec ce que tu connais.
a+
Bonjour a tous, a vrait dire he be voulais pas changer, seulement je trouve presque pas d'AVR et j'avais l'impression due m'aitre trompe sans Mon choix
le micro qui va bien c'est celui qui repond au besoin à moindre cout (cout materielet de programmation , facilité de developpement )
mes vieux 16F en basic(avec picsimulator ) me conviennent parfaitement pour mon utilisation (codage et decogage infrarouge , commande de servo moteur , affichage lcd ..) et de plus le 40 pattes coute 3euros
j'utilise arduino pour communiquer entre le monde exterieur et mon pc(avec processing sur le pc et arduino en usb) car c'est pour moi le moyen le plus simple
et je conseil le picaxe pour débuter car sa prise en main est immediate
donc le changement de micro s'impose pour des nouveaux besoins en programmation , pour faire baisser le coût,ou juste par curiosité .
donc conserve ce qui marche
mais ce n'est que l'avis d'un amateur !
cordialement
Alain
Parfois on a besoin d'un périphérique bien spécial, cela décide le micro à prendre.
Parfois le critère est "un mec sur internet a fait quasiment le même projet et le code est disponible en opensource". Là, c'est logique de prendre le même micro que lui. Ou bien tu peux trouver une carte toute faite avec les composants dont t'auras besoin.
C'est souvent le cas avec l'arduino : on trouve du code et des shields pour interfacer à peu près n'importe quoi. Par exemple j'avais besoin de réguler un ventilateur en PWM en fonction du taux d'humidité. Je prends un arduino, un shield LCD+boutons à 5€, le code pour le LCD est fourni, un capteur d'humidité, le code pour lui causer est fourni... ça a été torché en 1 heure...
bonjour bobfuck.
J'ai l'impression d'etre un peut restraint avec la programation de l'arduino ou je me trompe?
L'IDE arduino est à chier : au lieu de faire comme tout le monde et d'utiliser Scintilla, ils ont refait leur propre éditeur de texte en Java.
Heureusement, on peut utiliser une simple makefile, ton éditeur de texte favori, et compiler et programmer le uC avec une ligne de commande. C'est assez simple. Donc on n'est pas restreint par l'IDE.
Quand aux bibliothèques arduino, elles ne sont pas orientées performance, mais rien ne t'empêche d'utiliser directement le hard, il n'y a pas de restriction là dessus.
Enfin, si tu cherches la performance, un 8 bits n'est peut-être pas un choix pertinent...
"C'est assez simple"
si tu pouvez proposer un lien qui explique tout ça se serait sympa .
cordialement
Alain
google arduino makefile, il y a plusieurs tutos
Bonjour,
en fait mettez vous à l'assembleur et cela ira bien mieux!!
c'est toute la différence qui existe entre la haute couture et le pret à porter ou le gatte sauce et le grand chef.
JR
l'électronique c'est pas du vaudou!
L'assembleur de nos jours, c'est utile principalement pour la culture générale...
tu crois que les mecs avec du poil aux pattes qui travaillent dans le "rapide" ( militaire , nucléaire) font
confiance à des compilos approximatifs ?
Bonsoir,
Donnes moi en C pur, sans asm chose truc le code d'un flush de cache ou l'initialisation du stack ou de la MMU ?
Même un boot Linux possède de l'assembleur c'est inévitable car certains codes machine ne sont pas accessible au travers d'une instruction C standard sauf bien sur asm"".
Il ne reste plus beaucoup d'assembleur je le concède mais il en reste et mieux vaut le connaitre, ainsi que l'architecture de la machine, combien de bug soft n'ai je pas démerdé en quelques minutes alors que les équipes soft merdaient depuis des semaines dessus parce que moi, hardeux, je savais comment fonctionnait l'UC!
Bien sur on n'utilise l'assembleur qu'en zone critique ,temporelle ou système (OS), c'est assez faible, par contre les compilateurs doivent être certifiés ou certifiables et la traçabilité C => assembleur donc code machine assurée à 100% . voir DO178 tout çà mis bout à bout conduit à des couts plus que sérieux (l'unité de compte est du coté du M€).
JR
l'électronique c'est pas du vaudou!
Bhaaaa, tout de suite tu t'énerves...
> Donnes moi en C pur, sans asm chose truc le code d'un flush de cache
Ah ben tu peux pas, à moins bien sûr d'appeler la fonction de la librarie qui contient le petit bout d'assembleur nécessaire :
J'ai pas de cache sous la main, alors je te mets son cousin le DMB...Code:static __INLINE void __DMB(void) { __ASM volatile ("dmb"); }
GCC aussi fournit pas mal de fonctions intrinsics pratiques pour les instructions DSP...
Ce que je voulais dire c'est que l'asm est utile seulement dans des cas bien particuliers et assez rares (bootloader, OS, etc) qui généralement sont l'affaire de libraries.
Par contre, le mec qui connaît que dalle à l'assembleur, ben quand son programme rame ou crashe de façon subtile, il va être bien embêté pour regarder le désassemblage... L'asm il faut savoir le lire, c'est ça la culture générale, par exemple le mec qui ne sait pas pourquoi un cmov est plus rapide qu'un branchement n'est pas un programmeur, mais pour ce qui est de savoir coder plus de 10 lignes en asm, c'est du passé ...
La quantité de bugs dans un programme assez gros sera beaucoup moins élevée si il a été écrit et compilé dans un langage adéquat* plutôt qu'en asm...
* = (Pas en C...)
bonjour,
Je rejoins entierement cet avis.
En fait c'est plutot le hazard qui fait le choix, puisqu'au depart on ne connait ni l'un ni l'autre.
et une fois qu'on s'est investi dans un type ou famille , il est difficile de zapper sur un autre choix
Dans le passé j'ai zappé entre du motorola (650x 68xx 68xxx et intel 8080,Z80 80x86 à plusieurs reprises..
sans pour autant pouvoir designer qui etait le meilleur ou le plus facile à maitriser
(en asm ,à cette epoque).
Le langage d'assemblage (assembleur) est captivant, mais demande beaucoup trop d'effort si on veut changer de MCU.
Cela n'empeche pas qu'il faut avoir des notions d'assembleur , meme avec des langage evolues en C
ne serait ce que pour assimiler certaines specificites des registres MCU expliques dans une datasheet .
Il n'est pas rare avec MikroC , et ses jolies bibliotheques toutes pretes,
d'aller fouiller dans le code asm resultant , pour trouver là ou ça coince..
Un programmeur , pur et dur, n'a que faire de savoir ce qu'il y a comme unite centrale dans sa becane
et il est donc concevable, dans ce cas, que l'assembleur soit completement oublié ou zappé.
Hello,
Avec un bon compilateur, oui.
Je n'ai pas l'impression que ce soit le cas de l'IDE Arduino 1.0.6 ... lorsque je compile 'Blink.ino' :
et que je demande la source assembleur à 'avr-objdump.exe -S Blink.cpp.elf', j'obtiens un fichier de 25K (joint) dont voici l'essentiel :Code:// the setup function runs once when you press reset or power the board void setup() { // initialize digital pin 13 as an output. pinMode(13, OUTPUT); } // the loop function runs over and over again forever void loop() { digitalWrite(13, HIGH); // turn the LED on (HIGH is the voltage level) delay(1000); // wait for a second digitalWrite(13, LOW); // turn the LED off by making the voltage LOW delay(1000); // wait for a second }
la boucle led on/off :
et pour digitalWrite ceci ???? :Code:00000100 <loop>: ; C: digitalWrite(13, HIGH); 100: 8d e0 ldi r24, 0x0D ; 13 102: 61 e0 ldi r22, 0x01 ; 1 104: 0e 94 b5 01 call 0x36a ; 0x36a <digitalWrite> ; C: delay (1000); 108: 68 ee ldi r22, 0xE8 ; 232 10a: 73 e0 ldi r23, 0x03 ; 3 10c: 80 e0 ldi r24, 0x00 ; 0 10e: 90 e0 ldi r25, 0x00 ; 0 110: 0e 94 e2 00 call 0x1c4 ; 0x1c4 <delay> ; C digitalWrite(13, LOW); 114: 8d e0 ldi r24, 0x0D ; 13 116: 60 e0 ldi r22, 0x00 ; 0 118: 0e 94 b5 01 call 0x36a ; 0x36a <digitalWrite> ; C delay(1000); 11c: 68 ee ldi r22, 0xE8 ; 232 11e: 73 e0 ldi r23, 0x03 ; 3 120: 80 e0 ldi r24, 0x00 ; 0 122: 90 e0 ldi r25, 0x00 ; 0 124: 0e 94 e2 00 call 0x1c4 ; 0x1c4 <delay> 128: 08 95 ret
Je connais mal l'assembler de l'AVR et les AVR mais il me semble queCode:void digitalWrite(uint8_t pin, uint8_t val) { uint8_t timer = digitalPinToTimer(pin); 36a: 48 2f mov r20, r24 36c: 50 e0 ldi r21, 0x00 ; 0 36e: ca 01 movw r24, r20 370: 82 55 subi r24, 0x52 ; 82 372: 9f 4f sbci r25, 0xFF ; 255 374: fc 01 movw r30, r24 376: 24 91 lpm r18, Z+ uint8_t bit = digitalPinToBitMask(pin); 378: ca 01 movw r24, r20 37a: 86 56 subi r24, 0x66 ; 102 37c: 9f 4f sbci r25, 0xFF ; 255 37e: fc 01 movw r30, r24 380: 94 91 lpm r25, Z+ uint8_t port = digitalPinToPort(pin); 382: 4a 57 subi r20, 0x7A ; 122 384: 5f 4f sbci r21, 0xFF ; 255 386: fa 01 movw r30, r20 388: 34 91 lpm r19, Z+ volatile uint8_t *out; if (port == NOT_A_PIN) return; ... dont je ne trouve pas la fin, même pas certain qu'il s'agisse du bon bout de code :-)
cbi portX, 0
et
sbi portX, 1
en ajoutant les wait/delay ferait le boulot
Me trompe-je ?
============================== ====
Le compilateur GBC (great cow basic) sort ceci
Source
Code:'Chip model #chip mega328p, 16 'Set the pin directions dir PORTB.0 out dir PORTB.1 out 'Main routine Start: 'Turn one LED on, the other off SET PORTB.0 ON SET PORTB.1 OFF wait 1 sec 'Now toggle the LEDs SET PORTB.0 OFF SET PORTB.1 ON wait 1 sec 'Jump back to the start of the program goto Start
Code:;Start of the main program ;A program to flash two LEDs on PORTB, bits 0 and 1 ;Chip model ;Set the pin directions ;dir PORTB.0 out sbi DDRB,0 ;dir PORTB.1 out sbi DDRB,1 ;Main routine START: ;SET PORTB.0 ON sbi PORTB,0 ;SET PORTB.1 OFF cbi PORTB,1 ;wait 1 sec ldi SysWaitTempS,1 rcall Delay_S ;SET PORTB.0 OFF cbi PORTB,0 ;SET PORTB.1 ON sbi PORTB,1 ;wait 1 sec ldi SysWaitTempS,1 rcall Delay_S ;goto Start rjmp START BASPROGRAMEND: sleep rjmp BASPROGRAMEND
Biname
re
Bobfuck je te taquinais un peu , ton dernier message est tout à fait vrai .
Biname : tu as raison avec une led en charge à la masse:
sbi PORTx,BITy
rcall Delay1_64ms
cbi PORTx,BITy
une routine de delais paramétrable en assembleur c'est par exemple çà Attiny ou Atmega @8Mhz:
il y a donc 13 instructions au total.Code:Delay1_64ms: ldi rDelH,HIGH(1640) ldi rDelL,LOW(1640) rjmp DelayZ DelayZ: nop nop nop nop sbiw rDelL,1 ; 2 brne DelayZ ; 2 ret
JR
l'électronique c'est pas du vaudou!
Oui, quand je disais que les libs arduino ne sont pas optimisées pour la performance, c'est à ce genre de truc que je pensais...
Quoique dans le cas assez simple d'un GPIO à la con, ils auraient pu faire l'effort (minime) d'inliner la fonction... Oui mais ! La fonction digitalWrite() fait référence au numéro de la pin sur le connecteur et pas au numéro de port. Donc il faut faire la traduction. Et le C++, étant un langage idiot, ne permet pas de spécifier simplement que si le numéro de pin est une constante connue à la compilation on peut inliner la fonction et la transformer en 1 instruction asm, mais si c'est une variable, alors on peut pas. Enfin si, on pourrait faire de la spécialisation de templates... ou comment se prendre le chou... Et comme l'arduino est fait pour les débutants, voilà.
Les libs ARM Cortex ont la fonction GPIO inlinée donc c'est moins sale. Ceci inverse la pin deux fois de suite :
Le plus long, c'est de charger l'adresse du registre, à cause du mode Thumb... Enfin, la vitesse des GPIO en mode bit-bang à la pougne n'est pas forcément le paramètre le plus pertinent pour choisir un micro !... surtout quand le micro en question a des SGPIO hardware qui envoient plus de 100 Mbit/s par pin...Code:2: f242 3304 movw r3, #8964 ; 0x2304 6: f44f 5180 mov.w r1, #4096 ; 0x1000 a: 50d1 str r1, [r2, r3] c: 50d1 str r1, [r2, r3]
Dernière modification par bobflux ; 08/10/2014 à 19h08.
l'assembleur ça permet de comprendre comment ça marche et ça me parait indispensable même si apres ça on utilise un langage de haut niveau
j'ai commencé par bigonoff pour les pic et je ne regrette pas !
cordialement
Alain
Bonjour a tous,
en definitif la discussion sur la programmation n'aitais pas le theme, mais cette discution et très interessante. dans mes debuts pour ceut qui connaisse j'ai appris a programmer avec un SCMP (1978) non pas avec les Mnemonique comme mov, jp brq, mais direct code comme 35, 64, ect sur une machiene de 512 KB eprom et 256 ram un clavier de 20 touche je crois et un display 7 segments, mais je n'ai jamais reussi a programmer avev pascal, C, ou C++. peut etre parce que la langue Anglaise ne m'etais pas connue mais je comprend bien mieux un systeme comme "mov xx dans y, add 24 move le resulta dans ss en plus je crois que l'on peut mieux manipuler le code qu'avec c ou c++. je ne suis qu'un petit ammateur
Claude
bonjour à tous,
je pense que chaque famille de puce a des avantages et des incovinients.
perso mes pic 16f (qui sont decrit comme vieux par pas mal de monde) me permmettent de faire beaucoup de cartes assez evolué.
ensuite pour réelement faire une comparaison des puces, les atmel doivent etre comparé au pic 18F, car ils sont de la meme génération.
Et une astuces qui me permet de faire des economies, les fabriquants de puces donnes un certains nombres d'echantillons par mois.
Il faut s'inscrire avec un mail pro car les mails communs sont regeté (gmail, hotmail, yahoo, ect).
chez microchip on peux commender jusqu'a 6 puces par mois 100% gratis, ca fait un petit moment que je fait ca et j'en suis actuelement à plus de 50 puces. Je vous laisse faire le calcul des economies.
Je sais que chez atmel c'est aussi possible de le faire mais comme je n'ai pas de matos pour les programmer je ne my suis jamais intéréssé.
au final je rejoint l'ensemble des reponses, si tu as deja ton equipement de programmations et tes abitudes et que tu trouve toujours ce que tu as besoin reste avec ce que tu as.
Moi je me suis equipé pour du pic et je resterai pic car j'ai pas envie de reinvestire du temps et de l'argent pour les atmel.