profile
viewpoint
Daniel Egger therealprof @axiros https://therealprof.github.io @therealprof:matrix.org

stm32-rs/stm32f1xx-hal 209

A Rust embedded-hal HAL impl for the STM32F1 family based on japarics stm32f103xx-hal

stm32-rs/stm32f4xx-hal 139

A Rust embedded-hal HAL for all MCUs in the STM32 F4 family

japaric/stm32f103xx-hal 111

HAL for the STM32F103xx family of microcontrollers

jamwaffles/ssd1306 86

SSD1306 OLED driver

stm32-rs/stm32f0xx-hal 52

A Rust `embedded-hal` implementation for all MCUs in the STM32 F0 family

nrf-rs/nrf51-hal 18

A Rust embedded-hal impl crate for the Nordic nrf51 series of microcontrollers

stm32-rs/stm32f407g-disc 16

Rust BSP crate for the STM32F4DISCOVERY (STM32F407G-DISC) development board

nrf-rs/nrf51 12

Rust register descriptions for Nordic Semiconductor NRF51 MCUs

therealprof/display-interface 8

Rust crates providing a generic interface for display drivers and some default implementations (GPIO, SPI and I2C)

stm32-rs/nucleo-f042k6 7

Rust BSP crate for the STM Nucleo-F042K6 development board

Pull request review commentrust-embedded/wg

[RFC] Alternative new MSRV policy

+- Feature Name: msrv-2020+- Start Date: 2020-11-14+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary+[summary]: #summary++This RFC proposes an update to the [current MSRV policy], and is an+alternative to the earlier proposal [#449]. Some of the RFC text is copied+from that earlier proposal.++This proposal suggests a significantly reduced MSRV guarantee: all WG crates+must build on the _latest stable Rust release_ at all times, and it is+recommended that their main branches are checked to always build on stable via+CI on both pull requests and regularly scheduled CI runs.++[current MSRV policy]: https://github.com/rust-embedded/wg/blob/8eb6488fdb16e92e70b074acc2fcf249b3edc70b/ops/msrv.md+[#449]: https://github.com/rust-embedded/wg/pull/449++# Motivation+[motivation]: #motivation++<!-- Why are we doing this? What use cases does it support? What is the expected outcome? -->++As part of the push to take [foundational crates to 1.0] releases, it has+become necessary to be more exact on our guarantees to support versions of the+Rust compiler. This discussion [has been contentious] in the past, sparking+significant discussions in many meetings.++In particular, it has been necessary to balance the (somewhat opposed) concerns of:++1. Some users may find themselves stuck on old versions of the compiler, due to company restrictions, slow moving distribution/package managers, or regulatory concerns.+2. We maintain these crates on a volunteer basis, and our time is limited to focus on maintenance++Our current MSRV policy has been found to have significant flaws around how+dependencies are managed. Since many WG crates depend on non-WG crates, we+cannot control the MSRV policy of those dependencies without investing+additional effort to vendor or fork those crates. Consequently, a non-breaking+update to a dependency might violate a published crate's MSRV.++So far, the WG has received very little feedback from any users who rely on the+relatively old MSRV, and so most of their use cases have been hypothetical.

We can certainly review the policy in the future, especially if things seem to have settled down further. Sealed Rust is sort of its own thing I think; it would be a commercial offering with commercial support for its MSRV and library versions, so we might not expect to support it as a volunteer-run WG. Or, we might, if it's useful, or perhaps a commercial organisation could help maintain WG support.

Even 1.0 crates would have the same issue with dependencies - it's not generally considered a semver-breaking change to require a new stable feature, so (all hypothetical) cortex-m 1.0 could rely on some bitfields 1.0 and have an MSRV of 1.48, then bitfields 1.0.1 comes out with an MSRV of 1.50 -- what does cortex-m do? In this policy, it just now has an MSRV of 1.50. In other policies we either have to pin bitfields==1.0.0 and force users to deal with the issues, or we'd have to release cortex-m 2.0 just to increase our MSRV, which isn't great either. Or, we forbid using any dependencies not controlled by the WG (or vendor them all ourselves). I think the problem is basically no different with 1.0 crates as with any other version.

