Analizador lógico low cost 8 canales

[Salva_F]

Hola, he comprado un analizador lógico de estos de bajo coste de 8 entradas y 24Mhz de sample rate para ir trabajando en mi proyecto de display SPI y principalmente como decoder de SPI, he visto que alguno lo usáis y tenía varias preguntas:

Si el clock de SPI es de 2Mhz ¿que tal se comporta el dispositivo teniendo un sample rate 12 veces superior ?, ¿que software usáis, el Pulse View de código abierto o el Logic de Saleae?

Gracias por vuestra ayuda.

Salva

[Democrito]

Hola Salva:

Te recomiendo utilizar frecuencias menores porque con frecuencias muy altas no coge bien la señal. En este sentido me refiero a bajar de alguna forma la frecuencia del SPI y cuando veas que trabaja bien y hace lo que esperas entonces le pones la máxima velocidad.

Sobre la frecuencia de muestreo en teoría tendría que ser como mínimo el doble. Yo uso PulseView y de manera fija lo suelo poner a 4MHz. Si algo va a una frecuencia cercana a esos 4 MHz lo que hago es (en el caso del SPI) lo que te he comentado arriba.

Te dejo con un tutorial que hice sobre PulseView. Viene con ejemplos prefabricados para SPI e I2C, analizandos a través de PulseView.

https://github.com/Democrito/repositorios/tree/master/Micros/Atto64/PulseView

Saludos.

[Salva_F]

Hola, gracias, si, lo miro las demos de SPI la verdad que me vendrá bien para poder tener un entorno de familiarización.

Salva.

[charli va]

Hola Salva! te cuento por si te aporta algo.

Por la teoría de Nyquist (siempre nos olvidamos de Shannon) debes muestrear siempre al menos al 2doble de la frecuencia deseada. Es decir si tu señal spi es de 4Mhz, deberías muestrear al menos a 8Mhz. PEro se recomienda para minimizar errores muestrear  entre 4x y 10x es decir lo ideal sería escanear a 16Mhz como mínimo para que no tengas errores.

Yo en la realidad siempre he tenido buenos resultados con estos cacharritos, a veces es cierto que cometen errores cuando vas muy al límite de la velocidad pero en general por el precio que tienen la solución es más que aceptable.

Tengo que probar lo que ha mandado Luis Miguel, si tienes un esp32 a mano lo puedes probar, creo que por lo que vi en la documentación llegaría hasta 20Mhz pero verifícalo si lo quieres probar porque no lo tengo claro.

Luego por otro lado podrías usar Sigrok, que aunque tengo una nueva versión que liberaré en breve, la actual aunque con mucha carencias te permitirá muestrear de forma exacta y sin error todo lo que pase dentro de la FPGA, esto @obijuan tiene varios tutoriales, yo ahora no puedo invertir tiempo en preparar uno porque con la nueva versión quiero preparar mucho material de documentación y por unas semanas no quiero hacer trabajo que no valga, pero te lo comento porque igual investigas un poco y te viene muy bien.

Sobre el software pulse view es el estándar open source, casca de vez en cuando y tiene carencias pero el decoder de protocolos es una maravilla. El Logic es una maravilla pero depende del clon que hayas comprado te funcionará o no.

Saludos!

--
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 este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/70413cc2-c750-48e9-937a-4446c441d11an%40googlegroups.com.

[Democrito]

He eliminado el post anterior porque al mirar el circuito me he dado cuenta que el el "initic" (tic inicial transcurridos un tiempo) tiene un contador con el reset al aire. A partir de cierta versión de toolchain no se permite entradas al aire (aunque existen algunas excepciones, pero aquí no se cumple la excepción).

[Salva_F]

Hola, si, los conceptos de teoría de señal los tengo claros, la cosa era ver experiencias reales yendo al límite de la frecuencia de muestreo, pero con vuestros comentarios me queda claro. Lo que mencionas de usar "Sigrock"  es usar un modulo Verilog que recibe las señes a analizar dentro de la FPGA y lo saca hacia Pulse View via serie, ¿es así?, desafortunadamente la web de Sigrock https://sigrok.org/ está caída y tengo que ir sacando la información via tutoriales y repos.

Salva

El miércoles, 23 de abril de 2025 a las 15:26:23 UTC+2, charliva escribió:

[charli va]

El proyecoto Sigrok (pulseview es parte de él) está muy poco mantenido y suele tener muchos problemas.  el compoennte que tenemos en icestudio se llama iceRok , como te digo en breve tendremos nueva versión muy funcional. De momento explora con el saleae que es una herramienta fundamental.

Hablando de límites, el mío por ejemplo aunque pone 12Mhz me permite muestrear a 24Mhz y en general va muy bien.

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/477877ed-9974-43bc-bc19-6eecc8ef737an%40googlegroups.com.

[Salva_F]

Vale, con lo que comentas está claro. Ayer eche a andar la última versión del  Saleae con el dispositivo que compre, voy a ver como chuta.

Salva.

[Salva_F]

Pues ya he hecho pruebas, la verdad que viniendo de un osciloscopio de 4 canales pensaba que tampoco iba a ganar mucho en cuanto a poder ver cosas, pero no, la diferencia en cuanto a capacidad de hacer debug en entorno de FPGA es enorme. El analizador funciona bien pero el tamaño de la ventana de captura determina la velocidad máxima, si lo uso a 24Mhz puedo capturar unos 100-200mS, si lo uso a 8Mhz puedo capturar 5 o 6 sec, cuando paso de esos parametros me da error de buffer en el host, como si la velocidad entre el dispositivo y el PC no fuese suficiente, tengo que investigar un poco más a ver.

Pongo abajo una foto del modelo en concreto que tengo.

Salva.

[charli va]

Buenas Salva! efectivamente, el tema es el siguiente, estos dispositivos baratos la velocidad de comunicación entre el dispositivo y el ordenador usan usb 2.0 que en el mejor de los casos te dará una tasa de 30-40Mbps efectiva. Y en cualquier caso no tengo claro que envíen en tiempo real (yo doy por hecho que no) y lo que hacen es guardar en un buffer las muestras y luego mandártelas para así evitar  colapsos o perder datos.

Entonces al final juegas con ese buffer de memoria. Si metes más canales, el espacio lo usarás en datos en vez de en tiempo, si metes menos canales pues tendrás más tiempo y lo mismo ocn la velocidad. Si tomas más muestras por segundo perderás tiempo efectivo , al final tienes un saco y cuando se llena de la forma que sea se llenó. Ahí no tienes mucho más que hacer, por eso los analizadores cuando más capacidad tienen tanto de canales como de tiempo de captura cada vez cuestan más dinero.

Vete contándonos us progresos!

Para ver este debate, visita https://groups.google.com/d/msgid/fpga-wars-explorando-el-lado-libre/0bfd9bd2-d2e9-4d60-9c1d-912ceb0484fan%40googlegroups.com.