Atmel vs Microchip

[R-Mario]

Hoy me entere de que existe un aparato llamado fez panda 2 y tiene todos los chiches trabaja a 40 Megas!!! a la miercoles...........................................................

Retardos de nano Segundos NOOOO!!!! Tomatela

PIC como te amo <3

Enamorado de PICs, cuando conoces otras cosas vas cambiando, cuando inicie con el viejo 16f84 tambien decia "Es lo maximo " despues conoci AVR y dije "Es lo maximo " luego conoci los MSP430 que podian funcionar con una celda solar chiquita y decia "Es lo maximo ". Luego toque unos micros de renesas y paso lo mismo, algo me emociono

Luego de tantas emociones quede como la imagen de abajo, por eso ahora ya nada me emociona .


Por cierto no es que Net sea mas facil o mas util es solo que tu te adaptaste bien a el. Es como decir que es mejor borland o visual. Y ahi iniciaba otra guerra

 

[Meta]

Es como decir que es mejor borland o visual. Y ahi iniciaba otra guerra

En lo Borland y Visual he trabajado en los dos. Hubo guerra, al final gana oo pierde depende de mil factores, en mi caso el más que me gusta, ajjajjaja.

En cuanto a los microcontroladores, mejor usar el que dispongas muy fácil de encontrar. Total, ña mayoría lo usamos como aficonados.

 

[Meta]

Holas:

A parte de usar AVR o PIC, ¿alguien de aquí programan ARM?

Si lo han usado, ¿cuál son sus experiencias?

Saludo.

 

[cosmefulanito04]

Ya que levantaste el hilo.

Una duda que surgió de este proyecto, ¿es posible que los PIC18 solo tengan un registro de uso general (que lo llaman registro de trabajo WREG) y necesiten trabajar todo el tiempo sobre la RAM?

Con seaarg estamos tratando de traducir esta rutina en assembler de un AVR:

.global generar_senial
    #define DATA_REG        r31
    #define ACUMULADOR_INF    r24
    #define ACUMULADOR_SUP    r25
    #define X_INF            r26
    #define PASO_BYTE_1        r19
    #define PASO_BYTE_2        r20
    #define PASO_BYTE_3        r22
    #define PORT_SALIDA        PORTC


    generar_senial:            
        movw    X_INF,r24        ;En r27:r26 => PUNTERO "X" => Puntero de la senial                                    
        mov        PASO_BYTE_1,r18    ;En r18 se encuentra el paso más bajo
        clr        DATA_REG        ;Lo uso para almacenar el dato momentaneo almacenado en el vector de la senial
        clr        ACUMULADOR_INF    ;Lo uso de acumulador del "Paso" byte inferior
        clr        ACUMULADOR_SUP    ;Lo uso de acumulador del "Paso" byte superior
        clr        FLAG_INT_REG    ;Limpio el flag de salida!
                                ;Valor del "Paso" de muestreo => en funcion de "f" y los clk's 
    
        loop_senial:
            add        ACUMULADOR_INF,PASO_BYTE_1            ;Sumo el 1er byte del "Paso"                                                                        => 1 Clk    +
            adc        ACUMULADOR_SUP,PASO_BYTE_2            ;Sumo el 2do byte del "Paso" teniendo en cuenta el carry producido por la suma del 1er acumulador    => 1 Clk    +
            adc        X_INF,PASO_BYTE_3                     ;Sumo el 3er byte del "Paso" teniendo en cuenta el carry producido por la suma del 2do acumulador    => 1 Clk    +
            ld         DATA_REG,X                            ;Obtengo el dato almacenado en RAM mediante el puntero "X" y lo llevo al registro 20                => 2 Clk    +    
            out        _SFR_IO_ADDR(PORT_SALIDA),DATA_REG    ;Modifico el valor del PuertoC en función del dato leído previamente                                => 1 Clk    +
            cpi        FLAG_INT_REG,1                        ;Usando el r18 como flag de interrupcion externa 0, comparo dicho registro con "1"                    => 1 Clk    +
            brne       loop_senial                           ;Si no es igual Z=0 (Flag Zero) => salta                                                            => 2 Clk    
                                                             ;                                                                                                    ------------                                                
            ret

