bithead

Members
  • Content count

    33
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by bithead

  1. bithead

    USB Issue on AVR side.

    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?
  2. bithead

    USB Issue on AVR side.

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

    USB Issue on AVR side.

    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?
  4. bithead

    USB Issue on AVR side.

    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?
  5. bithead

    USB Issue on AVR side.

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

    My DUO arrived today

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

    Propeller 1 running on Pipistrello

    I also got it build for the LX45 and LX25, and can confirm that it does not fit on the LX9.
  8. bithead

    Propeller 1 open source

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

    Propeller 1 open source

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

    Propeller 1 open source

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

    Xilinx ISE and SSDs

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

    Papilio DUO Kickstarter - Feedback request!

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

    Papilio DUO Kickstarter - Feedback request!

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

    Papilio DUO Kickstarter - Feedback request!

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

    Papilio DUO Kickstarter - Feedback request!

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

    Papilio DUO Kickstarter - Feedback request!

    I'm just annoyed that I missed out on the cheaper 2MB boards. I went ahead and pledged the extra $25 to get that.
  17. bithead

    Papilio DUO Kickstarter - Feedback request!

    My first reaction was "When does this go live?" Since I'm part of the target market, I think you are doing a good job.
  18. 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?
  19. bithead

    Board Files for ISE

    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.
  20. I cannot believe the amount of fun I've had since finding the Papilio platform after I dipped my toe into the Arduino world. This probably isn't the best place to post this, but I'll put it here to begin with -- my current adventures are with the Papilio Pro, so this is the forum I read the most. My current project involves creating a system revolving around the J1 Forth core, since I've had a fascination with Forth for a long time, and the idea of a core designed to support Forth has always fascinated me. What I have at the moment is the J1 core running on the Papilio Pro (and the Papilio One), connected to the serial line that talks to the USB on the board. I'm using the UART provided by Xilinx (that you, Jack, for posting your tutorial on using those, it made implementation a lot easier than it could have been). In the process, I added the ability to sleep the processor if it needs to wait for i/o on the way in, or if it's about to overrun the output fifo on transmit. Between the two of those additions, the serial i/o became very relaible. I'm planning on putting the code up on Github. It's actually already up there, but private, since I realized I've got Xilinx code that I cannot distribute as part of the project, I'll take those out before I publish. Right now I'm trying to track down a possible bug in the system (it's in my code, the cross compiler, or in the core)... I've run into some annoyances there (see another post I made previously about BMM files). Once I have that down, the plan is to move in the following direction: 1. SDRAM access -- Make the J1 core interface with the SDRAM on the Pro. 2. Multicore -- using Chuck Moore's c18 based chips as an example, I'd like to explore the idea of multiple Forth cores all talking to each other. 3. Complete Mini-System -- I realized that the Arcade MegaWing has almost everything needed for a small computer system. PS2 to connect a keyboard and mouse, VGA as an output -- I'm only missing mass storage, but I'll figure out a way around that (hint -- a megawing with PS2 connectors, VGA, audio out, and an SD Card interface would be purchased, by me, almost immediately). 4. Somewhere else -- it's always possible that something shiny will catch my eye and I'll go in a different direction. It blows me away that with the Papilio platform and the free tools provided by Xilinx, a hobbiest such as myself can actually play with processor design. When I first went to college (mid 80's), the only way to really do processor design was to get hired by a place that was already doing processor design, since you needed someone who could bankroll the silicon foundry part of things. Sure, you could maybe play around with programmable ASICs, but once you burned them with your configuration, that was it. Either way, it was expensive. So, thank you Jack and the Gadget Factory for bringing this stuff to market. Thanks to Hamster for putting out the material that got me successfully started along this path. Perhaps I'll be able to give back something.
  21. bithead

    Feedback on Breadboard Wing Prototype

    I agree with Hamster's comments as well. And I would buy one.
  22. The OLS Demon Core with a Wishbone interface? Yes please! I wonder if there is much that could get stripped out of the OLS core if it was going to be used internal only.
  23. 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?
  24. bithead

    BMM Files

    Executive summary: I have a BMM file that looks like this: ADDRESS_SPACE jram RAMB16 [0x00000000:0x00003fff] BUS_BLOCK j1/ram [15:0]; END_BUS_BLOCK; END_ADDRESS_SPACE; Data2Mem gives the following error: ADDRESS_SPACE was defined as 0x00004000 bytes, but the ADDRESS_RANGE total is 0x00000800 bytes. Wha? I don't have an ADDRESS_SPACE element. I want to merge a MEM file that is 4k bytes long, 16 bits wide, into a BRAM that is of the same dimensions. How do I say that in a BMM file? Longer story: Finally got my Papilio Pro. Thanks to the Papilio Loader update, everything seems to be working fine, and I've been able to get the stuff that had been working on the Papilio One 500 over to the Pro. My problem is that I'm struggling with using data2mem and a BMM file to load the block RAM I'm using in a project. I'm using the J1 Forth processor in a project. I've got it running and talking over the serial line. The original author of the J1 processor divides the RAM into 8 2-bit chunks, and provides this BMM file that data2mem seems to be fine with: ADDRESS_SPACE jram RAMB16 [0x00020000:0x00023fff] BUS_BLOCK j1/ram[7].ram [15:14]; j1/ram[6].ram [13:12]; j1/ram[5].ram [11:10]; j1/ram[4].ram [9:8]; j1/ram[3].ram [7:6]; j1/ram[2].ram [5:4]; j1/ram[1].ram [3:2]; j1/ram[0].ram [1:0]; END_BUS_BLOCK; END_ADDRESS_SPACE; In the process of porting to the Pro, I needed to use Spartan 6 specific block ram, so I used the IP core generator to make me a 16 bit wide block RAM, and I hooked that up. Ran great, I was able to get everything working on the Pro as it did on the One. The problem is this -- I want to be able to merge a new set of RAM values into the bitstream without regenerating the RAM core to get it to read the COE file where I've got the current contents defined. Right now the process of loading a new program for the processor goes like this: write Forth codecross compile it, producing a MEM file and a COE file containing the new memory image (I hope to use the MEM file for merging)Force the RAM core to be regenerated so it will reread the COE fileGo through the Synthesis/Implementation/Bitgen cycleload it onto the Pro...then I run my tests and get one more debugging step in (I think I'm close to isolating a bug related to the math being done in the Forth core). All of the steps are relatively fast, except for the "Force the IP Core to be regenerated" and the "synth/imp/bitgen" part, even on a fast machine, these are slow steps. All the documentation I'm reading leads me to believe I can just regen the bit file with data2mem, if only I could get the BMM file format correct. Help!? -- I would really really like to decrease the amount of time it takes to load a new image into the block ram. I really don't want to go through the synth/imp/bitgen cycle every time I need to load a different set of bytes. Background: By day I'm a software development lead, and I've already been bitten by the "software guy tries to write hardware" problem a few times, but I'm pretty sure this is just a "help me figure out how to properly construct a BMM file" problem. I am not a complete idiot in these matters, but I do recognize that I am out of my area of expertise.