[NEWS] New Nucleo-32 boards

[Giovanni]

Well, this is interesting and worth a post here:

http://www.st.com/web/en/news/n3742

Basically those are a much smaller format for Nucleo boards, apparently a growing family, very interesting for breadboards. Of course we plan to offer support, it will just require board files.

Giovanni

[szego]

I'm running a few of these, and wanted to contribute a patch for them. I have one question however: for the NUCLEO-F303K8, I have a problem with the os/hal/ports/STM32/STM32F3xx/stm32_registry.h file.

There's a switch #if defined(STM32F303x8) that includes the following:

Code: Select all

#define STM32_HAS_GPIOA                     TRUE
#define STM32_HAS_GPIOB                     TRUE
#define STM32_HAS_GPIOC                     TRUE
#define STM32_HAS_GPIOD                     TRUE
#define STM32_HAS_GPIOE                     FALSE
#define STM32_HAS_GPIOF                     TRUE

However on the K8 variant there is no port C or port D. What's the best way to define this properly?

1) have finer-grained preprocessor flags, e.g. #if defined(STM32F303K8).
2) over-ride the values in the board.h file, but then I need to change the registry file along these lines:

Code: Select all

/* GPIO attributes.*/
#define STM32_HAS_GPIOA                     TRUE
#define STM32_HAS_GPIOB                     TRUE
#ifndef STM32_HAS_GPIOC
#define STM32_HAS_GPIOC                     TRUE
#endif
#ifndef STM32_HAS_GPIOD
#define STM32_HAS_GPIOD                     TRUE
#endif
#define STM32_HAS_GPIOE                     FALSE

etc.

3) something else?

Thanks, Paul.

[Giovanni]

Hi,

Is that variant just a package variant or ports are physically not present? if ports are present it is better to leave them to TRUE because it is better to initialize them with pullups anyway.

Giovanni

[szego]

I'm not sure precisely what the difference is - do you mean packaging as in LQFP32 vs. LQFP64 for example? In that case, yes: the K8 is a 32-pin device.

Does that mean the port is physically present, but not exposed via pins due to the packaging? If so I think I get it.

So what's the default for those? In the Application Note AN4538, "STM32F3xx microcontroller low-power overview", section 1.4.1 it states:

To avoid extra I/O currents, all unused pins should be configured as analog inputs, in this mode the schmitt trigger input is disabled, providing zero consumption for each I/O pin.

So I've been setting unused pins in that manner. Is that not correct?

Thanks, Paul.

[Giovanni]

Hi,

I usually put unused pins as input with pull-up/down, this prevents oscillations and has not leakage currents. I guess putting them in analog mode works too but I still don't like the idea to leave them floating.

Giovanni

[szego]

No problem. I was basing the code on two things:

1) the app note
2) the behaviour of CubeMX, when you say "Set all free pins as analog (to optimise the power consumption)" in the project settings.

Just let me know the exact defaults you'd prefer to use, and I'll submit the patch that way.

Thanks, Paul.

[Giovanni]

I prefer input with pullup, all other boards are done this way and I like to be consistent if possible.

Giovanni

[szego]

Done. Here's the additional files.

Note that I didn't use the Makefile, as I build under Eclipse. And I don't know how you create the board template stuff.

Paul.

[szego]

I also have the F031 and F042 using Nil instead of RT, if that's any use.

Paul.

[Giovanni]

Hi,

I added the F303 demo, including the missing files. I also received my boards

Post the other demos, I will add them in the next days.

Giovanni