Support for new PICs

[cuistax]

Hello again,

As I said earlier, I would be happy to add support for other PIC models.

I noticed that many newer PIC actually have 2 config words, CONFIG1 and CONFIG2, located at address 0x8007 and 0x8008 (see for instance the datasheet of PICS 16F1825/16F1829).

I believe it is not currently supported.
How easy would it be to make PicPas handle 2 config words ?

In the mean time, I could add support for the PICs that still use a single config word.
Do you have a list of favorite models that you would like to see supported in priority ?

[t-edson]

Hi.
I think it's easy to add support to 2 config word. Just need to define the syntax and implement it. Let me check.

I don't have a special list. You can add what you consider important. One detail, Some definitions need to be completed.
To add new devices, actually, it's needed to update the library https://github.com/t-edson/PicUtils that is waht PicPas use.

[t-edson]

PICS 16F1825 and 16F1829 are part of the new Enhanced Mid-Range Core 16F. They have a very different architecture from the classic 16F PICs. PicPas has not support to this models by the moment. Implementation require a considerable work.
First step would be to create new units for models this new architecture.

[cuistax]

Hello,
I'm curious, what is causing the most trouble ?
The handling of INDF & PCLATH registers, the stack ?
The rest I believe is just metadata from the compiler point of view (like the number of banks, the number of registers...)

[cuistax]

Regarding the support of additional PICs, I had a look at file Pic16Devices.pas.

I am concerned that the current way of defining models (through source code) will not scale very well with a growing number of supported models. It's ok for a small number of models, as it is the case now, but it will be hard to maintain with ten times more models.

I think those definitions could better be off-loaded to external files (like .xml or .csv files) and loaded at runtime. It least it would make the process of adding PIC models easier. What do you think ?

I will think about it and probably come up with a concrete proposition.

[t-edson]

There are a lot of differences on working with the Enhanced architecture. First of all PicPas is not only a compiler/IDE, it's a simulator too, and it's all integrated.
What does it mean? First of all PicPas use a object what models the PIC device (TCompilerBase.pic of the class TPIC16). This object represent a real PIC16 device including the CPU core, registers, FLASH and RAM memory (and peripherics on the future).
Compiling a program is doing writing to the FLASH memory of the object device. Simulating a program is just running the CPU of the object. Debuggin a program is inspect the internal register of the object.
This object (the class TPIC16) can represent all of the Microchip devices of the Mid-Range PIC models, like the PIC16F84 or the PIC16F887, because all the models of the Mid-Range share the same base architecture. It's just an issue of activating more or less memory (in some special positions), banks or pages, and some minor differences.
The Enhanced Mid-Range PICs have a different architecture. It's not just a case of incrementing the number of banks. Fundamentals registers like PORTA or WREG are mapped in a different way. Also there are new instructions in the CPU core and I don't know if the old Opcodes are the same.
It's possible to extend TPIC16 to modify his internal architecture (just activating some flags) and transform in a Enhanced CORE, but I think it could be a bit complex mantaining (and understanding).
I think the better approach to the implementation of the new Enhanced Core, could be to create a new clase (something like TPIC16En) to model the new architecture and then to create a base clase to derivate the two architectures.
One detail to consider is that compiler for the new core needs a new simulator too.

[t-edson]

Defining new devices can be done in compilation time, including the definition in the source file. Just check the README.md file, in the description of the directives $SET_STATE_RAM, $SET_MAPPED_RAM, $CLEAR_STATE_RAM:

//Define hardware
{$SET PIC_MODEL='MY_PIC'}
{$SET PIC_MAXFREQ = 1000000}
{$SET PIC_NPINS = 18}
{$SET PIC_NUMBANKS = 2}
{$SET PIC_NUMPAGES = 1}
{$SET PIC_MAXFLASH = 1024}
//Clear memory state
{$SET_STATE_RAM '000-1FF:NIM'}
//Define RAM state
{$SET_STATE_RAM '000-00B:SFR, 00C-04F:GPR'}
{$SET_STATE_RAM '080-08B:SFR, 08C-0CF:GPR'}
//Define mapped RAM
{$SET_MAPPED_RAM '080-080:bnk0, 082-084:bnk0, 08A-08B:bnk0'}
{$SET_MAPPED_RAM '08C-0CF:bnk0'}

