Leaderboard


Popular Content

Showing content with the highest reputation since 06/21/2017 in all areas

  1. 1 point
    Hello, I am using DesignLab 1.0.8 under Linux and I have a small problem when generating new bit files. The problem is that the case of the files is different from the default and therefore the IDE won't flash my new file. I either need to rename the file or create a symlink. For example the Multiple_Serial_Ports example Creates a Papilio_Pro.bit file while the IDE expects papilio_pro.bit. With kind regards
  2. 1 point
    I have used SK Pang Electronics (skpang.co.uk) which is a company based in the UK. I just checked and they have the Papilio Pro and Duo in stock. They are out of stock of other items. I noticed that prices rose significantly around the time of the Brexit result, and the fall of the UK pound against the dollar and other currencies. Then again you will get a better rate with the euro against the pound, which will offset for you. Buy now while the UK is still in the EU :-) good luck... --Gary
  3. 1 point
    The libraries are a fantastic aspect of the Arduino and the key thing that makes it a worthwhile if otherwise rather flawed platform. It took me a long time to warm up to Arduino but I love the way I can grab some widget and very often grab a library with example code to make it do something right away. It provides a great way to test the thing out and explore its capabilities right off the bat. I'd love to see a similar collection of HDL modules form, blocks of code that do the grunt work like initializing the device and communicating via whatever interface it uses and bring the controls out to sensible interfaces that can be tied into other modules in the top level file. Ideally these modules should be well commented, especially at the top level explaining what all the inputs and outputs do and what sort of signals they expect.
  4. 1 point
    Hmmm... the old Papilios use the FT2232D USB chip, the newer ones (e.g. Papilio Pro) the FT2232H high speed variant. With a more recent board, uploads "should" be fast. I'm using high speed (30 MHz, clock divider 0) JTAG with the -H chip routinely. For xc3sprog, it may be enough to write cables.txt via command line option, then edit the clock rate. I think I've done that once and got upload times (but probably for a compressed bitstream) 200 ms or so.
  5. 1 point
    Another update. I've now returned to Mike Field's original design, and done some work to port this to the Papilio Duo + Classic Computing shield. The main difference from the Papilio Plus is the memory is 512KBx8 rather than 256KBx16. This entailed a re-write of the memory controller to deal with half the memory bandwidth, but nothing else. I also added in the colour maps from Larry's Mandelbrot-Explorer. This is working very nicely indeed, panning is super smooth, and multiple colour maps is really funky. The picture below doesn't really do it justice! If anyone want to try this out, the source is it github, and I'm happy to post a .bit file on request: https://github.com/hoglet67/DSPFract Dave
  6. 1 point
    Update: I decided to try a newer Arduino library for the Wii chuck and a test sketch to read the buttons and joystick position and surprisingly it worked perfectly. I then took a Digilent Analog Discovery and used the Waveforms software to have a look at what was happening on the I2C bus on the working Arduino example and then the non-working DesignLab example on the Papilio and I could see a difference in the initialization sequence being sent from each. I guess I should have compared the two libraries and found the issue without breaking out a scope, but where's the fun in that, right? The Arduino example was sending hF0, h55, hFB, h00 as the init sequence. The Papilio example was sending h40, h00, hFB, h00 as the init sequence. After doing a bit more reseearch I changed the following section in the WiiChuck.cpp in the WiiChuck library in DesignLab as below: int WIIChuck_class::init_nunchuck() { int err = 0; if (I2C.start(WIICHUCK_ADDRESS,0)!=0) err = -1; if (err==0) // if (I2C.tx(0x40)!=0) - this is for OEM Wii nunchucks if (I2C.tx(0xF0)!=0) // for clone Wii nunchucks err = -1; if (err==0) // if (I2C.tx(0x00)!=0) - this is for OEM Wii nunchucks if (I2C.tx(0x55)!=0) // for clone Wii nunchucks err = -1; I2C.stop(); I recompiled the sketch, uploaded to the Papilio and I'm now getting the following results when testing: No Joystick or button activity - Chuck: 128 127 buttons 0 0 Joystick left - Chuck: 46 127 buttons 0 0 Joystick right - Chuck: 255 127 buttons 0 0 Joystick up - Chuck: 128 255 buttons 0 0 Joystick down - Chuck: 128 46 buttons 0 0 Button C - Chuck: 128 127 buttons 0 1 Button Z - Chuck: 128 127 buttons 1 1 Button C+Z - Chuck: 128 127 buttons 1 0 I was not aware that some (all?) clone chucks do not respond properly to the standard init sequence. The following comment was in the Arduino library that I used (https://playground.arduino.cc/Main/WiiChuckClass): // instead of the common 0x40 -> 0x00 initialization, we // use 0xF0 -> 0x55 followed by 0xFB -> 0x00. // this lets us use 3rd party nunchucks (like cheap $4 ebay ones) // while still letting us use official oness. // only side effect is that we no longer need to decode bytes in _nunchuk_decode_byte // seehttp://forum.arduino.cc/index.php?topic=45924#msg333160 Thanks for the advice Alvie, using the scope certainly revealed the issue even if it wasn't due to a hardware fault or misconfiguration. Regards, Anthony
  7. 1 point
    Hi all, over the last half year I have implemented a processor and surrounding SoC bringing the RISC-V ISA (http://riscv.org) to the Papilio Pro. It implements the 32Bit integer subset (RV32IM). The project is hosted on Gitub (https://github.com/bonfireprocessor). It still needs some additional documentation, cleanup and ready-to-run ISE projects to make it easy reproducable for others. But I post this link now, to find out if anybody is interested in my work. I will soon also post a bitstream here so anybody with access to a Papilio Pro can play with it. I have also ported eLua to it http://www.eluaproject.net @Jack: If you like I can also present the project in the GadgetFactory blog. Regards Thomas
  8. 1 point
    Assuming the need to go to multi-layer for the BGA part, that looks like it will be a very expensive board. You might look at a part such as the XC3S500E-4PQG208I which is in a 208 pin PQFP package. The FPGA is a bit more expensive but the PCB will be a fraction the cost if you can keep it to 2 layers. Also at least when it comes to Seeed, the cost of the board increases rapidly with size. 5cm * 5cm max is around $1/bd, 10cm * 10cm max is $2.50/bd, while the next size up, 15cm * 15cm max is close to $9/bd. If you can manage to keep it within 10cm square then the bare boards are ridiculously cheap.