@@ -8,17 +8,17 @@ source code of the stm32f3xx-hal crate.
8
8
For more information on how the STM32CubeMX database is structured, check out
9
9
the README in the [ cube-parse] ( https://github.com/dbrgn/cube-parse ) repository.
10
10
11
- Because by default cargo tries to use the ` thumbv7em-none-eabihf ` target, due
12
- to what's specified in the ` .cargo/config ` , you need to manually specify your
13
- host's target when building ` codegen ` , e.g.:
11
+ Because by default cargo tries to use the ` x86_64-unknown-linux-gnu ` target,
12
+ when building ` codegen ` , due to what's specified in the ` .cargo/config ` , you
13
+ need to manually specify your host's target if it differs from that , e.g.:
14
14
15
15
```
16
- $ cargo run --target x86_64-unknown-linux-gnu -- help
16
+ $ cargo run --target x86_64-apple-darwin -- help
17
17
```
18
18
19
19
` codgen ` can generate the following code:
20
20
21
- - GPIO mappings
21
+ - [ GPIO mappings] ( #gpio-mappings )
22
22
23
23
## GPIO mappings
24
24
@@ -27,12 +27,12 @@ invocations at the end of `src/gpio.rs`. Re-generating those macro-invocations
27
27
is simply a matter of deleting the old ones and then executing:
28
28
29
29
```
30
- $ cargo run --target $host_target -- gpio $cubemx_db_path >> ../src/gpio.rs
30
+ $ cargo run -- gpio $cubemx_db_path >> ../src/gpio.rs
31
31
```
32
32
33
- ` $cubemx_db_path ` must be the path to the ` db/mcu ` directory under an
33
+ ` $cubemx_db_path ` must be the path to the ` db/ ` directory under an
34
34
STM32CubeMX installation. With a default Linux install, this would be
35
- ` /opt/stm32cubemx/db/mcu ` .
35
+ ` /opt/stm32cubemx/db ` .
36
36
37
37
The generated ` gpio! ` invocations are gated by features whose names are derived
38
38
from the respective GPIO internal peripheral (IP) version:
0 commit comments