JavaScript está desactivado. Para una mejor experiencia, por favor, activa JavaScript en el navegador antes de continuar.

Responder al tema

Mensaje: [QUOTE="seaarg, post: 1017384, member: 11680"] Los 4 ciclos por instruccion descartan el manejo directo porque una transferencia desde un puerto a la ram implica al menos 2 o 3 instrucciones (hablo desde mi conocimiento de pic) Lo de las muestras pre-trigger es algo fundamental para mi: "Quiero ver que pasaba en la señal antes de un transitorio". Como mi contador de desborde (para saber cuando llene la memoria desde el evento de trigger) esta implementado en su mayoria con el contador TMR1 externo del pic, puedo configurar desde soft cuantas muestras pre-trigger necesito asi que estamos en la misma idea. En mi experiencia, no hace falta TANTA memoria, a menos que quieras medir señales muy lentas. Yo diseñe con double buffering por lo siguiente: - Implica poder usar memorias mas lentas (12ns de tiempo de grabacion, las que dispongo, para una tasa de captura de 80msps). Si usase 1 sola memoria, esta tendria que grabar el dato con un pulso de escritura de 6.25ns. Hay un truco, si se requiere, con un capacitor, resistencia y una compuerta AND creo, que permite que de los 12.5ns de periodo, tener en estado bajo la señal por la mayoria de ese tiempo, permitiendo usar una memoria mas lenta pero de todos modos aun con este truco no llego al tiempo requerido. Por eso el double buffering. - Desventaja: Las memorias consumen mucho. Para 2 canales implica 4 memorias, lo que representa cerca de 360ma solo para las memorias. Con las FIFO que me indicaste, acepto su limitacion de 50mhz pero al sacar 2 memorias y 2 PLD para la direccion, no solo simplifico ENORMEMENTE el pcb sino que tambien reduzco el consumo por al menos 90+90+100+100 = 380ma En mi experiencia, la FIFO de 1k que use en mi proyecto anterior iba, en teoria, a algo de 25-30mhz, y la hice funcionar sin ningun problema a 40mhz. Si estas se pueden exprimir de esa manera, quiza podria llevarlas a 60mhz. Teniendo en cuenta que mis ADC son de 80mhz creo que esta bastante bien. La transferencia a la PC en mi caso va por USB full speed, 12m Transferir 1 Kbytes (1 pantalla) toma algunos milisegundos. En mi diseño, se transfiere lo necesario. Es decir, si estoy tomando 1 muestra cada 2, no transfiero 2 muestras sino 1. Esto acelera muchisimo todo. Cuando quiera hacer zoom a la señal (cambiando hDIV) se hace una transferencia nueva. Te comento: Usando memorias de 32KB en mis primeras pruebas, la transferencia completa de esta cantidad por usb a todo trapo se hacia apreciablemente lenta e insoportable (un segundo mas o menos x frame) NO te recomiendo que manejes esa cantidad de datos y menos por puerto serial comun. Pensa en si, obtener muchas muestras, pero transferir solo lo necesario. Para la parte analogica, recorde que habia posteado un PDF con mi esquematico. Acerca de tus dudas de los 4052 estoy de acuerdo, es posible. Sin embargo este osciloscopio [url]http://fabiobaltieri.com/2013/07/10/inside-a-hantek-dso-2090-usb-oscilloscope/[/url] los usa y anda mas que bien! PD: Casi casi le compro al mismo chino :) pero no me gusto el tipo de shipping por lo que elegi otro con un shipping mas normal, que algunos comentarios lo denuncian por componentes usados. Arriesgue y elegi ese, ojala que lleguen y sirvan! Estuve viendo un poco de info acerca de el micro que estas usando. Viejo decis? que le queda a mi pobre pic entonces! Veo que tiene generadores de señal compatibles con video. Pensaste en conectar un monitor directamente al micro y no usar computador? Si almacenar la señal para verla despues es una razon, bien podes usar una microSD :) Si yo conociese de esos micros y tuviese alguno, intentaria exprimirlo. Se le ve muchisimo potencial. Si por casualidad tenes acceso a alguna FPGA, considera implementar casi todo el osciloscopio en una de esas. Simplificarias muchisimo todo. Por mi parte, me complico con el hard por simple disponibilidad de componentes. [/QUOTE]

Verificación