[fpc-pascal] Generating RTL Units for STM32 Processors
r030t1 at gmail.com
Sat Mar 31 22:55:54 CEST 2018
On Mon, Mar 5, 2018 at 1:54 PM, Michael Ring <mail at michael-ring.org> wrote:
> 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 :).
> Am 01.03.18 um 22:11 schrieb R0b0t1:
>> On Thu, Mar 1, 2018 at 2:46 PM, Marc Santhoff <M.Santhoff at web.de> wrote:
>>> On Wed, 2018-02-28 at 06:41 +0200, Christo Crause wrote:
>>>> On 28 Feb 2018 4:22 am, "R0b0t1" <r030t1 at gmail.com> 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
>> 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,
>> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
> fpc-pascal maillist - fpc-pascal at lists.freepascal.org
More information about the fpc-pascal