• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About MartyMacGyver

  • Rank

Profile Information

  • Gender Male
  1. I'm curious if anything ever became of the 2.1 redesign/prototype?
  2. Thanks for ironing out the bug in the original version... just ordered one myself. :-)
  3. I wasn't sure if you were still having that old issue or had encountered a new one. Sorry to see it's not resolved yet.
  4. Has anyone gotten the Sump Logic Sniffer working with the Papilio Pro? I'd rather not try to reinvent the wheel if others have already done the same.
  5. I found the probes on CuteDigi as well, where I'm ordering a few other small components anyway. Speaking about the Buffer Wings though, I'd kinda rather get the I/O (seems the specs on the I/O board are better - assuming it wouldn't cause problems of its own during logic probing by virtue of it having output capability). Actually, it's a little unclear how this I/O board is supposed to work (even looking at the schematics I found elsewhere on here). Does it auto-sense data directions or does it steam some I/O lines to do that? To recap though, the current input board available at seeedstudio is fine (is it available directly from here and I missed it?), and it's the I/O board that I may not really need which has some work being done on it but should be ready soon. (Edit: and I won't get the I/O wing at CuteDigi either since it sounds like it'd have the same problem - too bad they don't just have the input board.)
  6. I was *just* now pondering ordering one of these boards myself... I take it that it would be a good idea to hold off on buying this elsewhere (I thought it was strange I couldn't find it here; now I understand).
  7. I'd click "like" on your post there, but admin's don't apparently get a like button for their posts... I didn't take what Alex said as anything other than an effort to avoid having discussion of other devices impinge on your interests as site owner and businessman, but clearly you're not annoyed about it so it's all good. Kudos for your continued earnest support of the community - the true spirit of open source and open design!
  8. Had I not found this thread here and seen the active discussion I probably wouldn't have brought it up, but I took that and Jack's comments earlier in the thread as positive signs that discussion of this are OK and even encouraged. It'd be self-defeating to say "No, let's not discuss other open-source Papilio-friendly boards here!", especially ones with unique specs and feature sets that aren't currently available here. It shows interest, which is a sign of possible demand. It's like getting market research for free. Fostering open-source innovation by fellow devs is a win-win situation.
  9. I stumbled upon Magnus' Pipistrello Rev 2.0 today via Hamsterworks... a Spartan 6 LX45 board with HDMI?!? "Shut up and take my money!" was pretty much my first thought (unless the price is totally stratospheric of course). I've had my eye on the '45 (I'd like to have room for some "future-proofing" and perhaps the ability to emulate more than a few devices at once), the HDMI would be really sweet and the massive RAM would be nice as well! I'm surprised there's not been more discussion of it here. I pinged Magnus to learn more... it'd sure be nice to be able to work with one of these, and nicer still if you started carrying it here.
  10. Did you install CadSoft EAGLE and use EAGLE to open the schematic?
  11. As I just got done slaying a ghosting bug moments ago, I'd like to add to this cautionary tale... In the example I'm working on with the Papilio Pro, I've got a few clock-driven VHDL processes in action: one for PWM-style blanking on the order of 16 KHz (for dimming), one on the order of 64 KHz to handle display refresh/multiplexing, and one to simply clock the sample data (10 Hz). Each clock was derived separately from the master clock - nothing fancy, and no odd warnings (no gated clock warnings or such). Besides signals for I/O, the intermediate counters and states were mostly defined using variables and constants. Despite all this effort, I kept getting some faint but very definite ghosting coming from each adjoining digit (driving this in reverse digit order also reversed the direction of the ghosting. I was even careful to blank the anodes first thing in my refresh process, before updating the anode counter and the data pointer! I tried cramming all three clocked processes into one process... it didn't change a thing. Then I remembered something I'd previously read: a given process doesn't update I/O signals until the entire body of that process is executed. So my attempt to blank the display before updating it had no effect whatsoever - the end result was that I was, for one clock cycle for each digit, displaying the previous digit's data using the next anode's index. Voila! The bug behind the ghosting was revealed. (And it'd have gotten away with it too, if not for those meddling FAQs!) To fix the ghosting, I added a "settling" counter/toggle that blanks the display for one refresh cycle after switching to the next anode. This also has the effect of adding a bit of dimming (in addition to the separate dimming process I have in place). Note: even with all other dimming code disabled, making this one change eliminated ghosting... I tend to use an on/off duty cycle so my blanking comes after a short "on" period. It's good to have that "quiet space", but particularly before and immediately after changing to the next anode, particularly if you're doing that within a process block PS: If you ever try blanking (dimming) in one process and refreshing in another, or even in the same one, it's evidently wise to have the refresh clock at least n times faster than the blanking clock. Otherwise, you can encounter all sorts of vexing display artifacts (e.g., some digits stop turning on all the time). Looks kinda cool, IF that's the desired effect (it's usually not). tl;dr - Ghosting may be caused by code side-effects - when processes are involved it's easy to forget that signal settings (e.g., for anodes) won't get updated until AFTER the process is done.
  12. Thanks! Would "pulldowns all around" be reasonable for this board, when it comes to unused inputs? Yes, I'm recently aware of the unused pin property, but I'm not sure what's optimal. As a more general rule for unconnected I/O, would pulldowns be optimal, or would high-Z be (in terms of reducing noise and not consuming more power than is absolutely necessary due to unused pins)?
  13. FYI, in the process of investigating something else I stumbled upon this informative thread... evidently you can also use a setting to ignore unused constraints (which would save fiddling with the UCF for a component like the LogicStart).
  14. If I program my Papilio Pro + LogicStart to only use the LEDs and switches (leaving everything else unused and omitted from the UCF per other advice here) I notice that all segments of the 7-segment displays glow dimly once it's programmed and active. I wonder: would it be better to set all unused I/O lines to high-impedance to prevent this side-effect - or is that already the default, and I need to choose something else as a default? Or, is this actually a sign of some physical problem? The board looks OK... Since I've been doing more reading than programming and I'm waiting on a new joystick cap I haven't fiddled with the 7-segment displays yet.