Selección de los microcontroladores adecuados para este proyecto (basado en Arduino)

Estoy pensando en comprar algunos kits de desarrollo de Arduino para migrar de mi plataforma de desarrollo actual (picaxe) a Arduino. Quiero comprar justo lo que necesito para desarrollar mi próximo proyecto, pero teniendo en cuenta que soy un total ignorante de las capacidades de Arduino, tengo algunos problemas para decidir qué comprar. Así que decidí explicarles lo que quiero hacer y lo que creo que necesito (en términos de hardware) con la esperanza de tener algunos comentarios.

Ok, la idea es simple, a través del cable serial de mi computadora (o USBtoserial) enviaré algunos comandos a mi placa Arduino Uno: estos comandos se componen de varios bits (definidos en mi propio protocolo); de todos modos, después de que mi Arduino haya recibido estos comandos, tomará algunas acciones, por el momento, la única acción que importa es enviar una palabra a otros Arduinos conectados a un bus de comunicación (necesito decidir si I2C, serie o TTL). Esta palabra se compone de 1000 bits, los primeros 8 bits son solo el encabezado (que contiene la dirección del chip que recibirá los datos) y el resto son solo datos (la longitud real de esta palabra siempre se fija en 1000 bits).

Así que en resumen esto es lo que haré:ingrese la descripción de la imagen aquí

Por ejemplo, desde la PC, envío el comando por el cable serial: 11011011 1010101010011…….01101. Esto va a la placa Arduino que lo reenvía al bus de comunicación donde todos los demás microcontroladores siempre están escuchando el bus, leerán los primeros 8 bits y los compararán con su propia dirección: si coincide con la dirección del microcontrolador (almacenada en una variable), almacenará los siguientes bits en la memoria (si se corta la alimentación, no necesito guardar la información, por lo que podría ser una memoria volátil).

Después de eso, el micro estará esperando un comando futuro que eventualmente le indicará que envíe los bits de datos a través de un pin de salida. Todo el micro solo guardará una palabra de 1000 menos 8 bits en ese momento, por lo que la memoria está fijada para solo 9992 bits.

Tengo problemas para decidir qué microcontrolador pequeño usar, qué protocolo de comunicación usar y algunos problemas con el software. Teniendo en cuenta que la distancia entre el primer micro y el último podría ser de hasta 7 metros, creo que I2C no es el camino a seguir, la serie será excelente, pero eso significa que necesitaré un convertidor de serie a ttl en cada micro. (tome en cuenta que pueden ser hasta 128 micros) por lo que puede hacer que el proyecto se salga de mi presupuesto, TTL será genial pero nunca probé una comunicación vía TLL sobre 7 metros, ¿ustedes que opinan? Creo que un buen cable no dejará caer tanto voltaje en 7 metros, también la velocidad que pienso usar es de 19200bits/s como máximo.

Acerca de los micros, mi mayor preocupación es elegir la alternativa más barata porque solo recibirán datos en un pin (datos en serie) guardados en una memoria volátil, y luego enviarán esos datos a una velocidad fija a través de un pin de salida (para encender y de un led por ejemplo). Vi en internet que se podia programar el ATtiny con la placa arduino, este chip es capaz de hacer lo que necesito? ¿Necesito una memoria externa para almacenar los datos? ¿O puedo guardarlo en una variable? (¿Qué memoria sugieres?)

ingrese la descripción de la imagen aquí

Y mi pregunta final es sobre el software, cuando estaba usando PicAxe, un kit de desarrollo muy simple para microcontroladores cuando necesito almacenar una palabra en una entrada en serie, solo hago esto:

serin serpin,N2400,(27),seraddr, b4,b5

Donde serin es el comando para comenzar la adquisición en serie, serpin es el número del pin de entrada que quiero usar y b4 y b5 son variables de cuatro bits, por lo que al usarlas tengo una palabra de 8 bits. La plataforma PicAxe está fijada con 10 vars de 4 bits (b0,b1…….b9) por lo que será imposible almacenar una palabra de 1000 bits sin pasar la información a una memoria externa. Con Attiny puedo almacenar esa cantidad de datos en un programa var? ¿Cuál es el máximo que puedo almacenar? En ese momento, ¿sigues pensando que el attiny es el camino a seguir?

