#7 New Processor Documentation needs updating

[fazzitron]

The documentation on how to add a new processor found here needs updated. Without scouring the source code, it can be hard to find what the layout for the array indices are.

[Molnár Károly]

For this operation I wrote some perl scripts. These can be found in the svn repository: https://sourceforge.net/p/gputils/code/HEAD/tree/trunk/scripts/tools/

device-manager.pl, cfg-import.pl, build-register-db.pl
(Loosely linked here: device-help.pl)

Usually I refrain from that I write longer texts. I can hardly English. The translate.google during the translation often doing stupid things. I do not want to annoy anyone with this. It would be ridiculous the many error. Therefore, I do not like to deal with this. Borut could better in English, but he is no longer with us.

Károly

[fazzitron]

Ok, so here are my results from running the scripts after finding the correct way to alter gpprocessor.c in the source code. I will try to keep my English simple.

perl device-manager.pl -lg | grep "16f84fx"

Output:

The following header name differ from the device name in the gputils:

+-------------------+----------------------+
| device | header file |
+-------------------+----------------------+
| p16c52 | p16c5x.inc |
| p16c54b | p16c54a.inc |
| p16cr54b | p16cr54a.inc |
+-------------------+----------------------+
pic16f84fx

---

perl cfg-import.pl

Gives many errors saying "Database error in descriptor of _ at _: This CONFIGREG_INFO_TYPE empty!"
Also states several MCU are not supported

---

perl build-register-db.pl

successfully creates gpreg-table.c that contains p16f84fx.

---

make
make install

Compiles and installs. However, 16f84fx_g.lkr and p16f84fx.inc are not located with installation.

---

Am I missing a step?

Thank you

[Molnár Károly]

"perl device-manager.pl -lg"

Description of this command: "Lists all MCU is what gputils know."
I think that is not what you wanted.

"16f84fx" -- Does not exist this type of processor.

---

A new device, so you can add: perl device-manager.pl -a -p 16cr926
(Need to try so device that is not yet included in the gputils, otherwise ambiguous results are obtained.) The following files are generated:

16cr926_g.lkr.gen -- To be renamed onto 16cr926_g.lkr .
gpprocessor.c.gen -- To be renamed onto gpprocessor.c .
p16cr926.inc.gen -- To be renamed onto p16cr926.inc .
p16f1xxx.inc.gen -- This is now not necessary.
p18cxxx.inc.gen -- This is now not necessary.

The three remaining files should be moved to:

16cr926_g.lkr ==> gputils/lkr/16cr926_g.lkr
gpprocessor.c ==> gputils/libgputils/gpprocessor.c
p16cr926.inc ==> gputils/header/p16cr926.inc

You then need to edit the appropriate Makefile.am and Makefile.in files:

gputils/lkr/Makefile.am and Makefile.in

16cr84_g.lkr \
16cr926_g.lkr \  <-- New line.
16f1454_g.lkr \

gputils/header/Makefile.am and Makefile.in

p16cr84.inc \
p16cr926.inc \  <-- New line.
p16f1454.inc \

---

cfg-import.pl

This can only must run if new mplabx was issued by the Microchip. (In this case generally is updated the 8bit_device.info file.) In the database there are errors, these indicates the script.

The following files are generated:

gpcfg-table.c
gpcfg.h

These files should be moved to:

gpcfg-table.c ==> gputils/libgputils/gpcfg-table.c
gpcfg.h ==> gputils/libgputils/gpcfg.h

---

build-register-db.pl

This creates a database (of registers and bits) for the gpdasm. This always need to run, but only if the device-manager.pl is already ran and took place after, the next file movings also! This is necessary, because the build-register-db.pl script reads the gputils/libgputils/gpprocessor.c. See the relevant option:

   -gp <path> or --gputils-path <path>

        Path to gputils source files.

The following files are generated:

gpreg-table.c
gpregister.h

These files should be moved to:

gpreg-table.c ==> gputils/libgputils/gpreg-table.c
gpregister.h ==> gputils/libgputils/gpregister.h

---

The following two commands can be issued only after these:

make
make install

---

I hope to understandable the description.

Károly

[fazzitron]

Thank you! Given what you said, I now understand what to do! I will do this to make sure it works. Also, if you would like, I can write the process in English for you so that you can update your documentation.

[fazzitron]