A real device would be more complex but the idea is the same.
Althought it's possible to define all the devices this way, I think it's better to have a internal definition of the more common devices, just for better compilation time.

[cuistax]

Hello,
I have tried adding a new imaginary PIC named PIC16FXYZ, based on the PIC16F84A.

I put the PIC16FXYZ.pas in the "units" folder.
When I compile test_PIC16FXYZ.pas in PicPas, it says "Unknown device : PIC16FXYZ".

What else should I do ?

Please find files hereafter:
files.zip

[cuistax]

Nevermind I got it working.
I figured out the "{$PROCESSOR ...}" directive must NOT be used in that case.

Thanks anyway!

I join the fixed files in attachment, just for the record.
files2.zip

[t-edson]

Good. That's is exactly how new devices must be defined in compilation time. Using directives and putting all of them in a separated unit. In this case it's not necessary to use {$PROCESSOR ...}

In fact {$PROCESSOR ...} is just an abreviated form for all directives defining a device, but {$PROCESSOR} it's faster because use internal declarations (defined in Pic16Devices.pas).

[cuistax]

Hey,

I have added units to cover the whole PIC mid-range models.
I did not update the models for which there was already a unit file.
Let me know what you think.

Pull request: #40

[t-edson]

Good. I will commit and review. Now all Mid-range models will be covered by PicPas.

Thanks.

[cuistax]

Oops it looks all new unit files were wrongly added to the root folder instead of the "units" folder.
Maybe now is a good time to move all device unit files to a dedicated "/devices" folder, as suggested in #23.

[t-edson]

OK. I'm going to create a new branch to define the folder "/devices" in order to avoid compatibility problems. I will be the 0.8.5 version. I' going to include new changes too, about graphical interfaz of the debugger.

[cuistax]

There are a lot of differences on working with the Enhanced architecture.

Absolutely.
The thing is, most new PIC16s put on the market today use the Enhanced Architecture.
And they come with exciting features, like Core Independent Peripherals.
I think PicPas would be even more attractive if it was supporting them, don't you think ?

I think the better approach to the implementation of the new Enhanced Core, could be to create a new clase (something like TPIC16En) to model the new architecture and then to create a base clase to derivate the two architectures.

I understand the challenge.
How about doing the exercise for the baseline model range first ?
Their architecture is much closer to the Mid-Range architecture (almost the same, only with less features).
It would be a start to make PicPas more modular regarding supported PIC architectures.

I can quickly provide the device/unit files for the baseline models, if it helps ;)

[t-edson]

I think PicPas would be even more attractive if it was supporting them, don't you think ?

Definitely. It's just not implemented by now.

How about doing the exercise for the baseline model range first ?

Good excercise.

I can quickly provide the device/unit files for the baseline models, if it helps ;)

OK. I have opened the branch 1.4 for PicUtils: https://github.com/t-edson/PicUtils and created two new units: PicBaseDevices.pas and PicBaseUtils.pas.
I'm not sure if those are the best name (Pic10Utils.pas is better?) for the units but it can be changed later.
This units needs to be changed to model the architecture of teh Baseline devices. I have realized that maybe a new code generator is needed. We will see.

[cuistax]

Very good!

On my side I have added device units for PIC baseline models (all models existing at this time): #44

The list of added models is:

PIC10:
PIC10F200 PIC10F202 PIC10F204 PIC10F206 PIC10F220 PIC10F222

PIC12:
PIC12F508 PIC12F509 PIC12F510 PIC12F519

PIC16:
PIC16F54 PIC16F57 PIC16F59 PIC16F505 PIC16F506 PIC16F526 PIC16F527 PIC16F570

[cuistax]

I'm not sure if those are the best name (Pic10Utils.pas is better?) for the units but it can be changed later.

PicBaseUtils is definitely a better name than Pic10Utils since, as you can see in the post above, the baseline range contains PIC10, PIC12 and even some PIC16 models.

