[fpc-pascal] ARM CMSIS support

[Michael Ring]

Currently there is no support for embedded targets in the Lazarus 
Debugger so you will need to load/debug your code with the help of other 
tools.

For the Discovery board the easiest way to deploy binaries and to debug 
is to install openocd:

openocd -f board/stm32f4discovery.cfg

should connect you to the board, you can then use gdb (or cgdb or ddd) 
to upload and debug your code:

arm-none-eabi-gdb $BIN --eval-command="target extended :3333" 
--eval-command="set gdb_memory_map disable" --eval-command="monitor 
halt" --eval-command="set mem inaccessible-by-default off" 
--eval-command="load"

When you want to get a little more serious with the embedded target I'd 
highly recommend to buy a Segger J-Link Edu for about $50, it has 
support for almost any embedded controller on the market, for openocd 
the selection is a little more limited.

But the main advantage is that it comes with a very good gui based 
debugger, the JLinkDebugger allows you to load CMSIS svd files to 
directly browse all controller registers and it makes the whole 
debugging process a lot more convenient.

By the way, with fpc trunc compiler you can target your board directly:

ppcrossarm  -WpDISCOVERYF407VG (see ppcrossarm -i for other Discovery 
boards)

You should also refrain from using optimizations > -O1 as there are some 
issues with the compiler that make your compiled binary unusable.

Michael

Am 09.01.16 um 13:42 schrieb Marc Santhoff:
> On Sa, 2016-01-09 at 00:55 +0100, Jeppe Johansen wrote:
>> Yes, you understand it correctly :)
>> The FPC RTL only exposes the hardware, not the firmware stack on top.
>>
>> It might not be documented well anywhere but the weak linking with set
>> defaults basically means you can declare interrupt handlers like this:
>>
>> procedure MySystickHandler; [public, alias: 'SysTick_interrupt'];
>> begin
>>      // Code
>> end;
> I see. And there is no example in your testing code for stmf103fx.pas.
>
> Since this should be documented somewhere:
> Is that working for all embedded controller types? It should, the
> declarations look pretty much the same.
>
> I'm willing to collect some informations for starters and make a wiki
> page out of it, but I'll have to ask a lot of questions first. ;)
>
> On the wiki there is a lot of stuff, but what is missing a bit is a
> general getting started page for newbies.
>
>> For STM32 there's the stm32f103fw file on my site. There's also a
>> version on Anton Rieckert's github page which is split up a bit nicer.
>> Not sure what the status or compatibility is.
>> Otherwise I can plug my project of converting the STM32F7 codebase here:
>> https://github.com/Laksen/fp-stm32f7xx_hal
> My current targets are a f4-discovery board and maybe some simple f103
> controllers not choosen yet. Besides that AVR would be nice to have.
> When that works maybe I'll be trying some SAM7S64 or S256 boards, too.
> In principle all of them would be handled identically, besides their
> intergrated peripherals.
>
> So again:
> The process of getting started would be the same on every simple
> controller? Simple means having no OS, only bare silicon.
>
> What I know is:
> - get biunutils
> - build cross compiler
> But that's all. Mostly simple testing programs are given, but not many
> explanations on declaring IRQ-handlers, loading up a binary, etc.
>
> I like the technique of generating linker script and having memory
> address specifications and more build in the compiler. When using C and
> fiddling with Makefiles, linker scripts, not working code and so on can
> be very frustrating. And I like Pacal. ;)
>
> What tools do you use to load the binary up to the embedded target?
>
> Marc
>
>
>> If anyone other know of any nice embedded projects/links be sure to
>> chime in :)
>>
>> I know some people have been working with Silicon Labs and Freescale
>> codebases too. So there's a lot going on around.
>>
>> Best Regards,
>> Jeppe
>>
>> On 01/08/2016 11:58 PM, Marc Santhoff wrote:
>>> Answering myself here:
>>>
>>> On Fr, 2016-01-08 at 23:43 +0100, Marc Santhoff wrote:
>>>> On Fr, 2016-01-08 at 23:23 +0100, Jeppe Johansen wrote:
>>>>> CMSIS is a lot of things. What exact part of it are you asking about here?
>>>> In that file for example from line 887 on:
>>>>
>>>> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/embedded/arm/stm32f407xx.pp?revision=32386&view=markup
>>>>
>>>> there are lots of 'external'ly declared procedures. Where can I find
>>>> them?
>>> Hmm, that's only a list of interrupt procedures. After the declaration
>>> there are some assembler seetings to have default values - OK, now I
>>> think I understand. It's up to the user to let them be set to default or
>>> redefine and implement the IRQ procedure.
>>>
>>>>> FPC's embedded target has a bunch of controller units that are pulled in
>>>>> depending on the -Wp argument. These define exactly what you see in the
>>>>> units in the rtl/embedded/arm directory. In most cases just the physical
>>>>> registers, the interrupt vectors(and sometimes the IRQ levels), and some
>>>>> startup code. The mapping between the files and the controller names can
>>>>> be seen in the huge table in compiler/arm/cpuinfo.pas.
>>>> Have seen that, the wiki explains it.
>>>>
>>>>> There are no object or source files for other parts of CMSIS, so things
>>>>> like the CMSIS-DSP and all cortex-m intrinsics don't work right now.
>>>>>
>>>>> The cortexm3 and cortexm4 units that you can include in your uses clause
>>>>> will model some of the missing functionality but very far from all.
>>>> Your older implementation of STM32F103 found on your website has
>>>> declarations and implementations of the most important parts. The "new
>>>> style" sources included in fpc/rtl haven't. Or at least I can't find
>>>> them.
>>> No, it hasn't. I have read too many source files today. So there is only
>>> the declaration stuff for accessing the internals of the SoC, timers,
>>> peripherals and the like, OK.
>>>
>>> Marc
>>>
>>>>> Floating point support is very untested. Most of it should work, but
>>>>> there might be some bugs. You can enable it by compiling your RTL and
>>>>> application with -CfFPv4_S16. If you decide to test it please write on
>>>>> the bugtracker if you run into problems.
>>>> I think I'll have to wait a while, that not the right toy for starting
>>>> up. ;)
>>>>
>>>> Thanks a lot!
>>>> Marc
>>>>
>>>>> Best Regards,
>>>>> Jeppe
>>>>>
>>>>> On 01/08/2016 10:58 PM, Marc Santhoff wrote:
>>>>>> Hi,
>>>>>>
>>>>>> looking at the embedded source code there has been done a lot of work.
>>>>>> I'm interested in trying fpc on Cortex-M3 and M4, mostly from ST.
>>>>>>
>>>>>> While trying to get an overview of the sources I found the declarations
>>>>>> are pulled into a processor specific file by external declarations. But
>>>>>> where does it come from, does the linker pull in the cmsis object files
>>>>>> or something?
>>>>>>
>>>>>> If so, how? There has to be a pointer to those files I couldn't find
>>>>>> either.
>>>>>>
>>>>>> Second question is:
>>>>>> Does the embedded target support hard floting point on STM32F4?
>>>>>>
>>>>>> TIA,
>>>>>> Marc
>>>>>>
>>>>> _______________________________________________
>>>>> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
>>>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>> _______________________________________________
>> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal