Haz una pregunta
  Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos
Foros Registrarse ¿Olvidaste tu contraseña?

Temas similares

26/04/2012 #21

Avatar de Meta

Entendido campeón.

Lo que comparo los PIC con ARM es la información, no la arquitecturta.

ARM es ARM y PIC es PIC. PIC para jugar por lo que piensan muchos, PLC para cosas industriales, ARM es muy profesional, se instala Windows y Linux.

¿Correrá Ubuntu Linux en un micro de 8 bits?


http://electronica-pic.blogspot.com....icro-de-8.html


Saludo.
27/04/2012 #22


pero que pueda instalarse windows (solo windows 8 RT), no es por la capacidad del micro, sino porque microsoft quieren que así sea. Linux tambien corre en procesadores MIPS (aquí), android tambien corre en procesadores mips, simplemente ARM esta más expandido entre las tablet.

Un saludo

P.D. no pienses que es algo personal contra ti meta!! simplemente digo lo mismo que supongo pensaran los que trabajan con micros de 8 bits de atmel o freescale respecto a microchip, que hay más opciones y estaria bien conocerlas todas
27/04/2012 #23

Avatar de Meta

Normal, es bueno que haya competencia entre compañías, saber demás micros te abre las puertas. Eso si, o te expecializa en uno para ser maestro en algo aunque sea el 75% que mucho es, o intentarás aprender de todo un poco, AVR, FreeScale, ARM, PIC, Philips, y no manejarás ni el 4%.

En resumen, el que intenta ver todo un poco mucho de aprendiz y poco de maestro. Si quieres ser maestro en algo, te especializa en una cosa sola. Cada micro es un mundo.

Si usas el estandar C, es otra cosa.
27/04/2012 #24

Avatar de cosmefulanito04

Esa es la magia de programar en C, te aisla un poco de todo y te permite meterte en cada familia/marca sin tantos inconvenientes. Estamos de acuerdo que para ciertas cosas especificas necesitas usar codigo ASM, pero hacer todo un proyecto todo en ASM hoy dia creo que es medio una locura (es solo mi opinión). Por ej. usar estas bestias ARM y programarlas en ASM no tiene sentido alguno.

Tampoco me parece buena la idea de saber usar solo bien una marca/modelo, si sabes programar, tenes que poder manejarte relativamente bien con todos los uC y no "limitarte" a una solución.
27/04/2012 #25

Avatar de Meta

Dije una marca, la realidad es el 75% de una marca, los demás para todas. Así son los expertos, con esta metodlogía y años de experiencia.

En cuanto a programar todo a ASM, está bien para los 8 bits. PIC32 vi ejemplos en ASM casi se me cae la cara. Todo el mundo que saben piensa que es una locura. si lo manejas con soltura, sigue siendo una locura por el tiempo que pierdes en él. Para cosas pequeñas está bien, ahorras memoria, controlas todo paso a paso lo que deseas, bla, bla, C es más portable, más cómodo y no se que más historias, hoy en día es el C para dispositivos, java para Internet y PC en general.

Están desarrollando BIOS del PC que sea en C, ya que lleva más de 25 años haciendose en ASM. Cada vez más cuesta su mantenimiento, que los desarrolladores hagan cursos de ASM para BIOS, etc, un coste caro hoy en día. Por eso se harán en C y pantallas muy chulas a lo Windows o Linux.

En cuanto a ARM para Windows 8, Microsoft lo quiere así.
27/04/2012 #26

Avatar de cosmefulanito04

Meta dijo: Ver Mensaje
Dije una marca, la realidad es el 75% de una marca, los demás para todas. Así son los expertos, con esta metodlogía y años de experiencia....
¿Por qué limitarme a una sola marca?

Si por ej. el día de mañana PIC quiebra o es comprado por (decir algooo...) ATMEL, se te cae el mundo encima.

Yo creo que esa es una ventaja muy importante de los ARM, si NXP se va a pique, sabes que todavía tenés Atmel, ST, Motorola, etc. El 8051... arquitectura vieja, todavía está vigente por este tipo de cosas, además de la confiabilidad demostrada.

En ese sentido, creo que a la larga, mientras menos dependencia tengas de un fabricante y más te adaptes a los cambios mejor cintura vas a tener para evitar inconvenientes a futuro.
27/04/2012 #27