And, since you are asking my opinion ;), I take this opportunity to raise another point : I have been trying to read the source code (because I would like to be able to also help in that department) but unfortunately it's hard for me to make sense of it, as it requires spanish language skills that I don't have. It's not impossible, but it makes it harder to understand.

I fully understand the reason, but if it does not make a big difference for you, it will be much easier for others to contribute if english was predominantly used instead.
You will be reaching a much wider audience.

Anyway, that's my 2 cents.

[t-edson]

On my side I have added device units for PIC baseline models (all models existing at this time): #44

Good. But It won't work.
Doing:

{$SET PIC_MODEL    = 'PIC10F200'}
{$SET PIC_MAXFREQ  = 4000000}
{$SET PIC_NPINS    = 8}
{$SET PIC_NUMBANKS = 1}
{$SET PIC_NUMPAGES = 1}
{$SET PIC_MAXFLASH = 256}

Just will set the 14 bits PIC core. And all the other functions like compiling, assembling, linking and simulating, will be applied to the same 14 bits Mid-range core. Even the *.hex will be for 14 bits.

We need to have another PIC core in the compiler (some like the TPIC16 class). That's why we need to create the units PicBaseDevices.pas and PicBaseUtils.pas, including new memory models, new instructions, new SFR, new memory manager rouitines, new *.HEX file, ...

Then we need to see, How to include this new PIC object in the compiler? How to swicht the compiler, linker and code generator in the compiler when a Baseline device is used. All of this after create a new compiler, linker and code generator for the Baseline.

OK I will modify the PicBaseDevices.pas and PicBaseUtils.pas files. Can you tell me:
How many RAM banks have the Baseline? In Mid-range there are 4 max.
How many FLASH pages have the Baseline? In Mid-range there are 4 max.

[cuistax]

Good. But It won't work.

Yes I know. I was just doing my part ;)

How many RAM banks have the Baseline? In Mid-range there are 4 max.
How many FLASH pages have the Baseline? In Mid-range there are 4 max.

It ranges from 1 page / 1 bank (PIC10F200) to 4 pages / 8 banks (PIC16F570).

Here's an exhaustive list:

Model		Nb. Pages		Nb. Banks
PIC10F200		1		1
PIC10F202		1		1
PIC10F204		1		1
PIC10F206		1		1
PIC10F220		1		1
PIC10F222		1		1
PIC12F508		1		1
PIC12F509		2		2
PIC12F510		2		2
PIC12F519		2		2
PIC16F505		2		4
PIC16F506		2		4
PIC16F526		2		4
PIC16F527		2		4
PIC16F54		1		1
PIC16F57		4		4
PIC16F570		4		8

Also, please note that pages are 512-words long and not 2048-words long as in the Mid-Range.

[cuistax]

I made this small document for myself some time ago, maybe you will find it useful.
It's still a work in progress.
PIC Architectures Comparison v0.1.pdf

[t-edson]

And, since you are asking my opinion ;), I take this opportunity to raise another point : I have been trying to read the source code (because I would like to be able to also help in that department) but unfortunately it's hard for me to make sense of it, as it requires spanish language skills that I don't have. It's not impossible, but it makes it harder to understand.

OK. I will be translating in successive versions. It will take some time. Ayway If you have some question
just ask. A compiler is a complex program but PicPas pretend to be modular so no need to understand all the code.

There is also a Technicall documentation, but it's in spanish too. I can share it if you need.

[cuistax]

Then we need to see, How to include this new PIC object in the compiler? How to switch the compiler, linker and code generator in the compiler when a Baseline device is used. All of this after create a new compiler, linker and code generator for the Baseline.

As for the switch of compiler, maybe a directive in the units will do, like:

{$SET PIC_ARCH = 'Baseline' }
{$SET PIC_ARCH = 'Mid-Range'}
{$SET PIC_ARCH = 'Enhanced' }

...with 'Mid-Range' being the default if none is specified, for backward compatibility.

If it's specified in every device unit file, the user wouldn't even have to worry about it.

[t-edson]

I was thinking in something like that. A directive before all PIC definitions directives. That would change switch the current PIC device (compiler, linker, assembling, code generator, simulator). Other option I considered was using differentes object PIC:

