The biggest bugbear I have with testing and uploading code using the othrwise brilliant bootloader (BootForAll16) is the requirement to repeatedly configure the bootloader every time I want to use it.
Since I do most of my debugging using the serial port, I have to shut down the bootloader tool as soon as the project is uploaded to the target.
There are two big problems that need to be fixed.
First, the hex file should ALWAYS default to the current project's output. I have never uploaded one hex file while I've been debugging the current project! It's nice to leave in as an extra feature, but it should have a reasonable default and not require me to specify the hex file every debug cycle!
Secondly (and just as importantly), the serial port settings (port, baud rate, stop bits, parity, handshaking) for the bootloader should all be retained across instances of the GUI. Once I've changed my bootloader code upload default speed in the bootloader, I update all my projects to use the new speed, so I spend more time fiddling with the same dropdown combos each time I run the bootloader than I spend uploading code. It's annoying and error-prone.
Please make the bootloader settings non-volatile
Please make the bootloader settings non-volatile
Data is not Information. Information is not Knowledge. Knowledge is not Wisdom.
Re: Please make the bootloader settings non-volatile
Hi,
Done. The mikroBootloader will save com port settings.PC Pete wrote:The biggest bugbear I have with testing and uploading code using the othrwise brilliant bootloader (BootForAll16) is the requirement to repeatedly configure the bootloader every time I want to use it.
Since I do most of my debugging using the serial port, I have to shut down the bootloader tool as soon as the project is uploaded to the target.
There are two big problems that need to be fixed.
First, the hex file should ALWAYS default to the current project's output. I have never uploaded one hex file while I've been debugging the current project! It's nice to leave in as an extra feature, but it should have a reasonable default and not require me to specify the hex file every debug cycle!
Secondly (and just as importantly), the serial port settings (port, baud rate, stop bits, parity, handshaking) for the bootloader should all be retained across instances of the GUI. Once I've changed my bootloader code upload default speed in the bootloader, I update all my projects to use the new speed, so I spend more time fiddling with the same dropdown combos each time I run the bootloader than I spend uploading code. It's annoying and error-prone.
Excellent! Thats 50% of my wish come true!
Now, how about the other bit... Perhaps a "Use current" checkbox so the upload will default to the current project's output file, and a browse button so non-default uploads can occur?
While we're on the subject of the bootloader, it would also be great if the com port(s) were fully released once the upload is completed.
Currently, I have to manually close the bootloader window so I can run my terminal capture program for target PIC debugging, etc., which is a fiddle I can live without. To be fair, if I installed some bridging drivers, I can "snoop" the serial port pins, but I can't be *****ed, more so because I don't want to get into this on an x64 OS!
But thanks for at least setting the com port parms permanent.
Now, how about the other bit... Perhaps a "Use current" checkbox so the upload will default to the current project's output file, and a browse button so non-default uploads can occur?
While we're on the subject of the bootloader, it would also be great if the com port(s) were fully released once the upload is completed.
Currently, I have to manually close the bootloader window so I can run my terminal capture program for target PIC debugging, etc., which is a fiddle I can live without. To be fair, if I installed some bridging drivers, I can "snoop" the serial port pins, but I can't be *****ed, more so because I don't want to get into this on an x64 OS!
But thanks for at least setting the com port parms permanent.
Hi,
Bootloader will load hex file of the current project (if it exists) once it is started from the compiler's IDE.
As far as the serial port's releasing problem is concerned, mikroBootloader disconnects automatically after bootloading is finished. I have tried and succeeded connecting to serial port once bootloading was done.
Maybe you could point me to the terminal capture tool you are using, so I could try it myself. Which operating system do you use?
I guess you caught me in a good moodPC Pete wrote:Excellent! Thats 50% of my wish come true!
Now, how about the other bit... Perhaps a "Use current" checkbox so the upload will default to the current project's output file, and a browse button so non-default uploads can occur?
While we're on the subject of the bootloader, it would also be great if the com port(s) were fully released once the upload is completed.
Currently, I have to manually close the bootloader window so I can run my terminal capture program for target PIC debugging, etc., which is a fiddle I can live without. To be fair, if I installed some bridging drivers, I can "snoop" the serial port pins, but I can't be *****ed, more so because I don't want to get into this on an x64 OS!
But thanks for at least setting the com port parms permanent.
Bootloader will load hex file of the current project (if it exists) once it is started from the compiler's IDE.
As far as the serial port's releasing problem is concerned, mikroBootloader disconnects automatically after bootloading is finished. I have tried and succeeded connecting to serial port once bootloading was done.
Maybe you could point me to the terminal capture tool you are using, so I could try it myself. Which operating system do you use?
I'm so glad you're in a good mood! I like happy, contented developers... 
I made a mistake in the terminal capture issue - I left the "Reset PIC" announcement window open accidentally, that's why I couldn't capture immediately after uploading when I posted. I'm sorry about the mixup!
For what it's worth, I'm using the latest version of RealTerm on Windows XP x64 edition, on a quad core AMD MB with 4G ECC RAM and 4Tb RAID drive, along with separate hdd units for the boot drive, temp drives, swap drives, etc.
I made a mistake in the terminal capture issue - I left the "Reset PIC" announcement window open accidentally, that's why I couldn't capture immediately after uploading when I posted. I'm sorry about the mixup!
For what it's worth, I'm using the latest version of RealTerm on Windows XP x64 edition, on a quad core AMD MB with 4G ECC RAM and 4Tb RAID drive, along with separate hdd units for the boot drive, temp drives, swap drives, etc.
