Investigaciones previas sobre CHAMELEON96

Placas completas (con o sin programador incorporado): Terasic, Altera, "chinas", etc
fpganoob
Veroboard
Mensajes: 17
Registrado: 11 Oct 2018, 15:31

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por fpganoob » 14 Sep 2020, 20:34

No te desanimes hombre!!!

Las ip de altera/intel de video que usa el source que se distribuye, son con licencia. Hay que programar el TDA desde la parte FPGA sin ellas.
El error de que no cabe es un error "generico" del fitter, normalmente hay un error anterior que te da informacion mas veraz del origen.

Vamos hombre... entre todos lo arrancamos!!!

Avatar de Usuario
Subcritical
Spartan 3
Mensajes: 225
Registrado: 24 Ago 2018, 14:52

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por Subcritical » 15 Sep 2020, 06:22

Hoy de madrugada Rampa consiguió un basic "Basic6502" para la @Chameleon96.
https://github.com/Chameleon96-ES
photo_2020-09-15_06-18-10.jpg
photo_2020-09-15_06-18-10.jpg (50.78 KiB) Visto 9135 veces
Conexión serie hacia el Basic:
Screenshot_20200915_010317.png
Screenshot_20200915_010317.png (60.13 KiB) Visto 9135 veces
Última edición por Subcritical el 20 Sep 2020, 06:58, editado 1 vez en total.

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 226
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 15 Sep 2020, 09:08

Acabo de descubrir, que no es fallo mio el hecho de que "mi" quartus no compile NADA de lo que le doy.
Este ejemplo del 6502 que has dejado, no me compila tampoco, y me da el mismo error que ayer me daba cada "dos x tres".
Desconozco de dónde sale ese error, pero no hay manera, mi Quartus no compila nada que tenga QSYS en su código.
Me dice que "no entra" que elija una FPGA mas grande.

A ver si averiguo que pasa. Ayer 10 horas perdidas pensando que era yo el que fallaba...!!!

Imagen

Edito: ahora que veo que el fallo no es mio, he investigado en la red, y le pasa a mucha gente. Podría ser por que mi Quartus 17.1 no se ha actualizado en años, y los ficheros de configuración de Cyclone V están obsoletos. Se me hace raro que sea eso, por que la fpga está en su BD, pero no se me ocurre otra cosa. A ver si puedo actualizarlo o sino, en el peor caso, eliminar y reinstalar.

fpganoob
Veroboard
Mensajes: 17
Registrado: 11 Oct 2018, 15:31

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por fpganoob » 15 Sep 2020, 12:26

Todo esto se esta desarrollando con quartus 17.X
Como te he comentado antes revisa los errores antes de ese y descubriras el origen. Seguramente sera porque has generado de nuevo el Qsys, y en estos ejemplos hay que quitar el sdc de la SDRAM.
O dejas el hps_sdram_p0.sdc vacio o lo eliminas del fichero .qip eliminando su referencia.
Última edición por fpganoob el 15 Sep 2020, 12:29, editado 1 vez en total.

Avatar de Usuario
Subcritical
Spartan 3
Mensajes: 225
Registrado: 24 Ago 2018, 14:52

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por Subcritical » 15 Sep 2020, 12:27

Sysadmin se encontró con el mismo problema:
Imagen
Adjuntos
Captura de pantalla de 2020-09-15 12-26-25.png
Captura de pantalla de 2020-09-15 12-26-25.png (717.08 KiB) Visto 9115 veces

Rampa
Veroboard
Mensajes: 2
Registrado: 22 Sep 2019, 17:27

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por Rampa » 15 Sep 2020, 12:29

