Added STM32F412G Discovery kit #1916

alexandruradovici · 2020-06-06T18:45:00Z

Pull Request Overview

This pull request adds the STM32F412G Discovery Kit. Features working:

LEDs
Joystick
Virtual COM

This uses the same chip as the nucleo429 so all the low level hardware implemented for it should work with this device.

Testing Strategy

This pull request was tested using an STM32F412G Discovery.

TODO or Help Wanted

Documentation Updated

Updated the relevant files in /docs

Formatting

Ran make prepush.

bradjc · 2020-06-08T15:46:37Z

boards/discovery_f412g/README.md

+> **Note:** Unlike other Tock platforms, the default kernel image for this
+> board will clear flashed apps when the kernel is loaded. This is to support
+> the non-tockloader based app flash procedure below. To preserve loaded apps,
+> comment out the `APP_HACK` variable in `src/main.rs`.


Why are all of these platforms still doing this? My impression is the naming implied this was short-term, but if it is getting copied over and over, this is going to become less a hack and more of a standard. What would it take to fix this?

I did not implement the original Nucelo boards, I think tockloader does not support this platform so far.

bradjc

Remove tools/.format_fresh

Also, should probably match the naming for the other discovery board.

bradjc · 2020-06-08T15:56:02Z

My other question, and maybe opening an issue for this would be good, is what is the roadmap/vision for Tock support on STM boards? I imagine there are probably hundreds of them, do we want to support as many as possible? I'm not saying we should or should not, but having some shared understanding of the direction would be helpful.

I'm concerned that having many boards with only OK support and testing is less beneficial than having say two boards with robust support that gets tested for releases. But there is also merit in supporting the hardware that people already have. I would probably be supportive of having a "flagship" STM board that many of us buy and is included in release testing that we concentrate support around. Then, there could be other related boards with support in Tock, with the hope that fixes/improvements for the flagship help all of the related boards. But, I'm not sure how realistic that is, or if there is a clear STM board that would make sense to prioritize.

alexandruradovici · 2020-06-08T16:04:51Z

Remove tools/.format_fresh

Also, should probably match the naming for the other discovery board.

I will rename the other discovery board also, to be consistent with the initial naming used by nucleo.

alexandruradovici · 2020-06-08T16:06:57Z

My other question, and maybe opening an issue for this would be good, is what is the roadmap/vision for Tock support on STM boards? I imagine there are probably hundreds of them, do we want to support as many as possible? I'm not saying we should or should not, but having some shared understanding of the direction would be helpful.

I'm concerned that having many boards with only OK support and testing is less beneficial than having say two boards with robust support that gets tested for releases. But there is also merit in supporting the hardware that people already have. I would probably be supportive of having a "flagship" STM board that many of us buy and is included in release testing that we concentrate support around. Then, there could be other related boards with support in Tock, with the hope that fixes/improvements for the flagship help all of the related boards. But, I'm not sure how realistic that is, or if there is a clear STM board that would make sense to prioritize.

This discovery board has more or less the same MCU as the supported nucleo (stmf4xx). I intend to fully support this discovery board as I need it for my teaching. It will take some time to reach that point.

I still think having even partial support for the boards is beneficial, as this might encourage people to contribute to them. What about having s small set of "fully" supported boards and a set of "non-fully" supported boards?

hudson-ayers · 2020-06-08T16:47:05Z

My other question, and maybe opening an issue for this would be good, is what is the roadmap/vision for Tock support on STM boards? I imagine there are probably hundreds of them, do we want to support as many as possible? I'm not saying we should or should not, but having some shared understanding of the direction would be helpful.

I'm concerned that having many boards with only OK support and testing is less beneficial than having say two boards with robust support that gets tested for releases. But there is also merit in supporting the hardware that people already have. I would probably be supportive of having a "flagship" STM board that many of us buy and is included in release testing that we concentrate support around. Then, there could be other related boards with support in Tock, with the hope that fixes/improvements for the flagship help all of the related boards. But, I'm not sure how realistic that is, or if there is a clear STM board that would make sense to prioritize.

I think the stm32f3discovery board might make sense as a "flagship" STM board if we were to go that route. It has 10 LEDs, buttons, accel/gyro/compass, and costs $15. Most importantly, it is the board required to complete the embedded rust book, so lots of people interested in getting started with embedded Rust might already have one. The main downside is it doesn't have wireless.

alexandruradovici · 2020-06-18T23:05:19Z

Remove tools/.format_fresh
Also, should probably match the naming for the other discovery board.

I will rename the other discovery board also, to be consistent with the initial naming used by nucleo.

I rename this board as STM uses this naming in their website.

ppannuto

This may be the cleanest, most readable board main file I've ever had the pleasure of reading

chips/stm32f412g/README.md

ppannuto · 2020-06-22T15:22:13Z

boards/stm32f412gdiscovery/src/main.rs

