Part 1So, we bought all the necessary. It is time to deploy an experimental laboratory!
We put the software that comes with the programmer: PICKit2 Utility and MPLAB IDE. The first is the utility for working with the programmer, the second is the development environment. PICKit2 Utility, in principle, we do not need, but there is one point that I will mention later. For now, let's move our attention to MPLAB IDE.
')
MPLAB IDE
Open the development environment and create a new project. One of the drawbacks of this IDE is the lack of sticky panels; instead, we have a jumble of windows. To be able to live on, I arranged everything in the usual way (the window was reduced so that the picture would fit):
upd: everything sticks perfectly! We click on the icon in the upper left corner of the window, select Dockable in the menu, then drag it to the border. Thank you
lunatik42 for the info!
File> New ;
File> Save as ... , select the Assembly type, set the Add to project checkbox. Yes, we will code in assembler.
You also need to specify the IDE that we use the assembler.
We go to
Project> Select Language Toolsuite ... and select Microchip MPASM Toolsuite:

Now go to
Project> Build options ...> Project , there we have compilation settings. On the “MPASM / C17 / C18 Suite” tab, select the absolute code generation:

When writing absolute code, we can specify for ourselves which addresses our code and data are located at. When writing portable code, the compiler steers memory itself, but for this it is necessary to bathe with sections, so far we don’t need it.
On the MPLAB Assembler tab, you can disable case-sensitive variables. I decided not to disconnect.
Well, to make life easier, we go to
Edit> Properties ... There we set the display of line numbers and change the font to taste. I put Lucida Console 8 pins to fit more code into the window.
Again materiel
Our current task is to write the minimum amount of code that will be compiled to try to flash the controller. As a result, we will get several lines of code, but to write them you will have to read a lot of documentation. We need two sources: the
datasheet and the built-in IDE manuals (
Help> Topics ...> MPLAB Assembler ), which open in a separate window and do not interfere with the process. There is a table with a set of commands and a description of all directives; If you find an incomprehensible word in the code, then after interpretation it is necessary to climb there.
In the “8.0 Instruction Set Summary” section of the datasheet, a detailed description of the command system is given, I recommend to carefully read this section.
Minimum code
Okay, you can finally do a little bit - we can do it!
Let's start from the end and write a single line:
end
We compile on F10, we get a successful build and an error, saying that it’s impossible to load something there. We also get the Vorning from the compiler, which does not like the directives at the beginning of the line - this is not a problem, we shift our end by one tab. As for the error, its reason is in the absence of the configuration of the stone. The config is essentially a 12-bit word that is written into the stone during the firmware; in AVR stones, this is called fuse-bits. The meaning of each bit is described in the datasheet, section "7.1 Configuration Bits".
And now the quest for attention! What did we forget to do? We forgot to specify under which stone our code should be collected. To do this, go to
Configure> Select Device ... and select our stone - PIC12F509. The IDE boasts a bunch of possibilities that it provides for this stone:

But what if we suddenly want to use a different development environment? To do this, we can specify the type of stone directly in the code, this is done using the list directive. After reading the manuals for this directive, it becomes clear that you need to write the following (do not forget about the tab at the beginning):
list p = 12f509
The type of stone specified in the settings is transmitted to the compiler via the command line, and it has higher priority over the list directive. Therefore, if you specify one stone in the settings, and write another in the directive, the code will be compiled under the stone specified in the settings, while the compiler will issue the “Processor superseded by command line.” Verify processor symbol ".Stone, we have indicated. Now we recall that in the section “4.3 Data Memory Organization” it is written that the registers of our stone lie in the address space of the data memory. To access them by name, not by address, we include the header file:
#include p12f509.inc
In addition to the addresses of registers, the numbers of configuration bits are written there - what we need right now. You can also add this file to the project in order to see all the constants defined by it in the symbol list.
Now we can set the configuration. It can be specified in
Configure> Configuration bits ... , but for better portability and easier access, it is better to do it right in the code, for which the __config directive will help us. Open our incloud and look at the section "Configuration bits". Bits are named according to datasheet.
We need the following configuration: MCLR is disabled (works like a normal pin), code protection is disabled, the watchdog timer is disabled, an internal generator is used for clocking. Thus, our config will take the following form:
__config _IntRC_OSC & _CP_OFF ​​& _WDT_OFF & _MCLRE_OFF
Note that the values ​​are combined with an “AND”. At first, out of habit, I wrote everything through “OR”, and then I wondered for a long time why nothing worked.So, this is what we ended up with:
list p = 12f509
#include p12f509.inc
__config _IntRC_OSC & _CP_OFF ​​& _WDT_OFF & _MCLRE_OFF
end
Compile ... successfully! As I promised, a few lines and a lot of documentation.
Take the iron
That is the moment you have been waiting for! If you scroll the page in search of the place where the story finally reaches iron, then it's time to stop and start reading :)
So, we have a programmer, a microcontroller, a program and unhealthy enthusiasm to combine it all. And now we are tormented by only one question: what to connect with?
We climb to the datasheet, section 7.12 “In-Circuit Serial Programming” and see the following image:

We don't have Normal Connections yet, so we only look at the connection of the legs of the programmer with the feet of the stone. Okay, what with the connection we realized, now we need to find where these pins grow from on the stone and on the programmer.
From the
manuals to the programmer, we learn the purpose of his conclusions:

In the datasheet (section “Pin Diagrams”) we see the microcontroller outputs:

Now we look at the stone.

We are perplexed. Well, at what corner does he have the first conclusion? Where is the top and where is the bottom? To understand this, we climb into Wikipedia and read about the
DIP-package . From there we learn that the pins are numbered counterclockwise from the semicircular serif:

It turns out that the caring guys from Microchip even put a dot for us near the first output.
We finally get a breadboard! I connected everything as follows:

The same is true in augmented reality, as
rule has quite accurately put it:

Stitching
We are just a few clicks from the long-awaited result! So, we connect our programmer, if it is not yet connected, then in MPLAB we climb in the Programmer menu and select our programmer - PICKit2. A programmer's messages tab will open in the output window, where he will cheerfully report on his readiness. And we will have this panel to control the programmer:

We need the leftmost button - “Program the target device”. Click!
If we did everything right, a progress bar will run down below, and messages on the mashing and writing of program memory will appear in the output window. My congratulations, the stone is stitched! :)
In the next part, we will write HelloWorld, and I will also tell you why we might still need the PICKit2 Utility. See you!
The end of the second part.Part 1