Ok, I try with fresh source code:
perl device-manager.pl -a -p 16f84fx

I get:
addition_helper2(): This device: 16f84fx not exist in the 8bit_device.info!

It does not exist there because it should not. Why does this error occur?

[Molnár Károly]

"Also, if you would like, I can write the process in English for you so that you can update your documentation."

That would be good.

---

"16f84fx"

I do not know why you force this type. This message is not accidental:
"This device: 16f84fx not exist in the 8bit_device.info!"
The Microchip is not produced this type of processor. Therefore not listed in the database (8bit_device.info). Such processor must try which is exists and is not included in the gputils. Therefore, I wrote in the example of an old-type processor (16cr926). The newer ones are in already in the gputils, with these there is no make sense to try.

[fazzitron]

I am sorry, I did not realize I had not mentioned this. 16F84FX is a processor we had created for our company. It is similar to the 16F84A, but with extra memory. We had tried changing the .lkr, but we were still getting errors in trying to link it. So, we decided to try to just add our processor as a new processor to see if that would fix it.

[Molnár Károly]

This is a serious problem, since the script from the database you are taking out lot of information.

There is a need the matching files (p16f84fx.inc and 16f84fx_g.lkr) of processor. Must a complete description of the config bits and the memory regions. We need a new coff ID that does not conflict with anything (in the future neither). Because we do not know, what the Microchip will be manufactured in the future. This should be described in a separate file and this would also have to read the scripts (device-manager.pl, cfg-import.pl, device-help.pl). It would be complicated. --- Suddenly that's all I remembered.

Remark: If you change the original files (p16f84a.inc and 16f84a_g.lkr), there may be problems with the copyright. I do not know what would be a good solution. I do not know the legal stuff.

[fazzitron]

Thanks again. I was able to create the p16f84fx.inc and 16f84fx_g.lkr files and add them all manually. However, I am still having linker issues. However, I feel this might be due to SDCC as everything else seems to be in order.

[Molnár Károly]

Does not succeed the compilation? The SDCC also need to support this processor. But sooner here in the gputils must to solve the support. Thereafter, if you have a request in this context, you may write from the problem to the SDCC project. Currently I maintain the support of the PIC series at SDCC. :-)

[fazzitron]

I actually already put in a help request with SDCC. After a while of waiting, I decided to try here.

[Molnár Károly]

Since the processor (and the manufacturer) there is no information available on the internet, so it not possible to add in the official gputils project.

[fazzitron]

We are going to put together a more comprehensive spec sheet than what we have now to help fix this issue. I hope to have it available next week.

[Molnár Károly]

On Fri, 05 Sep 2014 19:13:07 +0000
"fazzitron" sleija@users.sf.net wrote:

We are going to put together a more comprehensive spec sheet than what we have now to help fix this issue. I hope to have it available next week.

I suggest that the name of the processor commence with one or more letters.

---

