[Aporte] Generador de Señales (DDS)

[cosmefulanito04]

Bien ahí.

8mhz / 2^24 = 0.476837158203125 de resolucion.

8MHz es la frecuencia de clk, pero ¿es también la frecuencia de sampling?, es decir ¿cuántos clks se necesitan para tener una muestra a la salida?.

En base a ese fsampling, supongamos que realmente te lleva solo un clk como decís, te queda:

fsampling= 8MHz => Resolución usando acumulador 24 bits = fsampling/2^(24) = 0,47... Hz

Paso que se sumará al acumulador = Fsalida/Resolución usando acumulador 24 bits = 2,0971 (1/Hz) x Fsalida

Entonces para obtener 30kHz tus pasos deberían ser:

Paso (30kHz)= 2,0971 (1/Hz) x 30kHz= 62914,56= 0x00F5C2

Hasta acá lo mismo que obtuviste vos, siguiendo con la explicación que dí en el mensaje #32, ese paso lo divido en 3 bytes distintos:

1er byte (menor peso) = 0xC2= 194
2do byte (mediano peso)= 0xF5= 245
3er byte (mayor peso)= 0x00= 0

Esos son los 3 bytes que vas a tener que ir sumando teniendo en cuenta el carry del byte anterior.

Tu circuito debería hacer esto:

Paso byte 1 = 194
Paso byte 2 = 245
Paso byte 3 = 0

Acum byte 1=0
Acum byte 2=0
Acum byte 3=0 (índice que usarás para sacar la muestra en tu RAM)

. Muestra número 1:

Acum byte 1 + Paso byte 1 = 194 → Acum byte 1
Acum byte 2 + Paso byte 2 = 245→ Acum byte 2
Acum byte 3 + Paso byte 2 = 0 → Acum byte 3

Muestreo el elemento "0" (de nuevo, el índice lo impone Acum byte 3) que se encuentra en la memoria RAM.

. Muestra número 2:

Acum byte 1 + Paso byte 1 = 194 + 194 = 132 y hubo carry→ Acum byte 1
Acum byte 2 + Paso byte 2 = 245 + 245 + carry (1) = 235 y hubo carry→ Acum byte 2
Acum byte 3 + Paso byte 2 = 0 + 0 + carry (1) = 1 → Acum byte 3

Muestreo el elemento "1" que se encuentra en la memoria RAM.

. Muestra número 3:

Acum byte 1 + Paso byte 1 = 132 + 194 = 70 y hubo carry→ Acum byte 1
Acum byte 2 + Paso byte 2 = 235 + 245 + carry (1) = 225 y hubo carry→ Acum byte 2
Acum byte 3 + Paso byte 2 = 1 + 0 + carry (1) = 2 → Acum byte 3

Muestreo el elemento "2" que se encuentra en la memoria RAM.

Bue... así se repite y se vé que tiene tiempo de sobra para muestrear los 256 elementos, pero ojo, habrá veces en los cuales un elemento se repetirá, a medida que se irán sumando los acumuladores, Acum byte 2 + Paso byte 2 + carry (1) dará menor o igual a 255 evitando que haya un carry y por lo tanto Acum byte 3 mantendrá su valor.

Ese juego del carry, hace posible que se muestreen los 256 elementos, incluyendo veces en los cuales se repite un elemento, esa repetición será la que sirva de ajuste para que justo se den los 30kHz y no los 31,25 khz que decís.

 

[seaarg]

8MHz es la frecuencia de clk, pero ¿es también la frecuencia de sampling?, es decir ¿cuántos clks se necesitan para tener una muestra a la salida?.

Dependiendo del prescaler. Supongamos que es &H00FFFF: Ante cada clk voy a incrementar en 1 posicion el MSB, o sea la direccion de la RAM.

Con ese prescaler, tengo 8 MHz / 256 posiciones de ram. Asumiendo que en esas 256 posiciones tengo almacenado un ciclo de la senoidal completo, tengo una Fout de 31.25 khz

O sea, la respuesta es SI, la Fsample en este caso es = al oscilador que le ponga y que se aguanten los sumadores. Como comente antes, se bancan OK hasta 16 mhz (cada uno por separado es mas rapido pero la cascada los limita) Le toma a un grupo de 2 sumadores de 4 bits 60 ns aprox para hacer una suma de 2 numeros de 8 bits (segun datasheet). 60 x 3 = 180 ns pero en la practica se ve que pueden ir un poco mas rapido porque anduvieron OK a 16 mhz.

