b4ab6bc7f2
arch/arm/src/stm32f0l0: Some fixes for a clean build. Still have a problem with lots of error messages coming from kconfig-mconf, but the configuation looks fine. Sometimes kconfig errors are difficult to spot. I would appreciate it anyone can spot the issue.
arch/arm/src/stm32f0l0/hardware: Rename the chip directory to hardware. This will hopefully eliminate some problems that I have seen with the chip include paths not being unique in more complex configuartions.
configs/nucleo-f072rb, configs/nucleo-f091rc, configs/stm32f051-discovery, and configs/stm32f072-discovery: Update for all of the naming changes made in arch/arm/src/stm32f0l0
arch/arm/include/stm32f0l0: Rename stm32f0 to stm32f0l0 to make a speace for STM32 L0. Rename files, functions and defines, removeing the f0_ from the names in order to make them MCU agnostic.
arch/arm/src/stm32f0l0: Rename stm32f0 to stm32f0l0 to make a speace for STM32 L0. Rename files, functions and defines, removeing the f0_ from the names in order to make them MCU agnostic.
|
||
|---|---|---|
| .. | ||
| include | ||
| nsh | ||
| scripts | ||
| src | ||
| Kconfig | ||
| README.txt | ||
STATUS
======
05/17: The basic NSH configuration is functional and shows that there is
3-4KB of free heap space. However, attempts to extend this have
failed. I suspect that 8KB of SRAM is insufficient to do much
with the existing NSH configuration. Perhaps some fine tuning
can improve this situation but at this point, I think this board
is only useful for the initial STM32 F0 bring-up, perhaps for
embedded solutions that do not use NSH and for general
experimentation.
There is also support for the Nucleo boards with the STM32 F072
and F092 MCUs. Those ports do not suffer from these problems and
seem to work well in fairly complex configurations. Apparently 8KB
is SRAM is not usable but the parts with larger 16KB and 32KB SRAMs
are better matches.