ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<re_irc> <@dirbaio:matrix.org> the fix for vscode is to set ""rust-analyzer.check.allTargets": false," in ".vscode/settings.json"
<re_irc> <@dirbaio:matrix.org> so I guess there must be some equivalent for nvim?
<re_irc> <@dirbaio:matrix.org> there's some info here https://rust-analyzer.github.io/manual.html#configuration
<re_irc> <@dirbaio:matrix.org> and here https://rust-analyzer.github.io/manual.html#vimneovim
<re_irc> <@dirbaio:matrix.org> on how to set these settings in neovim\
<re_irc> <@dirbaio:matrix.org> : ^
<re_irc> <@rmja:matrix.org> : Setting this in Cargo.toml:
<re_irc> [[bin]]
<re_irc> name = "name of app"
<re_irc> test = false
<re_irc> bench = false
starblue has quit [Ping timeout: 268 seconds]
starblue has joined #rust-embedded
lehmrob has joined #rust-embedded
linuxsroxs has joined #rust-embedded
linuxsroxs has quit [Quit: Quit]
linuxsroxs has joined #rust-embedded
linuxsroxs has quit [Client Quit]
<re_irc> <@luojia65:matrix.org> Hello! Do we have "embedded_hal::serial::Read"-like traits in embedded-hal 1.0.0-alpha versions? :)
<re_irc> <@luojia65:matrix.org> Looks like we only have blocking write traits here:
lehmrob has quit [Ping timeout: 240 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
lehmrob has joined #rust-embedded
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
justanotherdude2 has joined #rust-embedded
justanotherdude2 has quit [Read error: Connection reset by peer]
justanotherdude2 has joined #rust-embedded
justanotherdude2 has quit [Ping timeout: 240 seconds]
lehmrob has quit [Ping timeout: 256 seconds]
lehmrob has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
lehmrob has quit [Remote host closed the connection]
<re_irc> <@urhengulas:matrix.org> Hi đź‘‹
<re_irc> Jonathan told me that you are looking into switching from bors to github merge queue as well. I am looking into this for knurling-rs.
<re_irc> To me it seems rather straight forward: Enabling the merge queue in the branch protection rules and adapting the github actions workflow to listen on merge_group events. See here: https://github.com/knurling-rs/defmt/pull/756
<re_irc> Did you find any additional necessary steps? Or do you have any concerns?
<re_irc> <@ryan-summers:matrix.org> It kinda depends on what you're doing. I just did this swapover for running HITL via bors, and discovered that you can actually mark checks as "skip" for the PR process and only run them if the "merge_group" is the trigger, which is useful for jobs you only want to run from the queue
<re_irc> <@ryan-summers:matrix.org> And then you obviously have to set up the merge queue settings in the repo settings as well
<re_irc> <@romancardenas:matrix.org> Also there is an issue with skipped jobs: https://github.com/rust-embedded/wg/issues/671#issuecomment-1537500488
<re_irc> <@romancardenas:matrix.org> bors considers a skipped job as "failed", whereas ghmq seems fine with that
<re_irc> <@urhengulas:matrix.org> : That's interesting. Do you have an example of a step you only want to run for merge_group events?
<re_irc> <@romancardenas:matrix.org> So you need to add the steps outlined by in the link below to avoid this behavior
<re_irc> <@ryan-summers:matrix.org> https://github.com/quartiq/stabilizer/blob/main/.github/workflows/ci.yml#L127 - we only want to trigger our hardware-in-the-loop CI on the merge_queue event
<re_irc> <@ryan-summers:matrix.org> Because we'd overburden the hardware test machine if we ran on every commit
<re_irc> <@ryan-summers:matrix.org> This also ensures that the private runner cannot have jobs triggered on it by users who are unauthorized, which a normal check would do
<re_irc> <@romancardenas:matrix.org> * above
<re_irc> and it's a workaround for this issue: https://github.com/smoltcp-rs/smoltcp/pull/540
<re_irc> <@rin_shima:cryptty.tk> Hello! I worked on my code from last time and this time it could built perfectly:
<re_irc> ```
<re_irc> use hal::Twim;
<re_irc> #![no_main]
<re_irc> use core::*;
<re_irc> #![no_std]
<re_irc> use nrf52832_hal as hal;
<re_irc> use rtt_target::{rprintln, rtt_init_print};
<re_irc> use vl53l0x::VL53L0x;
<re_irc> #[panic_handler] // panicking behavior
<re_irc> fn panic(_: &core::panic::PanicInfo) -> ! {
<re_irc> loop {
<re_irc> cortex_m::asm::bkpt();
<re_irc> }
<re_irc> }
<re_irc> #[cortex_m_rt::entry]
<re_irc> fn main() -> ! {
<re_irc> rtt_init_print!();
<re_irc> let p = hal::pac::Peripherals::take().unwrap();
<re_irc> let port0 = hal::gpio::p0::Parts::new(p.P0);
<re_irc> let scl = port0.p0_03.into_floating_input().degrade();
<re_irc> let sda = port0.p0_04.into_floating_input().degrade();
<re_irc> let handler: Twim<hal::pac::TWIM0> = hal::Twim::new(
<re_irc> p.TWIM0,
<re_irc> hal::twim::Pins { scl, sda },
<re_irc> hal::pac::twim0::frequency::FREQUENCY_A::K400,
<re_irc> );
<re_irc> let mut sensor = VL53L0x::with_address(handler, 0x53).unwrap();
<re_irc> VL53L0x::start_continuous(&mut sensor, 3000).unwrap();
<re_irc> rprintln!("{}", VL53L0x::who_am_i(&mut sensor).unwrap());
<re_irc> loop {
<re_irc> rprintln!(
<re_irc> "{}",
<re_irc> VL53L0x::read_range_continuous_millimeters_blocking(&mut sensor).unwrap()
<re_irc> );
<re_irc> }
<re_irc> }
<re_irc> ```
<re_irc> There's no output however on the RTT console. I'm not sure whether or not that VL53L0X sensor is working properly, or that it has already been fried due to my previous failed attempts. Any thoughts?
<re_irc> <@rin_shima:cryptty.tk> wiring btw
<re_irc> <@rin_shima:cryptty.tk> Hello! I worked on my code from last time and this time it could built perfectly:
<re_irc> ```
<re_irc> #![no_main]
<re_irc> use hal::Twim;
<re_irc> #![no_std]
<re_irc> use core::*;
<re_irc> use nrf52832_hal as hal;
<re_irc> use rtt_target::{rprintln, rtt_init_print};
<re_irc> use vl53l0x::VL53L0x;
<re_irc> #[panic_handler] // panicking behavior
<re_irc> fn panic(_: &core::panic::PanicInfo) -> ! {
<re_irc> loop {
<re_irc> cortex_m::asm::bkpt();
<re_irc> }
<re_irc> }
<re_irc> #[cortex_m_rt::entry]
<re_irc> fn main() -> ! {
<re_irc> rtt_init_print!();
<re_irc> let p = hal::pac::Peripherals::take().unwrap();
<re_irc> let port0 = hal::gpio::p0::Parts::new(p.P0);
<re_irc> let scl = port0.p0_03.into_floating_input().degrade();
<re_irc> let sda = port0.p0_04.into_floating_input().degrade();
<re_irc> let handler: Twim<hal::pac::TWIM0> = hal::Twim::new(
<re_irc> p.TWIM0,
<re_irc> hal::twim::Pins { scl, sda },
<re_irc> hal::pac::twim0::frequency::FREQUENCY_A::K400,
<re_irc> );
<re_irc> let mut sensor = VL53L0x::with_address(handler, 0x53).unwrap();
<re_irc> VL53L0x::start_continuous(&mut sensor, 3000).unwrap();
<re_irc> rprintln!("{}", VL53L0x::who_am_i(&mut sensor).unwrap());
<re_irc> loop {
<re_irc> rprintln!(
<re_irc> "{}",
<re_irc> VL53L0x::read_range_continuous_millimeters_blocking(&mut sensor).unwrap()
<re_irc> );
<re_irc> }
<re_irc> }
<re_irc> ```
<re_irc> There's no output however on the RTT console. I'm not sure whether or not that VL53L0X sensor is working properly, or that it has already been fried due to my previous failed attempts. Any thoughts?
<re_irc> <@rin_shima:cryptty.tk> Hello! I worked on my code from last time and this time it could built perfectly:
<re_irc> ```
<re_irc> #![no_std]
<re_irc> #![no_main]
<re_irc> use core::*;
<re_irc> use hal::Twim;
<re_irc> use nrf52832_hal as hal;
<re_irc> use rtt_target::{rprintln, rtt_init_print};
<re_irc> use vl53l0x::VL53L0x;
<re_irc> #[panic_handler] // panicking behavior
<re_irc> fn panic(_: &core::panic::PanicInfo) -> ! {
<re_irc> loop {
<re_irc> cortex_m::asm::bkpt();
<re_irc> }
<re_irc> }
<re_irc> #[cortex_m_rt::entry]
<re_irc> fn main() -> ! {
<re_irc> rtt_init_print!();
<re_irc> let p = hal::pac::Peripherals::take().unwrap();
<re_irc> let port0 = hal::gpio::p0::Parts::new(p.P0);
<re_irc> let scl = port0.p0_03.into_floating_input().degrade();
<re_irc> let sda = port0.p0_04.into_floating_input().degrade();
<re_irc> let handler: Twim<hal::pac::TWIM0> = hal::Twim::new(
<re_irc> p.TWIM0,
<re_irc> hal::twim::Pins { scl, sda },
<re_irc> hal::pac::twim0::frequency::FREQUENCY_A::K400,
<re_irc> );
<re_irc> let mut sensor = VL53L0x::with_address(handler, 0x53).unwrap();
<re_irc> VL53L0x::start_continuous(&mut sensor, 3000).unwrap();
<re_irc> rprintln!("{}", VL53L0x::who_am_i(&mut sensor).unwrap());
<re_irc> loop {
<re_irc> rprintln!(
<re_irc> "{}",
<re_irc> VL53L0x::read_range_continuous_millimeters_blocking(&mut sensor).unwrap()
<re_irc> );
<re_irc> }
<re_irc> }
<re_irc> ```
<re_irc> There's no output however on the RTT console. I'm not sure whether or not that VL53L0X sensor is working properly, or that it has already been fried due to my previous failed attempts. Any thoughts?
<re_irc> <@juliand:fehler-in-der-matrix.de> You could try writing some sort of output to an LED or put a print statement before all the sensor stuff. Then you can at least check whether or not the RTT and the sensor alone work.
<re_irc> <@joelsa:fehler-in-der-matrix.de> You don’t seem to have pull-ups in place, does that breakout board has them integrated?
<re_irc> <@juliand:fehler-in-der-matrix.de> : The code says "into floating input"...
<re_irc> <@joelsa:fehler-in-der-matrix.de> These ST ToF Sensors Need notoriously strong pull-ups, the Datasheet specifies 1.5k to 2k IIRC, though I normally use 4.7k on them
<re_irc> <@rin_shima:cryptty.tk> : You mean that I shouldn't leave the pins floating? please elaborate
<re_irc> <@joelsa:fehler-in-der-matrix.de> I2C is Open-Drain so you need Pull-Up resistors to 3V3
<re_irc> <@rin_shima:cryptty.tk> : hmm but I don't think it's an issue for I'm using a development board...
<re_irc> <@juliand:fehler-in-der-matrix.de> Why should this not be a problem then?
<re_irc> <@joelsa:fehler-in-der-matrix.de> It seems to have a level shifter circuit that also includes 10k Pull-Ups
<re_irc> <@ryan-summers:matrix.org> But I2C likely still shouldn't be input pins
<re_irc> <@rin_shima:cryptty.tk> : I'm using a prebuilt sensor module with pins already soldered and I think just wire them to the board accordingly will do the job...
<re_irc> <@therealprof:matrix.org> : Generic development boards don't include the strong pull-ups by default usually. Some MCUs include software controlled pull-ups which are quite weak usually, though.
<re_irc> <@ryan-summers:matrix.org> I2C are open-drain outputs generally. You won't be able to act as the I2C master with input pins, would you?
<re_irc> <@ryan-summers:matrix.org> I.e. you could not generate clock cycles etc.
<re_irc> <@juliand:fehler-in-der-matrix.de> I was wondering that, as well. Depends on the magic dev board, I guess :D
<re_irc> <@ryan-summers:matrix.org> I don't think that's something the dev board can ever solve
<re_irc> <@ryan-summers:matrix.org> : Are you intentionally specifying SCL and SDA as inputs? This is not typical
<re_irc> <@rin_shima:cryptty.tk> : ... what do you mean...?
<re_irc> <@joelsa:fehler-in-der-matrix.de> These 10k resistors probably work in about 90% of the cases, depending on bus capacitance. If I am Troubleshooting, I don’t want to bet on my setup not belonging to the 10%, though you Setup doesn’t look like it’s high-capacitance, better to add a 2k Pull-Up and be safe than sorry.
<re_irc> <@ryan-summers:matrix.org> You specify them as "into_floating_input()" which configures the GPIOs as input pins. Generally, you need to configure I2C pins as output pins or alternate function pins
<re_irc> <@ryan-summers:matrix.org> But the nRF reference manual will tell you what you're supposed to do.
<re_irc> <@rin_shima:cryptty.tk> Oh... lemme check
<re_irc> <@ryan-summers:matrix.org> nRFs also use something called a pin mux to route the I2C to the IO pins. It should tell you how you're supposed to configure the pins first somewhere
<re_irc> <@rin_shima:cryptty.tk> : But according to the "TWIM" section in the nrf52832 specification, these two i2c pins are both listed at 'input'...
<re_irc> <@rin_shima:cryptty.tk> * as
<re_irc> <@juliand:fehler-in-der-matrix.de> And what is the config after enabling the peripheral?
<re_irc> <@rin_shima:cryptty.tk> : config...? It seems that only the open drain output mode requires config...
<re_irc> <@juliand:fehler-in-der-matrix.de> The table description says that this is the configuration before enabling the peripheral. According to the 3rd paragraph this is when the system is OFF and shall not influence other devices on the bus.
<re_irc> <@juliand:fehler-in-der-matrix.de> But I presume you want to turn the system ON and use it...
<re_irc> <@rin_shima:cryptty.tk> oh...
<re_irc> <@rin_shima:cryptty.tk> So, what should I do to properly initialize the I2C bus and access the peripheral on the specified pin? It appears to be a bit convoluted for me currently...
<re_irc> <@juliand:fehler-in-der-matrix.de> I dont have the hardware to test, sorry. Maybe the example from the nrf repo is of help: https://github.com/nrf-rs/nrf-hal/blob/master/examples/twim-demo/src/main.rs
<re_irc> <@rin_shima:cryptty.tk> : hmm, this example uses a lot of syntaxes that I can't fathom... like the "context" thing, can't find this usage elsewhere
<re_irc> But thanks nevertheless
<re_irc> <@juliand:fehler-in-der-matrix.de> The context stuff is specific to the used framework. But lines 46ff and 61 should be the same for you, as well.
<re_irc> <@rin_shima:cryptty.tk> : btw from the pcb image provided in this link, it seems that there is already a pull up resistor built-in in the module... I don't understand now
<re_irc> <@rin_shima:cryptty.tk> btw are there ways for me to manually debug/spectate output from i2c connections? If so, how?
<re_irc> <@rin_shima:cryptty.tk> * connections, through serial or other means?
<re_irc> <@joelsa:fehler-in-der-matrix.de> You can get one of these cheap Logic Analyzers for 10$
<re_irc> <@rin_shima:cryptty.tk> : "logic analyzers"?
<re_irc> <@joelsa:fehler-in-der-matrix.de> Yes
WSalmon has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
WSalmon has joined #rust-embedded
<re_irc> <@henrik_alser:matrix.org> : ctx is just an rtic things, so not related to the hal. ctx.device is just how you access the Periherals struct
<re_irc> <@henrik_alser:matrix.org> * thing,
WSalmon has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
WSalmon has joined #rust-embedded
<re_irc> <@henrik_alser:matrix.org> Btw, if you’re new to embedded Rust i’d very much recommend you to build your apps on top of rtic or embassy from the get go to not be confused by all the boilerplate of a ”bare bones” app. For anything more involved than a blinky you’ll run into the same problems as these frameworks solve in a super nice way
<re_irc> <@henrik_alser:matrix.org> Then if you’re interested in How it works under the hood it’ll be easier to grasp one layer at a time
<re_irc> <@henrik_alser:matrix.org> (Starting from the bottom up is way more confusing ime, introducing a lot of students to embedded Rust)
<re_irc> <@henrik_alser:matrix.org> * Rust every year)
<re_irc> <@henrik_alser:matrix.org> (Performance-wise you’ll be very hard pressed to make something as performant and reliable as these frameworks offer you on your own)
<re_irc> <@henrik_alser:matrix.org> Just a side note :)
<re_irc> <@henrik_alser:matrix.org> If you have questions about that demo, just ask, i believe i’m the one to blame from a couple years back :D
<re_irc> <@d3zd3z:matrix.org> Any pointers to getting probe-run/probe-rs-cli working with the nRF5340. I get an error "An operation could not be performed because it lacked the permission to do so: erase_all". I did an "nrfjprog --recover", and using "nrfjprog --program ..." does seem to work.
<re_irc> <@d3zd3z:matrix.org> It seems if I add "--verify" to the "nrfjprog" command, it comes back that the flash verification fails, so it might not actually be working with that tool either.
dc740 has joined #rust-embedded
<re_irc> <@d3zd3z:matrix.org> So I got nrfjprog working, I just need to pass "--coprocessor CP_APPLICATION" as well, and it flashes and verifies. "probe-rs" (and "probe-run") still come up giving the permission error on erase.
<re_irc> <@d3zd3z:matrix.org> So, I think the failures weren't related to each other.
<re_irc> <@d3zd3z:matrix.org> There is an example for this board in Embassy, so I suspect this board has worked at some point.
<re_irc> <@dirbaio:matrix.org> use "probe-rs-cli run --allow-erase-all"
<re_irc> <@dirbaio:matrix.org> the reason it wants to erase every time is the debug port gets locked if the flashed firmware doesn't explicitly unlock it
<re_irc> <@dirbaio:matrix.org> "embassy_nrf::init()" unlocks debug by default (it's this (https://docs.embassy.dev/embassy-nrf/git/nrf5340-app-s/config/struct.Config.html#structfield.debug)) setting
<re_irc> <@dirbaio:matrix.org> so once you've flashed some valid firmware it should never lock itself again
<re_irc> <@d3zd3z:matrix.org> This does seem to be working.
<re_irc> <@rin_shima:cryptty.tk> : Thanks! I'll check it out next time :)
dc740 has quit [Remote host closed the connection]
IlPalazzo-ojiisa has quit [Remote host closed the connection]