Skip to main content
Topic: Bus Pirate PIC 24F Programmer Dev Thread (Read 45011 times) previous topic - next topic

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #45
Followed the steps, it worked, had a few scares.  Sjaak, are you going to pick up the new rawmode in new term, so I can have both?  I miss my newterm:-(

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #46
Off course. You can speed it up by sending money ;)

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #47
Thanks for the reports guys, I'm gad it's working.

Actually Sjaak has some better handling for this stuff in the newterm branch, though we need to reconcile some things because the features of raw2wire are still needed for various weird things (hold data high at end of last write command, for example). Perhaps merging the newterm PIC commands (4/6 commands + data) into rawwire.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #48
[quote author="Sjaak"]
Off course. You can speed it up by sending money ;)
[/quote]
But all my money is gone for wonderful new toys like this one.  I was just giving feedback on the things I noticed and the bootloader is very slow.  I am debating whether to leave the nightly on so I could help someone if necessary or going back to newterm so I can use it.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #49
[quote author="rhyde"]
[quote author="Sjaak"]
Off course. You can speed it up by sending money ;)
[/quote]
But all my money is gone for wonderful new toys like this one.  I was just giving feedback on the things I noticed and the bootloader is very slow.  I am debating whether to leave the nightly on so I could help someone if necessary or going back to newterm so I can use it.
[/quote]

I wasn't serious when writing this. Sorry to offend anyone.

There is no reason to stick to the nightly if you don't want. (also no reason to switch back to newterm!) You must flash the version you want (or change when necessary) Flashing the BP takes only 10-20s so its quick. If you find tthis slow, please go back to the old bootloader at 9600 baud. ;)

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #50
Is it the OLS bootloader that's slow? How slow is it for you? FOr me it takes well under a minute, but not nearly as fast as the same bootloader in the USB IR Toy (seconds).

The problem is that the 18F24J50 has two write modes: 2bytes and 64bytes. A USB HID packet can only contain 64bytes, so once the header is included there's no room for a full page of data. What I did was convert the bootloader and the application to use the 2byte write mode. This is much slower than the original bootloader because only 2bytes go per packet (instead of 32 with the 18F2550 version). The eventual solution is to send 64bytes of page data over two packets, and set a write/flush flag on the second. The bootloader firmware actually already supports this, but I'm not much of a desktop programmer so I stopped with my first mods.

You can switch back to newterm as needed. We can also add the new command to the newterm binmode. It's just one function here:
http://code.google.com/p/the-bus-pirate ... wire.c#164

Thanks again for the upgrade reports. Admittedly it's a huge upgrade chain (BP, bootloader, firmware, ROM, etc). It's really encouraging that the first two upgrade seem to have been successful.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #51
A note about USB: At the lowest level, certain types of endpoints are indeed limited to 64-byte packets. However, the same limitation is not present at higher levels. Both ends (host and device) understand that sending more than 64 bytes requires a sequence of as many 64-byte-packets as possible, followed by a 'short' packet that is 0 to 63 bytes to signal the end.

When programming the PIC, I believe that the USB library hides this detail from you. I wrote a USB Device Firmware Upgrade (DFU) firmware which works over USB with simple Control endpoint transfers. My PIC has the ability to write 1024 bytes, so I structured my DFU code to send 1024 bytes over USB in each step. My Mac client program made a single call for 1024 bytes, and my PIC firmware received 1024 bytes, but meanwhile the OSX USB drivers and the Microchip USB stack automatically dealt with the low level details of breaking this 1024-byte request into multiple 64-byte packets as needed. I didn't have to worry about that detail.

In other words, you could speed up your 18F24J50 FlashBurn by switching back to the 64-byte transfer, so long as you have full USB support. I can't remember whether you're using the Microchip USB library or a third-party solution, but either way this should be a very basic feature of USB.

P.S. For endpoints that have 32, 16, or 8 byte maximums, the process is the same. Maximum length packets are sent until the final packet which is shorter than the maximum, or 0 if the transfer divides evenly into the max length.

 

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #52
We're using a modified version of the Diolan USB HID bootloader, written in ASM. It uses raw 64byte HID packets. As far as I know, it does not currently support transparently breaking apart large data transfers into smaller packets. I could be totally misunderstanding how it works though.

Before I dug into the guts of the utility and firmware to get it working, I just modified the data length and tried to send larger packets without success. I did leave a way to break larger transfers into smaller chunks so something similar to what you described is already supported by the current firmware. I've just not updated the PC to support this yet.

