[quote author="AndThen"] Compare with original, "diff -u irtoy_v22.hex read_test.hex", these should differ only on the last two lines where MPLAB puts the configuration data on multiple lines picprog will have them included on one line. [/quote]
You can use the "compare" program to compare 2 files (HEX or BIN).
Could you expand/explain "(see PIC24)"? I'm not sure where I'm being sent. You mean being able to read bytes of a word?
By generic read i mean read that will only read VISI register. PIC24x_READ does little more than that - sends out instructions and reads VISI register, 3 instructions and 3 register reads. (binIO.c in BP firmware)
Quote
The programming executives(PE) are released under the (standard?) Microchip license, the one that says you can only use the software on/with microchip products, and can't be re-distributed. So the license in addition to it(PE32) not working with the (small memory) chips and the time it takes to load (@9600) with all the bit banging, I just kinda of ignored them for this.
PE is just a piece of SW present in PIC, so you don't clock instructions to PIC, just send the High-level commands (write flash + data, read flash, etc)
What is licensed is the piece of SW. But you can always write your own piece of SW and put it in the PE space.
This is more of HACKING, as compared to Programming/Designing sw :-)
The Real solution is to rework the read/write commands together with the Interface definition. Add "generic" interface read/write functions, and setmode to select which pic we are dealing with (already in place).
By generic read/write I mean read that can actually read arbitrary register and not only 3consecutive memory spaces (see PIC24). FW in buspirate doesn't need to "speek" PIC instructions (as does now with the read). Buspirate will only understand the "ICSP" protocol (different ones for different PICs) and the actual programming logic will be inside PiratePICprog. This will also allow for future expansion (PE maybe?)
This will, of course, require changes in the firmware, message queueing in sw (as done for PIC18), etc.
We could also add PIC32 "commands" to the buspirate's FW, and not care about TMS/TDI bit-manipulation on host.
I have just committed changes to the PIC24 protocol. Now reading is supported, and seems to work correctly. (Tested with BPv4 as target - pic24fj256gb106).
if the magnetic reader has rs232 driver on board it will only interface to rs232 and not directly to arduino!. You will probably fry something with 12/-12 volts.
This development cycle is starting to get really messy. To which source should I be adding features ? Right now there are about 3-5 different branches for BPv4 (the one in SVN, JTR's 7 package, xsvf player, etc.)
Could someone merge them into one single project ?
[quote author="JTR"][quote author="ian"]Nice work![/quote] Why thank-you Sir. Thanks for putting me on to Robots loader. The code is so much better to work with than Diolan's. [/quote]