profile
viewpoint
Jorge Aparicio japaric @ferrous-systems Berlin, Germany https://blog.japaric.io/ Making awesome @rust-lang stuff at @ferrous-systems. Core member of the @rust-embedded WG. He/they

bheisler/criterion.rs 1233

Statistics-driven benchmarking library for Rust

japaric/cargo-call-stack 285

Whole program static stack analysis

japaric/f3 81

Board Support Crate for the STM32F3DISCOVERY

japaric/cast.rs 53

Machine scalar casting that meets your expectations

japaric/embedded-in-rust 47

A blog about Rust and embedded stuff

iqlusioninc/usbarmory.rs 41

Bare metal Rust support for USB armory MkII devices

japaric/embedded2020 26

A fresh look at embedded Rust development

japaric/cty 13

Type aliases to C types like c_int for use with bindgen

japaric/cortex-m-funnel 12

[Experiment] A lock-free, wait-free, block-free logger for the ARM Cortex-M architecture

japaric/2wd 11

A remotely controlled wheeled robot

push eventrust-embedded/showcase

Travis CI User

commit sha 6342c3fba753952008bddf8c5ae4edb0b5ea6577

Update documentation

view details

push time in 18 hours

push eventrust-embedded/discovery

Travis CI User

commit sha ef3313a1f96fb0b5ae716cc0798d10e8ee626f10

Update documentation

view details

push time in 2 days

push eventrust-embedded/showcase

Travis CI User

commit sha 96c69b9bd1493d31f2426589a0c0e15ed7ff9c7f

Update documentation

view details

push time in 2 days

push eventrust-embedded/book

Travis CI User

commit sha 226844675d9b67ad7db384e3d2d39ccb4628e60b

Update documentation

view details

push time in 2 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 42e1fbaa07c1fa53f43fdcb8f5991f53940fc460

Update documentation

view details

push time in 2 days

PR opened rtfm-rs/cortex-m-rtfm

allow handlers to be named 'main'

#[init], #[idle] and #[task] handlers can now be named main

fixes #311

+82 -3

0 comment

7 changed files

pr created time in 2 days

create barnchrtfm-rs/cortex-m-rtfm

branch : gh311

created branch time in 2 days

pull request commentjaparic/cargo-project

Use Path::join instead of hardcoded forward slash

v0.2.4 is out and includes this fix

SamP20

comment created time in 2 days

push eventjaparic/cargo-project

Jorge Aparicio

commit sha 6f7e79ec9268bdb87f9cdd40f44fc675725797aa

v0.2.4

view details

push time in 2 days

push eventjaparic/cargo-project

SamP20

commit sha 6774d0ee983a9054de81695112d56f6dcb980fd0

Use Path::join instead of hardcoded forward slash

view details

Jorge Aparicio

commit sha 860590a64f584f896233357bb8a391f76a459dff

fix unit tests on windows

view details

Jorge Aparicio

commit sha fe55e72b281dfd5b459ab4c0d2e35bf34603ea31

Merge pull request #8 from SamP20/master Use Path::join instead of hardcoded forward slash

view details

push time in 2 days

PR merged japaric/cargo-project

Use Path::join instead of hardcoded forward slash

For some reason Windows hates forward slashes which caused https://github.com/probe-rs/cargo-flash/issues/21. This should hopefully fix it.

+11 -25

6 comments

1 changed file

SamP20

pr closed time in 2 days

pull request commentjaparic/cargo-project

Use Path::join instead of hardcoded forward slash

CI is green; I have tested manually on Windows. Merging.

Thanks for the PR @SamP20 !

SamP20

comment created time in 2 days

push eventSamP20/cargo-project

Jorge Aparicio

commit sha 860590a64f584f896233357bb8a391f76a459dff

fix unit tests on windows

view details

push time in 2 days

push eventrust-embedded/showcase

Travis CI User

commit sha fbbb4916034f2ccb71b230fc32d4f468eeeb2b86

Update documentation

view details

push time in 3 days

push eventrust-embedded/book

Travis CI User

commit sha 8a95a273535b242a31b719f7e5ca1f98bfe177d3

Update documentation

view details

push time in 3 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 635be73a33aceecc4f064367e12b562cc6a0f81f

Update documentation

view details

push time in 3 days

push eventrust-embedded/discovery

Travis CI User

commit sha 1c06d4fc27190f0214ef9f641a399f6b9e803f8d

Update documentation

view details

push time in 4 days

push eventrust-embedded/showcase

Travis CI User

commit sha f1d255246f23b231a4a23e86a13f8aafd178ddaa

Update documentation

view details

push time in 4 days

push eventjaparic/usb2

Jorge Aparicio

commit sha 539f178d6a90610e3a0e34b0a1753026bbfe6cab

add some tests

view details

push time in 4 days

push eventrust-embedded/book

Travis CI User

commit sha fa4b27b9fe0602dd747b03b80bf8fd1b4ee26dbc

Update documentation

view details

push time in 4 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 21b839f0324b1180a39c079bcde34c2be3ab6b96

Update documentation

view details

push time in 4 days

push eventrust-embedded/discovery

Travis CI User

commit sha ed9ef4a13f01bece3ed01f543ac55edf81ff75b9

Update documentation

view details

push time in 5 days

push eventrust-embedded/showcase

Travis CI User

commit sha 96cd848a6f9e5cc7d2e0d7e116bd830bdd75eefa

Update documentation

view details

push time in 5 days

pull request commentrtfm-rs/cortex-m-rtfm

do not optimize build deps

CI times: this PR, incremental re-build after small codegen change: https://travis-ci.org/github/rtfm-rs/cortex-m-rtfm/builds/691468213

it seems this change cuts down the completion time of some build jobs by ~2 mins. It does break the MSRV build as it is but that can be addressed in ci/script.sh.

japaric

comment created time in 5 days

push eventrtfm-rs/cortex-m-rtfm

Jorge Aparicio

commit sha 3ed4fe3771e0187cb1ab40511803fc117e2e36f6

TODO(remove) codegen no-op

view details

push time in 5 days

pull request commentrtfm-rs/cortex-m-rtfm

do not optimize build deps

CI times: this PR, build from scratch: https://travis-ci.org/github/rtfm-rs/cortex-m-rtfm/builds/691455729

CI times: this PR, incremental re-build (*): https://travis-ci.org/github/rtfm-rs/cortex-m-rtfm/builds/691464099

CI times last PR: https://travis-ci.org/github/rtfm-rs/cortex-m-rtfm/builds/678193581

(*) I only modified Cargo.toml so it may not be a fair comparison

japaric

comment created time in 5 days

push eventrtfm-rs/cortex-m-rtfm

Jorge Aparicio

commit sha 303e964a1065fc8a1ef5e76ae8bffb27bcf0ef5e

touch src/lib.rs

view details

push time in 5 days

push eventrtfm-rs/cortex-m-rtfm

Jorge Aparicio

commit sha 709e893d0055381a751b1ac34a43282f19912711

trigger incremental CI re-build

view details

push time in 5 days

pull request commentrtfm-rs/rfcs

[RFC] Mod instead of const

if third_party crate defines it's own #[task] attribute. what does this do:

mod app {
    use third_party::task;

    #[task]
     fn foo(cx: foo::Context) {}
}

#[third_party::task]
fn bar(cx: bar::Context) {}
AfoHT

comment created time in 5 days

PR opened rtfm-rs/cortex-m-rtfm

do not optimize build deps

this may make CI faster

+15 -0

0 comment

1 changed file

pr created time in 5 days

create barnchrtfm-rs/cortex-m-rtfm

branch : faster-ci-question-mark

created branch time in 5 days

pull request commentserde-rs/json

tweak f64 deserialization to make float roundtrips work

@dtolnay did you have a chance to look at this PR? :eyes:

japaric

comment created time in 5 days

push eventjaparic/usb2

Jorge Aparicio

commit sha c2b8118e667026f690c847782ebc5809aba749fe

add device State

view details

push time in 5 days

push eventjaparic/usb2

Jorge Aparicio

commit sha 9f14b196b0e027b4186276bac0040d3eeec2acad

SET_ADDRESS argument can be 0

view details

push time in 5 days

create barnchjaparic/usb2

branch : master

created branch time in 5 days

created repositoryjaparic/usb2

USB 2.0 data types

created time in 5 days

push eventrust-embedded/discovery

Travis CI User

commit sha 44a6eaf32641795d61f45b50adcaa35c76dc6eb3

Update documentation

view details

push time in 6 days

push eventrust-embedded/showcase

Travis CI User

commit sha f5c583bff0b0443c2a7afe6ee7d1136bf52174ed

Update documentation

view details

push time in 6 days

push eventjaparic/embedded2020

Jorge Aparicio

commit sha 2b73f8f0e10956c2d899fe4fd05e1e7e02da97ce

properly account for CRC

view details

Jorge Aparicio

commit sha 6fe31c38d050eed7720a3b4d1d1e4e2e6b313d78

regen/binfmt: version symbols to avoid collisions

view details

Jorge Aparicio

commit sha df6aedcd03fcf5b2216adb07d052b7e469693181

SPI

view details

Jorge Aparicio

commit sha 576014264357964683236bc31b51efd310fb6560

compiler_fence -> dma_*

view details

Jorge Aparicio

commit sha c5375934f77f7265bdc09a94bed1020a9e6335ae

.

view details

push time in 6 days

push eventrust-embedded/book

Travis CI User

commit sha 724152f184b4e3ed63d4de90f097b7317ee68e79

Update documentation

view details

push time in 6 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 5a9d305bf790facac9f402b571a5750cc6c749e8

Update documentation

view details

push time in 6 days

push eventrust-embedded/book

Travis CI User

commit sha d676475143e1cf6d144dea657103c78cd4e66908

Update documentation

view details

push time in 6 days

push eventrust-embedded/discovery

Travis CI User

commit sha 6a8648ad350c051340dfea6c29fbd0fcb53d5830

Update documentation

view details

push time in 7 days

push eventrust-embedded/showcase

Travis CI User

commit sha abf3dce6b50be5fdfe3fa01d77a04d17681ec8a0

Update documentation

view details

push time in 7 days

push eventrust-embedded/book

Travis CI User

commit sha a3366d2c0f48d9d74b894670e4297d14a4d79c82

Update documentation

view details

push time in 8 days

push eventrust-embedded/discovery

Travis CI User

commit sha 4e5eb7f30c6109684e56c625b28b3d11b3ead0cb

Update documentation

view details

push time in 8 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 66e319ab1ec85e08f7d3ed3b20d34d9b1083fe6c

Update documentation

view details

push time in 8 days

push eventrust-embedded/showcase

Travis CI User

commit sha fbef0e1762ea0c8f9c3594cfc6506ce54ef314cf

Update documentation

view details

push time in 8 days

push eventrust-embedded/book

Travis CI User

commit sha b10631a977b8b41591a63a7930bb091b8a19970a

Update documentation

view details

push time in 8 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 0c708d3ffc9f5402c4fe89307bb959a9db27dd39

Update documentation

view details

push time in 8 days

push eventrust-embedded/discovery

Travis CI User

commit sha dd44bb05328b98ccf47775caa490ced448939e22

Update documentation

view details

push time in 9 days

push eventrust-embedded/book

Travis CI User

commit sha 55ce7f13e4400bd145ebac0d84c3d5d15788d33c

Update documentation

view details

push time in 9 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 18610e3f111f8fd8b94aaeaf6a3376ba230bdddc

Update documentation

view details

push time in 9 days

push eventrust-embedded/discovery

Travis CI User

commit sha 1eb1c8635d3bb61efc5090fd9848c6a1bc4d4879

Update documentation

view details

push time in 10 days

push eventrust-embedded/showcase

Travis CI User

commit sha e2e6969ea6030ed562e64b92b6be397795676313

Update documentation

view details

push time in 10 days

push eventrust-embedded/book

Travis CI User

commit sha 961d3ecc721f0420491328d42ccfc115f96aaefd

Update documentation

view details

push time in 10 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 760b3d2200825a9651aaca2016b5f2a3a003f0c2

Update documentation

view details

push time in 10 days

push eventrust-embedded/showcase

Travis CI User

commit sha 82b6d0420a074639d2011193429f0d12b82c4a3a

Update documentation

view details

push time in 11 days

push eventrust-embedded/book

Travis CI User

commit sha 12c4db63da03d7595c6f41deb69a3d07ac9401fd

Update documentation

view details

push time in 11 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 292d19ce52725092a2465678348528110eadbb8d

Update documentation

view details

push time in 11 days

push eventrust-embedded/discovery

Travis CI User

commit sha e105934bcdb80da308cdc5edd8dbdc640cb0a3c9

Update documentation

view details

push time in 11 days

issue commentrust-analyzer/rust-analyzer

Allow selecting targets instead of passing --all-targets

constantly complains it can't find crate for 'test'

You can work around this issue using the following .vscode/settings.json file (on the projects that need it):

