Picaxe 14m2 Pinout
James Gillock
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.
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.
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.
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.
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.
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.
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.
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'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.
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!