FYI I made some measures with the Bus Pirate frequencemeter.
Here are some tests on a XTal of 4MHz:
Displayed frequencies are always a multiple of 256 (this is the prescaler artefact) There is a temperature drift: o <9 degres Celcius: 4,001,280 Hz (too cold for my IR medical thermometer) o 9.5 degres Celcius: 4,003,072 Hz to 4,003,328 Hz o 17.5 degres Celcius: 4,004,352 Hz to 4,004,864 Hz o 26.5 degres Celcius: 4,006,912 Hz to 4,007,424 Hz o 33.5 degres Celcius: 4,009,728 Hz to 4,009,984 Hz
So at most 0.25% of error, not that bad While PIC24f datasheet announces for Fosc intern (8MHz): +-2% @25deg, +-5% @full range (cf also the datasheet page attached in one of the posts above) There is also apparently possibility to use a compensation register in the PIC: "OSCTUN"
For comparison I tried also with an Arduino (which has a real 16MHz XTal, 25deg): * 3,999,920 Hz without calibration * 3,999,998 Hz with calibration
I did an alternative for Bus Pirate v3, inspired by Tayken. Some characteristics: * Corrected UART pinouts * Color codes in separate column for better readability of labels * Reordered rows to match physical ordering of flat cable * Shows alternative color for +5V: orange or pink depending on the flat ribbon you have
I don't' know why bridge mode doesn't work, see Ian's comment, but there could be an explanation why you get dropped bytes in your live display test: For each byte received bus pirate is displaying sth like 11 or 12 bytes: "READ: 0x0Dn" So live display "[" can only reliably work if the input rate is much lower than 115200 (either by getting seldom bytes at 115200 or by getting bursts at lower baudrate) So apparently the bug is around the bridge mode, not in your physical setup...
> I'm not sure about the specific FPGA we use, but some allow this. It would work to hold them high (if it won't kill the circuit) or low on the unbuffered IOs. The buffered IOs would need to be grounded from the outward facing side (the buffer inputs), or there will still be undefined states driving the pin via the buffer inputs. > Out of curiosity - anyone know how other logic analyzers do this? A very gentle pull-down (1Mohm, for example)?
When I said virtually grounding I was more thinking of ignoring purely and simply the input on those probes, similar to disabling a whole group we could disable separate probes (but still send "empty" data to SUMP for compatibility reasons. No need to physically ground them.
Just an idea now that we have "plenty" of additional I/O: Why not having a second group of same I/O to be able to be e.g. man-in-the-middle on a bus and relay or change on the fly the data? So we could not only "sniff" or "speak" but also "alter" bus communication. Fits as "pirate" spirit isn't it? ;-)
Since RLE is compressing signals, it's better to ground unused probes of the same group rather that RLE being busy recording noise, right? We could then free some recording space. Next step: could we virtually ground unused PINs by sending a (new) command to the logic sniffer?
Try command "[" for continuous reading, see if you can get the bytes and if they're ok or with frame errors which would indicate a wrong bitrate. There is also some confusion with two opposite conventions for pin-color matching, see http://dangerousprototypes.com/docs/Com ... le_pinouts Maybe you swapped GND & MISO?
You (Linux & Mac users) don't need pirate-loader 1.02 with the delivered 5.10 firmware as it's using uppercases. It's only an issue if you create your own fw with MPLAB X.
Here are some numbers just to get an idea (using MPLABX), compiling all modules * -: does not fit * -O1: 195924 * -O2: 214052 * -O3: does not fit * -O4: does not fit * -O5: does not fit * -Os: 181508
So we can live with -O1 for a while... I still hope that new MPLABX gcc can be used more freely... at least I don't thing there is any limitation in the beta version.
I guess it's only a limitation of the IDE, do you know if it's still possible to use the option directly for pic30-gcc? In that case we would need a separate Makefile... Pfff I hate this non-free mentality.
