I'm putting together a collection of circuits for the PIC programmer 13volt VPP supply.
I'm going to prototype a charge pump and a boost converter. The boost converter will be able to make lots of voltages, up to hundreds of volts, but I plan to clamp it at <20 with a zener. I'm also going to try making the boost converter with a BC547 transistor instead of a FET, because the PIC is only 3.3volts and most FETS want 5v for full-on.
I'm currently investigating whether it is possible to do some reverse engineering with the help of the Bus Pirate. Basically, we need to correlate an USB data stream (PC to undocumented device) with a SPI data stream (undocumented device to documented SPI flash chip). I'm not sure whether the undocumented device is just a stupid SPI master which receives SPI commands over USB and passes them through or whether it actually has builtin "intelligence". Dumping the USB data stream is already taken care of, so only the SPI data stream remains, and for that we'd like to use the Bus Pirate.
Some things about the Bus Pirate SPI sniffer mode remain unclear, though:
The I2C and SPI sniffers now use a 4096byte output ring buffer. Sniffer output goes into the ring buffer and gets pushed to the PC when the UART is free. This should eliminate problems with dropped bytes, regardless of UART speed or display mode. A long enough stream of data will eventually overtake the buffer, after which new bytes will be dropped until space is available.[...]
Both sniffers use the user input buffer as a ring buffer. Any commands entered after the sniffer macro will be lost. If the ring buffer is full, bytes are simply dropped until thereâ€™s free space. The MODE LED turns off if this happens.
Since I want to correlate logs, dropped data is a problem, made more severe by the fact that there will be an almost sustained (that is, there will be a delay in the order of microseconds after each 260-byte communication chunk) data rate of 10 Mbit/s in each direction (MISO+MOSI) with a total length of ~2 MByte per direction. That means I will overrun the 4096 byte ring buffer easily.
After that, will the Bus Pirate empty and fill the ring buffer bytewise and thus end up with a random selection of bytes from the stream being filled in to the freed byte(s) in the ring buffer each time one byte becomes free in the ring buffer? Such a random selection would mean anything past the first 4096 bytes is unusable as trace. OTOH, if the ring buffer is emptied in n-byte chunks (preferably larger than 260) the chunks are still useful.
It seems the MODE LED is the only indicator of a buffer overrun and there is no way to detect such a condition from the Bus Pirate output on the virtual serial port. That makes finding the chunk boundary impossible AFAICS.
I've been playing with mingw for a updated PIC programmer, cross platform, console app. I started by compiling the pirate-loader.c for the v4 bootloader - it's a simple single file with all the components needed (HEX parsing, serial coms, etc). In the source it looks like Piotr made POSIX-compatible read, write, close, and open, functions for windows. When I compile with MinGW I get an error that write, read, and open are already defined in io.h (I guess it already has posix substitutes?). I commented out the version in io.h and it compiles and works fine (I tried removing the version in the app, but it didn't work right, opening serial port error). This doesn't seem like an ideal solution. Does anyone have any suggestions? Here's the prototypes for the functions:
From pirate-loader.c: int write(int fd, const void* buf, int len) int read(int fd, void* buf, int len) int open(const char* path, unsigned long flags)
From MinGW io.h: //_CRTIMP int __cdecl __MINGW_NOTHROW write (int, const void*, unsigned int); //_CRTIMP int __cdecl __MINGW_NOTHROW read (int, void*, unsigned int); //_CRTIMP int __cdecl __MINGW_NOTHROW open (const char*, int, ...);