Y lo que yo traduje en PIC fue esto (todavía le faltaba el salto condicional):

ACUMULADOR_INF	EQU	10h 
ACUMULADOR_SUP 	EQU	11h
PASO_BYTE_1 	EQU	12h
PASO_BYTE_2 	EQU	13h
PASO_BYTE_3 	EQU	14h
DIR_BUFF_ALTA 	EQU	15h   
PORT_SALIDA     EQU   	PORTB

funcion_assembler:
  CLRF 		FSR0L			;Limpio la parte baja del puntero que apuntará al buffer de datos
  MOVF		DIR_BUFF_ALTA,W		;Copio a WREG la parte alta del puntero donde apuntará al buffer de datos		
  MOVWF		FSR0H			;Paso de WREG a FSR0H la parte alta del puntero donde apuntará al buffer de datos		
  CLRF 		ACUMULADOR_INF
  CLRF 		ACUMULADOR_SUP
  
  loop_principal:
    MOVF 		PASO_BYTE_1,W		;Copio el Paso byte 1 en WREG
    ADDWF 	ACUMULADOR_INF,F        ;Sumo el Paso byte 1 en el Acumulador INF
    MOVF 		PASO_BYTE_2,W		;Copio el Paso byte 2 en WREG - El carry no se toca!	
    ADDWFC	ACUMULADOR_SUP,F        ;Sumo el Paso byte 2 en el Acumulador SUP teniendo en cuenta el carry	 		
    MOVF		PASO_BYTE_3,W		;Copio el Paso byte 3 en WREG - El carry no se toca!	
    ADDWFC	FSR0L,F        		;Sumo la parte baja del puntero con el Paso byte 3 del buffer y lo almaceno en FSR0L
    MOVF		INDF0,W			;Copia el contenido del puntero del Buffer en WREG
    MOVF		PORT_SALIDA,F		;Manda al puerto el contenido del puntero del Buffer
    GOTO		loop_principal		;Empieza el ciclo de nuevo
  
    ;8 ciclos + 2 ciclos del GOTO = 10 ciclos.

La diferencia es que AVR requiere de 9clks del oscilador para completar un loop y ese PIC requiere de 40 clks (al parecer c/ciclo son 4 clks del oscilador).

Si bien el PIC lo compensa trabajando a 48MHz vs 16MHz del AVR, el AVR sigue siendo más rápido y sin necesidad de tener un clock elevado en el PCB (aunque el PIC "tampoco" lo tendría ya que ese clk sería interno).

Edito:

Hablamos de un Atmega16 vs PIC18F2550, que si bien tienen periféricos distintos (el PIC sobresale por el USB), la comparativa apunta al Core más que nada.

 

[TRILO-BYTE]

yo tengo una pregunta por que los americanos usan mucho los AVR y en algunas empresas es muy importante que sepas AVR si son aplicaciones de solo mover un RELE y unos leds

y los pic son famosos en comunidades de habla hispana
estoy consiente de que los AVR son mas poderosos por su set de intrucciones en el reloj

¿que hiso que ganaran los PIC con los AVR en el habla hispana?
¿la documentacion?
¿que son aveces mas baratos?
¿el soporte tecnico?

ahora yo he manejado freescale ,me dejaron un sabor amargo en la boca pues hay muy poca documentacion tanto hispana como inglesa , aparte de que el code warrior tiene muchas funciones bloqueadas en vercion estudiantil

 

[Meta]

Una de las ventajas que tiene PIC es que a pesar usar memoria segmentadas o bancos de memoria, es uno de los que proporciona 25 mA a la salida de cada pin, corriente alta comprada con las demás marcas, otro dato bueno, que su ensamblador es más cómodo y puede usar los tiempos muy precisos escrito en asm que en AVR o otras marcas son más engorrosos.

De ahí el uso de usar mucho los PIC.

