Atmel vs Microchip

Estado
Cerrado para nuevas respuestas.
no tengo NPI que son esas shield .
yo hace años ya aprendi ASm y hice algunas cosas y lñuego a dormir.
sigo pero con cosas mas simples.

el tema es que es previsible que pase esto, de igual modo que "viejos" que aprendieron todo de valvulas electronicas o de programacion con tarjetas perforadas luego tuvieron que irse a dormir.

un dia de estos muy proximo el micro controlador mas chiquito, mas berreta , mas barato tendra una memoria de 64 K y eso impulsara a prpogramadores a generar nuevos lenguajes.
tan amigables que "uno que ni sabe el codigo de colorees de una R. podra programar " .

y asi es .
si te sobra memoria y no tenes un problema de velocidad asi es .
simple competencia.

encima hoy dia ( y con razon) muchisima gente se tira a programacion , mas que a electronica.
asi que ademas tenes programdores (no tontos) que pueden diseñar una placa sin casi saber que es una compuerta, o un 4017 , o que entraran a un foro a preguntar como se hace para manejar un relay .

sabes cuantas areas fueron afectadas con esto de la masividad ?? y de este continuo avance ?? muchisima gente que podria haber tenido trabajo siempre se quedo sin el .
yo, desde casi siempre gane mas plata por ir a tirar cables que por diseñar una placa.
hay un secreto, en esto , en aquello y en lo otro:
no obsesionarse.
si te gusta pintar paisajes o programar micros hacelo de gusto.
si queres ganar plata y ves que lo que deja plata es vender choripanes en la costanera ( y no te disgusta) , pues hace eso >>> venta de chori para hacer plata y luego a lo que te gusta para entretenerte. .
no quieras juntarlos si no da .
y si da.........ya dara solo .

lo primero es eso:
ver a donde va cada cosa y no querer forzarlas.
yo tarde años en entenderlo.



La verdad es medio un secreto mio pero me da como que bronquita esto de los shields.

absolutamente normal.
y sano diria .
 
Última edición:
X1un1Mundo1Mejor1wii me gusta tu idea, y si hacemos un grupo de developers tipo arduino para pic? que opinan? un tributito para nuestro viejo y querido amigo "el viejo pic" :D

Aparte recordemos el frustrado intento de PICAXE. vamos a dejar que arduino nos someta? jamas!

Moriré pero luchando :)

Esto me recuerda a battlefield batalla naval .. los marines que derrotaron a la nave extraterrestre. de hecho en mis tiempos libres (que es la 3 parte del dia, puedo distribuir un espacio para tal fin, deberíamos abrir otro hilo :) )
 
X1un1Mundo1Mejor1wii me gusta tu idea, y si hacemos un grupo de developers tipo arduino para pic? que opinan? un tributito para nuestro viejo y querido amigo "el viejo pic" :D

Aparte recordemos el frustrado intento de PICAXE. vamos a dejar que arduino nos someta? jamas!

Existe un grupo de developers tipo Arduino para PIC ... se llama Pinguino... y no ha despegado tanto como arduino, desconozco la razon...

http://www.pinguino.cc/
 
no tengo NPI que son esas shield .

Yo tampoco sabía así que averigué, al parecer son módulos que se van agregando a una placa principal para que aumentar su electrónica sin soldar absolutamente nada (el lego de la electrónica en temas de uC).

yo hace años ya aprendi ASm y hice algunas cosas y lñuego a dormir.
sigo pero con cosas mas simples.

Mirá assembler es lo más duro que vas a encontrar cuando trabajas con uC (y hoy en día es obsoleto su uso, salvo en pequeñas cosas que son muy necesarias, esto no quiere decir que no sea fundamental conocer ese lenguaje), si querés darle una segunda oportunidad al mundo de los uC, te aconsejo aprender lenguaje C desde la PC, se que es un dolor de hu...o aprender algo desde 0, pero no es difícil.

Y después ese lenguaje lo aplicás a cualquier uC.

un dia de estos muy proximo el micro controlador mas chiquito, mas berreta , mas barato tendra una memoria de 64 K y eso impulsara a prpogramadores a generar nuevos lenguajes.

Ya estamos llegando a eso, incluso C que es un lenguaje de mayor nivel que assembler, resulta complejo de llevar a medida que el proyecto crece, no es algo que no se pueda llevar, pero pide a gritos lenguaje de mayor nivel (ej. c++ o java).

encima hoy dia ( y con razon) muchisima gente se tira a programacion , mas que a electronica.
asi que ademas tenes programdores (no tontos) que pueden diseñar una placa sin casi saber que es una compuerta, o un 4017 , o que entraran a un foro a preguntar como se hace para manejar un relay .

