Programación de varios AVR con un ISP: ¿qué línea romper?

Supongamos que tengo dos AVR conectados a un conector ISP.

ingrese la descripción de la imagen aquíPara programar solo una MCU en esta configuración, necesito romper una (o quizás varias) líneas que van a la MCU que no quiero programar en este momento.

La primera línea que me viene a la mente es VCC, que sería genial ya que ahorraría energía. Pero como sabemos, la energía pasará por líneas digitales que tienen diodos de protección para VCC y GND.

Así que elegiría la línea RESET. ¿Alguna otra idea?

¿De qué se tratan esos diodos dentro de MCU1? ¡Los AVR no tienen esa estructura en el pin de reinicio! (todos los demás pines, solo reiniciar es especial)
@Jasen, probablemente tengas razón con respecto al pin RESET. No estaba al tanto. Simplemente coloque esto para indicar la protección de diodo en los pines digitales.
la programación en paralelo utiliza 12V en el reset como señal de activación, por lo que no tiene diodo de protección superior.
Supongo que la programación paralela de @Jasen es otra cosa. ¿El ISP también usa 12V en RESET?
no, en avr ISP solo usa VCC y 0V, pero PIC usa 12V para ISP
... Y esa es la razón por la que todos los demás usan JTAG ...
Ha dibujado por error diodos en el pin de reinicio. Estos no están disponibles ya que el pin de reinicio se usa para la programación de alto voltaje para recuperar fusibles.

Respuestas (2)

rompa MOSI porque es una salida de regreso al host y rompa SCK para que la otra MCU no pueda ver los comandos de programación.

editar: esto aún no funcionará ya que el reinicio se activará y desactivará durante la programación. Otras líneas de datos también deben romperse o restablecerse para las otras MCU mantenidas bajas.

Supongo que es por eso que la mayoría de los diseños usan un encabezado de programación separado para cada MCU.

MOSI es la línea de datos DESDE el programador HASTA MCU. ¿no es así? ¿Por qué crees que es mejor que RESET?
si desconecta, reinicia, la otra MCU se ejecutará y puede estar usando el GPIO para algún propósito ...
¡Buen punto! No lo pensé. ¿Es correcto que la línea RESET esté baja todo el tiempo durante el proceso de programación?
parece que tienes razón, supongo que es por eso que la mayoría de los diseños usan un encabezado de programación para cada MCU.
Entonces parece que romper la línea SCK es suficiente. En mi caso particular, las líneas SPI se usan solo para programación.

Creo que para hacer esto, debe mantener el otro chip reiniciado para hacer que el IO sea Z alto (no controlado).
Por lo general, el CS (selección de chip) hace esto, pero no hay selección de chip disponible aquí. Ver reinicio como !CS (no selección de chip).

Actualización: este concepto no funcionará para piezas atmel. Mantener el reinicio bajo solo ingresa al modo de programación. Puede mantener el reinicio alto en la parte que no desea programar. Pero debe asegurarse de que el programa no use los pines SPI.

Sin embargo, yo no iría por este camino. Compararía los costos de un operador cambiando el cable, usando dos programadores o usando multiplexores.

Mantener el reinicio bajo mientras se realizan ciclos similares a los de un ISP en las líneas SPI puede resultar en la corrupción de la memoria flash del ATmega no objetivo.
@ChrisStratton - ¿Cómo es esto posible? Mantener el reinicio bajo debe ser una protección absoluta. ¿Estás hablando de algún error?
@EgorSkriptunoff no para ISP, no lo es. El reinicio es bajo casi todo el tiempo. Esto puede ser un problema cuando se utiliza un Arduino como adaptador ISP para programar un AVR de destino que ejecuta un periférico SPI. Piense que simplemente mantendrá el programador reiniciado para "quitarlo del camino" sin desconectarse mientras prueba el programa de destino, y puede reiniciar su programador Arduino reiniciado cuando malinterpreta el tráfico SPI como ISP operaciones.
@ChrisStratton: esto no debería suceder. Debe enviar una firma correcta (que funciona como una contraseña) para ingresar al modo de programación AVR. ¿Atmel confirmó este comportamiento?
@EgorSkriptunoff: en este caso, el tráfico no deseado son las operaciones de ISP, otro ATmega, presumiblemente el mismo modelo. Pero también lo he visto personalmente dos veces con tráfico SPI no correlacionado.
@ChrisStratton Tienes razón, actualizó la respuesta. Atmel se contradice en la hoja de datos sobre el estado del pin durante el reinicio.
Programación de varios AVR con un ISP: ¿qué línea romper?
RespuestasAquíPolítica de privacidad1y, 0v