All Activity

This stream auto-updates   

  1. Today
  2. Alvie, thanks for the replay, yes, Only write is not working. I am able to read the files easily. but I cant open any file for writing. for instance, the "readwrite" example initializes the SD successfully, but it fails at "opening test.txt" step. Although If I manually create the "test.txt" file on the microSD (by connecting it to my PC via a memory-reader), It passes the write step (no write actually!) and reads the contents of test.txt successfully! I didn't know that at-all! How can I enable it?
  3. Yesterday
  4. BTW, here is the official definition of drive strength, straight from the horse's mouth: https://www.xilinx.com/support/answers/38820.html "The drive strength of an I/O specifies how much current we can drive and sink while maintaining the minimum Voh and Vol levels." The bold part is the catch: it doesn't refer to the short circuit current.
  5. Hi, the outputs cannot be used as constant current source. Been there, done that, got the T-shirt and had to buy a new LED. If absolutely desperate, I'd use PWM: E.g. generate a 200 MHz clock and a counter that generates one pulse in 32 or so. With a short circuit current ~ 300 mA this should give no more than ~ 10 mA in average. But this is a hack in oh-so-many ways (among them: tune it to a radio station of your choice...)
  6. Last week
  7. Good work Alvie
  8. Sometris game

    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
  9. Hi Jack, Sorry for the delay. Attached is the file. Thanks, fpga_guy top.bit
  10. Hello Thomas, Yes, it will continue with SDRAM, we have identified an ISSI SDRAM chip to use instead but there is still some work to be done to verify before we do the next run of boards. I'm also seeing if I can find a supply of the current SDRAM chips to do one more run of the Papilio Pro with the current chip. Jack.
  11. Thanks for the feedback Jack. Here's what I would expect to see. With 3.3 V (IOSTANDARD=LVTTL) and a 1K resistor, I would expect a current of 3.3 mA. Given the DRIVE options of 2, 4, 6, 8, 12, 16, 24, I would expect all of the DRIVE values other than 2 to let the full 3.3 mA to flow. Here's what I get: DRIVE=2: 2.85 mA DRIVE=4: 3.05 mA DRIVE=12: 3.18 mA DRIVE=24: 3.22 mA The values for DRIVE > 2 make some sense to me, since they are within a somewhat reasonable margin of 3.3 mA (< ~9%). With DRIVE=2 I don't get the expected current limit of 2 mA, by a large error margin (~42%). With the 'scope I didn't detect any weird power switching pattern.
  12. Are there still SDR-SDRAMs on the market? DDR will be difficult with a soft memory controller, and SRAM is small and expensive... I'm currently working on a project which implements th RISC-V ISA (see riscv.org) and runs a port of eLua to this architecture on a Papilio Pro. It is making great progress, I will post more information here in the forum in the next days. I'm already thinking about moving to another board (e.g. Pipistrello, Arty). But in some way I like the PaPro a lot: It is "publishing friendly" because I don't need a Xilinx CoreGen generated core to access the DRAM. With ISE a synthesis run for the LX9 usually takes only a few minutes including map, place and route, so it is possible to quick check design changes in Hardware As long a design fits in the LX9 it is really a convenient platform. And Xilinx has recently announced that they continue supporting the Spartan 6 series because of their success. Thomas
  13. It's not retired but the SDRAM chip that is used is obsolete. We are looking for replacements which will take a little time... Jack.
  14. I don't think its a good idea to connect directly to ground... I think that drive strength is how much current it will provide through that pin under load. So put a load in by connecting a 1k resistor in series with your ammeter and then see what the current is... Jack.
  15. Yesterday
  16. I was looking into how to limit current from FPGA pins, in the context of safely driving 7-segment LEDs. I thought that the .UCF output drive strength values were somewhat arbitrary values, but according to "Spartan-6 FPGA SelectIO Resources User Guide" the values are actually in mA. Nice. Yet, when I went to test this I got unexpected values. For instance, when I chose LVTTL & DRIVE=12 I think I got something like 46 mA, and when I reduced it to DRIVE=2 I think I got 6 dot something mA. Whatever it was it was very different from the specified DRIVE value. This was tested by shorting that pin to GND, with just the amp meter in series. Since the current did reduce when I reduced the drive strength, I though that maybe my cheap multimeter was not correctly calibrated. Yet, when I connected a 6.1 V power source with a 1K resistor in series I got the expected 6.1 mA. Any ideias?
  17. Last week
  18. Hi, I have seen the pro is out of stock, and also can't be preordered. Will it be in produced again or is the product retired? Regards Thomas
  19. Earlier
  20. Thanks for the suggestions/precautions. I understand your message completely. I have been an electronic technician for many years. However I don't feel that troubleshooting the board has a high likelihood of actually fixing it (I have no experience with SMD..); so I won't be going to the trouble. Paul
  21. Jack, Thank you. I've sent the email. Because of typos on my part you may receive more than one email. Paul
  22. psehorne, We can replace the board for you if you feel confident there is an issue with it. Just send us an email to support@gadgetfactory.net with your shipping address and a link to this email. Jack.
  23. Congratulations on finally breaking this one loose. The scenario like you describe has happened to me several time too. It's so easy to get the blinders on with this type of work. You think you know what the problem is so you just go further and further down the rabbit hole trying to fix it and it turns out to be something simple somewhere else. Good job and I'm sure you will not regret the Oscope. Jack.
  24. OK, I told you I felt like was going insane, right? I now know why... So today my oscilloscope arrived. I unpacked it, connected the power, calibrated the probes and explored the menus. Then I started examining the VGA sync signals of the Papilio + LogicStart, so that I knew what kind of signals I should expect to see when I used my homemade perfboard megawing. I explored all kinds of triggers, statistics, etc. Ahh, it's good to not be blind anymore and have a 'scope. Once I was confident I knew how to use this scope and understood the VGA signals I though "OK, time to connect my homemade megawing". In my homemade perfboard megawing I decided not to match the LogicStart pinout because the layout would not be very convenient for the perfboard I was using. So the first step was to change the .UCF file contents to the one I had written to match my homemade megawing. And as I was doing this I looked again at the contents and suddenly I had a chill: "wait, I have a few pins I'm not using... including the the 7 segment displays I haven't soldered yet... and also... oh my god... I have a reset pin assigned to the LogicStart joystick click... and now this pin is not connected to anything... so it's floating... oh god, don't tell me that...". So I changed my top level verilog file to ignore the reset port, and re-synthesized. I double-clicked the shortcut I had created to upload the bit file to the FPGA and... I got a 100% perfect image. Not only did I get a good sync, but the colors matched perfectly. So my perfboard circuit had been perfect all along, including the color components. No wonder I thought I was going insane. No matter how much I tried to diagnose the electrical part (without looking at the signals, i.e. just the DC components) I was never going to find any fault. Duh. I feel silly, but also relieved. I mean, my confidence was plummeting. I'm not an EE by training by I though a simple circuit like this wasn't going to be a challenge. So when it did prove a challenge it was time for a bit of soul searching. But now I've come back from hell, having slayed the beast, holding its head by its hair. Muhahaha. Bow before me, silly VGA monitor. Anyway, that's what happens when you make a silly mistake and 1) assume too much about where the fault generally should lie, and 2) don't have the adequate equipment to quickly diagnose it. Not that I ended up needing the scope to diagnose this... Thanks for all the feedback, guys.
  25. Hi, the very bright decimal points were indeed one "feature" of the resistor-less board. But best take a magnifying glass and look for the resistors, then you have peace of mind. I'd simply use a multimeter in diode mode on the headers to check the segments, or jumper wires to +3.3 V / GND (but don't do this without resistors or there will be 7-segment magic smoke).
  26. You can post your bit file here and one of us can try to load it to our Papilio Pro board and see if it is the same result. That would let us know if it is just your board or the bit file... Jack.
  27. Just received my Pro and MegaWing a couple of days ago. I have not been able to get segments in digit 0 to light up. Below is the VHDL that works for the other three digits. Seg7_AN(x) (all four 0 through 3) are all un-commented in the ucf file, and I get no compile errors. The Seg7_test process flashes all the other three digits once per second. EDIT-1:You can disregard the code referring to LEDs and Switches; that all works too, and it not relevant to the problem. EDIT-2: One other thing of note. The decimal points (of the three working digits) are very bright, but the other elements are very dim - hardly visible in normal room lighting. library IEEE; use IEEE.STD_LOGIC_1164.ALL; use IEEE.STD_LOGIC_UNSIGNED.ALL; entity Seven_Segment_LED is Port ( Seg7_AN : out STD_LOGIC_VECTOR(0 to 3); Seg7_A : out STD_LOGIC; Seg7_B : out STD_LOGIC; Seg7_C : out STD_LOGIC; Seg7_D : out STD_LOGIC; Seg7_E : out STD_LOGIC; Seg7_F : out STD_LOGIC; Seg7_G : out STD_LOGIC; Seg7_DP : out STD_LOGIC; CLK : in STD_LOGIC; -- 32MHz for Papilio Pro, period 31.25 ns JOY_SELECT : in STD_LOGIC; SWITCH : in STD_LOGIC_VECTOR(0 to 1); --reversed LED : out STD_LOGIC_VECTOR(0 to 3); LED1 : out STD_LOGIC); --reversed end Seven_Segment_LED; architecture Behavioral of Seven_Segment_LED is signal Counter : STD_LOGIC_VECTOR(24 downto 0) := (others => '0' ); signal CLK_1Hz : STD_LOGIC; constant Seg7_AN_ON : STD_LOGIC := '0'; constant Seg7_Element_ON : STD_LOGIC := '0'; begin LED(0) <= SWITCH(0) AND SWITCH(1); LED(1) <= SWITCH(0) OR SWITCH(1); LED(2) <= SWITCH(0) XOR SWITCH(1); LED(3) <= (NOT JOY_SELECT) or CLK_1Hz; -- Joy Stick normally high, acitve low. -- So line below holds LED1 on until JS_Select ir pressed. -- Then LED1 will flash at the rate of the preselector counter CLK_1Hz. LED1 <= JOY_SELECT or CLK_1Hz; Seg7_test: process (CLK_1Hz) -- flash LogicStartMegawing 7-segment LEDs at 1Hz begin Seg7_AN(0) <= NOT CLK_1Hz; --NOT Seg7_AN_ON; --CLK_1Hz; Seg7_AN(1) <= NOT CLK_1Hz; --NOT Seg7_AN_ON; Seg7_AN(2) <= NOT CLK_1Hz; --NOT Seg7_AN_ON; --CLK_1Hz; Seg7_AN(3) <= NOT CLK_1Hz; --NOT Seg7_AN_ON; --CLK_1Hz; Seg7_A <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_B <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_C <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_D <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_E <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_F <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_G <= Seg7_Element_ON; --NOT CLK_1Hz; Seg7_DP <= Seg7_Element_ON; --NOT CLK_1Hz; end process Seg7_test; Prescaler: process (CLK) -- flash onboard LED1 at 1Hz begin if rising_edge(CLK) then if Counter < "111101000010010000000000" then -- counter to clock freq /2 Counter <= Counter + 1; else CLK_1Hz <= NOT CLK_1Hz; Counter <= (others => '0'); end if; end if; end process Prescaler; end Behavioral; Only after I had this problem did I search this forum. I found hits about no current limiting resistors. But those discussion are a few years old, and at the time Mr Gassett stated that new boards were coming out with current limiting resistors. I just received my boards this past week; could my boards be old stock without the current limiting resistors; or is there a problem with my code?
  28. I don't think UART pins are the problem because everything works fine when I download to the FPGA. It only behaves badly when I try to write it to the serial flash. The Microblaze MCS program is written to sends the "Hello World" message at a fixed interval continuously. It only sends one char when I write it to the flash. fpga_guy
  29. Ah, that is a good idea... the crosstalk can make it kind of work sometimes... That sort of thing has happened to me before. Jack.
  30. Hi, random guess: Is it possible that the UART pins are swapped? It seems unlikely, but undriven digital inputs can do this kind of crosscoupling voodoo.
  31. If it helps: there is no need for resistors. You can plug male-female jumper wires into the FPGA board on one side and a 15 pin VGA cable on the other (the diameter of the pin matches). I'm using this as a standard debug tool in 640x480 just HSYNC, VSYNC, GREEN (on/off) and GND. The voltage is slightly out-of-spec but the monitors I've tried with didn't object. I think you won't regret buying a scope. Another immensely useful and free tool is an "activity detector" where you trigger a counter using an unused input and put e.g. every 5th bit on a different LED. Then plug a wire into the input and probe as needed. You could try to fit a SUMP logic analyzer core into the design (disclaimer, never tried this myself. For me it works as advertised on a 2nd board). Edit and pay attention to your programming LED. It is possible that the FPGA resets for whatever reason (e.g. random short circuit on 3.3 V when you move the boards a certain way).
  32. Load more activity