¡Muchas gracias por cualquier comentario y sugerencia!

Pocas líneas por microcontrolador; muchos datos; distancia "larga" -> En mi humilde opinión, UART es el camino a seguir
"Todo el micro solo guardará una palabra de 1000 menos 8 bits en ese momento, por lo que la memoria está fijada para solo 9992 bits". te refieres a 992 bits (1000-8)?

Respuestas (4)

La mayoría de los microcontroladores pequeños serán capaces de hacer lo que necesites. Incluso podrías deshacerte del "envoltorio" de Arduino y usar un micro USB en su lugar.

Microchip, Atmel, TI, ST, etc., todos tienen uC de 8, 16 y 32 bits de diferentes tamaños de RAM/FLASH/EEPROM para elegir. Todos los uC modernos vienen con al menos periféricos UART, SPI, I2C que se pueden usar para sus comunicaciones.
Realmente no hay mucho en ellos, solo elegiría uno y vería si te gusta.
Yo (actualmente) uso ARM de 32 bits de ST y PIC de Microchip de 8, 16 y 32 bits.
Probablemente usaría algunos PIC12F o 16F para los uC esclavos y un PIC18F o PIC24F para el maestro.

Usted menciona que necesita ~ 10kbits de memoria (sin embargo, no está muy claro qué tipo o qué uC lo necesita según su descripción). Sin embargo, es
fácil determinar qué es adecuado, solo verifique las especificaciones de RAM / ROM / EEPROM de cada uC que mira.
Por ejemplo, el PIC16F1938 tiene:

 Parameter Name          Value
 Program Memory Type     Flash
 Program Memory (KB)     28
 CPU Speed (MIPS)        8
 RAM Bytes               1,024
 Data EEPROM (bytes)     256

Por lo tanto, 28 KB de memoria de programa son más que suficientes para almacenar datos no volátiles si su programa es lo suficientemente pequeño (en los PIC más nuevos, también puede leer/escribir en la memoria del programa en tiempo de ejecución). 1024 * 8 = 8192 bits.
Sin embargo, el 16F1527 tiene 1536 bytes de RAM, por lo que podría usar esto si es necesario.

Para el master (alternativas a Arduino) hay algo como el 18F25J50 o similar, que tiene un periférico USB 2.0. Microchip proporciona una pila USB con un montón de firmware de ejemplo para que pueda comenzar con USB.
Si necesita algo más potente para el maestro, eche un vistazo a la serie PIC24 con hasta 256 K de Flash y 96 K de RAM. O incluso el PIC32 que es de 32 bits y hasta 80MIPS. El PICKit3 es un programador de bajo precio que programará todos los PIC mencionados anteriormente, y MPLAB (o MPLABX) es un IDE gratuito para el desarrollo de firmware.

La comunicación se puede realizar con I2C, que se ocupa de la configuración maestro/esclavo y el direccionamiento fácilmente. De lo único que tienes que preocuparte es de enviar los datos. 7 metros no deberían ser un problema con un entorno razonablemente silencioso y la configuración correcta (pulgadas de bajo valor, digamos 2.2k, cable de baja capacitancia)

Como ya está planeando usar un Arduino, ¿por qué no seguir con el de Arduino? O consiga un programador AVR y use chips ATMega328 desnudos.

En cuanto a la comunicación: RS485 es un bus muy confiable y los chips transceptores son baratos. Por un costo aún menor, podría enviar una señal de nivel TTL y regenerarla en cada nodo .

Buena respuesta, pero no hay necesidad de un programador adicional, Arduinos se puede usar para programar chips AVR: arduino.cc/en/Tutorial/ArduinoISP :)

Eche un vistazo a la serie TI MSP430. Son realmente de bajo costo (desde menos de $ 1.00) y las características aumentan con el precio hasta llegar a pequeños dispositivos SoC bastante potentes.

Con respecto a sus inquietudes sobre la distancia, consulte estos chips: Extensores de bus I2C . Están hechos por algunos fabricantes diferentes, puede encontrar uno que se ajuste a sus necesidades y presupuesto.

Creo que I2C es una buena opción para el protocolo dado que desea un esquema direccionable. Parece que Arduino puede hacer lo que quieras (ya que todos tienen capacidad UART e I2C), pero en realidad cualquier microcontrolador con esos periféricos funcionará.

