I have a Sparkfun, SEEED, and two Adafruit 3.6 bus pirates. I usually have multiple irons in the fire, and multiple BPs hooked up to them.
The other day I could have used a second AUX pin to toggle RST on a device under test. I know the BP4 has 2 extra AUX pins but I already have multiple version 3 BPs. I downloaded the 6.1 source and looked at the BP4 interface and how the extra AUX pins are controlled. The interface and code looks pretty straight forward.
Looking at the BP 3.6 the AUX pin is straight out of the processor, no external pullup. The AUX pin is a 3.3v pin 5v tolerant. The AUX pin comes off of RB10.
The ICSP header is pinned out and includes PGC and PGD. PGC and PGD are RB1 and RB0. They come straight off of the processor, just like the existing AUX pin, they are 3.3v but NOT 5v tolerant.
What do you think about using the PGC/PGD (RB1/RB0) pins as additional AUX pins on the BP 3.6?
As long as I stick with 3.3v interfacing, which more and more of my work is tending to, I should be safe.
Has anyone already done this? No sense reinventing the wheel.
I would keep the same cA/kA syntax as in BP4.
I see hints that the PB3.6 is code size limited. It doesn't look like a lot more code but am I going to run into problems trying to fit it in?
I am able to build the 6.1 source using the Microchip XC16 (v1.22) compiler and I get program space at 92% and data space at 66%.
In terms of data depth I agree that less is more. In fact 256k bits is bordering on too much to be useful.
Being able to trigger properly (complex triggers) and then a little pre and a little post data is what I have found to be most useful. Wading through megabits of trace is seldom productive, in fact in 30 years of doing this stuff I personally have never found more than a few k bits around a trigger to be useful.
I am curious, for those who want deep trace memory, what is your application? Serial data stream analysis? What else? Seriously, who walks through megabits of multi channel deep trace? Do you just grab a huge trace and then use a post processing program to search for events or triggers?
I can work the Java side. I assume we are talking about using Jawi's OLS client? I've downloaded the source and poked around a bit. I have not built it but that could be a project for this weekend.
I could also kick off a standalone java client to get something up and running until it can be integrated into an existing client.
The shrimp page says you are using a subset of the SUMP protocol to get the data capture out. Are you thinking to use the SUMP data transfer in reverse to get the pattern down to the shrimp or are you thinking a whole new transfer protocol?