Control del DAC MCP4725 de 12 bits con Verilog y la Alhambra II

[anil...@gmail.com]

Hace unas semanas comencé a trabajar en el proyecto de control I2C del conversor digital/analógico MCP4725, en Verilog y la placa Alhambra II...

Este chip ya lo había manejado en Arduino utilizando las librerías de Adafruit, pero al no haberlas para FPGA la idea fue adaptar el código que he hecho para el ADC7924, adaptando las rutinas y cambiando valores I2C... 

Lo primero fue encontrar el datasheet del chip DAC MCP4725 para estudiar las secuencias I2C

[anil...@gmail.com]

Así, pues, tras algunas pruebas ya tengo lista la primera versión operativa del módulo Verilog para el control I2C del MCP4725...

Este módulo permite distintas opciones de configuración, que para las pruebas controlo con un conjunto de interruptores DIL, con los bits 1,2 y 3 para definir el Modo de Funcionamiento, y los bits 4, 5 y 6 para establecer el valor analógico de salida.

Los códigos de esta configuración se resumen en la siguiente tabla:

El planteamiento del programa Verilog para las pruebas es el siguiente, con un módulo que contiene las rutinas I2C principales. A su izquierda el módulo auxiliar de configuración, y debajo del mismo el Debouncing+Pulse para activar la escritura mediante un pulsador...

El módulo auxiliar de configuración para pruebas envía al principal la dirección de escritura I2C (DIR), el dato a escribir (DAT), y el modo de funcionamiento (MODE). En un programa real todo esto vendría de distintos módulos...

Aquí, en las dos trazas superiores, una escritura en Modo Normal, cuyo ciclo dura 75 uS, con valor escrito 0 y analógico 0 Volts...

Y aquí, también una escritura en Modo Normal, con valor escrito 4095 y tensión 3,42 Volts... Observamos que los 4 bits USB están escritos en el 2º subframe, y los 8 LSB en el 3º...

Aquí una escritura de arranque para el Modo Rápido, en que escribe el DAC en 72 uS pero al final no cierra la comunicación del bus I2C (mantiene la línea SDA a 0), con lo cual, las siguientes reescrituras serán notablemente más cortas.

...Y al estar en Modo Rápido, las reescrituras no necesitan reconectar con la dirección I2C del DAC, con lo cual su ciclo se reduce a tan solo 49 uS... Este modo se mantendrá hasta recibir una orden de STOP...

La orden de STOP lo que hace es subir a 1 la línea de datos SDA y poco después la de reloj SCL, con lo cual se sale del Modo Fast y el bus I2C queda libre para cualquier otra comunicación. Esta orden dura 4 uS.

La orden o frame de escritura en la EEPROM es algo más largo que el Modo Normal, ya que contiene un subframe más, durando 98 uS. Los datos se escriben en este caso de forma distinta en los dos últimos subframes, en el Normal era 4+8 y en éste es 8+4...

Las EEPROM tienen un cierto número de reescrituras permitidas, normalmente de muchos miles pero variando según el chip, por este motivo la opción de regrabarlo se tiene que usar con precaución, solo cuando sea necesario guardar el valor...

Continuará...

Un saludo a todos.

[Democrito]

Buen trabajo Anilandro!

En mis comienzos con el protocolo I2C también practiqué con el MCP4725. Si te animas, puedes subir todos tus circuitos a GitHub para luego poner un enlace en este EXCEL: https://docs.google.com/spreadsheets/d/1AHKN015UBKr_EUMdBTnh8m93segdq5jyYwSP5YSIi40/edit#gid=0

Se trata de tener en algún lugar temporalmente los enlaces a los circuitos que vamos fabricando para no perder todos estos trabajos, hasta que finalmente consigamos centralizarlos. Si el GitHub fuese un problema, entonces podría valer poner un enlace a los post de este foro con tus trabajos.

Muchísimas gracias por compartir; saludos cordiales.

[charli va]

Hola Llorens! muchas gracias por los aportes.

Como dice Demócrito si lo añades al excel temporalmente sería fantástico, se avecina en los próximos meses una nueva versión de Icestudio con muchísimos cambios y entre ellos un repositorio centralizado de diseños que nos va a permitir compartir muy fácilmente los trabajos que hagamos, pero de momento al menos está genial ir teniéndolo todo al menos recopilado.

Un abrazo!

--
Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/c6eacd12-0e2c-4d7b-a688-1e989174bc73n%40googlegroups.com.

[Obijuan]

Buenísima aportación! Muchísimas gracias otra vez!

Pongo en la lista de deseos comprar ese ADC para probar tus módulos y frikear. Muchísimas gracias

Saludos, Obijuan

El jueves, 24 de febrero de 2022 a las 20:04:20 UTC+1, anil...@gmail.com escribió:

[anil...@gmail.com]

¿A qué Excel te refieres? ...lo siento pero no conozco la mecánica del grupo...

[anil...@gmail.com]

Un saludo a todos, el módulo DAC_MCP4725 es el siguiente:

[anil...@gmail.com]

...Y todo bien, pero a medias, porque al probarlo me he encontrado con un extraño efecto... resulta que si lo utilizo de esta forma, funciona bien...

Aquí he separado las entradas de configuración, en la dirección Dir I2C, el Dato a escribir y el modo (Mode) de funcionamiento. Ahora está en modo 0, es decir, es la escritura normal del valor... 

En esta configuración la señales SDA y SCL son las esperadas...

Vale... y ahora simplemente desconecto una de las salidas no imprescindibles, como la de indicación de ERROR, Err, que tenía conectada a un pin de salida de la placa para monitorizarlo...

...Y entonces, sin que venga a cuento las señales SDA simplemente desaparecen y claro está, el módulo deja de funcionar... 

El caso es que no hay ningún motivo para que ocurra esto... la Err es una salida, y por tanto no debería afectar al código para nada. El pin donde va conectado está aislado del resto de la circuitería, además que da lo mismo que lo conectes a otro pin cualquiera,  si está conectado el módulo funciona y si no lo está, no funciona...

Además tampoco tiene que ver con la variable interna de error del módulo, porque en una versión en que tenía otra salida con la monitorización interna de las señales SDA, si lo conectaba a un pin de la Alhambra, también podía dejar el Err desconectado y seguía funcionando...

Es algo sin sentido, que me sugiere tipo de "bug" del Icestudio... Debo decir que estoy utilizando la versión 0.6.0 porque al trabajar con W7 no me permite instalar versiones posteriores...

¿Alguno de vosotros tiene idea de qué puede estar pasando?

Saludos y gracias de antemano...

[Democrito]

A riesgo de equivocarme:

No creo que ese error sea de Icestudio, sino de las toolchain. Cuando se detecta que hay entradas o salidas que no se utiliza para optimizar anula esa parte del diseño.

Esto que comento es sólo una opinión totalmente irrelevante.

[charli va]

Con las entradas si que genera estabilidades la toolchain pero con las salidas al aire no lo había visto nunca.

¿Has probado a eliminar el bloque de salida desconectado? (me refiero al bloque azul de salida).

--

Has recibido este mensaje porque estás suscrito al grupo "FPGAwars: explorando el lado libre" de Grupos de Google.
Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a fpga-wars-explorando-el...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/a1e06b3e-f36b-4d4b-b278-569984517afcn%40googlegroups.com.

[Anilandro]

Sí, creo que lo he probado todo, si lo conectas a un pin de salida de la placa, funciona, si no, no funciona...

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/CAEQ-VCbrgyQ9v0rD5dVNi8YXNHcv%3DOLpa55WHM5WOrSH%2BfjGfg%40mail.gmail.com.

[Democrito]

