Skip to main content
Topic: Another programmer (Read 6533 times) previous topic - next topic

Another programmer

These are already out of date, full of errors, steals candy from children, kicks your dog ect...

Now with that disclaimer out of the way, I'm going to attach two patches for "insurance" purposes.

The first:
Is the "least intrusive" version, there are two known issues in this patch
1: There shouldn't be ANY changes in pic.c. You can replace/revert it from the svn repo
2: The related changes in main.c to MEM_Init calls
This patch includes:
Parallax BS2 Firmware with support for pic18(416 mode), pic24 (424 mode), and four-wire pic32
-L(ist) option from the USBASP patches
The few "fixes" for serial port, and maybe some random I don't remember.
[attachment=2]

The second:
Is my complete development branch in all it's glorious randomness...
This includes a 4 wire pic32.c, along with I don't recall what else. So I attach the Changelog from cvs commits.
[attachment=1]
[attachment=0]

I don't have a schematic drawn up sorry
MCLR is pulled low via an NPN
VPP is switched via NPN-PNP from the wall wart
5v to 3v3 Conversion is thru a TXB0104

2-wire connections:
 15 -> Data
 14 -> Clock
 11 -> MCLR
4-wire connections: (These are confused/ing sorry)
 15 -> TDI(to target)
 14 -> TCK
 13 -> TDO (from target)
 12 -> TMS
 11 -> MCLR

Re: Another programmer

Reply #1
Which product or project you're referring?
From the last paragraph I assume it's for programming by PIC-ICSP and JTAG.
But which programmer is this.
Still learning
-Arup

Re: Another programmer

Reply #2
Thanks that did get buried in text..

This adds support for boot strapping PIC's with a Parallax Basicstamp2, using the Bus Pirate PIC Programming software.

The firmware is included in the filetree as PirateProgv6.bs2 it is written in PBASIC

The patch files are generated against the older (pre april ~10th) code(PiratePICprog).  This means there maybe rejects conflicts and other assorted "fun" if applied with robots recent updates.  The 1st patch should apply simply with the recent changes but I have not tried yet, the other I recommend against applying to the current revision.

I guess I got lazy typing after I linked the Changelog..

Note the buspirate -> pic32 does not function.
1. The BP OCD mode uses CS as TMS, but CS is MCLR in PIC mode.  It could be AUX which is VPP in PIC mode, these are easy to set...
in pic32.c
Code: [Select]
#define TMS_h() iface->VPPHigh()
#define TMS_l() iface->VPPLow()
2. iface.h and buspirate.c need a new function Peekbit
Code: [Select]
static uint32_t BP_PeekBit()
{
        uint32_t rval = 0;
        int fd = pBP->fd;
        char buffer[5] = {0};

        buffer[0]=8;//BWCMD_RSC_PEEKBIT

        serial_write(fd, buffer, 1);
        serial_read(fd,(char*) &rval, 1);

        return(rval);
}

Also of note, the "stampIT2" is set to 9600 bps in the software and firmware to prevent data errors. It's configurable in both, however I ran out of space in firmware to implement any form of command buffer and CRC.  So it takes about 8-9 hours to read a mx220, or something crazy long I forgot (YAY) exactly how many.  2-wire 4-phase would make hours into days I fear...

Re: Another programmer

Reply #3
[quote author="AndThen"]2. iface.h and buspirate.c need a new function Peekbit
Code: [Select]
static uint32_t BP_PeekBit()
{
        uint32_t rval = 0;
        int fd = pBP->fd;
        char buffer[5] = {0};

        buffer[0]=8;//BWCMD_RSC_PEEKBIT

        serial_write(fd, buffer, 1);
        serial_read(fd,(char*) &rval, 1);

        return(rval);
}
[/quote]

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.

Re: Another programmer

Reply #4
[quote author="robots"]
This is more of HACKING, as compared to Programming/Designing sw :-)
[/quote]
I didn't design the programming spec or the programming interface, I'm just trying to put them together. :-) So I am OK with that view point. Priorities are functionality, then maintainability, and finally artistry.

[quote author="robots"]
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).
[/quote]
Sure I didn't understand, sorry.  I interpreted this as "You can simply add PIC32Read/PIC32Write to iface like the others" or "Combine the iface, PIC4* functions and test the mode"

[quote author="robots"]
By generic read/write I mean read that can actually read arbitrary register and not only 3consecutive memory spaces (see PIC24).
[/quote]
I have not IIRC explicitly tried reading arbitrary registers. It, the pic32.c:PIC32_Read, should read anything in the 4gig address space including registers.

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?

[quote author="robots"]
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?)
[/quote]
Of course the buspirate doesn't need to have the pic functions but it cuts way down on the communication overhead.  I use the pure bit banging solution for the pic32 because it fit(just barely ~16 bytes free) in the PBASIC firmware alongside the pic18/24 functions.

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.

[quote author="robots"]
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.[/quote]

For the V3x firmware there is about 4.5K. I think pic32 ejtag could fit in this, if it reuses OCD functions almost certainly. There are issues with OCD reuse however, the Peekbit is needed inside of Setmode(OCD tapshft?) to check processor state. The OCD code (IIRC) doesn't allow this.

Re: Another programmer

Reply #5
Quote
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.

Re: Another programmer

Reply #6
Quote
This adds support for boot strapping PIC's with a Parallax Basicstamp2, using the Bus Pirate PIC Programming software

Very cool! Thanks for sharing. If the source is not ready for robots maintained tree, may I pls add it to a contrib folder for safe keeping.
Got a question? Please ask in the forum for the fastest answers.

Re: Another programmer

Reply #7
NOT TESTED, this time it's going to kick the cat...

Updated against svn r1816. Didn't update my Changelog yet, it's not committed to my local cvs.

Added a configuration #ifdef USE_PICDEVICES for the picdevices.h
This has both versions of the pic24 unpack changes, my version is (currently) #ifdef ANDTHEN

Problem areas:
TMS not unified(still stamp specific)
bs2 code needs adapted to r1816 unpack methods
..?(somethings I forget probably)

Sorry there is a big ugly chunk in PIC24_Read that i'll include the start of below. It's still there/ugly because of, the middle "example" not sure how where or why those 01's showed up, gremlins and goblins.
Code: [Select]
//:10000000 11223300 55667700 88991000 11121300 F1
//:10001000 3A870001 3A870001 3A870001 3A870001 D8
//:10001000 3A870000 3A870000 3A870000 3A870000 DC

This patch with none of my defines used(check Makefile), is almost identical to the r1816.