[support-requests:#7] New Processor Documentation needs updating

Status: open
Group: v1.0_(example)
Created: Wed Aug 13, 2014 03:22 PM UTC by fazzitron
Last Updated: Wed Aug 20, 2014 07:49 AM UTC
Owner: Molnár Károly

The documentation on how to add a new processor found here needs updated. Without scouring the source code, it can be hard to find what the layout for the array indices are.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/gputils/support-requests/7/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[fazzitron]

The official part name is "AS_MCU1". Will that suffice?

Also, what information would be necessary to add a processor in gputils? I know that various memory locations are needed as seen in gpprocessor.c. Is that all that is necessary?

Thanks again for all your help!

[Molnár Károly]

Perhaps it would be better a similar name: AS84FX
In my opinion thus the name a bit refers onto the original type (pic16f84) processor.

Also, what information would be necessary to add a processor in gputils? I know that various memory locations are needed as seen in gpprocessor.c. Is that all that is necessary?

Thus the support would be fairly limited. Because the gpasm the 14-bit processors case of - unlike the mpasmx - the __config directive next to supports the CONFIG directive as well. This is only possible if the necessary config bits there are included in the gpcfg-table.c file. For the gpdasm program necessary the names of the SFRs and bits, included in the gpreg-table.c file. These informations is derived from the DEVICE.inc file (names of SFRs and bits) and the 8bit_device.info file (config bits and others). (Large part the latter, there are in the include file also.) The "DEVICE.inc" of course refer to the include file belongs to the device. For example: as84fx.inc (as84fx.lkr)

[fazzitron]

Ok, I got busy a few weeks ago and had to take a break from this problem. I finally had time to get back to it Friday. Still no progress.

Here are the edits I have made.

gpcfg-table.c
Placed after "PIC16f84"

{ "PIC16F84FX" , 1, PIC16F83_addrs },

gpreg-table.c
Placed after p16f84a

/--------------------- p16f84fx ---------------------/

static const gp_register_t p16f84fx_registers[] = {
&p10f200_INDF, / 0x0000 /
&p10f200_TMR0, / 0x0001 /
&p10f200_PCL, / 0x0002 /
&p10f320_STATUS, / 0x0003 /
&p10f200_FSR, / 0x0004 /
&p16c554_PORTA, / 0x0005 /
&p16c432_PORTB, / 0x0006 /
&p16c84_EEDATA, / 0x0008 /
&p16c84_EEADR, / 0x0009 /
&p12c671_PCLATH, / 0x000A /
&p16c84_INTCON, / 0x000B /
&p16c432_OPTION_REG, / 0x0081 /
&p16c554_TRISA, / 0x0085 /
&p16c432_TRISB, / 0x0086 /
&p16c84_EECON1, / 0x0088 /
&p16c84_EECON2 / 0x0089 */
};

16f84fx.inc
Essentially the same as 16f84

16f84fx.lkr

LIBPATH .

CODEPAGE NAME=page0 START=0x0 END=0x3FF
CODEPAGE NAME=page1 START=0x400 END=0xFFF
CODEPAGE NAME=.idlocs START=0x2000 END=0x2003 PROTECTED
CODEPAGE NAME=.config START=0x2007 END=0x2007 PROTECTED

DATABANK NAME=sfr0 START=0x0 END=0xB PROTECTED
DATABANK NAME=sfr1 START=0x80 END=0x8B PROTECTED

DATABANK NAME=gprs START=0xC END=0x4F

SECTION NAME=PROG0 ROM=page0 // ROM code space
SECTION NAME=PROG1 ROM=page1 // ROM code space
SECTION NAME=IDLOCS ROM=.idlocs // ID locations

I do not understand what is wrong. Our processor has the memory size of the 16f88, yet the memory locations of the 16f84. I have example code that compiles perfect as a 16f88. Yet, when I try to compile as a 16f84fx, I still get these errors:

error: no target memory available for section "ID_main_2"

With all of my changes, why am I still running out of memory?

[fazzitron]

The compile command that fails is:

gplink.exe -c -I "C:\Program Files (x86)\SDCC\non-free\lib\pic14" pic16f84.lib -
I "C:\Program Files (x86)\SDCC\lib\pic14" libsdcc.lib -I "C:\Program Files (x86)
\SDCC\lib\pic14" libm.lib -o output/main.hex -s 16f84fx.lkr crt0.o libastro_io.o output/main.o

The 16f84 has the same memory addresses, so I do not think it needs to change.

[Molnár Károly]

gpcfg-table.c
Placed after "PIC16f84"

{ "PIC16F84FX" , 1, PIC16F83_addrs },

Must place at beginning in the "gp_cfg_devices" table, because it's not original processor:

    { "16F84FX" , 1, PIC16F83_addrs },

Thereafter need to increase the value of the "gp_cfg_device_count" constant:

const int gp_cfg_device_count = 670;

          ||
          \/

const int gp_cfg_device_count = 671;

---

gpreg-table.c
Placed after p16f84a

/--------------------- p16f84fx ---------------------/

static const gp_register_t p16f84fx_registers[] = {

This not original processor:

static const gp_register_t _16f84fx_registers[] = {

Must place at beginning in the "gp_register_db" table:

  { "16f84fx"       ,  16, _16f84fx_registers      },

Thereafter need to increase the value of the "gp_register_db_size" constant:

const int gp_register_db_size = 669;

          ||
          \/

const int gp_register_db_size = 670;

---

Thereafter need to place the following record to beginning of the "struct px pics" table in the gpprocessor.c file:

  { PROC_CLASS_PIC14    , "__16F84FX"     , { "16f84fx"        , "16f84fx"        , "16f84fx"         }, 0x0084,  4,    2, { 0x0C, 0x4F },    -1, {     -1,     -1 }, 0x00213F, 0x000400, { 0x000400, 0x0020FF }, { 0x002000, 0x002003 }, { 0x002007, 0x002007 }, { 0x002100, 0x00213F }, "16f84fx.inc"      , "16f84fx.lkr"       , 0 },

---

16f84fx.inc
Essentially the same as 16f84

Not exactly.

        IFNDEF __16F84FX

---

This has to be in the 16f84fx.lkr file:

// File: 16f84fx.lkr
// Generic linker script for the 16F84FX processor.

LIBPATH .

CODEPAGE   NAME=page0      START=0x0               END=0x3FF
CODEPAGE   NAME=page1      START=0x400             END=0x7FF
CODEPAGE   NAME=page2      START=0x800             END=0xBFF
CODEPAGE   NAME=page3      START=0xC00             END=0xFFF
CODEPAGE   NAME=.idlocs    START=0x2000            END=0x2003         PROTECTED 
CODEPAGE   NAME=.config    START=0x2007            END=0x2007         PROTECTED 
CODEPAGE   NAME=eedata     START=0x2100            END=0x213F         PROTECTED 

DATABANK   NAME=sfr0       START=0x0               END=0xB            PROTECTED
DATABANK   NAME=sfr1       START=0x80              END=0x8B           PROTECTED

SHAREBANK  NAME=gprnobank  START=0xC               END=0x4F
SHAREBANK  NAME=gprnobank  START=0x8C              END=0xCF           PROTECTED

SECTION    NAME=PROG0      ROM=page0           // ROM code space
SECTION    NAME=PROG1      ROM=page1           // ROM code space
SECTION    NAME=PROG2      ROM=page2           // ROM code space
SECTION    NAME=PROG3      ROM=page3           // ROM code space
SECTION    NAME=IDLOCS     ROM=.idlocs         // ID locations
SECTION    NAME=DEEPROM    ROM=eedata          // Data EEPROM

---

If all this is done, then there is more work. Need to change the followings:

header/Makefile.am, header/Makefile.in

HEADER_FILES = \
    16f84fx.inc \
    coff.inc \

lkr/Makefile.am, lkr/Makefile.in

    16f84a_g.lkr \
    16f84fx.lkr \
    16f84_g.lkr \

Now it is possible compile and install the gputils.

---

If the compilation of the example code does not succeed, will be needed a minimal source code, which causes the error.

[fazzitron]

Minimal source code is tricky. Not only is the error caused by larger sources, but our core also requires a few sources for functionality and/or readability. But, I am putting together as simple an example as I can.

Also, thank you for your continued help. You have no idea how much it is appreciated.

[Molnár Károly]

Unambiguous, that if I can then i'll help you.

[fazzitron]

To make sure it wasn't my setup, I tried building gputils from a fresh download of the source. Unfortunately, I didn't have any better resutls. So, I have attached a small example. What it does is loops the numbers 0 through 7 to a 7-segment display output. Here is the structure of it.

src
    ./main.c
chip
    ./include
        ./flex.h
        ./astro.h
        ./newAstro.h
        ./oldAstro.h
        ./timing.h
    ./lib
        ./libastro_io/libastro_io.o
        ./crt0/crt0.o
        ./ln/16f84fx.lkr

./chip/include contains all of the necesarry files include files for the code to compile.
    ./flex.h: basic pin functions
    ./astro.h: Contains all our memory locations and the special way we access them. Essentially, we use the original locations of PortA and PortB as a 16-bit address for an area of extended memory. Let me know if this is confusing. I can try to explain it better.
    ./new(old)Astro.h: Assembly funtions. Since SDCC changed how it handles assembly, we have functionality for both.
    ./timing.h: Simple timing functions. It is also what causes the problem in this case.

./lib contains lower level files necessary for gplink. libastro_io is just functional version of macros used elsewhere. crt0 starts our code. I included the .lkr file so I can call in manually from the command prompt.

I have also included the Makefile I've been using. It should run in both Windows and Linux, but I have only been using it in Linux. Hopefully that isn't a problem. It will send everything to the output folder.

Thank you again for your help. Sorry for the size. I really did try to keep it down. Luckily, all 3 astro files can be ignored as they are primarily macros.

[Molnár Károly]

I hope that at the end of the week, I'll have time to look.

[fazzitron]

Thank you very much.