[fpc-pascal] Generating RTL Units for STM32 Processors
r030t1 at gmail.com
Wed Feb 28 20:11:24 CET 2018
On Wed, Feb 28, 2018 at 11:27 AM, Michael Ring <mail at michael-ring.org> wrote:
> Am 28.02.18 um 03:22 schrieb R0b0t1:
>> On Tue, Feb 27, 2018 at 2:43 AM, Michael Ring <mail at michael-ring.org>
>>> 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
>>> 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?
> 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
>>> by Jeppe Johansen that covers the STM32F7 series. Those Headers more
>>> 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:
> 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.
>>> 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.
>>>> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
>>> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
>> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
More information about the fpc-pascal