Ahh, famosos en el habla hispana no, es a escala mundial.

Uno de los motivos también es porque hay mucha información y ejemplos en su Web y muchos idiomas, libros en español, en aVR no lo hay, si lo hay si usas Arduino con AVR. En las universidades también se usan mucho los PIC, y Motorola o FreeScale.

¿Por qué los PIC con todas las marcas que hay?

Microcontroladores

• ARM
• Atmel
• Cypress
• Digi
• Diodes
• Ember
• Energy Micro
• Fairchildsemi
• FreeScale
• FTDIchip
• Fujitsu
• Hitachi
• Holtek
• IDT
• Infineon
• Intersil
• JMicron
• LSI
• Maxim-IC
• Micrel
• Microchip
• Microsemi
• National
• NEC
• Nuvoton
• Oki
• On Semi
• Parallax
• Philips
• Picaxe
• Rabbit
• Renesas
• Rohm
• Samsung
• Semtech
• Silabs
• STMicroelectronics
• TI
• Toshiba
• Winbond USA
• Xmos

Saludo.

 

[cosmefulanito04]

Una de las ventajas que tiene PIC es que a pesar usar memoria segmentadas o bancos de memoria, es uno de los que proporciona 25 mA a la salida de cada pin, corriente alta comprada con las demás marcas

Yo diría que la mayoría de los uC modernos permiten suministrar altas corrientes, solo uC viejos como el 89S52 suele ser un problema eso. Por ej. un Atmega 16 te permite 40mA por pin, sin exceder los 200mA en total.

otro dato bueno, que su ensamblador es más cómodo y puede usar los tiempos muy precisos escrito en asm que en AVR o otras marcas son más engorrosos.

Por lo expuesto arriba, diría que el assembler de PIC es muchísimo más engorroso, todo el tiempo trabajando sobre la RAM.

Cada vez estoy más convencido que PIC es fuerte en el mercado, por el soporte post-venta que hace a diferencia de otros fabricantes, ya que te dá en mano muchísimo código para que el usuario menos experimentado tenga una curva de aprendizaje más suave.

 

[locodelafonola]

hola gente... bueno yo soy nuevo en el tema....pero estoy entrando en AVR......por la cuestion de DMX...y viendo los equipos comerciales son todos con atmega (o microprosesadores parecidos ) ...nada con pic...y no son todos de origen americano...hay muchisinos alemanes...rusos..y algunos de tailandia..pero pic nada de nada..la razon debe ser otra ( no se cual sea )....todos lo esquemas que encuentro en la red y desarrollos.no cumplen con las funciones de uso...o sea los desarrollos con pic no se asemejan al uso ni forma de ningun equipo...y eso en DMX...esta estandarizado....no por norma,,sino por uso cotidiano...no se porque algunos se empeñan en diseñar con pic algo que no tiene uso practico en DMX

 

[Meta]

Yo diría que la mayoría de los uC modernos permiten suministrar altas corrientes, solo uC viejos como el 89S52 suele ser un problema eso. Por ej. un Atmega 16 te permite 40mA por pin, sin exceder los 200mA en total.



Por lo expuesto arriba, diría que el assembler de PIC es muchísimo más engorroso, todo el tiempo trabajando sobre la RAM.

No, no lo es, engorroso lo que dices es todo el día cambiando de banco, lo que quiero decir que es más fácil es las instrucciones del ensamblador del PIC que es mucho más fácil, sencillo de hacer aplicaciones comparado con otras marcas y está demostrado mundialmente.

Cada vez estoy más convencido que PIC es fuerte en el mercado, por el soporte post-venta que hace a diferencia de otros fabricantes, ya que te dá en mano muchísimo código para que el usuario menos experimentado tenga una curva de aprendizaje más suave.

El manejo de banco de memoria no es tan complicado, si es muy cansino leer todo el día los registros de la hoja de datos, por eso es bueno tener imprimido en papel esa parte para no volverte loco.

