Program pic microcontrollers and coding language?

[MrAl]

Well i want to try to learn how to program some pic microcontrollers and i know nothing. right now i am getting over wellmed and i need some guidance. 
What is some easy reading that will show working sample code and how it works, how i can use it to make more complex things?

the most i gotten in to was some arduino code that worked as a ROM switcher for my Commodore 64 witch i have working and works good switching 4 banks ina nd out on my EPROM. And a 10M CW beacon for a friend but that was all code that i found online.

I ordered some PIC12F675 to upload "picdiv"  for an over complicated digital clock running off a 10Mhz OCXO because i was board and it would be cool. 
but i would all so like to play with the PIC12F675 i ordered the only thing i seen on youtube was people making lights blink.

Hi there,

If you want to get started with the PIC chips you should check out the forum for that there is a forum just for Microchip products.  They have people that help there.  They had a better forum before that, but for some reason they seem to have switched to a different one.

Anyway, it is true that PIC chips are harder to program than Arduinos, but if you go to the Microchip site (or whatever they call it now) you can download examples.  They have quite a collection last time I checked.

Assembler for the 12F675 is not that bad because there are not many instructions to learn, but if you never programmed like that it may be hard to grasp.  You have to visualize what each instruction does and how it affects the registers and the outside world pins.
Also, the 12F675 is probably the easiest chip to learn that also has a built in AD converter, and you definitely want that or you miss out on a lot.
Programming in ASM (assembler) means you will also learn the registers in the chip, and there are quite a few registers.  To see if this is something you might want to do, download the data sheet for the chip and take a quick look through it.  See if the descriptions of the registers make sense to you.  If they don't you will have to read more on this or watch some videos.
The registers control everything, even the clock speed.  To use the AD converter or the built in EPROM you will have to look up code for that because there are special sequences you have to execute to get these to work, although some of that may be on the data sheet.  They also control the interrupts.

There's also another pdf file that you should download that tells you the basic operation of the mid range chips.  It's the reference manual for Midrange Pic chips.

If you have doubts that your current programmer can handle a pic like the 12F675, you might download the programming reference manual also, but it may be hard to follow.

ASM is great if you want to take complete control over every aspect of the chip.  You can see what every step is doing.  It takes longer to write a program though, and to do math you usually have to download a math library.  That would be a set of code you use in a routine to do the regular math like adding 32 bit numbers and stuff like that.  If you intend to display any data on an LCD, you also need a conversion routine to convert from the N bit 'hex' numbers into M digit decimal representation.  For example, 0x0F would convert to "15" which you could then send to the display.

The C language makes it faster to program, but you do lose some of the details of the why the chip handles certain operations.  A lot of people choose this though because with ASM it takes a long time to produce a complex program.

There's also memory 'banks' that you have to consider, via none other than the registers.  Some registers are stored in one bank, the others in the secondary bank.  You have to pay attention when to switch banks if using ASM.  The 12F675 has two banks, and some chips have more than two banks.

It can be a lot of fun to get one up and running after studying the resistors and the instructions.

If you get the PICKit 3 you will of course get a manual with that which should get you started.  I have not used that particular one though so I can't say how good it works.  You do have to make sure the kit you get handles your chip, if you end up getting a ready made programmer.
They also make prototype boards with support components.  They would also come with examples and also you can program the chips with that, but the chip parts they can handle may be limited you'd have to check that.

One of the nicest things about the PIC chips is that you can use the low power mode, and also set the chip into a sleep mode.  This allows you to use very little power for applications that only have to measure something once in a while, like every 10 minutes or something like that.  You can create a temperature meter for monitoring a freezer that uses two AA batteries and they last for 2 years.  This is harder to do with the Arduino, but if you like using the chip they use for the Uno for example you can learn to program that or use the IDE and a programmer and start with the raw chip.  That would be a bit more versatile although you have to add support components.

There are a lot of options out there:
1.  Raw Pic chips.
2.  Development board for Pic chips.
3.  Raw Arduino chips.
4.  Arduino dev boards.

It's amazing what these chips can do.  Years ago it would take a LOT more hardware to get even close to what these chips can do.  I've been involved in development of such hardware years ago and it was almost nuts compared to today with the huge number of microcontrollers out there.

[MarkF]

I think you're refering to pickit2, the pickit3 works perfectly, at least until v6.10 which I used last time.

