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

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #60
No that video is 10x the speed I had.  I will have to do it again with a stop watch or timer going.  I would not have mentioned that speed.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #61
@rhyde - thanks for the update. Maybe it's a bug we can work out.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #62
I have used the bootloader repeatedly during tests with the prototypes (before the preorder OLSs shipped) and with preorder OLSs and found the process rather slow myself. So I repeated loading OLSv1-firmware-v06-20MHz.hex with the bootloader again:

Here is the "stop watch timer":



20,18 sec ... while the progress counter was steadily increasing ... a few percent per second. This is about the same speed I get with the BP v4 bootloader ...  however, the total upload time for the BP firmware (v4.5) is about 10 times longer as it is roughly 10 times the size of the OLS firmware v06 (hex files: OLS 24 KB - Bus Pirate 237 KB)

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

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #63
It looks like Ipenguin had something similar to me, much less than 5-10second/chunk (8-10minutes?). No matter the cause, the situation would be vastly improved by sending more data per USB packet.

Do you have another device on the USB bus that takes priority and generates a lot of traffic - a USB sound device (speakers or headphones) maybe?

My current plan is to build a new, 'standard' bootloader based on serial protocol so the app is easier to work with. We're working on the teensy USB stack in another thread.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #64
There's a new package at google code with executable and source for the latest version. It's .net but also targeted to linux/mono, so it should work there too. It includes the HEX parser. It can ID, erase, and program the 18f24j50, with lots of testing completed successfully. It also has 18F and 24F script modes for debugging/prototyping other chip protocols.

http://code.google.com/p/the-bus-pirate ... UN2010.zip

I'll post an OLS rescue package and instructions next.

Getting the project started and the OLS rescue out was the most important goal so far. Now that a couple of us have an idea of the scope of a PIC programming app, we should try to regroup a little.

I'm stuck between continuing to use a raw2wire-based programmer, or implementing a PIC mode. I added a 4/16bit extension to the current nightly firmware, but maybe this should be planned a little better. Maybe it would be easiest to use the usbPICprog source as a mode or separate firmware, even if we have to write our own serial application. znanev has worked with the usbpicprog source lately, I'll ask if they have any thoughts.

What about moving future development to ming or something and make a console application? It would be a lot more portable, and use open source tools.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #65
My suggestion is this: Don't forget those of us who have an actual PICkit programmer.  So far, I haven't needed to change any firmware, but when I looked into the IR Toy update, I couldn't find a single firmware image that was ready for the PICkit.  There were options for USB programming, but even those seemed incompatible with each other (I found several images).

I'm not sure what to suggest, since it can be difficult to mix PICkit programming and USB programming, but I'm merely suggesting that you consider those of us who have the equipment for full-speed programming.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #66
There are several ways to go:

- Port the usbpicprog to a (seperate) firmware.
- Extend the current app with some scripting for lower end pics.
- write a new app (preferable in C/C++ to make it (more) platformindependable).

I prefer one of the last two options; The Buspirate is ment to be a all-round swiss army knife. This way the most options (without ruling out others) are in just one firmware and (also important) one codebase ;)

I think there is need for a special binmode since it is a strict protocol (see the timing issues some people expirience). On the other hand the rawwire could profit of sending multiple bits/byte in one go (there was a discussion about that in the newterm topic (?) some time ago).

@rsdio: the buspirate makes electronics reachable/understandable for the masses. It is ok for people who want to occasional program a chip.

I don't have a PICkit (yet) but I guess the .hex can be directly uploaded by the PICkit?

Edit: post 500!!!  \o o/ o//

 Sjaak gave you a virtual drink.. Enjoy!

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #67
Quote
So far, I haven't needed to change any firmware, but when I looked into the IR Toy update, I couldn't find a single firmware image that was ready for the PICkit.