{$SET PICBASE_MODEL = 'PIC10F200'}
{$SET PICBASE_MAXFREQ = 4000000}
{$SET PICBASE_NPINS = 8}
{$SET PICBASE_NUMBANKS = 1}

This have some advantages, like having static fields.

Why PIC_ARCH? I prefer something like PIC_FAMILY.

"Enhanced" could be ambiguous, because I read there is a Baseline Enhaced.

[t-edson]

I am changing the "PicBaseUtils" and I have defined most off the stuff for the 12 bits Core. It will be ready soon. But there is a lot of work later when implementing a code generator for 12 bits, that can be copied in most from the 14 bits code generator.
It would be good if you can help on implementing the code generator. I think the type DWORD must not be supported in this family.

[cuistax]

I guess I could try. What functions need to be updated exactly ?

[t-edson]

First I'm going to create the units then you would see what is needed.

[t-edson]

I don't really finish on understand the TRIS instruction in the Baseline. The Opcode is:
0000 0000 0fff
But the datasheet say "f" can be 6, 7 or 8 for some models. How can you codify 8 in 3 bits? If you use 000, it is another Opcode.

[cuistax]

According to my tests with mpasmx, the TRIS instruction accepts operands between 5 and 9.

And according to the disassembly below, it seems the instruction encoding is:

Instruction  Opcode(Hex)  Opcode(Binary)
-----------  -----------  ----------------
TRIS 5       005          0000 0000 0101
TRIS 6       006          0000 0000 0110
TRIS 7       007          0000 0000 0111
TRIS 8       008          0000 0000 1000
TRIS 9       009          0000 0000 1001

So, it seems there's actually two encodings for this instruction: 0000 0000 01xx and 0000 0000 10xx.

This has been tested on the PIC10F200 and the PIC16F570 (the two extremes of the baseline range) and the result is identical.

Disassembly (under MPLAB IDE):

[t-edson]

OK. I's done that way too in https://github.com/t-edson/PicUtils. It's strange some datasheet are wrong or have incomplete information.
Now the library PicUtils have (very) experimental support to the Baseline PIC devices. It's only lacking to update the file PicBaseDevices.pas
In theory, it's possible to create easily an assembler/disassembler for the family of the PIC PIC10F200, using https://github.com/t-edson/PicUtils. Even a basic simulation could be done (Not sure).

It'a a good progress :) .

[t-edson]

The next step is to make PicUtils works in PicPas. The first unit to modify is "GenCodBas_PICBase.pas". It includes some basic routines of the Code Generator. You can download de Source of PicPas (and update PicUtils too) and try to compile inlcudind the Unit GenCodBas_PICBase in the FormPrincipal.pas unit (Uncomment line 12) and you will see the errors in "GenCodBas_PICBase.pas", mainly because of the lack of the instructions ADDLW or SUBLW. It's needed to adapt the code using other instructions.

[t-edson]

I have updated de unit GenCodBas_PICBase.pas. Next Step is create the unit GenCod_PICBase and here is where all the operations of the Code Generator are implemented. This will take some time.
I've realized that the name GenCod_PIC10 is visually easier to identify than GenCod_PICBase. I'm considering to change all the prefix, and leave in "_PIC16" for the Midrange and "_PIC10" for the Baseline.

[cuistax]

Ok, even though I guess you already know that "PIC10" refers to 6-pin devices, and not the baseline range.
Likewise, "PIC16" is not an exact match for Mid-Range devices either.

But I guess it does not matter much what the class is named in the source code. Code readability is a good point.

What matters most, on the other hand, is the PIC architecture directive that users specify in their source code, which should be as unambiguous as possible.

[t-edson]

Yes. I know the name PIC10 is not exactly, as PIC16 is not too. They are just nomenclatures used in the source code to improve the readability. It's because a number helps to associate a PIC family when using a composite name. Later we can use PIC17 and PIC18 for the others families. I don't know the criterias Microchip use to asign name to his PIC families but I guess it could be done better.

[t-edson]

Unit GenCod_PIC10 is ready!!! with some operations not implemented and not tested yet, but we can say the Baseline have a code generator now.
The next step is to create the units ParserAsm_PIC16.pas and ParserDirec_PIC16.pas that are the Parsers for the ASM blocks and the DIRECTIVES. They should be similar to the PIC16 series so I hope there are only minor changes.
By the way, I have modified several units in the folder "/devices" to add the directive:
{$CLEAR_STATE_RAM}