Edit: pickit 3 support was gone in v6.25, happened just 6 months ago:
https://www.microchip.com/en-us/about/media-center/blog/2024/discontinued-ide-support-for-gen3-tools

No.  I am talking about the PICKit 3.
Yes, MPLAB X newer versions list the PICKit 3 in its list of programmers.

But those newer versions of MPLAB X running on Win7 do not recognize that the PICKit 3 is plugged in.
You can fool around and get it to appear 1% of the time if you're lucky.
Verion 3.55 connects first time, every time without issue.

Just my experience.  Take it or leave it.

[DavidAlfa]

No idea, might be caused by Win7, works perfectly fine in W10 or W11.

[lakis70]

How hard is to read the datasheet and read-write some registers that govern the pic periferals?

Dont use mplab or request a free hard disk from Microchip with theirs staff. Use open source tools

[wilfred]

How hard is to read the datasheet and read-write some registers that govern the pic periferals?

Dont use mplab or request a free hard disk from Microchip with theirs staff. Use open source tools

Don't forget you're replying like that in the beginner's section.  And people in forums might also seek to find like-minded people with whom they might share their interest. Obviously not you.

[SteveThackery]

Well, I still think PIC is the wrong place to start. Start with Arduino, then graduate to PIC.

[mikeselectricstuff]

12f675 is pretty old - I'd suggest using something more recent like the 16F15313/325/345 etc. series- more peripherals, most pins can map to any peripheral, and a range of different pin counts for essentially the same part. Also cheaper.

[DavidAlfa]

I'd say the opposite, Arduino won't teach anything about the hardware and the CPP libraries won't help either.
Pic 12/16/18 registers have the complexity of Lego, and it only needs setting up ~5 registers to get it up and running.

[tooki]

…
As others have suggested, the Arduino might be the best (easiest) way to learn coding in that it will teach some (but not all) coding fundamentals and it provides a ton of readily available resources.  In addition to being a gateway into software it sits close to the entry level intersections of software and hardware, analog and digital, and electricity itself - it has a lot to like for beginners who want to learn and explore by project building.
…
Another path - harder but potentially super valuable - would be with C (and/or C++).

Huh? Arduino is C/C++.

Learning programming involves multiple things:
1. learning how to think in logical steps, and how to structure software
2. learning the programming language
3. learning the target hardware/environment/framework

Learning Arduino teaches you the first two, for C/C++.
And nothing in the Arduino framework actually stops you from controlling the hardware directly. You don’t have to use built-in functions, nor libraries. But using them can let you learn #1 and 2 without having to immerse yourself in #3 yet.

Then, when you bump into the limitations of the Arduino framework (for example, if you find that digitalWrite is too slow), you can explore how to get around that. It’s not either-or, it’s a fluid continuum.

[tooki]

I'd say the opposite, Arduino won't teach anything about the hardware and the CPP libraries won't help either.
Pic 12/16/18 registers have the complexity of Lego, and it only needs setting up ~5 registers to get it up and running.

I think it depends entirely on what one’s learning goals are, one’s skills/talents, and on one’s learning style.

Me, for example: I am not a naturally gifted programmer. I’m not the worst, but not the best. If I had had to learn MCU programming completely without the use of libraries (or, god forbid, in assembly) I’d never have been able to do anything useful with MCUs, not because any one aspect of programming is particularly hard to learn, but because learning all aspects of MCU programming (see my previous post) at the same time would just be too much, and a hurdle in one blocks you from learning the others. So for me, and for many others, learning it progressively works better.

IMHO, learning #1 and 2 (in my post above) is more important overall than #3, insofar as #1 and 2 are “portable” skills that one can apply to whatever #3 comes along. In other words, it’s more important overall to learn how to program than to learn the innards of a particular target, because knowing #3 is useless unless you know #1 and 2.

In school, we used STM32 Discovery boards, and sometimes we’d run into some error that required some obscure MCU-specific setting in Keil to be changed for things to work. The teacher understood what it meant, but it was complete gibberish to me, because I didn’t know enough about STM32 to understand what it was. And I didn’t know enough to even understand the documentation about that setting or the error message that prompted it. Without assistance I would have just given up because it was not a surmountable problem. That’s the problem with a lot of bare-metal stuff: beginners don’t yet know enough to even be able to understand documentation, so you can’t dig yourself out with any reasonable amount of effort.


Most of my real coding experience is with the Arduino framework, but what I learned there was directly applicable to both PIC and STM32, the other families I’ve used. (My PIC code is used in managing well over $1 million of liquid xenon, so it has to work. It’s been in use for 2 years and counting, and they haven’t come back for any bug fixes, so it must be working properly.)

[Electro Fan]

…
As others have suggested, the Arduino might be the best (easiest) way to learn coding in that it will teach some (but not all) coding fundamentals and it provides a ton of readily available resources.  In addition to being a gateway into software it sits close to the entry level intersections of software and hardware, analog and digital, and electricity itself - it has a lot to like for beginners who want to learn and explore by project building.
…
Another path - harder but potentially super valuable - would be with C (and/or C++).

Huh? Arduino is C/C++.

Learning programming involves multiple things:
1. learning how to think in logical steps, and how to structure software
2. learning the programming language
3. learning the target hardware/environment/framework

Learning Arduino teaches you the first two, for C/C++.
And nothing in the Arduino framework actually stops you from controlling the hardware directly. You don’t have to use built-in functions, nor libraries. But using them can let you learn #1 and 2 without having to immerse yourself in #3 yet.

Then, when you bump into the limitations of the Arduino framework (for example, if you find that digitalWrite is too slow), you can explore how to get around that. It’s not either-or, it’s a fluid continuum.

With all due respect tooki (and btw I very often read and consistently enjoy and appreciate your posts including the insight you provided in this thread), while Arduino is related to C and C++ and while all 3 are related to each other they are not identical.

So saying “Arduino is C/C++” might be a tad overly simplified.  All matter is made of atoms (I think) but if I learn to shape some matter or apply some matter I haven’t necessarily learned the intricacies of atomic structures.

Of course you know the relationships between Arduino, C, and C++ but a beginner might not know or see the relationships.  Arduino and C and C++ each have some unique attributes.  One unique attribute of Arduino is that it shields beginners from some complexity found in C and C++.  Another unique and valuable attribute of Arduino is that it provides an ecosystem designed to introduce beginners into electricity and hardware along with software.  Different courses for different horses, ie, different “paths” as I suggested in my post.

So, changing metaphors, yes, the beginners wading pool and an Olympic pool both are filled with water.  The activities and levels of challenge in both will provide an exposure to water, no doubt - but is one also the other?

[SteveThackery]

I'd say the opposite, Arduino won't teach anything about the hardware and the CPP libraries won't help either.

That's my point. Arduino gives you an easy on-ramp to programming in C/C++, and getting some cool successes under your belt early on. Once you've got a little way with Arduino, then is the time to get closer to the metal with some PICs.

There is nothing controversial about what I'm saying. Arduino is so incredibly successful because it's the perfect choice for beginners. I did it the other way round: PIC first, then Arduino. I wish I'd done Arduino first, but it didn’t exist back then.

[Electro Fan]

I'd say the opposite, Arduino won't teach anything about the hardware and the CPP libraries won't help either.

That's my point. Arduino gives you an easy on-ramp to programming in C/C++, and getting some cool successes under your belt early on. Once you've got a little way with Arduino, then is the time to get closer to the metal with some PICs.

There is nothing controversial about what I'm saying. Arduino is so incredibly successful because it's the perfect choice for beginners. I did it the other way round: PIC first, then Arduino. I wish I'd done Arduino first, but it didn’t exist back then.

I agree with this - that Arduino provides an easy on-ramp to programming. 

Not to split too many hairs but when we say Arduino doesn’t teach anything about the “hardware” it’s probably worth clarifying what we mean by “hardware.”  For an intermediate to advanced coder hardware can be registers, memory addresses, assembly and machine level code, etc - and no, Arduino isn’t going to provide much visibility into that with the IDE and the typical Arduino beginner environment.  But, for some beginners “hardware’ might be the physical world of circuits including resistors, capacitors, and other passive components, and active components, and it might mean how electricity operates in those circuits (independent of code, or possibly in concert with code). 

Net, net:  Arduino can be a very good on-ramp for beginners interested in electricity or hardware or software - and in the case of software it can provide a good path to C/C++.  So for beginners Arduino is ideal because it provides a path to all 3:  electricity, hardware, and software - and as a result it can help beginners experience the intersections of analog and digital.  Back to PIC, no doubt PIC offered beginners a similar path back in the day and it continues to do so today, but it’s hard to compete with Arduino for “beginners” given all that the Arduino ecosystem offers - including shielding but not locking beginners out of complexities to the extent a beginner wants to go deeper.

[tooki]

With all due respect tooki (and btw I very often read and consistently enjoy and appreciate your posts including the insight you provided in this thread), while Arduino is related to C and C++ and while all 3 are related to each other they are not identical.

So saying “Arduino is C/C++” might be a tad overly simplified.  All matter is made of atoms (I think) but if I learn to shape some matter or apply some matter I haven’t necessarily learned the intricacies of atomic structures.

Of course you know the relationships between Arduino, C, and C++ but a beginner might not know or see the relationships.  Arduino and C and C++ each have some unique attributes.  One unique attribute of Arduino is that it shields beginners from some complexity found in C and C++.

Like what? The fact that it offers a bunch of libraries and functions doesn’t change the fact that the fundamental syntax is bog-standard C/C++. It uses the standard gcc C++ compiler. It’s not similar to C++, it is C++.

Arduino code is, save for calls to its library functions and some macros, portable to standard C/C++ (and the reverse is true too) — but that applies to any environment: the language is not the target/environment/framework. The same caveat applies to every piece of code written for every platform: it has to target something, so the names of system calls or hardware calls will have to be either changed, or use a wrapper of some sort.


I just don’t understand why people discount Arduino as being “not C/C++” simply because it has a few ready-to-use functions, wrappers for main(), and generates function prototypes automatically. The code language is still C++, unambiguously. I feel like people discount Arduino because they’ve been told they should, not because there is any rational reason for doing so.

I’ll spell it out once more (not in this thread, but in many others) since this point still seems to escape many people:
Arduino means 3 things, really:
1. Arduino-branded dev boards and clones thereof
2. The Arduino framework (the libraries)
3. The Arduino IDE

One can pick and choose any combination of these (with the exception that the Arduino IDE only supports the Arduino framework), or replace them with something else. Heck, my favorite combination is non-Arduino ESP32 or STM32 boards using the Arduino framework within the PlatformIO IDE.

But if you’re using the Arduino framework, then you’re using C/C++, and the fundamental C/C++ skills one learns by doing so are absolutely transferable to other environments.

So, changing metaphors, yes, the beginners wading pool and an Olympic pool both are filled with water.  The activities and levels of challenge in both will provide an exposure to water, no doubt - but is one also the other?

The wading and Olympic pools aren’t the same thing — but the water they’re filled with is, and the skills you learn in the water do transfer.

[brumbarchris]

I did it the other way round: PIC first, then Arduino. I wish I'd done Arduino first, but it didn’t exist back then.

I started the same way: PIC first, then other (sometimes higher level) embedded platforms. And I am absolutely thankful it happend this way. I would have had serious difficulties to understand what's happening ''under the hood'' otherwise. Doing a limited amount of assembler and stepping through code, seeing the effect on individual registers at every instruction (and interrupt) was very... eye opening.

Also initially working with resource limited micros, gives you later a better appreciation of the more powerfull platforms you have in front of you, on the desk.

Regards,
Cristian

[SteveThackery]

I started the same way: PIC first, then other (sometimes higher level) embedded platforms. And I am absolutely thankful it happend this way. I would have had serious difficulties to understand what's happening ''under the hood'' otherwise. Doing a limited amount of assembler and stepping through code, seeing the effect on individual registers at every instruction (and interrupt) was very... eye opening.

We can agree to differ on this. In my experience, working at the register level when you just want to multiply two numbers is a pretty steep learning curve. Higher level (than assembly) languages are the right place to learn about some of the universal concepts such as if/then, switch/case, functions, for, while, basic arithmetic, etc.

Once you've got your head around those concepts, then you can have a look at how they are implemented down at the register level.

Also, the great thing about Arduino is how readily you can get some successes under your belt. Your first flashing LED is a "Hah!" moment, and I think that most beginners would get a real kick from modifying 'Blinky' so it flashes "SOS" in Morse code, or whatever. That kind of kick really does motivate you to press on with the next learning challenge.

Anyway, I'll shut up now.  . As I say, we can agree to differ.

[mikeselectricstuff]

There is really no need to do assembler on PICs these days. The C compiler, even in free mode is good enough for the vast majority of cases.  The increased use of banking in larger PICs makes assembler more error-prone

[PGPG]

I did it the other way round: PIC first, then Arduino. I wish I'd done Arduino first, but it didn’t exist back then.

I started the same way: PIC first, then other

