<re_irc>
<@firefrommoonlight:matrix.org> (albeit a line on power on wouldn't hurt anything on any projects I have, perhaps that's not a safe assumption
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc>
<@mvanbergen:matrix.org> jamesmunns: Dirbaio Hi, I'm writing a Rust embedded program based on RTIC. It interfaces with a serial device so I am using the stm32f3xx_hal::serial module. I'm a Rust newbie and even worse have not written C code in a long time. Anyway, I'm working through a solution which allows me to read a variable size buffer using the '''pub fn read_exact<B, C>(self, buffer: B, channel: C) -> Transfer<B, C,...
<re_irc>
... Self>''' function from the stm32f3xx_hal::serial::Rx module using DMA. The interrupt fires only when the number of bytes coming from the device equals buffer B's size. It's not clear to me how I can just make this buffer be large enough for the largest message coming from the device, but having it fire at the end of receiving the message. It seems to "hang" until it receives the number of bytes to fully fill the buffer. ...
<re_irc>
... I hope I am explaining this clearly!
<re_irc>
<@jamesmunns:beeper.com> mvanbergen yeah, that's generally how the stm32 DMA engine works (notify on completion)
<re_irc>
<@jamesmunns:beeper.com> Your two options generally are:
<re_irc>
<@jamesmunns:beeper.com> 1. Have the other side pad out the messages, maybe with some dummy value
<re_irc>
<@jamesmunns:beeper.com> 2. You can use the serial idle detect functionality, or some kind of timer interrupt, to trigger an event, and you can terminate the transfer early. The API does not support this out of the box, afaik
<re_irc>
<@firefrommoonlight:matrix.org> For STM32 UART, there are a few other options you can try
<re_irc>
<@jamesmunns:beeper.com> But it's totally possible to do. I actually looked into it recently for a customer project
<re_irc>
<@firefrommoonlight:matrix.org> *Actually that's the only weirrd one that might make sense here besides TC
<re_irc>
<@jamesmunns:beeper.com> (the trick for early termination is you have to check the DMA control Registers for how many bytes were actually handled before stopping)
<re_irc>
<@firefrommoonlight:matrix.org> Is there an uppor or lower limit on buffer size?
<re_irc>
<@firefrommoonlight:matrix.org> Do you also write the firmware for the other device?
<re_irc>
<@mvanbergen:matrix.org> Thank you James Munns and firefrommoonlight .
<re_irc>
<@mvanbergen:matrix.org> firefrommoonlight: I think I could come up with a lower and upper limit based on my use case. Unfortunately, I don't have access to the firmware for the device. Right now for my proof of concept, I am interfacing with the Adafruit FONA cellular board. You talk to it serially using AT type commands.
<re_irc>
<@firefrommoonlight:matrix.org> My instinct is the best solution involves the devices cooperating with a standard protocol. If not, how you handle it will depend on the details of the data
<re_irc>
<@firefrommoonlight:matrix.org> Example: The devices agree a message is 30 bytes. Your DMA buffer is 30 bytes. You use the DMA transfer complete interrupt
<re_irc>
<@firefrommoonlight:matrix.org> If the other device only needs to send 20 bytes, it pads the rest using and end sequence, then 0s or something
<re_irc>
<@mvanbergen:matrix.org> firefrommoonlight: I was hoping there was an equivalent to "readLine" in python 😀.
<re_irc>
<@firefrommoonlight:matrix.org> You could do it without DMA
<re_irc>
<@firefrommoonlight:matrix.org> Or pick a buffersize and go with it
<re_irc>
<@mvanbergen:matrix.org> firefrommoonlight: Yes, good point.
<re_irc>
<@mvanbergen:matrix.org> firefrommoonlight: James Munns You both helped greatly, first confirming that I am not missing something obvious and also sharing a couple of approaches to take. I'll keep you updated as I work through it. Thanks!
rjframe has quit [Ping timeout: 245 seconds]
<re_irc>
<@contradict:matrix.org> mvanbergen: Another possibility is to use the Receive Timeout interrupt (discussed under the Modbus Communication heading of the user manual). I have used this on the STM32F7 from C, a quick glance at the F3 datasheet looks promising but I'm not sure how much of that functionality is available in the HAL.
<re_irc>
<@contradict:matrix.org> It is a bit of fiddling to cleanly shut down the DMA when the timeout happens, but it works well once you get it set up.
crabbedhaloablut has quit [Ping timeout: 276 seconds]
<re_irc>
<@jamesmunns:beeper.com> I also remember seeing something that was used for some smart card mode or something that was more flexible than the "single byte idle period" the typical idle detect uses
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
PyroPeter has quit [Ping timeout: 260 seconds]
PyroPeter has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc>
<@oddstr13:matrix.org> thejpster:matrix.org: You could use Firefox's container tabs, or simply multiple browsers.
<re_irc>
<@emilgardis:matrix.org> emilgardis:matrix.org: therealprof: this needs to be done now if its to be included in this weeks issue, the mail will be sent out in a few hours afaik
<re_irc>
<@thejpster:matrix.org> I am well aware of Firefox containers. They are excellent - except when you have two accounts at the same URL and it can no longer open pages in the correct container automatically.
<re_irc>
<@thejpster:matrix.org> Also, it wouldn't fix the URL used for my commits.
dcz has joined #rust-embedded
<dcz>
is there anyone here familiar with TockOS? I'm trying to understand how Bluetooth works from the application
<re_irc>
<@jamesmunns:beeper.com> dcz unfortunately most of the tock-os crowd isn't very active here (and vice-versa). They are usually pretty responsive on their mailing list though in my experience.
dcz has quit [Ping timeout: 250 seconds]
<re_irc>
<@thejpster:matrix.org> cortex-m-rt 0.7.1 is out. It fixes an unwinding issue, most notably seen in kurling's probe-run.
<re_irc>
<@adamgreig:matrix.org> thejpster: once you've pushed the tag, could you make a release from it on GitHub? Just stick the changelog section in the description
<re_irc>
<@adamgreig:matrix.org> (👍 on the release!)
<re_irc>
<@thejpster:matrix.org> cm-rt has zero releases on github
<re_irc>
<@thejpster:matrix.org> Is that a thing we do now?
<re_irc>
<@adamgreig:matrix.org> Ah.... Huh.
<re_irc>
<@adamgreig:matrix.org> Yes let's start!
<re_irc>
<@thejpster:matrix.org> Agreed. We should do this.
<re_irc>
<@adamgreig:matrix.org> We already do on c-m and other crates, I guess that's what I'm thinking of
<re_irc>
<@thejpster:matrix.org> Oooh. "Auto-generate release notes" is schfancy
<re_irc>
<@adamgreig:matrix.org> Did it work? I saw the announcement but haven't tried it out yet
<re_irc>
<@thejpster:matrix.org> Unfortunately I looked that them, thought "that's great" and then replicated the CHANGELOG contents instead for consistency. And how there's a release for 0.7.1 I can't auto-generate them any more.
<re_irc>
<@thejpster:matrix.org> But they looked pretty nice. Had a list of "new contributors" and linked in all the PRs in that release.
<re_irc>
<@thejpster:matrix.org> I have added releases for the two 0.7.x releases and every 0.6.x release. Not sure there's any point going further back in time.
<re_irc>
<@eldruin:matrix.org> I read this quote today:
<re_irc>
<@eldruin:matrix.org> > C++: The power, elegance and simplicity of a hand grenade.
<re_irc>
<@eldruin:matrix.org> Even more interesting is that it comes from Kenneth C. Dyke in 1997
<re_irc>
<@nickray:solokeys.com> ofc there's also xkcd 1319 with CI things ^^
rjframe has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> emilgardis:matrix.org: Oh sorry, you wanted to prod me into doing it? I thought you'd be picking that up (anyone could)...
dcz_ has joined #rust-embedded
dcz_ has quit [Remote host closed the connection]
dcz_ has joined #rust-embedded
dcz_ has quit [Remote host closed the connection]
dcz_ has joined #rust-embedded
<re_irc>
<@mehmet:grusbv.com> How often do you make use of the idioms in Rust when writing a device driver?
<re_irc>
<@mehmet:grusbv.com> A few that I wonder are, `Result<>` and Traits
<re_irc>
<@mehmet:grusbv.com> I mean, one can just write a driver without much reliance on them, with an exception of having a device instance and associated methods.
<re_irc>
<@mehmet:grusbv.com> And implementing a higher level Trait that standardizes how the device is going to be utilized.
<dcz_>
if your device has failing conditions, then you would use the Result in your interface too
<re_irc>
<@mehmet:grusbv.com> Would you define Errors, somehow?
<re_irc>
<@mehmet:grusbv.com> Like one would do with Exceptions
<re_irc>
<@mehmet:grusbv.com> Ah, I did this to indicate success in one fn.
<re_irc>
<@mehmet:grusbv.com> If there was an exception, you would return `Err(())` inline or `Err(something_goes_here)`
<dcz_>
you will likely implement traits for your internal structs if writing the device driver requires calling to interfaces that need them
<re_irc>
<@mehmet:grusbv.com> what would that `somethin_goes_here` be? An enum? Any enum? Predefined type of enum?
<dcz_>
or things like Copy, Eq, Debug
<dcz_>
any type really
<dcz_>
you can have a bare Error enum where you have all different error conditions, but you can also have a Struct containing time or some other context
<re_irc>
<@mehmet:grusbv.com> irc_libera_dcz_:psion.agg.io: pondering on this one.
<re_irc>
<@mehmet:grusbv.com> Do you mean in a case where a user code needs to interface with the struct, or in the case where even the driver itself needs to interface with that struct?
<re_irc>
<@mehmet:grusbv.com> (Btw, feel free to point me somewhere if the chat turns counterproductive)
<dcz_>
"Do you mean" what are you referring to?
<dcz_>
enums or traits like Copy etc?
<re_irc>
<@mehmet:grusbv.com> irc_libera_dcz_:psion.agg.io: "traits for your internal structs"
<dcz_>
generally all public structs in a library should implement Debug
<dcz_>
if you want to use some interface (e.g. ports, whatever HAL your driver might use), that interface can contain traits that do some work
<dcz_>
and finally you may want Copy or Eq for your internal purposes, or custom traits to avoid duplicating code
<re_irc>
<@mehmet:grusbv.com> And Debug, Eq, Copy can be derived.
Lumpio- has quit [Read error: Connection reset by peer]
tokomak has quit [Ping timeout: 245 seconds]
Lumpio- has joined #rust-embedded
Lumpio- has quit [Ping timeout: 245 seconds]
Lumpio- has joined #rust-embedded
rjframe has quit [Ping timeout: 260 seconds]
<re_irc>
<@mehmet:grusbv.com> Hi, I would like to write the portion of a device driver that handles interrupt configuration of an accelerometer. Still new, therefore a bit lost in how to get the structure. I am sure there is an idiomatic way to get this.
<re_irc>
<@mehmet:grusbv.com> I would like get the effect where one could easily add these binary values of the enums, effectively selecting multiple interrupt sources.
<re_irc>
<@mehmet:grusbv.com> I know that Rust has rather powerful enums, therefore I am wondering whether there is a nice trick to that.
<re_irc>
<@dngrs:matrix.org> there are some bitfield crates
<re_irc>
<@mehmet:grusbv.com> Ah, are they commonly used in device drivers?
<re_irc>
<@mehmet:grusbv.com> I checked a few dds to get inspiration but havent bumped into those
<re_irc>
<@dngrs:matrix.org> I wouldn't know how common its usage is but to me it looks similar to your example at least
<re_irc>
<@mehmet:grusbv.com> 👍️ thank you.
<re_irc>
<@mehmet:grusbv.com> This is the first time I bumped into this book, great.
<re_irc>
<@mehmet:grusbv.com> Another question: Do anyone do tests on the target, rather than to mock things?
<re_irc>
<@mehmet:grusbv.com> Say, unit tests or integration tests?
<re_irc>
<@mehmet:grusbv.com> Where shall I look?
<re_irc>
<@dngrs:matrix.org> sometimes, my button interrupt fires when *releasing* the button. I suppose I cannot really debounce that and it's just a dodgy button?
<re_irc>
<@jamesmunns:beeper.com> defmt-test is probably your best bet for on-device testing Mehmet Ali
<re_irc>
<@jamesmunns:beeper.com> there are a couple of blog posts on the ferrous blog explaining it
<re_irc>
<@mehmet:grusbv.com> On it, I am already using all the tools.
<re_irc>
<@jamesmunns:beeper.com> dngrs:matrix.org: Yeah, that's probably electrical bounce. You could debounce it with an RC circuit, if you are designing it (and it's off-board)
<re_irc>
<@jamesmunns:beeper.com> (you'd put a capacitor across the button, and a resistor between the button and the GPIO)
<re_irc>
<@jamesmunns:beeper.com> You can also debounce it in software, but it's not as simple as "set event on interrupt"
<re_irc>
<@dngrs:matrix.org> onboard ("super blue pill"), but good to know for future own designs!
<re_irc>
<@dngrs:matrix.org> not sure how to debounce in software though, I mean I am about to give it like 50ms time of "don't fire again", but let's say I press, hold for 1 sec, release and it still fires ... well, I'm SOL. I think?
<re_irc>
<@dngrs:matrix.org> (I can totally live with that - just wondering if I'm missing something)
<re_irc>
<@k900:0upti.me> Just ignore very short presses
<re_irc>
<@k900:0upti.me> It's impossible to hit a button for 0.05ms
<re_irc>
<@jamesmunns:beeper.com> Yeah, you'd need to switch to interrupts on both edges though
<re_irc>
<@k900:0upti.me> For a real human person
<re_irc>
<@jamesmunns:beeper.com> and only fire the event after the release, and keep track of time between press and release
<re_irc>
<@jamesmunns:beeper.com> or, only fire the event something like 50ms after the press (if it's a hold)
<re_irc>
<@jamesmunns:beeper.com> Honestly: putting a capacitor in parallel across the button will *probably* make it better 90% of the time
<re_irc>
<@jamesmunns:beeper.com> just a tiny <= 0.1 uF cap
<re_irc>
<@k900:0upti.me> If it's a blue pill, I don't think there's much space for a capacitor on there
<re_irc>
<@k900:0upti.me> Assuming you're using the one onboard button
<re_irc>
<@jamesmunns:beeper.com> Looks like PA8 is the onboard button on the super blue pill, and it's also broken out on one of the GPIO headers
<re_irc>
<@jamesmunns:beeper.com> so if you're breadboarding, you can put the cap between PA8 and ground
<re_irc>
<@k900:0upti.me> It depends on the variant I think
<re_irc>
<@k900:0upti.me> Pretty sure the OG blue pill had it hardwired to reset
<re_irc>
<@jamesmunns:beeper.com> Also maybe an external pullup? It looks like there is no on-board one, so it would only be using the built-in one, if you enable that in software.
<re_irc>
<@k900:0upti.me> But most of the knockoffs have a jumper
<re_irc>
<@jamesmunns:beeper.com> Yeah, if you DON'T have the internal pullup enabled, I am very surprised it works at all.
<re_irc>
<@k900:0upti.me> Except they're all unbranded
<re_irc>
<@jamesmunns:beeper.com> Otherwise you would have a totally floating pin
<re_irc>
<@k900:0upti.me> So no one knows what the actual OG is
<re_irc>
<@dngrs:matrix.org> (it's a weird board, some nice features some rather useless ones, eg you can't use the ESP01 socket to flash new firmware)
<re_irc>
<@jamesmunns:beeper.com> K900, yeah, definitely familiar with the more common blue/black pills
<re_irc>
<@k900:0upti.me> jamesmunns:beeper.com: Oh yeah I know you are :)
<re_irc>
<@jamesmunns:beeper.com> :D
<re_irc>
<@k900:0upti.me> Just trying to explain my confusion to people who might not be :)
<re_irc>
<@jamesmunns:beeper.com> Yeah, as a non-invasive modification (if the built-in pullup doesn't work, those are usually in the 10-50Kohm range), a big chonky 1K resistor between PA8 and VCC and a 0.1uF cap between PA8 and GND will proooooobably make your problems go away
<re_irc>
<@jamesmunns:beeper.com> it'd be better to also have a resistor between PA8 and the switch as well, but honestly: It's not going to matter much.
<re_irc>
<@dngrs:matrix.org> `let mut butt = gpioa.pa8.into_pull_up_input(&mut gpioa.crh);` so it should be enabled already
<re_irc>
<@dngrs:matrix.org> gonna try a cap
<re_irc>
<@dngrs:matrix.org> hmm, still happening but I think it's a bit better
<re_irc>
<@dngrs:matrix.org> I have more inappropriate letter-switching comments about *ticking clocks*
<re_irc>
<@jamesmunns:beeper.com> :|
<re_irc>
<@dngrs:matrix.org> ok, before I give up, I'm gonna try a bigger cap .. the ceramic one I found might have been too feeble
<re_irc>
<@jamesmunns:beeper.com> Borrow the Saleae from the office and take an analog sample :p
<re_irc>
<@jamesmunns:beeper.com> we can see what the ringing looks like
<re_irc>
<@dngrs:matrix.org> heh
<re_irc>
<@dngrs:matrix.org> I do have my own scope, that's actually not the worst idea
<re_irc>
<@jamesmunns:beeper.com> In fact, I would suggest it's in fact a pretty good one!
<re_irc>
<@dngrs:matrix.org> (but I never gotten around to porting the GUI to the m1..)
<re_irc>
<@jamesmunns:beeper.com> Connect an ADC pin to be common with PA8
<re_irc>
<@dngrs:matrix.org> the bigger cap is making it *worse*?
<re_irc>
<@jamesmunns:beeper.com> just store like 100ms of samples
<re_irc>
<@jamesmunns:beeper.com> lol
<re_irc>
<@dngrs:matrix.org> yeah now I reliably get a trigger on every press + release
<re_irc>
<@dngrs:matrix.org> even though I did `butt.trigger_on_edge(&mut dp.EXTI, hal::gpio::Edge::Falling);`
<re_irc>
<@dngrs:matrix.org> I mean, I can still put an is pressed check in the irq handler
<re_irc>
<@dngrs:matrix.org> I had that before, just exchanged it for `Falling` instead of `RisingFalling`
<re_irc>
<@jamesmunns:beeper.com> yeah... I could keep guessing, but honestly the scope will tell you more.
<re_irc>
<@dngrs:matrix.org> yeah. In fact the check is still there. Ok, scope time! Later though, I'm in fact on a detour and my actual mission is ultrasonic distance
<re_irc>
<@jamesmunns:beeper.com> :D
<re_irc>
<@jamesmunns:beeper.com> oh, another handy software tip is to just ignore button presses for N ms after the last one
<re_irc>
<@dngrs:matrix.org> yeah I'm going to do that for debouncing anyway, I'm specifically wondering about the spurious triggers after a long press
<re_irc>
<@jamesmunns:beeper.com> either by disabling the interrupt, or just bailing in the ISR
<re_irc>
<@jamesmunns:beeper.com> I'm *guessing* that's just a crappy, bouncy button? but I could be wrong.
<re_irc>
<@dngrs:matrix.org> yeah, I think so too
<re_irc>
<@dngrs:matrix.org> I mean, it's a dirt cheap board, what am I expecting
<re_irc>
<@thejpster:matrix.org> neotron-bmc uses debouncr. Works for me.