Paso que se sumará al acumulador = Fsalida/Resolución usando acumulador 24 bits = 2,0971 (1/Hz) x Fsalida

Esta parte no la comprendi. ¿ De donde sale el 2,0971 ?

Tu circuito debería hacer esto:

. Muestra número 2:

Acum byte 1 + Paso byte 1 = 194 + 194 = 132 y hubo carry→ Acum byte 1
Acum byte 2 + Paso byte 2 = 245 + 245 + carry (1) = 235 y hubo carry→ Acum byte 2
Acum byte 3 + Paso byte 2 = 0 + 0 + carry (1) = 1 → Acum byte 3

Muestreo el elemento "1" que se encuentra en la memoria RAM.

Estoy un 99% seguro de que hace precisamente eso, Te explico el esquematico:

Tengo un grupo de 3 serial shifters en los cuales programo el valor de paso para el prescaler (el numero 62914)

Estos 24 bits forman los 3 bytes que son la entrada de los sumadores. Fijate que cada grupo de 2 sumadores suma los 8 bits de paso (entradas B) + el resultado de la suma previa (entradas A, que esta almacenado en la salida del latch 74LS374)

Ante cada clock, los latches almacenan el resultado de la suma.

El carry se traspasa desde el pin 9 (carry out) hacia el pin 7 (carry in) de cada sumador, en toda la cascada de 24 bits.

Esto forma un acumulador, donde vemos que el ultimo latch LS374 (que tiene el MSB del resultado) esta conectado al puerto de direccion de la RAM. (ignora el 4094 que esta conectado alli, porque en este momento tiene las salidas en 3 state. Solo se usa para almacenar la forma de onda en la ram al inicializar o cambiar la misma)

Ahora bien, en el PIC hay una rutina para poner a cero el acumulador. Lo que hace es poner en 3state las salidas de los latches y el valor de paso a traves de los 4094. De esta forma, los sumadores hacen 0 + 0 (por el pack de resistores a masa). Esto se hace durante unos cuantos ciclos de reloj para asegurar la operacion.

Luego de resetear los sumadores a cero, se transfiere a traves de los 4094 el numero de paso. Esto es trasferido todo a la vez porque se actua sobre la linea de STROBE, que hace que, una vez que he transferido serialmente todos los bits, al actuar strobe, pasan todos juntos a los latch de salida internos del 4094.

A partir de ahi, se baja la linea OE de los latches LS374, empezando el ciclo de acumulacion, activando la salida de la RAM y desactivando los 2 ultimos 4094 de "programacion" (los 3 primeros fijate que su OE esta siempre activa, mantienen fijo el numero de paso)

En fin, la cuestion principal era si estaba pasando el carry de cada suma al siguiente grupo de sumadores y si, lo estoy haciendo asi que por ahi no viene la cosa

Voy a seguir haciendo pruebas. Me confunde que en tu caso, multiplicas 2^24 x 9 clocks y gracias a eso, obtenes un numero mucho mas chico en la resolucion. Matematicamente tiene sentido pero me confunde el hecho de que en mi caso, al usar solo 1 clock por sample, deberia tener mas resolucion (o mas velocidad y quiza son mutuamente excluyentes)

De todos modos, estoy muy contento con el resultado obtenido!! Yo creo que solamente faltan ajustes de soft. Quiza estoy "programando" una frecuencia, obtengo esa frecuencia a traves de la matematica de punto flotante en el display del PIC, pero en la realidad estoy transfiriendo otro numero como paso de prescaler sin saberlo (haria falta un analizador logico!!!)

Voy a depurar por ese lado a ver que ocurre.

Saludos y gracias! Cualquier tip o info sera muy bienvenida!

Agrego:

Es absurdo que, con semejante hardware, tenga un limite de 31.25 khz por lo tanto, tengo 2 caminos:

opcion 1: Permito que el paso de prescaler sea superior a &H00FFFF, haciendo que el MSB "saltee" muestras de las 256 (como es tu caso)

opcion 2: Limito el paso de prescaler a &H00FFFF pero hago un algoritmo para que, cuando el valor sea inferior, transfiera UN solo ciclo senoidal sintetizado a las 256 muestras en RAM (maxima precision), cuando es superior, almaceno 2 ciclos (128x2) en las 256 muestras y recalculo el valor de prescaler... y asi sucesivamente.

Esto ultimo lo empece a implementar, tengo en el programa 3 vectores de senoidal: 1 ciclo en 256 muestras, 2 ciclos, 4 ciclos. Transfiero a RAM el que necesite segun frecuencia de salida deseada.

¿Alguna recomendacion acerca de que opcion elegir?

Gracias!

 

[cosmefulanito04]

Me puse analizar el hard y es como decís, estás haciendo exactamente la misma operación, pero en hard. La verdad alto laburo te mandaste .

Esta parte no la comprendi. ¿ De donde sale el 2,0971 ?

Es exactamente lo mismo que hacés vos 1/0,476837158203125 = 2,0971

Me parece que el problema pasa por el soft (poner mal los pasos) y el no saber bien cual es tu fsampling. La fsampling es constante siempre, no importa en que frecuencia te muevas (salvo que le quites resolución al acumulador, complicado en tu caso).

La fsampling será la frecuencia máxima en la que tardás en cambiar una muestra en otra a la máxima velocidad posible, en mi caso, esa fsampling estaba dada por la frecuencia del clock (cristal) dividido por la cantidad de instrucciones que me tomaba cambiar el valor de la muestra (9 clk, de ahí el 9).

Como yo estoy oxidado con electrónica lógica por hard ( ), tal vez lo que ocurra es que en realidad no te tome 1clk, sino dos o más en cambiar esa muestra. Vos tenés los 8MHz como clk al sumador y al latch, la pregunta es: ¿cuántos clocks necesita el sumador para obtener el resultado? ¿el latch para retener el dato a la salida? ¿la memoria en leer el dato? Todo eso, más que nada la RAM, te tiene que sacar algún clk. Verificá eso y después discutimos el resto.

 

[seaarg]

Ahora comprendo de donde sale ese 2,0971 gracias! de hecho yo hago division de punto flotante (Fout / 0.47...) cuando vos haces en tu cuenta multiplicacion (Fout x 2,09...) No se si habra diferencia en el micro entre hacer division y multiplicacion cuando son de punto flotante, pero es un buen punto para probar cambiarlo. Quiza la precision se este perdiendo ahi.

La Fsampling es de 8mhz siempre. Por cada clock tenes a la salida de los latches el resultado de la suma de cada uno de los 3 bytes, donde el MSB determina la direccion de RAM.

Numeros:

8mhz = 125ns de periodo

Del datasheet del LS283:

Typical add times
Two 8-bit words 25 ns
Two 16-bit words 45 ns

Lo presentan como suma de 8 bits cuando son de 4 bits, supongo que ya asumen la cascada de 2 integrados, o de 4 en el segundo caso.

Entonces, yo tengo 24 bits, en el peor de los casos: 25 + 25 + 25ns = 75ns

El 74LS374 tiene un tiempo de propagacion en el peor de los casos de 25ns + 75ns = 100 ns

A partir de que el dato esta en el latch, no me tendria que importar el tiempo de la RAM, pero vamos a sumarlo. Esta SRAM tiene un tiempo de "address to data valid" maximo de 25ns

100ns + 25ns = 125ns Lo que es justito el tiempo del periodo de 8mhz. Repito, creo que es seguro asumir 100ns debido a que una vez que la direccion esta en el latch que controla la direccion, hasta que no haya un nuevo clk este no cambia y le da tiempo a actualizar la salida.

Analizados los tiempos, quisiera aclararte que los sumadores son "instantaneos" es decir, no tienen señal de clock. El clock se aplica si a los latches que son los que determinan el resultado de la suma previa (a ser sumado con el paso) y que ingresa a los sumadores como operador A.

Voy a apuntar a que el culpable es el numero de paso que le impongo al prescaler. Modificare el programa para que me muestre en display que es lo que verdaderamente le estoy diciendo al hardware como primer paso de depuracion.

