Open beadon opened 12 months ago
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.
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.
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.
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?
__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 )
Compiler MFG has communicated that they will consider adding UINTPTR_MAX
and other missing standard additions in the next revision.
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?
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
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.
Want to hack on this with me at the same time ?
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?
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 )
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 ?
Have put this down for a day or so as I think about it, and work on other items in parallel. Any thoughts ?
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.
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++?)
I've managed to make it compile:
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.
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.
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 !
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 :)
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 ?
current code is here: https://github.com/beadon/ecli_demo/tree/pic24_support
Sorry for the delay on reply. You can just assign fields of struct manually.
CliCommandBinding tempBinding;
tempBinding.name = "hello";
// other assignments
Will that help?
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 ?