I have a number of old projects that use PicAxe processors. Slowly I'm converting these to raw PIC devices using Great Cow Basic. As this leaves me with spare PicAxe devices, I've been re-programming them and restoring them to their original PIC devices. The 08M2 becomes a 12F1840, the 14M2 16F1825 and the 20M2 becomes my favourite device, the 16F1829.
I have one or two odd devices, the first of which is the 20X2. This turns out to be an 18F14K22 which is similar to, and has the same pinout as the 1829. As I have PCBs ordered that use the 1829, and limited 1829's to hand I thought I'd repurpose the 20X2 and put it to use. I'm working on my WS2812clock at the minute which uses an 1829 so I thought I'd use the code for that.
I simply changed my #Chip definition to: #Chip 18F14K22, 64 (from 16F1829, 32) and recompiled. I got a warning: Warning: Configuration setting not valid: CP=ON
It took me a while to figure out why this was and quite what was meant by this. After searching the datasheet I eventually spotted that CP1 and CP2 are the configuration bits for Code Protection. As I use code protection by default at work, I also do at home. Commenting out the line: #Config CP=On the program compiled and programmed. It didn't immediately work running at 64MHz, presumably it was sending the data for the WS2812 LEDs too fast. Once set to 32MHz, it does work correctly.
The 18F14K22 device seems to support code protection, is there a reason why GCB does not allow it?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes the config is different. Summary. Always check.
Re PICINFO for Mac. I have put the source on GitHub and you can compile a version for the Mac for your own use. :-) Simples. Download the XOJO IDE and run it. You may have to tweak the UI but that is the fun of Open Source.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Oh dear, I don't want to load another IDE and toolset. Thanks for the offer though!
Mind you, Trev's version is showing information that the newer version isn't. Surely that's a retrograde step?
I can confirm that setting the #Config for CPB, CP0 and CP1 does indeed seem to activate code protection. I've written then read the device with and without to confirm. The first block of code is within the "boot block" and should also be protected. CPD will prevent EeProm from being read if set on.
Before PICInfo was available I would simply open up the chipdata file and go to the end of the file and look at the valid config setting for the chip. Faster than looking at the datasheet which may or may not give the same names used by the inc file or the GCB datafile.
Example from datfile (18F14K22):
CP0=ON,OFF
CP1=ON,OFF
CPB=ON,OFF
CPD=ON,OFF
With this you can look at the datasheet and see what each one does.
PICInfo makes this much easier.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PICInfo does indeed make things easier. That's why I was eternally grateful to Trev.
I too was often trying to find the .dat file and having to scan through it playing spot the difference.
MicroChip deciding to have different names for the code protection config bits in different devices seems rather foolish to me. Why is it not possible for them to have a "global" code protection bit name of "CP" which set CP0, CP1 and CPB all on? Keep the individual ones if you want to maintain the flexibility, but wouldn't it have been easier for everyone? If the 16F1829 range came after the 18F14K22, why not match CP0, CP1 and CPB all to CP? Of course it isn't just the code protection bits that are different. In some devices the "pins" are named PortA.0, in some they're GP.0. You'd like to have thought they could have stuck to one naming convention.
Is there any wonder I tend to stick to one range of devices?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any wonder I tend to stick to one range of devices?
Now imagine that Evan and Hugh have to cover the entire spectrum of chip families for both PIC and AVR.
Recently I did a GCB project where I had to cover every single chip in over 6 PIC 18F Familys (and several sub families) where numerous registers and PPS were involved. And it was mostly written in ASM. Was a nightmare for sure in regards to register and bit names . But got it done.
Microchip certainly missed the ball on register naming /consistency. But sadly there is no going back. Let's hope they do better moving forward.
Last edit: William Roth 2021-01-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't envy anyone trying to make sense of Microchip's thought processes. GCB is the reason I'm here and not using MPLab. It totally fried my brain!
I'm eternally grateful for the existence of GCB and thank Evan, Hugh and all that contribute to GCB every minute I'm working with it. Otherwise I'd probably be battling with Mikroe Pascal, possibly their "C" compiler (hoping I've spelled that correctly) or still using PicAxe.
Last edit: mkstevo 2021-01-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@mkstevo- I erased a picaxe 28x2 (18f25k22) and a 20x no problems with pickit.
Sad but had made the change to gcb.
Picaxe and gcb both use basic but implement say serial comm in different ways.
Translating picaxe to gcb can be a pain if you've not used picaxe for a while. @mkstevo- gcb is better than picaxe imho.
the irony is I use avr as gcb choice device :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As I've said before, I rather liked PicAxe. It brought me back to microcontrollers. I've dabbled briefly with mBed, Arduino and other similar devices. My problem was that I just couldn't get my head around what I actually needed to make the "bare" processors work, and what I needed to program those bare devices. For a commercial product such as we make at work, I don't want (or need) to be fitting full Arduino/mBed shields. With PicAxe I could see that all I needed was the device and a download header. From that point, I could see a path to the products I needed to design.
The lack of speed of the PicAxe due to it being interpreted was a problem on one design which was designed to spot a falling object (size of a ping pong ball) having dropped 1m. When I calculated the time the ping pong ball was going to be in the range of my sensor and the length of time that it would take the PicAxe to check two banks of 9 individual IR transmitter/receiver pairs it was close to the limit of reliability and repeatability. I looked for something that would be quicker, and preferably fit the existing PCBs without modification. Noting that the 14M2 was a 16F1825 in disguise I started looking. I tried MPLab but couldn't make any sense of it at all. I don't think I ever got a simple LED blink program to compile. Again, I just couldn't "see" the path to a successful project in MPLab. I failed to get the correct compiler set for the processor and gave up. I did try Mikroe but it seemed very heavily biased towards libraries (that I couldn't see). {I may be totally wrong in this, it was almost ten years ago. I apologise to Mikroe if I'm not painting an accurate picture of their products.} I found GCB and absolutely loved it. The whole process of starting with a blank page and then building a program in GCB, compiling, programming, all suits my thought process perfectly.
I might have stuck with PicAxe for less speed critical programs had they kept their Mac products up to date. Sadly, they have not.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've all but given up trying to "convert" PicAxe programs to GCB. I find that if I print out the PicAxe version, I can then type it in as a new GCB program quicker, and with less errors than attempting to convert one already written. By the time I've searched and replaced all those EndIf statements to End If, replaced all the returns with End Sub, swapped the labels for Sub xxx, re-arranged the Do Whiles, re-declared the variables, replaced Symbol with #Define or Dim... Well I could have made progress writing the whole thing properly, and end up with something that has less errors and is more efficient due to the better program structure capabilities of GCB - proper functions and sub routines with parameters for starters.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@mkstevo-Hi. picaxe was cool when I first used it but then the weird variable use and speed
issues were a problem. I have happy memories of my robots and getting a ssd1306 working with forum help.
...but then I found gcb about 4 years ago...nuff said.
Some gcb projects are from picaxe that Evan and his mates have converted from
picaxe. Glcd devices like ili9341 and ssd1306 and VL0X laser rangefinder
have come from me posting to picaxe forum begging.
Gcb creators have their own agendas but thankfully sort time for hardware requests
from us..or leasts try. Very nice, cheers .
like you I have my favourite chip I like ...it's a 328 though :(
and that's not the bare blank chip, which I haven't tried as it looks inconvenient/not as easy.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have much to learn about gcb but like the hardware device support.
I like the glcd support and also have a favourite ili9341 glcd that if you nag get identify
pixel colour and touch control. Brill!
get a LGT8F328P nano for £2 . it's in the gcb rc releases and is great for fast graphics...
seems sorted like it's a nano but runs at 32mhz, got it's own programmer
to select in programmer preferences.
get 2, they good fun.
this is the nano vs lgtnano https://www.youtube.com/watch?v=doeI0XINim4
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have a number of old projects that use PicAxe processors. Slowly I'm converting these to raw PIC devices using Great Cow Basic. As this leaves me with spare PicAxe devices, I've been re-programming them and restoring them to their original PIC devices. The 08M2 becomes a 12F1840, the 14M2 16F1825 and the 20M2 becomes my favourite device, the 16F1829.
I have one or two odd devices, the first of which is the 20X2. This turns out to be an 18F14K22 which is similar to, and has the same pinout as the 1829. As I have PCBs ordered that use the 1829, and limited 1829's to hand I thought I'd repurpose the 20X2 and put it to use. I'm working on my WS2812clock at the minute which uses an 1829 so I thought I'd use the code for that.
I simply changed my #Chip definition to: #Chip 18F14K22, 64 (from 16F1829, 32) and recompiled. I got a warning: Warning: Configuration setting not valid: CP=ON
It took me a while to figure out why this was and quite what was meant by this. After searching the datasheet I eventually spotted that CP1 and CP2 are the configuration bits for Code Protection. As I use code protection by default at work, I also do at home. Commenting out the line: #Config CP=On the program compiled and programmed. It didn't immediately work running at 64MHz, presumably it was sending the data for the WS2812 LEDs too fast. Once set to 32MHz, it does work correctly.
The 18F14K22 device seems to support code protection, is there a reason why GCB does not allow it?
Configs are very different across chips. Use PICINFO (withIn RC38) to see the differences.
Great Cow BASIC supports all valid configs.
To be explicit using PICINFO.
The attachment show the huge differences. And, shows the PICInfo reveals. :=-)
Last edit: Anobium 2021-01-29
I see, I think.
So are you saying for the 18F14K22 I should set CP0=0, CP1=0?
And for the 16F1829 I should set CP=0?
Last edit: mkstevo 2021-01-29
Not say that - the config is specific for the chip. There is no general rule. CP, CPD and CPxx ... all do different things.
I would use the datasheet or PICINFO to ensure it is correct.
Last edit: Anobium 2021-01-29
The datasheet implies that it should be CP0 and CP1? CPD protects the EeProm I think.
Trev's PICInfo shows them as available too.
Of course the later PICInfo doesn't work on my Mac!
Yes the config is different. Summary. Always check.
Re PICINFO for Mac. I have put the source on GitHub and you can compile a version for the Mac for your own use. :-) Simples. Download the XOJO IDE and run it. You may have to tweak the UI but that is the fun of Open Source.
Oh dear, I don't want to load another IDE and toolset. Thanks for the offer though!
Mind you, Trev's version is showing information that the newer version isn't. Surely that's a retrograde step?
I can confirm that setting the #Config for CPB, CP0 and CP1 does indeed seem to activate code protection. I've written then read the device with and without to confirm. The first block of code is within the "boot block" and should also be protected. CPD will prevent EeProm from being read if set on.
The IDE allows you to compile and use the MAC version. Dead easy and it fun to learn.
What is missing from the new version? There is a lot more functionality than the early version. What did I miss?
Good news on config.
Dead easy? I can show myself up with the simplest of things...
The data in your picture seemed not to be showing the options for CP0, CP1 and CPB?
Before PICInfo was available I would simply open up the chipdata file and go to the end of the file and look at the valid config setting for the chip. Faster than looking at the datasheet which may or may not give the same names used by the inc file or the GCB datafile.
Example from datfile (18F14K22):
CP0=ON,OFF
CP1=ON,OFF
CPB=ON,OFF
CPD=ON,OFF
With this you can look at the datasheet and see what each one does.
PICInfo makes this much easier.
PICInfo does indeed make things easier. That's why I was eternally grateful to Trev.
I too was often trying to find the .dat file and having to scan through it playing spot the difference.
MicroChip deciding to have different names for the code protection config bits in different devices seems rather foolish to me. Why is it not possible for them to have a "global" code protection bit name of "CP" which set CP0, CP1 and CPB all on? Keep the individual ones if you want to maintain the flexibility, but wouldn't it have been easier for everyone? If the 16F1829 range came after the 18F14K22, why not match CP0, CP1 and CPB all to CP? Of course it isn't just the code protection bits that are different. In some devices the "pins" are named PortA.0, in some they're GP.0. You'd like to have thought they could have stuck to one naming convention.
Is there any wonder I tend to stick to one range of devices?
@mkstevo
Now imagine that Evan and Hugh have to cover the entire spectrum of chip families for both PIC and AVR.
Recently I did a GCB project where I had to cover every single chip in over 6 PIC 18F Familys (and several sub families) where numerous registers and PPS were involved. And it was mostly written in ASM. Was a nightmare for sure in regards to register and bit names . But got it done.
Microchip certainly missed the ball on register naming /consistency. But sadly there is no going back. Let's hope they do better moving forward.
Last edit: William Roth 2021-01-31
I don't envy anyone trying to make sense of Microchip's thought processes. GCB is the reason I'm here and not using MPLab. It totally fried my brain!
I'm eternally grateful for the existence of GCB and thank Evan, Hugh and all that contribute to GCB every minute I'm working with it. Otherwise I'd probably be battling with Mikroe Pascal, possibly their "C" compiler (hoping I've spelled that correctly) or still using PicAxe.
Last edit: mkstevo 2021-01-31
@mkstevo- I erased a picaxe 28x2 (18f25k22) and a 20x no problems with pickit.
Sad but had made the change to gcb.
Picaxe and gcb both use basic but implement say serial comm in different ways.
Translating picaxe to gcb can be a pain if you've not used picaxe for a while.
@mkstevo- gcb is better than picaxe imho.
the irony is I use avr as gcb choice device :)
As I've said before, I rather liked PicAxe. It brought me back to microcontrollers. I've dabbled briefly with mBed, Arduino and other similar devices. My problem was that I just couldn't get my head around what I actually needed to make the "bare" processors work, and what I needed to program those bare devices. For a commercial product such as we make at work, I don't want (or need) to be fitting full Arduino/mBed shields. With PicAxe I could see that all I needed was the device and a download header. From that point, I could see a path to the products I needed to design.
The lack of speed of the PicAxe due to it being interpreted was a problem on one design which was designed to spot a falling object (size of a ping pong ball) having dropped 1m. When I calculated the time the ping pong ball was going to be in the range of my sensor and the length of time that it would take the PicAxe to check two banks of 9 individual IR transmitter/receiver pairs it was close to the limit of reliability and repeatability. I looked for something that would be quicker, and preferably fit the existing PCBs without modification. Noting that the 14M2 was a 16F1825 in disguise I started looking. I tried MPLab but couldn't make any sense of it at all. I don't think I ever got a simple LED blink program to compile. Again, I just couldn't "see" the path to a successful project in MPLab. I failed to get the correct compiler set for the processor and gave up. I did try Mikroe but it seemed very heavily biased towards libraries (that I couldn't see). {I may be totally wrong in this, it was almost ten years ago. I apologise to Mikroe if I'm not painting an accurate picture of their products.} I found GCB and absolutely loved it. The whole process of starting with a blank page and then building a program in GCB, compiling, programming, all suits my thought process perfectly.
I might have stuck with PicAxe for less speed critical programs had they kept their Mac products up to date. Sadly, they have not.
I've all but given up trying to "convert" PicAxe programs to GCB. I find that if I print out the PicAxe version, I can then type it in as a new GCB program quicker, and with less errors than attempting to convert one already written. By the time I've searched and replaced all those EndIf statements to End If, replaced all the returns with End Sub, swapped the labels for Sub xxx, re-arranged the Do Whiles, re-declared the variables, replaced Symbol with #Define or Dim... Well I could have made progress writing the whole thing properly, and end up with something that has less errors and is more efficient due to the better program structure capabilities of GCB - proper functions and sub routines with parameters for starters.
@mkstevo-Hi. picaxe was cool when I first used it but then the weird variable use and speed
issues were a problem. I have happy memories of my robots and getting a ssd1306 working with forum help.
...but then I found gcb about 4 years ago...nuff said.
Some gcb projects are from picaxe that Evan and his mates have converted from
picaxe. Glcd devices like ili9341 and ssd1306 and VL0X laser rangefinder
have come from me posting to picaxe forum begging.
Gcb creators have their own agendas but thankfully sort time for hardware requests
from us..or leasts try. Very nice, cheers .
like you I have my favourite chip I like ...it's a 328 though :(
and that's not the bare blank chip, which I haven't tried as it looks inconvenient/not as easy.
I have much to learn about gcb but like the hardware device support.
I like the glcd support and also have a favourite ili9341 glcd that if you nag get identify
pixel colour and touch control. Brill!
get a LGT8F328P nano for £2 . it's in the gcb rc releases and is great for fast graphics...
seems sorted like it's a nano but runs at 32mhz, got it's own programmer
to select in programmer preferences.
get 2, they good fun.
this is the nano vs lgtnano
https://www.youtube.com/watch?v=doeI0XINim4
There is much to learn in Great Cow BASIC... and, there is even more in the next Release Candidate. :=)