Tambien he notado algo: a cada integrado, en su linea de VCC le pongo un filtrito pasabajos hecho con una R de bajo valor en serie y capacitor a masa. (no tenia inductores a mano). Sin embargo, en los integrados TTL estoy notando que, previo a la resistencia tengo 5V y en el pin en si tengo 4.6V. Las resistencias son de muy bajo valor ya asi que no tiene mucho sentido bajarlas mas, cambiare por inductor. Con los CMOS esto funciona de lujo porque consumen casi nada, y en ellos si tengo los 5V. Ninguno de los integrados tiene ruido en su linea VCC segun el osciloscopio.

Del hardware, si hubiera algun culpable, tambien podria apuntar a los pack de resistencias pull-down que tengo a la salida de los latches, y que los uso para poner a cero el prescaler. Actualmente son de 18K no sea cosa que esten siendo insuficientes para bajar la linea (no creo, porque es alta impedancia: la entrada de los sumadores y la salida OE deshabilitada del latch).

 

[seaarg]

Encontre la "formula" para que ande perfecto, pero me ha dejado muy desconcertado no saber la causa de esto.

En este "parche" utilizo como variable "resolucion" el doble del calculado. Es decir, si habia calculado 8mhz / 2^24 = 0.476837158203125 entonces uso 0.95367431640625

Luego, calculo el valor de paso asi:

paso = fout / resolucion;

El resultado de esa division es un valor entero.

Extraigo los 3 bytes de ese prescaler, almacenandolos en p2, p1 y p0

Y ahora, va el truco:

if (paso > 32767) {
	p2 = p2 + 1;
	t = intval((paso - 32768) / 65535);
	p2 = p2 + t;
	if(p1 > 127) {
		p1 = p1 - 128;
	}
}

Es decir: Se deja el LSB como esta (p0) y si el valor de paso es > 32k incremento en 1 el MSB... luego...
... al paso le resto 32k y eso lo divido por 64k. La parte entera del resultado de la division se la sumo al MSB

y por ultimo, si el byte del medio (p1) es > 127, le resto 128.

Envio p0, p1, p2 al sumador como valor de paso.

Con este ajuste horrible, obtengo exactitud en toda la gama de frecuencias que probe desde 100hz a 2mhz

Llegue a estos valores experimentalmente, analizando los valores que matematicamente deberia aplicar contra lo obtenido y entonces fue que note que luego de los 32k de valor de paso, el generador no me subia la frecuencia de salida hasta que el valor de paso fuera bastante mayor para llegar a afectar el MSB.

Luego observe, a medida que incrementaba fout, que cada cierto valor limite "binario" (64K = 65535) necesitaba incrementar en 1 el MSB del paso para que la salida correspondiera a lo deseado.

Lo "solucione" a mi problema digamos y anda perfecto, pero ahora estoy totalmente confundido porque este arreglo no tiene sentido y algo me dice que este arreglo solo esta "parchando" un problema electrico o logico en algun bit. No tengo idea como cazar el error real para solucionarlo sin parches.

Ejemplo:

Para generar 120khz necesito, segun la cuenta Fout / resolucion:

valor paso = 125829
p2 = 1
p1 = 235
p0 = 133

Esto genera 62.56 khz

Aplicado el parche queda:

Como el valor paso es > 32767 sumo 1 a p2
Luego:
valor paso - 32768 = 93061
93061 / 65535 = 1.41

p2 = 3 [1 + 1 + entero(1.41)]
p1 = 107 (235 - 128)
p0 = 133

Lo que genera aprox 120.09 khz lo que es bastante acertado (aceptando errores y derivas)

Esto sucede en toda la gama que probe, y se corrige en dicha gama

No entiendo mas nada!!

 

[cosmefulanito04]

Bueno si conseguiste obtener la frecuencia medianamente bien, no hay muchas vuelta que darle.

Sin embargo no entiendo porque tanto despelote, tiene que salir de una, tampoco entiendo porque 32kHz es una frecuencia frontera.

Numeros:

8mhz = 125ns de periodo

Del datasheet del LS283:

Typical add times
Two 8-bit words 25 ns
Two 16-bit words 45 ns

Lo presentan como suma de 8 bits cuando son de 4 bits, supongo que ya asumen la cascada de 2 integrados, o de 4 en el segundo caso.

Entonces, yo tengo 24 bits, en el peor de los casos: 25 + 25 + 25ns = 75ns

El 74LS374 tiene un tiempo de propagacion en el peor de los casos de 25ns + 75ns = 100 ns