Lo bueno del AVR que tiene memoria unificada, es decir, en un mismo segmento de una pasada, lástima que no se use mucho su asm, es muy engorroso y hacer lo mismo que los PIC, requiere más tiempo y muchas más intrucciones.

Saludo.

 

[seaarg]

Yo diría que la mayoría de los uC modernos permiten suministrar altas corrientes, solo uC viejos como el 89S52 suele ser un problema eso. Por ej. un Atmega 16 te permite 40mA por pin, sin exceder los 200mA en total.



Por lo expuesto arriba, diría que el assembler de PIC es muchísimo más engorroso, todo el tiempo trabajando sobre la RAM.

Cada vez estoy más convencido que PIC es fuerte en el mercado, por el soporte post-venta que hace a diferencia de otros fabricantes, ya que te dá en mano muchísimo código para que el usuario menos experimentado tenga una curva de aprendizaje más suave.

Lo que sucedio en mi caso es que la informacion para iniciarme en microcontroladores (soy programador de PC de muuuuuucho tiempo) estaba disponible en PIC. Entonces, una vez que haces todo lo que queres con PIC, cuesta adoptar otra plataforma.

Sin embargo, las ventajas de AVR sobre PIC me parece que son importantes cuando queres hacer algo de alto rendimiento ej: me hice un osciloscopio con el 18F2550 y hubiera simplificado bastante el hardware si hubiera conocido cosas que ahora voy conociendo de AVR. (gracias cosme!)

Todo tiene su lado oscuro. Odiaria tener un Atmega16 y tener que poner un conversor serial - USB y encima no disponer de HID.

 

[cosmefulanito04]

No, no lo es, engorroso lo que dices es todo el día cambiando de banco,

No es eso, digo engorroso porque por c/operación con dos datos, una la tenés que trabajar con el WREG y la otra con la RAM.

Ejemplo, para sumar dos número:

MOVF dato,W
ADDWF resultado,F

En cambio en avr, simplemente te manejas con cualquiera de los 32 registros generales que posee:

add registro1,registro2

Siempre es más rápido trabajar con registros dentro de la ALU que con RAM. Por otro lado c/ciclo del PIC representan 4clks del oscilador, dándote una diferencia de 8clk (PIC) vs 1clk. Incluso con un oscilador de 48MHz el PIC se queda atrás.

lo que quiero decir que es más fácil es las instrucciones del ensamblador del PIC que es mucho más fácil, sencillo de hacer aplicaciones comparado con otras marcas y está demostrado mundialmente.

Primero, hoy en día programar en assembler es de cavernícola, solo útil en casos donde se requiere máxima optimización.

Segundo ¿en qué resulta más sencillo? ¿programaste en AVR? compará las instrucciones tanto de PIC como de AVR y vas a ver que no hay mucha diferencia, la diferencia que destaco son los registros de uso general que tiene el AVR y PIC no (32 vs 1). Por otro lado ambos son RISC, no hay demasiadas instrucciones que aprenderse.

Lo bueno del AVR que tiene memoria unificada, es decir, en un mismo segmento de una pasada, lástima que no se use mucho su asm, es muy engorroso y hacer lo mismo que los PIC, requiere más tiempo y muchas más intrucciones.

Saludo.

¿En base a que decís eso?

Te aseguro que todo lo contrario, yo justamente no soy muy amigo del assembler, si puedo evitarlo lo hago, pero si una cosa debo decir de los AVR es que su assembler es tan sencillo que no requiere mucho tiempo para entenderlo, más si se viene de arquitecturas mucho más complejas como la x86 (ahí si agarrate con las instrucciones que tiene, un lindo CISC tenés ahí).

Todo tiene su lado oscuro. Odiaria tener un Atmega16 y tener que poner un conversor serial - USB y encima no disponer de HID.

Ese es el plus que destacó de PIC y seguramente debe tener muchísima información del propio fabricante para sacar andando el puerto sin demasiadas complicaciones.

 

[Meta]

Buenas:

El asm no es de cavernícolas, . Lo que tengo que leer, jajajajajajjjajaj.