Avatar de Meta

cosmefulanito04 dijo: Ver Mensaje
¿Por qué limitarme a una sola marca?
Dije el 75 % aprendes una marca. Ahora por aquñi digo el resto de otra menara. El 25 % restante, son otras marcas y familiar. Así serás un experto en una marca y si esta falla, con los que has aprendido del 25%, ya tienes para centrarte en los demás microcontroladores que has visto. Claro que hay que ver los demás micro, es el 25 % que me refiero para tener puertas abiertas. So intentas aprenderlos todos, casi imposible, no manejarás algo con soltura.

Siempre se nombran ARM, PIC, AVR, FreeScale, ¿sabes cuántos hay realmente?

Microcontroladores



Me refiero a eso.



Saludo.
28/04/2012 #28


cosmefulanito04 dijo: Ver Mensaje
¿Por qué limitarme a una sola marca?
Yo creo que esa es una ventaja muy importante de los ARM, si NXP se va a pique, sabes que todavía tenés Atmel, ST, Motorola, etc.
Volvemos a confundir marca y arquitectura. . . . si tu aprendes a programar un NXP, con los compiladores de NXP, con las librerías de NXP, y NXP se va a pique, tendrás el mismo problema que si programas PIC. Tendrás que aprender de nuevo a programar micros ARM de texas por ejemplo. ARM solo es el núcleo, cada marca pone sus periféricos y los registros de estos periféricos son únicos para cada marca.
28/04/2012 #29

Avatar de Meta

Es verdad, no leí bien.
28/04/2012 #30

Avatar de cosmefulanito04

Pablet dijo: Ver Mensaje
Volvemos a confundir marca y arquitectura. . . . si tu aprendes a programar un NXP, con los compiladores de NXP, con las librerías de NXP, y NXP se va a pique, tendrás el mismo problema que si programas PIC. Tendrás que aprender de nuevo a programar micros ARM de texas por ejemplo. ARM solo es el núcleo, cada marca pone sus periféricos y los registros de estos periféricos son únicos para cada marca.
Nunca programé un ARM que no fuera nxp, estoy de acuerdo que no puedo usar las mismas herramientas (tal vez en algunas cosas si), pero ¿tanto te cambia el código de una marca a la otra? dejando de lado los registros, que evidentemente no se van a llamar iguales, pero adaptarte no debería costarte demasiado.

Ojo, hablo a nivel soft, a nivel hard es otra cosa y como todo componentes vas a tener que ver cuales son sus limitaciones y ventajas.
28/04/2012 #31

Avatar de Meta

Menos mal que existe un lenguaje estandar como el C, varían cosas, pero se coge el hilo rápido.
28/04/2012 #32


efectivamente como dice meta tenemos la ayuda de que C es un standar y no cuesta demasiado, pero cuesta lo mismo que, por ejemplo, pasar de un msp430 de texas a un dspic de microchip, respecto a lo de porque limitarse a una sola marca, está claro que no son todo ventajas, pero las que hay son muy grandes, por ejemplo, C18 y C32 son muy muy parecidos, incluso los registros de los dspic, y los pic32 tienen mismo nombre, diferente tamaño eso si.
Otra ventaja es que si yo tengo en un sistema un dspic30f..... y un dia necesito mas velocidad, saco el dspic30f..., le meto un pic24h... y el patillaje es el mismo, o incluso un pic32mx1, incluso podría hacerlo sin grandes cambios en el codigo. Como contras, pues lo que tu has dicho, si microchip se va a pique (cosa bastante complicada), tienes que volver a empezar pero bueno, fue bonito mientras duró.

Un saludo
28/04/2012 #33

Avatar de ilcapo

hola le pregunto a ustedes que conocen de C.... que diferencia hay en los programas para los pics de 8 bits y los de 32 bits,,, en assembler me doy cuenta rapido porque las instrucciones de 32 bits son "mas largas" que las de 8 bits ,, pero en C como se dan cuenta si el programa esta hecho para un pic de 8 o uno de 32 ?

saludos!
28/04/2012 #34


puedes saberlo por el tamaño se los registros, es decir, a la hora de configurarlos, en 8 bits tendrías algo así ADCON1=0x25, y en 32 bits algo así ADCON1=0x23562145, por lo demás como bien dices sería todo igual.

Un saludo
29/04/2012 #35

Avatar de Meta

Trabando con tipos de memoria como int, ulong, etc, sabrás la cantidad de memoria que tiene PIC32 porque alcanzan hasta los 32. Trabajan 32 en paralelo.

Se dice que PIC64 están hecho desde que salió PIC32. Lo que no quieren venderlo por ahora. Será que como no hay demanda casi ni PIC32 o la competencia tampoco le interesa...

Cada vez se cende más PIc32, sobre todo cuando sacaron los de 28 y 40 pines a lo 16F886/7 y 18Fx550.
17/07/2012 #36

Avatar de ilcapo

info en español de ARM 7 no existe (osea algun buen libro) ? :(
17/07/2012 #37

Avatar de cosmefulanito04

Mirá yo de inglés se menos que Tevez, pero todo lo que es bibliografía técnica es bastante más sencillo de entender que otro tipo de cosas, de hecho te vas acostumbrando cuando lees las hojas de datos o las notas de aplicación.

Si querés te puedo pasar un apunte introductorio (nada más que eso, después si querés meterte más si o si tenés que buscar en libros) de como funciona la arquitectura y después si te interesa te puedo subir código de la familia nxp ARM7 en C.
Archivos Adjuntos
Tipo de Archivo: pdf Cap10_2009_ARM7_apunte.pdf (1,55 MB (Megabytes), 194 visitas)
17/07/2012 #38

Avatar de ilcapo

muy bueno el apunte gracias, con respecto al programa en C que compilador se usa ? se puede usar el CCS o es solo para pics ? si tenes un codigo simple como ser encender y apagar un led en ARM 7 seria genial ! saludos
17/07/2012 #39

Avatar de cosmefulanito04

Me imagino que el CCS es solo para PIC.

Yo usó el keil, podés bajar una versión de evaluación que te limita compilar código mayor a 32kbytes (para empezar es un montón).

https://www.keil.com/demo/eval/arm.htm

El keil te permite configurar bien la inicialización del bicho, osea sin meterte mucho en el código podés configurar el PLL (etapa del uC que permite modificar la frecuencia del clock a partir de cualquier cristal que uses), esto es muy importante que lo hagas, sino no vas a saber en que frecuencia está trabajando tu clock.

Acá te dejo un código pensado para un LPC2003 (o similar) que simplemente enciende y apaga varios leds al mismo tiempo en base a un timer:

Código PHP:
// Con un Xtal 14,7456 MHz => configuro el PLL para => CClk=fosc y Pclk = CClk/4 = 3,6864 MHz  TPclk= 272 nSeg (aprox.)
// Pclk es el clock de los puertos, CClk es el clock del Core del ARM


#include <LPC210x.h>

__irq void timer0(void); // Prototipo de la interrupcion

unsigned char toggle=0;

int main(void)
{
    
PINSEL0=0;
    
PINSEL1=0// Todos los puertos funcionan como tales.
    
IODIR=0x0F000001// De P27 a P24 y P0 los configuro como puertas de salida
    
IOSET=0x0F000001// Prendo leds
    
    /* Los timers tienen 2 contadores, 1 es el prescaler y el otro es el contador en si mismo, ambos tienen registros son de 32 bits
       por lo tanto por c/u puedo contar 2^32, osea como maximo podria contar hasta 2^64*272 nSeg = muchos dias :-)
       El timer seria una cosa asi:  FPclk --> Prescaler --> Contador

       - Prescaler -> 2 resgistros
             . TxPR: Es el valor de cuenta del prescaler.
             . TxPC: Sirve para indicarle desde donde comienza a contar el prescaler, cuando sea igual a TxPR, desborda y empieza de nuevo, mandandole una cuenta al otro contador

       - Contador -> 4 registros
             . TxTCR: Es un registro de control, si vale:
            -0: el contador no cuenta
            -1: el contador cuenta
            -2: reseteo el contador.
            Es como el TRx del 8051.
          . TxTC: Sirve para indicar el valor de inicio del contador
          . TxMRx: Son varios registros (segun el timer pueden ser 4 o 3), aca se pondra el valor de la cuenta q se desea alcanzar con el contador, cuando TxTC sea igual se produce un evento.
            Son varios porq se lo puede configurar para q envie un evento en cuentas distintas, ej:
            - TxMR0 = 34; Al llegar aca se produce un evento, pero el contador sigue
            - TxMR1 = 45; Al llegar aca se produce otro evento
          . TxMCR: Sirve para configurar q accion tomar cuando se produce un evento, es de 32 bits y c/3bits se cunfigura un MRx distinto:
              Si se produce un evento en MRx y TxMCR vale:
            - 001: lanza una interrupcion
            - 010: se resetea el contador
            - 100: se para el contador
            Las 3 acciones se pueden combinar, osea interrumpir y resetear al mismo tiempo.
    */

    //------------------ Configuracion del Timer -----------------------------------------------//
    
T0TCR=0x0// el contador no cuenta
    
T0TC=0x0;  // el contador comienza de 0
    
T0PR=3686// configuro la cuenta del prescaler tal q le mande una cuenta al contador c/ 1 mSeg
    
T0PC=0x0;  // el prescaler comienza de 0
    
T0MR0=1000// configuro la cuenta del MR0 tal q cuente 1000 mSeg osea 1 seg
    
T0MCR=0x03// configuro q al producirce un evento en MR0, se lance una interrupcion y se resetee el contador
    //------------------------------------------------------------------------------------------//

    /* Registros de interrupciones:
       VICIntEnable: habilita las 16 posibles fuentes de interrupciones, tipo un IE del 8051
       VICIntSelect: configura a las interrupciones como:
               - FIQ: interrupciones rapidas
            - IRQ: interrupciones comun, q a su vez pueden ser:
                 * vectorizadas (igual q en el 8051)
                * no vectorizadas (en teoria no lo veriamos)
       VICVectCntl_0 al 15: en el se indican los indices de interrupciones habilitadas y si es vectorizada o no.
       VICVectAddr_0 al 15: la direccion donde se encuentra la rutina de atencion, es como un setvect
    */

    //------------------------ Configuracion de las interrupciones ------------------------------//
    
VICIntSelect=0x0// Lo configuro como IRQ
    
VICIntEnable=0x10// Interrupcion del Timer 0 activado, su indice es 4 al ser el bit 4    (importante para el reg. q viene)
    
VICVectCntl0=0x24// Los 4 1eros bits sirven para indicar el indice, el 6to bit si vale 1 indica q es vectorizado y si vale 0 q no
    
VICVectAddr0= (unsigned longtimer0// Le digo q la direccion de la subrutina timer0 q funciona como interrupcion
    //--------------------------------------------------------------------------------------------//

    
T0TCR=1// el contador empieza a contar
    
while(1);
}

//--------- Rutina de la interrupcion ---------------------//
 
__irq void timer0(void)
 {
     if(
toggle==0)
       {
       
IOCLR=0x0F000001// Apago leds
       
toggle=1;
       }
    else
       {
       
IOSET=0x0F000001// Prendo leds
       
toggle=0;
       }
    
T0IR=0x01// Limpio registro de interrupcion - No tengo idea de donde sale, habria q ver hoja de datos
    
VICVectAddr=0xFF;
 }
 
//---------------------------------------------------------// 
Te recomiendo que uses el Proteus como simulador de este tipo de uC, te va a resultar muy útil y obviamente con hoja de datos encima para entender que es cada registro, después veo si encuentro un resumen que había hecho.
17/07/2012 #40


yo tengo un LPC1768 con un Cortex M3. No te voy a aconsejar acerca de que micro coger por que solo he probado este y no tengo los conocimientos suficientes.

pero si te aconsejo que te compres la placa de desarrollo con el J-tag integrado para depurar. si lo compras aparte sale mucho mas caro.

si haces proyectos un poco complejos el Jtag te va a sacar de muchos apuros y te va a ahorrar mucho tiempo.

-----------------------

alguien sabe utilizar el I2C para esta familia de micros (LPC17xx)? no se que pasa que no lo consigo. alguien me echa una mano?



saludos
¿Tienes una mejor respuesta a este tema? ¿Quieres hacerle una pregunta a nuestra comunidad y sus expertos? Registrate

Foros de Electrónica » Diseño digital » Microcontroladores y sistemas embebidos

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO ©2011, Crawlability, Inc.