I will be happy to make/test a bootloade firmware r for 886/887 as the one supplied by TBL does not seem to work. .
However I will need to confirm specifics related to the system clock as I am guessing this is for Chipino. While I have no experience with Chipino I do see a crystal oscillator on a photo of the board. Is this 20 MHz ?
The 886/887 USART uses PortC.7 for RX and PortC.6 for TX. These cannot be changed.
The bootloader sets the config bits and these cannot be changed by GCB source code. So I will need to know if you need any specific Config settings for your application.
Code Protection will be enabled to prevent users from reading and exporting the hex.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually could you produce two?
1. CHIPINO version, 16Mhz, Mode, External MCLR, Watchog off, LVP off, POR off, PWRT off, BOR off.
2. Then stand-alone 886/887, 8Mhz HF Internal osc, internal mclr, Watchog off, LVP off, POR off, PWRT off, BOR off.
Years ago, microEngineering Labs (melabs.com) had a bootloader called meloader. It worked great but they cancelled it due to tech support (so they told me). They had an application with drop down menus. You selected the configuration from the drop downs and then it would produce a .hex file bootloader that you programmed into the PIC. From there you could program the device with their meloader application that ran on windows. This gave a developer lots of choices. It only supported about 20 chips at the time but it was awesome.
Is something like that possible for your bootloader project?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
With Internal MCLRE, the chip will need a Power On Reset (POR) in order to start the programming cycle. Is that really what you want ?
Note: There is no "POR" Config setting on these chips. Did you mean something else?
=========================================
In regards to an application that creates a bootloader based either upon the pxxxx.inc file or aGCB chipdata file, it is certainly possible, but not something that I am interesting in persuing, or supporting.
I have taken the assembly code provided by the folks at TBL and cleaned up / modified it to create a few templates. I use these ASM templates to produce the bootloader hex files using MPLAB X 3.45 and MPASM 5.7. That is as far as I intend to go.
Supporting an application such as the one by Melabs could be a nightmare.
Last edit: William Roth 2016-11-09
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, I didn't realize POR was required but that makes sense. I want to have a version that only requires power and ground to run the device without any external components (other than the serial connection) so Internal OSC and Internal MCLR are key.
I understand about the melabs application. It was just an idea. I appreciate what you are doing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I initially thought as you are and wanted to use POR and keep the MCLR pin available as input.
But in practice I soon discovered that having DTR connected via a 100nF cap to the MCLR pin, as is the default setting for the TBL+ software, allows seamless control and programing on the fly.
Whilst on the 8 pin, and even 14 pin, devices losing the MCLR pin can be an issue iit is not a problem on 20 / 28 / 40 pin devices and greatly improves your user experience.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I haven't had a use for a bootloader, but never say never.
I tried the tiny bootloader with the 12f1822 and a blinky led, and it worked fine. May have tested the 16f1503 with the software UART, can't exactly remember, it has been awhile. Also having say an ATTiny 25 would be interesting.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You selected the configuration from the drop downs and then it would produce a .hex file bootloader that you programmed into the PIC. From there you could program the device with their meloader application that ran on windows.
But what was the point?
You would need a PICKit to get the bootloader into the devicve to then use the windows app to preogram the device. If that is the case then just set the config in your GCB source and program the device once.
To my mind a bootloader is set to a generic configureation to be distributed to people who do not have any means of programing the device other than a generic USB/Serial Bridge.
Maybe I am missing the point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To my mind a bootloader is set to a generic configureation to be distributed to people who do not have any means of programing the device other than a generic USB/Serial Bridge.
Even if there was a way to make a "bootloader set to a generic configureation" it still needs to be programmed into the device with a PICkit or similar. From that point if a person who has a PICkit wants to supply those who don't have one with a preprogrammed chip (like Arduino), then you would have a device anybody can program without a PICkit.
Since each device has a somewhat different memory map and register setup, a generic bootloader isn't possible so William has offered to make different files for various devices. What I proposed was an application that makes it easier in the long run to make custom bootloaders so William doesn't have to make a new bootloader configuration every time a new setup is needed. That is the point of that application.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since each device has a somewhat different memory map and register setup, a generic bootloader isn't possible so William has offered to make different files for various devices.
Thanks Chuck,
I was under the impression that you needed a multi configuration application for the PIC16f866 alone.
I can also now see why the melabs bootloader was cancelled due to tech support, there are over a thousand PIC devices and each has many possible config combinations.
A few 'Generic' as in 'the most common settings" bootloaders created on demand sounds more manageable.
My personal experience with creating Bootloaders were the ones I created for the PIC32MX and I needed 12 different bootloaders just to cover the the USB and Serial versions of the device with a subset of internal vs external oscillator and with / without RTC.
Cheers
Chris
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be nice to have an I2C bootloader espessialy for PIC16F18855. There are many applications, which have several slaves connected by I2C bus. It will allow remote upgrate of the firmware.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would like to see the PIC16F886/887 added to the list. Thanks
I will be happy to make/test a bootloade firmware r for 886/887 as the one supplied by TBL does not seem to work. .
However I will need to confirm specifics related to the system clock as I am guessing this is for Chipino. While I have no experience with Chipino I do see a crystal oscillator on a photo of the board. Is this 20 MHz ?
The 886/887 USART uses PortC.7 for RX and PortC.6 for TX. These cannot be changed.
The bootloader sets the config bits and these cannot be changed by GCB source code. So I will need to know if you need any specific Config settings for your application.
Code Protection will be enabled to prevent users from reading and exporting the hex.
Actually could you produce two?
1. CHIPINO version, 16Mhz, Mode, External MCLR, Watchog off, LVP off, POR off, PWRT off, BOR off.
2. Then stand-alone 886/887, 8Mhz HF Internal osc, internal mclr, Watchog off, LVP off, POR off, PWRT off, BOR off.
Years ago, microEngineering Labs (melabs.com) had a bootloader called meloader. It worked great but they cancelled it due to tech support (so they told me). They had an application with drop down menus. You selected the configuration from the drop downs and then it would produce a .hex file bootloader that you programmed into the PIC. From there you could program the device with their meloader application that ran on windows. This gave a developer lots of choices. It only supported about 20 chips at the time but it was awesome.
Is something like that possible for your bootloader project?
Note: There is no "POR" Config setting on these chips. Did you mean something else?
=========================================
In regards to an application that creates a bootloader based either upon the pxxxx.inc file or aGCB chipdata file, it is certainly possible, but not something that I am interesting in persuing, or supporting.
I have taken the assembly code provided by the folks at TBL and cleaned up / modified it to create a few templates. I use these ASM templates to produce the bootloader hex files using MPLAB X 3.45 and MPASM 5.7. That is as far as I intend to go.
Supporting an application such as the one by Melabs could be a nightmare.
Last edit: William Roth 2016-11-09
Yes, I didn't realize POR was required but that makes sense. I want to have a version that only requires power and ground to run the device without any external components (other than the serial connection) so Internal OSC and Internal MCLR are key.
I understand about the melabs application. It was just an idea. I appreciate what you are doing.
I initially thought as you are and wanted to use POR and keep the MCLR pin available as input.
But in practice I soon discovered that having DTR connected via a 100nF cap to the MCLR pin, as is the default setting for the TBL+ software, allows seamless control and programing on the fly.
Whilst on the 8 pin, and even 14 pin, devices losing the MCLR pin can be an issue iit is not a problem on 20 / 28 / 40 pin devices and greatly improves your user experience.
Cheers
Chris
I haven't had a use for a bootloader, but never say never.
I tried the tiny bootloader with the 12f1822 and a blinky led, and it worked fine. May have tested the 16f1503 with the software UART, can't exactly remember, it has been awhile. Also having say an ATTiny 25 would be interesting.
But what was the point?
You would need a PICKit to get the bootloader into the devicve to then use the windows app to preogram the device. If that is the case then just set the config in your GCB source and program the device once.
To my mind a bootloader is set to a generic configureation to be distributed to people who do not have any means of programing the device other than a generic USB/Serial Bridge.
Maybe I am missing the point.
To my mind a bootloader is set to a generic configureation to be distributed to people who do not have any means of programing the device other than a generic USB/Serial Bridge.
Even if there was a way to make a "bootloader set to a generic configureation" it still needs to be programmed into the device with a PICkit or similar. From that point if a person who has a PICkit wants to supply those who don't have one with a preprogrammed chip (like Arduino), then you would have a device anybody can program without a PICkit.
Since each device has a somewhat different memory map and register setup, a generic bootloader isn't possible so William has offered to make different files for various devices. What I proposed was an application that makes it easier in the long run to make custom bootloaders so William doesn't have to make a new bootloader configuration every time a new setup is needed. That is the point of that application.
Thanks Chuck,
I was under the impression that you needed a multi configuration application for the PIC16f866 alone.
I can also now see why the melabs bootloader was cancelled due to tech support, there are over a thousand PIC devices and each has many possible config combinations.
A few 'Generic' as in 'the most common settings" bootloaders created on demand sounds more manageable.
My personal experience with creating Bootloaders were the ones I created for the PIC32MX and I needed 12 different bootloaders just to cover the the USB and Serial versions of the device with a subset of internal vs external oscillator and with / without RTC.
Cheers
Chris
Just now. The TBL+ bootloader came to the resue!
Comparing 18f45k80 and a 16f1789. One is PK2 and the other is.... PK3+IPE...
But, not in my world. Anything like the 16f1789 has a TBL+ blown on to it and tonite I was able to test with some ease.
TBL+ Rocks - thanks Bill!
It would be nice to have an I2C bootloader espessialy for PIC16F18855. There are many applications, which have several slaves connected by I2C bus. It will allow remote upgrate of the firmware.
A PIC I2C Bootloader is not on my "to do" list. However, if you would like to make one your efforts will be appreciated. It would not be a minor task.
We have one. :-)