Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compilation issues in CCS C Compiler #39

Open
beadon opened this issue Nov 9, 2023 · 22 comments
Open

Compilation issues in CCS C Compiler #39

beadon opened this issue Nov 9, 2023 · 22 comments

Comments

@beadon
Copy link

beadon commented Nov 9, 2023

There appears to be a typo in the released v0.1.3 .h file

See : https://github.com/funbiscuit/embedded-cli/releases/tag/v0.1.3

Line 49,
#elif UINTPTR_MAX == 0xFFFFFFFFFFFFFFFFu

should probably be:
#elif UINTPTR_MAX == 0xFFFFFFFFFFFFFFFF

right ?

@funbiscuit
Copy link
Owner

It's not a typo, it's just an indication that literal is unsigned. But probably should be 0xFFFFFFFFFFFFFFFFuL since it's not unsigned int. Anyway, if you don't receive unsupported pointer size error when trying to compile then everything works correctly.

@funbiscuit funbiscuit added the question Further information is requested label Nov 9, 2023
@beadon
Copy link
Author

beadon commented Nov 9, 2023

Yep, got it. Ok, I compared it to the code in the repo and the search showed a missing u which is the reason for the raised issue, but upon checking thoroughly again right now I can see that this u is also in the repo. Your description makes sense.