adamgreig

comment created time in 2 hours

Pull request review commentrust-embedded/wg

[RFC] Alternative new MSRV policy

+- Feature Name: msrv-2020+- Start Date: 2020-11-14+- RFC PR: (leave this empty)+- Rust Issue: (leave this empty)++# Summary+[summary]: #summary++This RFC proposes an update to the [current MSRV policy], and is an+alternative to the earlier proposal [#449]. Some of the RFC text is copied+from that earlier proposal.++This proposal suggests a significantly reduced MSRV guarantee: all WG crates+must build on the _latest stable Rust release_ at all times, and it is+recommended that their main branches are checked to always build on stable via+CI on both pull requests and regularly scheduled CI runs.++[current MSRV policy]: https://github.com/rust-embedded/wg/blob/8eb6488fdb16e92e70b074acc2fcf249b3edc70b/ops/msrv.md+[#449]: https://github.com/rust-embedded/wg/pull/449++# Motivation+[motivation]: #motivation++<!-- Why are we doing this? What use cases does it support? What is the expected outcome? -->++As part of the push to take [foundational crates to 1.0] releases, it has+become necessary to be more exact on our guarantees to support versions of the+Rust compiler. This discussion [has been contentious] in the past, sparking+significant discussions in many meetings.++In particular, it has been necessary to balance the (somewhat opposed) concerns of:++1. Some users may find themselves stuck on old versions of the compiler, due to company restrictions, slow moving distribution/package managers, or regulatory concerns.+2. We maintain these crates on a volunteer basis, and our time is limited to focus on maintenance++Our current MSRV policy has been found to have significant flaws around how+dependencies are managed. Since many WG crates depend on non-WG crates, we+cannot control the MSRV policy of those dependencies without investing+additional effort to vendor or fork those crates. Consequently, a non-breaking+update to a dependency might violate a published crate's MSRV.++So far, the WG has received very little feedback from any users who rely on the+relatively old MSRV, and so most of their use cases have been hypothetical.

I take this lack of feedback as a temporary situation caused by the immaturity of the current ecosystem, but l expect this will change in the context of something like Sealed Rust where the version might be frozen for years.

Is it commonly agreed that the policy will change once such a situation is close to becoming reality?

Similarly, if a create becomes 1.0 shouldn't there an expectation that the msrv to be kept the same for all 1.x versions?

adamgreig

comment created time in 2 hours

pull request commentARMmbed/DAPLink

Add SWO support for MIMXRT1170-EVK

Hi,

What is the ci-morph ? thx

groleo

comment created time in 2 hours

pull request commentARMmbed/DAPLink

Add SWO support for MIMXRT1170-EVK

/morph test

groleo

comment created time in 4 hours

issue commentrust-embedded/alloc-cortex-m

Make a new release on crates.io

Could you make a release with the new changes in #37 too please? Meanwhile I'll use the git link

diondokter

comment created time in 5 hours

pull request commentARMmbed/DAPLink

Add SWO support for MIMXRT1170-EVK

/morph test

groleo

comment created time in 8 hours

issue commentARMmbed/DAPLink

DAPLink tests gets hanged on Toshiba Targets

The Bootloader firmware gets missing from the board after the tests hang, so again and again, Bootloader has to be flashed.

Just reading the command. if you are executing --loadbl I would expect that bootloader is loaded before running the tests. If the tests are already executing, bootloader should be already loaded and checked, so should be valid. Does this mean later tests are corrupting the bootloader ?

How does this behave without --loadbl ?

deepak-shreshti

comment created time in 8 hours

issue commentARMmbed/DAPLink

USBD_CDC_ACM_SendBreak implment issue

@yandld Is this a bug or a feature? I belive the latter. Can you confirm ?

yandld

comment created time in 8 hours

issue commentARMmbed/DAPLink

Can you tell me the support requests?

@git-binbin Can you provide more details ?

git-binbin

comment created time in 8 hours

issue closedARMmbed/DAPLink

can not use progen generate the project