Charliva, creo que con las salidas que no se utilizan también "optimiza", es decir, que puede anular ciertas partes del circuito. Pero lo que comento es sólo una impresión. Seguramente estoy equivocado, el tiempo dirá. También depende de si esas salidas se utiliza en otras partes del circuito, entonces no se "perderían" si es por ejemplo para comparar u otras historias. Pero salidas como tal, sin otros efectos, creo que anulan si van directas.

[Democrito]

Ejemplo:

Ahora bien, si la salida está relacionada con algo y tiene salida, también lo sintentiza como se esperaría:

La cuestión es entonces si la patilla "Error" del circuito de Llorens, saber si es un bit aislado sin conexión con el resto del circuito, entonces al estar aislado y no tener conexión con el resto del circuito (y puede ser un simple "assign" con una condición y nada más), el sintetizador anula esa parte del circuito si no hay conexión final a un pin físico.

No sé, por mi experiencia creo que me han pasado cosas de este tipo, incluso para saber de que hay algo que no he hecho bien y al ver los luts (LC) darme cuenta de que he cometido un error, pese a que lo sintetiza, pero claro, no puede ser que me de tan poco luts y cuando me sucede sé que los tiros van por ahí. Pero todo lo que comento son impresiones, desconozco la realidad de lo que sucede y podría ser por otros motivos.

[Jo mo]

Hello everyone,

@Democrito, yes, if there are no connection to the outside of the FPGA, i found-it very normal that a part of the circuit is just not synthetized !

 in your example just above i would even imagine that the resources use will be 0 LC without the only output connection present in you circuit.

Also for the Alhambra board it seams that when we build an almost "empty" design, the minimum IO use is 8 ouputs???

And for that same empty design, i will have 0 on a colorlight board build ! So maybe something is wrong with the apio alhambra definition! ?

@ Lorens, maybe share also the full design  (.ice) where you are getting the error!

I just remade a similar one but has i have no Alhambra board, i could only test building your circuit !

- 1103 luts with the output "error" connection

- 835 luts  without theoutput  "error" connection

So about 25 % of the circuit is suppressed after these ouput disconnection! quite a lot considering the little presence of ERR in your code block (only 3 little assigments) !

I tried converting-it to my ECP5 FPGA board but it as some ice40 specific primitives ( SB_IO # )

My advice/ idea:  when we have spcecific fpga primitives in our design, maybe we can add after the name _ICE40 or _ECP5 (eg in your case DAC_MCP4725_ICE40_v1.1  ).

Have a nice weekend guys

[Democrito]

Joaquim, I just tried, within the verilog code, to cancel everything related to the ERR register by putting "//", and the same thing happens if the ERR output is not connected, that is, it cancels that part of the circuit.

This symptom has happened to me many times and when it happens I know there is something I have not taken into account and I have to check the circuit.

To correct this problem, you have to separate the ERR register from the rest of the registers (do not include ERR inside an "if" for example if there are more registers involved. If a register is disconnected, it throws the other registers "on the ground", the cancel.

I can't be sure what I'm saying because I don't have much experience with verilog, but I do have experience with connecting specific circuits, but I think everything indicates that it happens.

And this problem is not with Icestudio, but with the tools that synthesize the circuits.

I don't think there is an easy solution for this kind of thing because tools are always going to want to simplify, so in this case the onus is on the designer (if he knows what's going on).

[Llorens_MRC]

A mí han llegado a sucederme cosas muy raras con el código de Verilog, como decirme que hay un error de una variable que no reconoce, pese a que todo está bien, borrar la línea entera y volver a escribirla exactamente igual, y desaparecer el error ...como si hubiera algún código oculto en el texto del listado que afectara a lo anterior...

Otra de las cosas que me hace en este caso concreto del módulo DAC, incluso teniendo conectado el pin Err y funcionando, es que uno los pines SDA y SCL a los respectivos libres I2C de la placa Alhambra (no naturalmente a los que dedica a la ADC instalada en la propia placa). Estos dos pines son los del extremo bajo, junto a las entradas analógicas... y cuando vuelvo a cargar el programa me ha cambiado la selección a los pines ADC_SDA y ADC_SCL... Pero resulta que es sólo el gráfico que cambia por sí solo, porque en realidad no cambia internamente, porque en este caso no funcionaría, especialmente por el distinto SDA... El SCL en cambio es el mismo para los dos buses I2C...

Raro, raro... Esta tarde seguiré trabajando un poco con el problema, intentaré sacar la primitiva que me controla la línea triestado de la señal SDA, del interior del módulo, a ver que pasa...

Saludos y gracias por los comentarios...

[Llorens_MRC]

...Ya he visto el Excel que comentabas, pero antes deberé abrirme una cuenta de github, que es algo que nunca he utilizado... Otra cosa, contesto aquí porque la forma como se representan los mensajes en los grupos de Google me resultan confusa... a veces no veo como contestar a algo o me aparece todo apilado... Por otra parte, el conocimiento que tengo de las FPGA y de Verilog es muy limitado, solo he ido aprendiendo un poco a base de prueba y error, y con los consejos del compañero José, o Jospicant... no recuerdo como se identifica en este grupo... Así que seguramente os preguntaré cosas que son básicas pero desconozco...

Un saludo y gracias...

El sábado, 26 de febrero de 2022 a las 5:03:33 UTC+1, Democrito escribió:

[Llorens_MRC]

Hello Joa. The entire design is precisely this module, the error does not occur when synthesizing, there is no erroneous indication. It is simply that the DAC does not respond because it does not receive the SDA signal from the I2C bus...

[Jo mo]

Hi Llorens ,

i understood your issue!

what i mean by entire design is the one containing also the fpga in/out port and the code blocks around your new dac block!

The ice file you posted contains only the dac block!

The 2-3 min time that people spare for reproducing the error, they can use it to try solving that issue ;-)

[Llorens_MRC]

Hello,  Joaquim  ...It is that there are no other code blocks around the DAC module. I have developed this module in solitary, so that it can later be connected to other modules. The DAC is a terminal module, an actuator that generates in a pin an analog electrical voltage determined according to the I2C order that is sent to it. The DAC itself has no digital outputs (except error indication) that would necessarily affect other modules...

[Llorens_MRC]

Ayer tarde estuve trabajando algunas horas con el problema del DAC, y como sospechaba, no tiene nada que ver con la salida de Err, si está conectada o no a un pin físico de la Alhambra. Esta causa-consecuencia es solo circunstancial y está provocada por algo raro en el proceso de síntesis... De hecho, si se elimina cualquier referencia a Err en el código, en control I2C sigue sin funcionar ...Mi sospecha iba dirigida hacia al código de la primitiva Inout que controla el triestado del pin utilizado como bus SDA, que es un código que no entiendo y en el módulo del ADC7924 funcionó bien, pero aquí, por lo que sea, no se sintetiza de forma adecuada e interrumpe la salida de la señal SDA...

SB_IO #(                             // Primitiva Inout para línea SDA
    .PIN_TYPE(6'b1010_01),
    .PULLUP(1'b0)
    ) triState (
    .PACKAGE_PIN(SDA_ADC),
    .OUTPUT_ENABLE(DSW),
    .D_OUT_0(SDA),
    .D_IN_0(SDAin)
    );

Ayer prescindí de este código y creé el sistema triestado externo a la Alhambra II, añadiendo un simple diodo de señal polarizado inversamente entre el pin de salida SDA y la resistencia pullup del bus I2C, y entonces sí, funcionó todo a la primera, con pin Err conectado y sin él... Esta tarde lo puliré un poco e incluiré un diagrama explicativo...

Un saludo a todos

Llorens

[Democrito]

Por si te sirve de algo: https://github.com/Obijuan/Cuadernos-tecnicos-FPGAs-libres/wiki/CT.3:-Pines-de-Entrada-Salida

[Llorens_MRC]

De todas formas, si alguno de vosotros pudiera explicarme de forma pormenorizada en funcionamiento a nivel electrónico de esta secuencia inout, se lo agradecería... 

SB_IO #(                             // Primitiva Inout para línea SDA
    .PIN_TYPE(6'b1010_01),
    .PULLUP(1'b0)
    ) triState (
    .PACKAGE_PIN(SDA_ADC),
    .OUTPUT_ENABLE(DSW),
    .D_OUT_0(SDA),
    .D_IN_0(SDAin)
    );

En concreto el significado de  " .PIN_TYPE(6'b1010_01)," ¿a qué pin físico de la FPGA está apuntando?, porque si es al utilizado para la ADC_SDA, sería normal que no funcionara bien, ya que no es éste en que se usa para controlar el bus I2C actual. En este caso lo realmente extraño y hasta erróneo, sería el que funcionara uniendo una salida informativa Err, que no tiene nada ve ver con este código, a un pin físico de la Alhambra que tampoco tiene nada que ver...

Saludos y gracias una vez más por la atención...

[Llorens_MRC]

Gracias por la información, Democrito, miraré el enlace...

[Democrito]

Cuando meto una caja de código verilog, si necesito añadir módulos que no sé manejar (y me pasaría con este proyecto) meto un módulo (en este caso sería un módulo de triesteado que sí sé manejar) conectado a la caja de código.

 

He puesto un gestor de triestado que está en la colección Jedi (es una colección muy completa y que uso al 99.9% en mis diseños).

Un resumen ultra rápido de funcionamiento:

* Olvida que el pin de salida IO es una salida, porque va a funcionar como entrada y salida. Va conectado a  la patilla pin del módulo triestado.

* oe es quien va a gestionar si los datos van a entrar o salir. No existe un triestado convencional, sino que o permites dejar entrar datos o permites sacarlos fuera, es como un conmutador ( lo más parecido a dejar la salida como flotante es ponerlo como entrada).

* Cuando oe esté a 0, lo que entre por pin se dirigirá hacia din. Cuando oe esté a 1, permitirá que lo que salga por dout salga por pin.

* pin va a funcionar como entrada o como salida, según gestiones oe. Si en algún proyecto necesitas que quede como flotante, entonces configuras como entrada.

[Democrito]

Rectifico el comienzo de mi post anterior, pero no afecta a lo que seguía; donde digo:

" Cuando meto una caja de código verilog, si necesito añadir módulos que no sé manejar (y me pasaría con este proyecto) meto un módulo (en este caso sería un módulo de triesteado que sí sé manejar) conectado a la caja de código."

Quise decir esto: Cuando no sé manejar algo dentro de la caja de código (en este caso el triestado y me sucedería porque no domino verilog), lo que hago es añadir un módulo a fuera que sí sé manejar y lo gestiono desde la caja de código. 

[Llorens_MRC]

Sí, los módulos inout de la colección Jedi los utilicé en las primeras versiones del controlador ADC de 12 bits, mientras estaba poniendo a punto el módulo de comunicación I2C, pero cuando tuve éste acabado, integré el código verilog del inout dentro del código general del controlador, para lo cual me ayudó el compañero Jospicant...

Sobre el tema del triestado más la necesaria conmutación para que el pin determinado sea de doble dirección, me interesa especialmente su funcionamiento en hardware, y es que soy de la rama electrónica... por ejemplo ¿todos los pines I/O de la Alhambra permiten la opción del triestado? ¿Se puede activar en todos ellos una resistencia pullup? ¿de qué valor es esta resistencia? ¿Cómo se puede acceder a los pines actuando directamente sobre los registros? etc, etc... A veces también encuentro a faltar una opción "solo código", con acceso completo al código de la cabecera del módulo, sin elementos gráficos que sin duda simplifican la programación pero también suelen añadir condicionantes y limitaciones... 

[Llorens_MRC]

Éste es el esquema de conexión sin utilizar pines con función triestado, con lo cual se puede crear un bus I2C en cualquier pin I/O de la Alhambra II...

El SDA_out combinado con el diodo de usos generales, actúa como una salida en colector abierto. Las resistencias pull-up no se ven porque están integradas en la plaquita DAC MCP4725, en este caso de 4,7K... La escritura se efectúa en durante los ciclos de reloj CLK adecuados poniendo a 0 la salida SDA_out o bien a 1, que al polarizar inversamente el diodo es el estado de alta impedancia... En este caso la resistencia pull-up "tira" a 1, a la tensión de alimentación de 3,42 volts... Para que la Alhambra lea por ejemplo el reconocimiento ACK del slave, basta poner SDA_out también a 1 durante el 9º impulso de SCL de cada subframe y dejar que el chip DAC module la tensión de la forma que precise, titando la tensión a 0 sei todo ha ido bien o dejándola a 1 si hay un "no reconocimiento" NACK, señal que leería la SDA_in...

En fin, ya sé que es un poco confuso, pero el sistema funciona y claro está sin ninguna relación con el Err, que esté conectado o desconectado de un pin de la Alhambra...

Saludos a todos

Llorens

[Democrito]

Te entiendo perfectamente, si todo se resuelve con verilog es más sencillo luego parametrizar los circuitos (cambiar número de bits, etc); crear módulos con otros módulos lleva más trabajo, sin embargo yo prefiero esta segunda opción, excepto en los algoritmos, de todas formas, según voy viendo, hago mezcla de ambos sistemas.

No recuerdo si es posible que desde nuestras FPGAs (ICE40) tener una salida polarizada con una resistencia, sé que con las entradas sí se puede, pero a nivel de código yo no te puedo aconsejar en este sentido.

Tengo entendido que todos los pines de la FPGA (ICE40) que puedan ser utilizados como entradas/salidas pueden tener la función de triestado (teniendo en cuenta que sólo queda flotante cuando se pone como entrada, no hay tres estados, sino dos).

Y si la FPGA conecta una resistencia no sé cual es su valor.

El truco que yo he utilizado en mis últimos diseños de I2C es este: (Ya sé que tú buscas el código, pero cuando consigas averiguar todo lo que necesitas puedes verlo como otra opción en tu diseño, si así fuese).

Imagina que la patilla IO tienes conectada una resistencia externa con valor de 5k (por ejemplo) para polarizar. En este diseño, para escribir en el I2C se hace a través de la patilla oe. Si oe=0 la salida IO vadrá 1 (ese 1 es gracias a la resistencia externa en pull up), y si la patilla oe=1 entonces la patilla IO valdrá 0. Para mantener la lógica de que oe sea igual que IO, se pone una puerta Not a la entrada oe. Y para leer del I2C, simplemente pones oe = 0 (y si tienes en cuenta la puerta Not será 1).

El protocolo I2C usa por defecto estados altos, es decir, que si no haces nada, SDA y SCL se mantienen a 1. Por esta razón para escribir un 1 el módulo triestado queda como entrada (flotante) pero la resistencia externa mantiene ese 1 en la línea, y cuando pones 0 se convierte en una salida y fuerzas a la línea a ponerse a 0.

De este modo no te hará falta el diodo externo.

Efectivamente, todo lo que comenté sobre patillas sueltas fue una "metida de gamba" por mi parte. He visto cosas muy raras mientras diseño y eso me emparanoia un poco (creer cosas que no son, o suponer más de la cuenta), y suceden esas cosas por desconocimiento (el mío en este caso).

[Obijuan]

Hi Joaquim,

El sábado, 26 de febrero de 2022 a las 11:11:58 UTC+1, joa...@gmail.com escribió:

Hello everyone,

@Democrito, yes, if there are no connection to the outside of the FPGA, i found-it very normal that a part of the circuit is just not synthetized !

 in your example just above i would even imagine that the resources use will be 0 LC without the only output connection present in you circuit.

Also for the Alhambra board it seams that when we build an almost "empty" design, the minimum IO use is 8 ouputs???

And for that same empty design, i will have 0 on a colorlight board build ! So maybe something is wrong with the apio alhambra definition! ?

This is because the  "board rules" are activated (Edit/preferences/Board Rules). If you disable it, the IO blocks will no longer be 8

You can check the board rules for the current board in the View/Board Rules menu

In the case of the Alhambra II boards, the board rules are used for connecting automatically the system clock (that comes from the pin 49 in the Alhambra II board) and turning off all the LEDs if not used (This is because the FPGA pins that are not used are in a high impedance state, and the LEDs connnected bright a little bit). Activating the board rules assigns a '0' to the unused leds so that they all are off when not used

Best regards, Obijuan

[Jo mo]

Ah ok Juan,

Thanks a lot for the info!

Have a good evening

[Llorens_MRC]

He estado probando de utilizar un módulo inout externo al módulo DAC, y de forma sorpresiva, hace lo mismo... Conectando ERR funciona y desconectándolo, no ...deja generar la señal SDA... En fin, ya no sé que más mirar...

 

[Llorens_MRC]

Así pues, como de momento no le veo arreglo a este problema que me crea el uso del módulo o el código de "inout", voy a prescindir de él y sigo con mi solución del simple diodo ...A partir de aquí he cambiado un par de líneas del código del módulo DAC, con la sorpresa que se ha simplificado con respecto al anterior, ya que no necesito todas las condiciones lógicas de manejo del impulso de control "oe", y la línea de detección de error NACK es también más simple...

Aquí las señales del frame I2C para escribir un "0" en el DAC...

1) La trama superior es la salida SDA_out, es decir, la señal del master al slave.

2) La trama central es señal en el bus I2C, tras el diodo