+    kernel::procs::load_processes(
+        board_kernel,
+        chip,
+        core::slice::from_raw_parts(


I know about it, but is is not merged yet. I'll update the stm boards as soon as this gets merged. Should I do it differently?

Just flagging the (potential) conflict here; whichever goes in first, the other will have to update

boards/stm32f412gdiscovery/Makefile

boards/stm32f412gdiscovery/chip_layout.ld

boards/stm32f412gdiscovery/src/io.rs

Co-authored-by: Hudson Ayers <32688905+hudson-ayers@users.noreply.github.com>

ppannuto

🎉

ppannuto

bors r+

alexandruradovici · 2020-06-29T12:55:07Z

bors seems to be stuck here ...

ppannuto · 2020-06-29T12:56:49Z

bors retry

Hmmm..

bors · 2020-06-29T13:04:13Z

Build succeeded:

alexandruradovici force-pushed the stm32f412g_discovery branch from dab4aaf to 1e116f8 Compare June 8, 2020 09:34

bradjc reviewed Jun 8, 2020

View reviewed changes

alexandruradovici force-pushed the stm32f412g_discovery branch from 419b470 to 9356c74 Compare June 18, 2020 23:02

ppannuto previously approved these changes Jun 22, 2020

View reviewed changes

hudson-ayers reviewed Jun 22, 2020

View reviewed changes

boards/stm32f412gdiscovery/Makefile Outdated Show resolved Hide resolved

boards/stm32f412gdiscovery/chip_layout.ld Outdated Show resolved Hide resolved

boards/stm32f412gdiscovery/src/io.rs Outdated Show resolved Hide resolved

alexandruradovici dismissed ppannuto’s stale review via c09bcdf June 22, 2020 15:51

alexandruradovici and others added 14 commits June 24, 2020 14:25

openocd

4f16029

initial support

c39182c

documentation and format

3b40186

delete sudo

c29d1cf

added interrupts

b60fa1f

rename

074d760

delete .format_fresh

d980e82

documentation

310f46f

touches

7edefe1

Update boards/stm32f412gdiscovery/src/io.rs

d475a66

Co-authored-by: Hudson Ayers <32688905+hudson-ayers@users.noreply.github.com>

Update boards/stm32f412gdiscovery/Makefile

d68ca62

Co-authored-by: Hudson Ayers <32688905+hudson-ayers@users.noreply.github.com>

Update boards/stm32f412gdiscovery/chip_layout.ld

05604c2

Co-authored-by: Hudson Ayers <32688905+hudson-ayers@users.noreply.github.com>

stm chip name

92700b3

added i2c and initial touch support

9242f8f

alexandruradovici force-pushed the stm32f412g_discovery branch from 021c9e3 to 9242f8f Compare June 24, 2020 11:27

alexandruradovici added 2 commits June 24, 2020 15:31

use standard openocd

9c24a14

readme

7d275f9

ppannuto previously approved these changes Jun 26, 2020

View reviewed changes

ppannuto added the last-call Final review period for a pull request. label Jun 26, 2020

bradjc added the needs-rebase label Jun 26, 2020

Merge branch 'master' into stm32f412g_discovery

c32e4fe

alexandruradovici dismissed ppannuto’s stale review via c32e4fe June 28, 2020 13:48

ppannuto approved these changes Jun 28, 2020

View reviewed changes

bors bot merged commit 4e3c160 into tock:master Jun 29, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Added STM32F412G Discovery kit #1916

Added STM32F412G Discovery kit #1916

alexandruradovici commented Jun 6, 2020

bradjc Jun 8, 2020

alexandruradovici Jun 8, 2020

bradjc left a comment •

edited

bradjc commented Jun 8, 2020

alexandruradovici commented Jun 8, 2020 •

edited

alexandruradovici commented Jun 8, 2020 •

edited

hudson-ayers commented Jun 8, 2020

alexandruradovici commented Jun 18, 2020

ppannuto left a comment

ppannuto Jun 22, 2020

alexandruradovici Jun 22, 2020

ppannuto Jun 26, 2020

ppannuto left a comment

ppannuto left a comment

alexandruradovici commented Jun 29, 2020

ppannuto commented Jun 29, 2020

bors bot commented Jun 29, 2020

Added STM32F412G Discovery kit #1916

Added STM32F412G Discovery kit #1916

Conversation

alexandruradovici commented Jun 6, 2020

Pull Request Overview

Testing Strategy

TODO or Help Wanted

Documentation Updated

Formatting

bradjc Jun 8, 2020

Choose a reason for hiding this comment

alexandruradovici Jun 8, 2020

Choose a reason for hiding this comment

bradjc left a comment • edited

Choose a reason for hiding this comment

bradjc commented Jun 8, 2020

alexandruradovici commented Jun 8, 2020 • edited

alexandruradovici commented Jun 8, 2020 • edited

hudson-ayers commented Jun 8, 2020

alexandruradovici commented Jun 18, 2020

ppannuto left a comment

Choose a reason for hiding this comment

ppannuto Jun 22, 2020

Choose a reason for hiding this comment

alexandruradovici Jun 22, 2020

Choose a reason for hiding this comment

ppannuto Jun 26, 2020

Choose a reason for hiding this comment

ppannuto left a comment

Choose a reason for hiding this comment

ppannuto left a comment

Choose a reason for hiding this comment

alexandruradovici commented Jun 29, 2020

ppannuto commented Jun 29, 2020

bors bot commented Jun 29, 2020

bradjc left a comment •

edited

alexandruradovici commented Jun 8, 2020 •

edited

alexandruradovici commented Jun 8, 2020 •

edited