Everyone starts as conditions allow.
I have never started with microcontroller programming. In our 2 person team it is my brother who writes microcontroller programs.
Our first microcontroller program should be bug-free from first shot as we had to pay (and it was expensive for us) for EPROM programming service to have it burn into EPROM and you couldn't check it in any way before paying for that service.
It's easy to guess what that program was doing.
No! Like probably no one else our first program was not LED blinking.
It was program for 8048 that was receiving data via RS232 (8048 had no UART so bit by bit byte sending and receiving and whole communication protocol was coded 'manually') and then programming them into EPROM (switching 25V VPP and so on). I have written the program working at IBM-XT to read HEX file and send it by RS232 to our device.

After getting our EPROM programmed first what we have done was to program new EPROM with the same program and check if it is working.
Even programming and verification passed successfully our EPROM didn't worked!
My brother made a mistake resulting in programming all 256 byte pages (except the first one that was programmed correctly) in random locations (verification was done at the same page address so passed).
To avoid paying next time for EPROM programming our next task was to shorten being longer than 2 pages program to fit into one page and be able to program at least 2 pages. Removing all communication error checking and EPROM program verifying we did it being one or two bytes shorter than 256.
Being able to program EPROMs ourselves was the first step to be able to use microcontrollers.

I think one explanation can be needed to people coming from 'normal' countries.
In Poland those time things like EPROM programmer (being imported) had 'normal' prices while everything else (salary and living) was may be 100 times cheaper (my academic teacher salary was about $13 per month). So if someone bought EPROM programmer for his may be 3 month salaries he offered EPROM programming for the price resulting from this.

[brumbarchris]

We can agree to differ on this

I agree.

Why I still look fondly to ''my'' approach is that I continued for a very long time to actually use microcontrollers for low level relates stuff. Only much later did I come across the need to actually multiply numbers or do more complex algorithms with micros and had the need to move to C. To each their own, I suppose.

What I fear is that if you start with such higher level things which shield you to a considerable extent from the register an single cycle stuff, you might not find it necessary to look under the hood until much, much later. And at that point one might find it a nuisance, rather than a natural step.

Regards,
Cristian

[mkube396]

ok there is a lot of reading in here for me to look at here..

right now i might be a little in over my head with the "pic" stuff I guess ill try to focuses on "Arduino" I'm all ready semi familiar with the Arduino IDE
i did try  to understand how to wright code for a month. but i was lost and was not able to get anything i made to work.

[ahsrabrifat]

The easiest way is to download Mikro C for PIC. I has a free version. The coding language is quite easy and there are lots of in built examples.

[shabaz]

i did try  to understand how to wright code for a month. but i was lost and was not able to get anything i made to work.

To get the basics solved first:

A very friendly, beginners book for C programming is:

"Problem Solving and Program Design in C"

An old, used edition of this (no need for the latest) shouldn't cost more than $10.

That will get you familiar with the language, on a PC, within a few weeks with just an hour or two of study every few days.

After that, you'll have a lot more confidence with your Arduino code. It makes little sense to try a PIC for now, because for beginners (who naturally may need some help along the way), there is a lot more beginner material focused on Arduino.

Also, although you may have specific projects in mind, it's worth trying a few simple projects, before embarking on something complex. The simple projects will show you how to use print statements, the serial console for debugging, how to control input and output, and so on. Look around for decent projects (not all are), ideally ones that reveal interesting patterns about structuring things. For instance, at a basic level, look to see how arrays and loops can help reduce coding and potential errors.

Regarding:

"the only thing i seen on youtube was people making lights blink."

That can still be an important step. That exercise shows you how to configure and control outputs to blink the lights. Depending on the blinking project, it may also demonstrate how to pull in libraries of code and call functions to operate more complex LED modules. You could use these concepts for debugging code (for instance, turning on an LED to confirm when your code reaches a certain point).

Then, look to see how some of the extra features inside the microcontroller (known as 'integrated peripherals') are used, again, one feature at a time.

All these things will become the building blocks for larger projects, but one step at a time can be helpful. It's pretty much what I do when using a new microcontroller. First, I'll try blinking an LED. Then, I'll get the serial console operating (known as the UART integrated peripheral) to send print statements for debugging purposes. Then I might try getting a timer running, and seeing how I can get timer events. Then maybe try to make the microcontroller sleep and wake up. All small bite-sized chunks before embarking on a larger project. But first it's worth just concentrating on the C programming language by picking up a book on it, because it doesn't take a lot of time to study and try some of the exercises, and you'll need that knowledge to make your experience with microcontrollers more productive.