boards: add nucleo-f042 by vincent-d · Pull Request #6273 · RIOT-OS/RIOT

vincent-d · 2016-12-28T12:54:39Z

This PR adds the support for the tiny nucleo-f042 board. This board is based on a stm32f042k6 MCU.

I have succesfully ran hello_world, ipc_pingpong and default examples.

aabadie

Tested on board, works well. Well done 👍

aabadie · 2017-01-05T13:24:44Z

boards/nucleo-f042/include/periph_conf.h

+ * oscillator provided on the X2 slot.
+ * See Nucleo User Manual UM1724 section 5.6.2.
+ */
+//#define RTC_NUMOF           (1U)


RTC is supported on STM32f0 CPUs, so why commenting this out ?

RTC is indeed supported, but there is no LSE on this board. I should change the define to 0, btw.

The other option is to add the capability of running with the LSI to the RTC driver, but this require more work ;)

makes sense. I'm fine with the define to 0 then.

aabadie · 2017-01-05T13:40:10Z

It would be great if you could add a wiki page here describing this board.

aabadie · 2017-01-05T13:46:41Z

I ran a few tests (mainly the xtimer ones) and had some ram overflows at linkage. This CPU has only 6k of ram so you'll have to add it in the BOARD_INSUFFICIENT_MEMORY variable in a few Makefiles.
Let's ask Murdock about that.

vincent-d · 2017-01-05T14:37:25Z

@aabadie I am wondering if we could reduce the default thread stack size for this board. I ran some tests with the line export CFLAGS=-DTHREAD_STACKSIZE_DEFAULT=512 in the board's Makefile.include and it run fine. Otherwise some tests just do not link or crash early when printing.

I'm not sure if it should be set on the board level or application level though.

aabadie · 2017-01-06T09:09:23Z

@aabadie I am wondering if we could reduce the default thread stack size for this board. I ran some tests with the line export CFLAGS=-DTHREAD_STACKSIZE_DEFAULT=512 in the board's Makefile.include and it run fine.

Sounds reasonable. Maybe @OlegHahm, @kaspar030 have a better opinion on that.

kYc0o · 2017-01-06T11:02:20Z

I think the best place could be here just next to the header include.

vincent-d · 2017-01-06T11:40:43Z

board added to BAORD_INSUFFICIENT_MEMORY in tests which do not compile. Default stack size reduced in the way suggested by @kYc0o

Rebased on latest master.

aabadie

ACK when Murdock is happy, commits are squashed and the tests/conn_can/mapping_read.py python file is removed

aabadie · 2017-01-06T12:47:07Z

tests/conn_can/mapping_read.py

@@ -0,0 +1,35 @@
+import re


Looks like you added this file by mistake (git add tests ?)

oops, indeed git add tests :D

vincent-d · 2017-01-06T13:40:54Z

fixed and squashed

OlegHahm · 2017-01-06T13:42:25Z

@aabadie I am wondering if we could reduce the default thread stack size for this board. I ran some tests with the line export CFLAGS=-DTHREAD_STACKSIZE_DEFAULT=512 in the board's Makefile.include and it run fine. Otherwise some tests just do not link or crash early when printing.

Why do you think that this stack size would be sufficient for this MCU but not for other MCUs from the same family?

edited

vincent-d · 2017-01-06T13:56:40Z

Well, I guess it depends on your application.

The stack size seems enough for basic application, but for bigger ones it could be an isssue. Anyway the RAM is small on this micro, so you will not be able to run a lot of threads, especially if you use some more memory for data. Moreover printf needs some free RAM used as heap.

I don't mind reverting back that change and letting the default stack size to 1024.

OlegHahm · 2017-01-06T14:09:09Z

I agree with your assessments, but I would leave it to the application developer to choose the optimized stack size values. The default values per MCU (family) are intended to be on the safe side for most standard cases.

vincent-d · 2017-01-06T14:12:55Z

I'm fine with that.

Stack size change removed, and squashed.

OlegHahm · 2017-01-06T14:16:49Z

