• Content count

  • Joined

  • Last visited

  • Days Won


Posts posted by bithead

  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 hub
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    ddb@xilinx DesignLab-1.0.1 $ uname -a
    Linux xilinx 3.11.0-26-generic #45-Ubuntu SMP Tue Jul 15 04:02:06 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
    ddb@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 $ lsusb
    Bus 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 hub
    Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
    Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
    Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
    ddb@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. 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.

  7. 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...

  8. 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.

  9. 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.

  10. 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.

  11. It's also what worries me about the Raspberry Pi, and the community at large. We're all attracted to the newest and shiniest thing, and those at the bottom end with the least experience and capability are riding on our coat tails



    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.

  12. 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.

    • Like 1

  13. I'm still at the stage of learning where I'm sure I've selected the wrong thing whenever I start a new project.  Having all of that done for me with the pipistrello was a pleasant surprise.


    I have to admit that after 30+ years of software dev I enjoy being a newbie again.


    I suppose I could take a swing at making the files for the One and Pro.  Would be a good way to understand the tools better.

  14. I just recently purchased a Pipistrello, and one of the things provided was a folder of files that I placed in the proper place in the ISE installation, which caused ISE to start offering "Pipistrello" as one of the board it can target.  This made starting a project targeted for the Pipistrello a breeze.


    Has anyone made these files for the Papilio One and/or Papilio Pro?

  15. It's interesting that this thread should pop up.


    I've been wondering if it would be possible to include the Logic Sniffer HDL into another project (on a board like the Papilio One 500 or Papilio Pro, which would have room for it and your project) and then use a Sump client as a ChipScope substitute for those of us using the WebPack tools.


    In other words, I don't want to hook the probes up to external pins, I want to hook them up directly to the modules I'm working on in the FPGA.


    Has anyone else already done this?

  16. Actually, I did see that thread early on. That was one of the motivations -- someone else got it to work, so I should be able to.


    I'm a bit of a masochist, it seems.


    The root of this comes from college -- a friend of mine, while he was in high school (we both graduated in 1983, so you understand the time frame) wrote and sold a Forth interpreter for the Apple II.  I thought that was impressive.  Ever since then, it has been in my brain that I wanted to roll my own Forth sometime.  So this is what I'm doing, although I'm starting out a little lower by actually working on the hardware level first.


    I'm not opposed to stealing code when I find it useful, but I also want to do as much myself as I can.  Like I said, I'm a masochist.


    Heck, that's why I'm playing with FPGAs rather than just getting a processor and starting there.

  17. Alvie: I've been using the J1 forth cpu from here:


    I have it running, and I have it talking to a serial console, but I am quite far away from having an interactive Forth experience running on the cpu. What I have is a gforth-based cross compiler that spits out code that I can load into the CPU (right now I'm using a trick to get the code in, and it is in no way a shortcut, I end up having to resynthesize everything).  I've been able to prove to myself that the system is running, but not much beyond that. Getting the outer Forth interpreter running (that's the command processor most people interact with) means rolling up my sleeves and writing Forth.


    I've also contemplated using the b16 processor from here:


    ...either the b16 or the b16-small (I'd probably do the b16 as it seems small enough). My hesitancy there is because I don't know of any working cross compilers for that chip, and the J1 had one that worked out of the box.


    I didn't realize that the ZPU was a stack machine.  I'm going to have to read up on it.