PS F:\DAPLINK\DAPLink> progen generate -f projects.yaml -p stm32f103xb_stm32f746zg_if -t uvision Traceback (most recent call last): File "C:\Python27\Scripts\progen-script.py", line 11, in <module> load_entry_point('project-generator==0.9.13', 'console_scripts', 'progen')() File "c:\python27\lib\site-packages\project_generator\main.py", line 62, in main return args.func(args) File "c:\python27\lib\site-packages\project_generator\commands\generate.py", line 30, in run if project.generate(args.tool, copied=args.copy, copy=args.copy) == -1: File "c:\python27\lib\site-packages\project_generator\project.py", line 552, in generate files = exporter(self.project['export'], self.settings).export_project() File "c:\python27\lib\site-packages\project_generator\tools\uvision.py", line 490, in export_project path, files = self._export_single_project('uvision') #todo: uvision will switch to uv4 File "c:\python27\lib\site-packages\project_generator\tools\uvision.py", line 452, in _export_single_project self._set_target(expanded_dic, uvproj_dic, tool_name) File "c:\python27\lib\site-packages\project_generator\tools\uvision.py", line 317, in _set_target if not pro_def.is_supported(expanded_dic['target'].lower()): File "c:\python27\lib\site-packages\project_generator_definitions\definitions.py", line 129, in is_supported mcu_record = self.targets.get_mcu_record(target) if self.mcus.get_mcu_record(target) is None else self.mcus.get_mcu_record(target) File "c:\python27\lib\site-packages\project_generator_definitions\definitions.py", line 46, in get_mcu_record return _load_record(mcu_path) File "c:\python27\lib\site-packages\project_generator_definitions\definitions.py", line 28, in _load_record config = yaml.load(project_file, Loader=yaml.FullLoader) AttributeError: 'module' object has no attribute 'FullLoader'

closed time in 8 hours

2502797718

issue commentARMmbed/DAPLink

build without drag-n-drop (MSD) support

It should be possible just not using DAPLink/records/daplink/drag-n-drop.yaml . This one defines that macro and adds sources.

moyoumos

comment created time in 8 hours

pull request commentARMmbed/DAPLink

always put the main.o code and the startup data in RAM1

cc @flit @maclobdell @marcuschangarm @0xc0170

groleo

comment created time in 8 hours

pull request commentARMmbed/DAPLink

Add SWO support for MIMXRT1170-EVK

v6: fix the flash-algo bits (Alex Yang alex.yang@nxp.com) v5: add source/cmsis-driver include to records/hic_hal/lpc4322.yaml (previously it was in mimxrt1170_evk_qspi.yaml) v4: git add the missing RTE_Driver header files (GPDMA_LPC43xx.h, USART_LPC43xx.h and SCU_LPC43xx.h) v3: reorder commits (first reorder the headers, then add platform specific changes) v2: CMSIS-Driver headers under source/cmsis-driver as you prefer.

groleo

comment created time in 8 hours

issue commentrust-embedded/wg

Panic handler binary size bloat

Is there a solution for this now that RFC-2070 has been closed?

japaric

comment created time in 10 hours

issue commentrust-embedded/cortex-m-rt

RAM initialization code violates pointer provenance

Linking relevant issues so others can follow breadcrumbs:

  • https://github.com/betrusted-io/betrusted-rt/issues/1
  • https://github.com/iqlusioninc/usbarmory.rs/issues/74
  • https://github.com/rust-embedded/riscv-rt/issues/69
  • https://github.com/rust-embedded/msp430-rt/issues/13

We also need to reach out to tock-os, I'll open an issue there shortly.

jonas-schievink

comment created time in 11 hours

pull request commentrust-lang/blog.rust-lang.org

Use the `disc` list style type

So where should I change it if not here? Should I add a new CSS file that overrides this style?

camelid

comment created time in 15 hours

delete branch rust-embedded/svd2rust

delete branch : cortex-m-InterruptNumber

delete time in 18 hours

PR merged rust-embedded/svd2rust

Implement new InterruptNumber trait from next cortex-m release S-waiting-on-review T-tools

This eliminates the bare-metal and cortex-m-rt dependencies for Cortex-M and thus changes CI and svd2rust-regress accordingly.

Replaces #455

Signed-off-by: Daniel Egger daniel@eggers-club.de

+15 -44

6 comments

5 changed files

therealprof

pr closed time in 18 hours

push eventrust-embedded/svd2rust

Daniel Egger

commit sha be9fd648733fa9e428676ed12cdb240917f08c28

Implement new InterruptNumber trait from next cortex-m release This eliminates the bare-metal and cortex-m-rt dependencies for Cortex-M and thus changes CI and svd2rust-regress accordingly. Replaces #455 Signed-off-by: Daniel Egger <daniel@eggers-club.de>

view details

bors[bot]

commit sha c68b71c09c87ff17270e9e8e6cb63f45276b5068

Merge #473 473: Implement new InterruptNumber trait from next cortex-m release r=adamgreig a=therealprof This eliminates the bare-metal and cortex-m-rt dependencies for Cortex-M and thus changes CI and svd2rust-regress accordingly. Replaces #455 Signed-off-by: Daniel Egger <daniel@eggers-club.de> Co-authored-by: Daniel Egger <daniel@eggers-club.de>

view details

push time in 18 hours

delete branch rust-embedded/svd2rust

delete branch : staging.tmp

delete time in 18 hours

push eventrust-embedded/svd2rust

Daniel Egger

commit sha be9fd648733fa9e428676ed12cdb240917f08c28

Implement new InterruptNumber trait from next cortex-m release This eliminates the bare-metal and cortex-m-rt dependencies for Cortex-M and thus changes CI and svd2rust-regress accordingly. Replaces #455 Signed-off-by: Daniel Egger <daniel@eggers-club.de>

view details

bors[bot]

commit sha c68b71c09c87ff17270e9e8e6cb63f45276b5068

Merge #473 473: Implement new InterruptNumber trait from next cortex-m release r=adamgreig a=therealprof This eliminates the bare-metal and cortex-m-rt dependencies for Cortex-M and thus changes CI and svd2rust-regress accordingly. Replaces #455 Signed-off-by: Daniel Egger <daniel@eggers-club.de> Co-authored-by: Daniel Egger <daniel@eggers-club.de>

view details

push time in 18 hours

push eventrust-embedded/svd2rust

Daniel Egger

commit sha be9fd648733fa9e428676ed12cdb240917f08c28

Implement new InterruptNumber trait from next cortex-m release This eliminates the bare-metal and cortex-m-rt dependencies for Cortex-M and thus changes CI and svd2rust-regress accordingly. Replaces #455 Signed-off-by: Daniel Egger <daniel@eggers-club.de>

view details

bors[bot]

commit sha 7b0b15672a640087e2edde880a1c4c4465e5069d

[ci skip][skip ci][skip netlify] -bors-staging-tmp-473

view details

push time in 18 hours

create barnchrust-embedded/svd2rust

branch : staging.tmp

created branch time in 18 hours

issue commentARMmbed/DAPLink

RFE : add support for "IBDAP Adapter from Armstart"

The origin IBDAP source code is now relocated to: https://github.com/ibdap/ibdap-cmsis-dap From what we have investigated, DAPLink needs some work to replace proprietary dependencies in order to support building the source code from gcc. Am I right @flit ?

captcha1

comment created time in 18 hours

issue commentstm32-rs/stm32f4xx-hal

Complementary PWM outputs with dead time

It would be great to see it in HAL.

Yes, let's keep this open to track that.

kirill-havryliuk

comment created time in 18 hours

pull request commentrust-embedded/cortex-m-rt

Initialize RAM in assembly

r? @thalesfragoso

(rust-highfive has picked a reviewer for you, use r? to override)

jonas-schievink

comment created time in 19 hours

PR opened rust-embedded/cortex-m-rt

Initialize RAM in assembly

Fixes #300

+32 -32

0 comment

10 changed files

pr created time in 19 hours

delete branch rust-embedded/wg

delete branch : 2020-11-24

delete time in a day

more