Como mencionó @Oli Glaser, usar una resistencia pull-up más fuerte (más pequeña) también ayudará, pero si eso solo puede llegar hasta cierto punto, definitivamente revise los extensores de bus, ya que he tenido éxito con ellos antes.

Con respecto a sus preocupaciones sobre el tamaño, consulte las especificaciones del microcontrolador que está viendo. Específicamente, desea ver cuánta SRAM tiene. Usted mencionó que desea almacenar en búfer 1000 bits == 125 Bytes. La especificación SRAM generalmente se proporciona en KB (Kilo-Bytes), así que asegúrese de elegir uno que sea más grande que eso. Si también está utilizando más búferes en su código, o su programa es algo complejo (grande y con muchas llamadas a funciones), entonces probablemente querrá al menos 512 bytes - 1 KB de SRAM. Es difícil determinar cuánto necesita sin saber más sobre la aplicación. Si no necesita todos los 125 bytes a la vez, también puede transmitirlos desde y hacia la EEPROM.

No creo que este sea el camino a seguir, especialmente para enviar esa cantidad de datos; UART me parece un protocolo más confiable, también porque no necesita ahorrar en términos de pines o líneas.
@clabacchio, a menos que esté sugiriendo agregar una suma de verificación al protocolo, no puedo imaginar cómo UART será más o menos confiable dado que no ha hecho ningún comentario sobre cableado o blindaje ni proporcionó ningún hecho o evidencia. ¿Puedes explicar cómo? Hice mi sugerencia para I2C en función de la arquitectura maestro/esclavo direccionable que especificó, y porque I2C ya se encarga de todo eso.
Premisa: esa es mi idea, basada en mi conocimiento y no pretendo en absoluto tener la verdad absoluta. Entonces, AFAIK, I2C es una interfaz diseñada para la comunicación intra-PCB, como también sugiere el nombre. Al ser un drenaje abierto, no es realmente robusto y preferiría usar un protocolo más fuerte como UART. Entonces, es cierto que las consideraciones de cableado y blindaje son necesarias, pero mi objeción se debió únicamente al hecho de que es extraño enviar señales en cables de 7 m con I2C, y nunca he visto eso.
@clabacchio, estuvo de acuerdo, es extraño, por eso sugerí los circuitos integrados extensores de bus para habilitar esa capacidad. Estoy de acuerdo en que la señalización UART sobre RS232 probablemente funcionaría mejor en esas longitudes, pero sopesé el hecho de que necesitaría escribir su propio protocolo maestro/esclavo en lugar de usar un periférico de hardware. A fin de cuentas, no creo que sean malas ideas, solo compromisos. Gracias por la respuesta.
De todos modos, si tuviera que elegir, usaría una red inalámbrica :)
@clabacchio: I2C se usa principalmente para cosas dentro de PCB, pero no hay ninguna razón por la que no se pueda usar en distancias más largas. Esta es la razón por la que están disponibles los circuitos integrados de búfer. Creo que se deberían lograr 7 metros sin un búfer dependiendo de la cantidad de esclavos y la configuración correcta. Aquí hay un par de referencias que mencionan el uso de I2C hasta 100 m 1. Preguntas frecuentes sobre I2C 2. Publicación relacionada con la distancia I2C
@OliGlaser guau! De todos modos, ¿solo es posible o también es recomendable?
@clabacchio: para hasta 7 m a las bajas velocidades necesarias, lo recomendaría. Si ejecutó el I2C a, digamos, 22 kHz, cubriría los 19200 baudios mencionados y tendría un margen de error aún mayor. Si quisiera que fuera más sólido, también podría usar un IC de búfer, pero creo que probablemente sea una exageración. Solo estamos hablando de un par de metros adicionales más allá del rango "habitual", por lo que siempre que se preste un poco de atención a los pullups, la capacitancia del bus y el cableado y las señales se verifiquen con alcance para confirmar que no son marginales, estoy seguro estará bien.
@OliGlaser Realmente puedo creerte, simplemente nunca he visto salir I2C de una PCB... pero de hecho lo he visto unas cuantas veces...
Selección de los microcontroladores adecuados para este proyecto (basado en Arduino)
RespuestasAquíPolítica de privacidad1y, 0v