Hola. yo uso el 17.0.1 (es el que se usa por defecto en mister para no fastidar los repositorios cuando hay varios en el mismo proyecto) y sin problemas. Lo usas en linux? o en windows? lo digo porque en linux hay que instalar el quartus "headerless" o nunca acaba de instalar y luego hace cosas asi.... :(

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 226
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 15 Sep 2020, 12:50

Ahora ya me funciona:
Eran dos las cosas que me impedían trabajar, una, lo de generar de nuevo el QSYS. Esto lo hacía por que al trabajar con la 17.1, la mayoría de cosas piden conversión entre versiones, y al hacerlo, regenero el QSYS. Lo genera bien, pero luego, al compilar, daba el error ese de que no hay espacio.

El otro error, era, que si no convertía (dejaba el "letrero amarillo" de aviso) y compilaba así, daba error en el módulo de memoria.
Eliminando la línea como se indica en el pantallazo del telegram, se soluciona.

Gracias compas. Ahora sí puedo probar cosas.
(por cierto, uso "guindous", forever :ugeek: )

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 226
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 19 Sep 2020, 06:50

Llevo unos días investigando como obtener video HDMI.

Sé que es un chip NXP TDA19988 (creo que es compatible con los TDA9883) pero aparte del doc. técnico, no encuentro nada mas. Parece que es un chip relativamente viejillo. No he sido capaz de localizar ningún proyecto FPGA que lo emplee, para poder coger sus VHD o Verilog. Lo mas parecido es la BeagleBone, una clónica tipo RPI, pero los fuentes son en "C".
Los fuentes QSYS de a placa que controlan el HDMI no se pueden emplear, por que son "licenciados", y están encriptados. Son binarios quartus ocultos por el vendedor. (creo)
Este chip TDA se programa con registros, y a mi me viene un poco grande leerme toda la documentación existente, y partir de cero creando un código para él.

(reflexiones, no leer... :oops: )
Cuando hice el unamiga (antes de tener ese nombre), estuve yo solito investigando, cerca de un mes, sin publicar nada, para no crear falsas expectativas, y que la gente se lanzase a comprar para luego no obtener resultados. Pero este caso, las placas son tan baratas, y la oportunidad tan cercana (y corta, no duraron ni dos dias en agotarse) que debíamos valernos de ello. Y dado que unos cuantos (digamos 50 usuarios en españa, de las 170 que vendían al inicio) tenemos la placa, lo correcto es mantenernos el día dentro de lo posible, sean buenas o malas noticias.

Avatar de Usuario
Subcritical
Spartan 3
Mensajes: 225
Registrado: 24 Ago 2018, 14:52

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por Subcritical » 19 Sep 2020, 22:32

Marcus Jordan ha investigado el u-boot y tiene dos códigos de inicialización

Código: Seleccionar todo

"i2c dev 2;"                  
"i2c mw 37 FF.1 87 1;"        
"i2c mw 73 FF.1 00 1;"        
"i2c mw 73 A0.1 02 1;"        
"i2c mw 73 E4.1 C0 1;"        
"i2c mw 73 F0.1 00 1;"        
"i2c dev 0 "
genera una carta de ajuste
photo_2020-09-19_22-31-49.jpg
photo_2020-09-19_22-31-49.jpg (109.29 KiB) Visto 8940 veces

Código: Seleccionar todo

"echo Initializing HDMI for 720p...;" 
"i2c dev 2; "                 
"i2c mw 37 FF.1 02 1;"        
"i2c mw 73 FF.1 00 1;"        
"i2c mw 73 A0.1 02 1;"   //02 = 720p / 08 = 1080p 
"i2c mw 73 CB.1 00 1;"        
"i2c mw 73 F0.1 00 1;"        
"i2c mw 73 18.1 FF 1;"        
"i2c mw 73 19.1 FF 1;"        
"i2c mw 73 1A.1 FF 1;"        
"i2c mw 73 20.1 45 1;"        
"i2c mw 73 21.1 23 1;"        
"i2c mw 73 22.1 01 1;"        
"i2c mw 73 23.1 14 1;"        
"i2c mw 37 23.1 20 1;"        
"i2c dev 0  "
Inicializa el TDA hay vídeos del proceso de inicialización a las resoluciones 720p y 1080p a 30Hz de refresco de pantalla.
Gracias a Sysadmin por indicarme que hacían los códigos.

Fihero de inicialización localizado del tda19988 en c, gracias a somhic:
https://github.com/ARM-software/u-boot/ ... tda19988.c

El grupo de telegram en Español es el siguiente:
https://t.me/Chameleon_dev_es

Avatar de Usuario
jepalza
Spartan 3
Mensajes: 226
Registrado: 14 Ago 2018, 18:51

Re: Investigaciones previas sobre CHAMELEON96

Mensaje por jepalza » 29 Sep 2020, 08:40

Siento ser negativo, pero alguien tiene que serlo, no todo van a ser buenas noticias (ojalá alguien sea mas positivo que yo):
tras mas de una semana, y no menos de 50 horas, investigando temas sobre las Altera Cyclone V SOC , sinceramente, por mi parte, dan ganas de abandonar esta placa.... (no la FPGA, sino la placa Chameleon96)

Es lo mas complicado a lo que me he enfrentado en años, y eso que cuando empezamos el ZXUNO ya me parecía complejo el Verilog o el VHDL, pero esto del SOC (ARM+FPGA) se lleva la palma en complicación.
Es una placa muy atada a su procesador, y con pocos pines libres directos, ademas del reloj "atado" y fijo.

Para empezar, los relojes, como ya han indicado los compañeros de telegram, solo se puede (por ahora) emplear desde el HPS (la CPU ARM). Lo que he averiguado, es que "solo" hay tres relojes, uno principal, y dos secundarios, pero son tan raros de manejar, que si le pides 65mhz, te "ofrece" 66.6666mhz, y no he visto forma de cambiar a 65 exactos. Para cambiar los relojes, hay que pasar sí o sí por el QSYS, que ademas de ser lento entre abrir y cerrar, te obliga a recompilar los fuentes, lo que hace que sea lentísimo cambiar un simple reloj. Ademas, luego, a mano, hay que editar un fichero .QIP y anular una línea, cada vez que haces un cambio.

Pueden ser males menores, y quizás con el tiempo aprendamos a hacerlo mas rápido y cómodo, pero por ahora, despues de lo menos 50 horas probando cosas, no he visto nada mejor para hacerlo, lo que incomoda cualquier prueba o cambio, por simple que sea.

Luego, está el tema de los pines, que "solo" disponemos de 8 pines FPGA reales, directos desde FPGA, lo que es insuficiente para cosas serias. El resto de pines son HPS, o sea, los controla la CPU ARM, y si los quieres "coger" para uso propio, hay que usar de nuevo el QSYS, modificar de GPIO a LOANIO, e indicarlo a la CPU, pero en un proceso tan complejo, que se escapa de mis conocimientos aprendidos en casa.
Para lograr UN SOLO pin HPS redirigido a FPGA, estuve 3 horas investigando, y la forma en la que se debe manejar me hace alejarme de ese sistema (con lo fácil que es en una FPGA estándar).

Si haces cambios muy fuertes en el HPS (en QSYS) , cambios que aún desconozco qué lo provocan, el QUARTUS te avisa de que hay que recompilar el cargador (boot o preloader), para lo cual se requiere OTRO programa aparte del QUARTUS, algo llamado "SOC FPGA" de intel, otros 3gb de programa, solo para recompilar el cargador, y reprogramarlo en el SOC, o usar Linux, pero en ambos casos, por ahora, ha quedado fuera de mi alcance, por que he tratado de recompilar ese "loader", y no he sido capaz. Errores por todas partes, que hace que sea un tema completamente separado del tema FPGA, y para una sola persona, se convierte en tarea de gigantes.
de la forma que explico aquí --> viewtopic.php?f=29&t=364

Y ya no digamos el tema del chip TDA19988 , que NO HAY NADA DE NADA en la red, cero patarero. A nivel FPGA no hay nada, ni un solo proyecto que lo emplee. Lo mas parecido es una placa compatible "raspberry", llamada "beaglebone" o algo así, pero es Linux ARM, no FPGA, y los fuentes en C ayudan, pero no son VHDL.
Hay un proyecto llamado HOMER que lo emplea y dice haber logrado salida HDMI, pero es muy viejo, de 2015, y no dejó fuentes en ningún lado, y ademas, juraría que quedó incompleto, sin actualizar.
Otro proyecto es de un Brasileño (o portugués) que emplea uno compatible, el TDA9983, pero no tiene fuentes, solo habla de ello como conversor de video mediante FPGA y TDA.

Yo no me veo capaz de crear un código VHDL o Verilog desde cero, que inicialice el TDA con sus registros, mirando los fuentes C del Linux del "beaglebone", por lo que descarto este punto.
Quizás la gente de telegram lo consiga, yo no puedo, por mas que lo he mirado.

He tratado de sacar VGA por los 8 pines FPGA directos que tenemos, pero no funciona, por que al cambiar cosas en el QSYS, me pide recompilar el "boot" del ARM, y como no he sido capaz, no funciona. Con 8 pines solo da para RGB222, pero para probar es suficiente.

Resumidas cuentas: ahora mismo, es una placa para divertirse y aprender, con resultados decepcionantes.
No me duele nada, por lo que ha costado, pero me decepciona. No sabía que programar un SOC ARM con FPGA fuera tan complejo y lento.

No he logrado, en estas 50 horas, ni un solo ejemplo mio propio, con salida VGA ni HDMI, ni una sola imagen en la pantalla del monitor, pero seguiré intentándolo, la placa sigue en casa, y sigue siendo divertido aprender cosas, a pesar de los batacazos.

Responder

Volver a “Placas entrenadoras”