Seeed has the Bus Blaster v2 again. Yeah! Get one here:
http://www.seeedstudio.com/depot/bus-bl ... p-807.html (http://www.seeedstudio.com/depot/bus-blaster-v2-jtag-debugger-p-807.html)
Now in RED! :)
[quote author="ian"]Now in RED! :)[/quote]
Dangerously!
Finally, I was hoping it would be in stock soon; ordered one immediately, so I can finally hack on my new puppy (http://http://beagleboard.org)...
Any idea when they will be in stock again? Seeed has no more available. :-(
Should be any day. I ordered the new batch when the last batch went on sale. I'll make sure they have the latest test and see where things are at.
Sounds great; thanks!
It's back again :)
Just ordered one! Thanks! :-)
Out of curiosity, what revision of the Bus Blaster is being sold at Seeed? I've seen two different schematic versions in the projects area:
2.a1: http://http://dangerousprototypes.com/docs/Bus_Blaster_v2_design_overview, and
2.6: http://http://dangerousprototypes.com/docs/Bus_Blaster_v2_hardware_revisions
Though I suppose I can wait until it arrives. :-)
v2.a1 is the current production version. v2.6 is a revision that is currently in development, but before that ships we actually have a v2.5 that is a small update with a LED and button.
Gotcha, thanks!
[quote author="ian"]v2.a1 is the current production version. v2.6 is a revision that is currently in development, but before that ships we actually have a v2.5 that is a small update with a LED and button.[/quote]
Maybe something you could incorporate in the next version:
We're currently using the Busblaster as sort of a fast USB->SPI interface in the FT245 synchronous FIFO mode. In this mode the FT2232H outputs a 60MHz clock on ACBUS5. The schematic of the first version (http://http://dangerousprototypes.com/docs/images/0/01/Bus_Blaster-v2-cct.png) correctly points out on the bottom that the GCK pins of the CPLD are 1,43,44, but incorrectly says: "AD0 (TCK) and AC5 (FT245 clock out) are GCK pins".
This is not the case, and it really hurts, since we can't use the clock distribution of the CPLD.
This would really come handy for using the Busblaster e.g. as Logic Analyzer or whatever else (the FT245 synchronous mode is quite fast, ~32MByte/s). So my suggestion for the next revision is: swap ACBUS2 and 5 (pin 41 and 44 on the CPLD), so that the clock out is connected to a GCK pin.
Steve
Thanks Steve,
My original intent was to make that connection, but the routing was too messy. I'm sorry I didn't remove the note.
Is it just the routing of AC5 to the other clock input that needs the GCK pin?
[quote author="ian"]Is it just the routing of AC5 to the other clock input that needs the GCK pin?[/quote]
Yes, in the synchronous mode the FT2232H will use ACBUS5 as clock output. There is another mode called "Host Bus Emulation Mode", where the chip outputs CLKOUT on BDBUS5, but I think this mode is to no relevance for the Busblaster, so you're just fine with ACBUS5, since you can do all the stuff in either the synchronous or asynchronous FIFO mode anyway.
One possible use: With the ACBUS5 clock pin connected, it would be totally easy to put a 8 channel 30MHz or 16 Channel 15MHz logic analyzer inside the CPLD when using the synchronous mode (providing a constant stream of data). Not dividing the clock (60MHz) might work as well, but you may overflow the FIFO.
Actually this should work fine as well on a current Busblaster without a dedicated clock input, but you're really running in timing trouble if you're trying to do more complex stuff like SPI or other serial interfaces in the CPLD without being able to use it's clock distribution network.
Steve
A forum member (arhi) has messed with this before. As I recall the AC5 output is looped back to the FT2232 on another pin. Is that what the CPLD divider would be for? I'd like to add this feature and add support to the SUMP open logic analyzer client, but I wan to be sure to get it right this time :)
It does not work that simple ... ftdi samples data on the 60Mhz clock when the "sample now" pin is at proper state (don't remember what pin and was it high or low, irrelevant it's there in the datasheet) and if the "ready" pin is at proper state. If ready pin is at "wrong" state the ftdi is "busy" and is not sampling. You could divide the 60MHz that is outputted from ftdi but the sampling time with always be 1/60M sec and in sync with that 60MHz clock.
Making sump compatible client with ftdi only is impossible as ftdi will be sending data via usb in real time, it can;t sample this fast when operating in serial mode etc etc ... so you need to have a client that talk to ftdi using ftdi libraries.
Adding a cpld on board could give us some ring buffer, so that sampling is actually done by the cpld at frequency we like and then sent back to client via ftdi at 60MHz (with pauses that usb port generate). I believe FPGA is better choice here because we can squeeze a huge enough ring buffer in to have the device be usable at 60MHz too :D (with a fpga like we have on obls we could in theory get 50MHz sampling stream to go without interruptions. FPGA would also allow for some fancy triggering...
Anyhow, SUMP compatibility - not gonna happen - as if you want to use 60MHz throughput of the 2232H you have to use ftdi libraries. Good thing is that those exist for linux, osx and windoze so it's not a big deal. What could be made is a "driver" that would present itself as serial port and that would accept the sump commands and then pass the data from the ftdi, but taking into account a major difference between this type of device and sump device, this device sends "real time data" while sump sends "captured package" so a whole client software really has to be written differently ..
I know it won't be drop-in replacement, and I figure reworking it will be a lot of labor. When we started OLS I kept smacking down the idea of "Fast USB 2.0 interface, OMG!!!" because it wasn't drop-in compatible with SUMP and I knew nobody else was going to add that support except Jack and I...
Here I just think it would be fun to use a Java FTDI library (http://bleyer.org/jd2xx/ (http://bleyer.org/jd2xx/)) to capture some data and show it on the display. Just a proof of concept like you did with your application. Once the support is there we can give away some free PCBs and hope someone gets the itch to add trigger searching, etc to the data stream ;)
Don't get me wrong, I'm all for making a logic analyzer based around 2232H :) .. it's just that I think the sump compatibly is going to be unefectively difficult and that we have to go with ftdi drivers meaning the brains basically need to be on the client. With the brains on client you could easily implement triggering on client side... it would basically be something similar to logic8. Besides 2232H there needs to be a ring buffer on board to buffer data when ready line show that ft is waiting to send data. I did some small test with a counter and sampling at 60MHz on 500M samples that ftdi was supposed to fetch it skipped ~200k (some average from 3 runs on a very fast computer doing nothing but fetching data from usb). Some more tests should be performed in order to see the minimal ring buffer required for different frequencies to get consistent error free scan's but these small tests I made show that dropping freq to 50MHz and a small buffer of few hundred bytes should get the job done ..
I did some small test with a counter and sampling at 60MHz on 500M samples that ftdi was supposed to fetch it skipped ~200k (some average from 3 runs on a very fast computer doing nothing but fetching data from usb).
Good to know. I didn't realize this was an issue. A FPGA is a way better frontend then I think, because the memory and registers are "cheaper".
Thing is when you engage the 60MHz transfer it sends bytes from the input pins at max 60MHz or 60000000 bytes in second. What is the problem, there is a "busy" pin and when local buffers on ftdi get full the busy pin is activated. Anything happening on input pins while busy is active is - ignored :D... In theory if you had a super fast computer fetching data from usb port at max speed with super free usb controller there will never be a busy state as data would go trough immediately, but you can't have a long sustained transfer of 60Mhz trough usb port. There are buffers inside FTDI + in the usb receiver on computer side that handle this but they are not enough if you are constantly pushing data at 60MHz. If you drop the data stream to 50MHz you will have enough buffering on the ftdi and client side to send data trough, and for short bursts (still way longer then obls) a ring buffer will allow even 60MHz sampling to work (for e.g. 200kb will allow for 500M samples to go trough at 60MHz by some tests I made...) .. so I think some combo of obls and 2232h would be best... a fpga that does triggering and sampling (50MHz and down) into a ring buffer that's then sent real time to computer via 2232h
The Saleae logic is 20 (for me never >12) MHz max, even hitting 20/30/40MSPS with a $6 chip is ok by me :) I have wanted to do a continuous sampling LA for a while, but I hate writing desktop software so it won't happen :D
Will the coolrunnerii be able to handle 60MHz on a /2 without problems on non-GCK pins? I'm not experienced enough to know. I will make the swap in the next revision, but maybe it is possible to test it before then?
For SUMP to work with continuous, it would need a new capture module that configures the ft2232, searches the datastream for the set triggers (even simple h/l/r/f triggers like the saleae), and count to X samples. The logic seems not-hard, back-of-napkin code. The Java wrapper stuff, and integrating into sump I have no idea about. Maybe if I make a simple test module with one of the java wrappers Jawi will integrate it for me.
Been messing with the driver wrapper, but I don't think it supports the MPSSEs.
You seen my tests .. if we decide to go 50MHz and down we might be able to do it with cpld but how expensive are the fpga's I think it might be way better to go with fpga. It can easily handle 50MHz, it can have big buffer, it can sample at 100MHz in "sump" mode and it can sample 50MHz and lower in "throughput" mode ... so I'd avoid cpld for this...
Wrt client, The source I linked to one of the posts configures ft2232h and gets the stream from it. That stream I then read into ram and display using opengl .. converting that source to java should be 10-30min of work (to get all ftdi stuff working with java) and then the difficult job starts - fetching 50MB/sec stream and displaying it in real time .. that's not a simple task .. you want to display "how much" data, how much data to keep in history .. if you run the LA in throughput mode there's a finite amount of data you can operate with ... I worked with ring buffer in my app iirc so I was storing few hundred MB of data only so oldest data is being lost .. jawi might have some ideas on this but .. Donno how saleae solved it ..
Now I see the "not support mpsse" - the c app could be modified to pipe the data to java .. that's not a too big of a problem, bigger problem is what to do with that stream, most hdd's today can't write at that speed
The Saleae doesn't display it in real time, though maybe you meant process it in real time. The Saleae just sets 1M/10M/100M samples and displays the data 50/50 around the trigger. I assume a ring buffer that holds n samples there too. I think the cypress chip has some basic smarts, so that might be assisting with the trigger.
To design a dedicated device I 100% agree on the FPGA, but I just want to hack something together to see it work :) Just to gauge the feasibility of the toolchain changes. If I can mock it up on the BBv2, then I don't need to do any extra hardware to satisfy my curiosity.
you can for sure mock something up with just a ft2232h break and cpld break ... not sure about bb2 because I'm not sure about all the connections .. will check later today but it might be possible ...
if saleae don't show data real time then I'm dissapointed :D .. I'd like something like "oscilloscope" view of the data from la with real time decoding of some signaling (like rs232, i2c ..)
There is so much blank space in most signals, maybe a live view of only (beginning) of periods of activity would be possible and easier. Eg even if it doesn't match the trigger conditions, the most recent activity can be updated on the graph occasionally. Another nice feature that would be possible and something to try once there was a data connection between the FT2232 and client ;)
All the BBv2 MPSSE1 pins are connected to the CPLD, I can make nearly any routing needed. Loop AC5 back to the sync clock pin through a /2 is no problem, the inputs come in the normal JTAG header..
I don't fear the mpsee pins but the 60mhz output, busy etc etc ...
I have a test core for the CPLD with one 8bit counter, and data hold register. This was supposed to generate test pattern. I also wrote some little test app, that sampled the data and looked at the pattern whether it was ok or not.
But i never got to sync it with the clock, I wasn't able to generate /2 clock inside the cpld - simulation looked ok, but the 2232 didn't sample the data correctly. I guess that with proper clocking it would be manageable :-)
2232 is using the 60MHz clock to sample the signal. Can you use the 60MHz provided by the 2232 to clock the cpld?
well, the clocking is not done on the "global" clock network. The design is suboptimal, as the clock has to pass through the cpld like "ordinary" signal. But it works :-).
You are however limited, as you cannot use the internal clock divider, dual-rate registers, etc...
Back in stock now :)