In this case, immediate squashing is no issue, but usually you should not squash before a reviewer has approved the amendment (just in case you didn't know).

OlegHahm

@aabadie already approved this PR

aabadie · 2017-01-06T17:33:45Z

@vincent-d, there are remaining issues reported by Murdock.

vincent-d · 2017-01-09T09:18:41Z

#6187 has been merged in between.

I will update that PR with the new uart driver.

haukepetersen · 2017-01-09T09:53:44Z

cool, thanks!

vincent-d · 2017-01-09T10:59:40Z

Do we care about the whitespace check fail in the vendor header ?

OlegHahm · 2017-01-09T12:15:55Z

If it's just failing because of trailing white spaces it should be super simple to fix, right?

vincent-d · 2017-01-09T14:39:31Z

Murdock still complains about some unrelated errors (lwip download failed ?) but it looks OK now.

Shall I squash ?

aabadie · 2017-01-09T14:56:34Z

can you:

git commit --amend
git push -f

?

aabadie · 2017-01-09T14:56:52Z

This will force a Murdock restart

vincent-d · 2017-01-10T09:20:43Z

Murdock seems happy.

aabadie · 2017-01-10T09:27:23Z

@vincent-d, Murdock is complaining because this branch needs squashing. Can you create 2 separate commits with comments:

cpu/stm32f0: add support for stm32f042x6 mcu
boards/nucleo-f042: initial support

aabadie added Platform: ARM Platform: This PR/issue effects ARM-based platforms Type: new feature The issue requests / The PR implemements a new feature for RIOT labels Dec 28, 2016

aabadie assigned haukepetersen and aabadie Dec 28, 2016

OlegHahm assigned DipSwitch Jan 3, 2017

aabadie reviewed Jan 5, 2017

View reviewed changes

aabadie added the CI: ready for build If set, CI server will compile all applications for all available boards for the labeled PR label Jan 5, 2017

vincent-d force-pushed the pr/nucleo-f042 branch from b0ae483 to 1ac803c Compare January 6, 2017 11:38

aabadie added the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Jan 6, 2017

aabadie requested changes Jan 6, 2017

View reviewed changes

vincent-d force-pushed the pr/nucleo-f042 branch from 1ac803c to 04cf9f4 Compare January 6, 2017 13:39

vincent-d force-pushed the pr/nucleo-f042 branch from 04cf9f4 to 27fa772 Compare January 6, 2017 14:12

OlegHahm removed the CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable label Jan 6, 2017

OlegHahm approved these changes Jan 6, 2017

View reviewed changes

aabadie approved these changes Jan 9, 2017

View reviewed changes

vincent-d force-pushed the pr/nucleo-f042 branch from 27fa772 to 6b3e6e9 Compare January 9, 2017 13:21

vincent-d force-pushed the pr/nucleo-f042 branch from 8b5946f to faee662 Compare January 9, 2017 14:59

Vincent Dupont added 2 commits January 10, 2017 10:34

cpu/stm32f0: add support for stm32f042x6 mcu

83b8495

boards/nucleo-f042: initial support

1a12a40

vincent-d force-pushed the pr/nucleo-f042 branch from faee662 to 1a12a40 Compare January 10, 2017 09:35

PeterKietzmann merged commit f76b2f4 into RIOT-OS:master Jan 10, 2017

aabadie mentioned this pull request Jan 13, 2017

boards/nucleo32-f031: initial support #6345

Merged

aabadie mentioned this pull request Mar 1, 2017

boards, nucleo: THREAD_STACKSIZE_DEFAULT too large #6669

Closed

vincent-d deleted the pr/nucleo-f042 branch March 2, 2017 14:59

kaspar030 mentioned this pull request Jun 14, 2018

core: add more stacksize defines #9356

Merged

Conversation

vincent-d commented Dec 28, 2016 • edited by haukepetersen Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aabadie left a comment

Choose a reason for hiding this comment

Uh oh!

aabadie Jan 5, 2017

Choose a reason for hiding this comment

Uh oh!

vincent-d Jan 5, 2017

Choose a reason for hiding this comment

Uh oh!

aabadie Jan 5, 2017

Choose a reason for hiding this comment

Uh oh!

aabadie commented Jan 5, 2017

Uh oh!

aabadie commented Jan 5, 2017

Uh oh!

vincent-d commented Jan 5, 2017

Uh oh!

aabadie commented Jan 6, 2017

Uh oh!

kYc0o commented Jan 6, 2017

Uh oh!

vincent-d commented Jan 6, 2017

Uh oh!

aabadie left a comment

Choose a reason for hiding this comment

Uh oh!

aabadie Jan 6, 2017

Choose a reason for hiding this comment

Uh oh!

vincent-d Jan 6, 2017

Choose a reason for hiding this comment

Uh oh!

vincent-d commented Jan 6, 2017

Uh oh!

OlegHahm commented Jan 6, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vincent-d commented Jan 6, 2017

Uh oh!

OlegHahm commented Jan 6, 2017

Uh oh!

vincent-d commented Jan 6, 2017

Uh oh!

OlegHahm commented Jan 6, 2017

Uh oh!

OlegHahm left a comment

Choose a reason for hiding this comment

Uh oh!

aabadie commented Jan 6, 2017

Uh oh!

vincent-d commented Jan 9, 2017

Uh oh!

haukepetersen commented Jan 9, 2017

Uh oh!

vincent-d commented Jan 9, 2017

Uh oh!

OlegHahm commented Jan 9, 2017

Uh oh!

vincent-d commented Jan 9, 2017

Uh oh!

aabadie commented Jan 9, 2017

Uh oh!

aabadie commented Jan 9, 2017

Uh oh!

vincent-d commented Jan 10, 2017

Uh oh!

aabadie commented Jan 10, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

vincent-d commented Dec 28, 2016 •

edited by haukepetersen

Loading

OlegHahm commented Jan 6, 2017 •

edited

Loading