I tried the programmer successfully with the Windows version of Python 2.x.
You ignore the bootloader area, what a nice touch, the Microchip programmer doesn't have this option.
The first two bytes gave an error, but I assume this is because the bootloader modifies the start address.
I also got verify failures at c04, c05, c06, a8f8, a8f9, a8fa, a8fc, a8fd, and a8fe.
Firmware seemed to work OK. I didn't remove the jumper, is this a problem? It went into the firmware just fine with the jumper attached. I can tweak the bootloader or firmware if this is causing an issue.
The update seems a bit slow. I used 115200bps, which works fine on my PIC, and it seemed to take longer than normal. There was much less frequent traffic, the TX LED was only on intermittently, instead of constantly as with the Microchip programmer utility.
I'm writing a guide for the Python programmer now. Is your serial port on Linux specified as /dev/ttySx? Do you know what it should look like for a Mac?
Can we change the name to P24qp.py to be consistent with the existing programmer?
Config words appear to be correct, save some endianness (from MPLAB): @ABFC = F9DF @ABFE = 3F7F
I also started a new topic to discuss the hardware I2C mode you PMed me about. There's already code for it, but I was never able to test it because I only had REV3 silicone.
I used the free MS Windows Portmon utility to get a full debug dump of the serial traffic. The virtual serial port monitor I used didn't echo back the local traffic, only the serial port traffic. I held this up by posting bad dumps, and I'm really sorry. Now we can really see what's going on. I also attached this as an archive too.
I'm doing some new dumps, they look exactly like the old ones. It looks like the serial splitter isn't echoing the data from the local application into the other local apps. I need to find a new way to dump the traffic, I think the previous dumps only show what the PIC echoes back to the application.
While I work on dumping the traffic, does the source to the quick programmer .dll help? The PICBOOT.h defines all the commands:
****************************************************************************/ INT APIENTRY ErasePIC(HANDLE hComPort, DWORD PICAddr, BYTE nBlock, BYTE nRetry) { BYTE InData[MAX_PACKET]; //Allocate for one packet INT RetStatus;
Thank you, a patch would be great, or you can have SVN access (send me an e-mail addy that's registered with google). Peter's actually maintaining the python QP code, I only have a passing familiarity with Python.
Looking at your break-down of my dumps, the "sequence to start the bootloader" is actually the output of the firmware after it boots. Great catch, I didn't pay any attention. I bet that's causing a problem because it's certainly not correct.
Do you want dumps that show who said what? A text file with a full, 100% log of a programming session? Do you have a favorite snooper utility? I'll be happy to provide anything I can.
For the bootloader - one pin is twiddled, the other watches for a match. If there are accidental matches, the jumper can be moved over one position to ground the watching (input) pin. If I swap them, then the firmware has to swap which pin get's twiddled and which is an input, or moving the jumper shorts the output pin to ground. For the new POST mode, the inner pin will need to be taken high, which will generate a mismatch in the bootloader and trigger the power-on self-test mode for quality control (QC will be automated in the future).
You said you tried a 1K resistor, so that obviously isn't it. My new post has the 1-Wire demo re-done for the Bus Pirate 2go. I included the complete terminal output so you can see everything I did. I can verify that the v2 firmware 1-wire library can work with the DS2431, but that doesn't mean you didn't find another problem.
It's strange that the PIC wouldn't even connect to the programmer. Did you see how it had failed? Seeed did two tests on each unit before it left the factory, it's worrying if the minor stress of shipping is breaking a lot of connections.
At Hack a Day I had to kick out projects cheap and fast, so it was advantageous to the same chip over and over.
The 16bit PICs (24F-ds33) are great, so much easier to work with than the 8bit 18F series. 8K SRAM, 64K program space, twice as fast, and only a few dollars. Also full speed operation at 3volts.
The 28pin SOIC package is a good first surface mount chip for a timid solder, and it's easy to prototype on homemade PCBs (I make 99% of my own PCBs).
I didn't use a USB PIC for several reasons. First, Microchip's USB stack would have to be licensed separately from the rest of the Bus Pirate code because it's not public domain. Second, the USB stack uses a cooperative multi-tasking system that would take some major changes to the Bus Pirate code to implement and make development harder for beginners. Third, when you're using a USB PIC during development, the USB disconnects any time you hit a breakpoint in the code, so you have to do a full reset and reconnect every time. Fourth, it would have meant changing PICs and code right before I manufactured a product for the first time, which is a bit scary, the existing Bus Pirate design was well proven. Fifth, I believe the price difference was negligible once the extra PCB space and larger chip costs were taken into account. Finally, the FTDI driver is so well known and support, it was difficult not to choose it.
Great question. I was expecting someone to ask this on the original article.
