No code yet... just setting up the chip. (great cow Graphical) I figured out how to add IO in the .dat file, but not sure I did all correctly
Added this to the .dat file:
And seems to work.... but now the bootloader offset of 0x1000 is giving me grief, but have high hopes of figuring it out.... compiler telling me I'm out of memory...
This is a USB HID bootloader so, uses much space, but should have plenty left... works well in mplab...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
There are quite a few DAT files that are missing the [Pins-xxx] section.
12f1501.dat, 16f1454.dat, 16f1455.dat, 16f1458.dat, 16f1459.dat and about 20 more.
Also in the Graphical Basic hardware setup when trying to define Pins for SendAHigh, etc in software serial, there re no pins in the pull down menu. Same thing with some others.
As far as using the Microchip HID bootloader with GCB/GCGB, I am not aware of anyone that has done this yet.
FYI. The GCB "Option Bootloader" directive does not accept addresses above 0x699, even though the help file uses 0x800 as an example (that does not work). Not sure if this will be a problem or not. The "option bootloader" directive is not needed with the Arduino Bootloader and may not be needed with the Microchip HID bootloader.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Huh, I thought that Hugh said that [Pins] was deprecated at one time? Now I'm not so sure. Pins was also used for an earlier IDE that offered a device block diagram view with Pin function(s).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The [Pins-xxx] section is definitely in use. The compiler uses it to tell if pins are not bidirectional, and to generate a warning if for example the input-only MCLR pin on a PIC is set to act as an output. GCBASIC will still compile without it, though. GCGB uses it to show a diagram of the chip and allowing the user to select pins. I think Emile's GCBIDE also may have used it, but not sure.
I'll have a look at the chip data file conversion/generator program and see what's happening there. It tries to extract information from MPLAB/gputils about the pinout, but often can't get anything and then has to guess based on the pin count and special function register names. In this case, it's probably not guessing correctly.
GCGB won't show pins in the software serial configuration window, because those boxes need to have commands or conditions entered. (Set TX On, RX = On, etc). It's a bit confusing, and probably should be simplified, but how to do this without breaking compatibility will be the tricky part.
Option Bootloader should work for higher locations on PIC18F and AVR chips, but on 12F/16F the compiler currently expects to be able to place some things on page 0. If it's told to start the program on page 1, it gets unhappy. Maybe this is something that could be dealt with, are there specific bootloaders for 12F/16F that take up all of the first 2048 words of memory? (Given that many 12F/16F chips don't have that much program memory anyway, would there be a point to a bootloader this big?)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have loaded the HID USB bootloader from Microchip onto a 16f1459.
The loader aplication on the pc identifies the chip correctly.
When I try to compile a program with #option bootloader 0x1000 I get the following message:
Error: First page of program memory is full, please reduce size of Main and Interrupt routines
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I remove the option bootloader directive the bootloader application gives the following message:
No address within range in file: LED Dimmer 16f1459 bootloader hid.hex. Verify the correct firmware image was specified and is designed for your device.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
not much of a user program...
`; ----- Configuration
#chip 16f1459, 48
#option bootloader 0x1000 'must for usb Bootloader
#option NoConfig
#option explicit
; ----- Define Hardware settings
dir PORTc.0 out
;----- Variables
; ----- Main body of program commences here.
Main:
set PORTc.0 on
wait 50 ms
set PORTc.0 off
wait 1 s
goto Main
end`
If you can reccomend a different usb bootloader that would also work. I allready went the serial bootloader route and was hoping to avoid the usb to serial hardware in my product to reduce costs.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Explanation: #option bootloader prevents the overwriting of any pre-loaded bootloader code, vectors, etc. below the address and have all Great Cow BASIC code start at address.
Copied from GCBasic help, what's above explanation suppose to mean?
For those using Tiny Bootloader all these years, suggest hex 'ADDRESS' you specify in #option bootloader, is the start address of Tiny Bootloader it's self, which isn't the case,
as compiler throws an error, for using option address in hex rather for start address of
your GCBasic code, how can this be?, given explanation in GCBasic help above.
Kindly make [#option bootloader 0xYYY] work as it's originally intended.
Anobium recommended a work around, but omitted #option NoConfig for clarity and GCBasic beginners, but still runs the risk of bootloader overwrite by compiler, if basic code
is quite large.
My preferred choice in programming is assembler, I particularly can't stand the attitude of C, C++ my next option was to try Basic on PIC and AVR controllers as I did with my Sinclair ZX80.
GCBasic looks promising and hope compiler in the future will be optimised for
space on PIC's 10F, 12F, 16F devices.
Regards,
Hanspeter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
'#option bootloader prevents the overwriting of any pre-loaded bootloader code, vectors, etc. below the specified address. The Great Cow BASIC code will start at specified address.`
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The '#option bootloader address' works as intended this is a documentation error.
Re #2. Not sure this is the case. If the code started at the specified address, with or without Noconfig I am sure how this gets overwritten. If you can give us more insight I am sure this will help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I recommend the following: Use the TinyBootloader+ and then adapt your user program as shown below:
#chip 16f1459, 48
#option explicit
; ----- Define Hardware settings
dir PORTc.0 out
;----- Variables
; ----- Main body of program commences here.
Main:
set PORTc.0 on
wait 50 ms
set PORTc.0 off
wait 1 s
goto Main
end`
And, program your chip with the attached HEX which is the TinyBootloader+ for that chip. The software for TinyBootloader+ is included in your Great Cow BASIC installation.
tynybootloader is a serial bootloader. I have a handle on serial bootloaders. I want to use the usb bootloader to avoid the serial to usb hardware in order to save costs. Thanks anyway
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
LOL.
I have found this bootloader but it uses a python scrypt to write the hex file to the pic.
It also solves the memory full problem since the bootloader offset is 0x200 and great cow is happy with compiling that.
Can some clever coder out there maybe make an .exe of it that works with GCB? I live in hope...
New USB bootloader is now available for these chips - 16f1454, 55 and 59
Following discussions with Gert I had lots of conversations with developer of the USB Bootloader. Some background - the USB Bootloader was based upon a Microchip project and the USB Bootloader essentially filled the Progmem. Very little space was left for a user program.
When I set hardware to 16f1459, I get no IO pins listed and an unhandled exception in the IO pin parameter editor.
Is this an issue with the .dat file for this chip? can I change this somehow?
Same result with the 1459's cousins 1454 and 1455.
Thanks!
Hi,
Can you attach your code please?
Anobium
No code yet... just setting up the chip. (great cow Graphical) I figured out how to add IO in the .dat file, but not sure I did all correctly
Added this to the .dat file:
[Pins-DIP]
1,Vdd
2,RA5(IO)
3,RA4(IO)
4,MCLR
5,RC5(IO)
6,RC4(IO)
7,RC3(IO)
8,RC6(IO)
9,RC7(IO)
10,RB7(IO)
11,RB6(IO)
12,RB5(IO)
13,RB4(IO)
14,RC2(IO)
15,RC1(IO)
16,RC0(IO)
17,Vusb
18,D-
19,D+
20, Vss
And seems to work.... but now the bootloader offset of 0x1000 is giving me grief, but have high hopes of figuring it out.... compiler telling me I'm out of memory...
This is a USB HID bootloader so, uses much space, but should have plenty left... works well in mplab...
This does sound like a .dat file that is not correct.
Are you making headway?
RE: GCGB
There are quite a few DAT files that are missing the [Pins-xxx] section.
12f1501.dat, 16f1454.dat, 16f1455.dat, 16f1458.dat, 16f1459.dat and about 20 more.
Also in the Graphical Basic hardware setup when trying to define Pins for SendAHigh, etc in software serial, there re no pins in the pull down menu. Same thing with some others.
As far as using the Microchip HID bootloader with GCB/GCGB, I am not aware of anyone that has done this yet.
FYI. The GCB "Option Bootloader" directive does not accept addresses above 0x699, even though the help file uses 0x800 as an example (that does not work). Not sure if this will be a problem or not. The "option bootloader" directive is not needed with the Arduino Bootloader and may not be needed with the Microchip HID bootloader.
Huh, I thought that Hugh said that [Pins] was deprecated at one time? Now I'm not so sure. Pins was also used for an earlier IDE that offered a device block diagram view with Pin function(s).
The [Pins-xxx] section is definitely in use. The compiler uses it to tell if pins are not bidirectional, and to generate a warning if for example the input-only MCLR pin on a PIC is set to act as an output. GCBASIC will still compile without it, though. GCGB uses it to show a diagram of the chip and allowing the user to select pins. I think Emile's GCBIDE also may have used it, but not sure.
I'll have a look at the chip data file conversion/generator program and see what's happening there. It tries to extract information from MPLAB/gputils about the pinout, but often can't get anything and then has to guess based on the pin count and special function register names. In this case, it's probably not guessing correctly.
GCGB won't show pins in the software serial configuration window, because those boxes need to have commands or conditions entered. (Set TX On, RX = On, etc). It's a bit confusing, and probably should be simplified, but how to do this without breaking compatibility will be the tricky part.
Option Bootloader should work for higher locations on PIC18F and AVR chips, but on 12F/16F the compiler currently expects to be able to place some things on page 0. If it's told to start the program on page 1, it gets unhappy. Maybe this is something that could be dealt with, are there specific bootloaders for 12F/16F that take up all of the first 2048 words of memory? (Given that many 12F/16F chips don't have that much program memory anyway, would there be a point to a bootloader this big?)
Has there been any progress made on the "option bootloader" for the 16f1459? I also get the "memory full" error. (using compiler 98.0.1)
No. No change. We never identified an issue.
I think we ended up with post from Hugh, shown above.
Can you recap the question to ensure we are all on the same page.
I have loaded the HID USB bootloader from Microchip onto a 16f1459.
The loader aplication on the pc identifies the chip correctly.
When I try to compile a program with #option bootloader 0x1000 I get the following message:
Error: First page of program memory is full, please reduce size of Main and Interrupt routines
When I remove the option bootloader directive the bootloader application gives the following message:
No address within range in file: LED Dimmer 16f1459 bootloader hid.hex. Verify the correct firmware image was specified and is designed for your device.
Please post your user program.
Let us advise. We may recommend a much smaller and improved bootloader, but, we should start with your code.
not much of a user program...
`; ----- Configuration
#chip 16f1459, 48
#option bootloader 0x1000 'must for usb Bootloader
#option NoConfig
#option explicit
; ----- Define Hardware settings
dir PORTc.0 out
;----- Variables
; ----- Main body of program commences here.
Main:
set PORTc.0 on
wait 50 ms
set PORTc.0 off
wait 1 s
goto Main
end`
If you can reccomend a different usb bootloader that would also work. I allready went the serial bootloader route and was hoping to avoid the usb to serial hardware in my product to reduce costs.
Hi All,
Option Bootloader
Syntax:
#option bootloader address
Explanation:
#option bootloader prevents the overwriting of any pre-loaded bootloader code, vectors, etc. below the address and have all Great Cow BASIC code start at address.
Copied from GCBasic help, what's above explanation suppose to mean?
For those using Tiny Bootloader all these years, suggest hex 'ADDRESS' you specify in #option bootloader, is the start address of Tiny Bootloader it's self, which isn't the case,
as compiler throws an error, for using option address in hex rather for start address of
your GCBasic code, how can this be?, given explanation in GCBasic help above.
Kindly make [#option bootloader 0xYYY] work as it's originally intended.
Anobium recommended a work around, but omitted #option NoConfig for clarity and GCBasic beginners, but still runs the risk of bootloader overwrite by compiler, if basic code
is quite large.
My preferred choice in programming is assembler, I particularly can't stand the attitude of C, C++ my next option was to try Basic on PIC and AVR controllers as I did with my Sinclair ZX80.
GCBasic looks promising and hope compiler in the future will be optimised for
space on PIC's 10F, 12F, 16F devices.
Regards,
Hanspeter.
Help should read
`
Syntax:
'#option bootloader address'
'#option bootloader prevents the overwriting of any pre-loaded bootloader code, vectors, etc. below the specified address. The Great Cow BASIC code will start at specified address.`
The '#option bootloader address' works as intended this is a documentation error.
Re #2. Not sure this is the case. If the code started at the specified address, with or without Noconfig I am sure how this gets overwritten. If you can give us more insight I am sure this will help.
Regarding optimisation.
If you idenftify opportunties to optimise then please let us know. We can look at the recommendation.
Thanks,
then this clears my understanding [#option bootloader address].
Going through assembled GCBasic code, compiler placed start address as entered
in [#option bootloader 0xAddress].
Impression was [0xAddress] is in reference to resident Tiny Bootloader in Flash high address.
I recommend the following: Use the TinyBootloader+ and then adapt your user program as shown below:
And, program your chip with the attached HEX which is the TinyBootloader+ for that chip. The software for TinyBootloader+ is included in your Great Cow BASIC installation.
Enjoy
PS: thanks for a cool compiler and prompt help.
tynybootloader is a serial bootloader. I have a handle on serial bootloaders. I want to use the usb bootloader to avoid the serial to usb hardware in order to save costs. Thanks anyway
ok.
I will have to duck out on this one as I would simply use a USBtoSerial converter.
LOL.
I have found this bootloader but it uses a python scrypt to write the hex file to the pic.
It also solves the memory full problem since the bootloader offset is 0x200 and great cow is happy with compiling that.
Can some clever coder out there maybe make an .exe of it that works with GCB? I live in hope...
https://github.com/74hc595/PIC16F1-USB-Bootloader
Useful? Doubt it but tried. Simple circuit like this works for me. What's the problem programming?
Last edit: stan cartwright 2017-11-08
New USB bootloader is now available for these chips - 16f1454, 55 and 59
Following discussions with Gert I had lots of conversations with developer of the USB Bootloader. Some background - the USB Bootloader was based upon a Microchip project and the USB Bootloader essentially filled the Progmem. Very little space was left for a user program.
So, Johnny, as redeveloped in ASM.
I have not tested but he is confident. :-)
See https://github.com/johnnydrazzi/USB-uC/tree/master/Hex%20Files there a other chips there but this post is specifically to share the 16f news.