Leaderboard


Popular Content

Showing content with the highest reputation since 05/29/2014 in all areas

  1. 2 points
    Original version of game was running on PIC18F6622 and Dingoo A320. Now it's running on Papilio One 500K + Arcade Megawing. I've used the ZPUino soft processor which is realized by Xilinx Spartan-3E FPGA. VGA signal is also generated by the FPGA. The game can be played with integrated buttons of Arcade Megawing or with Atari/Commodore joysticks. I've used a QuickShot II Plus (SVI-102 Plus) joystick in the video below: Demo Please, use the .bit file included in the ZIP. Otherwise buttons and joystick are not working properly. sometris_v121.zip
  2. 2 points
    This is a library for Designlab and Papilio Duo. The decoder module can have up to 4 encoders. For example 4 wheels on a mobile robot platform. Optionally this can be use with a PID regulator for controlling current position, velocity, and direction of an object. - The shown pins are totally optional - By default the Avr chip is disabled Download: Quadrature_decoder.zip
  3. 2 points
    Or any other Xilinx FPGA board with an FTDI chip with MPSSE-engine connected to the JTAG pins (like Pipistrello but not Mojo or Saturn). This is using the xilinx virtual cable driver. Playtag is written by Patrick Maupin. Steps: 1) you need python 2.7 installed. Get it here:http://www.python.org/getit/ 2) unzip the attached zip file playtag.zip somewhere on your computer 3) open a cmd-window and cd to <playtag>\tools\jtag 4) connect your Papilo board to the computer 5) type xilinx_xvc.py ftdi, this will report the available FTDI ports.You should see the A and B ports of the Papilio board (see image). 6) type xilinx_xvc.py ftdi 0, this will start the xilinx virtual cable server on the A port of the Papilo board 7) you can now use impact and chipscope etc. by selecting the xilinx_xvc plugin. Use this plugin settings: xilinx_xvc host=localhost:2542 disableversioncheck=true See attached images and zip file. Do a google-search for xilinx_xvc for more info on how to use the virtual cable driver. Magnus playtag.zip
  4. 2 points
    There is plenty wrong with VHDL and Verilog but I have to say the biggest problem I (and I think many people from a programming background) have is the business of thinking in parallel. Not just the idea that things like assignments take time and aren't instant but things like the fact that (except for power in some cases) it's actually not worth doing conditional evaluation of something, you can evaluate it every clock at no extra cost, in fact you can evaluate hundreds of un-needed things for free just in case they are relevant to a given cycle. Not sure a language can help much with that. There is simply a gap between the conceptual model of programming and the reality of FPGA.
  5. 2 points
    Hi, not every pin can function as clock input. See here http://www.xilinx.com/support/documentation/user_guides/ug385.pdf page 30, search for "GCLK" in the name. Now did you know that there are PLLs inside the FPGA? It takes 2 min of work (maybe a bit more if you do it the first time) to run the core generator and turn the existing 32M clock into 20 MHz or whatever you like. It's one of the most useful features, IMO, in everyday use.
  6. 2 points
    ever heard of "paralysis by analysis"? My advice still stands: Don't try to buy the "best" or the "right" board. Just get any cheap board, spend two working weeks and learn to make that LED blink.
  7. 1 point
    Teaser: Yes, that is XThunderCore. Game still crashes after a few seconds, looks like software issue.
  8. 1 point
    That's the spot sorry not much help ATM but it's almost 10pm and I work very early tomorrow. I will reply back on wed after I have a chance to look into it.
  9. 1 point
    I've just finished testing my LED driver PCB - 8 channels, each driving two constant current outputs (well, sinks actually). Loaded with 50 ohm sense resistors it gives 13mA per channel. 33 ohm will give 20mA. It is using discrete transistors to allow for higher power dissipation - maybe up to 300mW per channel, so should survive a hard short in in LED chains that that run at up to 15V. If anybody wants a PCB just ask... I can send it air post so you might just be able to use it for your Christmas tree lights
  10. 1 point
    I like it :-) For the electronics guys, I also like the "Have you ever played around with solderless breadboards and little ICs? - and FPGA is equivilent to a breadboard the size of a somewhere between a garage and a basketball court, all covered in digital ICs, and a thousand eager minions ready to do the tedious wiring for you".
  11. 1 point
    I hit a brick wall on this for a couple of days - it locked correctly but no HSYNC or VSYNC was being detected by my TV. I've lent my 'scope to a friend to fix his stereo so decided to play with smart LEDs instead. However I had an minor epiphany tonight while getting the boy ready for bed - was looking for the wrong channel for the HSYNC and VSYNC signals. D'oh! Here's the test setup - Pipistrello generating HDMI (powered over the HDMI cable's 5V line! :-/ ), over to my HDMI input wing, then into the Papilio Pro, and out via the 8 bit analogue VGA output of the LogicStart. Holy C@#p - it works! Still a few little random pixel-level issues here and there. Looks like timing between clock domains and/or phase of the capture bit clock. But on the other hand, the errors look consistent between each colour channel - somewhere around the middle of the LSB. Might be a TMDS decode issue. I am stoked.
  12. 1 point
    A Papilio digital line set to be an input should not place that much load on your test circuit as to cause a huge voltage drop. Most likely the FPGA has the internal pulldown resistors configured and they are stronger than your test circuit pullups. You should re-synthesize the bitstream with all pullup/pulldown resistors from the FPGA removed in the constraints file.
  13. 1 point
    I have made a video on that a while ago.
  14. 1 point
    Built two boards last night - one was trashed due to a misaligned HDMI connector, the other is looking OK. Haven't powered it up yet! Only problem so far is that the HDMI connector holes are a little bit too big... and yes, I also need to get some nice clean solder for attaching the pins, not my fifteen year old through-hole stuff!
  15. 1 point
    Yeah the subscription is only $50/year for the electronic edition (pdf download). I've been reading CC since I was a young whipper snapper, I have a full pdf collection back to issue 1.
  16. 1 point
    >> I was thinking it's easy to learn FPGA and then make your idea real by using it It is not. It is 1000x harder than it looks. You would use a "virtual com port", send serial data from PC to FPGA. This is relatively easy. Even easier, implement a pseudorandom generator to create the data. But, sorry for being direct, you're totally in over your head. Proposal: Why don't you buy some cheap low-end FPGA board. Papilio is fine, so is any other, just don't try to anticipate what you think you need. What you really need is one LED and two months hard work. Learn to make it blink, control it through the PC (USB-serial port and UART). When you can do that, you'll be in a much better position to judge the task at hand. It would be realistic for an experienced engineer but not if you're starting from square one. PS you don't actually have to buy it, just get the design tools and learn to use them (and get used to simulate: Hardware just tells you "it doesn't work". Not "why"). The tools are neither beginner- nor user friendly, takes a lot of patience.
  17. 1 point
    Halder: At what speed do you want to transfer data ? What encoding/protocol you want to use in the optical part ? is that a full-duplex or half-duplex protocol ? Do you really need to use USB ? Or just using it as a transport protocol ? (implementing USB is really hard) Best regards, Alvie
  18. 1 point
    Thanks Jack! My Kickstarter Papilio DUO Board Builder version is assembled! I have confirmed the power supply and FTDI 2232 are working. This weekend I hope to have time to check out the Arduino, FPGA, and SRAM! When I have it up and running I'll share assembly details and photos. Enjoy! Bill
  19. 1 point
    Just finishing up testing the project.... http://hamsterworks.co.nz/mediawiki/index.php/High_Speed_Frequency_Counter
  20. 1 point
    Hi, I am a contestant of digilent contest, and I need a feedback for my project. The project name is "Real Time Digital Circuit Design tool in FPGA with VGA interface" Short description: This project implements a digital circuit design tool, as the name says, in FPGA. The FPGA board is connected directly on a monitor and a mouse. The user should use this project to create a digital schematic, and he could check the output signals on a logic analyzer which is included in the project. Here we have two working modes: directly mode, using a mouse which is connected directly on FPGA board, and second mode, using PC. In second mode, user should use Xilinx ISE to create a schematic, and after executing a command, some data are transferred to FPGA via RS232 communication and the schematic is created automatically. FPGA part is implemented in VHDL and in second mode, the data prom Xilinx ISE schematic is processed with Visual Basic Script. You can watch on a example movie on the following link: Thank you!
  21. 1 point
    Assuming the need to go to multi-layer for the BGA part, that looks like it will be a very expensive board. You might look at a part such as the XC3S500E-4PQG208I which is in a 208 pin PQFP package. The FPGA is a bit more expensive but the PCB will be a fraction the cost if you can keep it to 2 layers. Also at least when it comes to Seeed, the cost of the board increases rapidly with size. 5cm * 5cm max is around $1/bd, 10cm * 10cm max is $2.50/bd, while the next size up, 15cm * 15cm max is close to $9/bd. If you can manage to keep it within 10cm square then the bare boards are ridiculously cheap.
  22. 1 point
    Latest code for windows and linux32 can be found here: http://pipistrello.saanlima.com/index.php?title=Arduino-1.5.2_on_Pipistrello
  23. 1 point
    A friend of mine found a junked Hitachi LCD and gave it to me to see if I could get it going. The LCD is an older type, monochrome low resolution. I couldn't find a datasheet for it or pinouts so I went old school and tracked down datasheets for the chips on board and did some reverse engineering of the schematic using a continuity meter. A very good datasheet resource is the "Hitachi LCD Controller Driver LSI Data Book" which is a compendium of a large number of Hitachi LCD controller chips. According to the datasheet, the large chips on board are six HD61200 column shifters (IC3,4,5 and IC 6,7,8) and two HD61203 row shifters (IC 1,2). The unpopulated footprint is is a little weird with some missing pin traces (the one trace gaps on the short edge of the chip) and one less pin on one side of the chip compared to the other side. This footprint matched exactly the footprint of the HD61830 controller chip. The last unpopulated footprint of IC12 should be a SRAM chip for the IC11 controller. The LCD has one 20 pin set of connections that just go to the unpopulated IC11 controller chip. It also has a 10 pin edge connector that connects to the outputs of the IC11 controller and the inputs of the row/column shifters. It appears the PCB was designed to work in both a smart mode (with controller) and a dumb mode (no controller) hence the two different connector options. Because the controller chip was missing, I realised immediately that this LCD could not be driven in a static mode, where you just write data to the LCD internal memory and you can leave it alone to display that data. Instead this LCD would be more like a VGA display where you must constantly send data to it to refresh the picture. The 10 pin connector pinout is:1 to pin 47 IC11 D1 - pin 42 (DR) IC 3,4,5 (upper half of screen)2 to pin 10 IC11 FLM - pin 50 (DR) IC 1,23 to pin 5 IC11 MB - no connection4 to pin 11 IC11 CL1 - pin 52 (CL2) IC 1,2 and pin 37 (CL1) IC 3,4,5,6,7,85 to pin 46 IC11 CL2 - pin 40 (CL2) IC 3,4,5,6,7,86 to pin 48 IC11 D2 - pin 41 (DL) IC 6,7,8 (lower half of screen)7 to pin 29 IC11 VCC (+5V supply)8 to pin 20 IC11 GND9 to TR1 Collector (LCD bias -10V )10 to TR1 Base (LCD bias enable, contrast?) The internal chip to chip connections of the column shifters match those from the datasheet as below. Essentially each column shifter can address 80 columns and three of them are chained together to form a 240 column shifter. There is one set for addressing the top half of the screen and another set for the bottom half of the screen. The two row shifters IC1 and IC2 then select one of the 64 rows to be addressed. Together these two chips can address 128 rows but because their inputs are connected together they address the entire screen (both top and bottom of screen simultaneously) so the entire screen is refreshed in 64 cycles. In cycle 1, row 1 and row 65 are selected and a line is drawn through the top and bottom column shifters, in cycle two row 2 and row 66 is selected, etc, through to cycle 64 where row 64 and row 128 are selected. So the LCD has a resolution of 240x128 but can be throught of as two independent 240x64 areas stacked together. Input D1 sends serial pixel data to the top half of the LCD (top column shifters) and D2 to the bottom. CL2 is the LCD master clock which can go up to 2.5Mhz according to the datasheet. CL1 is the signal that latches data from the shifter outputs to the display registers, MB pin is not connected to anything and FLM is the input to the row shifters. At the start of each frame a 1 is shifted into the row shifters through FLM then zeroes are shifted for the remaining 63 cycles. This way a single bit travels through the both top 64 and bottom 64 rows selecting one row at a time in each half of the screen. Once I understood the basic function of the shifters I decided to hook it up the a Papilio One FPGA as the ideal driver hardware. Please note that the LCD panel runs off 5V whereas the FPGA outputs are 3.3V, however since the LCD does not output signals to the FPGA, it is quite safe to drive the 5V LCD inputs with 3.3V from the FPGA without using level translators. I decided to display a picture on the LCD and I picked a dithered bilevel picure of Lena. I cropped it to 256x128 resolution so it can be easily stored and displayed to the LCD without performing additional math. If I had stored the picture in its more compact 240x128 native LCD resolution I'd have to convert the LCD vertical and horizontal coordinates to ROM addresses via some math such as address = v + h*240 whereas by storing the picture as two ROMs of 256x64 bytes the v counter can directly index ROM address lines 10..5, the top bits of the h counter can index ROM address lines 4..0 and the bottom three bits of the h counter index a bit within the currently addressed ROM byte. The top half 256x64 of the 256x128 picture is stored into one 8x2K RAMB and the bottom 256x64 of the picture into another 8x2K RAMB. The reason for using two separate RAMBs is because the top and bottom of the image is shifted simultaneously so both RAMBs need to be accessed simultaneously. Another way of doing this would be to create a 16x2K memory and use 8 bits for the top and 8 bits for the bottom, or a 8x4K using 4 bits for top, 4 bits for bottom but any of these schemes would require the original image to be preprocessed and interlaced accordingly. The final code to drive the LCD ended up being very simple and is shown below. One last thing to mention is that initially I got no picture at all. After of course simulating the design to make sure the signals produced are correct and then examining the final design running on the FPGA with an oscilloscope, I saw that while the inputs to the chips had valid signals, all the outputs of the row and column drivers were sitting at 5V instead of toggling. After refering to the datasheet again I realised that these drivers need a negative Vee voltage in the range -7v to -17v. This would normally be connected to the collector of transistor TR1 and the base of TR1 could adjust the amount of voltage let through the transistor forming a contrast adjustment. Since I didn't have a handy negative supply I simply soldered a 9V battery in reverse, with the positive to the system ground and the negative directly to the Vee (emitter of TR1). This then provided the necessary negative bias to allow the LCD to display a picture. The contrast is fairly low due to the 9V battery not supplying the ideal bias voltage, I guess -12V would have been better. -- Driver for LCD type LMG6351PLYR, 240x128 resolution, monochromelibrary ieee; use ieee.std_logic_1164.all; use ieee.std_logic_unsigned.all; use ieee.numeric_std.all;library unisim; use unisim.vcomponents.all;entity lcd_top isport ( RST_I : in std_logic; -- active high reset CLK_I : in std_logic; -- master clock -- D1_O : out std_logic; -- data to top half of lcd column shifter D2_O : out std_logic; -- data to bottom half of lcd column shifter CL1_O : out std_logic; -- clock CL2_O : out std_logic; -- latch display data FLM_O : out std_logic; -- row drivers input MB_O : out std_logic -- not used);end;architecture RTL of lcd_top is signal rst : std_logic := '0'; signal clk : std_logic := '0'; signal cl1 : std_logic := '0'; signal cl2 : std_logic := '0'; signal d1 : std_logic := '0'; signal d2 : std_logic := '0'; signal flm : std_logic := '0'; signal mb : std_logic := '0'; signal bits_top : std_logic_vector( 7 downto 0) := (others=>'0'); signal bits_bot : std_logic_vector( 7 downto 0) := (others=>'0'); signal mainctr : std_logic_vector( 3 downto 0) := (others=>'0'); signal hctr : std_logic_vector( 7 downto 0) := (others=>'0'); signal vctr : std_logic_vector( 5 downto 0) := (others=>'0');begin -- input assignments rst <= RST_I; clk <= CLK_I; -- output assignments FLM_O <= flm; CL1_O <= cl1 and (not cl2); CL2_O <= cl2; D1_O <= d1; D2_O <= d2; MB_O <= mb; -- divide main 32Mhz clock by 16 to get 2Mhz clock clk_inst : process(clk) begin if rising_edge(clk) then mainctr <= mainctr + 1; end if; end process; -- 2Mhz clock (max 2.5Mhz per datasheet) cl2 <= mainctr(3); -- horizontal counter hctr_inst : process(cl2, rst) begin if (rst = '1') then hctr <= (others=>'0'); elsif rising_edge(cl2) then if hctr = 239 then hctr <= (others=>'0'); else hctr <= hctr + 1; end if; end if; end process; -- vertical counter vctr_inst : process(cl2, rst) begin if (rst = '1') then vctr <= (others=>'0'); elsif rising_edge(cl2) then if vctr = 64 then vctr <= (others=>'0'); elsif hctr = 239 then vctr <= vctr + 1; else vctr <= vctr; end if; end if; end process; -- generate CL1 (display data latch) cl1_inst : process(cl2) begin if falling_edge(cl2) then if (hctr = 239) then cl1 <= '1'; else cl1 <= '0'; end if; end if; end process; -- generate FLM flm_inst : process(cl2) begin if falling_edge(cl2) then if (hctr = 239) and (vctr = 0) then flm <= '1'; else flm <= '0'; end if; end if; end process; -- image data shifters bit_inst : process(cl2) begin if rising_edge(cl2) then case hctr(2 downto 0) is when "000" => d1 <= bits_top(7); d2 <= bits_bot(7); when "001" => d1 <= bits_top(6); d2 <= bits_bot(6); when "010" => d1 <= bits_top(5); d2 <= bits_bot(5); when "011" => d1 <= bits_top(4); d2 <= bits_bot(4); when "100" => d1 <= bits_top(3); d2 <= bits_bot(3); when "101" => d1 <= bits_top(2); d2 <= bits_bot(2); when "110" => d1 <= bits_top(1); d2 <= bits_bot(1); when "111" => d1 <= bits_top(0); d2 <= bits_bot(0); when others => null; end case; end if; end process; -- top and bottom of screen image ROMs ROM_TOP : entity work.ROM_TOP port map ( CLK => clk, ENA => '1', ADDR (10 downto 5) => vctr, ADDR ( 4 downto 0) => hctr(7 downto 3), DATA => bits_top ); ROM_BOT : entity work.ROM_BOT port map ( CLK => clk, ENA => '1', ADDR (10 downto 5) => vctr, ADDR ( 4 downto 0) => hctr(7 downto 3), DATA => bits_bot );end RTL;
  24. 1 point
    Jack, I tried powering the board both through a high-quality powered USB hub and through a direct USB port on the machine. With both, the noise was clearly audible. When I used an external power supply, there was no issue. In a performance situation, there'd be no issue with using a separate power supply, but for development, the approach won't work. I'll try powering from an extra laptop tomorrow, just for another data point. I kind of suspect a ground connection issue, but I'm not much of an electronics buff. -Hans
  25. 1 point
    Hmm, this is something I started myself a while ago. One of the problems with extending the AVR softcore is that it just didn't seem to be built for a peripheral rich setup (IO space, etc). But I didn't want to leave an open source GCC based solution. Which is why I've watched the ZPU work with interest. I recently tried to use a quadrature interface from opencores, but it was far too featureful and resource heavy. So instead, I created my own "simple" quadrature interface for the ZPU, and using the standard HD44780 code in the ZPUino IDE install, created a sketch to read the quad counter and write to the LCD. It is so very nice to read a quadrature encoder as simply as: unsigned int y=REGISTER ( IO_SLOT (8) ,0); Serial.println(y); And to know that it is being clocked at 96Mhz. (Of course, I most probably have created a piece of junk, full of bugs - but I think it's cute) The code's a complete mess, but if you're interested... it's attached. View attachment: ZpuQuadDec.zip