{
    "rust-analyzer.checkOnSave.allTargets": false,
    "rust-analyzer.checkOnSave.extraArgs": [
        "--bins"
    ]
}

(that calls cargo check --bins on save, instead of cargo check --all-targets)

You can use other combinations like --bins --examples --lib to check src/lib.rs, src/main.rs, src/bin/*.rs and examples/*.rs.

Omit --lib if you don't have a src/lib.rs file.

Note that --bins will check both src/main.rs and src/bin/*.rs.

It would be nice if RA used the right cargo check invocation for no_std targets though.

darkwater

comment created time in 11 days

issue commentrtfm-rs/cortex-m-rtfm

naming the `#[idle]` function "main" produces a compiler error

Possibly. I would still like to see this fixed in the v0.5.x series, which use const APP, though.

japaric

comment created time in 11 days

issue commentrtfm-rs/cortex-m-rtfm

naming the `#[idle]` function "main" produces a compiler error

The reason one may want to name the #[idle] function "main" is better integration with VS Code + Rust-Analyzer. RA gives you this "Run" button (which is sugar for cargo run --example foo) when it says a function named "main".

2020-05-20-123040

japaric

comment created time in 11 days

issue openedrtfm-rs/cortex-m-rtfm

naming the `#[idle]` function "main" produces a compiler error

Steps to reproduce:

Modify the examples/idle.rs in this repository like this:

     }

     #[idle]
-    fn idle(_: idle::Context) -> ! {
+    fn main(_: main::Context) -> ! {
         static mut X: u32 = 0;

         // Safe access to local `static mut` variable

Now the example fails to build:

$ cargo b --example idle --target thumbv7m-none-eabi
error[E0061]: this function takes 0 arguments but 2 arguments were supplied
  --> examples/idle.rs:19:8
   |
11 | #[rtfm::app(device = lm3s6965)]
   | -------------------------------
   | |
   | supplied 2 arguments
   | defined here
...
19 |     fn main(_: main::Context) -> ! {
   |        ^^^^ expected 0 arguments

error: aborting due to previous error

The problem

If you look into the rtfm-expansion.rs file you'll see that the proc-macro produces a #[no_mangle] function called "main"; this name collides with the user provided one.

fn main(main::Locals { X, .. }: main::Locals, _: main::Context) -> ! {
    // user code
}

const APP: () = {
    use lm3s6965 as _;
    #[no_mangle]
    unsafe extern "C" fn main() -> ! {
        // ..
        main(
            main::Locals::new(),
            main::Context::new(&rtfm::export::Priority::new(0)),
        )
    }
};

The fix

Modify the main function inside const APP to have a random identifier (it won't be called by user code or proc-macro generated code) and use export_name instead of no_mangle. So, like this:

const APP: () = {
    use lm3s6965 as _;
    #[export_name = "main"]
    unsafe extern "C" fn __rtfm_0() -> ! {
        // ..
        main(
            main::Locals::new(),
            main::Context::new(&rtfm::export::Priority::new(0)),
        )
    }
};

Or change the inner main function call to use an absolute path: crate::main(/* args */). That may also work.

created time in 11 days

push eventrust-embedded/showcase

Travis CI User

commit sha 6cc81a2a93902f142f9243394afa00d381b74c6a

Update documentation

view details

push time in 12 days

issue commentrust-embedded/cortex-m-rt

HardFault == panic sets the correctness bar too high for panic handlers

not necessarily

sorry, incomplete sentence / idea. I mean to say that "fixing" 196 does not necessarily mean that PR 258 != UB for existing panic handlers. Hence, I think we should not make the default UB, even if end users can UB themselves, until 196 is addressed.

japaric

comment created time in 12 days

issue commentrust-embedded/cortex-m-rt

HardFault == panic sets the correctness bar too high for panic handlers

it's just something we'd want to remedy at the same time as rust-embedded/cortex-m#196 if possible, right?

not necessarily. If the solution to 196 is to make custom HardFault unsafe then PR #258 still makes panic-rtt and similar UB without the user setting any custom HardFault handler

the option of making interrupt::free unsafe I don't see as a viable solution for panic handlers because they can be called from any context including HardFault and NMI -- the implementer of the panic handler may have no way to know whether it's being called from such a context thus it can't enforce the safety requirement of interrupt::free

japaric

comment created time in 12 days

issue openednrf-rs/nrf-hal

`Pin`'s public fields let you break `Pin`'s singleton property

For example:

let p0 = p0::Parts(p.P0);
let a = p0.p0_00.degrade();
let mut b = p0.p0_01.degrade();
b.pin = 0;

Lets you create 2 P0.00 pins. I don't think this operation is UB per se but it does break the intended (singleton) semantics and can result in IO misconfiguration, e.g. configuring P0.00 both as serial Tx and Rx if you pass the a and b from above to the Uarte abstraction.

Setting the public pin field to value equal or greater than 32 may result in out of bounds array access though (either a panic or UB if the HAL is using unchecked bounds access).

I think making the fields private and instead providing getter methods for pin and port would be a better fit here.

created time in 12 days

issue openedrust-embedded/cortex-m-rt

HardFault == panic sets the correctness bar too high for panic handlers

as pointed out in rust-embedded/cortex-m#196 interrupt::free does not mask NMI or HardFault meaning that panic handlers that do this:

fn panic(_: &PanicInfo) -> ! {
   interrupt::free(|_| unsafe {
       // access static mut variables
    });
}

become unsound after #258. Those panic handlers assume no reentrancy but calling panic from HardFault or NMI can result in the panic handler being reentered which would be UB. This is likely going to make panic handlers that contain RAM buffers, like panic-rtt and panic-ram, unsound.

The same issue extends to DefaultHandler, I think, because the NMI will be serviced by DefaultHandler and, e.g. a Debug implementation could call nmipendset which is a safe operation (or at least, like pending any other interrupt, should be safe operation; I don't think we expose a safe API for it ATM though)

Basically, with this change only panic handlers that don't touch memory (e.g. panic-loop) or implement fully lock-free algorithms using atomics (I'm not aware of any) will remain sound.

cc @korken89

created time in 12 days

issue openedrust-embedded/cortex-m-rt

v0.6.13 release?

Did anything breaking land in master since the v0.6.12 release?

I would like to see a v0.6.x release that includes binary-level fixes like #265 (I guess cortex-m had more of that kind of fixes)

created time in 12 days

issue openedrust-embedded/cortex-m

v0.6.3 release?

Did anything breaking land in master since the v0.6.2 release?

I would like to see a v0.6.x release that includes binary-level fixes like #212 and #216

created time in 12 days

push eventrust-embedded/discovery

Travis CI User

commit sha 3683cfd2baeacb40be440bd4741b7beedb505699

Update documentation

view details

push time in 13 days

push eventrust-embedded/showcase

Travis CI User

commit sha bd4cf57e6deccc76b7ff3ee82ea3e73e421d6a3a

Update documentation

view details

push time in 13 days

push eventrust-embedded/book

Travis CI User

commit sha 8ac9f7d6f109b5c44958440e3ecbecd1876e344f

Update documentation

view details

push time in 13 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 8cff3d7fc20d2799d0b8082c55a17b9964b938a6

Update documentation

view details

push time in 13 days

create barnchjaparic/nrf-hal

branch : 143+144

created branch time in 13 days

pull request commentserde-rs/json

tweak f64 deserialization to make float roundtrips work

const NTHREADS: u32 = 8;
const STEP: u32 = u32::MAX / NTHREADS;

let mut threads = vec![];
for i in 0..(NTHREADS - 1) {
    threads.push(thread::spawn(move || {
        let mut json = vec![];

        let start = Instant::now();
        for j in i * STEP..(i + 1) * STEP {
            let input = f32::from_bits(j);
            if input.is_finite() {
                json.clear();
                serde_json::to_writer(&mut json, &input).unwrap();
                let output: f32 = serde_json::from_slice(&json).unwrap();
                assert_eq!(input, output);
            }
        }
        println!("({}) DONE in {:?}", i, start.elapsed());
    }));
}

let start = Instant::now();
let mut json = vec![];
for j in (NTHREADS - 1) * STEP..=u32::MAX {
    let input = f32::from_bits(j);
    if input.is_finite() {
        json.clear();
        serde_json::to_writer(&mut json, &input).unwrap();
        let output: f32 = serde_json::from_slice(&json).unwrap();
        assert_eq!(input, output);
    }
}
println!("({}) DONE in {:?}", NTHREADS - 1, start.elapsed());

threads.into_iter().for_each(|t| t.join().unwrap());

is what I tried. It doesn't do load balancing but all threads complete in about the same amount of time (270-300s) so maybe load balancing is not too important.

japaric

comment created time in 13 days

