!BHcierreUuwCMxVqOf:matrix.org

Rust Embedded

310 Members
Welcome to the Rust Embedded chat room! | Bridged to Freenode IRC: #rust-embedded | Public logs: https://freenode.logbot.info/rust-embedded/ | Discuss, coordinate, help: https://github.com/rust-embedded/wg | Code of conduct: https://www.rust-lang.org/conduct.html36 Servers

Load older messages


Timestamp Message
4 Apr 2020
17:08:14@jamesmunns:matrix.orgjamesmunnsYeah, it probably gives you everything <= 32
17:08:33@jamesmunns:matrix.orgjamesmunnshmmm
17:08:52@jamesmunns:matrix.orgjamesmunnsI wonder if that would be true for targets like AVR where they have 16 bit pointers, but are 8 bit devices.
17:08:59@jamesmunns:matrix.orgjamesmunnsCan they atomically read/write u16s?
17:10:28@jamesmunns:matrix.orgjamesmunns

hmm, msp430-none-elf doesn't seem to get the load/stores:

~ rustc --print cfg --target msp430-none-elf
debug_assertions
target_arch="msp430"
target_endian="little"
target_env=""
target_os="none"
target_pointer_width="16"
target_vendor=""
17:10:37@jamesmunns:matrix.orgjamesmunns *

hmm, msp430-none-elf doesn't seem to get the load/stores:

~ rustc --print cfg --target msp430-none-elf
debug_assertions
target_arch="msp430"
target_endian="little"
target_env=""
target_os="none"
target_pointer_width="16"

target_vendor=""

17:10:47@jamesmunns:matrix.orgjamesmunns *

hmm, msp430-none-elf doesn't seem to get the load/stores:

~ rustc --print cfg --target msp430-none-elf
debug_assertions
target_arch="msp430"
target_endian="little"
target_env=""
target_os="none"
target_pointer_width="16"
target_vendor=""
17:11:20@freenode_adamgreig:matrix.orgadamgreig i don't believe avr can read/write u16 atomically
17:11:52@alex:mailandmore.no-ip.orgalexfrom what I can remember they can not.
17:16:50@jamesmunns:matrix.orgjamesmunns

Ah, looks like you can actively inhibit it with giving it Some(0) as max atomic width, from the msp430 spec:

// There are no atomic CAS instructions available in the MSP430
// instruction set, and the LLVM backend doesn't currently support
// compiler fences so the Atomic* API is missing on this target.
// When the LLVM backend gains support for compile fences uncomment
// the `singlethread: true` line and set `max_atomic_width` to
// `Some(16)`.
max_atomic_width: Some(0),
17:18:13@jamesmunns:matrix.orgjamesmunns
/// This target has no support for threads.
pub singlethread: bool,

I wonder if this is true for any device with interrupts?

17:32:20@dngrs:matrix.orgdngrs (spookyvision@github)
In reply to @justacec:matrix.org
dngrs (spookyvision@github): Let me know where I can put the files. I included my helloSTM32 app along with the driver for the HX8357 driver and a small driver I cobbled together for the MMA8452Q accelerometer.
can you email it?
17:32:25@dngrs:matrix.orgdngrs (spookyvision@github)(also, thank you so much!)
17:38:44@dngrs:matrix.orgdngrs (spookyvision@github) FYI, switching to nightly fixed that! (context: variables disappearing as "optimized away" in debugger)
17:39:21@dngrs:matrix.orgdngrs (spookyvision@github)
In reply to @jschievink:matrix.org
then that's a rustc bug, if you can make a minimal reproduction that works on x86 feel free to open an issue, but I don't think debuginfo is very maintained at the moment
* FYI, switching to nightly fixed that! (context: variables disappearing as "optimized away" in debugger)
17:40:01@freenode_richardeoin:matrix.orgrichardeoin joined the room.
17:40:02@freenode_richardeoin:matrix.orgrichardeoin Hey dirk-dms - running code on the H7's Cortex-M4 core isn't so bad, but there's quite some way to getting rtfm-multicore running. I made a couple of PRs (like https://github.com/rtfm-rs/rtfm-syntax/pull/21) and then got bored
17:40:44@freenode_richardeoin:matrix.orgrichardeoinAnyhow, let me make a WIP PR on stm32-rs/stm32h7xx-hal showing what you need to run on the M4 only
17:48:03@freenode_richardeoin:matrix.orgrichardeoinhttps://github.com/stm32-rs/stm32h7xx-hal/pull/62
17:52:07@hargonix:matrix.orghargonix richardeoin: Could we do the replace process automatically by having a build.rs script that produces a memory.x file dynamically based on the config?
17:57:04@freenode_richardeoin:matrix.orgrichardeoinSure, if build.rs can do that
17:57:28@gulwath:matrix.orgdirk-dms For both cores presumably we'd need two linker scripts with some sections visible and at the same adr for data exchange via shared memory, right? Doesn't uAMP do this for you already?
18:01:05@freenode_richardeoin:matrix.orgrichardeoin Yes ideally we'd use all the infrastructure from microamp, and this is where the names 'core0.x' / 'core1.x' come from
18:02:12@freenode_richardeoin:matrix.orgrichardeoinPlease do try to get it working and post an example
18:03:50@freenode_richardeoin:matrix.orgrichardeoinMore examples generally would be good, especially some for dual core to add to the table here https://github.com/stm32-rs/stm32h7xx-hal#hardware
18:05:48@freenode_richardeoin:matrix.orgrichardeoinParticularly for the dual core, where you need to set the right bits in rcc.cr3 depending on your board
18:08:25@gulwath:matrix.orgdirk-dms I'll try, yesterday I was tumbelling down a rabbit hole to get the debugger working till I finally compiled openocd from source... Next step will be single core M4 and M7 and if that works uAMP with both, one step at a time. Ahh yes debugging both cores in sync is probably the fourth step then 😁
18:10:09@gulwath:matrix.orgdirk-dmsThanks for all the input, I will report on any progress I make.
18:12:24@freenode_richardeoin:matrix.orgrichardeoinGreat, yes getting a debug probe to work always involves plenty of yak-shaving and rabbit holes :)
18:55:13@antoinevg:matrix.organtoinevg joined the room.

There are no newer messages yet.


Back to Room List