<Lumpio[m]>
Hmm, I don't think that's quite correct. I think what I was trying to say that if you call it periodically it needs to be often enough, and that there's max latency of about 10ms allowed between calls. The main reason is that control transfers will timeout if you're too slow to respond.
<Lumpio[m]>
At any rate interrupts are the correct way, but they also are not allowed to have too much latency.
<dav1d>
If I panic due to an unwrap etc. is it possible to automatically reset the chip (using an esp32s3)? I see the esp-backtrace crate has a halt-cores feature, but that doesn't do what I want.
<dngrs[m]>
Resetting an esp chip is definitely doable but I don't know how without reading the TRM
mabez[m] has joined #rust-embedded
<mabez[m]>
<dav1d> "If I panic due to an unwrap etc...." <- Using a watchdog typically does this, but a reset feature to esp-backtrace would be accepted if that's something you want to add :)
<dav1d>
I think I can just call esp_hal::reset::software_reset() in my own panic handler
<dav1d>
mabez[m], watchdog? 👀
<dav1d>
Thanks, looks like I have something to read up
<dav1d>
Hopefully I can set up something like that without esp-idf
<dav1d>
Watchdog works as expected, nice! Thanks for the tip
<dav1d>
Not sure how to add this to esp-backtrace, doing it via a feature flag feels dirty
AtleoS has joined #rust-embedded
hmw has quit [Quit: Bye.]
hmw has joined #rust-embedded
<dngrs[m]>
if I want to use cargo test at all, there's no reasonable way around making a workspace, right?
<cr1901>
Lumpio[m]: Okay, that makes more sense re: the latency. I ask b/c I'm playing with an atsamd21, and AFAICT, the USB handler is definitely _not_ firing every 10ms (only when events actually happen)
<cr1901>
So poll is only called if there's an event or I have forcefully set the USB handler to pending (to kickstart IN xfers)
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
<vollbrecht[m]>
<dngrs[m]> "if I want to use cargo test at..." <- if you are talking about running the test on your host target. Otherwise you may try to look into `embedded-test`
<dngrs[m]>
yeah, the former
<Lumpio->
cr1901: Yes if there's no traffic there's nothing to time out so it should be fine. If the atsamd driver written so that IN transfers require a manual pend/poll? That definitely wasn't my intention originally but I didn't write that driver
<cr1901>
Lumpio-: At the very least, if I want everything purely interrupt driven, so far I have to make a heapless spsc queue that the main thread puts chars in, and the USB interrupt thread takes chars from.
<cr1901>
If there's no USB activity when the main thread puts chars in, I have to set the USB thread to pending and force e.g. the serial device to start writing
<cr1901>
this will trigger additional interrupts until there's nothing left to send
<dirbaio[m]>
<dngrs[m]> "if I want to use cargo test at..." <- no, why? you can make a crate work on the host and on the embedded target at the same time if you're careful, then you don't need a workspace
<cr1901>
(I haven't worked out how to handle the OUT side of things, which has the lovely property of "if I use a second heapless spsc queue that the interrupt thread puts chars in, there's always the possibility that queue is full and I have no choice but to drop chars)
<Lumpio[m]>
Well that possibility is always there with any sort of buffer or queue if you don't have infinite memory.
<Lumpio->
The way I intended usb-device to be used was that you would use Endpoint::write or SerialPort::write or such methods from wherever your data originally comes from, and you would use Endpoint::read or SerialPort::read or such in the interrupt handler, after the poll
<Lumpio->
In hindsight it's kind of cumbersome to use because you have to mutex everything
* cr1901
nods, tbf that's how I would've done it or similar
<Lumpio->
If some driver doesn't support that then I guess the intention wasn't clear ehough heh
<Lumpio->
I think some drivers ended up putting more logic in "poll" due to hardware differences so they might require you to call it more
<cr1901>
I'm trying to remember what tinyusb does (I wrote a backend for it several years ago), but if the application didn't schedule a packet to be received (i.e. not expecting an OUT xfer), then the intention is that the packet stays in the hardware FIFO/buffer (so the device sends NAK back to the host for further OUTs) and the interrupt is ignored.
<cr1901>
At least that's my recollection.
<Lumpio->
The interface in usb-device isn't _the best_ for that it's possible to implement, as long as you can space a packet's worth of memory
<Lumpio->
Solution being "if your queue is full, don't call read" - but then you have to arrange for it to be called later
<cr1901>
If I do everything interrupt-driven in usb_device, I can't keep the packet in the hardware FIFO/buffer _and_ simultaneously ignore interrupt (at least AFAICT)
<Lumpio->
That's platform dependent I guess, whether that interrupt is level triggered or not
<cr1901>
>but then you have to arrange for it to be called later <-- yup, and that means putting the Serial<UsbBus> device in a refcell :D
<cr1901>
Ooooh, I didn't think of that
<Lumpio->
I think on STM32 where I originally made it from you could clear the interrupt flag and it would not fire again until something new happened.
<cr1901>
Uhhh, I don't know if ATSAMD21's interrupts are level or edge triggered (presumably level, seeing that if I comment out serial.read(), and then type a char in my terminal, the app grinds to a halt :D)
<Lumpio->
Often there are two levels to this
<Lumpio->
There's the interrupt signal that requests the interrupt, and the interrupt flag that gets set
<cr1901>
In tinyusb's case, at least for msp430, there's a register separate from the interrupt flag that tells you in order "here's the actual interrupts that need handling, based on the masks"
<Lumpio->
The flags are usually level triggered in my experienc
<Lumpio->
But yeah masking the interrupt via an enable bit would also work
<dngrs[m]>
<dirbaio[m]> "no, why? you can make a crate..." <- hmmm, I suppose I can't specify `[build] target =` in `.cargo/config.toml` then though? Anyway, already switched to workspace so don't have the build errors anymore, but I got a lot of them
<cr1901>
so e.g. if an OUT endpoint gets a packet without you expecting an xfer, and you get an interrupt anyway due to a different source, you won't attempt to handle the OUT endpoint interrupt condition
<cr1901>
as part of collecting interrupt sources due to the different source*
<cr1901>
Idr what STM32 does
<cr1901>
Lumpio-: It was probably a mistake for me to think I could write a USB app w/o not getting bogged down in internals (especially after several years), but tyvm for answering my q's :)
<Lumpio->
The original intention of usb-device was to abstract all that away but it didn't quite end up working and there's a lot of cruft around it required now
barnabyw[m] has quit [Quit: Idle timeout reached: 172800s]
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
AdamHott[m] has quit [Quit: Idle timeout reached: 172800s]
<dav1d>
I currently have a single embassy task which handles http traffic (server) for me: https://p.dav1d.de/9gE.rs - now I ran into the issue that it cannot serve multiple requests simultaneously, because while the request is active there is no socket listening. My idea was to just spawn the task 3 times as is (see paste), is that the right way to handle
<dav1d>
this? In theory I could build something like FuturesUnordered, maybe "fork" off the request handler while immediately re-opening the listen socket, etc. Any advice how I should handle this?
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room , meeting time again! agenda doc is https://hackmd.io/UQEgr7P8SlGDWz2-cLD02g, I'm still updating it but please add anything you'd like to talk about or discuss and we'll start in a few minutes
<adamgreig[m]>
ok, let's start! couple of announcements, cortex-m-rt 0.7.4 is finally out with a few new features like the ability to zero all the ram at startup and to disable the hardfault trampoline generation
<adamgreig[m]>
and svd2rust 0.33.1 is also out
<adamgreig[m]>
and i see also microbit 0.14 and nrf*-hal 0.17.1 released! 🎉
<bartmassey[m]>
Thanks to @qwandor for a crazy amount of work to get the microbit and nrf stuff released!
bartmassey[m] has joined #rust-embedded
<adamgreig[m]>
yea, looks great, well done! glad you were able to get that over the line
therealprof[m] has joined #rust-embedded
<therealprof[m]>
New maintainers at work.
<bartmassey[m]>
It all has dependabot support now too, so it should be a bit more stable / maintainable.
<JamesMunns[m]>
it's like `libusb` but in Rust and pleasant to use!
<adamgreig[m]>
get ready to be delighted
<newam[m]>
Ahhh, awesome, I'll have to check that out, thanks!
<dirbaio[m]>
nusb 💯👌
<JamesMunns[m]>
(and not just a wrapper, but a full impl, so no weirdness)
<JamesMunns[m]>
dirbaio[m]: yeah, nusb has been awesome to use, and thanks to dirbaio and henrik_alser for awesome embassy examples of how to use it from both sides!
<adamgreig[m]>
all pure rust, and still cross platform too
<adamgreig[m]>
ok, let's crack on with this agenda
<adamgreig[m]>
there's a question from the meeting discussion topic about whether ExclusiveDevice should document if the CS pin must be low when the device is created or whether it should set the pin low itself, https://github.com/almindor/mipidsi/issues/129#issuecomment-2067713648
<bartmassey[m]>
<JamesMunns[m]> "See https://docs.rs/postcard-rpc..."; <- adamgreig eldruin : Henk and I would like to resolve the PR queue in the Discovery Book repo. We'll start by adding reviews, but eventually may need permission to merge?
<adamgreig[m]>
uh, high*
danielb[m] has joined #rust-embedded
<danielb[m]>
must be high*
<adamgreig[m]>
* there's a question from the meeting discussion topic about whether ExclusiveDevice should document if the CS pin must be <del>low</del>high when the device is created or whether it should set the pin <del>low</del>high itself, https://github.com/almindor/mipidsi/issues/129#issuecomment-2067713648
<dirbaio[m]>
yeah... constructor should set it high
<dirbaio[m]>
costs us nothing and avoids an annoying footgun
<adamgreig[m]>
documenting that it must already be high costs even less, right? but yea i think just setting it high is probably fine too
<dirbaio[m]>
that means we have to add where CS: OutputPin, to fn new()... but I guess that's ok?
<adamgreig[m]>
it might still be worth documenting that the pin should generally be created as high
<danielb[m]>
document for 0.1.x, set for 0.2.x?
<adamgreig[m]>
as otherwise there will be a glitch every startup, even if most devices are ok with that
<dirbaio[m]>
danielb[m]: uhh i'd argue setting it high is a bugfix
<adamgreig[m]>
but since it's easy for end users to get wrong, and the bug is typically in end-user code, it seems nice to be defensive about it
<dirbaio[m]>
hence not breaking
<dirbaio[m]>
why'd you want it to not set it high?
<dirbaio[m]>
what breakage could that cause?
<danielb[m]>
dirbaio[m]: with an API change
<diondokter[m]>
Technically breaking, but in practice? I don't think anyone has code where it isn't an output pin
<dirbaio[m]>
dirbaio[m]: ahh this is a breaking change, yes 🤦♂️
<diondokter[m]>
If they have it with CS not being output pin, then that's probably a bug in their code?
<dirbaio[m]>
ughhhh
<dirbaio[m]>
I've never understood this "alleged best practice" of adding the where bounds only when needed
<dirbaio[m]>
if we had added them to the struct we wouldn't have this issue
<dirbaio[m]>
* this issue now
<diondokter[m]>
dirbaio[m]: Yeah... Only saves a bit of boilerplate
<danielb[m]>
isn't set_high also fallible, so the return type should change, too?
<thejpster[m]>
the useful SpiDevice impl requires CS: OutputDevice, so just add it as a bound on fn new and be done with it.
<dirbaio[m]>
the alleged advantage is future evolution. Like, all your struct methods require CS: OutputPin today, but what if you want to add one tomorrow that doesn't, expanding the functionality of the struct? if you added where CS: OutputPin to the struct you wouldn't be able to, and removing it would be breaking ...
<dirbaio[m]>
thejpster[m]: yeah, the issue is it's breaking. so it'd need `embedded-hal-bus 0.2`
<dirbaio[m]>
maybe we should just do that, and release embedded-hal-bus 0.2, yep
<dirbaio[m]>
* the alleged advantage is future evolution. Like, all your struct methods require `CS: OutputPin` today, but what if you want to add one tomorrow that doesn't, expanding the functionality of the struct? if you added `where CS: OutputPin` to the struct you wouldn't be able to, and removing it would be breaking ...
<dirbaio[m]>
but ... it also hurts future evolution, as seen in this case 🤦♂️
<diondokter[m]>
I don't really see why a version 0.2 would be that bad. People only should use it though the eh traits anyways
<thejpster[m]>
it's only theoretically breaking - it only breaks people who were holding it wrong. And semver doesn't apply to 0.x releases anyway.
<dirbaio[m]>
we made it a separate crate exactly for this reason
<adamgreig[m]>
so i think you'll end up with mixed versions, but that's OK?
<dirbaio[m]>
we can bump it as much as we want without breaking the ecosystem
<adamgreig[m]>
thejpster: semver does apply to 0.x releases in rust
<diondokter[m]>
thejpster[m]: Depends... Set high returns a result, so the new function should maybe also return a result
<diondokter[m]>
Like <a data-mention-type="user" href="https://matrix.to/#/@bugadani:matrix.org" contenteditable="false">@danielb</a> said
<adamgreig[m]>
right, HALs provide implementations of the 0.1 version but anyone consuming implementations should be going through the e-h traits so hopefully it doesn't break anything, just takes a while to roll out
<diondokter[m]>
Isn't there an error type with fields for both spi and cs errors?
<thejpster[m]>
adamgreig[m]: the docs tell you how cargo behaves, but the [semver spec](https://semver.org/#spec-item-4) is quite clear that 0.x is a free for all
<dirbaio[m]>
it's weird for new() to return that, since it can't do any actual spi stuff
<adamgreig[m]>
how cargo behaves is what matters here though
<thejpster[m]>
but I'm going to shut up becuase I have agenda items at the end, and we're 34 minutes down already
<dirbaio[m]>
also gpio is usually infallible and spi usually isn't
<adamgreig[m]>
since it's what's deciding what is compatible or not
<diondokter[m]>
dirbaio[m]: Yeah, but say I'm wrapping the bus error in my own error struct. With only returning the CS error I now need to make a new error variant
<dirbaio[m]>
but you probably are constructing the SpiDevice and using it in very different places
<dirbaio[m]>
you usually don't construct it on the fly
<diondokter[m]>
That's true though
<dirbaio[m]>
also gpio is usually infallible, so you'd be able to do .new(...).into_ok() (when that's stable 🫠)
<dirbaio[m]>
dirbaio[m]: context on this is: it's a "bad" mutex that fails with `Busy` if you try to lock it twice, but it's sort of needed to use SpiDevice with "classic" (not async) RTIC resources
<dirbaio[m]>
* RTIC resources. if you "hold it right" RTIC guarantees "busy" errors never happen.
<dirbaio[m]>
so
<dirbaio[m]>
seems like a desirable thing IMO
<diondokter[m]>
dirbaio[m]: Oh, right! I always forget this API
<dirbaio[m]>
possible concerns is: it's too niche, or too easy to misuse
<adamgreig[m]>
it's clear that it's useful in RTIC, but is it useful elsewhere? could RTIC provide it?
<diondokter[m]>
I think it'd be fair to document it with 'probably not what you want to use if you're not using RTIC'
<adamgreig[m]>
the only way to use it is to magically guarantee from outside rust that you won't try to lock the mutex while already locked, right?
<dirbaio[m]>
it could be useful if you reaaaally don't want a CS and are OK with "busy" errors because you can try again later...
<dirbaio[m]>
* a CS because realtime, and are
<adamgreig[m]>
but conceivably you might have some other external synchronisation or reason to be sure that's the case...
<dirbaio[m]>
* it could also be useful, * a CS because realtime, and are
<dirbaio[m]>
adamgreig[m]: yea this is the case with RTIC locks
<adamgreig[m]>
oh, yea, since it's not a panic you can at least catch it and do something I guess
<dirbaio[m]>
dirbaio[m]: in this case you won't have any external lock, you'd just deal with Busy errors
<adamgreig[m]>
is AtomicDevice the best name for it?
<adamgreig[m]>
I guess it does use an atomicbool for locking, so ok :P
<bartmassey[m]>
It's the coolest name for it…
<adamgreig[m]>
it is pretty cool
<rmsyn[m]>
intimidating name...
<dngrs[m]>
DemonCore
<adamgreig[m]>
an attractive nuisance
<dirbaio[m]>
AtomicDevice feels ... okay to me
<adamgreig[m]>
ok, so to wrap up, it sounds like "have exclusivedevice set cs high and document that it should be high and will be set high, do a 0.2 release with that change" and "merge atomicdevice"?
<adamgreig[m]>
I guess atomicdevice can go into a 0.1 release first
<therealprof[m]>
Atomice
<therealprof[m]>
Saves a few letters. 😛
<adamgreig[m]>
i haven't read through the docs in the pr fully but i'd want them to be clear where it's expected to be used
<adamgreig[m]>
as from a pure API signature point of view it will surely be tempting, and it will Just Work for a while until you actually hit a race? but I guess you still have to handle the error one way or another, so...
<adamgreig[m]>
a10e
<dirbaio[m]>
yea the "busy" error will be a clue this device needs "special care"
<dirbaio[m]>
unless you're doing "yolo .unwrap()"
<adamgreig[m]>
yea
<diondokter[m]>
Is there another way?
<diondokter[m]>
:P
<danielb[m]>
dirbaio[m]: unwrap should have been called yolo()
<adamgreig[m]>
I guess the RTIC users will be unwrapping?
<dirbaio[m]>
just the Busy error, not others (?)
<dirbaio[m]>
anyway... that's all for e-h from me. Will open PRs for these things now (and release 0.1.1 and 0.2.0)
<adamgreig[m]>
<bartmassey[m]> "adamgreig eldruin : Henk and I..." <- bartmassey: sorry, didn't see this thread (?), that sounds good though. you'd need to join the resources team to merge but that can happen.
<adamgreig[m]>
thanks ❤️
<adamgreig[m]>
ok, thejpster do you want to run through your points now?
<thejpster[m]>
ok
<thejpster[m]>
I installed the cortex-m-quickstart and it gave me cortex-m 0.6
<thejpster[m]>
assuming that's not by design, maybe we should update it.
<thejpster[m]>
second, I spent a very very long time trying a very large set of -C target-feature and -C target-cpu flags with the latest nightly Rust.
<thejpster[m]>
Is it useful to update the target documentation to tell people how to support various different Arm CPU cores beyone the architecture baseline
<thejpster[m]>
because woah nelly, the auto vectorisation is incredible
<thejpster[m]>
there are DSP instructions for saturated adds that Cortex-M33 people (if they have the optional DSP extension), M55 and M85 people are missing out on
<adamgreig[m]>
yes please, that would be really good
<adamgreig[m]>
the target docs got a small update recently
<thejpster[m]>
there are vector integer operations that will operate on 8 integers simultaneously
<thejpster[m]>
and vector float operations that will operate on four floats simultaneously
<adamgreig[m]>
and sadly the updated ones we made a while back never got merged to upstream, so there might be some useful snippets from there too
<adamgreig[m]>
but that page seems a great place to document them and be able to point people at
<diondokter[m]>
If this gets documented somewhere, it might be useful to link to it from a well-visited place. Maybe the readme of the cortex-m crate?
<thejpster[m]>
This repo contains a program which builds a sample with a bunch of flags (in targets.txt), dissassembles them all, and then shasums them to find out which binaries are exactly the same
<adamgreig[m]>
thejpster[m]: yep for sure, and to use probe-rs instead of openocd I think
<thejpster[m]>
it can then basically tell you which flags were useless
<bartmassey[m]>
adamgreig[m]: Thanks! We'll start by getting stuff reviewed to merge and then bug you here if that's ok.
<thejpster[m]>
the README contains my proposal for the new target docs
<dirbaio[m]>
(do we really need e-h-bus 0.1.1? people whow ant AtomicDevice can update to 0.2, the cost of updating is almost zero)
<thejpster[m]>
bonus points if you can find me a Cortex-M55 with Integer Helium but no FPU, which ARM tells me can exist.
<bartmassey[m]>
gtg next meeting thanks all! 👋
<adamgreig[m]>
dirbaio[m]: yea true, seems fine then
<adamgreig[m]>
Adam Hott: do you want to talk about the tooling thing in the last few minutes?
<AdamHott[m]>
Yes, I suppose it goes a higher level, I'd like to get involved with updating some of the documentation, whether thats the Discovery Book or the openocd/gdb/probe-rs stuff
<AdamHott[m]>
Just need some guidance on what's important and who to work with
<AdamHott[m]>
If it's the tooling stuff for probe-rs, I just need a rough outline of what to research
<JamesMunns[m]>
* if you think its important, do it!
<JamesMunns[m]>
* if you can't find someone to review/merge it, post here we will find someone!
<dirbaio[m]>
lol AtomicDevice is unsound. it has one busy flag per device, it should have a shared one for the whole bus
<JamesMunns[m]>
there's no "boss" of pretty much any of this, if it seems right just do it!
<AdamHott[m]>
what do yall think?
<AdamHott[m]>
ok there was a lag in Element
<AdamHott[m]>
ok, I'll start with a write up for openocd/gdb/probe-rs!
<AdamHott[m]>
that's all I got!
<AdamHott[m]>
I gotta go everyone good night take care!
<thejpster[m]>
should I open a PR with the target docs as proposed?
<adamgreig[m]>
maybe even start by getting that tooling page to mention probe-rs and what it can do, i.e. that it can replace openocd and gdb, handles programming and print-style debugging and also interactive debuggign
<adamgreig[m]>
and then other sections of that book - like semihosting and gdb - could be updated and eventually removed
<adamgreig[m]>
thejpster: as a subsection called like "compiler flags" or something?
<adamgreig[m]>
maybe add a table for thumbv6 like you have in thumbv7m-none-eabi just for consistency?
<adamgreig[m]>
and perhaps explain how to set the target-cpu and target feature flags?
<adamgreig[m]>
or link to something about it
<thejpster[m]>
I should probably note the feature flags are unstable (although they are required for target-cpu to be of any real use)
<adamgreig[m]>
reading through it, maybe it would be helpful if it said like "Optional DSP extensions - dsp feature flag" (i.e., adding "feature flag" after the monospaced feature flags)
<adamgreig[m]>
since other monospaced things are CPU names, or are just Rust types
<adamgreig[m]>
looks like good data though
<adamgreig[m]>
so in the end target-cpu=cortex-m7 enables double FPU use, and you have to opt-out if you don't want it?
<thejpster[m]>
yes
<thejpster[m]>
LLVM policy is target-cpu goes all-in
<adamgreig[m]>
cool, well that's simpler at least
<thejpster[m]>
-C target-cpu=cortex-m7 enables the double precision FPU even on the eabi target
<JamesMunns[m]>
thejpster[m]: "don't lie to me I KNOW you have an FPU!"
<thejpster[m]>
because wanting to put args in float registers != wanting to use the FPU
<thejpster[m]>
or, putting args in d0 requires an FPU, but an FPU does not require putting args in d0
<thejpster[m]>
and pre-compiled C code exists that you might want to remain ABI compatible with
<thejpster[m]>
anyway, feel free to send PRs :)
<adamgreig[m]>
I'm happy to do a quick pr this evening with some wording suggestions if you like? it would be great to get this into the upstream target doc
<adamgreig[m]>
thejpster[m]: shame it's not `cortex-m7f` then...
<adamgreig[m]>
anyway that's all for this week's meeting, thanks everyone!
<thejpster[m]>
you could try and propose that, but it's an LLVM patch not a Rust patch
<rmsyn[m]>
<3
<thejpster[m]>
arm compiler has cortex-m55, cortex-m55.fp, cortex-m55.mve, cortex-m55.mve.fp, etc, iirc
<thejpster[m]>
also "cortex-a" is a broad church, from the A32 Cortex-A8 to the A64/A32 Cortex-X3
<adamgreig[m]>
if someone was interested in bringing it back and wanted to join the cortex-a team that sounds ok, but generally yea, not much enthusiasm or use from people who were around
<thejpster[m]>
I wonder how well aarch64-cpu will work when the Aarch64 Cortex-R82 turns up
<thejpster[m]>
Aarch64 is an execution state which is now implemented by two different Arm Architecture profiles
<thejpster[m]>
and honestly I wouldn't rule out an Aarch64 Cortex-M at some point
<rmsyn[m]>
ok, at the risk of taking on too much, i'd be interested to start poking around at it. having a HAL for A72/A53 based devices would be nice.
<thejpster[m]>
unfortunately a Cortex-A72 includes very little hardware - it's all SoC specific.
<thejpster[m]>
IIRC not even the interrupt controller is standard
<thejpster[m]>
(hence devicetree was invented to explain to the Linux Kernel what the hell it just booted on)
<rmsyn[m]>
lol, sounds like a nightmare
<thejpster[m]>
there may be useful abstractions for the MMU, but they are only really useful if you want to write a kernel
<JamesMunns[m]>
tho to be clear, this doesn't stop you from writing a HAL. It just does mean that many HALs will need a bit more "custom" work than many cortex-m HALs need.
NickStevens[m] has joined #rust-embedded
<NickStevens[m]>
Alternately you could utilize the device tree as an input for the HAL - this is actually the approach that U-boot took to avoid having to maintain the myriad configurations of Cortex-A CPUs. I haven't done anything bare-metal on Cortex-A but I've done a lot of Linux driver work that operates at the hardware level on those chips, so I might be helpful in some cases.
<NickStevens[m]>
Device tree itself is a pretty much just a binary configuration format with some features that make it useful for configuring hardware, it's not limited to the Linux kernel.
geky[m] has joined #rust-embedded
<geky[m]>
Isn't this also how Zephyr works on cortex-m? IIRC they have a device-tree, but not sure if it's in name only
<NickStevens[m]>
Ah, I didn't know Zephyr used it too! Yup, exactly the same idea, just that the Zephyr configuration nodes might not line up 100% with what the Linux node names are.
<dirbaio[m]>
it's quite different
<dirbaio[m]>
it's mostly just same syntax
<NickStevens[m]>
That's what I was trying to get at - device-tree is a file format with a defined syntax and use-agnostic tooling. But what people often call "device trees" are the configured values for a Linux kernel / U-boot / Zephyr. An unfortunate naming overlap.
<NickStevens[m]>
what format is the device tree? It's device tree format 🤦♂️
<dirbaio[m]>
so, "json but with weird syntax, and inheritance" :P
<NickStevens[m]>
don't forget comments
<NickStevens[m]>
which you'll need for the bounty of random addresses in most files