[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