Generating RTL Units for STM32 Processors

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

Generating RTL Units for STM32 Processors

R0b0t1
Hello list,

I'd like some pointers on generating the RTL files for a processor I
am interested in, the STM32L432KC (which is available for ~$15 with
JTAG on a "Nucleo" board from STMicroelectronics).

The CMSIS (Cortex Microcontroller Software Interface Standard) files,
as they come from STM, use structures to represent the registers. The
example RTL files for STM devices seem to follow this pattern fairly
well, but I would like to know about any discrepancies; I opened one
file and think it was structured more closely to the way libopencm3
does things, but I can't find it again. This may have been the file
for the NXP part listed on the Wiki.


How much was converted by hand, and how much can be automated? M4
devices are noticeably more complicated, and even though this is a
hobby project I am worried about the time investment required to get
my device working with FPC.

What complicates things is the way libopencm3 has their headers
structures is more standard. They avoid using structures that
represent the registers, instead using faux namespacing with lots of
underscores in macro names.

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

Re: Generating RTL Units for STM32 Processors

Michael Ring-2
The process is completely automated and is based on converting the
header files that come in the CMSIS packages of the processors.

I will send you the file for that chip via pm, you will also have to
tweak compiler/systems/t_embed.pas compiler/arm/cpuinfo.pas but this is
pretty straightforward, only extend both structs for the processors.

There is a second class of Headerfiles that were done half automated
(afaik) by Jeppe Johansen that covers the STM32F7 series. Those Headers
more closely match the STM32 code C-code examples but are a lot less
portable to other chips (Microchip etc...)

Michael


Am 27.02.18 um 04:09 schrieb R0b0t1:

> Hello list,
>
> I'd like some pointers on generating the RTL files for a processor I
> am interested in, the STM32L432KC (which is available for ~$15 with
> JTAG on a "Nucleo" board from STMicroelectronics).
>
> The CMSIS (Cortex Microcontroller Software Interface Standard) files,
> as they come from STM, use structures to represent the registers. The
> example RTL files for STM devices seem to follow this pattern fairly
> well, but I would like to know about any discrepancies; I opened one
> file and think it was structured more closely to the way libopencm3
> does things, but I can't find it again. This may have been the file
> for the NXP part listed on the Wiki.
>
>
> How much was converted by hand, and how much can be automated? M4
> devices are noticeably more complicated, and even though this is a
> hobby project I am worried about the time investment required to get
> my device working with FPC.
>
> What complicates things is the way libopencm3 has their headers
> structures is more standard. They avoid using structures that
> represent the registers, instead using faux namespacing with lots of
> underscores in macro names.
>
> Cheers,
>       R0b0t1
> _______________________________________________
> 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: Generating RTL Units for STM32 Processors

Michael Ring-2
In reply to this post by R0b0t1
What are you planing to implement? Do you need the RAM and FLASH of the
stm32l432 or the low power features?

If not then I'd suggest to start wit a more simple CPU like the
STM32F303K8 or, if you are okay with standard size nucleo boards the
STM32F401RE or STM32F411RE are a good choice.

On the low energy chips the configuration is more demanding and for the
other chips mentioned above there's already plenty of code available to
re-use/re-purpose

Michael


Am 27.02.18 um 04:09 schrieb R0b0t1:

> Hello list,
>
> I'd like some pointers on generating the RTL files for a processor I
> am interested in, the STM32L432KC (which is available for ~$15 with
> JTAG on a "Nucleo" board from STMicroelectronics).
>
> The CMSIS (Cortex Microcontroller Software Interface Standard) files,
> as they come from STM, use structures to represent the registers. The
> example RTL files for STM devices seem to follow this pattern fairly
> well, but I would like to know about any discrepancies; I opened one
> file and think it was structured more closely to the way libopencm3
> does things, but I can't find it again. This may have been the file
> for the NXP part listed on the Wiki.
>
>
> How much was converted by hand, and how much can be automated? M4
> devices are noticeably more complicated, and even though this is a
> hobby project I am worried about the time investment required to get
> my device working with FPC.
>
> What complicates things is the way libopencm3 has their headers
> structures is more standard. They avoid using structures that
> represent the registers, instead using faux namespacing with lots of
> underscores in macro names.
>
> Cheers,
>       R0b0t1
> _______________________________________________
> 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: Generating RTL Units for STM32 Processors