Ese tipo que no tienen todos esos conocimientos que mencionan, a lo sumo puede apuntar a un desarrollos ya hechos e ir combinandolos, pero a medida que se le presenten cosas de mayor complejidad, si no está bien preparado hace agua.
 
Última edición:
No hay que subestimar a "esos que no saben nada" que no siempre es asi, la realidad es distinta y se ve en todas parte, hoy es menos necesario alguien que maneje flip flops y mas necesario uno que maneje FPGA, menos uno que sabe Assembler y mas uno que sabe C y aplicarlo a un procesador y que sabe manejar MMU, cache, etc. o que al menos sabe inicializar un sistema operativo.

Es entendible que nos de bronca el cambio pero independientemente de lo que pensemos o queramos el cambio ocurrira, y no es algo nuevo. Lo que es nuevo es la gran velocidad del cambio y queda en nosotros mantenernos sobre la ola o dar un paso al costado.

Un super experto en valvulas hoy, nos guste o no, no vale nada. Salvo quiza para una oportunidad entre mil para hacer un ampli para exigentes, pero fuera de eso.... campo nulo.

La parte buena es que la accesibilidad de los datos es hoy impresionante y muy democraticamente accesible a todos. El que quiere y con un poco de suerte... se mantiene arriba de la ola.
 
No hay que subestimar a "esos que no saben nada" que no siempre es asi, la realidad es distinta y se ve en todas parte, hoy es menos necesario alguien que maneje flip flops y mas necesario uno que maneje FPGA, menos uno que sabe Assembler y mas uno que sabe C y aplicarlo a un procesador y que sabe manejar MMU, cache, etc. o que al menos sabe inicializar un sistema operativo.

Hasta un cierto punto, si empiezan a cambiar la condiciones de entorno, por ej. trabajar en ambiente de mayor ºT, ya no lo resuelve cualquiera, si la aplicación se usa en ambientes ruidosos tal vez deje de funcionar.

Hay ciertos aspectos en donde solamente programar no alcanza, además tenés que tener conocimientos en el diseño del hard según la aplicación y el entorno donde será usado y saber diseñar un buen PCB, ¿qué sabés si esos módulos tiene un PCB bien diseñados?

A lo que apunto, la diferencia puede estar en los detalles, no en lo genérico de la aplicación.
 
Hola:

Ahora se programará dispositivos con C# y los módulos estarán diseñados para que iniciados y novatos no tengan qu esaber de electrónica para controlar LEd y relés entre otras muchas cosas más.

Más información aquí.
gadgeteer_example.jpg


http://www.netmf.com/gadgeteer/

Por mi parte es de agradecer, C# y microcntroladores.

Saludo.
 
No creo que C# vaya a durar mucho tiempo... definitivamente la guerra de software esta siendo ganada por los sistemas Open Source...
 
No creo que C# vaya a durar mucho tiempo... definitivamente la guerra de software esta siendo ganada por los sistemas Open Source...

No se si va a pasar eso a la larga (teniendo a Ms detrás lo veo difícil), pero por lo menos yo prefiero un lenguaje como Java que te permite trabajar en cualquier lado, lo malo es que con Oracle pareciera que la cosa no va tan bien como antes.
 
No se si va a pasar eso a la larga (teniendo a Ms detrás lo veo difícil), pero por lo menos yo prefiero un lenguaje como Java que te permite trabajar en cualquier lado, lo malo es que con Oracle pareciera que la cosa no va tan bien como antes.

Depende de como lo orienten, sin embargo Microsoft ya tubo cierto recorrido en esto con Microsoft Robotics y según veo, ya no hay actualizaciones al respecto y se a quedado dentro de un sector.
Si les va bien, solo se verán dichos módulos en las universidades. Me agradan que sean de buen nivel ya que son con ARM, almenos con esto justifica el echo de usar C# pero limitado al hardware... mmm
 
No se si va a pasar eso a la larga (teniendo a Ms detrás lo veo difícil), pero por lo menos yo prefiero un lenguaje como Java que te permite trabajar en cualquier lado, lo malo es que con Oracle pareciera que la cosa no va tan bien como antes.

Java consume recursos :/
bueno pero usen el IDE eclipse y Netbeans,
En cuanto a Arduino(AVR) ARM PFGA o PIC DSPIC, todo apunta al tiempo en que te demores en hacer un proyecto, su fiabilidad, y los costos de producción.
Mientras exista ese equilibrio y quien mejor lo sobrelleve.. siempre existirá mercado para ese dispositivo y software u entornos de programación.
 
Estoy en el mundo Visual Basic .Net, te aseguro que en el mundo empresarial se usa bastante y se usará más la era .NET, C# lo está optimizando hasta en las narices.

De todas maneras hay que usar el C y el nuevo si acaso C++ para los PIC32. Por fin un C++ para los PIC, es mucho más eficiente. ¿Ahora cuando se dan cuenta?

Programar un PIC en C es la leche, el ASM me tiene negro y m epego media vida haciendo lo mismo. Viendo la cantidad de microcontroladores y programado en C mejor que los PIc, me han disolucionado en algunos aspecto, en otros no porque tiene mayor información que la competencia.

Microcontroladores


Seguro que me falta algún microcontroladore de la lista de arriba, y eso sin contar las familias diferentes de cada marca como los PIC de 8, 16, 32 e incluso subfamlia como los PIC32, dsPIC y demás, piensa en otras marcas poco dificil de encontrar información.

Los más que veo que se usa son los Pic, AVR y ahora cada vez más los ARM.

No creo que C# vaya a durar mucho tiempo... definitivamente la guerra de software esta siendo ganada por los sistemas Open Source...

No están en guerra, en algunos artículos comentan que es un complemento para Arduino y Raspberry Pi.

Otro dato que MicroSoft dejó de lado, al menos temporal es el XNA Game Studio C# y VB .net para PC y la X-Box 360. Sólo temporal ya no se actualiza, se cree que se está haciendo el nuevo motor del entorno para la nueva X-Box One.

Lo de Robotic no tengo idea pero aquí hay más información.

No se el motivo de que MicroSoft le den por monatnos hardware modulares para novatos sin saber electrónica como manejar Relés, Leds, ventiladores, motores, USB, y demás cosas que nosotros hacemos desde cero con los PIC, AVR y algunos más. El lenguaje a utilizar es el C#.

También le dieron programar mediante C# el Kinect en PC, el Kinect 2 seguirá el mismo camino.

He dado una asignatura con Java, no me gusta mucho y menos aún si es de Oracle y su futuro, hay que reconocer que es el rey del más usado y multiplataforma hasta el momento.

Lo que me gusta de
Gadgeteer.



DesignerConnectedModules.png


ArcadeCad.png


La propuesta de Microsoft no está tan mal, le doy la bienvenida, sobre todo lo que sea de programación y electrónica.

http://www.netmf.com/Gadgeteer/what-is-gadgeteer.aspx

;)
 
Última edición:
Es como el Lego NXP pero de mayor nivel.
No contradigo... C# es el lenguaje que mejor entiendo y núcleos ARM para esto es una buena combinación.
 
Ve más difícil conseguir esos módulos de electrónica para C#. Prefiero que hagan esquemas eléctricos y los monto. En España no se si algún día traerán estas cosas. De todas maneras tiene que haber demanda, viendo Arduino, a pesar de tener cierto éxito , no es muy demandado que digamos.
 
La semana pasada conocí a un tipo que hace unos sensores para una empresa, los hace con arduino.
EL chavon lo programa con las shields y todo y lo sumerge en resina epoxi, y vende un cuadrado donde se encuentra las shields y todo lo que use esta cosa de arduino.

En el peor de los casos sacaría el chip y rediseño el PCB pero nunca haría esa estupidez :eek: yo compré un Arduino UNO solo por la popularidad de esa cosa, pero sinceramente solo lo usé una ves que quería volver MIDI mi teclado, ahora he dejado ese proyecto suspendido y no he sacado el Arduino para nada, si solo es para jugar o hacer un proyecto rápido para uso personal agarro lo que tenga a la mano y alcance su capacidad, tambien tengo LaunchPads MSP430 y Stellaris que puedo programar con Energía con el mismo lenguaje que Arduino, pero soy muy dedicado a la eficiencia en especial la energética y que el MCU no realice actividades innecesarias y eso es lo que menos me gusta de Arduino, que se como hacer que haga las cosas, pero no se que hace detrás de cada función y cuantos recursos me esta desperdiciando, prefiero programar a mi manera en C modificando los registros directamente, ni los PIC programo con las funciones que me trae el compilador o las cabeceras de Microchip.

Y ese es el por qué me da igual cual MCU programe, al final todos los hago igual tras leer los nombres de los registros y saber que hace cada BIT en ellos.
 
...pero soy muy dedicado a la eficiencia en especial la energética y que el MCU no realice actividades innecesarias y eso es lo que menos me gusta de Arduino, que se como hacer que haga las cosas, pero no se que hace detrás de cada función y cuantos recursos me esta desperdiciando, prefiero programar a mi manera en C modificando los registros directamente, ni los PIC programo con las funciones que me trae el compilador o las cabeceras de Microchip.

Y ese es el por qué me da igual cual MCU programe, al final todos los hago igual tras leer los nombres de los registros y saber que hace cada BIT en ellos.

Viéndolo desde la eficiencia energética coincido, no cabe duda de que es importante hacer que el micro ejecute la menor cantidad de código posible y pase la mayor parte del tiempo en modo sleep, bajar las tensiones de alimentación, etc. En ese sentido sí se justifica hacer código "bare metal" (sin un framework o RTOS en el medio).

A mi también me pasa con algunos periféricos, me lleva el mismo tiempo entender la librería que provee el fabricante que configurar los registros a mano (un módulo PWM, un timer, un conversor AD, etc). Además que las que provee el fabricante no suelen hacer un buen uso de interrupciones.

Pero hay cosas en las que ya no podemos hacer un seguimiento tan fino, y no nos queda otra que incluir la librería y usarla lo mejor posible.
Por ejemplo, una librería USB (CDC, HID), ethernet, o una librería para un LCD gráfico.

O que pasa si tenemos un proyecto complejo donde empieza a haber de todo: manejo remoto por GSM + log de datos en una SD con sistema de archivos FAT + conectividad USB con bootloader + manejo de display + teclado + sensores varios….
Ahí ya es difícil pensar en todas las posibles interacciones del código, solo queda separar en tareas usando un RTOS y tratar de que las tareas no tengan problemas de sincronización.

Después está el compromiso de ingeniería entre hacer una solución a medida, o algo que sea configurable, expandible y con código reutilizable. En el 1er caso es un sistema fuertemente embebido y en el 2do se parece más a lo que pasó con los celulares que pasaron a ser computadoras de bolsillo. En unos se utilizará C y ASM con micros de 8/16 bits, o incluso se diseñará una ASIC para ello; y en otros se utilizará un sistema operativo con C++ (algunos incluso Java!!! :eek:), manejo de memoria dinámica, etc.

Para terminar, creo que hay lugar para todo el mundo, y más aún, a nosotros nos conviene que la electrónica hobby se masifique con plataformas tipo Arduino.
Veo al usuario de Arduino no como un competidor sino como un posible cliente: cada vez que salga un chip nuevo (sensor, actuador, comunicaciones, lo que sea) el tipo va a precisar que alguien le haga la plaqueta y la librería, alguno va a querer manejar todo por I2C (por que no va a tener los conceptos básicos para usar el conversor AD del micro), otro por SPI, o que sea compatible con raspberry pi...
Fíjense que este es el negocio de Adafruit, Parallax, Sparkfun, etc.
Y a mayor masificación menor precio de los componentes y los servicios asociados (fabricación de PCB, ensamble, proveeduría de componentes).

Incluso los tipos que tienen conocimientos de software de alto nivel pueden hacer su aporte manejando código más complejo, por ejemplo, que sepa hacer un diseño modelando con UML implementando código con técnicas ágiles, diseño iterativo y haciendo TDD (test driven development) y llevando un buen sistema de seguimiento de bugs, con un sistema de documentación claro y repositorios de código sanos; y otras yerbas que no tengo idea (las que mencioné tampoco tengo mucha idea :oops:, solo sé que existen).

En fin, los proyectos con electrónica se van haciendo más complejos. Cada vez van a requerir más de esto último, más gente, mejor organización y planificación, etc. Cosas como la electrónica automotriz (no solo para el motor del auto, sino para manejar y hacer el piloto automático tipo google car → lo siento por los camioneros), comunicaciones, autopistas inteligentes, inteligencia artificial, robots autónomos, electro-medicina, redes de sensores inalámbricos... antes era impensable poder implementar sistemas tan complejos, ahora solo es cuestión de poder manejar complejidad en forma eficiente.

Es un lindo tema, daría para un tema nuevo.
 
Última edición:
Coincido... actualmente los proyectos de "encender un led" o incluso "controlar un robot por puerto paralelo" ya son cada vez mas academicos, pero no practicos... los nuevos proyectos se estan haciendo cada vez mas complejos y requieren el uso de multiples tecnologias y multiples expertos, cada uno en su rama para poder terminar el proyecto y por eso estan teniendo tanto exito los sistemas embebidos, ya que permiten hacer mas cosas con menos tiempo y recursos...
 
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.
 
...

Pero hay cosas en las que ya no podemos hacer un seguimiento tan fino, y no nos queda otra que incluir la librería y usarla lo mejor posible.
Por ejemplo, una librería USB (CDC, HID), ethernet, o una librería para un LCD gráfico.

...

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.

Pero de momento me estoy peleando con FreeRtos en ARM y esta muy bueno las cosas que podés hacer y la facilidad de manejar los tiempos a tu antojo + encapsular en tareas las distintas operaciones. El manejo de las interrupciones con semáforos es buenísimo y garantizas ejecutar toda una tarea afuera de la rutina.

Entonces ya que estoy delegando gran parte del control al Scheduler, no veo con malos ojos hacer lo mismo con Ethernet, USB o cosas más complejas.
 
Estado
Cerrado para nuevas respuestas.
Atrás
Arriba