I like the idea and it would make a great tool for education. One would have to desgin a breadboard like set-up for it.
@Sleepwalker3: You might underestimate the power of mass fabrication. 100 ATtiny24 will cost you 0,473€/chip 100 standard SN7400N will be 0,833 €/chip In todays world, small microcontroller are cheaper then standard logic gates. You gain all the flexibility and only have to design a single circuit to rule them all. I know all those bashing (not that you was bashing) ala "That does not need an uC, that can be done with discreet electronic". However, we oldtimers have to face that an uC-solution might be even the cheaper solution, albeit sometimes maybe a bit more circuitry is involved.
I know all those smartphone and tablet releases is poisoning peoples mind when it comes to release cycles and features releases. However the buspirate is NOT a smartphone or a tablet.
The V3 will always be functional and I assume that all features which will fit in the V3 will make it into the V3 even if V4 is officially out. It might has a few hardware-based features less compared to the V4, however, at the moment it is the stable reference platform, which even the V4 has to measure against.
Ian said it already, it will take the V4 a great amount of time to get close to the V3.
Early buyers might have to fight with bugs on the BP V4 rather then tackle bugs on there projects with the PB V4. Serious, having a buggy project and trying to tackle it with a buggy dev-kit is really frustrating! So stability and well tested performance is something you have to add to the V3 feature list !!!
This is open hardware, V4 is not a "Let's add a few more features and sell it again"-release. Its in many aspects a redesign and hence it will introduce its very own problems. The same problems and time consuming debugging it took the V3 to get as stable and useful as it is today.
And even if you are going to upgrade to the V4 anytime later, and do not see any need for having two buspirates in your toolbox, you can still hook-up the V3 permanently to a project to provide terminal-based low level access to your project.
We are talking here about $27.15 and not $300 or $600 dollars. If you wait a year for a more or less stable V4, you wait to save <$2 a month...
kyron, to help you.... help us ;) Please show exactly what you did and what you typed in. It could be a very small point which makes all goes wrong and we can´t really help you with just more wild speculations. E.g. Make a plain copy of what your tried to connect to the on-board CPLD, including all messages received from the terminal. If its too long and boring paste in somewhere like pastebin (make sure its valid forever, so people in a year or so who are looking for the same problem can still find it) and send a link here... or copy it in a plain text file and attach that.
Which OS? Which clientsoftware (guess URJTAG, but which version)? Which drivers (question might be redundant if OS==Windows)?
What you could try is to connect to the CPLD on-board. The serial-jtag chip on board has two channels. One is connected to the JTAG interface of the CPLD to be able to upgrade the firmware. You can select the port via urjtag by urjtag> cable jtagkey interface=[0,1]
Other then this, I kind of remember that this problem appears to happen with the open source ftdi drivers under Linux (this are the drivers which came with the kernel in most of the cases). I figured out that I could get around it by explicitly refer to the cable address. I will describe that method if you need it.
If this Xilinx people offer a "one-click" SVF generation... then they should do that right. It make no sens to leave the configure part out and I consider that actually a major bug. Plus its even not enough to create manually a SVF file from an existing project, but to create a new project and assign directly a SVF file to it.
impact offers a batch mode as well, I guess it would be the best to figure out how to do all this in a batch file and hence avoid obstacles by pressing different buttons in different orders in a GUI.... grrrrrrr
libftdi module and urjtag are fine too. That means we end up with those topics (all working)
* Using the busblaster with Xilinx impact directly under Linux via the opensource drivers (using a recent impact version 14.2) Unclear here was whether the open source drivers still work with more recent versions of impact and the more recent kernel versions. There was another problem in case impact crashed or got killed. In that case sometimes the JTAG-cable was not longer recognized. It had to do with occupied semaphores which I could solve as well.
* Creating valid SVF files from within impact to be used by urjtag The tricky part to create a SVF file which contains ALL necessary config steps.
* Using urjtag and the busblaster under (tested on Linux 64bit kernel 3.6.5) using the more common libftdi-module Works under a recent Linux system, no need to use the proprietary FTDI drivers and hence no fiddling with unloading and loading modules resp. blacklisting them.
* Getting steppings and bsdl stuff right Where to find and how to make use of bsdl files. How to get unkown steppings right.
Just need to find the time to update the wiki now. Help is welcome ;)
ok i guess I got all parts together. since a certain release impact has a function call "One step SVF". From there help
Quote
An SVF file named default.svf is created in your project directory. For PROMs and CPLDs, the SVF file contains device erase, program, and verify sequences using the specified configuration data file. For FPGAs, the SVF file contains a device program sequence using the specified device bitstream file.
Sounded good and valid to me. Erasing, Programming, Verifying... what else, right?! Apparently NOOOOOO, thanks Xilinx!!! This svf file does not contain any config option. If you go the more complex way, creating a new project->Prepare a Boundary-Scan File (choose) SVF and do all the steps manually (really all, since they will be recorded ALL in the SVF file). It seems to work. E.g., in the "hand-made" svf file, I found
//Operation: Program -p 0 -e -r -loadfpga -master -internalClk -clkFreq 20 -defaultVersion 0 TIR 0 ; HIR 0 ; TDR 0 ; HDR 0 ; TIR 0 ; HIR 0 ; HDR 0 ; TDR 0 ; //Loading device with 'idcode' instruction. SIR 16 TDI (00fe) ; SDR 32 TDI (00000000) SMASK (ffffffff) TDO (f5058093) MASK (0fffffff) ;
The program operation was exactly what was missing within the "One step" SVF files. Thanks again Xilinx for making things more complicated!
I have now more or less a good overview of what to do and hope to update the wiki soon. This is on the list at the moment:
* Using the busblaster with impact directly under Linux via the opensrouce drivers * Creating valid SVF files from within impact * Using urjtag and the busblaster under Linux * Getting steppings and bsdl stuff right
I still want to check if I can manage to compile urjtag with the "native" ftdi_sio modules. That would avoid the usage and installation of the ftd2xx drivers and the necessary fiddling between those two modules.
But the proposed solution by You, has the problem that any time You must to call it via the script. If You forget it, They will'nt work.
Yup thats right, but relatively easy. In my case I never can remember that one has to start urjtag by a command call 'jtag'. Thus, I created this little script call urjtag which does the kernel module stuff first. Solved two problems ;) If people still prefer to call 'jtag' as a command, it's possible too. Either, place a script somewhere which has higher priority in the execution look up compared to the original /usr/bin/jtag, or simply rename jtag into jtag_do_not_start_me_directly_or_you_will_be_badly_surprised and create a script jtag which calls the renamed original jtag command.
As for the patch I believe it's only a small bug-fix. It might work without it equally well.
Did you try in addition to compile urjtag against the ftdi_sio module? Would be interesting if this works too.
Hi, I'm working on a set of modules for OpenScad to generate SoB cases. The idea is to create something people call with a single line of code and which can be both printed on a 3D printer or cut-out by a laser cutter. Many parameters can be changed for individual generation.
Attached is the openscad file and some screenshots. Would be glad if someone could test it. I couldn't test the real world results yet. Hence there might be rather big mistakes or errors.
ok I guess all my other posts condense now down to this. How to configure a PROM or FPGA via urjtag?
In Xilinx impact I can set different configuration options. However, those are NOT part of a generated SVF file. They are included in the impact project file (ipf).
Just copy over the svf file is therefore not enough. One has to make sure PROM or FPGA are correctly configured. How to do this within urjtag?
There is the instruction command and some other and I tried a bit around but couldn't see how this should work.
After solving this I guess I am ready to update the wiki ;)
My question is more, how does the STEPPING influence programming in general including Xilinx own tools (impact). Does stepping just refer to some minor silicon revision or does that include change in functionality which might be incompatible with older versions.
In urjtag the file STEPPINGS allow to assign a certain stepping of a part to a certain bsdl file. Thus, I guess a change in functionality would require to assign a new/different bsdl file to this stepping version.
Xilinx itself provides several BSDL files for the same resp. similar parts E.g. for the xcf16p you can find xcf16p.bsd, xcf16p_1532.bsd, xcf16p_fs48.bsd, xcf16p_fs48_1532.bsd, xcf16p_vo48.bsd, xcf16p_vo48_1532.bsd
Urjtag ships with different versions too. However, providing the more specific versions from xilinx, urjtag switches over to that one. That's a bit odd in my opinion since bsdl files describe the chip and it should either fit or not. I can't see how one could say... it fits nearly if I do not have better options. However, maybe its using simply the most recent... not sure.
ok I checked the SVF file for different programming settings. They are both identical. That means the programming settings as you can reach from within impact are NOT part of the SVF file. Now I leave with the question how to set those programming flags from within urjtag. Couldn't find any info yet.
The info is saved in the impact project file (.ipf) but how to get it from there into the jtag chain via urjtag?
in my understanding its not a good idea to add ftdi_sio to the module blacklist. It works pretty well for other ftdi-based devices. Thus, I would recommend to write a little script which first unloads the ftdi_sio and then start urjtag. Could be as simple as this (not tested)
However, if I read it correct, one can compile urjtag against both drivers. Need to test this. For me compiling urjtag worked compiled against the ftd2xx-driver without any patching with regards to the Busblaster. See the Arch Linux PKGBUILD file [1]. Its pretty much a script which just does what you would do on a manual install. There is a patch but that seems just to fix type casting problem.
Yup ;) As soon as I get it round up I will add it to the wiki.... in sum, impact 14.2 + open source drivers + busblaster works but is very slow still struggel with the SVF conversion and usage of urjtag. urjtag might work under Linux under both ftdi modules need to test this too...