A partir de que el dato esta en el latch, no me tendria que importar el tiempo de la RAM, pero vamos a sumarlo. Esta SRAM tiene un tiempo de "address to data valid" maximo de 25ns

100ns + 25ns = 125ns Lo que es justito el tiempo del periodo de 8mhz. Repito, creo que es seguro asumir 100ns debido a que una vez que la direccion esta en el latch que controla la direccion, hasta que no haya un nuevo clk este no cambia y le da tiempo a actualizar la salida.

Ok, la hoja de datos avala que al menos en 8MHz se mueve, entonces tal vez lo haga más rápido, es necesario que midas ese retardo bien y la única forma que se me ocurre es que hagas que el paso sea 0x00FFFF y que el contenido de la RAM te permita leer cambios de estado, es decir la idea podría ser que el contendio en los índices pares sea 1 y en los índices impares 0, de esa forma te colgás con el OCR en el bit de menor peso de la salida de la RAM y medís a que frecuencia se dá ese cambio, con eso obtenés la fsampling.

 

[seaarg]

Bueno, atento a tu sugerencia, al programa le agregue la forma de onda cuadrada compuesta de 255,0,255,0...

A la salida, con prescaler 0x00FFFF tengo exactamente 4mhz lo que implica 8mhz de sampling. Obviamente la forma de onda es redondeada por el filtro y por la entrada de mi osciloscopio casero.

En la salida digital de la ram tengo lo mismo pero mas cuadrada y de maxima amplitud.

Mas info: El efecto "parche" lo hace tambien en proteus! Esto implica que no tengo un problema electronico en la placa sino que: O es necesario el parche, o hay un error de logica en el diseño.

Me inclino por el ultimo, porque el parche "no tiene sentido". aunque no se que podra ser.

Probe tambien (en proteus) conectar el carry out del MSB al carry in del LSB por si fuera ese el problema con identicos resultados (variacion despreciable)

 

[cosmefulanito04]

¿A la salida de la RAM (no la salida después del filtro) obtenés una rectangular con duty 50% perfecta de 4MHz? si así tu fsampling es 8MHz como decís.

O sea, que las muestras en la RAM son: 0x00, 0xFF, 0x00,.... etc

 

[seaarg]

Exactamente. Es lo mismo antes o despues del filtro ya que el valor es 0xFF, 0x00.... Obviamente despues del filtro es mas redonda nomas.

 

[cosmefulanito04]

Y si cargas al paso 0x00F5C2, ¿qué frecuencia tenés a la salida de la RAM?, siempre usando 0x00, 0xFF.... como muestras.

Si no me equivoco, debería darte 30kHz/256 y tal vez un poco menos por los carry.

Editado:

No, estoy tirando cualquiera, debería darte 30kHz/2, o sea clavado 15kHz.

 

[seaarg]

mmmm esto es raro, poniendo ese paso que me sugeris: 0,245,194 en la cuadrada tengo igual 4 mhz

No me suena a que me de una frecuencia tan baja como decis debido a que es un valor de paso bastante alto, de hecho, es cercano a 0x00FFFF

¿Cual es la ecuacion que hiciste para obtener 30khz / 256 a partir de ese valor de paso?

Mismo valor, en senoidal que usa las 256 muestras para 1 ciclo da 31.36 khz (hay redondeos implicados en el calculo que hace el soft del osci)

Meti el valor 31360 en mi soft externo que calcula los valores de paso que deberia poner (para senoidal, querya contrastar tu valor sugerido) y, sin parche, me da: 0,128,115

con parche: 1,0,115

No se si tendras posibilidad de hacer esto pero, ¿vos tenes forma de imponerle a tu generador un paso de 0x007FFE (32766) y luego uno de 0x0087FE (34814) y ver si te genera una frecuencia apropiada para esos pasos, a tu resolucion? El motivo de estos numeros es que el primero es menor a 32k (32768 seria) y el segundo mayor. Si tuvieses el mismo problema que yo, practicamente no aumentaria la frecuencia de salida entre esos dos valores de paso, mas alla de algun redondeo del instrumento de medicion.

 

[cosmefulanito04]

No, es cierto lo que decís, lo que estás haciendo ahí es darle un paso un poco más lento para que hayan más de 256 muestras y la frecuencia se mantiene en 4MHz que es la mitad de la fsampling que mencioné que siempre se mantiene.

Para ver esos 15kHz, las muestras deberían ser 128 con 0xFF y 128 con 0x00 o viceversa, pensá que así como está, estamos repitiendo las muestras 128 veces, que eso servía para sacar la fsampling.

 

[cosmefulanito04]

No se si tendras posibilidad de hacer esto pero, ¿vos tenes forma de imponerle a tu generador un paso de 0x007FFE (32766) y luego uno de 0x0087FE (34814) y ver si te genera una frecuencia apropiada para esos pasos, a tu resolucion? El motivo de estos numeros es que el primero es menor a 32k (32768 seria) y el segundo mayor. Si tuvieses el mismo problema que yo, practicamente no aumentaria la frecuencia de salida entre esos dos valores de paso, mas alla de algun redondeo del instrumento de medicion.

Es un quilombo, porque tengo que reprogramarlo. Pero te hago la inversa, sabiendo el paso, averiguo la frecuencia que debería darme para corroborar que no hay problemas con esos pasos.

En mí código el paso lo calculaba así:

step=(u32)((frecuencia_salida*9.437184));

Donde 9,437184 sale siempre de lo mismo => Step= 2^(24)* 9 * Frecuencia_Hz / 16MHz = 9,437184*Frecuencia_Hz

2^(24): es el acumulador.
9: la cantidad de clks que me toman.
16MHz: el cristal.

Entonces en base a tus pasos:

• 0x007FFE (32766) => Frecuencia_Hz= Paso/9,437184= 32766/9,437184= 3472Hz
  
  
• 0x0087FE (34814) => Frecuencia_Hz= Paso/9,437184= 34814/9,437184= 3689Hz
  
  

No se vé bien, pero el tester indica unidad de kHz.

En tu caso, la cuenta que deberías hacer en el PIC es la siguiente:

step=(u32)((frecuencia_salida*2.097152));

Y después obviamente el resultado lo separás en 3 bytes. No sé porque no te dá bien, ya que el hard hace exactamente lo mismo que el soft.

 

[seaarg]

Gracias por las fotos!

step=(u32)((frecuencia_salida*2.097152));

Haciendo esto, y removiendo el "parche" sigue fallando. Con parche sigue andando bien ya sea esta multiplicacion o la division /0.47x2 que yo hacia.

Sin embargo, a pesar de que haciendo tu cuenta en la realidad falla igual, en proteus anda perfecto SIN parche. Antes a menos que pusiera el parche tambien fallaba en proteus... o sea que entre hacer F / 0.47 o sino F / 0.92 y hacer F x 2.09... hay diferencia real.

Esto significa que ahora tengo una punta para empezar a pensar que hay algo mal, ya no en el diseño y/o conexionado logico sino en el armado del hardware fisico, y el olfato me dice que por ahi sea algun nivel que no esta correcto en los carry o en la transferencia serial.

Me voy a volver loco para depurar 24 bits en hardware moviendose a todo trapo!!!



Deseenme suerte

 

[cosmefulanito04]

A favor de los carry es que te dieron la fsampling teórica cuando usaste 0x00FFFF como paso.

Podrías probar usando un acumulador de 16 u 8 bits para ir descartando (sacás sumadores, obviamente sin tocar el hard):

- 16 bits:

step=(u16)((frecuencia_salida*0.008192));

El paso lo mandás así: 0x Byte1 - Byte2 - 00

- 8 bits:

step=(u8)((frecuencia_salida*0.000032));

El paso lo mandás así: 0x Byte1 - 00 - 00

Obviamente perdés resolución, con 16 bits 122Hz y con 8 bits 31,25 kHz.

 

[seaarg]

Solucionado!! funciona perfectisimo ahora sin parches.

Al final no fue tan dificil depurar los 24 bits. Primero estableci un valor de paso determinado por tu formula (hay diferencia entre tu multiplicacion y mi division. Gana tu multiplicacion)

Entonces, con el osciloscopio me puse a ver el valor de cada bit de los shifters.... OK

Entonces, verifique los carryout y carryin de cada sumador. En todos tenia una frecuencia, excepto en el sumador nro 4, que tenia un carryin, pero carryout siempre era 5v

