|
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 |
|
|
16F88 bootloader
Started by ●August 8, 2004
Reply by ●August 9, 20042004-08-09
Reply by ●August 9, 20042004-08-09
|
> > >>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 > > |
|
|
Reply by ●August 9, 20042004-08-09
|
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 |
|
|
Reply by ●August 9, 20042004-08-09
|
[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 __________________________________ |
|
|
Reply by ●August 9, 20042004-08-09
|
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 > > __________________________________ > |
Reply by ●August 10, 20042004-08-10
|
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 |
Reply by ●August 10, 20042004-08-10
|
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 |
|
|
Reply by ●August 10, 20042004-08-10
|
--- 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 |
|
|
Reply by ●August 10, 20042004-08-10
|
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 > > |
Reply by ●August 10, 20042004-08-10
|
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 |