push eventrust-embedded/showcase

Travis CI User

commit sha 0784b12fe5719d9af20c1e3150c9e65e02226d7d

Update documentation

view details

push time in 14 days

push eventrust-embedded/discovery

Travis CI User

commit sha 7251ea1105c52c0bb05aca060b555bd4c7c073c7

Update documentation

view details

push time in 14 days

push eventrust-embedded/showcase

Travis CI User

commit sha 8e87e28c325402aa65f06aa9aa47a016a24d414e

Update documentation

view details

push time in 15 days

push eventrust-embedded/book

Travis CI User

commit sha 95a143d71fd23277a1678cde698d2bb0ba6ced2b

Update documentation

view details

push time in 15 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha a536dec6ff46b084a102dd3d904fe438785ef7ac

Update documentation

view details

push time in 15 days

push eventrust-embedded/discovery

Travis CI User

commit sha d7bfd9b1578e57e8c974088f21456234f2ff0d90

Update documentation

view details

push time in 16 days

push eventrust-embedded/showcase

Travis CI User

commit sha ff3b2ad69b6404cbaec1c8637fb7b9418c61c0b1

Update documentation

view details

push time in 16 days

issue commentprobe-rs/probe-rs

[0.6.2] nRF52840_xxAA: erase_sector fails with error code 1

probe-rs-cli info with the CMSIS-DAP probe (nRF52840 MDK)

japaric

comment created time in 16 days

issue openedprobe-rs/probe-rs

[0.6.2] nRF52840_xxAA: erase_sector fails with error code 1

Describe the bug

I get "erase_sector fails with error code 1" from both cargo-flash (tool) and probe_rs::flashing::download_file (library). I've tested with these combinations of probes: (CMSIS-DAP + nRF52840) and (J-Link + nRF52840).

To Reproduce

The ELF I'm using is basically what you get from compiling the snippet with opt-level = 'z':

#[cortex_m_rt::entry]
fn main() -> ! {
    loop { asm::nop() }
}
$ cargo flash --chip nrf52840
INFO probe_rs::flashing::download > Found 2 loadable sections:
INFO probe_rs::flashing::download >     .vector_table at 00000000 (1024 byte0)
INFO probe_rs::flashing::download >     .text at 00000400 (112 byte0)
INFO probe_rs::flashing::flasher  > Erasing sector at address 0x00000000
INFO probe_rs::flashing::flasher  > Done erasing sector. Result is 1. This took 20.939951ms
Error failed to flash app: The execution of 'erase_sector' failed with code 1
let probes = Probe::list_all();
let probe = probes[0].open()?;
let sess = probe.attach("nRF52840_xxAA")?;
let core = sess.attach_to_core(0)?;
flashing::download_file(&sess, path, Format::Elf)?;

Expected behavior

I expect both versions to be able to flash the device. OpenOCD is able to program the binary (tested both a nop loop and a blinky program):

$ openocd -f interface/cmsis-dap.cfg -f target/nrf52.cfg
(..)

$ telnet localhost 4444
> program path/to/elf
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0000104c msp: 0x20040000
** Programming Started **
nRF52840-xxAA(build code: C0) 1024kB Flash, 256kB RAM
Flash protection of this nRF device is not supported
Adding extra erase range, 0x00000470 .. 0x00000fff
** Programming Finished **

Stacktrace

See logs in the STR section (I can provide trace logs as well)

Desktop

  • Arch Linux x86_64
  • cargo-flash 0.6.0
  • probe_rs 0.6.2

Additional context