Ultimately, I'd like to port the LUFA open source USB CDC-serial (ACM) stack and CDC-serial bootloader to the OLS (and PIC in general). The Windows application for HID transfers requires a massive amount of system setup to compile, and it has a huge number of source files for a simple console app. I really prefer simple serial bootlaoders because the apps are easy to write, and bootloaders can be made in scripting languages like Perl and Python.

http://www.fourwalledcubicle.com/LUFA.php
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #53
[quote author="ian"]
You can switch back to newterm as needed. We can also add the new command to the newterm binmode. It's just one function here:
http://code.google.com/p/the-bus-pirate ... wire.c#164
[/quote]

I added it to newterm for now to keep up with the normal release. It is in the other topic ( http://dangerousprototypes.com/forum/in ... opic=291.0 )

BTW: should the reply to 0x01 (get id) not RAW2 instead of RAW1? I know the first concern is to help the people and get most of the OLS's (OLSes?) into working order.
BTW2: forgot to add something (0x4x) to the svn? :P

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #54
Yeah, that's probably a good idea to up the number. Thanks for adding it v5. I'll cross it off the list on the other thread.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #55
We should just have one reply to the entire PIC command of three bytes to speed up the time between bus writes.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #56
[quote author="ian"]We're using a modified version of the Diolan USB HID bootloader, written in ASM. It uses raw 64byte HID packets. As far as I know, it does not currently support transparently breaking apart large data transfers into smaller packets. I could be totally misunderstanding how it works though.[/quote]I got the impression from reading the USB spec that this is required. I suppose that still doesn't guarantee that Diolan implemented it. The feature would certainly be at a higher level, because individual packets are limited in length. Perhaps HID never allows more than 64, and so Diolan skipped the higher-level feature altogether. Something like Microchip's USB stack, which must support more than just HID, handles this for you. Then again, even Microchip has a separate bootloader implementation of their USB stack, and it is stripped down.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #57
The upload to the OLS once the bp had loaded the bootloader on it was extremely slow.  The progress print out incremented, but so slowly I was wondering if it was working.  (That is why I mentioned it, as it could cause someone to abort.)  I mean more than a couple of minutes I would say 5 to 10 seconds a chunk is what I observed.  It was not intolerable, but it was as I said slow enough I was worried it was not working.  The BP upload was not blindingly fast, but it was not ridiculously slow.  It was about what I expected, probably output limited on the display.  The OLS bootloader was the one that was very slow.  I do not know how big the the pic image is, but those things do not have that much memory, and it was slow enough it could have been timeouts IMHO.  Fortunately it was not.

(Sjaak, I was just kidding back.  I am not one to take offense.)

[quote author="ian"]
Is it the OLS bootloader that's slow? How slow is it for you? FOr me it takes well under a minute, but not nearly as fast as the same bootloader in the USB IR Toy (seconds).

The problem is that the 18F24J50 has two write modes: 2bytes and 64bytes. A USB HID packet can only contain 64bytes, so once the header is included there's no room for a full page of data. What I did was convert the bootloader and the application to use the 2byte write mode. This is much slower than the original bootloader because only 2bytes go per packet (instead of 32 with the 18F2550 version). The eventual solution is to send 64bytes of page data over two packets, and set a write/flush flag on the second. The bootloader firmware actually already supports this, but I'm not much of a desktop programmer so I stopped with my first mods.

You can switch back to newterm as needed. We can also add the new command to the newterm binmode. It's just one function here:
http://code.google.com/p/the-bus-pirate ... wire.c#164

Thanks again for the upgrade reports. Admittedly it's a huge upgrade chain (BP, bootloader, firmware, ROM, etc). It's really encouraging that the first two upgrade seem to have been successful.
[/quote]

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #58
The way to write a pic18f or pic24f is different then the lowerend pic. You need to send a lot bytes just to programm one programword. With the lower end it is just 3/4 bytes to program just one programword.

The icsp is just pratical for uploading a bootloader. Suppose you need to upload 256Kb ;) zz.. ..zzZZzzZzZZZz

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #59
Quote
I do not know how big the the pic image is, but those things do not have that much memory, and it was slow enough it could have been timeouts IMHO.

This chip especially is tiny (4K words, 8Kbytes), and we only program a small portion with the current firmware.

Just in case, here is a screencast of my update process. Is it comparable to your speed? Actually timing it with the recorder I can see it's only about 20 seconds, that's a lot less than what you're reporting. I wonder if it's a bug somewhere.

http://www.whereisian.com/files/ols-bootloader.swf
Got a question? Please ask in the forum for the fastest answers.