El asm se enseñan en institutos, universidades y hasta autodidacta con el fin de entender paso a paso la arquitetura interna de una tecnología con un microcontrolador PIC. ASM es más bien para trabajar cosas pequeñas, la mayoría que programas en C bajo 16F no caben. El lenguaje como C está mejor por su tiempo de desarrollo, para esto está, más potente y cómodo, te olvida de los bancos de memoria y otras cosas.

El tema de tener una línea para sumar arriba como el ejemplo que usaste, siento decirte que se puede hacer igual como dices en los PIC de gama alta 18F, los de 16F no se puede.

He estado trasteando el asm de PIC y asm de AVR, la mayoría de las cosas se usan más instrucciones en AVR que los PIC. EN 16F se usan más porque solo maneja 14 bits, los de gama alta 16 bits, ya pueden hacer las cosas directas.

Eso que hago de PIC de 8 bits, si comparas los PIC o dsPIC de 16 bits, rompen a AVR en el mismo terreno. Total, si vas a coger un buen microcontrolador, el mejor mirado son la firma ARM.

Una pena que ARM no esté tan espandido para los hobbistas como los PIC y AVR.

Antes que se me olvide, asm para hacer cosas pequeñas y C para cosas grandes. Hay personas que se empeñan en complicarse demasiado con el asm para cosas muy grandes, te pegas media vida,ajjaajjajajaja. Eso si, el rendimiento es impresionante.

 

[locodelafonola]

la verdad que con lo que plantie...no me dieron respueta.....y la realidad muestra que con pic NADA....con AVR muchisimo ¿¿¿¿¿ porque ?????

 

[cosmefulanito04]

Buenas:

El asm no es de cavernícolas, . Lo que tengo que leer, jajajajajajjjajaj.

La verdad que si, es de cavernícolas usarlo sin justificación.

Hoy en día no tiene ningún sentido su uso salvo en caso de necesaria optimización, porque incluso con los uC modernos se pueden acceder a una buena memoria Flash/SRAM a bajo costo.

El asm se enseñan en institutos, universidades y hasta autodidacta con el fin de entender paso a paso la arquitetura interna de una tecnología con un microcontrolador PIC.

Pero amigo, una cosa es enseñar como funciona una arquitectura y otra lo que resulta más práctico.

El tema de tener una línea para sumar arriba como el ejemplo que usaste, siento decirte que se puede hacer igual como dices en los PIC de gama alta 18F, los de 16F no se puede.

Pero mirá que los AVR que mencioné, Atmega 16 incluso el 8, no son gamas altas .

He estado trasteando el asm de PIC y asm de AVR, la mayoría de las cosas se usan más instrucciones en AVR que los PIC. EN 16F se usan más porque solo maneja 14 bits, los de gama alta 16 bits, ya pueden hacer las cosas directas.

Insisto, los registros generales te marcan algo muy importante de la arquitectura, es poco práctico tener solo un registro de uso general en la ALU.

Eso que hago de PIC de 8 bits, si comparas los PIC o dsPIC de 16 bits, rompen a AVR en el mismo terreno.

No tiene mucho sentido comparar naranjas con manzanas, de última compará PIC32 vs AVR32, pero si me mudo a 32 bits, voy directo a ARM.

Una pena que ARM no esté tan espandido para los hobbistas como los PIC y AVR.

Que no encuentres gran información en español no significa que no haya, eso si, insisto que no vale la pena programar estos uC en assembler, más si justamente fueron pensados para usarlos con C.

Mucha de la información la podés encontrar en las hojas de datos (incluyendo notas de aplicación) y en libros sobre ARM.

Antes que se me olvide, asm para hacer cosas pequeñas y C para cosas grandes.

Ni para encender un LED optaría assembler, lejos C es la mejor opción, assembler solo para optimización necesaria donde los clks cuentan y mucho, nada más.

la verdad que con lo que plantie...no me dieron respueta.....y la realidad muestra que con pic NADA....con AVR muchisimo ¿¿¿¿¿ porque ?????