Luego, tenia que ver los 24 bits cambiantes. Con el osci, pin por pin... todos tenian una frecuencia excepto la entrada A3 del sumador nro 4 (bit 16) del acumulador, donde tenia un valor constante de 1.5v. Esto me suena!!! bit 16?? muy relacionado a 65535 Resulta que los TTL con entrada abierta, quedan con 1.5v en dicha entrada y lo toma indeterminado (obvio) con tendencia a 1 logico.

Entonces, revise el latch LS374 en su salida Q7 que va a ese pin del sumador > tenia una frecuencia.

Agarre el tester, medir continuidad. Tenia 15 megaohms entre el pin del latch y la entrada del sumador. UNA maldita mala soldadura entre el pin del latch y su pista!!!

Repase la soldadura... presto!!! anda perfecto Ahora pensando en retrospectiva, el parche era muy "logico" por ser el bit 16, pero no revisaba las pistas porque en proteus tambien fallaba (y ahi no hay soldaduras!!! ). Resulta que sumado a la mala soldadura estaba que la cuenta haciendo division provocaba exactamente el mismo error en proteus! Increible, ni queriendo tendria tanta suerte jaja.

Ahora si, puedo continuar mejorando el programa, la interfaz, etc, como para contribuirlo al foro cuando este listo 100%.

Muchas gracias cosme por tu colaboracion y tus ganas de ayudarme a depurar esto.

 

[cosmefulanito04]

Bien ahí. Eso toma vuelo, ya 8 MHz de sampling es super respetable.

Después si te interesa te puedo pasar el protocolo (es bastante sonzo) del puerto serie para poder establecer comunicación con el programita que hice en Java.

 

[seaarg]

Ni hablar, ahora que se que genera bien con 8mhz puedo ponerme ambicioso y volver a poner el oscilador de 16 mhz

Sobre tu ofrecimiento, podria verlo para chusmear que cosas podria hacerle desde la PC. En este caso es usb y el programa lo voy a hacer en .NET

Desde la PC pocas cosas se podrian hacer ya que no es necesario excepto para transferir formas de onda personalizadas.

La funcion sweep va a ser bien complicada, porque implica trasferencia del paso a traves de los serial shifters, pero creo que es posible gracias al STROBE.

Todo este hardware permite que el generador sea standalone, no necesita la PC mas que para transferir ondas personalizadas

Quisiera hacer unas consultas para ver sus sugerencias:

- Para la salida TTL, la conecte derecho al generador de PWM del pic. Me conviene usar esto o hacer una rutina para generarla poniendo alto-bajo?

- La electronica analogica es donde mas hago agua. Me gustaria si alguien tiene tiempo de mirar en el esquematico la parte de los operacionales, para ver si hay alguna mejora para hacerle al filtro de salida (el pote es para el offset, la amplitud la voy a controlar digitalmente alterando la señal en ram)

Pido esto, porque el filtro actual anda bien pero a frecuencias bajas esta un poco imperfecto y a frecuencias muy altas reduce amplitud (o es mi osciloscopio el que reduce, ya voy a pedir prestado uno profesional)

Lo ideal seria cambiar la frecuencia de corte del filtro en forma escalonada pero eso implica poner otro integrado y distorsion. No se si hay una forma mejor de hacerlo (o una llave mecanica podria ser!)

 

[cosmefulanito04]

Sobre tu ofrecimiento, podria verlo para chusmear que cosas podria hacerle desde la PC. En este caso es usb y el programa lo voy a hacer en .NET

Sos del lado oscuro... corporativo de .NET

Fijate en los videos que subí que ahí se vé lo que hace el programa, pero si manejás .NET lo ideal es que te hagas algo a medida.

Desde la PC pocas cosas se podrian hacer ya que no es necesario excepto para transferir formas de onda personalizadas.

La funcion sweep va a ser bien complicada, porque implica trasferencia del paso a traves de los serial shifters, pero creo que es posible gracias al STROBE.

Todo este hardware permite que el generador sea standalone, no necesita la PC mas que para transferir ondas personalizadas

Claro, pero la magia que te puede dar la PC además de las formas de ondas, es el barrido tanto en frecuencia como en duty.

Ni hablar, ahora que se que genera bien con 8mhz puedo ponerme ambicioso y volver a poner el oscilador de 16 mhz

Duda, ¿en qué te cambia un oscilador de 16MHz si los tiempos de propagación son fijos? ¿no deberías buscar integrados más rápidos?

Quisiera hacer unas consultas para ver sus sugerencias:

- Para la salida TTL, la conecte derecho al generador de PWM del pic. Me conviene usar esto o hacer una rutina para generarla poniendo alto-bajo?

Yo lo hice por rutina porque el PWM del hard no superaba los 30 y pico kHz, en cambio con assembler llegaba mucho más.

- La electronica analogica es donde mas hago agua. Me gustaria si alguien tiene tiempo de mirar en el esquematico la parte de los operacionales, para ver si hay alguna mejora para hacerle al filtro de salida (el pote es para el offset, la amplitud la voy a controlar digitalmente alterando la señal en ram)

Pido esto, porque el filtro actual anda bien pero a frecuencias bajas esta un poco imperfecto y a frecuencias muy altas reduce amplitud (o es mi osciloscopio el que reduce, ya voy a pedir prestado uno profesional)

Lo ideal seria cambiar la frecuencia de corte del filtro en forma escalonada pero eso implica poner otro integrado y distorsion. No se si hay una forma mejor de hacerlo (o una llave mecanica podria ser!)

Después lo veo, la frecuencia inferior la podés controlar, la superior dependerá mucho de los operacionales que usastes y la fcs que impusiste.

Lo único que vi de tu hard, es que el teclado no tiene los diodos schottky que evitan que haya un corto entre los puertos en caso de pulsar dos botones a la vez.

 

[seaarg]

Sos del lado oscuro... corporativo de .NET

Jaja no way, en realidad trabajo en PHP, o en C++ pero para aplicaciones desktop siempre le di a .NET porque Java no me puse a aprender

Claro, pero la magia que te puede dar la PC además de las formas de ondas, es el barrido tanto en frecuencia como en duty.

Para el barrido en frecuencia, tenia pensado que el micro cambie el prescaler cada un tiempo determinado. ¿Como seria eso del barrido en duty para una onda senoidal?

Duda, ¿en qué te cambia un oscilador de 16MHz si los tiempos de propagación son fijos? ¿no deberías buscar integrados más rápidos?

En que la fsampling seria en vez de 8mhz, de 16mhz. A cada ciclo de reloj tengo un sample en ram, que puede ser distinto al anterior o igual, depende el prescaler. Los tiempos de propagacion de los integrados solo limitan hasta que fsampling puedo llegar, y 16 mhz *creo* que llegan (ahora que anda bien puedo probarlo). Digo *creo* porque los tiempos que calculamos mas arriba son los tipicos, pero no significa que sean necesariamente los limites. A 12mhz estoy bastante seguro que llega bien solo que no tengo un oscilador de 12mhz (antes removi el oscilador y puse un cristal en el inversor que uso para distribuir el reloj)

Yo lo hice por rutina porque el PWM del hard no superaba los 30 y pico kHz, en cambio con assembler llegaba mucho más.

http://calculator-sundar.hpage.co.in/pic-pwm_88966258.html

En esta pagina, pone como frecuencia 48mhz, deja el pwm freq en blanco y pone el duty en 50%. Te va tirar la lista de todos los pwm posibles con ese micro. A medida que te vas mas arriba tenes menos "suavidad" entre saltos.

Después lo veo, la frecuencia inferior la podés controlar, la superior dependerá mucho de los operacionales que usastes y la fcs que impusiste.

Los operacionales son LM318 configurados de forma tal que den el maximo slew rate (son de 50v/us y con esta configuracion trepan a 150v/us) El ancho de banda en señal pequeña es de 15mhz. No estoy seguro que puedan ir a tanto pero creo que deberian poder tirar una señal de 5vpp a 4-5mhz sin problemas. (No hice cuentas aun)

Lo único que vi de tu hard, es que el teclado no tiene los diodos schottky que evitan que haya un corto entre los puertos en caso de pulsar dos botones a la vez.

AUCH! que buena observacion no me habia dado cuenta. Puedo solucionarlo poniendo en alta impedancia los pines de las columnas que no estoy sensando (en el esquematico no esta, pero cada fila tiene una resistencia pull-down)

De todos modos, aun no se si dejar puesto este teclado o no, hace que sea muy comodo ir por los menu y particularmente ingresar la frecuencia, pero es voluminoso. Estaba pensando en reemplazarlo por 3 botones nomas (arriba, abajo, menu/enter)