I got my BPv4 some time ago and unfortunately I don't get around using it much because my V3.Xes lay on my bench anyway. Long sotry short, I updated to the 6.1 firmware release today (which was successful) and tried to use the BP with my Win7 PC (32bit win on 64 bit AMD). After installing the supplied .inf-file (using device manager > update driver), Windows is showing me a COM12 named Bus Pirate v4 in device manager. I can also successfully connect to the COM-port, but no matter what I send to it in no matter which baud rate (115200 also ;) ) with no matter which CR or LF or both, it does not respond in any way.
Using my Android 4.? Tablet it works like a charm...
So i suppose it is a Problem with my PC (or the USB-stack of the BP??). I tried both Putty and hTerm with no luck at all. Maybe there is a fix which I didn't find? I tried the 6.2 beta1 firmware out of the forum but that one doesn't work at all, the USB LED is on all the time and Win7 is telling me to connect it to a USB 2.0 port (wtf?). So I downgraded to 6.1 again...
I would really appreciate some help, thanks in advance, Tobi DK7SCH
@ian the testing procedure of the mikrocontroller.net tester is really straightforward! I was amazed how simple it is. It is as a matter of fact a organized way of "Let's apply voltage to some of the pins and see what happens...".
Sure; because I'm a german native, it is quite easy for me to understand the (great) article on the hardware and algorithm... http://www.mikrocontroller.net/articles ... stortester which is (I think) a little budgy when you get a machine translate..).
I see your point but LiPoly cells can be quite dangerous. Plus you need special charging circuits, voltage monitors, high impedance on-off switches etc. I think with a solid 9V cell as suggested or some other kind of 'normal' battery (maybe 2 or 3 AAA [eneloop] cells - maybe on the backside of the PCB - or whatever) you're on the safe side, even when it's more expensive.
I really like the component tester/superprobe idea, which would really make a great tool. However I think it would be wrong to include a breadboard area and or make the device non-standalone. It might be OK to have a non-standalone logic analyzer or a USB scope but when it comes to component testing or taking live measurements I think nothing is more annoying than having to click some kind of button on a computer screen.
I think the DCA-tester is such a handy tool because it is small, standalone and has only 2 buttons and 3 leads. Sure enough a tester/multiprobe gadget would need more buttons and some leads more but I like the general paradigm.
As for the display, graphic OLEDs are in fact dirt cheap; and could be controlled over a on-chip (parallel) memory interface (which would save space). But, as we saw, a normal alphanumeric LCD is sufficient (however I think the OLED version would be cheaper..).
The DCA meter seems to be powered from one of these 12V-batteries, which means we could try a CR2032/step-up power supply (CR2032s are dirt cheap, too).
As for other features such as a waveform generator or even an arbitrary wave gen (using I²C DAC), they were in fact nice to have, but they would complicate the project and make it a never ending story. It might be a great idea to add expansion capability though (such as an open I²C interface and or SPI) to later add things such as an arb (you need more firmwarespace then). An additional PC interface (firmware USB stack??) might in fact be useful, but should not be obligatory.
Once again I love the idea of a DP component tester Prototype :)
So that would prove that 5.10 and 5.9 do not come with jtag. ...or am I wrong?
... I would pay 80€ for that tool. (even more if you would implement AVR-ISP MK2 functionality... ;) ) And... think what you could do with a Buspirate and a CPLD / FPGA... Should I post this on the idea / suggestion forums?
Hm I got the latest 5.10-package from sourceforge... Could you post a compile with uncommented jtag for testing? Maybe like a 5.10+ -Version? I am not into pics and thus I don't have any compilers...
I keep testing my buspirate/LPC2138-Setup here - seems like I messed up my cable...
@Ian ... What do you think about combining the Buspirate and the Busblaster (v2) to some kind of Superblaster? (-> but keeping them as seperate products too) You could use the 2. FT2232-Output as uart-bridge and it would bring the benefits of both tools - versatility from the pirate and speed from the ft2232. I like the buspirate as much as my trusty usbProg but they both have the same problem: When it comes to JTAG-programming/debugging they are dead slow. Just an idea... ;)
I loaded your firmware (ver. 6 according to the i-option), for which my fresh-out-of-the-oven cygwin-openocd has the following to say: [attachment=0] (with no target connected) (seems like it would work)
When I try the actual 5.10-Version I get the same error as I got above, which would imply that there is no jtag-support on 5.10 (and on 5.9-extras which I tested as well).
I have a similar problem - I got the openOCD 0.5-dev sources via git and compiled it with --enable-buspirate - which worked. OpenOCD can connect to the buspirate (as a test - without hardware config file, because I haven't found a suitable (and working) one yet - LPC2138). But then openOCD quits maybe 5 seconds later...
Error: Buspirate error. Is is binary//OpenOCD support enabled?
When I start openOCD the buspirate's MODE-LED turns on. I use the 5.10-BP-Firmware with a custom openOCD compile on a virtual (and thus extremely slow) Ubuntu 10.10-install on a WinXP-Host (using VirualBox). I tried this as a workaround of the Windows-problem; but since openOCD has a network-interface, it should work....
The question is: Is this error a result of the lacking device-spec or is there some more serious issue?
-> I changed the port-spec in the buspirate-conf-file to /dev/ttyUSB0, which corresponds to the buspirates usb/uart-bridge. What is not working is the vreg-setting, as far as I tested this.
The buspirate/openOCD explanations and tutorials are extremely weak; maybe some of you pros out there should write a wiki page? - I would really really appreciate that :)
I'll keep trying... Tobi
[EDIT] I got a halfway working device config file ... output is now:
tobi@tobi-VirtualBox:~$ openocd -f buspirate.cfg -f lpc2138.cfg Open On-Chip Debugger 0.5.0-dev-00783-g0123985 (2011-03-07-23:25) Licensed under GNU GPL v2 For bug reports, read http://openocd.berlios.de/doc/doxygen/bugs.html Warn : Adapter driver 'buspirate' did not declare which transports it allows; assuming legacy JTAG-only Info : only one transport option; autoselect 'jtag' srst_only separate srst_gates_jtag srst_open_drain trst_and_srst srst_pulls_trst srst_gates_jtag trst_push_pull srst_open_drain adapter_nsrst_delay: 100 jtag_ntrst_delay: 100 Warn : use 'lpc2138.cpu' as target identifier, not '0' dcc downloads are enabled fast memory access is enabled Error: Error reading data Error: Buspirate error. Is is binary//OpenOCD support enabled? tobi@tobi-VirtualBox:~$
Sorry, I forgot the reading error earlier...
I doubt it is the config... Might be a device handthrough problem... but the mode-led lights up as soon as I hit return...
I do have a very similar problem, I tried to upgrade the PIC-Firmware to 2.6 using the new shiny GUI updater (ols_winloader.exe). It told me that it would now perform the update then it said something about "fail" and now the Sniffer is not enumerating on USB. (Sniffer is passive, only the Power-LED is on). I think the Firmware is broken; so a manual flash would be indicated (?).
@ian... Do you think I can wait for the BusBlaster v2 or should I head for a Bus Pirate to solve this problem?
I noticed that there exist several firmwares / bitsreams for different features. As rsdio mentioned I thought of a manual firmware selection menu.
Thanks a lot ian for updating the wiki - it really helps to see which firmwares are availabele and which features they include. I see your point with the serial/USB connection; that is a little bulky when it comes to writing (and using) an upgrade tool. But as I see it there is already software for both of the tasks; so why not compiling them together? Sure it would be a hack but ... Well another problem that I see is - where and how does the update-software get its overview of availabele firmwares / bitstreams from?
To cut a long story short. I just thought it would be great if there was an easy way of choosing firmware. It could even be a web application. Something that lets you choose (and download) the (one single) firmware and keeps you from scrolling through the files of an update package. The wiki was an important step in this direction
I got my sniffer a few weeks before and I am pretty impressed. It is a really neat tool but I think there are some issues (I've searched but havent found anything so I hope I'm not preaching to the choir):
1) Firmware updates are a mess: I wanted to use the new 2.12 test release. To do so I noticed (!) that I had a completely old PIC-firmware. So I wanted to update it but as a matter of fact it turned out that this isn't quite ... intuitive. I needed to do the following things: a) search for actual (stable) firmware image b) search for update how-to c) find the right firmware in the bunch of files d) run update script (that was easy) Wouldn't it be nice if there was a tool which automatically checked the sniffer firmware and bitstream version and compared it to the latest available files online? And then automatically updates the sniffer? Just like apt? And/or in which you could choose which bitstream you wanted to use? What do you think?
2) Now I'm using the v06-16MHz firmware with the 2.12 bitstream. It works really nice on my XP machine but I noticed when I use really slow sample frequencies (like 1kHz) the shiffer captures data but the client runs the capturing-progress-bar when the capturing has finished. Is that on purpose or is it not? I thought the bar was indicating capturing progress...