and define the commom RAM, using:
{$SET_MAPPED_RAM '0F0-0FF:bnk0'}
{$SET_MAPPED_RAM '170-17F:bnk0'}
{$SET_MAPPED_RAM '1F0-1FF:bnk0'}
or some similar for each model.

A revisions of all units may be needed. I was thinking on creating new folders, something like: /devices10, /device16, /device18 ... It's some confusing to have diferent families of units in one folder.

[cuistax]

Excellent.

I can update the device models to include the missing directives.

Regarding devices folders. What grouping do you suggest ? If that can help, I made a table below to summarize what models are present in what range line.

The way I see it, it can be grouped, either:
a) by "range" : Baseline/Mid-Range/Enhanced Mid-Range, but then you have a mix of model numbers in each group
b) by model number prefix : PIC10 / PIC12 / PIC16, but then you have a mix of families in each group

So, it's not about choosing the best way, it's more about choosing the less wrong ;)

Baseline      Mid-Range     Enhanced Mid-Range
---------     ---------     ------------------
PIC10F200     PIC10F320     PIC12F1501
PIC10F202     PIC10F322     PIC12F1571
PIC10F204     PIC12F609     PIC12F1572
PIC10F206     PIC12F615     PIC12F1612
PIC10F220     PIC12F617     PIC12F1822
PIC10F222     PIC12F629     PIC12F1840
PIC12F508     PIC12F635     PIC16F1454
PIC12F509     PIC12F675     PIC16F1455
PIC12F510     PIC12F683     PIC16F1459
PIC12F519     PIC12F752     PIC16F1503
PIC16F505     PIC16F610     PIC16F1507
PIC16F506     PIC16F616     PIC16F1508
PIC16F526     PIC16F627     PIC16F1509
PIC16F527     PIC16F627A    PIC16F1512
PIC16F54      PIC16F628     PIC16F1513
PIC16F57      PIC16F628A    PIC16F1516
PIC16F570     PIC16F630     PIC16F1517
PIC16F59      PIC16F631     PIC16F1518
              PIC16F636     PIC16F1519
              PIC16F639     PIC16F1526
              PIC16F648A    PIC16F1527
              PIC16F676     PIC16F15313
              PIC16F677     PIC16F15323
              PIC16F684     PIC16F15324
              PIC16F685     PIC16F15325
              PIC16F687     PIC16F15344
              PIC16F688     PIC16F15345
              PIC16F689     PIC16F15354
              PIC16F690     PIC16F15355
              PIC16F707     PIC16F15356
              PIC16F716     PIC16F15375
              PIC16F72      PIC16F15376
              PIC16F720     PIC16F15385
              PIC16F721     PIC16F15386
              PIC16F722     PIC16F1574
              PIC16F722A    PIC16F1575
              PIC16F723     PIC16F1578
              PIC16F723A    PIC16F1579
              PIC16F724     PIC16F1613
              PIC16F726     PIC16F1614
              PIC16F727     PIC16F1615
              PIC16F73      PIC16F1618
              PIC16F737     PIC16F1619
              PIC16F74      PIC16F1703
              PIC16F747     PIC16F1704
              PIC16F753     PIC16F1705
              PIC16F76      PIC16F1707
              PIC16F767     PIC16F1708
              PIC16F77      PIC16F1709
              PIC16F777     PIC16F1713
              PIC16F785     PIC16F1716
              PIC16F818     PIC16F1717
              PIC16F819     PIC16F1718
              PIC16F83      PIC16F1719
              PIC16F84      PIC16F1764
              PIC16F84A     PIC16F1765
              PIC16F87      PIC16F1768
              PIC16F870     PIC16F1769
              PIC16F871     PIC16F1773
              PIC16F872     PIC16F1776
              PIC16F873     PIC16F1777
              PIC16F873A    PIC16F1778
              PIC16F874     PIC16F1779
              PIC16F874A    PIC16F1782
              PIC16F876     PIC16F1783
              PIC16F876A    PIC16F1784
              PIC16F877     PIC16F1786
              PIC16F877A    PIC16F1787
              PIC16F88      PIC16F1788
              PIC16F882     PIC16F1789
              PIC16F883     PIC16F1823
              PIC16F884     PIC16F1824
              PIC16F886     PIC16F1825
              PIC16F887     PIC16F1826
              PIC16F913     PIC16F1827
              PIC16F914     PIC16F1828
              PIC16F916     PIC16F1829
              PIC16F917     PIC16F18313
              PIC16F946     PIC16F18323
                            PIC16F18324
                            PIC16F18325
                            PIC16F18326
                            PIC16F18344
                            PIC16F18345
                            PIC16F18346
                            PIC16F18424
                            PIC16F18425
                            PIC16F18426
                            PIC16F18444
                            PIC16F18445
                            PIC16F18446
                            PIC16F18455
                            PIC16F18456
                            PIC16F1847
                            PIC16F18854
                            PIC16F18855
                            PIC16F18856
                            PIC16F18857
                            PIC16F18875
                            PIC16F18876
                            PIC16F18877
                            PIC16F19155
                            PIC16F19156
                            PIC16F19175
                            PIC16F19176
                            PIC16F19185
                            PIC16F19186
                            PIC16F19195
                            PIC16F19196
                            PIC16F19197
                            PIC16F1933
                            PIC16F1934
                            PIC16F1936
                            PIC16F1937
                            PIC16F1938
                            PIC16F1939
                            PIC16F1946
                            PIC16F1947

