ARM CMSIS support

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

ARM CMSIS support

Marc Santhoff-2
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

--
Marc Santhoff <[hidden email]>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Jeppe Johansen-3
CMSIS is a lot of things. What exact part of it are you asking about here?

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.

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.

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.

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  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Marc Santhoff-2
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?

> 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.

> 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  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

--
Marc Santhoff <[hidden email]>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Marc Santhoff-2
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  -  [hidden email]
> > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>

--
Marc Santhoff <[hidden email]>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Jeppe Johansen-3
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;

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

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  -  [hidden email]
>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Michael Ring-2
Chiming in ;-)

There are two more options:

https://github.com/yunkot/pxl

There are units available for higher level access to STM32F4, Teensy and
some Freescale Devices. Very usable for devices that have >64k of Flash,
a number of displays and sensors are supported out of the box.

When your board has Arduino compatible headers the code is very portable
between the different devices.

https://github.com/yunkot/pxl/tree/PXL-cleanups

As there are some limitations with classes and memory usage in
FreePascal there's a work-in-progress alternative available named MBF
that uses record helpers.

Syntax and usage is 99% the same as with the PXL Library mentioned above
but the memory footprint is much lower (typically 6-8k of flash for
simple apps). Teensy/Freescale code is already there, I have not yet
committed the STM32 and LPC8xx code as I wanted to commit them when they
both on same feature level as the existing code. Also more examples will
come with the new commit.

If you are interested in testing let me know...

Michael

Am 09.01.16 um 00:55 schrieb Jeppe Johansen:

> 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;
>
> 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
>
> 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  -  [hidden email]
>>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Marc Santhoff-2
In reply to this post by Jeppe Johansen-3
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  -  [hidden email]
> >>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

--
Marc Santhoff <[hidden email]>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Michael Ring-2
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  -  [hidden email]
>>>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>> _______________________________________________
>> fpc-pascal maillist  -  [hidden email]
>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Bernd Mueller-3
Michael Ring wrote:
> 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.

I have built the crosscompiler and the rtl for the STM32F429xx
controller. Basic functions seem to work.

By default, the rtl is compiled with optimization -O2. Should the rtl be
better compiled with optimization -O1 too, if there are issues with the
compiler? Or is the rtl not affected?

What is recommended by the developers? Where bug reports accepted, if I
use optimization -O2?

Regards, Bernd.




_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Michael Ring-2
Good point, Jeppe, what do you think on compiling rtl on arm-embedded
with -O1 ?

Michael

(Glad to hear that basic functionality works...)

By the way, I have done a patch for Lazarus so that debugging with
ST-Link/JLink/Texane works, send me an e-mail when you want to test this.

Michael

Am 12.02.16 um 15:10 schrieb Bernd Mueller:

> Michael Ring wrote:
>> 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.
>
> I have built the crosscompiler and the rtl for the STM32F429xx
> controller. Basic functions seem to work.
>
> By default, the rtl is compiled with optimization -O2. Should the rtl
> be better compiled with optimization -O1 too, if there are issues with
> the compiler? Or is the rtl not affected?
>
> What is recommended by the developers? Where bug reports accepted, if
> I use optimization -O2?
>
> Regards, Bernd.
>
>
>
>
> _______________________________________________
> fpc-pascal maillist  -  [hidden email]
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Bernd Mueller-3
Michael Ring wrote:
>
> (Glad to hear that basic functionality works...)

I finished my first (small) project with the STM32F429ZI controller and
everything went smooth :-) Even with optimization level -O2.

Thanks everyone, who is involved in the ARM compiler/rtl development.

Regards, Bernd.


_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Marc Santhoff-2
On Di, 2016-02-23 at 12:25 +0100, Bernd Mueller wrote:
> Michael Ring wrote:
> >
> > (Glad to hear that basic functionality works...)
>
> I finished my first (small) project with the STM32F429ZI controller and
> everything went smooth :-) Even with optimization level -O2.
>
> Thanks everyone, who is involved in the ARM compiler/rtl development.

Did you use the stmf103fw.pas translation from Jeppe or make you own
unit for supporting the 429?

My target would be f407, although the project in mind has to be done
using an Atmel SAM7 now, programmed in C... :|

--
Marc Santhoff <[hidden email]>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Bernd Mueller-3
Marc Santhoff wrote:

> Did you use the stmf103fw.pas translation from Jeppe or make you own
> unit for supporting the 429?

I needed only a few peripherals (GPIO, USART, RCC and embedded FLASH). I
wrote this stuff by myself.

> My target would be f407, although the project in mind has to be done
> using an Atmel SAM7 now, programmed in C... :|

I used the AT91SAM7S256 controller 5 years ago (with fpc 2.3.1 btw). If
I had to use ATMEL, I would look at the SAM3S or SAM4S family. They
should replace the SAM7 which is now over 10 years old. But since ATMEL
has been bought by Microchip, I would avoid them.

Regards, Bernd.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: ARM CMSIS support

Marc Santhoff-2
On Di, 2016-02-23 at 15:58 +0100, Bernd Mueller wrote:
> Marc Santhoff wrote:
>
> > Did you use the stmf103fw.pas translation from Jeppe or make you own
> > unit for supporting the 429?
>
> I needed only a few peripherals (GPIO, USART, RCC and embedded FLASH). I
> wrote this stuff by myself.

OK.

> > My target would be f407, although the project in mind has to be done
> > using an Atmel SAM7 now, programmed in C... :|
>
> I used the AT91SAM7S256 controller 5 years ago (with fpc 2.3.1 btw). If
> I had to use ATMEL, I would look at the SAM3S or SAM4S family. They
> should replace the SAM7 which is now over 10 years old. But since ATMEL
> has been bought by Microchip, I would avoid them.

I know, I know. But it is a low volume device and the chips are in
stock. Plus there is the complete compiler and support/HAL-library stuff
already done.

--
Marc Santhoff <[hidden email]>

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal