Atmel vs Microchip

Estado
Cerrado para nuevas respuestas.
Sabes que estoy tratando de tomar esa decisión, si usar o no librerías de terceros para cosas complejas como las que mencionas, no es lo mismo levantar un par de funciones para una Uart que para el USB.

Es que en última instancia, con C tampoco tenemos un control total. Uno escribe código en C y es el compilador el que tiene el control, que traduce las instrucciones a código objeto.
Una simple instrucción de asignación (a = b) va a ser compilada de formas distintas dependiendo de la configuración del compilador (nivel de optimización entre otras), si la variable es volatile o no, si la variable "a" es una variable local a la función (en tal caso normalmente se use la pila, se puede cambiar con opciones de compilación), si es static entonces en realidad es global. Si b es el resultado de llamar a una función entonces quizás se use para b uno de los registros de trabajo del micro.

Y también el código generado va a depender del código antes y después de la instrucción de asignación, si después hago un if(a) el código no va a ser el código de la instrucción de asignación más el codigo del if; sino una fusión (siempre y cuando se utilice al menos una mínima optimización).
Normalmente cuando uno está escribiendo el código por primera vez puede optar por no usar ninguna optimización, usar -O0 para los que hablan gcc, y una vez que sabe que eso funciona entonces sí puede optimizar en general (-O2, -O3), o quizás le interese optimizar el tamaño de código (-Os que puede ir en contra de la velocidad de ejecución). Lo digo porque alguna vez puede pasar que uno no sabe por qué algo no funciona y termina viendo el disassembly que generó el compilador, y ve alguna operación "rara" (por ejemplo, suele pasar que si usas código optimizado las instrucciones no se ejecutan en el orden que las escribiste, sino que salta de un lugar a otro dentro de la rutina en forma fantasmagórica -> optimización).
¿Entonces por qué usar optimización?, porque normalmente te reduce la cantidad de memoria usada a la mitad, y se ejecuta más rápido, lo que no es para nada despreciable.

En fin, a lo que voy es que no hay que creerse que por usar C tenemos todo el control, u órdenes de magnitud de mayor control que usando C++. Lo que tiene C es que seguro lo vas a poder usar con cualquier cosa (8, 16, 32 bits), C++ recién en algunos micros de 16 bits y seguro de 32 bits.

Al final, la diferencia pasa más por si la compañía X (que puede ser distinta a la que hace el micro) te provee de un buen compilador (que no genere instrucciones inútiles y esté bien optimizado para el hardware del micro) de que si escribís en C o C++.
 
Hola:

Pues para cosas complejas me está interesando el tema este con C#, lo entiendo y todo.

NanoTop01Med.jpg

http://gadgeteerguy.com/Catalog/ArticleView/tabid/142/ArticleId/3/NANO-Mainboard.aspx


Se metieron hasta con el LCD de Hitachi, ajjaja.
http://www.netmf.com/gadgeteer/show...&title=GHI Electronics HD44780 (With Display)

Doc de demás comunicaciones, I2C, SPI, USB...
http://www.ghielectronics.com/docs

Los periféricos hardware tienen parar artarte, están todos hehcos. Mirar página por página.
http://www.netmf.com/showcase.aspx?ShowcaseID=1&id=151

Tutoriales:

http://www.ghielectronics.com/docs/37/netmf-and-gadgeteer-tutorial-index

Con mi lenguaje preferido C# y todo, por ahora son fáciles de entender.

Example 3: Blink an LED timed ON/OFF
Código:
[LIST]
[*][COLOR=#0000FF]using[/COLOR] [COLOR=#008000]System.Threading[/COLOR][COLOR=#008000];[/COLOR]
[*][COLOR=#0000FF]using[/COLOR] [COLOR=#008000]Microsoft.SPOT.Hardware[/COLOR][COLOR=#008000];[/COLOR]
[*][COLOR=#0000FF]using[/COLOR] [COLOR=#008000]GHI.Premium.Hardware[/COLOR][COLOR=#008000];[/COLOR]
[*] 
[*][COLOR=#0000FF]namespace[/COLOR] change_this_to_your_namespace
[*][COLOR=#008000]{[/COLOR]
[*]    [COLOR=#0000FF]public[/COLOR] [COLOR=#0000FF]class[/COLOR] Program
[*]    [COLOR=#008000]{[/COLOR]
[*]        [COLOR=#0000FF]public[/COLOR] [COLOR=#0000FF]static[/COLOR] [COLOR=#0000FF]void[/COLOR] Main[COLOR=#008000]([/COLOR][COLOR=#008000])[/COLOR]
[*]        [COLOR=#008000]{[/COLOR]
[*]            [COLOR=#00a7d8]OutputPort[/COLOR] LED[COLOR=#008000];[/COLOR]
[*]            LED [COLOR=#008000]=[/COLOR] [COLOR=#0000FF]new[/COLOR] [COLOR=#00a7d8]OutputPort[/COLOR][COLOR=#008000]([/COLOR]EMX[COLOR=#008000].[/COLOR]Pin[COLOR=#008000].[/COLOR]IO47, [COLOR=#0000FF]true[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000];[/COLOR]
[*] 
[*]            [COLOR=#0000FF]while[/COLOR] [COLOR=#008000]([/COLOR][COLOR=#0000FF]true[/COLOR][COLOR=#008000])[/COLOR]
[*]            [COLOR=#008000]{[/COLOR]
[*]                LED[COLOR=#008000].[/COLOR]Write[COLOR=#008000]([/COLOR][COLOR=#0000FF]true[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000];[/COLOR]
[*]                [COLOR=#00a7d8]Thread[/COLOR][COLOR=#008000].[/COLOR]Sleep[COLOR=#008000]([/COLOR]200[COLOR=#008000])[/COLOR][COLOR=#008000];[/COLOR]
[*] 
[*]                LED[COLOR=#008000].[/COLOR]Write[COLOR=#008000]([/COLOR][COLOR=#0000FF]false[/COLOR][COLOR=#008000])[/COLOR][COLOR=#008000];[/COLOR]
[*]                [COLOR=#00a7d8]Thread[/COLOR][COLOR=#008000].[/COLOR]Sleep[COLOR=#008000]([/COLOR]200[COLOR=#008000])[/COLOR][COLOR=#008000];[/COLOR]
[*]            [COLOR=#008000]}[/COLOR]
[*]        [COLOR=#008000]}[/COLOR]
[*]    [COLOR=#008000]}[/COLOR]
[*][COLOR=#008000]}[/COLOR]
[/LIST]

http://www.ghielectronics.com/docs/7/digital-outputs

Lo que no se si en cada componente habrá un esquema libre para hacerlo nosotros. Ojalá tenga adeptos.
 
Ya recorde que el Micro-Framework lo había visto antes aplicado en otras tarjetas como la Microsoft .NET Micro Framework Board FEZ Mini de Olimex. Parece más fácil de clonar jeje...
Si es compatible, ya es otra opción...
 
Es que en última instancia, con C tampoco tenemos un control total. Uno escribe código en C y es el compilador el que tiene el control, que traduce las instrucciones a código objeto.

Estoy de acuerdo, que con C el control del hard es mucho más limitado.

Pero si encima entregás el control a funciones que no tenés idea de lo que hacen, corrés el riesgo de no saber que registros del hard estan tocando, más si estas trabajan con rutinas de interrupción.

Mismo el RTOS, no me queda otra que usarlo porque no voy a reinvertar la rueda creando mi propio Scheduler, pero hay un alto riesgo de que si algo falla y no es algo de mí código, las cosas se compliquen y mal. Lo bueno del FreeRtos es que tiene un respaldo importante.

Por eso comparto lo que decís, pero entregar ese control tiene ese costo.

En fin, a lo que voy es que no hay que creerse que por usar C tenemos todo el control, u órdenes de magnitud de mayor control que usando C++. Lo que tiene C es que seguro lo vas a poder usar con cualquier cosa (8, 16, 32 bits), C++ recién en algunos micros de 16 bits y seguro de 32 bits.

Yo no discuto eso, pero si además el compilador se complicá con un buen código en C, ¿qué puede pasar con uno pésimo?
 
Lo que se sobre el C/C++, en PC no está tan limitado como los PIC, así de simple. Así que pongan más RAM y memoria programa.
 
Pero si encima entregás el control a funciones que no tenés idea de lo que hacen, corrés el riesgo de no saber que registros del hard estan tocando, más si estas trabajan con rutinas de interrupción.
.....

También coincido :).
Son distintas herramientas y todas tiene su campo de aplicación. Una cosa es poner baldosas en la vereda de tu casa y otra es poner los pisos en un complejo de edificios.

cosmefulanito04 dijo:
Yo no discuto eso, pero si además el compilador se complicá con un buen código en C, ¿qué puede pasar con uno pésimo?

Si el compilador es pésimo, con bugs, y no tengo acceso a uno bueno o alternativo (porque no lo puedo pagar) -> me cambio de micro (si es que hay opción).
Y si el código que uno escribe es malo, capacitación, porque ninguna herramienta por buena que sea va a poder salvar la situación (garbage in, garbage out como dicen los gringos).

Meta, interesante el framework que mencionás. Es algo que pasar a ser necesario para micros ARM, en la elección de un ARM pasa a pesar mucho más la disponibilidad de herramientas como esa, librerías, frameworks, etc; que para micros más chicos. Porque se manejan cosas más complejas, y se trata de que el tiempo de desarrollo (que pasa a ser el principal costo de desarrollo) no se dispare al infinito.
 
Claro que C no es tan optimo, pero programar el Cortex-M4F en ensamblador me enredara horrible, si ahora veo el código que hice para que un carrito se estacione solo y ya no se ni como escribí las primeras funciones para controlarlo, son explorar múltiples sensores y la medición de la batería, calcular las correcciones necesarias para el control del motor, los movimientos que debe realizar y saber cuando detenerse, no me enseñan a programar, lo aprendí por cuenta propia así que no me queda de otra más que usar C y las librerías del fabricante por que la configuración misma para controlar cada cosa en este chip es bastante extendida con tantos periféricos y no tengo el tiempo para aprenderlo, el proyecto debe estar listo la próxima semana.
 
Si, los PIC para jugar. Un argentino que desarrolla bien PCB con 18F4550, dice que no es fiable en el mundo laboral como para venderlo y usarlo en empresas porque se cualga como Windows. Es decir, PIC no es muy fiable. Por eso usar autómatas o PLC.

Saludo.

Bueno si, en mi ciudad pusieron unos paneles led grandes hechos con pic :unsure:, estos se andan malogrando al menos una vez cada 3 semanas :rolleyes:, me causa gracia cada vez que el bus me lleva de regreso a casa, siempre veo al menos 1 de los 6 mostrando caracteres extra◄os a lo loco, debe ser el ruido de toda esa gente con los celulares, ondas de radio, etc ...

Obvio que para el campo industrial estan los PLC que son robustos y hechos para trabajar en un ambiente lleno de ruido, tambien la flexibilidad de su aplicacion, pero por ahi vi varios proyectos academicos basados en pic-avr para hacer un plc, incluso algunos aplicaciones industriales basadas en arduino ... :eek:, pondre mas tarde los links :D

Ahi van :
http://www.caveo.com.ar/PLC-05.htm (PLC de "bajo rango" basado en pic)
http://www.pablogindel.com/2012/12/arduino-en-la-industria/
https://www.forosdeelectronica.com/f21/manera-efectiva-eliminar-ruido-electrico-videos-32019/
 
Última edición:
En realidad basta con leer, recuerdo que vi en algún momento algo relacionado con el sector para el cuál se fabrican los PIC y ésta información lo encontré en la misma página de Microchip; en mi opinión los fabricantes si saben lo que hacen y es muy distinto cuando el usuario lo utiliza para trabajos para el cuál no está fabricados (desde éste punto ya empiezan las criticas y/o opiniones sobre el dispositivo).

Los AVR mencionan algo parecido y ya todos sabemos que el hardware tiene algo más de protección a diferencia de los PIC.

Los PLC generalmente están basados en núcleos ARM construidos por 'x' empresas que los dotan de periféricos sencillos o muy robustos de acuerdo al entorno donde va a trabajar.

Todo lo demás echo por estudiantes/aficionados son solo intentos que no siguen generalmente todas las normas/reglas de diseño que hasta para hacer PCB hay normas que muchos desconocen y no basta que se vea bonito u ordenado.
 
...
Los AVR mencionan algo parecido y ya todos sabemos que el hardware tiene algo más de protección a diferencia de los PIC.

Mi experiencia con los AVR con respecto a eso, durante el arranque de un motor (nada potente, el típico de un compresor casero), tenia una placa de prototipo casera con el AVR + una PC conectados en el mismo tomacorriente que el motor, la PC se reinicio, el AVR no se reseteo.

Y encima en esa prueba el AVR no tenía todos los filtos que recomienda el fabricante, solo tenía los capacitores de desacople.
 
Mi experiencia con los AVR con respecto a eso, durante el arranque de un motor (nada potente, el típico de un compresor casero), tenia una placa de prototipo casera con el AVR + una PC conectados en el mismo tomacorriente que el motor, la PC se reinicio, el AVR no se reseteo.

Y encima en esa prueba el AVR no tenía todos los filtos que recomienda el fabricante, solo tenía los capacitores de desacople.

Es bueno saber de las experiencias de los demás. La ventaja de los PIC y vende muchísimos es porque son muy populares.

¿Por qué?

Bajo coste. (AVR son más bajos).
En cada salida de los pines tiene mucho para consumir como 25 mA. Algo que destaca frente a otras marcas que no tienen.
Muy usados entre aficionados.
Mucha documentación, ejemplos y tutoriales, en muchos idiomas y incluyendo es español.
Pocas instrucciones del ASM.
Libros en español. Aún se siguen haciendo, el último con el nuevo PIC16F886. AVR nada de español, en Inglés de sobra.
Se usa mucho en Universidades, otras han quitado Motorola y han puesto PIC. En instituto también.
Y mucho más...

Con el tiempo escogerás otras alternativas o opciones, en mi caso quería pasarme a AVR, como es el mismo perro pero de distinto collar, prefiero el ARM junto con C#, solo falta que sea muy estandar y lo distribuyan mucho por España.

Un saludo.

...
Obvio que para el campo industrial estan los PLC que son robustos y hechos para trabajar en un ambiente lleno de ruido, tambien la flexibilidad de su aplicacion, pero por ahi vi varios proyectos academicos basados en pic-avr para hacer un plc, incluso algunos aplicaciones industriales basadas en arduino ... :eek:, pondre mas tarde los links :D

Hasta el PIC16F84A tiene su especie de PLC bien hecho frente a ruidos.
PLC84_3.jpg


En realidad basta con leer, recuerdo que vi en algún momento algo relacionado con el sector para el cuál se fabrican los PIC y ésta información lo encontré en la misma página de Microchip; ...

Los PLC generalmente están basados en núcleos ARM construidos por 'x' empresas que los dotan de periféricos sencillos o muy robustos de acuerdo al entorno donde va a trabajar.

ARM es ARM, parece que se lo están tomando en serio, por eso quiero ARM con C#, un buen microcontrolador, mejor que los PIC en muchos aspectos con gran diferencia y usa mi lenguaje favorito, C#. En la Web como dije arriba en otros post, hay hasta vídeo de ejemplos.

Mi experiencia con los AVR con respecto a eso, durante el arranque de un motor (nada potente, el típico de un compresor casero), tenia una placa de prototipo casera con el AVR + una PC conectados en el mismo tomacorriente que el motor, la PC se reinicio, el AVR no se reseteo.

Y encima en esa prueba el AVR no tenía todos los filtos que recomienda el fabricante, solo tenía los capacitores de desacople.

Es bueno saber de las experiencias de los demás. La ventaja de los PIC y vende muchísimos es porque son muy populares.

¿Por qué?

Bajo coste. (AVR son más bajos).
En cada salida de los pines tiene mucho para consumir como 25 mA. Algo que destaca frente a otras marcas que no tienen.
Muy usados entre aficionados.
Mucha documentación, ejemplos y tutoriales, en muchos idiomas y incluyendo es español.
Pocas instrucciones del ASM.
Libros en español. Aún se siguen haciendo, el último con el nuevo PIC16F886. AVR nada de español, en Inglés de sobra.
Se usa mucho en Universidades, otras han quitado Motorola y han puesto PIC. En instituto también.
Y mucho más...

Con el tiempo escogerás otras alternativas o opciones, en mi caso quería pasarme a AVR, como es el mismo perro pero de distinto collar, prefiero el ARM junto con C#, solo falta que sea muy estandar y lo distribuyan mucho por España.

Un saludo.
 
Es bueno saber de las experiencias de los demás. La ventaja de los PIC y vende muchísimos es porque son muy populares.

¿Por qué?

Bajo coste. (AVR son más bajos).
En cada salida de los pines tiene mucho para consumir como 25 mA. Algo que destaca frente a otras marcas que no tienen.
Muy usados entre aficionados.
Mucha documentación, ejemplos y tutoriales, en muchos idiomas y incluyendo es español.
Pocas instrucciones del ASM.
Libros en español. Aún se siguen haciendo, el último con el nuevo PIC16F886. AVR nada de español, en Inglés de sobra.
Se usa mucho en Universidades, otras han quitado Motorola y han puesto PIC. En instituto también.
Y mucho más...

Con el tiempo escogerás otras alternativas o opciones, en mi caso quería pasarme a AVR, como es el mismo perro pero de distinto collar, prefiero el ARM junto con C#, solo falta que sea muy estandar y lo distribuyan mucho por España.

Un saludo.

Igual con los PIC me imagino que el fabricante te debe tirar un montón de consejos para evitar eso mediante filtros, con lo cual estas en lo mismo, siempre darle importancia a los consejos que te dá el fabricante.

No sé experiencia tendrás vos en ese sentido, pero seguro que una vez que encontraste el filtro adecuado el uC no se te restea más.
 
Yo tambien hice un μPLC con PIC16F819, con él se aprobaron dos materia el semestre pasado ;), lo diseñe para ser robusto, solo el PIC tiene su propio regulador y el resto usa otras fuentes de voltaje, el PCB está tan lleno que me dio insomnio lograr que todo entrara con las consideraciones de ruteo, en especial por lo de las lecturas análogas, estas pasan a dos LM324, uno que se alimenta directo y un segundo que tiene regulador específicamente al voltaje necesario para dar la salida de 5V aún con las perdidas del A.O., además de resistencias al conectarlo al PIC, solo el puerto B no tiene nada ya que está pensado dejarlo libre para que se le pueda adaptar cosas extras, pero de ahí esta protegido para que si algo se conecta mal o incluso si se programa mal (entradas como salidas) el PIC sea el ultimo en recibir daños (y lo que se dañe sea economico de reemplazar), tambien tiene una generosa capacitancia total de 4.2mf solo en la placa del circuito (aparte la de la fuente de alimentación) y capacitores de tántalo en los reguladores, solo lo diseñe "para que los estudiantes tengan un modelo de bajo costo para realizar practicas acerca de PLC", es bastante robusto y el único motivo de que eligiera ese chip fue por que era el más barato que tenia ADC y era compatible con LDmicro, con suficientes consideraciones de diseño estos bichos de Microchip pueden ser bastante estables, un PLC solo necesita cumplir ciertas características para considerarse como tal, no importa si su microprocesador es un Intel o algo tan simple como un microcontrolador... aunque igual prefiero que este μPLC que hice se siga usando solo para practicas en ambientes no críticos por si acaso (igual no tiene la memoria para hacer mucho :p)
 
Lo que te diga el fabricante es una cosa, en este caso es lo que dice las experiencias de muchos aficionados que he estado siguiendo desde el 2000, en el 2005 empecé con algo y no tenía Internet ni libro, luego compré el libro www.pic16f84a.org y me gustó, luego otro libro del PIC16F886 en asm y en C del CCS. Como si fuera un datasheet en español. Lo que deseo un buen libro en XC8 en el futuro y el XC32, así nos adentramos en PIC de 32 bits, que hacen más cosas. Total, si otras marcas se pusieran de acuerdo para traducir, pues mejor que mejor, por ahora, aunque PIC no sea gran cosa, es la reina en ventas. El que me llama la atención ahora más que AVR son los ARM, son potentísimos, como no hay tanta documentación en español y apoyo como los AVR y PIC al mismo nivel, pues es lo que hay. Por ahora parece que AVR sigue reciendo gracias a Arduino, PIC tiene algo parecido y ARM con lo qu ecomenté ese día.

http://blog.bricogeek.com/noticias/electronica/microsoft-gadgeteer/

Saludo.
 
Meta como que siento que defiendes a capa y espada el uso de los PIC, yo en lo personal no discuito sobre "Cual es mejor" Al final uno se tiene que adaptar con lo que te den para trabajar. Sobre cual es mas poderoso hummm para que discutir sobre eso si muchos terminan haciendo cosas que se pueden hacer con otro mucho mas sencillo jejej cuantas veces he visto "Proyecto de antena motorizda" y zasss le clavan un PIC16F877 cuando bien pudo haber funcionado el 16F84 o encarrerados hasta un 12F508.

Asi pues el dia que tenga la "necesidad" de algo mas poderozo "cosa que veo dificil a no ser que sea por trabajo" entonces buscare algo mas grande que mi pedorro attiny88.

SObre que lenguaje usar pasa algo similar. Se usa el que mas te acomode a uno y ya. Yo conosco un señor que hacer programas en pic a la medida para venderlos a fabricas pequeñas y usa flowcode. Igual no dudo que alla quien crecio con el ASM y de ahi no salga. O quienes como yo siguen los pasos del C y se acabo hasta ahi llegue. SI me pongo a querer aprender tantos otros lenguajes al final no voy acabar entendiendo ni uno
 
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
 
Meta como que siento que defiendes a capa y espada el uso de los PIC,

Tampoco es eso. Estoy con el ASM, claro que si, aunque cansándome, ya que me pego media vida con ella, ahora estoy observando el C para PIC practicando primero con el CCS, más adelante me meteré con el XC8. En cuanto a los PIC, no son de lo mejor, solo la gran documentación que hay sobre ello.

Prefiero algo que se me hace atractivo,. un ARM programado bajo Visual Studio .net y C#. Si es por elegir, claro.

Total, escojas el que escojas, en el fondo hará lo mismo con maor o menos rendimiento, como apagar y encender Led para practicar.

Saludo.
 
Que estamos en sistemas embebidos o no, uso de Visual Studio.net para micro controlador que malos son.
En esto el control del tiempo es preciso así con C y ASM. Si no entienden estudien de nuevo sistemas de control automático.

Otro es el tema de los ARM9, Cortex A. Ahí se maneja con un sistema operativo complejo.
Y de los Cortex M4 se maneja ASM sobre todo en el DSP y coma flotante si no para que sirven.

 
Visual Studio .net comparado con C y ASM por supuesto, ajjajajjaja. Eso si, .net es muchísimo más cómodo que el C y ASM. Ahora, en el futuro deben mejorar.
 
Estado
Cerrado para nuevas respuestas.
Atrás
Arriba