Cosas con PIC vi, pero es cierto que ese tipo de uC apunta más a fabricantes chicos.

Como mencioné en este mismo hilo, AVR es muy robusto, conectando en un mismo toma una PC un motorcito de aire comprimido y una placa con un AVR en PCB experimental, cuando arrancó el motor la PC se reinició, el AVR ni se enteró y ni siquiera tenía los filtros que recomendaba el fabricante.

Eso independientemente del Core, te dice algo sobre esa familia de uC.

 

[Meta]

Tengo claro que ARM lo programaré en C, ajjaajaja. Me cansé un poco del asm ya que me pego media vida y en C no tanto, a parte que C es más facil exportar códigos para otros mircocontroladores.

En cuanto a PIC y AVR, lo veo poco flojo comparado con los ARM. Así de claro opino.

 

[seaarg]

El tema de tener una línea para sumar arriba como el ejemplo que usaste, siento decirte que se puede hacer igual como dices en los PIC de gama alta 18F, los de 16F no se puede.

Meta, puede ser que te estes confundiendo con MOVFF? que es solo un opcode que resume 2 operaciones en 1 pero igual consume 2 ciclos.

Si no es asi, como sumas 2 numeros en una sola instruccion en 18F? Si existe me vendria barbaro pero no lo vi en el datasheet.

 

[Meta]

Me refiero ese. Y si, ocupa 2 ciclos máquina a cambio de una línea.

Fentro de poco me meteré a fondo con Arduino en C, hay dos libros en español para aprender que dicen ser los mejores al menos por ahora. En Inglés son otros.

Saludo.

 

[locodelafonola]

Cosas con PIC vi, pero es cierto que ese tipo de uC apunta más a fabricantes chicos.
Como mencioné en este mismo hilo, AVR es muy robusto, conectando en un mismo toma una PC un motorcito de aire comprimido y una placa con un AVR en PCB experimental, cuando arrancó el motor la PC se reinició, el AVR ni se enteró y ni siquiera tenía los filtros que recomendaba el fabricante.
Eso independientemente del Core, te dice algo sobre esa familia de uC.

a eso hiba amigo..pero es indudable..que hay algo alo que se refirio el amigo meta..y es que en español..hay muy pocos manuales...y como algunos saben yo tengo amigos rusos y polacos ( por internet ) todos estudiantes de ingieneria electronica en polonia...y ellos me pasaron varios manuales de AVR...pero en ruso..y al traducirlos entiendo muy poco o casi nada.....y si eso fuera
un factor muy importante..porque se tiene los datos tecnicos del componete..las herramientas de programacion..pero no se tiene un manual de uso...si ya se lo que me van a decir.... "aca en el foro hay un manual de uso del AVR" ... chicos si ... en ese manual esta muy bueno (LO LEEI ) pero para alguien que no maneja lenguajes..las sentencia..los simbolos y espacios de cada compilacion ... es chino basico.....¡¡¡¡ y para colmo es un dialecto !!!!!! asi no aprendo nada
recien... hace unos segundos..... acabo de recibir unas pantallas mini lcd... asi que voy a crear un post para programar un atmega...pero quiero aprender varias cosas y tratar de ver si se puede mezclar algunas cosas de los .HEX que tengo y como tal funcionan pero todo por separado.... led por un lado... motores pap por el otro... servos por otros lados..matrix en otro ...o sea nada combinado...

 

[cosmefulanito04]

a eso hiba amigo..pero es indudable..que hay algo alo que se refirio el amigo meta..y es que en español..hay muy pocos manuales...y como algunos saben yo tengo amigos rusos y polacos ( por internet ) todos estudiantes de ingieneria electronica en polonia...y ellos me pasaron varios manuales de AVR...pero en ruso..y al traducirlos entiendo muy poco o casi nada.....

En inglés hay mucha información, tenés foros exclusivos como AVR Freaks, etc.