[t-edson]

I prefer to group by Baseline/Mid-Range/Enhanced Mid-Range
But using a number, according to the compiler code used in PicUtils:

• PIC10 -> Compiler for Baseline
• PIC16 -> Mid-Range
• PIC17 -> Enhanced Mid-Range (Not yet implemented)
• PIC18 -> High performance (Not yet implemented)

So we can have different folders: /devices10, /devices16, /devices17, /devices18, that will be useful and secure considering that we have different compilers for different families. So we can indicate to a specific compiler searchs his units in a specific path and avoid try to compile a different family (This happened in some test I made, and the compiler crashsed).

By the way, When updating fodler /devices I remember I found a Mid-Range PIC model that have not a unit created. I don't remember the code.

[t-edson]

Finally I got a functional class TCompiler_PIC10, that is the compiler object for the Baseline family. :)
The problem now is how to integrate this new compiler to the IDE. I guess I have to modify the IDE design to make it "multi-compiler". There are some forms that need to be implemented too, like the debugger and some aditional units like "CodeTools" and see if they can be modified to work like "multi-compiler". There is some work to do first before having a "Hello world" for a PIC10F200.
Some doubts I have are: What is the format of an *.hex file for the Baseline family? How the CONFIG word is defined?

[cuistax]

Hi,

I just saw you had to fix several unit files. There was indeed an issue in the baseline headers I created, the mirrored registers were not correctly set.

For instance, you changed the file for to PIC16F57 as follows in commit 2f1b1259999dc93a2fa26b30048377fd3930f540

BEFORE:                             AFTER:
-------                             ------
{$SET_STATE_RAM '000-007:SFR'}      {$SET_STATE_RAM '000-007:SFR'}
{$SET_STATE_RAM '008-01F:GPR'}      {$SET_STATE_RAM '008-01F:GPR'} 
{$SET_STATE_RAM '028-03F:GPR'}
{$SET_STATE_RAM '048-05F:GPR'}
{$SET_STATE_RAM '068-07F:GPR'}
                                    {$SET_STATE_RAM '020-03F:GPR'}
                                    {$SET_STATE_RAM '040-05F:GPR'}
                                    {$SET_STATE_RAM '060-07F:GPR'}

                                    {$SET_MAPPED_RAM '020-02F:bnk0'}
                                    {$SET_MAPPED_RAM '040-04F:bnk0'}
                                    {$SET_MAPPED_RAM '060-06F:bnk0'}

It's indeed more accurate, but still not completely right.

For instance, registers 0x20 to 0x27 are defined as GPR registers but in reality they are mirrors of SFR registers 0x00 to 0x07 (as set by the SET_MAPPED_RAM directive).

