Hi Byron:

I basically agree with most of your post, although I don't do MIDI
so I don't have your need for a separate programming input to the
chip.  I'm going to snip out a lot of the previous messages so as to
not tie up bandwidth.

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D  =
ORIGINAL MESSAGE =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

On Mon, Dec 06, 2004 at 09:13:48AM -0500, Roy J. Gromlich wrote:
> Hi Jan-Erik:

>>> Roy,

>>> I'm going to horn in because it's a bootloader discussion.

You are welcome to jump in any time - this is a free=20
place for everyone.

>>>  using or developing Open Source tools.

I had not found any Open Source PIC programming tools,
but then I probably don't know where to look.

>>>  they only have multiword writes (4 or 8 words) to write.=20
>>> The second issue is that newer PICS requires a row erase,=20
>>> generally 32 words, before you can write to it. With Tiny,=20
>>> such a row erase could be added silently.

Tiny already erases and programs the Flash Program memory just
fine, so it already knows how to do multi-word erase and write.
The problem is that it can't write to the Configuration registers
- just returns Error! with no explanation.  I am certain TINY=20
could be fixed fairly easily, but the programming algorithm is=20
in the Windows App, and I don't have the source for that part.

>>> A better idea may be to use Tato's PLoader.
>>> You can find the project here: http://propic2.com/ploader

I will check it out as soon as I get some free time - probably
over this coming weekend.

>>> Finally someone that appreciates the power of the bootloader...

Coming from the world of erase the EPROM / burn the EPROM,=20
I really appreciated the first uProc development system I had which
allowed loading the code  into emulation RAM.. What a time saving
that was, even though the code went away when power went off.

>>> But a good command protocol should mask most of the issues.=20

If (that's a BIG if) you can anticipate the possible changes in new
chips programming requirements, you can have a parameter file for
the programmer which has entries for each new chip, telling the
programmer how to do it.=20

>>> I strongly feel that the hardware USART should be available to=20
>>> the application instead of having to share with the bootloader.

I understand, and even agree to an extent.  As I said, the UART is
already connected to the computer doing the programming, so having
the programmer and the application take turns using the RS232 isn't
a serious problem.

>>> Everyone else requires that you move at least to address 4 or 8.

I almost always write code so the first 2 bytes are a jump to the
system initialization code, so that isn't an issue.

>>> Only 18F parts can do that. You should read Wouter's=20
>>> explanation to why messing with config regs is a bad idea=20
>>> even for 18F parts. In short it allows the bootloader to=20
>>> potentially disable itself, which is a no no.

I would agree that would be a nasty problem, but the firmware
you are testing could always find strange ways to disable the=20
device being tested.

>>>BAJ

I am trying to get in touch with the author of TinyBootloader to
see if I can get the source for the Windows app which does the
programming.  Unfortunately, it appears to have been written
in Delphi, and I don't have a development system for that suite.

Roy


_______________________________________________
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
_______________________________________________
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist