Forums

16F88 bootloader

Started by upand_at_them August 8, 2004
On Mon, 9 Aug 2004, Igor Janjatovic wrote:

> > I guess I was talking about both. I don't see why the ICSP interface
> > can't be the same as that for self-programming. Since no high
> > voltage is used they're both just sending logic signals.

The ICSP may have LVP,HVP or both. If it's a prototype
board, populated with SO/TSSOP packages (and if it's possible),
having both volatge levels is a good choice. I let other people to say why.

> If ICSP interface is the same as that for bootloader, then why using
> bootloader?


16F88 is not an ideal device for bootloader. However, why using a
bootloader? A bootloader is usefull only in prototyping/developing stage
when the user is testing multiple routines and need too many
programming-erasing sequences. Why both botloader and ICSP ?
Because probably the prototyping becomes a final product and require
memory protection which a bootloader can't offer. Because the PIC have a
SO or TSSOP package and there is a virgin microcontroller soldered
onboard. So the bottloader software must be programmed somehow inside
the microcontroller. Easy, isn't it ?

Is much cheaper for a developer to use the same board for prototyping as
the product itself. It's also cheap enough to have an ICSP and a
bootloader connection (assuming you don't use the RS232 for loading, like
most popular loaders but other PIC pins like Wouter's one wire
serial bootloader or ZPL)
>
> > Cost isn't really an issue since this is a single item project for
> > myself. I just want simplicity and low power consumption - the
> > MAX232 would consume power even when it's not used.
>

No, there are so many Maxim transcievers with shut down and low power
consumtion, just visit the site. If you don't like what you see check my
collection/ideeas about RS232 interfacing:
http://www.surducan.netfirms.com/RS232.html
and try to understand my english... :)

Vasile




>
>
>>If ICSP interface is the same as that for bootloader, then why using
>>bootloader?
>>
> >16F88 is not an ideal device for bootloader.
>
Hi Vasile, tell me why not ?

> However, why using a
>bootloader? A bootloader is usefull only in prototyping/developing stage
>when the user is testing multiple routines and need too many
>programming-erasing sequences.
>
Depends on what you want to achieve.
As almost all my designs already I have need for USB communication (is
functionality),
bootloading is the most fantastic thing I've ever seen.
Development and serial debugging is fast and easy.
But even when the products are at my customers,
I just send a them file, and they load it up.
Sorry but I don't know any other way to achieve such easy upgrading.

cheers,
Stef

>
>




Actually, a place where a bootloader might be usefull is in field
configuration of large amounts of data. Suppose you had a device
that needs a large amount of tabular data to drive your application
and the data can change based on the needs/wants of the
customer/user. I'd want to build bootloading capabilities into my
application. Maybe bootloading is the wrong term but the scenario
is - hook up a notebook computer to the serial connection and upload
the new data.

I have such an application right now but have gone the route of using
a PIC with more flash (16F648A) and storing the most likely tables in
flash. Still, it doesn't afford me as much flexibility as I think my
customers will want.

--- In , Vasile Surducan <vasile@s...> wrote:
> On Mon, 9 Aug 2004, Igor Janjatovic wrote:
>
> > > I guess I was talking about both. I don't see why the ICSP
interface
> > > can't be the same as that for self-programming. Since no high
> > > voltage is used they're both just sending logic signals.
>
> The ICSP may have LVP,HVP or both. If it's a prototype
> board, populated with SO/TSSOP packages (and if it's possible),
> having both volatge levels is a good choice. I let other people
to say why.
>
> > If ICSP interface is the same as that for bootloader, then why
using
> > bootloader? > 16F88 is not an ideal device for bootloader. However, why using a
> bootloader? A bootloader is usefull only in prototyping/developing
stage
> when the user is testing multiple routines and need too many
> programming-erasing sequences. Why both botloader and ICSP ?
> Because probably the prototyping becomes a final product and require
> memory protection which a bootloader can't offer. Because the PIC
have a
> SO or TSSOP package and there is a virgin microcontroller soldered
> onboard. So the bottloader software must be programmed somehow
inside
> the microcontroller. Easy, isn't it ?
>
> Is much cheaper for a developer to use the same board for
prototyping as
> the product itself. It's also cheap enough to have an ICSP and a
> bootloader connection (assuming you don't use the RS232 for
loading, like
> most popular loaders but other PIC pins like Wouter's one wire
> serial bootloader or ZPL) >
> >
> > > Cost isn't really an issue since this is a single item project
for
> > > myself. I just want simplicity and low power consumption - the
> > > MAX232 would consume power even when it's not used.
> >
>
> No, there are so many Maxim transcievers with shut down and low
power
> consumtion, just visit the site. If you don't like what you see
check my
> collection/ideeas about RS232 interfacing:
> http://www.surducan.netfirms.com/RS232.html
> and try to understand my english... :)
>
> Vasile





[snip]
> Use low power RS232 transceiver with shutdown and
> with receiver enabled
> while in shutdown.
[snip]

Better yet, make the max232 chip part of the cable and
unplug after transfering data

additional advantages only one chip per cable (low
cost) and usable for any design you make.

Peter van Hoof
__________________________________




You beat me to it. Good idea.

Mike --- In , Peter van Hoof <pvhoof@y...> wrote:
> [snip]
> > Use low power RS232 transceiver with shutdown and
> > with receiver enabled
> > while in shutdown.
> [snip]
>
> Better yet, make the max232 chip part of the cable and
> unplug after transfering data
>
> additional advantages only one chip per cable (low
> cost) and usable for any design you make.
>
> Peter van Hoof >
> __________________________________
>





OK, understood, maybe the subject was better 16F88 datalogger, but also
bootloader is ok. On Mon, 9 Aug 2004, Phil wrote:

> Actually, a place where a bootloader might be usefull is in field
> configuration of large amounts of data. Suppose you had a device
> that needs a large amount of tabular data to drive your application
> and the data can change based on the needs/wants of the
> customer/user. I'd want to build bootloading capabilities into my
> application. Maybe bootloading is the wrong term but the scenario
> is - hook up a notebook computer to the serial connection and upload
> the new data.
>
> I have such an application right now but have gone the route of using
> a PIC with more flash (16F648A) and storing the most likely tables in
> flash. Still, it doesn't afford me as much flexibility as I think my
> customers will want.
>
> --- In , Vasile Surducan <vasile@s...> wrote:
> >
> >
> >
> > On Mon, 9 Aug 2004, Igor Janjatovic wrote:
> >
> > > > I guess I was talking about both. I don't see why the ICSP
> interface
> > > > can't be the same as that for self-programming. Since no high
> > > > voltage is used they're both just sending logic signals.
> >
> > The ICSP may have LVP,HVP or both. If it's a prototype
> > board, populated with SO/TSSOP packages (and if it's possible),
> > having both volatge levels is a good choice. I let other people
> to say why.
> >
> > > If ICSP interface is the same as that for bootloader, then why
> using
> > > bootloader?
> >
> >
> > 16F88 is not an ideal device for bootloader. However, why using a
> > bootloader? A bootloader is usefull only in prototyping/developing
> stage
> > when the user is testing multiple routines and need too many
> > programming-erasing sequences. Why both botloader and ICSP ?
> > Because probably the prototyping becomes a final product and require
> > memory protection which a bootloader can't offer. Because the PIC
> have a
> > SO or TSSOP package and there is a virgin microcontroller soldered
> > onboard. So the bottloader software must be programmed somehow
> inside
> > the microcontroller. Easy, isn't it ?
> >
> > Is much cheaper for a developer to use the same board for
> prototyping as
> > the product itself. It's also cheap enough to have an ICSP and a
> > bootloader connection (assuming you don't use the RS232 for
> loading, like
> > most popular loaders but other PIC pins like Wouter's one wire
> > serial bootloader or ZPL)
> >
> >
> >
> > >
> > > > Cost isn't really an issue since this is a single item project
> for
> > > > myself. I just want simplicity and low power consumption - the
> > > > MAX232 would consume power even when it's not used.
> > >
> >
> > No, there are so many Maxim transcievers with shut down and low
> power
> > consumtion, just visit the site. If you don't like what you see
> check my
> > collection/ideeas about RS232 interfacing:
> > http://www.surducan.netfirms.com/RS232.html
> > and try to understand my english... :)
> >
> > Vasile >
>
> to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
> Yahoo! Groups Links





Hi Stef,
Suppose you are living in the East and send a hex file for uploading to
one of your customers (which have already bought your tool), learning him how
to upload and configure the stuff, you have created your own competitor.
He will produce a tool with your last firmware inside. And maybe will be
better than yours just by 30% modification he made. Reverse PCB to SCH is
a joke for someone having good eyes (and some years of experience).

Of course a bootloader is a cool stuff. But I didn't see yet a mass
product (OTP, flash) without code protecting (only by mistake).
Looking to 16F88, a bootloader of 100 bytes without protecting the
page where the bootloader is located, means almost 4kbyte of memory, isn't
it ? It's ok. Unfortunately the Microchip distributors in the East of
Europe just say this chip exist. If you want to buy it is much difficult.
Like with the LF versions.

top 10 wishes,
Vasile
http://surducan.netfirms.com On Mon, 9 Aug 2004, Stef Mientki wrote:

>
> >
> >
> >>If ICSP interface is the same as that for bootloader, then why using
> >>bootloader?
> >>
> >>
> >
> >
> >16F88 is not an ideal device for bootloader.
> >
> Hi Vasile, tell me why not ?
>
> > However, why using a
> >bootloader? A bootloader is usefull only in prototyping/developing stage
> >when the user is testing multiple routines and need too many
> >programming-erasing sequences.
> >
> Depends on what you want to achieve.
> As almost all my designs already I have need for USB communication (is
> functionality),
> bootloading is the most fantastic thing I've ever seen.
> Development and serial debugging is fast and easy.
> But even when the products are at my customers,
> I just send a them file, and they load it up.
> Sorry but I don't know any other way to achieve such easy upgrading.
>
> cheers,
> Stef
>
> >
> >
> to unsubscribe, go to http://www.yahoogroups.com and follow the instructions
> Yahoo! Groups Links




--- In , "Phil" <phil1960us@y...> wrote:
> Actually, a place where a bootloader might be usefull is in field
> configuration of large amounts of data. Suppose you had a device
> that needs a large amount of tabular data to drive your application
> and the data can change based on the needs/wants of the
> customer/user. I'd want to build bootloading capabilities into my
> application. Maybe bootloading is the wrong term but the scenario
> is - hook up a notebook computer to the serial connection and
upload
> the new data.
>
> I have such an application right now but have gone the route of
using
> a PIC with more flash (16F648A) and storing the most likely tables
in
> flash. Still, it doesn't afford me as much flexibility as I think
my
> customers will want.


Can't you create some variables that you change by means of inputs ?

I considdered a datalogger that would be able to be changed easily by
means of a poatable unit. Maybe a PALM Pilot or some such.

You flip a switch on your device, connect the PALM and then upload
the 5,10 or more values.

how many readings to take, how often, thing like that.

Then those values are stored as variables the device will reference
to do it's thing.

It should seperate the user from any of the underlying software and
make it easy to alter the operaton of the unit.

Dave



hi Vasile,

Vasile Surducan wrote:

>Hi Stef,
>Suppose you are living in the East and send a hex file for uploading to
>one of your customers (which have already bought your tool), learning him how
>to upload and configure the stuff,
>
The user only has to press a preprogrammed button in his application
program, which will download the new hex file from the web, and program
it in the PIC, so hardly tolearn anything.

> you have created your own competitor.
>He will produce a tool with your last firmware inside. And maybe will be
>better than yours just by 30% modification he made. Reverse PCB to SCH is
>a joke for someone having good eyes (and some years of experience). >
I agree, if you've large bulk application, it's not the way to go.
But for research projects (which are my customers) it's great.
And if the whole worlds copies it, I'm very happy,
because then I'm involved in an epochmaking research project ;-)

(btw just right now I'm thinking of making bootable datasection for JAL,
so even in the smallest PICs you can easily change (a bit) functionality)

Stef

>
>



I can think of numerous examples where the data is simply too large.
For example, using tables to drive a frequency generator is pretty
common. what if you wanted to have a library of 20-30 different
waveforms? The wave tables, in aggregate, are too big for the flash
but could be read in and stored to flash via a boot load-like
mechanism. These days, I seem to be building more applications that
are driven by large amounts of data so this issue is fairly near to
me. I've been using the 16F877 but the F88 sure is a nice little and
much cheaper device.

I do agree that there are lots of cases where what you describe is
the best way to go.

--- In , "Dave Mucha" <dave_mucha@y...> wrote:
> --- In , "Phil" <phil1960us@y...> wrote:
> > Actually, a place where a bootloader might be usefull is in field
> > configuration of large amounts of data. Suppose you had a device
> > that needs a large amount of tabular data to drive your
application
> > and the data can change based on the needs/wants of the
> > customer/user. I'd want to build bootloading capabilities into
my
> > application. Maybe bootloading is the wrong term but the
scenario
> > is - hook up a notebook computer to the serial connection and
> upload
> > the new data.
> >
> > I have such an application right now but have gone the route of
> using
> > a PIC with more flash (16F648A) and storing the most likely
tables
> in
> > flash. Still, it doesn't afford me as much flexibility as I
think
> my
> > customers will want. > Can't you create some variables that you change by means of inputs ?
>
> I considdered a datalogger that would be able to be changed easily
by
> means of a poatable unit. Maybe a PALM Pilot or some such.
>
> You flip a switch on your device, connect the PALM and then upload
> the 5,10 or more values.
>
> how many readings to take, how often, thing like that.
>
> Then those values are stored as variables the device will reference
> to do it's thing.
>
> It should seperate the user from any of the underlying software and
> make it easy to alter the operaton of the unit.
>
> Dave