R0b0t1
In reply to this post by Michael Ring-2
On Tue, Feb 27, 2018 at 2:43 AM, Michael Ring <[hidden email]> wrote:
> The process is completely automated and is based on converting the header
> files that come in the CMSIS packages of the processors.
>

Excellent! What about the startup assembly files? I see an equivalent,
it is autogenerated too?

> I will send you the file for that chip via pm, you will also have to tweak
> compiler/systems/t_embed.pas compiler/arm/cpuinfo.pas but this is pretty
> straightforward, only extend both structs for the processors.
>

Yes, I forgot about this, but it does sound easy. Which chip?

> There is a second class of Headerfiles that were done half automated (afaik)
> by Jeppe Johansen that covers the STM32F7 series. Those Headers more closely
> match the STM32 code C-code examples but are a lot less portable to other
> chips (Microchip etc...)
>

Where are these?

I have some interest in exploring a wide variety of platforms with
FPC. When doing so using C, I have unfortunately found that
portability only half-exists between chips of the same family from the
same manufacturer.

My interest in FPC is partly an interest in increased portability, but
that may need to be achieved in some other way than a HAL. This may be
due to how peripheral mappings are supplied. Perhaps there is a better
way I do not know about. Large projects such as
https://github.com/qmk/qmk_firmware manage.

I will be following up with you off list, since you do not seem to mind.

Cheers,
     R0b0t1

> Michael
>
>
> Am 27.02.18 um 04:09 schrieb R0b0t1:
>>
>> Hello list,
>>
>> I'd like some pointers on generating the RTL files for a processor I
>> am interested in, the STM32L432KC (which is available for ~$15 with
>> JTAG on a "Nucleo" board from STMicroelectronics).
>>
>> The CMSIS (Cortex Microcontroller Software Interface Standard) files,
>> as they come from STM, use structures to represent the registers. The
>> example RTL files for STM devices seem to follow this pattern fairly
>> well, but I would like to know about any discrepancies; I opened one
>> file and think it was structured more closely to the way libopencm3
>> does things, but I can't find it again. This may have been the file
>> for the NXP part listed on the Wiki.
>>
>>
>> How much was converted by hand, and how much can be automated? M4
>> devices are noticeably more complicated, and even though this is a
>> hobby project I am worried about the time investment required to get
>> my device working with FPC.
>>
>> What complicates things is the way libopencm3 has their headers
>> structures is more standard. They avoid using structures that
>> represent the registers, instead using faux namespacing with lots of
>> underscores in macro names.
>>
>> Cheers,
>>       R0b0t1
>> _______________________________________________
>> 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: Generating RTL Units for STM32 Processors

Christo Crause
On 28 Feb 2018 4:22 am, "R0b0t1" <[hidden email]> wrote:
I will be following up with you off list, since you do not seem to mind.

I'm also interested in the general topic of incorporating embedded controllers (avr at the moment)  into fpc. It would be useful to me if I could follow at least the general highlights for the porting process, not necessarily all the platform specific details.

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

Re: Generating RTL Units for STM32 Processors

Michael Ring-2
In reply to this post by R0b0t1
Am 28.02.18 um 03:22 schrieb R0b0t1:
> On Tue, Feb 27, 2018 at 2:43 AM, Michael Ring <[hidden email]> wrote:
>> The process is completely automated and is based on converting the header
>> files that come in the CMSIS packages of the processors.
>>
> Excellent! What about the startup assembly files? I see an equivalent,
> it is autogenerated too?

Nope, those were created manually (from Jeppe), the one relevant for the
STM32L432KC is cortexm4f_start.inc
It will automagically be included when you add definitions for the chip.
>
>> I will send you the file for that chip via pm, you will also have to tweak
>> compiler/systems/t_embed.pas compiler/arm/cpuinfo.pas but this is pretty
>> straightforward, only extend both structs for the processors.
>>
> Yes, I forgot about this, but it does sound easy. Which chip?

STM32L432KC

if you plan to some some serious development I can provide you a patch
file for including the whole stm32l4 family

>
>> There is a second class of Headerfiles that were done half automated (afaik)
>> by Jeppe Johansen that covers the STM32F7 series. Those Headers more closely
>> match the STM32 code C-code examples but are a lot less portable to other
>> chips (Microchip etc...)
>>
> Where are these?
Take a look at github:

https://github.com/Laksen/fp-stm32f7xx_hal

great for stm32f7, but changing this to stm32l4 is a heroic effort ;-)

>
> I have some interest in exploring a wide variety of platforms with
> FPC. When doing so using C, I have unfortunately found that
> portability only half-exists between chips of the same family from the
> same manufacturer.
>
> My interest in FPC is partly an interest in increased portability, but
> that may need to be achieved in some other way than a HAL. This may be
> due to how peripheral mappings are supplied. Perhaps there is a better
> way I do not know about. Large projects such as
> https://github.com/qmk/qmk_firmware manage.

I have done my own platform independant lib for stm32(f0)/f1/f3/f4 and
pic32 with a focus on low memory consumption, if you are interested I
can put it on github, still some loose ends as I only have implemented
what I needed.

>
> I will be following up with you off list, since you do not seem to mind.

let's stay on list, there are others like Christo who may be interested.

Michael

>
> Cheers,
>       R0b0t1
>
>> Michael
>>
>>
>> Am 27.02.18 um 04:09 schrieb R0b0t1:
>>> Hello list,
>>>
>>> I'd like some pointers on generating the RTL files for a processor I
>>> am interested in, the STM32L432KC (which is available for ~$15 with
>>> JTAG on a "Nucleo" board from STMicroelectronics).
>>>
>>> The CMSIS (Cortex Microcontroller Software Interface Standard) files,
>>> as they come from STM, use structures to represent the registers. The
>>> example RTL files for STM devices seem to follow this pattern fairly
>>> well, but I would like to know about any discrepancies; I opened one
>>> file and think it was structured more closely to the way libopencm3
>>> does things, but I can't find it again. This may have been the file
>>> for the NXP part listed on the Wiki.
>>>
>>>
>>> How much was converted by hand, and how much can be automated? M4
>>> devices are noticeably more complicated, and even though this is a
>>> hobby project I am worried about the time investment required to get
>>> my device working with FPC.
>>>
>>> What complicates things is the way libopencm3 has their headers
>>> structures is more standard. They avoid using structures that
>>> represent the registers, instead using faux namespacing with lots of
>>> underscores in macro names.
>>>
>>> Cheers,
>>>        R0b0t1
>>> _______________________________________________
>>> 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

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

Re: Generating RTL Units for STM32 Processors

R0b0t1
On Wed, Feb 28, 2018 at 11:27 AM, Michael Ring <[hidden email]> wrote:

> Am 28.02.18 um 03:22 schrieb R0b0t1:
>>
>> On Tue, Feb 27, 2018 at 2:43 AM, Michael Ring <[hidden email]>
>> wrote:
>>>
>>> The process is completely automated and is based on converting the header
>>> files that come in the CMSIS packages of the processors.
>>>
>> Excellent! What about the startup assembly files? I see an equivalent,
>> it is autogenerated too?
>
>
> Nope, those were created manually (from Jeppe), the one relevant for the
> STM32L432KC is cortexm4f_start.inc
> It will automagically be included when you add definitions for the chip.
>>
>>
>>> I will send you the file for that chip via pm, you will also have to
>>> tweak
>>> compiler/systems/t_embed.pas compiler/arm/cpuinfo.pas but this is pretty
>>> straightforward, only extend both structs for the processors.
>>>
>> Yes, I forgot about this, but it does sound easy. Which chip?
>
>
> STM32L432KC
>
> if you plan to some some serious development I can provide you a patch file
> for including the whole stm32l4 family
>

I am planning serious development. If you can provide the patch that
would be great, but if it is any amount of work I may be able to do it
myself with some pointers.

It is my intent to stick with the L4 part I am using, but there have
been many issues with it so far. Moving to an F3 or F4 may happen, but
only after I attempt some actual use of the L4. Maybe eventually
working libraries can be built up.

>>
>>> There is a second class of Headerfiles that were done half automated
>>> (afaik)
>>> by Jeppe Johansen that covers the STM32F7 series. Those Headers more
>>> closely
>>> match the STM32 code C-code examples but are a lot less portable to other
>>> chips (Microchip etc...)
>>>
>> Where are these?
>
> Take a look at github:
>
> https://github.com/Laksen/fp-stm32f7xx_hal
>
> great for stm32f7, but changing this to stm32l4 is a heroic effort ;-)
>

Right, I find myself needing to refer to STM's official HAL. Their
normal documentation is lacking.

>>
>> I have some interest in exploring a wide variety of platforms with
>> FPC. When doing so using C, I have unfortunately found that
>> portability only half-exists between chips of the same family from the
>> same manufacturer.
>>
>> My interest in FPC is partly an interest in increased portability, but
>> that may need to be achieved in some other way than a HAL. This may be
>> due to how peripheral mappings are supplied. Perhaps there is a better
>> way I do not know about. Large projects such as
>> https://github.com/qmk/qmk_firmware manage.
>
>
> I have done my own platform independant lib for stm32(f0)/f1/f3/f4 and pic32
> with a focus on low memory consumption, if you are interested I can put it
> on github, still some loose ends as I only have implemented what I needed.
>

Please do, thanks.

>>
>> I will be following up with you off list, since you do not seem to mind.
>
>
> let's stay on list, there are others like Christo who may be interested.
>
> Michael
>
>
>>
>> Cheers,
>>       R0b0t1
>>
>>> Michael
>>>
>>>
>>> Am 27.02.18 um 04:09 schrieb R0b0t1:
>>>>
>>>> Hello list,
>>>>
>>>> I'd like some pointers on generating the RTL files for a processor I
>>>> am interested in, the STM32L432KC (which is available for ~$15 with
>>>> JTAG on a "Nucleo" board from STMicroelectronics).
>>>>
>>>> The CMSIS (Cortex Microcontroller Software Interface Standard) files,
>>>> as they come from STM, use structures to represent the registers. The
>>>> example RTL files for STM devices seem to follow this pattern fairly
>>>> well, but I would like to know about any discrepancies; I opened one
>>>> file and think it was structured more closely to the way libopencm3
>>>> does things, but I can't find it again. This may have been the file
>>>> for the NXP part listed on the Wiki.
>>>>
>>>>
>>>> How much was converted by hand, and how much can be automated? M4
>>>> devices are noticeably more complicated, and even though this is a
>>>> hobby project I am worried about the time investment required to get
>>>> my device working with FPC.
>>>>
>>>> What complicates things is the way libopencm3 has their headers
>>>> structures is more standard. They avoid using structures that
>>>> represent the registers, instead using faux namespacing with lots of
>>>> underscores in macro names.
>>>>
>>>> Cheers,
>>>>        R0b0t1
>>>> _______________________________________________
>>>> 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
>
>
> _______________________________________________
> 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: Generating RTL Units for STM32 Processors

Michael Ring-2
I have uploaded my Code to github:

https://github.com/michael-ring/mbf.git

In the Patches directory you will find a patch to add all STM32L4 chips
to a vanilla fpc-trunk installation.

Please pm me for questions or use github, documentation is still very
sparse ;-)

The Blinky Example is prepared for the Nucleo-L432 Board, it does of
course not compile successfully because initial code for switching CPU
Frequency and accessing GPIO are missing for the L4 family, but this is
easy to add, L4 is similar to F0 when I remember correctly.

Michael


Am 28.02.18 um 20:11 schrieb R0b0t1:

> On Wed, Feb 28, 2018 at 11:27 AM, Michael Ring <[hidden email]> wrote:
>> Am 28.02.18 um 03:22 schrieb R0b0t1:
>>> On Tue, Feb 27, 2018 at 2:43 AM, Michael Ring <[hidden email]>
>>> wrote:
>>>> The process is completely automated and is based on converting the header
>>>> files that come in the CMSIS packages of the processors.
>>>>
>>> Excellent! What about the startup assembly files? I see an equivalent,
>>> it is autogenerated too?
>>
>> Nope, those were created manually (from Jeppe), the one relevant for the
>> STM32L432KC is cortexm4f_start.inc
>> It will automagically be included when you add definitions for the chip.
>>>
>>>> I will send you the file for that chip via pm, you will also have to
>>>> tweak
>>>> compiler/systems/t_embed.pas compiler/arm/cpuinfo.pas but this is pretty
>>>> straightforward, only extend both structs for the processors.
>>>>
>>> Yes, I forgot about this, but it does sound easy. Which chip?
>>
>> STM32L432KC
>>
>> if you plan to some some serious development I can provide you a patch file
>> for including the whole stm32l4 family
>>
> I am planning serious development. If you can provide the patch that
> would be great, but if it is any amount of work I may be able to do it
> myself with some pointers.
>
> It is my intent to stick with the L4 part I am using, but there have
> been many issues with it so far. Moving to an F3 or F4 may happen, but
> only after I attempt some actual use of the L4. Maybe eventually
> working libraries can be built up.
>
>>>> There is a second class of Headerfiles that were done half automated
>>>> (afaik)
>>>> by Jeppe Johansen that covers the STM32F7 series. Those Headers more
>>>> closely
>>>> match the STM32 code C-code examples but are a lot less portable to other
>>>> chips (Microchip etc...)
>>>>
>>> Where are these?
>> Take a look at github:
>>
>> https://github.com/Laksen/fp-stm32f7xx_hal
>>
>> great for stm32f7, but changing this to stm32l4 is a heroic effort ;-)
>>
> Right, I find myself needing to refer to STM's official HAL. Their
> normal documentation is lacking.
>
>>> I have some interest in exploring a wide variety of platforms with
>>> FPC. When doing so using C, I have unfortunately found that
>>> portability only half-exists between chips of the same family from the
>>> same manufacturer.
>>>
>>> My interest in FPC is partly an interest in increased portability, but
>>> that may need to be achieved in some other way than a HAL. This may be
>>> due to how peripheral mappings are supplied. Perhaps there is a better
>>> way I do not know about. Large projects such as
>>> https://github.com/qmk/qmk_firmware manage.
>>
>> I have done my own platform independant lib for stm32(f0)/f1/f3/f4 and pic32
>> with a focus on low memory consumption, if you are interested I can put it
>> on github, still some loose ends as I only have implemented what I needed.
>>
> Please do, thanks.
>
>>> I will be following up with you off list, since you do not seem to mind.
>>
>> let's stay on list, there are others like Christo who may be interested.
>>
>> Michael
>>
>>
>>> Cheers,
>>>        R0b0t1
>>>
>>>> Michael
>>>>
>>>>
>>>> Am 27.02.18 um 04:09 schrieb R0b0t1:
>>>>> Hello list,
>>>>>
>>>>> I'd like some pointers on generating the RTL files for a processor I
>>>>> am interested in, the STM32L432KC (which is available for ~$15 with
>>>>> JTAG on a "Nucleo" board from STMicroelectronics).
>>>>>
>>>>> The CMSIS (Cortex Microcontroller Software Interface Standard) files,
>>>>> as they come from STM, use structures to represent the registers. The
>>>>> example RTL files for STM devices seem to follow this pattern fairly
>>>>> well, but I would like to know about any discrepancies; I opened one
>>>>> file and think it was structured more closely to the way libopencm3
>>>>> does things, but I can't find it again. This may have been the file
>>>>> for the NXP part listed on the Wiki.
>>>>>
>>>>>
>>>>> How much was converted by hand, and how much can be automated? M4
>>>>> devices are noticeably more complicated, and even though this is a
>>>>> hobby project I am worried about the time investment required to get
>>>>> my device working with FPC.
>>>>>
>>>>> What complicates things is the way libopencm3 has their headers
>>>>> structures is more standard. They avoid using structures that
>>>>> represent the registers, instead using faux namespacing with lots of
>>>>> underscores in macro names.
>>>>>
>>>>> Cheers,
>>>>>         R0b0t1
>>>>> _______________________________________________
>>>>> 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
>>
>> _______________________________________________
>> 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: Generating RTL Units for STM32 Processors

Marc Santhoff-2
In reply to this post by Christo Crause
On Wed, 2018-02-28 at 06:41 +0200, Christo Crause wrote:
> On 28 Feb 2018 4:22 am, "R0b0t1" <[hidden email]> wrote:
>
> I will be following up with you off list, since you do not seem to mind.
>
>
> I'm also interested in the general topic of incorporating embedded
> controllers (avr at the moment)  into fpc.

Me too, especially STM32F407 & 446.

--
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: Generating RTL Units for STM32 Processors

R0b0t1
On Thu, Mar 1, 2018 at 2:46 PM, Marc Santhoff <[hidden email]> wrote:

> On Wed, 2018-02-28 at 06:41 +0200, Christo Crause wrote:
>> On 28 Feb 2018 4:22 am, "R0b0t1" <[hidden email]> wrote:
>>
>> I will be following up with you off list, since you do not seem to mind.
>>
>>
>> I'm also interested in the general topic of incorporating embedded
>> controllers (avr at the moment)  into fpc.
>
> Me too, especially STM32F407 & 446.
>

Well - as mentioned, it may be best to pick "standard" parts (did you
have a preference?). This is an issue even with C or C++; many parts,
especially from STM32, are very poorly documented. In C I am still
having issues with my controller than I can only fix by copying,
verbatim, the autogenerated code. At this point I suspect order of
hardware initialization matters where no order dependency is
documented.

This is kind of sad, because most of the popular STM32 parts are
rather old. For other manufacturers the situation can be even worse.
It is also sad because I want to try various products to see which is
best (e.g. PIC32 parts are very cheap but still performant), but my
experience as far as C goes is that all development environments and
vendor provided libraries are terrible.


Also, thank you Michael, I may be able to give an update with my
progress soon. It seems wise to iron out the initialization and
hardware setup in C first.

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

Re: Generating RTL Units for STM32 Processors

R0b0t1
On Thu, Mar 1, 2018 at 3:11 PM, R0b0t1 <[hidden email]> wrote:

> On Thu, Mar 1, 2018 at 2:46 PM, Marc Santhoff <[hidden email]> wrote:
>> On Wed, 2018-02-28 at 06:41 +0200, Christo Crause wrote:
>>> On 28 Feb 2018 4:22 am, "R0b0t1" <[hidden email]> wrote:
>>>
>>> I will be following up with you off list, since you do not seem to mind.
>>>
>>>
>>> I'm also interested in the general topic of incorporating embedded
>>> controllers (avr at the moment)  into fpc.
>>
>> Me too, especially STM32F407 & 446.
>>
>
> (did you have a preference?)

> Me too, especially STM32F407 & 446.

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

Re: Generating RTL Units for STM32 Processors

Michael Ring-2
In reply to this post by Marc Santhoff-2
Both STM32F407 & 446 Chips are already in fpc-trunk, so no patches are
needed to use those chips, mbf should work ok for you, I have a
development kit for STM32F407VC (Mikroe EasyMXPro V7) and I should also
have a NUCLEOF446RE Board somewhere here, so in case something does not
work I may be able to help.

Michael

Am 01.03.18 um 21:46 schrieb Marc Santhoff:

> On Wed, 2018-02-28 at 06:41 +0200, Christo Crause wrote:
>> On 28 Feb 2018 4:22 am, "R0b0t1" <[hidden email]> wrote:
>>
>> I will be following up with you off list, since you do not seem to mind.
>>
>>
>> I'm also interested in the general topic of incorporating embedded
>> controllers (avr at the moment)  into fpc.
> Me too, especially STM32F407 & 446.
>

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

Re: Generating RTL Units for STM32 Processors

Michael Ring-2
In reply to this post by R0b0t1
@R0b0t1:

FYI, I have now implemented Clock Configuration and gpio for stm32l4
chips, the blinky program works now, please pull latest mdf libs from
github.

Why do you think STM32 chips are poorly documented?

The Reference Manuals are pretty good an the code generated by
STM32CubeMX is very helpful to better understand the inner working of
the Chips.

Michael


