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
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
blueluna[m] has quit [Quit: Idle timeout reached: 172800s]
<firefrommoonligh> So, if you are looking for a way to share Mutex-locked resources across interrupts, either is fine?
<firefrommoonligh> (They both seem to work on my end)
Averyshethey[m] has joined #rust-embedded
<Averyshethey[m]> I'm trying to generate an rtic project, rtic is complaining about the function signature that the template generated, is there an up to date example of what an rtic file should look like?
<adamgreig[m]> if you're using critical_section::Mutex, you'll eventually need to use critical_section::with to get the cs token, and you may as well swap now
IlPalazzo-ojiisa has quit [Quit: Leaving.]
bpye has quit [Quit: The Lounge - https://thelounge.chat]
bpye has joined #rust-embedded
bpye has quit [Ping timeout: 240 seconds]
bpye has joined #rust-embedded
yourarj[m] has joined #rust-embedded
<yourarj[m]> How should I initialize the huge array with Non copy type.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/IgZjgaBKbtqpcoufFbnHWeau>)
<JamesMunns[m]> If you can make a single const item, you can use that
<yourarj[m]> JamesMunns[m]: Any example please?
<yourarj[m]> <JamesMunns[m]> "like:..." <- > <@jamesmunns:beeper.com> like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/KyOdaCmwkQSGJiVoICYSdqku>)
<JamesMunns[m]> I'm not sure what you mean by "no overhead". If you can define it const, then yes, the compiler could create it at compile time
<JamesMunns[m]> if you know the size ahead of time, you can even make the array const.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/BQiJsmvfTgfDpETDACNtNBtq>)
<yourarj[m]> James Munns: will it equivalent to creating a macro which will repeat the value?
<JamesMunns[m]> this will, at runtime, likely just be a memcpy from flash/.text to RAM
<JamesMunns[m]> yourarj[m]: yes
<yourarj[m]> When I say overhead I'm referring to impact on bin size between two approaches creating array of copy type with obvious way
<yourarj[m]> And array of non copy type with const approach?
<JamesMunns[m]> honestly, I'm not sure! I would guess the compiler will optimize them the same way. But you would have to benchmark your specific program to see if it makes any change.
<yourarj[m]> Great! THANKS James Munns: appreciate your help. 😃
<JamesMunns[m]> yourarj[m]: > <@yourarj:matrix.org> When I say overhead I'm referring to impact on bin size between two approaches creating array of copy type with obvious way... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/dQSeLRVHFmFKJeospVgDWZUZ>)
<yourarj[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> btw, this was very helpful! Whenever you are asking about "overhead" or "performance", it's very useful to share *in which resource* you mean! There might be different ways that:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/auOiaKPVtGaXKqPdjjaCyaIE>)
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
khionu[m] has joined #rust-embedded
<khionu[m]> Hi, I'm working with a [B-L4S5I-IOT01A](https://www.st.com/resource/en/user_manual/um2708-discovery-kit-for-iot-node-multichannel-communication-with-stm32l4-series-stmicroelectronics.pdf) and its [ST25DV04K NFC chip](https://www.st.com/resource/en/datasheet/st25dv04k.pdf), and my current goal is to detect when I'm [in between smartphone detection and reading of
<khionu[m]> NDEF](https://www.st.com/resource/en/application_note/an5439-augmented-ndef-with-st25dvi2c-series-dynamic-nfc-tags-stmicroelectronics.pdf) over I2C. So far, I'm not sure how to identify that. My only clue so far is that I can poll to see when RF is in use, but idk if I could use that method to determine when the smartphone has detected my tag.
<JamesMunns[m]> So, looking at the schematic, the "GPO" pin from the NFC chip is wired up to pin PE4
<JamesMunns[m]> GPO is:
<JamesMunns[m]> > Interruption pin configurable on multiple RF events (field change, memory write, activity, Fast Transfer end, user set/reset/pulse)
<JamesMunns[m]> so, it seems like (somehow?) you can configure the st25dv04k to set a GPIO low (I think?) when something interesting happens
<JamesMunns[m]> so you can do something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/mbtUOGGffPXWOdGnBfqfDjJI>)
* khionu[m] starts itching to import an FSM crate
<JamesMunns[m]> async functions are already finite and hierarchical state machines
<JamesMunns[m]> but you do you :D
<khionu[m]> You're not wrong! But making sure they're clear and correct is a whole other deal
<JamesMunns[m]> Just letting you know how I got there: you linked this datasheet:
<JamesMunns[m]> err, you linked that PDF, the first link IN that PDF is what I linked
<JamesMunns[m]> if you go to the "CAD Resources" page, that's where STM puts their schematics for dev boards
<JamesMunns[m]> I looked for the NFC chip in the block diagram:
<JamesMunns[m]> it showed there were I2C pins and three extras:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/wePgeHUVZkFeEkfQqsRxppoy>)
<JamesMunns[m]> interrupt pins actually work exactly like wakers in async: they tell you something happened, but not what happened, but they are useful for telling you when it is time to check what is going on.
<JamesMunns[m]> Section 5.2 of the ST24DV04K datasheet explains all the different ways you can use GPO.
<khionu[m]> Wonderful! Thank you very much!
<khionu[m]> <JamesMunns[m]> "so, it seems like (somehow?) you..." <- Section 5.2 on the NFC datasheet PDF, btw
<khionu[m]> Also Section 4.4
<JamesMunns[m]> <JamesMunns[m]> "Section 5.2 of the ST24DV04K..." <- yep :)
MathiasKoch[m] has joined #rust-embedded
<MathiasKoch[m]> I could use some help here;... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/JeGDYWevjHRxnSRubMvTbTdQ>)
<JamesMunns[m]> I dunno off the top of my head, but:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/eaXfgyhgdirPrtgMcGFiXdso>)
<MathiasKoch[m]> Uhh... Have not seen that one, no..
<MathiasKoch[m]> Yeah, found it. thanks
<MathiasKoch[m]> What is the definition of abreak transfer is requested before the end of D1 transfer
<MathiasKoch[m]> ?
<JamesMunns[m]> uh, maybe "the code commands a 'line break' before the end of D1 transfer"
<JamesMunns[m]> Not sure what "D1" is, probably mentioned in the RM for that chip?
<JamesMunns[m]> > After the end of transmission of a data (D1)
<JamesMunns[m]> Ah
<MathiasKoch[m]> yeah, just a data byte i think
<JamesMunns[m]> so, while you're sending data, but before you are done, you request a line break
<JamesMunns[m]> but probably not that if you are blocking
<JamesMunns[m]> it's probably:
<JamesMunns[m]> > nCTS is de-asserted before the end of transfer of D1.
<JamesMunns[m]> so like, you are sending a byte, and the other side raises the nCTS pin before the end of the byte
<JamesMunns[m]> or does it require all of those? I dunno. Are you sending line breaks?
<MathiasKoch[m]> It's AT commands, so most likely :p
<JamesMunns[m]> ah, so do you do something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/xcvFmwIfuzBcPkiouUgmdbGh>)
<JamesMunns[m]> if so, it sounds like you need to do:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/UvQIviJVIUUURnqvnBEaOsen>)
juliand[m] has joined #rust-embedded
<juliand[m]> <JamesMunns[m]> "Screenshot 2024-01-29 at 08.20.4..." <- "After the end of transmission... Will not be set... (If) D1 is being transmitted"
<juliand[m]> What's that supposed to mean? Has the transmission ended and a new transmission started?
<MathiasKoch[m]> Well, the line breaks a serialized as part of my data :/
<JamesMunns[m]> juliand[m]: > <@juliand:fehler-in-der-matrix.de> "After the end of transmission... Will not be set... (If) D1 is being transmitted"
<JamesMunns[m]> > What's that supposed to mean? Has the transmission ended and a new transmission started?
<JamesMunns[m]> I assume "all data is sent", but "not all data has hit the wire", e.g. there's still data in the output shift register/fifo
<JamesMunns[m]> MathiasKoch[m]: it seems the workaround is "don't do that" :p
<MathiasKoch[m]> Haha xD Awesome.. Gotta love STM
<JamesMunns[m]> yeah, it's really really important to review the errata for any parts on any chip you use
<JamesMunns[m]> ideally before you pick them, before you write code, and before you ship
<MathiasKoch[m]> gotcha
<JamesMunns[m]> sometimes you find errata the invalidate the whole purpose of choosing a part, like "oh yeah you can't use low power mode with that peripheral sorry"
<JamesMunns[m]> idk if stm32 is particularly bad, but every chip maker has them, if they don't have errata docs it just means YOU get to prove there are hardware bugs
<juliand[m]> JamesMunns[m]: I feel like STM is especially bad at fixing them in new revisions. Like the STM32H743ZI vs ZI2 still has mostly the same annoying hardware bugs...
<JamesMunns[m]> Do AT commands use line breaks? Not newlines, a line break is when you hold the serial line low for like 9-20 bit times
<JamesMunns[m]> which is an illegal bit pattern (e.g. overrunning start/stop bits)
<MathiasKoch[m]> Hmm.. They just use new lines..
<JamesMunns[m]> yeah, a "line break" and a "break request" is a specific thing
<Darius> AT commands don't use breaks AFAIK
<JamesMunns[m]> Darius: yeah, that's what I thought, I thought it was all ASCII in-band signalling
<Darius> yes
<Darius> well there was the (patented) delay after +++
<MathiasKoch[m]> But, then i don't think we have anything using break requests?
<MathiasKoch[m]> Zero mentions of `sbkrq` throughout the HAL.
<JamesMunns[m]> Then... the chase continues! It's unclear whether the errata means ALL FOUR conditions are true, but it sorta reads like that?
<Darius> UART breaks are pretty old school, not really surprise it hasn't been implemented IMO
<MathiasKoch[m]> Hmm.. Darn! Would have been so happy if it was just to implement an errata fix :/... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/yVFVbFDezgsVMuQGZMEQFsDi>)
<MathiasKoch[m]> The with_timeout solution is what we have implemented in our newer async version, but we still need to fix the blocking legacy stuff here
<JamesMunns[m]> Other wild guess, can you ever flush after sending no data? like, is it possible you're trying to flush after sending no data, and that just never sets the "done" flag high because nothing ever happened?
<JamesMunns[m]> like, doing something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/nnQxNDhPansIYvrqkWZNpAAB>)
<MathiasKoch[m]> Uhmm.. Thats a nice catch! Will absolutely make sure that is out of the way :p
<JamesMunns[m]> probably more like, you are sending in chunks, and the last chunk is zero?
<JamesMunns[m]> not sure if that actually confuses the hardware, but I've seen errors like that before where sending zero bytes makes things act weird
<MathiasKoch[m]> Yeah.. Don't think we have a check for that currently, so it could be! Will add a check
<JamesMunns[m]> it might be worth checking the TXE bit or something to see if anything is actually active before you spin potentially forever
<JamesMunns[m]> or just do it on purpose and see if you can make the bug repro immediately :D
<JamesMunns[m]> IMO it does seem the flush logic needs to be a little smarter, it looks like TC doesn't go high until some data is sent
<JamesMunns[m]> so like if you start up or something, and do a flush before ever sending data, it does look like TC might never go high
<MathiasKoch[m]> The empty write is a super valid point, that we absolutely should add a check for in our code, but I am not so sure that is what happens.
<MathiasKoch[m]> We tried to print what we are transmitting, and the last transmit before we get stuck in flush (`tc`) does indeed contain data :(
<JamesMunns[m]> Any chance you have a logic analyzer attached and can see what the CTS line looks like?
<MathiasKoch[m]> That is on my agenda next
Socke has quit [Ping timeout: 260 seconds]
<MathiasKoch[m]> James Munns:
<MathiasKoch[m]> Minor progess.. :p
<MathiasKoch[m]> Good case (flush works, and `tc` is correctly set:)
<MathiasKoch[m]> * James Munns:
<MathiasKoch[m]> Minor progess.. :p
<MathiasKoch[m]> Good case (flush works, and `tc` is correctly set) ^
<MathiasKoch[m]> Bad case (flush hangs, tc is never set)
<MathiasKoch[m]> MathiasKoch[m]: Bad case!
<MathiasKoch[m]> MathiasKoch[m]: Good case!
<MathiasKoch[m]> Could be, if I interpret the errata correctly, that the break (0xFF) we receive on TXD (as seen from the modem towards MCU), while still clocking data out on RXD, breaks the TC stuff
Socke has joined #rust-embedded
lehmrob has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]> Dunno! Might be worth looking at if there are any encoding errors (logic seems real unhappy), and what the timing of the start/stop message vs the CTS pulses looks like, and if there's any difference
johannes[m] has joined #rust-embedded
<johannes[m]> Is there an easy way to replicate what arm-none-eabi-objcopy -O binary does but using Rust code? I've been playing around with https://crates.io/crates/elf but it does not seem to be able to do this easily.
<johannes[m]> * Is there an easy way to replicate what arm-none-eabi-objcopy -O binary in.elf out.bin does but using Rust code? I've been playing around with https://crates.io/crates/elf but it does not seem to be able to do this easily.
<JamesMunns[m]> If it doesn't have to be Rust, you can use llvm's binutils with cargo-binutils to make it cargo objcopy --release -- -O binary out.bin
<JamesMunns[m]> otherwise, you can look at what probe-rs/probe-rs-cli does, they extract the flashable segments from an elf as well.
<johannes[m]> JamesMunns[m]: ah great, thanks
lehmrob has quit [Ping timeout: 256 seconds]
kenny has quit [Quit: WeeChat 4.2.0]
lehmrob has joined #rust-embedded
lehmrob has quit [Remote host closed the connection]
corecode has joined #rust-embedded
kenny has joined #rust-embedded
<Ecco> I have an embassy question: in the sample STM32 code, there are some examples of "bind_interrupts!". Is it different from using "#[interrupt]" before the handler's declaration (kind of like #[exception])?
mameluc[m] has joined #rust-embedded
<mameluc[m]> <Ecco> "I have an embassy question: in..." <- yes, bind_interrupts lets embassy handle the interrupts, #[interrupt] you do it yourself. You can do #[interrupts] without embassy but not bind_interrupts
<mameluc[m]> strictly speaking #[interrupt] comes from cortex-m-rt
<Ecco> yes indeed
<Ecco> By the way, I found a bug in embassy-stm32
<Ecco> (I'm still investigating)
<Ecco> Yeah, ok, I believe it's a bug in embassy-stm32
<Ecco> The vector for the EXTI13 is *not* sequential
<Ecco> (that's STM32WBA, but I looked at STM32H503 and apparently it's identical)
<Ecco> So the vector table is *entierly wrong* for every interrupt after EXTI13
<Ecco> (I'm surprised nobody caught it already)
<Ecco> This is incorrect
<dngrs[m]> oh STM
<Ecco> :)
<Ecco> It's not just that one chip tho
<Ecco> seems to affect every M33
<Ecco> It's weird that nobody caught that
<GrantM11235[m]> <JamesMunns[m]> "if you can name those fun tricks..." <- creating a fn ptr that uses a generic: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=08c85e2bb802dc86deb7cc8f651df3ca
explodingwaffle1 has joined #rust-embedded
<explodingwaffle1> <Ecco> "This: https://github.com/embassy..."; <- why does this use a union and not Option? (i don't think this pattern is exclusive to embassy either)
<Ecco> explodingwaffle1: Not sure I understand what you mean
AdinAck[m] has quit [Quit: Idle timeout reached: 172800s]
<explodingwaffle1> not really anything to do with your issue. but iirc Option<fn()> has the same size as pointer and None is null, so i was wondering what the point in union Vector was
<GrantM11235[m]> That's a good question. The union allows you to store any arbitrary integer, but I don't know if that is useful or even a good idea
<GrantM11235[m]> Also, I think that union technically needs to be repr(C)
<Ecco> So it's all a bunch of errors in ST's doc
<Ecco> For some reason, using probers and defmt, I have some kind of a backtrace when I log anything
<Ecco> Is there a way to just get the logged message?
<Ecco> Found it. It's `--no-location` for probe-run
Guest7282 has left #rust-embedded [Error from remote client]
barafael[m] has joined #rust-embedded
<barafael[m]> I can't get this display to work reliably: https://joy-it.net/de/products/COM-OLED2.42
<barafael[m]> I got the same module from a different brand and it works fine... But none of the joy-it ones. I'm using an rp2040 with the ssd1309 driver, all via i2c. They all get NAK every couple seconds during continuous write. Speed does not make a difference though
<thejpster[m]> <johannes[m]> "Is there an easy way to replicat..." <- The Neotron-loader does this. Sort of. I load ELF binaries off disk and into RAM then jump to the entry point.
<thejpster[m]> Should be easy enough to write it to disk instead.
<thejpster[m]> To be clear, I load them off and SD card on an RP2040 microcontroller . But anything that implements my file access trait will work.
<adamgreig[m]> you might be able to get probe-rs to do it for you too, but if not you can certainly check its code, since it already has to load elf files and extract the part to write to flash
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #rust-embedded
tiwalun[m] has joined #rust-embedded
<tiwalun[m]> Probe-rs uses this crate
<firefrommoonligh> <Ecco> "It's weird that nobody caught..." <- You may be the first one using this feature/MCU
<firefrommoonligh> The rust embedded open source community is p small, and clusters around a few MCUs and features
<adamgreig[m]> (it turned out to just be an error in the ST datasheet; the interrupt vectors are and have to be consecutive by position)
emerent_ has joined #rust-embedded
emerent is now known as Guest3037
Guest3037 has quit [Killed (calcium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
<firefrommoonligh> Classic
<ragarnoy[m]> any idea what kind of issue could lead probe-rs to hang after flashing and not do anything ?