Taking that point into account, I think the most accurate definition would be:

  {$SET_STATE_RAM '000-007:SFR'}  // INDF, TMR0, PCL, STATUS, FSR, PORTA, PORTB, PORTC
  {$SET_STATE_RAM '008-01F:GPR'} 
  {$SET_STATE_RAM '020-027:SFR'}  // mapped RAM
  {$SET_STATE_RAM '028-02F:GPR'}  // mapped RAM
  {$SET_STATE_RAM '030-03F:GPR'} 
  {$SET_STATE_RAM '040-047:SFR'}  // mapped RAM
  {$SET_STATE_RAM '048-04F:GPR'}  // mapped RAM
  {$SET_STATE_RAM '050-05F:GPR'} 
  {$SET_STATE_RAM '060-067:SFR'}  // mapped RAM
  {$SET_STATE_RAM '068-06F:GPR'}  // mapped RAM
  {$SET_STATE_RAM '070-07F:GPR'} 

  {$SET_MAPPED_RAM '020-02F:bnk0'}
  {$SET_MAPPED_RAM '040-04F:bnk0'}
  {$SET_MAPPED_RAM '060-06F:bnk0'}

Would you agree with that ?
If so I will update header files accordingly.

[t-edson]

OK. I agree. Please update the units. And if it's needed include the new directive $SET_UNIMP_BITS1 to define unimplemented bits read always as "1".

[t-edson]

Hi. Someone has noted the configuration bits defined in unit PIC16F877.pas seems to be wrong:

// WDTE : Watchdog Timer Enable bit
  {$define _WDTE_ON      = $13BFF}  // WDT enabled
  {$define _WDTE_OFF     = $3BFF}  // WDT disabled
 
  // FOSC : Oscillator Selection bits
  {$define _FOSC_EXTRC   = $63BFF}  // RC oscillator
  {$define _FOSC_HS      = $43BFF}  // HS oscillator
  {$define _FOSC_XT      = $23BFF}  // XT oscillator
  {$define _FOSC_LP      = $3BFF}  // LP oscillator

Because the length of the word is only 14 bits.

[cuistax]

Yeah, good catch !
I will fix it ASAP.

[t-edson]

Good. Some user is collaborating with the units for the Enhanced Mid-range. You can check it in the Lazarus forum.

[cuistax]

Good. Some user is collaborating with the units for the Enhanced Mid-range.

Well, you should have asked me, I already made them ;)
I thought you were not ready to work on that.

Let me know if you want them (I have 119 files ready).

[cuistax]

And if it's needed include the new directive $SET_UNIMP_BITS1 to define unimplemented bits read always as "1".

Someone has noted the configuration bits defined in unit PIC16F877.pas seems to be wrong

Both issues are fixed. Check out #49

[t-edson]

Some observations:
The Max frequency for PIC16F84A is 20Mhz. You set to 4MHz.
There are some wrong mapped address, in some file like PIC16F84.pas:
{$SET_MAPPED_RAM '08C-0CF:bnk1'} // maps to area 00C-04F (bank 0)
This is wrong because the mapped must be to bank0.

[t-edson]

Well, you should have asked me, I already made them ;)
I thought you were not ready to work on that.
Let me know if you want them (I have 119 files ready).

I didn't know you have made it. Please upload them to /devices17. I have created a new compiler (PIC17) to support this new family. It's just a test no yet functional but can be used to test the Devices units.
By the moment I'm focused on improve the simulator to automate the test, for the PIC10 and PIC16 compilers.

[cuistax]

Some observations...

Yes, another good catch !

These are fixed in #50

[cuistax]

Please upload them to /devices17

Enjoy : #51 !

[cuistax]

Just a quick note about the /devices16 folder, I think the two following files should be deleted:

• PIC12F675A.pas (that model does not exist, PIC12F675.pas is the file to keep)
• PIC16F570.pas (that model is a baseline model, it's already present in /devices10)

I can do it if you want.

Also, you were previously talking about missing models, do you remember what those were ?

[t-edson]

I can do it if you want.

Yes. Do it please.

I don't remember what were the missing models but I will tell you if I find them again.