On Wed, Feb 28, 2018 at 11:27 AM, Michael Ring <m...@michael-ring.org> wrote: > Am 28.02.18 um 03:22 schrieb R0b0t1: >> >> On Tue, Feb 27, 2018 at 2:43 AM, Michael Ring <m...@michael-ring.org> >> 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 - fpc-pascal@lists.freepascal.org >>>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >>> >>> >>> _______________________________________________ >>> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >>> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal >> >> _______________________________________________ >> fpc-pascal maillist - fpc-pascal@lists.freepascal.org >> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > > _______________________________________________ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
