Pues depués de un rato configurando la pc (una gateway mx6947m) con Fedora 22, ya puedo programar microcontroladores PIC de nuevo en Linux!! acabo de probar y configurar Piklab para que por medio de SDCC programe un microcontrolador PIC con el programador USB pickit 2 Clon.
viernes, 14 de agosto de 2015
USB blaster clon en Fedora 22 como usuario normal
Ya con mi máquina funcionando de nuevo veo con agrado que Fedora ha mejorado mucho desde que la deje, po cuestiones de problemas con los paquetes y las actualizaciones.
Ahora expongo el caso de tener el programador USB blaster funcionando muy bien en mi box con Fedora 22
Primero, experimenté un poco con el script que hice para hacer andar mi usb blaster en Manjaro, y funcionó muy bien, sin embargo me pregunte si habría otra forma mas sencilla de hacer funcionar mi programador para la CPLD que voy a usar para dar mis clases de electrónica digital, sin verme en la necesidad de voltaer hacia la ventana.
Pues, siempre si la encontré en un post viejito que tenia para hacer andar mi programdor para AVR, el USBASP y para el USB blaster en Manjaro, pero que requería de añadir mi usuario al grupo plugdev, así como al grupo users.
Sin embargo, no me encontré al dichoso grupo en la nueva Fedora, entonces después de googlear un poco, encontré este link, donde ví un archivo similar al de mi post para AVR, pero para el USB blaster de Altera.
Bien, solo abrí el editor pluma con sudo y se guardo con el nombre
Y pues, escrito así, sin la directiva GROUP de los post anteriores, el programador funciona correctamente.
Ahora expongo el caso de tener el programador USB blaster funcionando muy bien en mi box con Fedora 22
Primero, experimenté un poco con el script que hice para hacer andar mi usb blaster en Manjaro, y funcionó muy bien, sin embargo me pregunte si habría otra forma mas sencilla de hacer funcionar mi programador para la CPLD que voy a usar para dar mis clases de electrónica digital, sin verme en la necesidad de voltaer hacia la ventana.
Pues, siempre si la encontré en un post viejito que tenia para hacer andar mi programdor para AVR, el USBASP y para el USB blaster en Manjaro, pero que requería de añadir mi usuario al grupo plugdev, así como al grupo users.
Sin embargo, no me encontré al dichoso grupo en la nueva Fedora, entonces después de googlear un poco, encontré este link, donde ví un archivo similar al de mi post para AVR, pero para el USB blaster de Altera.
# USB-Blaster SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6001", MODE="0666" SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6002", MODE="0666" SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6003", MODE="0666" SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6010", MODE="0666" SUBSYSTEM=="usb", ATTR{idVendor}=="09fb", ATTR{idProduct}=="6810", MODE="0666"
Bien, solo abrí el editor pluma con sudo y se guardo con el nombre
sudo pluma /etc/udev/rules.d/51-usbblaster.rules
Y pues, escrito así, sin la directiva GROUP de los post anteriores, el programador funciona correctamente.
miércoles, 12 de agosto de 2015
Escribiendo desde Fedora 22
Muy bien, pues ya instale Fedora 22 en mi pc, y pues ahi va jalando de a pocos; como principal ventaja, es que ya la habia manejado con anterioridad y que, algunos de los programas instalados con Manjaro, aqui están, funcionando de nuevo.
Definitivamente, la herramienta Yum extender con dnf se tarda mucho, para mi gusto.
Seguiré probando.
Definitivamente, la herramienta Yum extender con dnf se tarda mucho, para mi gusto.
Seguiré probando.
¿El retorno a Fedora?
Desafortunadamente, desde la ultima actualización de Manjaro, y después de creo dos años sin ningún problema grave, antier mi sistema basado en mancjaro se rompió de una forma estrepitosa.
simplemente se quedaba en el splash y asi estaban dando de vueltas las bolitas verdes, despues de seleccionar el kernel de arranque desde GRUB, incluso, el modo a prueba de fallos se quedaba en esa misma situación.
Primero pensé que el grub estaba apuntando mal, después de la actualización, pero mi unidad de dvd no funciona al 100.
resuelto el problema con una unidad usb y el comando dd, logre reinstalar manjaro en su versión de 64 bits (que es la que tenía), sin embargo ahora, después de la reinstalación. al dar inicio en initramfs, la pantalla se volvia negra y se reiniciaba el equipo.
Leyendo en los foros de Manjaro y ArchLinux, encontré que posiblemente estuviera roto el initramfs, por lo que hice un hijack desde el livecd de manjaro y despues de montar la partición en /mnt y hacer que el chroot tuviera acceso a la red.
La actualización, tal y como se indicaba en los foros, no fue posible, y esto por problemas con gpg, cosa que no entendí.
Aunque agradezco el hecho de que he aprendido mucho sobre la reinstalación, ahora mi sistema no reinicia.
Por lo que tuve que bajarme la iso de Fedora en spin con Mate + compiz y pues a ver que resulta.
Ojalá sea posible que mas adelante pueda recuperar Manjaro, ya que la verdad en cuanto a la ejecución de programas para electrónica, todos corrian perfectamente (bueno a excepción del software para programar microcontroladores PIC y Pinguino), cosa que en Fedora hasta su versión creo 19 no logré que lo hiciera de manera satisfactoria.
simplemente se quedaba en el splash y asi estaban dando de vueltas las bolitas verdes, despues de seleccionar el kernel de arranque desde GRUB, incluso, el modo a prueba de fallos se quedaba en esa misma situación.
Primero pensé que el grub estaba apuntando mal, después de la actualización, pero mi unidad de dvd no funciona al 100.
resuelto el problema con una unidad usb y el comando dd, logre reinstalar manjaro en su versión de 64 bits (que es la que tenía), sin embargo ahora, después de la reinstalación. al dar inicio en initramfs, la pantalla se volvia negra y se reiniciaba el equipo.
Leyendo en los foros de Manjaro y ArchLinux, encontré que posiblemente estuviera roto el initramfs, por lo que hice un hijack desde el livecd de manjaro y despues de montar la partición en /mnt y hacer que el chroot tuviera acceso a la red.
La actualización, tal y como se indicaba en los foros, no fue posible, y esto por problemas con gpg, cosa que no entendí.
Aunque agradezco el hecho de que he aprendido mucho sobre la reinstalación, ahora mi sistema no reinicia.
Por lo que tuve que bajarme la iso de Fedora en spin con Mate + compiz y pues a ver que resulta.
Ojalá sea posible que mas adelante pueda recuperar Manjaro, ya que la verdad en cuanto a la ejecución de programas para electrónica, todos corrian perfectamente (bueno a excepción del software para programar microcontroladores PIC y Pinguino), cosa que en Fedora hasta su versión creo 19 no logré que lo hiciera de manera satisfactoria.
domingo, 9 de agosto de 2015
codificador de prioridad 74x148 en GHDL usando solo estandares IEEE
En el siguiente código se muestra la implementación y simulación de un codificador de prioridad 74x148 que viene de ejempl en el libro Diseño Digital: Principios y prácticas de John F. Wakerly.
El problema que encontré al tratar de compilar en primera instancia este código para el codificador de prioridad, es que usa la función conv_std_logic_vector. La cual, en la libreria IEEE.numeric_std no está definida.
Esto es un problema y de acuerdo a lo leido en los siguientes links
link1, link2, y link3, el uso de esta función se implementa al incluir a std_arith, la cual no es un estándar del IEEE, y que solo fue un "invento" de synopsys. Aunque cabe señalar los siguiente:
Muchos colaboradores de los hilos de los foros consultados, argumentan que nunca han tenido algún problema de compatibilidad al hacer uso de std_arith, y que esto se puede implementar, al pasarle el respectivo parámetro al "compilador" del VHDL.
Pero siguiendo estándares, la implementación del codificador se puede realizar de la siguiente manera:
El testbench usado para la prueba de este código es el que se muestra a continuación:
Y la salida de la señales son las siguientes:
SSSSSS
Se señala que se utilizó la herramienta UMHDL v2.00 de Pablo Garrido de la Universidad Miguel Hernández, de Elche, en su versión para sistema operativo Linux
La siguiente dirección es la indicada por el software, en la sección de acerca de..
http://labatc.umh.es:50005/pgarrido/
El problema que encontré al tratar de compilar en primera instancia este código para el codificador de prioridad, es que usa la función conv_std_logic_vector. La cual, en la libreria IEEE.numeric_std no está definida.
Esto es un problema y de acuerdo a lo leido en los siguientes links
link1, link2, y link3, el uso de esta función se implementa al incluir a std_arith, la cual no es un estándar del IEEE, y que solo fue un "invento" de synopsys. Aunque cabe señalar los siguiente:
Muchos colaboradores de los hilos de los foros consultados, argumentan que nunca han tenido algún problema de compatibilidad al hacer uso de std_arith, y que esto se puede implementar, al pasarle el respectivo parámetro al "compilador" del VHDL.
Pero siguiendo estándares, la implementación del codificador se puede realizar de la siguiente manera:
library IEEE; use IEEE.std_logic_1164.all; -- Para std_logic use IEEE.numeric_std.all; -- Para unsigned entity v74x148b is port( EI_L: in std_logic; I_L : in std_logic_vector(7 downto 0); A_L : out std_logic_vector(2 downto 0); EO_L, GS_L : out std_logic ); end v74x148b; architecture arq1 of v74x148b is signal EI: std_logic; signal I : std_logic_vector(7 downto 0); signal A : std_logic_vector(2 downto 0); signal EO,GS:std_logic; begin codif: process (EI_L, I_L, EI, EO, GS,I,A) variable j: integer range 7 downto 0; begin EI <= not EI_L; I <= not I_L; EO<= '1'; GS<= '0'; A<= "000"; if(EI) = '0' then EO <= '0'; else for j in 7 downto 0 loop if I(j) = '1' then GS<= '1'; EO<= '0'; A<= std_logic_vector(to_unsigned(j,A 'length)); exit; end if; end loop; end if; A_L <= not A; GS_L <= not GS; EO_L <= not EO; end process; end arq1;
El testbench usado para la prueba de este código es el que se muestra a continuación:
library IEEE; use IEEE.std_logic_1164.all; -- Para std_logic use IEEE.numeric_std.all; -- Para signed, unsigned entity v74x148b_tb is end v74x148b_tb; architecture Testbench of v74x148b_tb is -- Component Declaration for the Unit Under Test (UUT) component v74x148b port( EI_L: in std_logic; I_L : in std_logic_vector(7 downto 0); A_L : out std_logic_vector(2 downto 0); EO_L, GS_L : out std_logic ); end component; signal EI_L: std_logic; signal I_L : std_logic_vector(7 downto 0); signal A_L : std_logic_vector(2 downto 0); signal EO_L,GS_L:std_logic; begin uut: v74x148b port map ( EI_L => EI_L, I_L => I_L, A_L => A_L, EO_L => EO_L, GS_L => GS_L); stim_proc: process begin I_L <= "11111111"; EI_L <= '1'; wait for 10 ns; I_L <= "00000000"; EI_L <= '1'; wait for 10 ns; I_L <= "11111111"; EI_L <= '0'; wait for 10 ns; I_L <= "10000000"; EI_L <= '0'; wait for 10 ns; I_L <= "11000000"; EI_L <= '0'; wait for 10 ns; I_L <= "11100000"; EI_L <= '0'; wait for 10 ns; I_L <= "11110000"; EI_L <= '0'; wait for 10 ns; I_L <= "11111000"; EI_L <= '0'; wait for 10 ns; I_L <= "11111100"; EI_L <= '0'; wait for 10 ns; I_L <= "11111110"; EI_L <= '0'; wait for 10 ns; end process; end Testbench;
Y la salida de la señales son las siguientes:
SSSSSS
Se señala que se utilizó la herramienta UMHDL v2.00 de Pablo Garrido de la Universidad Miguel Hernández, de Elche, en su versión para sistema operativo Linux
La siguiente dirección es la indicada por el software, en la sección de acerca de..
http://labatc.umh.es:50005/pgarrido/
Suscribirse a:
Entradas (Atom)