• Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

13 Good

About offroad

  • Rank
    Advanced Member

Profile Information

  • Gender Male
  • Location Munich

Recent Profile Visitors

834 profile views
  1. FYI: This is the FTDI board to rule them all: "-H" means high speed version, the MPSSE will clock up to 30 MHz and this works reliably with JTAG+Xilinx. You can get it from many vendors.The same exists for quad-channel FT4232H BTW, but I prefer the remaining pins as GPIO. It has proper protection circuitry on the USB port, which most other boards are lacking. I am using those in volume for industrial automation BTW.
  2. BTW, here is the official definition of drive strength, straight from the horse's mouth: "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.
  3. 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...)
  4. 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).
  5. 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.
  6. 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).
  7. 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.
  8. 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.
  9. 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.
  10. 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 :-)
  11. 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.
  12. 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).
  13. 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.
  14. 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).
  15. 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).