smach has quit [Remote host closed the connection]
smach has joined #rust-embedded
smach has quit [Remote host closed the connection]
smach has joined #rust-embedded
<re_irc>
<@tholmie:matrix.org> Doesn’t an MSRV change require “major” version bump? If not I would think removing the pre-compilation of ASM routines and removing the inline ASM feature so it’s just always used would be
<re_irc>
<@adamgreig:matrix.org> changing msrv doesn't require a semver-incompatible bump (perhaps unfortunately, views vary, but that's not the rule we follow in any event)
<re_irc>
<@adamgreig:matrix.org> _removing_ the inline feature would be breaking, but we can leave it there as a no-op
<re_irc>
<@adamgreig:matrix.org> the reality was that many projects on crates.io that we depend on would not even track or document an MSRV, would update it by accident or incidentally or on purpose, so we'd often end up in an impossible situation where our MSRV was higher because of a dependency, or we had to pin an outdated version of a dependency
<re_irc>
<@adamgreig:matrix.org> perhaps if cargo had tracked this sort of thing (the new rust-version attribute in the manifest for example) from day 1, the ecosystem in general would be stricter about it, though maybe that would be worse overall
<re_irc>
<@adamgreig:matrix.org> what we found at the time was nobody actually cared or wanted an old MSRV, we received no feedback from anyone saying it would be useful, all we had was hypothetical examples
<re_irc>
<@adamgreig:matrix.org> so basically we gave up on MSRV: most of our crates do specifically say what their MSRV is and check it in CI and so will only ever increase it as a deliberate act to use a new feature, but they are free to increase it all the way to current-stable in any release
<re_irc>
<@adamgreig:matrix.org> (and as far as I know still no one has complained, though I am aware of various industrial users of embedded crates that pin old stable or nightly compilers, so far they've still been ahead of us... that may change come 1.59)
<re_irc>
<@adamgreig:matrix.org> (pinning a >1-year-old nightly 😬)
<re_irc>
<@tholmie:matrix.org> Makes sense! Thanks for the thorough explanation 😄 yeah personally I just alway update on every release so I don’t care, and people who do care should pin dependencies too 🤷 but yeah who knows, maybe 1.59 is finally the release with enough embedded features, but I’m sure there is still plenty to be desired (const float stuff, GATs, async traits…)
<re_irc>
<@adamgreig:matrix.org> yea.. i don't think async traits and GATs will matter as much for c-m/-rt but might be some nice uses of const floats
<re_irc>
<@adamgreig:matrix.org> i wouldn't be surprised if we stay on 1.59 for a good while, but stable inline asm is just too appealing to resist
<re_irc>
<@adamgreig:matrix.org> maybe us bumping it will give holdouts a good excuse to spend the time updating their rustc
<re_irc>
<@adamgreig:matrix.org> rust makes it really easy and backcompat is so good, so I can't imagine it really takes much time to update.... except if you've pinned an old nightly
<re_irc>
<@adamgreig:matrix.org> there's also an aspect that we're all volunteers and enforcing the strict msrv policy was boring, tiresome, high-effort, and didn't benefit us or anyone who talks to us
<re_irc>
<@adamgreig:matrix.org> if some company needs to stick to an old rustc they're welcome to maintain their own forks or pay someone to do it, of course
<re_irc>
<@adamgreig:matrix.org> but in general we do want to make life better for commercial/industrial users, so that's not an argument used very often
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Client Quit]
jackneillll has joined #rust-embedded
jackneilll has quit [Ping timeout: 256 seconds]
smach has quit [Read error: Connection reset by peer]
smach has joined #rust-embedded
<re_irc>
<@jordens:matrix.org> As a commercial/industrial user who has been pinning old nightlies and old crate versions for years, I encourage the community to bump MSRV freely and often. In practice for us it's not something that is holding us back at all. On the contrary, a consistently modern and current ecosystem is much more convincing and easier to use than one with lots of layers of compatibility and workarounds for old RVs.
<re_irc>
<@chrysn:matrix.org> adamgreig: GATs (at least generic-over-lifetimes) are quite useful in embedded network protocol processing, when it is supposed to be portable over different network backend implementations. I see great value in this, and it'll allow a few things I've run nightly-only so far become stable.
<re_irc>
<@adamgreig:matrix.org> chrysn:matrix.org: Sorry, I mean the cortex-m crate specifically, not embedded cortex-m applications in general! Certain to be useful there (like async-embedded-hal)
<re_irc>
<@thejpster:matrix.org> Wouldn't it be nice if you could just put rust="1.59" in your dependencies.
<re_irc>
<@thejpster:matrix.org> Or std=, or core=
<re_irc>
<@thejpster:matrix.org> But I guess std is tied to rustc, so you can't build an old std with a newer rustc.
<re_irc>
<@adamgreig:matrix.org> For now... there's work to make std and core just like other crates that you can version and build
<re_irc>
<@adamgreig:matrix.org> You can put rust-version in cargo.toml now at least
<re_irc>
<@adamgreig:matrix.org> jordens:matrix.org: Thank you for the feedback!
<re_irc>
<@jamesmunns:beeper.com> thejpster:matrix.org: Wasnt this a thing in a somewhat recent release?
<re_irc>
<@jamesmunns:beeper.com> Maybe the keyword was just reserved
<re_irc>
<@burrbull:matrix.org> with `esp32` feature enabled
<re_irc>
<@mabez:matrix.org> burrbull:matrix.org: Thanks for the link. That's super odd, because it builds locally and when I add the explicit import it says the import is unused...
<re_irc>
<@mabez:matrix.org> Ugh must have been a buggy nightly version or something, updating to the last night it now shows the error. I'll push a fixed release now.
<re_irc>
<@k900:0upti.me> There's a HAL for the main core
<re_irc>
<@fragadaleta:matrix.org> yeah i saw that. What's the situation wrt the nRF52840-DK ?
<re_irc>
<@fragadaleta:matrix.org> if you know...
<re_irc>
<@k900:0upti.me> Generally probably the same
<re_irc>
<@k900:0upti.me> As in there's a HAL that works
<re_irc>
<@k900:0upti.me> The weird secondary core on the nRF53 is the thing that's not really well supported
<re_irc>
<@fragadaleta:matrix.org> yeah ☹️
<re_irc>
<@k900:0upti.me> It's very unlikely you need it tbh
<re_irc>
<@fragadaleta:matrix.org> the second core is exactly the reason why i would buy it
<re_irc>
<@k900:0upti.me> It's a pretty niche design for niche use cases
<re_irc>
<@k900:0upti.me> What are you going to do with it?
<re_irc>
<@fragadaleta:matrix.org> on-edge compute and DSP
<re_irc>
<@k900:0upti.me> But why do you need a second core for that?
<re_irc>
<@k900:0upti.me> Especially one not really designed for either of those thinga
<re_irc>
<@tarfu:matrix.org> I think the biggest "problem" with the nrf5340 is the change in bluetooth as it changed a lot to the nrf52 and there is no softdevice you can use if my knowledge is up to date. They focus on zephyr as OS and use their bluetooth stack.
<re_irc>
<@fragadaleta:matrix.org> well the 52840 has an M4 and the 5340 has an M33
<re_irc>
<@k900:0upti.me> The secondary core on the nRF53 is definitely slower than the M4 on the nRF52
<re_irc>
<@k900:0upti.me> Because it's running at half clock
<re_irc>
<@fragadaleta:matrix.org> the first core does
<re_irc>
<@fragadaleta:matrix.org> ok LE audio is interesting 😛
<re_irc>
<@k900:0upti.me> The first core does, but if you're just getting it for the first core, just get something M7 based instead
<re_irc>
<@fragadaleta:matrix.org> tarfu:matrix.org: ah didn't know. So they force you to run over Zephyr or they just support it?
<re_irc>
<@tarfu:matrix.org> fragadaleta:matrix.org: They don't force you and there is stuff which gets you the BLE controller side but you need the host side which is the problem (and where they "recommend" zephyr)
<re_irc>
<@fragadaleta:matrix.org> i see
<re_irc>
<@newam:matrix.org> Zephyr isn't the end of the world if you want to use rust, there's a decent rust wrapper for it.
<re_irc>
<@newam:matrix.org> Zephyr is unlike FreeRTOS and other - your code runs with fewer permissions as an "app" scheduled by the zephyr kernel, so there is a clean line of separation.
<re_irc>
<@firefrommoonlight:matrix.org> fragadaleta:matrix.org: Do you know more on that? I see the claim in the doc you linked, but what sort of audio quality is that good for? I'm asking because I'm searching for a BT module for audio. (Ideally, it would connect via I2C etc for controls, and pass audio over i2S etc). I'd just wire up an nRF, like so, but heard BT LE audio isn't good
<re_irc>
<@firefrommoonlight:matrix.org> And you need normal BT for godo quality audio
<re_irc>
<@k900:0upti.me> BT audio generally sucks extremely badly unless you use a fancy codec like aptX or LDAC
<re_irc>
<@k900:0upti.me> Or AAC
<re_irc>
<@firefrommoonlight:matrix.org> Thx
<re_irc>
<@k900:0upti.me> And that comes with patent fees
<re_irc>
<@firefrommoonlight:matrix.org> Also, if anyone knows of a good BT audio module... lol
<re_irc>
<@firefrommoonlight:matrix.org> So much of the BT stuff I see is LE
<re_irc>
<@newam:matrix.org> firefrommoonlight:matrix.org: There are multiple bluetooth audio protocols.
<re_irc>
<@newam:matrix.org> There's the one designed in the mid 00's made for bluetooth earpieces - it sounds terrible for non-voice.
<re_irc>
<@newam:matrix.org> There are more modern things (like sony's A2DP) that performs MUCH better so you can use it for listening to music, or even gaming if you tune the latency right.
<re_irc>
<@k900:0upti.me> firefrommoonlight:matrix.org: LE or not doesn't actually matter
<re_irc>
<@k900:0upti.me> You just have very little bandwidth to work with
<re_irc>
<@k900:0upti.me> And the Bluetooth spec mandates one codec, which is a complete abomination
<re_irc>
<@k900:0upti.me> Everything actually decent is a vendor extension
<re_irc>
<@k900:0upti.me> So if you want to have consistently good sound, you probably want to support ALL OF THEM
<re_irc>
<@k900:0upti.me> Apple stuff only supports AAC, Sony stuff supports LDAC, everyone else buys the same Qualcomm SoC that only supports aptX
<re_irc>
<@firefrommoonlight:matrix.org> Well, I need to accept BT audio or no one will buy the thing
<re_irc>
<@firefrommoonlight:matrix.org> I gather normal BT is a lot better quality
<re_irc>
<@firefrommoonlight:matrix.org> But I haven't actually tried
<re_irc>
<@k900:0upti.me> You need to pay Apple for AAC, pay Qualcomm for aptX, and god help you if you try to figure out if LDAC is patent encumbered in your jurisdiction
<re_irc>
<@firefrommoonlight:matrix.org> I'm making fancy scifi hearing aids, and no one will buy a hearing aid that can't link to the phone or tv
<re_irc>
<@firefrommoonlight:matrix.org> BT support is m andatory
<re_irc>
<@firefrommoonlight:matrix.org> Just need to pass it through though; nothing fancy
<re_irc>
<@k900:0upti.me> And all of this applies to normal BT or LE
<re_irc>
<@k900:0upti.me> Oh so you're on the receiving end
<re_irc>
<@k900:0upti.me> Then you _really_ want to support everything
<re_irc>
<@k900:0upti.me> But realistically you probably just want to buy that one Qualcomm SoC
<re_irc>
<@firefrommoonlight:matrix.org> Just need it to pair to a device, accept a BT audio stream, and pass the audio to the rest of the app
<re_irc>
<@newam:matrix.org> Standards are really hard like that. I have a lot more sympathy after working closely with the people driving the NVMe standards.
<re_irc>
<@newam:matrix.org> Your standard has to keep up with the functionality people want to avoid fracturing the ecosystem, even if that means releasing a half-baked feature of the new standard because there is a very small time window to implement before fracturing occurs.
<re_irc>
<@newam:matrix.org> If vendors/customers want new functionality they will do vendor-specific things.
<re_irc>
<@firefrommoonlight:matrix.org> then I'll mix etc as required. And presuambly would need to manage pairing etc over an I2C (?) interface
<re_irc>
<@firefrommoonlight:matrix.org> Haha I might just buy some of those and have at it
<re_irc>
<@firefrommoonlight:matrix.org> Hmm. Price is fine, but I can't get any without MOC=4000 from Digikey
<re_irc>
<@firefrommoonlight:matrix.org> Ocotopart isn't showing any distributors with it in stock :(
<re_irc>
<@firefrommoonlight:matrix.org> And dev kits are pricey
<re_irc>
<@k900:0upti.me> It do be like that
<re_irc>
<@k900:0upti.me> If you want decent quality audio, you pay for the good codec
<re_irc>
<@firefrommoonlight:matrix.org> Price at quant is fine
<re_irc>
<@k900:0upti.me> If you want to receive decent quality audio, you pay for all five of them
<re_irc>
<@firefrommoonlight:matrix.org> But I need to eval it lol
<re_irc>
<@adamgreig:matrix.org> also all the docs are restricted
<re_irc>
<@firefrommoonlight:matrix.org> That's fucked up
<re_irc>
<@k900:0upti.me> That's just typical Qualcomm
<re_irc>
<@newam:matrix.org> firefrommoonlight:matrix.org: Some companies don't want hobbyists working on their chips.
<re_irc>
<@newam:matrix.org> They want the people who will buy in bulk and give them an unholy amount in licensing fees.
<re_irc>
<@k900:0upti.me> That is also typical Qualcomm
<re_irc>
<@adamgreig:matrix.org> yea, no interest unless you're buying at least a million
<re_irc>
<@firefrommoonlight:matrix.org> I was about to yolo some and add to teh design, but I'll wait and see what optiosn are avail, then ask Qualcomm nicely or something
<re_irc>
<@firefrommoonlight:matrix.org> Right now, need to work on other areas. The BT isn't core functionality, but it's a (mandatory) drop-in before shipipng
<re_irc>
<@firefrommoonlight:matrix.org> Have a lot of work to go on this product
<re_irc>
<@adamgreig:matrix.org> probably cheaper and easier to buy a cheap bluetooth earbud off-the-shelf, take its pcb out, solder it to your board :P
<re_irc>
<@firefrommoonlight:matrix.org> Haha that's so awful
<re_irc>
<@firefrommoonlight:matrix.org> I could at least try the BTLE thing by adding an nRF or something
<re_irc>
<@k900:0upti.me> Which would be extremely illegal
<re_irc>
<@k900:0upti.me> And Qualcomm will have your ass as soon as you start shipping more than like three of those
<re_irc>
<@firefrommoonlight:matrix.org> It should work, just maybe not good for music quality. If it's good enough for phone calls, maybe could even ship initially with that
<re_irc>
<@firefrommoonlight:matrix.org> I wasn't counting on getting a BT module for audio being this tough
<re_irc>
<@k900:0upti.me> Having an army of trigger happy lawyers is also very much typical Qualcomm
<re_irc>
<@firefrommoonlight:matrix.org> Fuck that
<re_irc>
<@firefrommoonlight:matrix.org> If I don't find a good alt, will try with nRF or other BTLE module
<re_irc>
<@newam:matrix.org> You can get custom ASICs fabbed for $5k these days :)
<re_irc>
<@firefrommoonlight:matrix.org> Basis is, blind source sep is a hard problem, so I'm cheating by isolating sources based on direction
<re_irc>
<@matoushybl:matrix.org> newam:matrix.org: 8051 with custom peripherals? :D
<re_irc>
<@firefrommoonlight:matrix.org> And combining various array configs to optimize frequency response, directionality etc
<re_irc>
<@adamgreig:matrix.org> digital logic is one thing, RFASICs maybe another...
<re_irc>
<@newam:matrix.org> matoushybl:matrix.org: You can actually get _good_ custom ASICs for $5k, 100nm process I think.
<re_irc>
<@newam:matrix.org> Lots of RISC-V things.
<re_irc>
<@k900:0upti.me> matoushybl:matrix.org: Found the Intel employee
<re_irc>
<@newam:matrix.org> I am actually lol
<re_irc>
<@k900:0upti.me> xd
<re_irc>
<@k900:0upti.me> Has anyone done a count of how many product Intel still ships that have either an 8051 or a 386 inside?
<re_irc>
<@newam:matrix.org> Intel is pretty isolated between business units. I'm in the storage side of things.
<re_irc>
<@newam:matrix.org> k900:0upti.me: Probably. Not my department though :P
<re_irc>
<@k900:0upti.me> SSDs or Optane?
<re_irc>
<@k900:0upti.me> Or is it the same thing now?
<re_irc>
<@newam:matrix.org> Used to be both, but intel is selling the NAND business to SKHynix, so we had to split. I just do NAND now
<re_irc>
<@k900:0upti.me> I'm expecting a "no comment" on this one, but any plans for gen4 drives? Was looking at throwing more storage into my work machine
<re_irc>
<@k900:0upti.me> And I don't want to give Samsung any more money after all the Linux bugs
<re_irc>
<@newam:matrix.org> We have gen4 drives shipping today, but they are all enterprise. If you want a super high endurance 4TB or 8TB u.2 drive I would recommend them :D
<re_irc>
<@newam:matrix.org> Otherwise, yeah, unfortunately I have to say no comment.
<re_irc>
<@k900:0upti.me> Yeah, can't really fit a U.2 into my desktop :)
<re_irc>
<@k900:0upti.me> Buy one and disassemble it
<re_irc>
<@fragadaleta:matrix.org> i am really curious about the DSP they have... these things are amazingly fast
<re_irc>
<@k900:0upti.me> But it's probably custom
<re_irc>
<@fragadaleta:matrix.org> lol i have one but i will never open it
<re_irc>
<@fragadaleta:matrix.org> *never*
<re_irc>
<@fragadaleta:matrix.org> 😀
<re_irc>
<@k900:0upti.me> Most higher end stuff is custom
<re_irc>
<@newam:matrix.org> it's yamaha, so very likely custom.
<re_irc>
<@fragadaleta:matrix.org> i believe so. Just wondering how powerful the hardware could be
<re_irc>
<@fragadaleta:matrix.org> and for sure they'd go bare metal
<re_irc>
<@k900:0upti.me> Probably not powerful at all
<re_irc>
<@k900:0upti.me> It's very likely mostly analog
<re_irc>
<@fragadaleta:matrix.org> there is hard real time pretty much everywhere
<re_irc>
<@k900:0upti.me> And mostly fixed function
<re_irc>
<@fragadaleta:matrix.org> yeah but the DSP?
<re_irc>
<@k900:0upti.me> I don't even know if that thing _has_ one
<re_irc>
<@k900:0upti.me> It could just be completely fixed function
<re_irc>
<@fragadaleta:matrix.org> what do you mean with fixed function?
<re_irc>
<@k900:0upti.me> Completely custom chips that are designed to do one specific thing
<re_irc>
<@k900:0upti.me> And do it entirely in hardware
<re_irc>
<@fragadaleta:matrix.org> ah but they play thousands of sounds recorded in the studio
<re_irc>
<@k900:0upti.me> There's probably a ROM for those
<re_irc>
<@fragadaleta:matrix.org> and they process them in real time depending how you hit the tom
<re_irc>
<@k900:0upti.me> And a DAC
<re_irc>
<@fragadaleta:matrix.org> or the drum in general
<re_irc>
<@fragadaleta:matrix.org> it's sick
<re_irc>
<@fragadaleta:matrix.org> believe me
<re_irc>
<@k900:0upti.me> And then the processing is hardware
<re_irc>
<@k900:0upti.me> That's how it usually is with high end audio stuff
<re_irc>
<@fragadaleta:matrix.org> yeah but a DSP must be there indeed
<re_irc>
<@k900:0upti.me> Not necessarily
<re_irc>
<@fragadaleta:matrix.org> reverb and stuff like that is easy...
<re_irc>
<@k900:0upti.me> It could be fully analog
<re_irc>
<@fragadaleta:matrix.org> but getting the sensor data and processing in real time....
<re_irc>
<@fragadaleta:matrix.org> uh
<re_irc>
<@k900:0upti.me> Yamaha has their own fabs
<re_irc>
<@k900:0upti.me> They can make whatever the hell they want
<re_irc>
<@fragadaleta:matrix.org> 🙂
<re_irc>
<@k900:0upti.me> And they do
<re_irc>
<@fragadaleta:matrix.org> and they do it pretty well
smach has quit [Quit: Leaving]
<re_irc>
<@thejpster:matrix.org> Apropos Bluetooth, I made a Bluetooth in-car hands-free kit back in the day
<re_irc>
<@thejpster:matrix.org> I got a free sample when I was finished, but I glued the display into the ashtray so when I sold the car I had to give them the hands free too
<re_irc>
<@firefrommoonlight:matrix.org> neato!
<re_irc>
<@dirbaio:matrix.org> fragadaleta:matrix.org: embassy-nrf supports both cores, in both secure or nonsecure mode, also including the newer DPPI
<re_irc>
<@matoushybl:matrix.org> Both cores running simultaneously?
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> each with their own firmware
starblue1 has quit [Ping timeout: 240 seconds]
starblue1 has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> fragadaleta:matrix.org: In the nrf-HAL fork I added support for it, but haven't tested
<re_irc>
<@firefrommoonlight:matrix.org> I have a 53-DK board; just haven't gotten aroudn to it
<re_irc>
<@firefrommoonlight:matrix.org> the reg API is similar to 52 except for RF
<re_irc>
<@firefrommoonlight:matrix.org> Is the second core like STM32-WB, where you flash proprietary black-box firmware?
<re_irc>
<@firefrommoonlight:matrix.org> Or do you write firmware for it?
<re_irc>
<@dirbaio:matrix.org> firefrommoonlight:matrix.org: PPI is completely different
<re_irc>
<@firefrommoonlight:matrix.org> ALso, there are 2 more GPIO ports AFAIK
<re_irc>
<@dirbaio:matrix.org> there's only 2 ports, but each has two mirrors, for S and NS mode (and there's a 3rd in the net core)
<re_irc>
<@firefrommoonlight:matrix.org> o
<re_irc>
<@firefrommoonlight:matrix.org> As in m-33 secure stuff?
<re_irc>
<@dirbaio:matrix.org> trustzone-m yup
<re_irc>
<@firefrommoonlight:matrix.org> Interesting. On the STM32s that use it, the only time I've seen that coming up is flash read/writes
<re_irc>
<@dirbaio:matrix.org> S firmware can set permissions per gpio pin, so that NS firmware can only touch pins it has permission to
<re_irc>
<@dirbaio:matrix.org> fancy stuff 🤣
<re_irc>
<@dirbaio:matrix.org> if you don't need it, for the most part you can run your entire firmware in S mode and pretend trustzone doesn't exist
<re_irc>
<@firefrommoonlight:matrix.org> NS mode?
<re_irc>
<@firefrommoonlight:matrix.org> non secure right?
<re_irc>
<@firefrommoonlight:matrix.org> and ignore secure
<re_irc>
<@dirbaio:matrix.org> no, the other way around
<re_irc>
<@dirbaio:matrix.org> core boots in S mode, so you can run everything in S mode without having to do special stuff to switch to NS, and pretend trustzone doesn't exist
<re_irc>
<@dkhayes117:matrix.org> Does the nrf9160 have DMA?
<re_irc>
<@firefrommoonlight:matrix.org> ohh
<re_irc>
<@firefrommoonlight:matrix.org> Yes
<re_irc>
<@firefrommoonlight:matrix.org> I'm not sure tehre are any good MCUs that don't!
<re_irc>
<@dkhayes117:matrix.org> It just wasn't listed on the product brief, so I was double checking.
<re_irc>
<@dkhayes117:matrix.org> I've messed very little with DMA. I'm looking at a project where I need large data storage capabilities. DMA should be able to write to external flash right?
<re_irc>
<@firefrommoonlight:matrix.org> Yes, via QSPI
<re_irc>
<@firefrommoonlight:matrix.org> *Actually maybe QSPI directly since it's memory mapped
<re_irc>
<@firefrommoonlight:matrix.org> not sure!
<re_irc>
<@therealprof:matrix.org> DMA support doesn't say anything about technical features.
<re_irc>
<@therealprof:matrix.org> It's simply a feature to get data directly from a to b without using CPU cycles by instructing a separate functional unit to make it happen.
<re_irc>
<@dkhayes117:matrix.org> I found this on the nordic website
<re_irc>
<@dkhayes117:matrix.org> The SPI master can communicate with multiple slaves using individual chip select signals for each of the slave devices attached to a bus.
<re_irc>
<@dkhayes117:matrix.org> Listed here are the main features for the SPIM
<re_irc>
<@dkhayes117:matrix.org> So it seems it can't do DMA to external flash, just RAM
<re_irc>
<@therealprof:matrix.org> No, the peripheral is SPI.
<re_irc>
<@therealprof:matrix.org> If you use a Flash chip connected via SPI you can (or in case of Nordic most likely have to) use DMA.
<re_irc>
<@dkhayes117:matrix.org> Okay, that makes sense.
<re_irc>
<@therealprof:matrix.org> DMA is just an offloading technique.
<re_irc>
<@therealprof:matrix.org> It does not mean that it will map any external chip into the regular address space.
<re_irc>
<@therealprof:matrix.org> If you just want to RW data to a large flash, an SPI flash will do and work with pretty much any MCU out there (except for some 8bit ones). Only if you want to execute code from flash things get a bit spicy.
<re_irc>
<@thejpster:matrix.org> Think of DMA as a hardware memcpy.
<re_irc>
<@dkhayes117:matrix.org> I will be taking high sample rates with the adc, store in flash, then poll for the flash for data samples to run analysis on.
<re_irc>
<@dkhayes117:matrix.org> Roughly, I'm in early stages of hashing this out
<cr1901>
DMA is unsafe in general in Rust? I seem to recall that it's not as useful
<cr1901>
i.e. need a third buffer or something
<re_irc>
<@therealprof:matrix.org> dkhayes117:matrix.org: Sounds totally feasible. But depends on a ton of details, like how much data, how does this data polling mechanism work, etc.
<re_irc>
<@therealprof:matrix.org> irc_libera_cr1901:psion.agg.io: The problem with DMA is that Rust likes to know hollistically everything that is going on in the execution domain. If things happen outside of the usual instruction processing and memory domain (like interrupt processing and DMA) you somehow have to teach the Rust compiler about those concepts which is tricky since it doesn't easily translate...
<re_irc>
<@firefrommoonlight:matrix.org> Nah
<re_irc>
<@firefrommoonlight:matrix.org> DMA works fine in Rust
<cr1901>
>instruction processing
<re_irc>
<@firefrommoonlight:matrix.org> Don't be scared of it or think it's weird
<cr1901>
is that a problem in and of itself to change control flow like that from Rust's POV?
<cr1901>
Or is it only a problem when coupled w/ side effects in the interrupted control flow that wouldn't have occurred otherwise
<re_irc>
<@dkhayes117:matrix.org> The sampling will be a continuous type operation, which is why I thought that DMA doing the writing would help to free up the cpu for data anaylsis. So I would be taking ADC measurements from some sensor, DMA the values to flash, cpu poll flash with a certain window size, run analysis, on significant results side data over cellular connection
<cr1901>
Anyways, I thought Cells solve the problems of interrupts
<re_irc>
<@therealprof:matrix.org> irc_libera_cr1901:psion.agg.io: The side effects are the main problem.
<re_irc>
<@firefrommoonlight:matrix.org> Make sure you're careful about what accesses your DMA buffers, and that they live long enough. Eg as `statics`
<cr1901>
B/c of their special LLVM annotation that "they can be changed by multiple things"
<cr1901>
firefrommoonlight: Ahhh, I thought there was something special that causes DMA to be unimplementable soundly w/o a perf penalty
<re_irc>
<@firefrommoonlight:matrix.org> use `static` arrays for DMA writes, and `static mut` for DMA reads, as a default. Whenever you modify them, make sure a transfer isn't running.
<re_irc>
<@ioctl:matrix.org> Hi, something funny is happening with me. I have a st7789 (generic module) display connected to my nRF52840-DK and only after I halt the program the image is drawn in the display (using probe-rs to run). Any ideas what could be causing this? Sounds like something simple.. but I cannot figure out myself
<re_irc>
<@thejpster:matrix.org> Imagine we have a function 'memcpy'. Because the function doesn't end until the copy is complete, the borrow is straightforward.
<re_irc>
<@thejpster:matrix.org> Now imagine we have some function 'memcpy_start' that runs 'in the background' in some fashion. How do you teach rust but to touch the buffers until the copy is complete? You can return an object that holds a reference to the buffers. But what if someone does a mem::forget? That won't stop the DMA.
<re_irc>
<@thejpster:matrix.org> Conceptually it doesn't matter if you asked the hardware to copy the data, or if you asked the OS to do it.
<re_irc>
<@thejpster:matrix.org> Some 'other' thing is touching your data and we just have to tell the compiler enough about it that a) it's happy and b) it's safe.
<re_irc>
<@thejpster:matrix.org> Or yeah, just use static buffers and pinky swear to the compiler that there's nothing to worry about
<re_irc>
<@firefrommoonlight:matrix.org> thejpster:matrix.org: Don't do that!
<re_irc>
<@firefrommoonlight:matrix.org> What if I set `n` to 10, which is needs to be. But what if someone changes it to 5? Then it'll be wrong
<re_irc>
<@firefrommoonlight:matrix.org> I guess that's a bit of a strained analogy, but it's what I think whenever I read things like that
<re_irc>
<@firefrommoonlight:matrix.org> And errors of the form that's demonstrating are tougher to find in complex programs
<re_irc>
<@firefrommoonlight:matrix.org> Or with multiple people in a team
<re_irc>
<@firefrommoonlight:matrix.org> I guess at the root of this is that you can't rely on the compiler to catch these sorts of errors, but you can other classes of error
<re_irc>
<@firefrommoonlight:matrix.org> And, this complicates using third party libraries
<re_irc>
<@firefrommoonlight:matrix.org> Hopefully the `unsafe` key word you use (eg when getting an array's pointer to pass to a DMA register, or access a static) should be a warning that "Hey, make sure you're not stepping on another piece of code here!". Ie don't train yourself to ignore it as boilerplate