AFAIK the device has no way to set write protection for Flash (it can set write protection for the "User Configuration" section but that's at a different address: 0x1000_1000). Both cargo flash and probe_rs::flashing also fail after OpenOCD flashed a binary (I tested this in case OpenOCD did remove write protection).

Any other info I can provide to help debug this?

created time in 16 days

pull request commentserde-rs/json

tweak f64 deserialization to make float roundtrips work

ah, yes. You are right. Deserialization also allocates because Deserializer contains a Vec (that was there before this PR). I don't see a way to re-use a Deserializer to avoid that Vec being allocated and deallocated each time a value is deserialized though, at least not using the public API.

Using to_writer, testing the whole 32-bit range takes ~11 minutes in single-threaded mode, ~5 minutes with 8 threads (using just std::thread and no external dependencies) and ~6 minutes with 4 threads -- I guess more threads don't help in the program I wrote because there's no load balancing. I can commit either version and if the test is deemed to take too long it could be run on a daily basis using cron (rather than on each commit / PR).

japaric

comment created time in 16 days

push eventrust-embedded/showcase

Travis CI User

commit sha 9e1540e544a8d09eb4c251bd4f661611319b50ce

Update documentation

view details

push time in 17 days

push eventrust-embedded/book

Travis CI User

commit sha 9b079e9fb8350b6a7937f2bb2eff53a848a9fb2e

Update documentation

view details

push time in 17 days

push eventrust-embedded/debugonomicon

Travis CI User

commit sha 531b3c90030cd1b58c191c20b7288eda0876b25a

Update documentation

view details

push time in 17 days

pull request commentserde-rs/json

tweak f64 deserialization to make float roundtrips work

we should use that one if the requested output is the f32 type.

Done, f32 roundtrip is now working for all finite f32 values (and the program seems to terminate a bit faster?). This change will bring in the f32 monophormization of parse_float; that seems to increase the # of instructions reported by perf stat cargo build by ~0.13%.

japaric

comment created time in 17 days

push eventjaparic/json

Jorge Aparicio

commit sha 0d97e08568378ea5bb593c2ceb69598df6bcd073

if f32 was requested use 32-bit minimal-lexical instead of using the 64-bit version and then casting down to f32

view details

push time in 17 days

pull request commentserde-rs/json

tweak f64 deserialization to make float roundtrips work

errors: 1 with 0x95ae43fd errors: 2 with 0x15ae43fd

OK, I see the issue. when serializing we use the f32 variant of ryu to serialize f32 values and the f64 variant to deal with f64 inputs. when deserializing everything goes through the 64-bit variant of minimal-lexical and then output gets casted to an f32 if the user requested that; doing it like that results in an error of 1 ULP for 0x15ae43fd (0x95ae43fd is the negated value).

using the 32-bit variant of minimal-lexical (on the ryu-stringified value of 0x15ae43fd) does produce the correct value so we should use that one if the requested output is the f32 type

japaric

comment created time in 17 days

pull request commentserde-rs/json

tweak f64 deserialization to make float roundtrips work

WDYT about testing every f32? :-]

let start = Instant::now();
static N: AtomicU32 = AtomicU32::new(0);
(0..=u32::MAX).into_par_iter().for_each(|i| {
    let input = f32::from_bits(i) as f64;
    if input.is_finite() {
        let json = serde_json::to_string(&input).unwrap();
        let output: f64 = serde_json::from_str(&json).unwrap();
        if input != output {
            let x = N.fetch_add(1, Ordering::Relaxed);
            println!("errors: {} with {:#010x}", x + 1, i);
        }
    }
});
let end = Instant::now();

println!("errors: {}", N.load(Ordering::Relaxed));
println!("DONE in {:?}", end - start);
DONE in 380.674042494s

That works fine but takes 6-7 minutes so probably way too long to run on CI (which probably has less parallelism).

If I deserialize/serialize to f32 instead of f64 I get two errors though:

-        let input = f32::from_bits(i) as f64;
+        let input = f32::from_bits(i);
         if input.is_finite() {
             let json = serde_json::to_string(&input).unwrap();
-            let output: f64 = serde_json::from_str(&json).unwrap();
+            let output: f32 = serde_json::from_str(&json).unwrap();
errors: 1 with 0x95ae43fd
errors: 2 with 0x15ae43fd

Will look into the errors.

japaric

comment created time in 17 days

push eventrust-embedded/discovery

Travis CI User

commit sha 904eda363f54e73ea1edb3ce5b10b3cf8bd4b462

Update documentation

view details

push time in 18 days

push eventrust-embedded/showcase

Travis CI User

commit sha f3fb523c65834316dce6dc8a91eef281dfa32ea4

Update documentation

view details

push time in 18 days

push eventjaparic/json

Jorge Aparicio

commit sha e004665bab8880f36fb5e1e70b84cd2b19b1bac8

make clippy happy

view details

push time in 18 days

issue commentserde-rs/json

Perfect accuracy float parsing

I have opened a new PR (#671) that uses the latest version of minimal-lexical to fix this issue. The PR description has quite a few measurements but the summary is that I'm (only) seeing an increase in compile times of ~2-3% (# instructions as reported by perf) or ~0.3s in wall time (out of an initial ~15s) for builds from scratch of the serde-json crate.

dtolnay

comment created time in 18 days

more