Am 01.03.18 um 22:11 schrieb R0b0t1:

> On Thu, Mar 1, 2018 at 2:46 PM, Marc Santhoff <[hidden email]> wrote:
>> On Wed, 2018-02-28 at 06:41 +0200, Christo Crause wrote:
>>> On 28 Feb 2018 4:22 am, "R0b0t1" <[hidden email]> wrote:
>>>
>>> I will be following up with you off list, since you do not seem to mind.
>>>
>>>
>>> I'm also interested in the general topic of incorporating embedded
>>> controllers (avr at the moment)  into fpc.
>> Me too, especially STM32F407 & 446.
>>
> Well - as mentioned, it may be best to pick "standard" parts (did you
> have a preference?). This is an issue even with C or C++; many parts,
> especially from STM32, are very poorly documented. In C I am still
> having issues with my controller than I can only fix by copying,
> verbatim, the autogenerated code. At this point I suspect order of
> hardware initialization matters where no order dependency is
> documented.
>
> This is kind of sad, because most of the popular STM32 parts are
> rather old. For other manufacturers the situation can be even worse.
> It is also sad because I want to try various products to see which is
> best (e.g. PIC32 parts are very cheap but still performant), but my
> experience as far as C goes is that all development environments and
> vendor provided libraries are terrible.
>
>
> Also, thank you Michael, I may be able to give an update with my
> progress soon. It seems wise to iron out the initialization and
> hardware setup in C first.
>
> Without much cheer,
>       R0b0t1
> _______________________________________________
> 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: Generating RTL Units for STM32 Processors

R0b0t1
On Mon, Mar 5, 2018 at 1:54 PM, Michael Ring <[hidden email]> wrote:
> @R0b0t1:
>
> FYI, I have now implemented Clock Configuration and gpio for stm32l4 chips,
> the blinky program works now, please pull latest mdf libs from github.
>

Thank you Michael, it may be some time before I can work with this,
much to my dismay.

> Why do you think STM32 chips are poorly documented?
>
> The Reference Manuals are pretty good an the code generated by STM32CubeMX
> is very helpful to better understand the inner working of the Chips.
>

The generated code has been about the only thing that has helped me.
Trying to use anything but the generated code tends to lead to lots of
pain. Specifically the L4 (or just generally newer) parts seem to have
lots of changes that break compatibility with existing projects or
hardware documentation efforts.

I am lacking time, but what time I can devote to this isn't getting me
very far. Hopefully some day :).

Cheers,
     R0b0t1

> Michael
>
>
> Am 01.03.18 um 22:11 schrieb R0b0t1:
>>
>> On Thu, Mar 1, 2018 at 2:46 PM, Marc Santhoff <[hidden email]> wrote:
>>>
>>> On Wed, 2018-02-28 at 06:41 +0200, Christo Crause wrote:
>>>>
>>>> On 28 Feb 2018 4:22 am, "R0b0t1" <[hidden email]> wrote:
>>>>
>>>> I will be following up with you off list, since you do not seem to mind.
>>>>
>>>>
>>>> I'm also interested in the general topic of incorporating embedded
>>>> controllers (avr at the moment)  into fpc.
>>>
>>> Me too, especially STM32F407 & 446.
>>>
>> Well - as mentioned, it may be best to pick "standard" parts (did you
>> have a preference?). This is an issue even with C or C++; many parts,
>> especially from STM32, are very poorly documented. In C I am still
>> having issues with my controller than I can only fix by copying,
>> verbatim, the autogenerated code. At this point I suspect order of
>> hardware initialization matters where no order dependency is
>> documented.
>>
>> This is kind of sad, because most of the popular STM32 parts are
>> rather old. For other manufacturers the situation can be even worse.
>> It is also sad because I want to try various products to see which is
>> best (e.g. PIC32 parts are very cheap but still performant), but my
>> experience as far as C goes is that all development environments and
>> vendor provided libraries are terrible.
>>
>>
>> Also, thank you Michael, I may be able to give an update with my
>> progress soon. It seems wise to iron out the initialization and
>> hardware setup in C first.
>>
>> Without much cheer,
>>       R0b0t1
>> _______________________________________________
>> 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