• Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

12 Good

About offroad

  • Rank
    Advanced Member

Profile Information

  • Gender Male

Recent Profile Visitors

587 profile views
  1. 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).
  2. 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.
  3. 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).
  4. Just wondering: Do you know the Microblaze debugger that comes with Web-edition Vivado? I've used the basic features (breakpoints, step, edit variables etc) on an Artix. It was surprisingly simple and usable without having read any manual.
  5. BTW if anybody is interested: I could dig up my 640x480 monochrome text adapter (40x20 char) that fits into a single 2kByte block ram. It's ugly as hell but excellent for debugging as one write port of DP ram can be used by the application at any clock without restrictions.
  6. Hi, did you check the voltage rating of the RAM? I think it's 5 V, won't work in a 3.3 V environment. The Papilio Duo might be able to do the job with its on-board SRAM, or Saanlima's Pepino.
  7. Stumbling over my old post, if someone is sent here by Google on a mission to reduce latency... The secret to achieving low latency with a UART is... don't use a UART. The 2232H chip, programmed through the DLL interface, can achieve physical roundtrip (!) times, e.g. send a byte via JTAG bypass through the FPGA and back in MPSSE mode, of slightly over 1/8 ms. If I extrapolate the 3.75 ms UART roundtrip time I achieved earlier... my boss wouldn't be happy :-)
  8. just noticed this old post... It's "reasonably" easy to attach it via SPI, I've done it once, takes only four wires and it worked at fairly high clock speed ~50 MHz if I recall correctly. "Reasonably" in quotation marks if I need realtime, but that's Raspberry Pi territory.
  9. Just remembered something: If someone actually reads this >> there are ways to give the device name (which you can find out for example with FTDI's FT_PROG, free download) note that the FT2232H includes two independent devices (e.g. for JTAG and UART). The name of the device "A" or "B" needs to be appended to what is shown in FT_PROG. To make matters more confusing, it's automatically attached to the description with a space character in-between, but to the serial number without (if I remember correctly).
  10. Yes... that error message is a classic... If I didn't know any better I'd guess it came straight from Seattle Unplug everything from USB that might include an FTDI USB-to-serial converter. If in doubt, everything except keyboard / mouse. When this fixes the problem, there are ways to give the device name (which you can find out for example with FTDI's FT_PROG, free download) as an argument so the uploader knows which chip to talk to.
  11. It might be the easiest to write it yourself. From how I understand it (disclaimer - I never actually hacked it) it boils down to write a few bytes to a UART. See this link at "Long commands". At first glance the trigger section looks exactly like what's available in the GUI. As a personal comment: I've learned programming on Unix and often feel sorry for those folks who know only Microsoft GUI-driven madness. But, for FPGAs the additional burden from running Linux is too much for a hobbyist, IMHO. I'd pick my battles carefully... (and PS: In Windows C#, the minimal program to open a serial port, write some bytes, pick some output bytes will probably fit on one screen or two. It's extremely usable for this kind of job).
  12. Hi, >> Pity that development appears to have really slowed down, as it is really close to being brilliant. the disclaimer first, I'm using SUMP only with the Pipistrello board, where I have it in flash ROM. This keeps the Papilio board free for "higher risk" stuff :-) Anyway: If I had to do serious work with the logic analyzer, the first thing I'd do is hijack the interface code and then write a very simple command line back-end that sets trigger conditions, start an acquisition, then dumps everything to .vcd (the file format is trivial BTW) so that it can be analyzed in GTKwave later. My $0.02... So far I've been lucky to get the complex issues sorted out in simulation, the logic analyzer is more like a swiss army knife (which does save the day, occasionally).
  13. Have a look at the FTDI application note: It's actually quite readable. I think MPSSE is geared towards serial IO, with a pre-assigned CLK pin. BTW, after spending a working day on FTDI's JTAG sample code (and bulldozing over 95 % of lines, and it still works, oh yeah) I've come to the conclusion that JTAG and SPI are things I'd rather deal with in Verilog than in C. It seems a total no-brainer, but only from a safe distance...
  14. Hi Captbill, check the MPSSE capabilities carefully. As far as I know, the "fast" commands are tied to a few pre-selected pins so you'll have to write and sample the whole 8-bit IO bank. That means, the "programming paradigm" for the FTDI chip is completely different from the regular MPSSE SPI/JTAG/etc libraries, where MPSSE commands operate largely on a single pin. The clock toggles at twice the data rate so you'd probably have to write D0[0..7] | CLK_low D0[0..7] | CLK_high D1[0..7] | CLK_low D1[0..7] | CLK_high D2[0..7] | CLK_low D2[0..7] | CLK_high ... Assuming the FTDI chip can't help you with handling the clock on an arbitrary pin, you might end up with 1/3 of the data rate of a "by-the-book" MPSSE implementation. The slightly-broken FTDI library posted above will run at clock divider 0, so I do achieve the maximum possible 1-bit data rate. As a word of advice: JTAG isn't rocket science but in implementation it is much harder than it looks due to its flexibility (try to read other peoples' code if you don't believe it). Most communication standards sacrifice some performance for simplicity (regular framing, layer stacks). This one is flat, and your USB "layer" adds complexity (e.g. max. size of a single FT_Write/FT_Read transaction, formatting the data for MPSSE, ..). When it comes to "imagining": As an artist, an FPGA inspires and provokes me like a blank sheet of paper because of its infinite potential. As an engineer, blank paper is a no-cost item hauled around with forklifts by the ton PS: Magnus' "FIFO" logic analyzer code might give some examples to 8-bit data handling.
  15. So you're trying to port this to an Altera FPGA? Of course, the easier way would be to make it work first on the original hardware. Then port it. If I had to debug this design, what I would do first check for valid HSYNC and VSYNC. Does the monitor recognize the frame timing? With valid sync signals applied, connecting any color signal e.g. VGA_greeen to 3.3 V should result in a bright (e.g. green) screen. When this works, we know the basic clocks are correct. DISCLAIMER: My monitor does not turn into a fireball when I do this but I don't know about yours. But as said, porting a design without reference on working hardware is an uphill battle. Besides simulating, maybe it's a good time to buy a Papilio Pro as a logic analyzer which might be part of the 2nd step I'd do.