3) La trama inferior es la señal de reloj SCL del master

Aquí vemos como la SDA_out lo que hace cuando se pone a 1 es crear un estado de alta impedancia en el bus I2C, ya que el diodo queda polarizado inversamente y la resistencia "pullup" mantiene el nivel alto... Observar como además de los bits a 1 de la selección de dirección 11000010 hay otros bits algo más cortos coincidiendo con las 9ª señales SCL del reloj en cada subframe, que es el momento en que el master "escucha" la señal de reconocimiento ACK del slave... que si se mantiene a 0 es un OK, todo bien...

Veamos también que en el bus I2C (trama central) estos impulsos a 1 para la alta impedancia de la salida SDA_out no aparecen, al estar bloqueados por el diodo y porque el mismo chip slave está manteniendo en este momento el bit a 0, indicando al master que todo va bien...

Cuando tenga el módulo empaquetado os lo envío... que por cierto, el enlace en el Excel supongo que no tiene que ser forzosamente de github ¿o sí? ya que no tengo github pero puedo colgar mis módulos en Drive...

Saludos a todos

Llorens 

[Llorens_MRC]

Ya tengo listo el módulo de control I2C del DAC MCP4725, sin utilizar los módulos "inout" que me causan problemas.

...Recordar que este módulo, para la función triestado necesita un diodo de usos generales (p.ej 1N4148) entre la salida SDA_out y la entrada SDA_in, con el ánodo en ésta última... Esta conexión del SDA_in es la que va al bus de datos I2C de la placa DAC, que a su vez contiene la resistencia "pull-up" del bus...

Observar como en el diagrama anterior no se ha conectado la salida indicadora de error NACK, ya que ahora, y como debe ser, para el funcionamiento no importa si dicha salida está o no conectada...

Aquí las señales lógicas para escribir en la DAC el valor 4095, que corresponde a una tensión de salida de 3,42 Volts...

El módulo lo podéis descargar desde el archivo adjunto...

Saludos a todos...

Llorens

[Llorens_MRC]

...Perdon, y añado que se pueden utilizar cualquiera de los pines de la Alhambra II para crear el bus I2C, en este caso son el 5 para el bus de datos SDA (el pin 4 sólo va al cátodo del diodo), y el pin 3 para el bus de reloj SCL...