[fpc-devel] Need your help on how to best fix cmsis incompatibilities between arm chip vendors when linking to c-code
Michael Ring
mail at michael-ring.org
Tue Jan 26 01:29:54 CET 2021
I am having an issue in the form that I want to link to freertos static
library and I do not want to provide a freertos library for every
flavour of interrupt vector tables that is out there. (and there are
quite some...)
Also, there are people who want to link to vendor specific arduino
libraries that include already full implementation for gpio, spi, i2c
and whatever and those libs also use the vendor specific naming. for the
system interrupts defined by cmsis standard.
In a perfect world we would only have one freertos static lib for
armv6m, one for armv7m and one for armv7em that uses cmsis compatible names.
But there are vendors that name, for example, the scvcall handler
svc_handler, some call it svcall_handler and last version I saw was with
new rp2040 chip, they totally ignore everything and name the handler
isr_svcall.
In FreeRTOS the problem is solved by defining the right name to use for
svcall handler in a header file and then recompiling FreeRTOS for your
specific vendor.
In Freepascal we could do the same thing but this would require us to
either provide all flavours of freertos as a static library or to
require the user to build a freertos lib on their own that matches the
name for svc handler that is defined within fpc unit for the chip
needed. Not very userfriendly....
So I was thinking about a workarround which I seem to have found, we can
redefine Linker symbols as needed in the gnu linker with the --defsym=
parameter.
I have attached below sample code that shows how this works.
My problem is now that I do not know how to best implement this in
freepascal so that it is as transparent as possible to the user, not
requiring him to create a huge list of defsym parameters in the lpi file
or on commandline.
My current idea is to put a list of default defsyms for arm chips in
t_embed/t_freertos, re-mapping non-cmsis conformant names to proper
cmsis names.
Does this make sense to you guys or does it sound like a crazy hack? I
am not sure myself so I would love to hear your opinion, or perhaps even
better ideas on how to solve the problem....
Thanks in advance,
Michael
Example:
program svctest;
uses
svchandlers;
procedure handle_svc external name 'handle_svc';
begin
handle_svc;
end.
unit svchandlers;
interface
procedure isr_svcall; public name 'isr_svcall';
procedure svcall_handler; public name 'svcall_handler';
procedure svc_handler; public name 'svc_handler';
implementation
procedure isr_svcall;
begin
writeln('I am isr_svcall');
end;
procedure svcall_handler;
begin
writeln('I am svcall_handler');
end;
procedure svc_handler;
begin
writeln('I am svc_handler');
end;
end.
Now compile like this:
fpc -Parm -Tembedded -Wpbluepill -Cparmv7m
-k'--defsym=handle_svc=svc_handler' svctest.pas
fpc -Parm -Tembedded -Wpbluepill -Cparmv7m
-k'--defsym=handle_svc=svcall_handler' svctest.pas
fpc -Parm -Tembedded -Wpbluepill -Cparmv7m
-k'--defsym=handle_svc=isr_svcall' svctest.pas
one of the three implementations will be choosen based on the selected
defsym
More information about the fpc-devel
mailing list