Notably, I am attempting an integration on a PIC18F57Q84 , and my compiler CCS C Info ( https://www.ccsinfo.com/ ) is throwing a fit about this line - it does not define UINTPTR_MAX. Planning to #define it to 0xFFFF , since the compiler appears(?) to fake 16-bit most of the time, even though underlying hardware is 8-bit. I may need to concede and drop it to 0xFF.

  • Your opinion on this matter , setting UINTPTR_MAX, would be welcome.

It's also throwing errors about const , so I'll be walking through why this is happening shortly. Insights to the use of const on an 8-bit system is also welcome. I would be happy to share the integration steps if they differ from your documentation.

@funbiscuit
Copy link
Owner

If your compiler doesn't define UINTPTR_MAX then I guess it doesn't support C99 standard. And so it doesn't support fixed width int types which are all over the place in this lib. I guess it will be quite hard to define everything properly for it to work.
Does your compiler define __STDC_VERSION__ and/or __STDC__ and what are they?

@beadon
Copy link
Author

beadon commented Nov 9, 2023

__STDC__ and __STDC_VERSION__ are not set.

However, the compiler does support fixed width int types, and I am using exactly these elsewhere in the program. I am holding onto hope this does integrate ...

first step was removing all const since this compiler will do this:
"Note: The const qualifier in CCS always means that the data will be placed in program memory, and that the data is 'read-only'. It does not follow the ANSI definition which simply states that const is 'read-only'."
(reference: https://www.ccsinfo.com/content.php?page=compiler-features )

@beadon
Copy link
Author

beadon commented Nov 13, 2023

Compiler MFG has communicated that they will consider adding UINTPTR_MAX and other missing standard additions in the next revision.

@funbiscuit
Copy link
Owner

I don't actually think that const's should not work, I think they will, try to leave them as is.

As for UINTPTR_MAX - try to define it as 0xFFFF it's mainly there for alignment purposes. If your PIC doesn't mind accessing random offsets then you can even define it as 0xFF so memory buffers align on byte boundaries (instead of 2-byte boundary as with UINTPTR_MAX equal to 0xFFFF ).

Do you have any other issues with compilation?

@beadon
Copy link
Author

beadon commented Nov 13, 2023

Yes, a few.

Currently fighting what should be valid code. The compiler believes that the "defaultConfig" struct is somehow a problem.

Compiling C:\Users\beadon\Documents\GitHub\embedded-cli-mods\main on 13-Nov-23 at 13:11
*** Error 56 "C:\Users\beadon\Documents\GitHub\embedded-cli-mods\embedded_cli.h" Line 735(19,31): Element is not a member
*** Error 56 "C:\Users\beadon\Documents\GitHub\embedded-cli-mods\embedded_cli.h" Line 736(19,32): Element is not a member
*** Error 56 "C:\Users\beadon\Documents\GitHub\embedded-cli-mods\embedded_cli.h" Line 737(19,36): Element is not a member
*** Error 56 "C:\Users\beadon\Documents\GitHub\embedded-cli-mods\embedded_cli.h" Line 738(19,28): Element is not a member
*** Error 56 "C:\Users\beadon\Documents\GitHub\embedded-cli-mods\embedded_cli.h" Line 739(19,32): Element is not a member
*** Error 56 "C:\Users\beadon\Documents\GitHub\embedded-cli-mods\embedded_cli.h" Line 740(19,34): Element is not a member
*** Error 56 "C:\Users\beadon\Documents\GitHub\embedded-cli-mods\embedded_cli.h" Line 741(19,37): Element is not a member
*** Error 56 "C:\Users\beadon\Documents\GitHub\embedded-cli-mods\embedded_cli.h" Line 742(19,29): Element is not a member

@beadon
Copy link
Author

beadon commented Nov 13, 2023

In the interest of getting this resolved, I have invited you to the demonstration integration with this chipset.
https://github.com/beadon/ecli_demo

You comments are welcome.

@beadon
Copy link
Author

beadon commented Nov 14, 2023

Want to hack on this with me at the same time ?

@funbiscuit
Copy link
Owner

I don't have that compiler and from what I see, it has only paid version. You've included compiler errors, but I don't see any struct access at lines 736-738. Are you using modified version of header? Can you attach it here so I can look at it?

@beadon
Copy link
Author

beadon commented Nov 14, 2023

I believe this free version (demo) should work . Unfortunately I believe it is windows only. ( https://www.ccsinfo.com/ccsfreedemo.php )

I needed to snag the embedded_cli.c and embedded_cli.h from this repository because the all-in-one combined header file was throwing too many problems (seemed compiler specific). I will see about adding the demo exe to the public demo repository ( https://github.com/beadon/ecli_demo )

@beadon
Copy link
Author

beadon commented Nov 14, 2023

Exe has been added to the public repo for testing. It has some reduced functionality, but I am expecting to see the same errors.

The public repo has the latest as I try and integrate.

errors revolve around typedefs:

typedef struct EmbeddedCliImpl EmbeddedCliImpl;
typedef struct AutocompletedCommand AutocompletedCommand;
typedef struct FifoBuf FifoBuf;
typedef struct CliHistory CliHistory;

and the separate struct definitions later on in the code.

If I choose to address these by defining the structs and typedef at the same time, then I am faced with a (different) problem:

this overloaded function (very slick by the way!) --

void (*onCommand)(EmbeddedCli *cli, CliCommand *command);
void (*writeChar)(EmbeddedCli *cli, char c);

which does not appear to be supported ? How would I write it otherwise ?

@beadon
Copy link
Author

beadon commented Nov 16, 2023

Have put this down for a day or so as I think about it, and work on other items in parallel. Any thoughts ?

@funbiscuit
Copy link
Owner

I didn't have time yet to look at this, hopefully I'll take a look on weekend.
As for typedefs - if I remember correctly they're required since we use same struct inside of struct (in onCommand and writeChar) so compiler has to know about it beforehand. Without typedefs the only option I could think of is to use void * instead of EmbeddedCli * in function parameters.
I'll try to install that compiler on windows vm later and see if it compiles.

@beadon
Copy link
Author

beadon commented Nov 17, 2023

Ok, I am going to change the order of the typedefs , I've re-read and I believe if the compiler is strict we may need to define the struct first, then typedef ..

as for the overloaded functions I am thinking the same thing. However, I will miss having the correct type checking. (but maybe that's only offered with C++?)

@funbiscuit
Copy link
Owner

I've managed to make it compile:
image

I've attached modified embedded_cli.h:
embedded_cli.zip

Notice that this is single header version so you should remove .c file from your project.
I deleted all const modifiers since it's not supported on PIC, rearranged typedefs so they're after definitions and changed how constant strings are printed. I think some of these changes I'll apply to this repo as well (not const removal of course).

Inside your repository I also added onCommand assignment (otherwise it won't compile saying no valid assignment to onCommand):

// main.c
// ...

void onCommand(EmbeddedCli *embeddedCli, CliCommand *command)
{
    // your implementation

}

void main()
{
    // ...
    cli->onCommand = onCommand;
}

And defined UINTPTR_MAX to be 0xFFFF:

// main.h
// ...

#define UINTPTR_MAX 0xFFFF

#include "embedded_cli.h"

// ...

Try to use it and tell me if errors somewhere else. If it does, include full error logs and relevant source code where it errors.

@funbiscuit funbiscuit changed the title v0.1.3 has a typo ? Compilation issues in CCS C Compiler Nov 18, 2023
@funbiscuit funbiscuit removed the question Further information is requested label Nov 18, 2023
@funbiscuit
Copy link
Owner

I tried to compile it again and noticed String is truncated warning. It's because constant string literal is assigned to char *, which is wrong for this compiler. To fix it before embeddedCliDefaultConfig function declare:

static char defaultInvitation[] = "> ";

And then instead of

defaultConfig.invitation = "> ";

Use that array:

defaultConfig.invitation = defaultInvitation;

Other two warnings seem not important.

@beadon
Copy link
Author

beadon commented Nov 18, 2023

Truly nice work !

Yes, I have implemented these as you describe, and updated the repo here ( https://github.com/beadon/ecli_demo

I will be trying it on a serial line tomorrow. This is looking very promising !

@beadon
Copy link
Author

beadon commented Dec 6, 2023

Have not forgotten about this, have needed to lay in an RTOS first so I can use the right calls as I implement the cli. I will keep you posted :)

@beadon
Copy link
Author

beadon commented Mar 8, 2024

Have gotten to the implementation, however, the processor is absolutely freaking out.

I can't distinguish exactly what is a compiler issue, or what might be a hardware issue.

At the moment, I am having an issue with the command binding because the compiler does not support compound literals.

To get around things , I've chosen to go this route, but I think the compiler is silently creating broken code.

   EmbeddedCli *g_cli;

   CliCommandBinding tempBinding = {
            "hello",
            "Print hello message",
            true,
            (void *) "World",
            onHello
    };

   embeddedCliAddBinding(g_cli, tempBinding );

Any recommendations for doing the command binding without compound literals ?

@beadon
Copy link
Author

beadon commented Mar 8, 2024

@funbiscuit
Copy link
Owner

funbiscuit commented Mar 16, 2024

Sorry for the delay on reply. You can just assign fields of struct manually.

CliCommandBinding tempBinding;
tempBinding.name = "hello";
// other assignments

Will that help?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants