• Content count

  • Joined

  • Last visited

  • Days Won


Community Reputation

2 Neutral

About bithead

  • Rank
    Advanced Member
  • Birthday 02/08/1965

Profile Information

  • Gender Male
  • Location West Seattle
  • Interests electronics, development -- I will learn how to program anything.
  1. I appreciate the help. After watching the serial ports slowly go away over time, using Windows 7, I asked for a replacement board. Let me just state publicly that Gadget Factory, and Jack especially, have been wonderful to work with and helpful in any way they can be. I've been playing with the Papilio platform for a while, starting with a Papilio One 250 and gradually exploring the entire product line. This was a small hiccup, but nothing that would prevent me from ordering one of whatever Jack's next idea is.
  2. I do not have anywhere near the equipment I would need for the test plan. However, I do see some interesting behavior when I tried burning the boot loader. Under Windows 7, with the device manager window open: I see two com ports, Papilio DUO AVR Serial Port (COM15) and Papilio DUO FPGA Serial Port (COM16) I then execute the Tools->Burn Bootloader... command, with the serial port set to COM16. Burning the boot loader executes successfully. In the device manager, COM15 has disappeared, and "Papilio DUO AVR Bootloader (COM17)" appears. If I then set the serial port to COM17, and load an Arduino sketch, the sketch will execute. But now in device manager, COM17 has gone away, and COM15 (Papilio DUO AVR Serial Port) has come back, and that port has never worked for programming sketches. In order to load another sketch, I would have to re-burn the bootloader and wait for COM17 to reappear. Is this expected behavior? Perhaps I read the tutorials too quickly. ...having rewatched the tutorial, I see that the switching between AVR Bootloader and AVR Serial Port is expected behavior. And what I'm seeing is that I cannot load a sketch using the serial port provided by AVR Serial Port. I have to wipe out the sketch by rewriting the bootloader and addressing the AVR Bootloader port directly. I could offer up a few uninformed hypotheses of why this is happening, but I'll pass. Is there anything else I should test?
  3. I've tried under Win7, and I see the same symptoms. Programming the FPGA goes smoothly, but when trying to program the AVR, it acts as if it cannot detect the board. There are actually some moments where it looks like it thinks it has programmed the AVR, but when the dust clears, it's still just blinking the LED on pin 13, in the same maddening rate. SW1 is at the top. And to be sure that it wasn't a matter of orientation, I tried it both ways. I'm afraid I may have a bum board. Is there anything else I can try to be sure?
  4. It's not a matter of the name, that was just a brief comment -- What I'm trying to do is get DesignLab to program the AVR side of things, and no matter what I try it just fails and goes back to the already-loaded "blink pin 13" demo code. I'll try running it on the Windows VM tonight, just to make sure that the hardware side of things is okay, but I prefer getting it to work on the Linux side of things, because the Windows VM is too damn big to keep on my drive.
  5. I'm trying to program the AVR side of my Duo. I cannot do so. I've got Ubuntu running under Parallels on a MacBook Pro, and I've been running ISE (as well as PlanAhead and Vivado) under this successfully. I can successfully load bit files to the FPGA side of the Duo. However, I cannot seem to get DesignLab to even acknowledge that I have a duo hooked up, when I hook up the AVR side. Relevant information: ddb@xilinx DesignLab-1.0.1 $ lsusb Bus 001 Device 002: ID 203a:fff9 Bus 002 Device 005: ID 1d50:60a5 OpenMoko, Inc. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hubBus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hubddb@xilinx DesignLab-1.0.1 $ uname -aLinux xilinx 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linuxddb@xilinx DesignLab-1.0.1 $ The "Serial Port" menu is greyed out. To contrast, here's lsusb when I plug in the FPGA side: ddb@xilinx DesignLab-1.0.1 $ lsusbBus 001 Device 002: ID 203a:fff9 Bus 001 Device 005: ID 0403:7bc0 Future Technology Devices International, Ltd Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hubBus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hubBus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hubddb@xilinx DesignLab-1.0.1 $ So you can see that things make sense on the FPGA side. And why would the board identify as OpenMoko?
  6. Mine showed up a couple of days ago, along with the LogicStart and the RetroComputing shields. Seems to work, but I haven't programmed the AVR or the spartan yet. This weekend, though... look out
  7. I also got it build for the LX45 and LX25, and can confirm that it does not fit on the LX9.
  8. While removing the cores may be defeating the purpose of getting the full propeller code running on the chip, I think the coolest part of getting the code is our ability to make it do whatever we want it to do, within our own (meager) abilities. I'm also enjoying trying to understand the verilog source. I think the challenge to get arbitrary numbers of cores to work is an interesting one. But step one is getting the actual original code running, and verified. Once I can run a SPIN program on my FPGA, I'll be happy.
  9. I had the same thought about the Cyclone on the DE0 being bigger, but it occurs to me that it's not really an apples-to-apples comparison. But at least in one aspect, it is. Mind you, I am using the code that was meant for the DE1 (the difference is exactly as you say). Also -- I haven't done the work to load the ROM code, so I could be pretty far off of the mark. This is all just an evening's work, and most of that time was spent waiting for the Place and Route step to complete. I'm not sure that the LX25 is a minimum. I have a couple of LX9's (Papilio Pro and the Logi-Pi), an LX25 (the XuLa2), and an LX45 (the Pipistrello), so those are the chips I targeted. I suppose I could be thorough and try other sizes, but the smaller chips take so much time to route...
  10. I've done a little bit of preliminary work to get the design to run on the Xilinx Spartan as opposed to the Altera Cyclone on the DE0 and DE1. A couple of tweaks need to be made to account for the differences between the Altera and Xilinx tools (a couple of definitions need to be moved to before they are initially referenced, and the includes needed to be whacked). The design, as it stands, will not fit on a Spartan 6 LX9. However, it fits on an LX25, which means it would work on a pipstrello just fine, since it uses an LX45. It occurs to me that if we can modify the design to use fewer than 8 cores, it would fit into an LX9, but there would have to be a lot of testing done to make sure that nothing subtle got borked. As of right now, I've only gotten the verilog to build and to get a preliminary place and route done. I haven't done a proper job of setting up pin constraints, which also means that I don't even know if the code will run yet, but at least it builds and routes.
  11. Regardless of whether ISE would do well, UPGRADE TO AN SSD. You will not regret this. Yeah, a lot of what ISE does is CPU bound, but much more of what you do with a computer is disk bound. Just have good backups. The failure mode on an SSD is sudden and complete. If you don't already have an automated backup system, set one up. If you have to think about backing up, it won't happen. FWIW, I've been running on SSD's for about 3 years now. Going back to rotational media is painful.
  12. I'm not quite of the right place to put this, so I'll just put it here. It would be REALLY COOL if one of the components provided in the circuit library was a text-mode VGA driver. Something that displays a simple 80x25 (40x25, 64x16, or something) text screen. I know that perhaps that is something that should be left as an exercise for the user, but it would be so handy. I understand that this is fairly involved -- a font will need to be created/licensed/stolen, there's the VGA driver to be done, is it memory mapped, and many other considerations... Think of it like the video driver chip that motorola shipped next to the 6809 -- Radio Shack put the two together and made the color computer. I can dream.
  13. I can see that. On the other hand, I also know a lot of people that are playing with the Pi, and I don't really see that dropping off, especially with the shield market starting to take off like it is. Just look at the number of Pi accessories available now. Hell, when the Logi-Pi shows up (it's a Spartan 6 board that attaches to a Pi), I'll be right back at the Pi. I also don't see the Arduino market going anywhere. The Atmel chips have a heck of a lot of power available for very little money. I'm not sure about the lifespan worry. From what I can tell, Gadget Factory can get more inventory by just having SeeedStudio make a bunch more boards, the limiting factor would be if any of the parts hit end of life, which I think is more of a risk for the Spartan 3E chips than it is for the Spartan 6. Lets face it though -- we are a niche. Few people will bother to learn an HDL. The software being promoted alongside the Duo will go a long way towards making that better, but it's still going to be limited to those people who want to learn something new. I don't mean to sound negative. I don't feel negative. I think out's an exciting time -- when I went to college, I learned a little bit of microprocessor design. If I wanted to continue with it, I would have had to get a job at a place that did chip design. Now, I can do all of that and more with an inexpensive FPGA. That's huge. It's wishful thinking, certainly, but both Apple and Microsoft got their start selling to curious hobbyists.
  14. Hmmm. Right now I'm playing with the Parallella the most, because it arrived last week. Before that it was the Pipistrello, and I assume that when the Logi-Pi arrives, it will get the majority of my attention. I like them all differently. The Papilio was my gateway drug. I had the Papilio One and the Pro first. Getting the Pro got me interested in the Spartan 6, and that led me to the XuLa2, with a Spartan 6 LX 25, and a breadboard form factor, and that had my attention for a good long time, but the relatively lack of GPIO kept me going back to the Pro. Then I had the opportunity to pick up a Pipistrello, and its Spartan 6 LX 45, with roughly the same peripherals as the XuLa2 (SDRAM, micro-SD card slot), but with as much or more GPIO as the Pro, distracted me for a good long time. I've become a believer in the CPU+FPGA fabric combination, which attracts me to the Parallella and its Zynq chip, the Logi-Pi with its integration with the Raspberry Pi, and now the Duo and its Atmel chip on board. Basically, I love them all, the one that gets my attention is usually the newest. Hopefully I will eventually have a project worthy of publicizing.
  15. Oh, I don't think there is anything to "make right," I just didn't get there fast enough! Be happy that it went as fast as it did! Man, Papilio One, Papilio Pro, XuLa2, Pipistrello, Logi-Pi, Parallella, and now a Papilio Duo. I might have to admit I have a problem.