Popular Content

Showing content with the highest reputation since 08/06/2012 in all areas

  1. 3 points
    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
  2. 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
  3. 2 points
    Hi, I just got started with Papilio Pro last week (side note: Great work with the papilio family and wings.. Im really excited about the board's potential). The Pro was my first entry to the papilio line. I was mostly able to figure out how to get the board running and programming. But, many of the instructions/downloads on the papilio website are either outdated or directed towards Papilio One, so getting started took about 4 hours longer than I expected. I thought I'd put together a list of links and instructions for problems I encountered along the way so that perhaps others starting with the Papilio Pro could have something up-to-date (well, as of April 2013, that is): 1. Windows FTDI Drivers: I had some real trouble getting the Papilio recognized as both a USB and a virtual COM port. For my problem, the device was ALWAYS recognized on Windows-- even when I did not have the Gadget Factory drivers installed. And it never showed a virtual COM port. Troubleshooting suggests using a different cable, or editing the device properties. Apparently in my situation, the Papilio was recognized as an FTDI device first and was not using the Gadget Factory drivers. My solution: Download the FTDI CDM Uninstaller. Using FTDI's USBView utility, find the Device Vendor ID and Product ID. Use the CDM Uninstaller to uninstall the FTDI drivers for the Papilio. After plugging and replugging, Windows recognized a virtual COM port. I could also connect through putty and see the default ASCII table output which was apparently the factory default program. 2. Getting Started Bitfile: http://papilio.cc/index.php?n=Papilio.GettingStarted It appears as though the getting started website (as of April 5 2013) does not include the getting started bit file for Papilio Pro. In my beginner state, I assumed this website would have the materials I needed, so I fumbled around trying to use the Papilio One 500K bitfile. After a while, I realized it certainly doesnt make sense to try to use the Papilio One bitfile, especially since the Papilio Pro uses a completely different FPGA. I dont think I've found a replacement for the "Getting Started" bitfile for the LX9 yet. 3. Papilio Loader: As with the bitfiles, the Papilio Loader GUI on the Getting Started Page is out of date (it downloads v1.7). According to a forum discussion around December 2012, the Papilio Loader was modified to support the Papilio Pro. Download the Papilio Loader GUI specifically from the Downloads webpage (this should be version 2.1 or later): http://forum.gadgetfactory.net/index.php?/files/category/2-papilio-fpga/ 4. ZPUino Core and Loader: I think the official ZPUino download page is a little out of date for Papilio Pro. It looks like the papilio website ZPUino getting started guide is out of date too- It uses an old version of the IDE and does not include links for the Papilio Pro bitfiles. Instead a forum post indicates the RetroCade installer works with the Papilio Pro. So, to get the ZPUino to work, download the Retrocade Synth Windows Installer from the Download Page. Use the bitfile ZPUIno_SOC/zpuino-1.0-PapilioPro-S6LX9-RetroCade-1.0.bit to program the Pro. The installer should also include a version of the Arduino GUI which includes a board option for ZPUino on Papilio Pro (LX9). 5. Intro to FPGA Book: With a functioning Papilio Loader and a ZPUino core/ GUI, I was basically good to go with the Intro to FPGA E-book. I also installed the Xilinx toolchain as instructed. No issues there. I'm looking forward to generating and programming with my own bitfiles shortly. It would, however, be nice to have an updated Xilinx webpack quickstart page: http://papilio.cc/index.php?n=Papilio.XilinxISEWebpackQuickStart. EDIT: I installed the wrong Xilinx tools at first. The default link inside the Intro to FPGA E-book now leads to the Xilinx Vivado suite, which doesnt support the Spartan 3 or Spartan 6 series. Instead, make sure to download and install the ISE Design Suite. 6. Papilio Arcade: I also tried the papilio arcade wing. Just make sure to download the correct LX9 bit files from the github https://github.com/GadgetFactory/Papilio-Arcade I havent looked at the AVR8 softcore processor. This is on my list to test with the Papilio Pro, along with some other fun things (SoC editor is on the horizon too). Like I said, Im a big fan of the board. Overall, it looks to be a really great FPGA. I do want to see the usability/ learning curve get to the Arduino level, and it helps to have a good getting started procedure for all boards. Hopefully this helps another beginner in the same situation. Thanks for all the work so far! EJ
  4. 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
  5. 2 points
    I had a copy of Lady Bug written by Arnim Laeuger, that I downloaded from fpgaarcade a long long time ago and forgot all about it. I recently came across it and I spent a little time getting it going for the Papilio. Unfortunately it won't fit on a Papilio One, it uses about 28 BRAMs and the Papilio One doesn't have any external memory and not enough internal memory. Good news is, it will fit entirely into a Papilio Pro or any Spartan 6 FPGA without needing any external RAM or ROM. Getting this ported to the Papilio was just a matter of writing a top level module to connect the ladybug machine to the various ROMs and input controls. This is the first time I've finally used a PS2 keyboard controller from here which appears to have a well written bidirectional PS2 controller. Bidirectional means that when you hit for example the caps lock key, the PS2 controller detects that and sends data back to the keyboard to turn on the caps lock LED. The key mapping I chose can be easily changed if you look in the source code and have a handy PS2 key code reference. As is, the game should be playable with the arrow keys. A small issue, if you have your monitor tilted one way to get other games like Pacman showing correctly, then Ladybug will appear upside down. If you can tilt the monitor the other way, you're all set, if however you can't and just reverse the state of the flip_screen_g variable, the screen will appear at first glance to be correctly flipped but unfortunately only the background is flipped, the sprites and key mapping are not, so, for example, Ladybug will appear to move the wrong way, won't line up with the corridors, eating the dots on one side of the screen causes the dots on the opposite side to disappear, etc. Currently three games are supported: Ladybug, Dorodon (a Ladybug like clone) and Cosmic Avenger (a Defender like clone). I haven't searched what other ROMs the original hardware supported, if any. The source code is available here. To make it all work, download the source then download and place the game ROMs into the appropriate ROMs folder. See the readme file in each folder for a list of the files and checksums you should be looking for, If you're on Windows, run the make_roms batch file in the relevant game rom folder. Game ROMs will be converted to vhdl files in the build directory. If you're on linux, there appears to be a makefile based system for creating ROMs and other files in the hex folder, seemed to work for me in MinGW, but I use Windows primarily. Once the ROM files are converted to VHDL, run the ladybug_papilio.xise project in the top directory and synthesize then upload to your board. You need a Papilio Pro with a Arcade Megawing and a PS2 keyboard in port "PS/2 B", VGA and audio connected. Enjoy! This post has been promoted to an article
  6. 2 points
    Well after finishing this mini project I was very sad because the Double Dragon only has a handful of (not really that great) songs it can play over the YM2151 chip. I started looking around "teh nets" for more YM2151 music and eventually I arrived in Japan so to speak. I guess since Yamaha is a Japanese company it makes sense that it was adopted as the chip of choice on local computer systems. One such very popular system is the Sharp X68000 which as the name suggests, is based on a 68000 CPU. The cool thing about this system is that it has vast amounts of music created for it, here is a hard disk image with over thirty thousand music files on it. The music is in an MML (Music Macro Language) format and typically has an extension of .MDX In fact there are two types of files, .MDX and .PDX and after a fair amount of looking into these formats it turns out that while the MDX files are the Music Macro files, the PDX files contains sampled sounds that can accompany the melodies produced via FM modulation through the MDX files. In fact the PDX files contain 4 bit ADPCM data and they could be directly feed into a chip such as the MSM5205. Another cool thing is that some very nice people have written and open sourced an MML parser that can read MDX/PDX file combos and play them via a software implementation of the YM2151 chip and some generic ADPCM decoder. It is at this point that my other post comes in. With such vast amounts of YM2151 music it was only fair to find a way to play them, so I took the source of the MML player and carved out the software YM2151 implementation (which was in fact copied from MAME's implementation of the YM2151) and only left the calls to initialize the chip and write to the registers. I then had the initialization call simply pulse the reset line to the chip while the write register calls the FTDI functions to transfer the register data to the FPGA which in turn writes it to the real chip. The result can be seen in this 4 minute video. Hope you enjoy it! If the embedded video shows in portrait mode (tall and narrow) click on the youtube logo in the bottom right corner of the video and it will show properly in landscape mode.
  7. 2 points
    Hi, I've got my SDRAM controller up and running on the Papilio Pro as well as the Logi-Pi. http://hamsterworks.co.nz/mediawiki/index.php/Simple_SDRAM_Controller It is running at 96MHz, but as it currently does the full "row open, read or write two words, close row" cycle for every memory access it isn't too fast. However, 24MB/s is more than fast enough if you have any audio projects in mind... flanger, delay, chorus, reverb etc Maybe somebody will write a nice roomy reverb for on the RetroCade?? 8MB is enough for 43 seconds of 48k/16bit audio. That gets you an awful lot of reverb!
  8. 2 points
    I decided to also port the Demon 3.07 verilog code to Papilio_One. This version is identical to the code running on the OpenBench Logic Sniffer board except for using 32MHz oscillator and using serial@115200 instead of SPI. It supports both meta data and input pin data query. The full XISE project can be found here: http://www.saanlima.com/download/Papilio_One/Papilio_One_OLS_3.07.zip 250K and 500K bit files are attached. Let me know if you notice any strange behavior. This post has been promoted to an articlelogic_sniffer_P1_250K.bit logic_sniffer_P1_500K.bit
  9. 2 points
    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;
  10. 2 points
    I've just finished my 8 digit frequency counter - I'm just waiting for a GPS module to arrive so I can use it as the reference timesource. Here's a block diagram of the project: And here is a photo of it in action, when using a one pulse per second generated from the local Xtal as the reference. Full source is up on my wiki at http://hamsterworks....equency_counter This post has been promoted to an article
  11. 2 points
    3 bit of green, 3 bit of red, and 2 bit of blue. http://en.wikipedia.org/wiki/8-bit_color
  12. 1 point
    A new version of the Open Bench Logic Sniffer code is now available for Pipistrello. This version has the capture buffer increased to 64 MB by using the onboard LPDRAM instead of using internal BRAM. The capture rate is still the same, i.e. it still support 200 MHz 8 and 16-bit capture as well as 100 MHz 32-bit capture. The serial communication speed is set to 921600 baud. The original SUMP protocol unfortunately has a capture size limitation (in both hardware and software) to a maximum of 256k samples (512k samples in mux mode). This version of the verilog code has an alternative set of capture size registers that will allow up to 256M samples. However, the SUMP client on the PC must be modified to take advantage of the new registers so I have modified JaWi's OLS client to allow longer captures. BTW, the bit file will also work with the current release of the SUMP client but with the capture size limitation mentioned above. Here is a link to a zip file that has the bit file, the full Xilinx ISE project and the modified version of JaWi's OLS client: http://www.saanlima.com/download/pipistrello-v2.0/Pipistrello_OLS_64M.zip Enjoy! BTW, if anyone is interested in using the built-in DRAM memory controller in Spartan-6 parts this code might be a good starting point. It's setup to use one 64-bit read/wire port but this can be changed by using different parameters when instantiating the memory controller block.
  13. 1 point
    If I was to approach this like developing an FPGA design, where rather than jumping all the way in the deep end and do everything at once I do things incrementally. How is this for a roadmap: 1. Papilio Technology Transition One (TT1) - End of life the Papilio One 250/500 and replace it with a TT1 without the SDRAM. - Keep Papilio Pro form-factor- Move to a four layer board - Add PMOD connectors at ether end of existing wing connectors. - Use 54-ball BGA footprint for the SDRAM, (try to make it compatible for DDR for experimentation) - Route differential pairs to wings - Implement USB interface changes (high B/W FIFO) - Add an additional four power pins between the high/low eight bit wings, giving a middle wing position. Benefits for GadgetFactory: - Build up four-layer PCB design skills - Build up BGA experience - Platform to prototype a DDR platform without using an MCB - decide after a few test boards to go DDR or not - Minimal schematic changes from existing Papilio Pro design - Rework on BGA SDRAM is far cheaper less risky than rework on the larger more expensive FPGA - More freedom for signal routing - EOLing the Papilio One design should reduce the number of configs stock and support (e.g. RMAs, new-user startup issues, EDA tooling) - If BGA proves a difficult nut to crack then you still get to update the PapOne and experience - Solves the eventual problem with Xilinx EOLing the Spartan 3E parts. - adding another 4 pins to the power rails replaces 6x4pin connectors with 4x12 pin connectors, maybe helping out with assembly Benefits for us end users: - Plug and play for the vast range of PMODs (maybe 40 or 50 devices) - Maybe twice the memory SDRAM bandwidth if DDR works out - All existing Papilio Projects should work with a UCF file update, unless they use the SDRAM - Better signal integrity due to more freedom in PCB design - Ability to use differential wings - Access to a higher speed USB host Interface- Removes a bit of the the Papilio One/Papilio Pro divide, as all are now Spartan 6 LX9 - Could use up to 6 PMODs and three 8-bit wings because of the middle wing position. - PMODs are more stripboard / protoboard friendly - MegaWings still work - Just like the Papilio Pro, but even better! 2. Papilio Technology Transition Two (TT2) - Physically same form-factor as the Papilio TT1. - Move to a BGA FPGA as well as BGA SDRAM - Add LX25 options - Wire for using the on-die MCB - use extra I/O and space on PCB for HDMI and uSD card Benefits for GadgetFactory: - No major technology changes - can focus on BGA issues - Leverage built up BGA experience on the TT1 - Minimal software changes required to support - Migration off of TQFP - they won't be available forever - Place Papilio Boards back above the competition Benefits for us end users (over the Papilio TT1): - On board HDMI, - On board uSD - Able to use the higher performance / more flexible MCB in designs - More FPGA logic (due to larger FPGA and use of MCB freeing up resources) You'll notice that I've dropped off the whole Arduino / AVR part of the design. Why? - Most modules/sensors I get require four or five jumpers and don't use the full shield form factor (eg Power + I2C + an interrupt). - PMODs cover nearly all of the Arduino Shields I could see being used. Sure, they cost a little bit more, but where else can you get a 4 channel 4.8 kHz 24-bit A/D converter for an Arduino that you can use for sensing ULF waves? Or an I2S DAC? - All Arduino wings and shields are made to be used by an 8 or 16 MHz MCU. They don't need the power of an FPGA to support them. Nearly any design that the FPGA enables can also be achieved with one of the new 80MHz ARM based Arduino. - You can't use an Arduino to drive HDMI, a high speed serial interface, a CMOS camera, a LVDS display, this is where you need wings or PMODs, and they don't need the Arduino headers - I sort of agree with Alex that moving to an FPGA+Arduino confuses things. If you jump over the Arduino fence I fear you will land in a pool full of sharks and alligators - I would hate to see the forum filled with "I have brand X shield, and it doesn't work right - can you help?" posts. At least with Wings and PMODs it gives a limited set of well known hardware with good documentation (well, some Digilent documentation is patchy in places) that people can leverage - I hate 5V-only Arduino shields with a passion. If you need to include Arduino to improve marketability then I think it is looking in the wrong direction. What you want to be doing is hitting products like the http://www.xess.com/shop/product/xula2-lx25. I think that the TT2 works because it is 'more friendly' than the 40 pin form factor as you can just plug in PMODS/Wings and play. It would also scores over the $230 Digilent Nexys3 in my book - I can use the I/O for what I want to use it for. Why would I want three different sorts of memory? Where is my HDMI? Where is my uSD card?
  14. 1 point
    I haven't really had many thoughts on features I would like - I'm not really an ideas guy... However here is my five cents worth. I would prefer HDMI & uSD card to be a wing, as some day somebody will want HDMI-in and HDMI-out in the same project. It also seems to go against the idea of the FPGA board having no personality, allowing you to customise it with wings to meet your needs.I (most likely needlessly) worry about the power demands of shields and the additional I/OI love the idea of the PMOD compatible wings.sockets by adding GND+3V3 on the end of the connector.If you are going to go Arduino form factor and not have ADC on board then don't put the ADC header on. I'm sure people will get confused if you put a header, market as "Arduino compatible" and none of the analogue shields or sensors work Or at least add pads so the ADC signals could be jumpered to a ADC wing.I (most likely needlessly) worry that the 0.1" headers will become an increasing limitation due to signal integrity issues with more advanced add-ons (which conflicts to me wanting HDMI as a wing ).Decent mounting holes are a must-have.Has anybody ever got the differential input as a usable one-bit ADC to work? I've tried a couple of times with no useful results. It would be cheap and easy if a couple of pins could be made into a workable low-bandwidth/low rez ADC. An inexpensive all-passive 4-channel ADC wing might be possible using 4 differential pairs.
  15. 1 point
    Here's something for you all:
  16. 1 point
    Hi Loop_51, I don't think there ever has been a 100k version - have a close look at the chip's markings. When you click "write to FPGA" the host PC talks to the FT2232D chip, and transfers the bit file via ithe FT2232D's connection to the FPGA's JTAG port. There really isn't anything like a "bootloader" involved - it is all acheived by the TCK, TDI and TMS signals shown on http://papilio.cc/uploads/Papilio/usb-schematic.png It is a little different when you burn the design into serial configuration EEPROM. To do this the programming tool first downloads a 'special' '.bit' into the FPGA, and it is this '.bit' file that connects the EEPROM to the programming interface. The host then erases the required bits of the EEPROM, verifies that the erase worked, programs the EEPROM, then verifies that the EPROM now contains the correct image.
  17. 1 point
    Mike, set the PLL's CLKFBOUT_MULT parameter to 25 and the various CLKOUT<n>_DIVIDE parameter to 8 and you get 100 MHz. 32 MHz * 25 yields an FB clock of 800 MHz. Pages 56/57 of the spartan 6 data sheet (ds162) give the min/max PLL operating range. Fvcomin is 400 MHz, and Fvcomax is 1000 MHz. If you feed the PLL 32 MHz and specify MULT=3, DIVIDE=1, you will be out of spec. BTW, the download link for your papilio pro zip file is messed up -- clicking on it leads to the message saying I don't have permission to upload that file!
  18. 1 point
    Hi Rafael, For a frequency I chose the modulation values used was something like 1221381325 +/-1000000, so when transmitting the positive side of the square wave I used 1222381325, and for the negative side I use 1220381325. This gives the required depth of frequency modulation (a frequency change of approximately 75kHz). If you have an audio stream of signed 16-bit samples A(n), You could use 1221381325 + 32 * A(n) for your modulation. Actually getting the values from A(n) from the CODEC is a different project!
  19. 1 point
    Ok, here's the first prototypes: I've got a set like this going out to Jack and Alvie for testing.
  20. 1 point
  21. 1 point
    Hi Steve, There is a lot you can do on the 250k for Audio projects, but as it only has a small amount of RAM the scope for DSP-style effects (reverb etc) are limited. Compared to a microcontroller (e.g. Arduio) it has a huge scope for weird and wacky sound synthesis - as projects like the Retrocade and the chip-tunes demonstrate. MIDI in/out is pretty simple (it's just a serial protocol after all...), Plenty of scope for things like an ultrasounic distance sensor to MIDI interface. One thing that Papilio can do that micro-controllers can't is generating high quality digital output. .(see http://hamsterworks.co.nz/mediawiki/index.php/SPDIF_out for an example). In-line audio processing is possible too - for example you could build an all-digital active speaker crossover to split out high and low frequencies. But a rule of thumb might be "Writing software is 10x quicker than designing equivalent hardware, so unless you want to chew through your time use a micro-controller (or an FPGA with a soft CPU like the ZPUnio or AVR8) if at all possible". As for wireless, it should be possible to use any wireless modules that works with Arduino - just do a quick search for "Arduino WIreless" on http://dx.com for examples. Of course you may need to port the driver across too!
  22. 1 point
    Looking at the https://github.com/GadgetFactory/Papuino repo, it looks like you're fairly up to date with the main Arduino IDE. Is there something missing in the Papuino repo that prevents a direct build from source of it from working out of the box?
  23. 1 point
    The Papilio Plus sounded interesting but wasn't available when I started this project and did not have any of the needed interfaces on-board. The Avnet LX9-microboard was also a possibility but the limited user-I/O and the lack of HDMI on-board killed that idea. So the only option left was to make my own board - basically merging the fpga and LPDDR from the LX9-Microboard with the formfactor, wing interface and tool-set from Papilio, then adding all the needed interfaces on-board (and then some more to make it more interesting). The biggest challenge was the 324-ball BGA package which forced me away from the hobbyist PCB vendors (like Seeed studio and OSH Park) to the more traditional (and expensive) PCB vendors that offers the PCB geometry needed for this board (5 mil trace width/spacing, 8 mil holes, 4-layes). In my professional life I have used PCB Universe (http://www.pcbuniverse.com/) for many boards with great success and they have very reasonable prices and an on-line quote and ordering system so it's easy to place an order (disclamer: I have no business interest in PCB Universe, just a happy customer). The quote for this board was $450 for 50 boards, more than I like to spend but still a bargin compared to other options. So far all circuits on the board have been tested OK except for the USB host interface which really need Linux up and running first. The board came out perfect - no cuts or jumpers needed so far. Read more about the board features here:http://pipistrello.saanlima.com My plan is to make this an open-source project once all features on the board have been verified. Magnus Karlsson Saanlima Electronics
  25. 1 point
    Finally got another camera to put everything onto a wing and get the thing off my breadboard. So relieved the right angle connector worked out correctly!