Pic ou ATMel?

[Claude-23]

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
-----

[PIXEL]

le meilleur des procs étant celui dont on sait se servir.....

continue avec l'Atmel !

[Claude-23]

Hallo Pixel, Tu veut dir ils sont pareil ?

[PIXEL]

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

[A voir en vidéo sur Futura]

[bobflux]

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 ?...

[RISC]

Claude,

La question est : pourquoi veux-tu éventuellement changer ?
Si tu n'as aucune raison de changer, reste avec ce que tu connais.

a+

[Claude-23]

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

[alainav1]

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

[bobflux]

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...

[Claude-23]

bonjour bobfuck.

J'ai l'impression d'etre un peut restraint avec la programation de l'arduino ou je me trompe?

[bobflux]

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...

[alainav1]

"C'est assez simple"
si tu pouvez proposer un lien qui explique tout ça se serait sympa .
cordialement
Alain

[bobflux]

google arduino makefile, il y a plusieurs tutos

[jiherve]

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

[bobflux]

L'assembleur de nos jours, c'est utile principalement pour la culture générale...

[PIXEL]

tu crois que les mecs avec du poil aux pattes qui travaillent dans le "rapide" ( militaire , nucléaire) font
confiance à des compilos approximatifs ?

[jiherve]

Bonsoir,

L'assembleur de nos jours, c'est utile principalement pour la culture générale...

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

[bobflux]

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 :

static __INLINE void __DMB(void) { __ASM volatile ("dmb"); }

J'ai pas de cache sous la main, alors je te mets son cousin le 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é ...

[bobflux]

tu crois que les mecs avec du poil aux pattes qui travaillent dans le "rapide" ( militaire , nucléaire) font
confiance à des compilos approximatifs ?

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...)

[paulfjujo]

bonjour,

le meilleur des procs étant celui dont on sait se servir.....

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é.

[Biname]

Hello,

L'assembleur de nos jours, c'est utile principalement pour la culture générale...

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' :

// 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
}

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 :
la boucle led on/off :

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

et pour digitalWrite ceci ???? :

 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 :-)

Je connais mal l'assembler de l'AVR et les AVR mais il me semble que
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

'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

;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

[jiherve]

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:

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

il y a donc 13 instructions au total.
JR

[bobflux]

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 :

   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]

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...

[alainav1]

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

[Claude-23]

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

[cacoucatatonique]

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.