The IR Toy firmware is ready to program into the chip without a bootloader, it works either way. The bootload-able firmware contains jump instructions at the 0x8 and 0x18 interrupt vectors that redirect them to the relocated vectors in the firmware. This is not true of the Bus Pirate (yet...) but it is the case with the IR Toy, OLS, and Flash Destroyer. This 'feature' is actually what caused the bootloader-less OLSes to go unnoticed.
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #68
Congrats on 500 posts!
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #69
;D :D :D ;D

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #70
[quote author="ian"]
The IR Toy firmware is ready to program into the chip without a bootloader, it works either way. The bootload-able firmware contains jump instructions at the 0x8 and 0x18 interrupt vectors that redirect them to the relocated vectors in the firmware. This is not true of the Bus Pirate (yet...) but it is the case with the IR Toy, OLS, and Flash Destroyer. This 'feature' is actually what caused the bootloader-less OLSes to go unnoticed.
[/quote]
I'm probably being too picky, but what you describe would remove the ability to upgrade the firmware via USB, wouldn't it?  I was hoping for a way to program both the USB bootloader and the new firmware together.  I guess you could say that I want my cake and to eat it, too.  I did not want to end up with a bootloader-less IR Toy, because I might be off somewhere with my laptop and no PICkit.

I'm not saying there is an easy fix for this.  I tried manually merging the IR Toy bootloader image with the upgraded firmware, by staring at the raw hex (and using a hex disassembler that I wrote), but there were some incompatibilities.

@Sjaak: Of course you guys are all doing great work to support people without the PICkit or similar commercial programmers.  I think it's awesome that DP makes the BP and it can program the other DP products.  All that I am suggesting is that this effort not end up making regular fast programming any harder.  I guess that means coming up with procedures for combining the bootloader and firmware updates so that the programmer can maintain both of them instead of erasing the bootloader during an upgrade.

One thing to keep in mind is that the programmers seem to always erase the entire Flash.  In contrast, the bootloader can erase some blocks and leave other blocks untouched.  That makes it a challenge.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #71
Quote
...would remove the ability to upgrade the firmware via USB, wouldn't it?

I see, yes, programming the firmware directly like that does erase and remove the bootloader.

Quote
I was hoping for a way to program both the USB bootloader and the new firmware together.

This should be totally possible. I'm not sure of the .HEX foo required to to merge the files, but I provide a dump to Seeed with bootloader+firmware in one, for example, so it's possible to build an all-in-one. The problem might be that it doesn't play well with the bootloader then because certain vectors are already relocated, but if the bootloader PC program was smart enough to ignore the bootloader section, then maybe that can be worked out too.

On a related note: I've never been able to find a good open source intel .HEX editor, does anyone know of one? (not a HEX editor that shows the values in any file, but one that loads intel HEX and displays it. maybe allows editing, and resaves with updated checksums)
Got a question? Please ask in the forum for the fastest answers.

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #72
[quote author="ian"]On a related note: I've never been able to find a good open source intel .HEX editor, does anyone know of one? (not a HEX editor that shows the values in any file, but one that loads intel HEX and displays it. maybe allows editing, and resaves with updated checksums)[/quote]This is an excellent question, but potentially a deep topic, so I've created a new thread in the general category: (Intel) .HEX reader/writer/editor

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #73
[quote author="ian"]
Quote
...would remove the ability to upgrade the firmware via USB, wouldn't it?

I see, yes, programming the firmware directly like that does erase and remove the bootloader.

Quote
I was hoping for a way to program both the USB bootloader and the new firmware together.

This should be totally possible. I'm not sure of the .HEX foo required to to merge the files, but I provide a dump to Seeed with bootloader+firmware in one, for example, so it's possible to build an all-in-one. The problem might be that it doesn't play well with the bootloader then because certain vectors are already relocated, but if the bootloader PC program was smart enough to ignore the bootloader section, then maybe that can be worked out too.

On a related note: I've never been able to find a good open source intel .HEX editor, does anyone know of one? (not a HEX editor that shows the values in any file, but one that loads intel HEX and displays it. maybe allows editing, and resaves with updated checksums)
[/quote]

If you copy two .hex in just one file (remove the end of file indicator from the first) the programmer will fix it. The order is important (last file wins), but perfect doable.

So I would say notepad rules! :P

Re: Bus Pirate PIC 24F Programmer Dev Thread

Reply #74
I moved this to a new PIC programmer sub-forum. I also started a new cross-platform console version of this app that compiles with GCC/MinGW. It currently IDs, erases, and programs a single page. Updates are here:
http://dangerousprototypes.com/forum/in ... opic=650.0
Got a question? Please ask in the forum for the fastest answers.