A ver, yo tampoco es que sea un tipo que se sepa al 100% como funciona un uC en particular, para mí creo que no es la forma de aprender o mejor dicho no es práctico especializarte en una familia determinada, ya que el día de mañana no solo te podés quedar sin fabricante, sino que incluso la tecnología c/vez avanza a pasos más grandes que llega un punto que si no actualizaste de familia te quedás en el tiempo.

un factor muy importante..porque se tiene los datos tecnicos del componete..las herramientas de programacion..pero no se tiene un manual de uso...si ya se lo que me van a decir.... "aca en el foro hay un manual de uso del AVR" ... chicos si ... en ese manual esta muy bueno (LO LEEI ) pero para alguien que no maneja lenguajes..las sentencia..los simbolos y espacios de cada compilacion ... es chino basico.....¡¡¡¡ y para colmo es un dialecto !!!!!! asi no aprendo nada
recien... hace unos segundos......

Primero decidí el lenguaje que vas a utilizar, hoy en día el mejor lenguaje para aprender es C y tiene la gran ventaja que resulta prácticamente igual en todas las familias de uC, es decir es muchísimo más fácil trasladar un proyecto hecho en AVR a uno en PIC y viceversa.

¿Qué cambia?

Los registros que necesitás configurar en los periféricos del uC al que te trasladás, nada imposible si tu programación es ordenada.

¿Necesitas aprender assembler?

Si, si bien como mencioné lo ideal es tocarlo lo mínimo posible, hay veces que no hay más remedio y tenés que usarlo, además te sirve entender los pasos que debe realizar el uC en cada operación que hacés y eso también te puede servir para optimizar tú código en C.

Volviendo a C, si nunca programaste en ese lenguaje, mi consejo es que aprendas hacerlo desde una PC, ahí tenés la ventaja de tener un monitor (mostrar resultado), un teclado (ingresar datos), etc que un uC al principio cuesta tener. Linux es una excelente opción que te dá todas las herramienta que necesitas, incluso para que te dés una idea, AVR usa gcc, que es el mismo compilador de linux, obviamente adaptado para la familia AVR.

Una vez que aprendés bien C, simplemente es aplicarlo al uC, es todo igual, solo cambian las funciones que llamás y aparecen los registros propios del uC. En este paso es importante aprender, independientemente del uC, a leer bien su hoja de datos, las notas de aplicación y googlear mucho para ver ejemplos de código.

acabo de recibir unas pantallas mini lcd... asi que voy a crear un post para programar un atmega...pero quiero aprender varias cosas y tratar de ver si se puede mezclar algunas cosas de los .HEX que tengo y como tal funcionan pero todo por separado.... led por un lado... motores pap por el otro... servos por otros lados..matrix en otro ...o sea nada combinado...

Cualquier cosa preguntá en el foro que vamos ayudarte.

Yo a medida que fuí usando uC, fui desarrollando mis propias librerías y por ej. uso las mismas librerías para un LCD 2x16 en un AVR, 8051 o ARM, porque resulta muy sencillo adaptarlo con C y estoy bien al tanto que cosas tocan esas librerías y que no (eso resulta muy importante).

Me refiero ese. Y si, ocupa 2 ciclos máquina a cambio de una línea.

Ahhh pillín, estás en la misma .

 

[Meta]

Hola:

Otra ventaja del ASM, es que si no usas compiladores no oficiales, como el CCS, hay algunos PIC que lo actualizan en un año, es decir, no puedes hacer cambios de un icerto registro en un banco de memoria para cambiar alguna función.

¿Qué hacer?

Añadirle una etiqueta dentro de C para usar ASM dentro de ella, así cambiarás algunas funciones específicas y sin rechistar. Mientras pasa un año y CCS lo arreglan. Lo comento porque ha pasado mucho.

El tema de AVR usaré Arduino. Aprenderé C para PIC a fondo en el futuro y probaré ARM que tanto dicen que es muy bueno.

Usar PIC o AVR habiendo otras marcas, pues...

hoy en día más que gustos si se pregunta a uno mismo qué microcontrolador es mejor. Pues ni uno ni otro, solo el que veas necesitado o el que te haga falta realmente.

Salu2.