• AVR Freaks

Hot!Can't understand PIC32M variable visibility

Page: 12 > Showing page 1 of 2
Author
davepl
New Member
  • Total Posts : 25
  • Reward points : 0
  • Joined: 2016/06/11 01:01:31
  • Location: 0
  • Status: offline
2020/07/25 03:21:31 (permalink)
0

Can't understand PIC32M variable visibility

Hi, in xc8 if I wanted a particular function,variable, bit structure or array visible to another source file in the project I simply included the header file that I declared the variable etc in.
With xc32 functions cross files without declaration ie. int foo(*mem) can be called from the file it was declared in and also from another source file within the project. It has global visibility. But if I have a bit structure   declared in foo's header file which is included from foo's source file it isn't visible in any other source file ie undefined variable.
If I then #include foo.h from the other source file I get multiple definition errors for variables used in functions defined in foo.c from the use of the function from the other source file.
I haven't read the manual from cover to cover but I've read the sections on memory several times.
foo.c includes foo.h, bar.c includes bar.h, function defined in foo.c works in bar.c but the bit structure declared in foo.h isn't visible from bar.c, if I include foo.h in bar.h the compiler says there are multiple declarations of variables not used in bar.* at all.
 
There's a chunk of data removed from gsm.h that contained sensitive base64 stuff, thanks github.
post edited by davepl - 2020/07/26 01:03:01
#1

23 Replies Related Threads

    al_bin
    Super Member
    • Total Posts : 214
    • Reward points : 0
    • Joined: 2011/02/11 06:28:47
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/25 05:07:08 (permalink)
    +1 (1)
    Please show examples.
    In my opinion gcc/xc32 better fit  C standard then xc8
    #2
    NorthGuy
    Super Member
    • Total Posts : 6289
    • Reward points : 0
    • Joined: 2014/02/23 14:23:23
    • Location: Northern Canada
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/25 05:36:59 (permalink)
    +1 (1)
    davepl
    foo.c includes foo.h, bar.c includes bar.h
    ...
    the bit structure declared in foo.h isn't visible from bar.c



    bar.c should #include foo.h, directly or indirectly.
     
    #3
    ric
    Super Member
    • Total Posts : 28365
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/25 06:46:59 (permalink)
    0
    This page gives you a better idea about how you are supposed to organise header and C files in a project.
    Organizing Code Files in C and C++ (Ignore the C++ specific bits)
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #4
    davepl
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2016/06/11 01:01:31
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/25 06:59:03 (permalink)
    0
    NorthGuy
    [
    bar.c should #include foo.h, directly or indirectly.


    This is how I expect it to happen, with linux x86_64 gcc I can include files to my hearts extent but with PIC32MX xc32 if I include foo.h in bar.c or bar.h it gives a multiple definition of variable error for the function call in bar.c to the function in foo.c.
    I'm just working around this atm, it must be a setting somewhere:
    Simple example for @al_bin :
    foo.h
    #include <xc.h>
    uint8_t buffer[512];
    uint8_t workbyte;
    int function(uint8_t, uint8_t*);
     
    Then in foo.c
    #include "foo.h"
    int function(uint8_t count, uint8_t *storage)
    {
              count = storage[8];
              return count;
    }
     
    Then in bar.h
    #include <xc.h>
    uint8_t buffer[512];
     
     and in bar.c
    #include "bar.h"
    int x = function(1, uint8_t buffer);
     
    this compiles fine but if I remove uint8_t buffer[512]; from bar.h and add #include foo.h to bar.h then the compiler says multiple definition of buffer and gives a whole list of link errors.
    I also have a bit structure in foo.h for error flags which are impossible to use across files, foo and bar were  ported from PIC18F47K40 - xc8 and I never had a problem.
    post edited by davepl - 2020/07/25 07:01:31
    #5
    andersm
    Super Member
    • Total Posts : 2839
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/25 07:43:48 (permalink)
    +1 (1)
    This is a definition, not a declaration:
    uint8_t buffer[512];
    uint8_t workbyte;

    By putting these in a header, the definitions are duplicated in every translation unit that includes the header. To make them into declarations, use the "extern" keyword:
    extern uint8_t buffer[512];
    extern uint8_t workbyte;

    As an aside, duplicating a declaration in two headers ("buffer" in both foo.h and bar.h) is a recipe for disaster. Sooner or later, you will change the declaration and forget to change it everywhere. The compiler won't catch it, but your code will just mysteriously break.
    #6
    davepl
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2016/06/11 01:01:31
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/25 07:53:04 (permalink)
    0
    The strangest part of all this is a buffer that is populated in foo.c has the correct information in bar.c although it's declared in both foo.h and bar.h. The only problem I have is a single error flag in a bit structure but with the above logic it will most probably work across files after being declared in both.
    I shall worry about error flags when everything is working.
    Thanks @ric I'm already aware of those pitfalls, I did say PIC32M, it's actually a PIC32MX470F512H the project was on a PIC18F47K40 until I found out that SIM800's TLS wasn't suitable and had to be done in the program.
    #7
    davepl
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2016/06/11 01:01:31
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/25 07:58:05 (permalink)
    0
    andersm
    This is a definition, not a declaration:
    uint8_t buffer[512];
    uint8_t workbyte;

    By putting these in a header, the definitions are duplicated in every translation unit that includes the header. To make them into declarations, use the "extern" keyword:
    extern uint8_t buffer[512];
    extern uint8_t workbyte;

    As an aside, duplicating a declaration in two headers ("buffer" in both foo.h and bar.h) is a recipe for disaster. Sooner or later, you will change the declaration and forget to change it everywhere. The compiler won't catch it, but your code will just mysteriously break.


    I tried extern it doesn't make a difference, if you read above you'll see that the problem is sort of solved but it doesn't work as I would have expected.
    #8
    al_bin
    Super Member
    • Total Posts : 214
    • Reward points : 0
    • Joined: 2011/02/11 06:28:47
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/25 08:03:27 (permalink)
    0
    Show as how you tried.
    #9
    ric
    Super Member
    • Total Posts : 28365
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/25 15:32:20 (permalink)
    0
    al_bin
    Show as how you tried.

    +1.
    You are still not doing it right if you're getting errors.
    H files should only contain declarations, not definitions.
    C files can contain both, but all your definitions must be in C files, and only occur in ONE of them.
    That is what the article I linked to explains in detail.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #10
    davepl
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2016/06/11 01:01:31
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/26 00:00:03 (permalink)
    0
    I should have done this in the first place, I've uploaded the four files to a github repository:
    https://github.com/plater/gsm_tcp
    On line 530 in gsm.c is the function "void gsm_gettime(void)" which is declared in gsm.h on line 121. gsm.h has the global memory declarations used in that function.
    tcpip.c has a call to that function on line 51. The only way I can get this to work, both files are ported from xc8 PIC18F47K40 but I had to comment out the include for gsm.h in tcpip.h to get it to compile. I also had to remove a host of other includes to clib functions like stdin.h, I'm assuming that xc.h takes care of that.
    You will find copied declarations at the top of both tcpip.h and gsm.h eg. uint8_t gsdate[10]; on line 101 in gsm.h you will find "extern struct gsmflags" you will find the same structure without extern on line 30 in tcpip.h to service gsmflags.meerror derived from gsm's "EUSARTG_Read" and used at line 158 in tcpip.c. From what I can understand in the xc32 manual this is the proper use of extern but why can't I simply include gsm.h in tcpip.h
    If I change this to my preferred way of declaring everything in gsm.h and only use tcpip.h for tcpip related stuff, I get all sorts of errors including cryptic link time errors.
    I hit the above multiple link error brick wall trying to port mbedtls and I assumed it was to do with the use of heap memory, BearSSL works but it only uses array buffers.
    I'm concerned when something doesn't work as expected because it can form a hard to fix bug at a later stage.
    post edited by davepl - 2020/07/26 00:42:03
    #11
    ric
    Super Member
    • Total Posts : 28365
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/26 00:24:19 (permalink)
    +1 (1)
    davepl
    ...
    Sorry I couldn't work out how to enable highlights

    You need to put "code" tags around your code.
    This enables the highlighting, and it stops the forum trying to interpret your array indices as formatting commands.
    (Note how your code shifts to italic font half way down)
    Just put
    [CODE]
    before the block of code, and
    [/CODE]
    after it, but use lower case "code" and "/code". I can't here, or you wouldn't be able to see them.
    i.e. if I make them lower case, it looks like this:

    before the block of code, and


    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #12
    andersm
    Super Member
    • Total Posts : 2839
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/26 00:50:52 (permalink)
    +2 (2)
    As an excercise, do manually what the C preprocessor normally does for you.
     
    Open tcpip.c, and on the line that says '#include "tcpip.h"', paste in the whole tcpip.h file. Then, on the commented out line '//#include "gsm.h"', paste in the whole gsm.h file. Are you starting to see the problems?
    #13
    ric
    Super Member
    • Total Posts : 28365
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/26 00:59:29 (permalink)
    +1 (1)
    davepl
    You will find copied declarations at the top of both tcpip.h and gsm.h eg. uint8_t gsdate[10]; on line 101 in gsm.h you will find "extern struct gsmflags" you will find the same structure without extern on line 30 in tcpip.h to service gsmflags.meerror derived from gsm's "EUSARTG_Read" and used at line 158 in tcpip.c. From what I can understand in the xc32 manual this is the proper use of extern but why can't I simply include gsm.h in tcpip.h

    No, you should have extern in both H files.
    I will say once again, you should never define variables in an H file, only declare them.
    Said in another way, "if it reserves memory, it shouldn't be in a header file".
    You are getting all these problems because you are breaking that rule.
     
    post edited by ric - 2020/07/26 01:02:59

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #14
    davepl
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2016/06/11 01:01:31
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/26 01:41:41 (permalink)
    0
    So @ric I'm led to understand that if I for example place
    uint8_t gsmmsg[512]; 
    into gsm.c (possibly using extern) it will be visible in tcpip.c without any reference other than it's name? I usually put variables into header files to contain data common to the entire program, with xc8 I would include the header file in all source files that used them.
     
    You must please excuse a possible lack of c jargon as I'm a hardware engineer with many years of assembly language programming experience but I've never had formal c training except the gnu c tutorial. I only started with embedded programming in c a few years ago I also program under linux without the above ill effects.
    This is from the MPLAB XC32 C/C++ Compilers User's Guide:
    3.4.1.4
     HOW CAN I USE A VARIABLE DEFINED IN ANOTHER SOURCE FILE?
    Provided the variable defined in the other source file is not static (see
    Section 9.3.2 “Static Variables”) or auto (see Section 9.4 “Auto Variable Allocation and
    Access”), adding a declaration for that variable in the current file will allow you to
    access it. A declaration consists of the keyword extern in addition to the type and
    name of the variable as specified in its definition, e.g.
    extern int systemStatus;
    This is part of the C language and your favorite C text will give you more information.
    The position of the declaration in the current file determines the scope of the variable,
    i.e., if you place the declaration inside a function, it will limit the scope of the variable to
    that function; placed outside of a function allows access to the variable in all functions
    for the remainder of the current file.
    Often, declarations are placed in header files and these are then #included into the C
    source code (see Section 19.3 “Preprocessor Directives”).
    post edited by davepl - 2020/07/26 01:49:07
    #15
    ric
    Super Member
    • Total Posts : 28365
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/26 01:56:04 (permalink)
    0
    davepl
    So @ric I'm led to understand that if I for example place
    uint8_t gsmmsg[512]; 
    into gsm.c (possibly using extern) it will be visible in tcpip.c without any reference other than it's name?

    You need it to be in at least one C file, without the "extern".
    That is the "definition".
    If you want to access it from another C file, that other C file needs to include a "declaration", which looks like a definition, but has "extern", and does not have any initialisation.
    It is normal to put these definitions into a header file, and #include THAT into each C file.
    You usually #include the header file into the C file it is declaring values for, which is a little redundant., but gives a cross check as an error will be generated if the definition and the declaration don't agree.
    Once again, if you actually read the page I linked to, it takes you right through the process, and why it is done this way.
     
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #16
    davepl
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2016/06/11 01:01:31
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/26 02:18:16 (permalink)
    0
    andersm
    As an aside, duplicating a declaration in two headers ("buffer" in both foo.h and bar.h) is a recipe for disaster. Sooner or later, you will change the declaration and forget to change it everywhere. The compiler won't catch it, but your code will just mysteriously break.




    This is precisely why I'm asking this question, if you look in gsm.h line 101 from:
    https://github.com/plater/gsm_tcp
    this includes the working parts of the program with sensitive const data removed from gsm.h
    If I remove duplicates from tcpip.h and include gsm.h I get this, note that "gsmbyte" and "mncbyte" along with the myriad of
    const uint8_t phonenum[] string declarations aren't duplicated.
     
    build/debug/production/tcpip.o: In function `tcp_connect':
    /home/davepl/MPLABXProjects/MX470_test.X/tcpip.c:11: multiple definition of `gsmbyte'
    build/debug/production/gsm.o:/home/davepl/MPLABXProjects/MX470_test.X/gsm.c:13: first defined here
    build/debug/production/tcpip.o: In function `tcp_connect':
    /home/davepl/MPLABXProjects/MX470_test.X/tcpip.c:11: multiple definition of `mncbyte'
    build/debug/production/gsm.o:/home/davepl/MPLABXProjects/MX470_test.X/gsm.c:13: first defined here
    build/debug/production/tcpip.o:(.rodata+0x0): multiple definition of `phonenum'
    build/debug/production/gsm.o:(.rodata+0x0): first defined here
    build/debug/production/tcpip.o:(.rodata+0x4): multiple definition of `cmti'
    build/debug/production/gsm.o:(.rodata+0x4): first defined here
    build/debug/production/tcpip.o:(.rodata+0xc): multiple definition of `pnum'
    build/debug/production/gsm.o:(.rodata+0xc): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1c): multiple definition of `spnum'
    build/debug/production/gsm.o:(.rodata+0x1c): first defined here
    build/debug/production/tcpip.o:(.rodata+0x28): multiple definition of `anum'
    build/debug/production/gsm.o:(.rodata+0x28): first defined here
    build/debug/production/tcpip.o:(.rodata+0x38): multiple definition of `sanum'
    build/debug/production/gsm.o:(.rodata+0x38): first defined here
    build/debug/production/tcpip.o:(.rodata+0x44): multiple definition of `ackmsg'
    build/debug/production/gsm.o:(.rodata+0x44): first defined here
    build/debug/production/tcpip.o:(.rodata+0x58): multiple definition of `mtmpcm'
    build/debug/production/gsm.o:(.rodata+0x58): first defined here
    build/debug/production/tcpip.o:(.rodata+0x60): multiple definition of `vdcpcm'
    build/debug/production/gsm.o:(.rodata+0x60): first defined here
    build/debug/production/tcpip.o:(.rodata+0x68): multiple definition of `sigstr'
    build/debug/production/gsm.o:(.rodata+0x68): first defined here
    build/debug/production/tcpip.o:(.rodata+0x70): multiple definition of `pintest'
    build/debug/production/gsm.o:(.rodata+0x70): first defined here
    build/debug/production/tcpip.o:(.rodata+0x7c): multiple definition of `sendms'
    build/debug/production/gsm.o:(.rodata+0x7c): first defined here
    build/debug/production/tcpip.o:(.rodata+0x88): multiple definition of `smsnmd'
    build/debug/production/gsm.o:(.rodata+0x88): first defined here
    build/debug/production/tcpip.o:(.rodata+0x9c): multiple definition of `smdqry'
    build/debug/production/gsm.o:(.rodata+0x9c): first defined here
    build/debug/production/tcpip.o:(.rodata+0xa8): multiple definition of `smsdel'
    build/debug/production/gsm.o:(.rodata+0xa8): first defined here
    build/debug/production/tcpip.o:(.rodata+0xbc): multiple definition of `smslst'
    build/debug/production/gsm.o:(.rodata+0xbc): first defined here
    build/debug/production/tcpip.o:(.rodata+0xcc): multiple definition of `smscap'
    build/debug/production/gsm.o:(.rodata+0xcc): first defined here
    build/debug/production/tcpip.o:(.rodata+0xd8): multiple definition of `smstxt'
    build/debug/production/gsm.o:(.rodata+0xd8): first defined here
    build/debug/production/tcpip.o:(.rodata+0xe4): multiple definition of `softid'
    build/debug/production/gsm.o:(.rodata+0xe4): first defined here
    build/debug/production/tcpip.o:(.rodata+0xf0): multiple definition of `alphon'
    build/debug/production/gsm.o:(.rodata+0xf0): first defined here
    build/debug/production/tcpip.o:(.rodata+0xfc): multiple definition of `alpoff'
    build/debug/production/gsm.o:(.rodata+0xfc): first defined here
    build/debug/production/tcpip.o:(.rodata+0x108): multiple definition of `pvdnam'
    build/debug/production/gsm.o:(.rodata+0x108): first defined here
    build/debug/production/tcpip.o:(.rodata+0x114): multiple definition of `engqry'
    build/debug/production/gsm.o:(.rodata+0x114): first defined here
    build/debug/production/tcpip.o:(.rodata+0x120): multiple definition of `engfmt'
    build/debug/production/gsm.o:(.rodata+0x120): first defined here
    build/debug/production/tcpip.o:(.rodata+0x12c): multiple definition of `engoff'
    build/debug/production/gsm.o:(.rodata+0x12c): first defined here
    build/debug/production/tcpip.o:(.rodata+0x138): multiple definition of `noecho'
    build/debug/production/gsm.o:(.rodata+0x138): first defined here
    build/debug/production/tcpip.o:(.rodata+0x144): multiple definition of `usdtst'
    build/debug/production/gsm.o:(.rodata+0x144): first defined here
    build/debug/production/tcpip.o:(.rodata+0x150): multiple definition of `ussdrd'
    build/debug/production/gsm.o:(.rodata+0x150): first defined here
    build/debug/production/tcpip.o:(.rodata+0x15c): multiple definition of `ussdwe'
    build/debug/production/gsm.o:(.rodata+0x15c): first defined here
    build/debug/production/tcpip.o:(.rodata+0x168): multiple definition of `ussdwc'
    build/debug/production/gsm.o:(.rodata+0x168): first defined here
    build/debug/production/tcpip.o:(.rodata+0x174): multiple definition of `ussdwv'
    build/debug/production/gsm.o:(.rodata+0x174): first defined here
    build/debug/production/tcpip.o:(.rodata+0x18c): multiple definition of `ussdwm'
    build/debug/production/gsm.o:(.rodata+0x18c): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1a0): multiple definition of `ussdw2'
    build/debug/production/gsm.o:(.rodata+0x1a0): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1b8): multiple definition of `setgsm'
    build/debug/production/gsm.o:(.rodata+0x1b8): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1c8): multiple definition of `airtim'
    build/debug/production/gsm.o:(.rodata+0x1c8): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1d4): multiple definition of `prodid'
    build/debug/production/gsm.o:(.rodata+0x1d4): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1dc): multiple definition of `dconfg'
    build/debug/production/gsm.o:(.rodata+0x1dc): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1e4): multiple definition of `ownnum'
    build/debug/production/gsm.o:(.rodata+0x1e4): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1f0): multiple definition of `clockr'
    build/debug/production/gsm.o:(.rodata+0x1f0): first defined here
    build/debug/production/tcpip.o:(.rodata+0x1fc): multiple definition of `clockw'
    build/debug/production/gsm.o:(.rodata+0x1fc): first defined here
    build/debug/production/tcpip.o:(.rodata+0x208): multiple definition of `pwrsta'
    build/debug/production/gsm.o:(.rodata+0x208): first defined here
    build/debug/production/tcpip.o:(.rodata+0x210): multiple definition of `loctim'
    build/debug/production/gsm.o:(.rodata+0x210): first defined here
    build/debug/production/tcpip.o:(.rodata+0x220): multiple definition of `nettst'
    build/debug/production/gsm.o:(.rodata+0x220): first defined here
    build/debug/production/tcpip.o:(.rodata+0x22c): multiple definition of `netoff'
    build/debug/production/gsm.o:(.rodata+0x22c): first defined here
    build/debug/production/tcpip.o:(.rodata+0x238): multiple definition of `baudra'
    build/debug/production/gsm.o:(.rodata+0x238): first defined here
    build/debug/production/tcpip.o:(.rodata+0x248): multiple definition of `facres'
    build/debug/production/gsm.o:(.rodata+0x248): first defined here
    /opt/microchip/xc32/v2.41/bin/bin/gcc/pic32mx/4.8.3/../../../../bin/pic32m-ld: Link terminated due to previous error(s).
    collect2: error: ld returned 255 exit status
    make[2]: *** [nbproject/Makefile-debug.mk:325: dist/debug/production/MX470_test.X.production.hex] Error 255
    make[1]: *** [nbproject/Makefile-debug.mk:91: .build-conf] Error 2
    make: *** [nbproject/Makefile-impl.mk:39: .build-impl] Error 2
    #17
    andersm
    Super Member
    • Total Posts : 2839
    • Reward points : 0
    • Joined: 2012/10/07 14:57:44
    • Location: 0
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/26 02:52:19 (permalink)
    +2 (2)
    daveplIf I remove duplicates from tcpip.h and include gsm.h I get this, note that "gsmbyte" and "mncbyte" along with the myriad of
    const uint8_t phonenum[] string declarations aren't duplicated.

    As has been stated several times, what you have in your header files are definitions, not declarations. If you move the definitions into a source file, and have only declarations in the header file, you can include the header file in as many source files as you like.
     
    gsm.c:
    uint8_t gsmbyte = 0;
    uint8_t mncbyte = 0;
    uint8_t gsmmsg[512];
    uint8_t gsmums[512];
    uint8_t gsmusd[128];
    uint8_t gsmusm[24];
    uint8_t gsmtim[23];
    uint8_t gsdate[10];
    uint8_t gstime[10];
    uint8_t phnumb[11];
    uint8_t noofline;
    uint16_t index;

    gsm.h:
    //Gsm related memory
    extern uint8_t gsmbyte;
    //moble network code 01 = Vodacom, 10 or 12 = Mtn
    extern uint8_t mncbyte;
    //gsm scratch pad
    extern uint8_t gsmmsg[512];
    //sms storage
    extern uint8_t gsmums[512];
    //ussd storage
    extern uint8_t gsmusd[128];
    //Store unsolicited notifications
    extern uint8_t gsmusm[24];
    extern uint8_t gsmtim[23];
    //Store date
    extern uint8_t gsdate[10];
    //Store time
    extern uint8_t gstime[10];
    //Phone number scratch pad
    extern uint8_t phnumb[11];
    extern uint8_t noofline;
    extern uint16_t index;

    Repeat for all other variables. Remove the duplicates from tcp.h.
    #18
    davepl
    New Member
    • Total Posts : 25
    • Reward points : 0
    • Joined: 2016/06/11 01:01:31
    • Location: 0
    • Status: offline
    Re: Can't understand PIC32M variable visibility 2020/07/26 03:29:49 (permalink)
    0
    @andersm this results in:
    gsm.c:10:9: error: redefinition of 'gsmbyte'
     uint8_t gsmbyte = 0;
             ^
    In file included from gsm.c:8:0:
    gsm.h:21:16: note: previous definition of 'gsmbyte' was here
     extern uint8_t gsmbyte = 0;
                    ^
    gsm.c:11:9: error: redefinition of 'mncbyte'
     uint8_t mncbyte = 0;
             ^
    In file included from gsm.c:8:0:
    gsm.h:23:16: note: previous definition of 'mncbyte' was here
     extern uint8_t mncbyte = 0;
     
    If I comment out the one declaration of gsmbyte or mncbyte I get the previously posted link errors. If I comment out the gsm.h include in tcpip.h then uncomment the duplicates, the program compiles fine and the arrays declared in gsm.h have the same populated data in tcpip.c. This in my opinion flies against convention but if it ain't broke don't fix it, I debug on the fly and I'm already behind with this device.
    Thanks very much for all the input to my problem to all
    #19
    ric
    Super Member
    • Total Posts : 28365
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Can't understand PIC32M variable visibility 2020/07/26 03:46:48 (permalink)
    0
    Christ, this sounds like "sweep it under the carpet" debugging.
    It's all wrong, but so long as it appears to work, ship it.,
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #20
    Page: 12 > Showing page 1 of 2
    Jump to:
    © 2020 APG vNext Commercial Version 4.5