<spinfast[m]>
thejpster: i'm almost there... regmap described in yaml, with codegen from chiptool... and a nice little layer to write a wm8960 driver in
<spinfast[m]>
* thejpster: i'm almost there... regmap described in yaml, with codegen from chiptool... and a nice little layer to write a wm8960 driver in
<spinfast[m]>
so hopefully I can just finish writing up my regmap and have svd2rust/chiptool like register manipulations
<spinfast[m]>
* register manipulations (with some minor corrections), the idea seems to mostly pan out
nex8192 has left #rust-embedded [Error from remote client]
starblue has quit [Ping timeout: 240 seconds]
paulyoung[m] has quit [Quit: Idle timeout reached: 172800s]
starblue has joined #rust-embedded
GolfMike32 has joined #rust-embedded
m5zs7k has quit [Ping timeout: 260 seconds]
m5zs7k has joined #rust-embedded
GolfMike32 has quit [Quit: Client closed]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Read error: Connection reset by peer]
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
nex8192 has joined #rust-embedded
M9names[m] has quit [Quit: Idle timeout reached: 172800s]
Lumpio[m] has quit [Quit: Idle timeout reached: 172800s]
nex8192 has left #rust-embedded [Error from remote client]
MattiasGrnlund[m has quit [Quit: Idle timeout reached: 172800s]
nex8192 has joined #rust-embedded
m5zs7k has quit [Ping timeout: 264 seconds]
m5zs7k has joined #rust-embedded
KarthiR[m] has joined #rust-embedded
<KarthiR[m]>
Hello, I am working on a project where im having to work with riscv64imac static libraries built from C for the riscv ISA version 2.0. For the rust part of the project, I've added riscv64imac target through rustup to cross compile rust code for riscv but it builds libraries for riscv ISA version 2.1. Because of this, I'm facing a isa version mismatch error at the linking stage when i try linking the C generated static libraries
<KarthiR[m]>
with the rust generated ones. To resolve this, i would like to roll my rust target back to riscv isa 2.0 version ensuring compatibility. Wanted to check if it would be possible for me roll back the isa version of my target?
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<jessebraham[m]>
Could somebody who is smarter than me please explain what's going on with these magic numbers in the `DelayNs` trait default method impls? 😁
<diondokter[m]>
Seems to be the first number below u64::MAX that is divisibile by 1000
<diondokter[m]>
Likely because to go from us to ns, you have to multiply by 1000
<jessebraham[m]>
Oh, yeah. I assume you mean `u32::MAX`? But that would make sense haha
<jessebraham[m]>
Thanks
<diondokter[m]>
Whoops, u32::MAX
<diondokter[m]>
yeah
<adamgreig[m]>
Yea, previously we just did "ms" iterations of delaying 1000us, but that's not only strictly worse, it's really bad for 1000ns if something would have to round to more than 1us
lockna[m] has quit [Quit: Idle timeout reached: 172800s]
dsvsdveg[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]>
yeah I should've written some comment at least 🤣
<dirbaio[m]>
thanks james
<mabez[m]>
thejpster: Sorry for the ping, do you think you could get someone to give some feedback in https://github.com/knurling-rs/defmt/pull/796? It would be really cool to have defmt-test for some other architectures
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<ryan-summers[m]>
Has anyone managed to software-reset into the DFU for the STM32H7 series chips? I've done it on the F4, but replicating it for the H7 doesn't seem to be working as I'd hope
Ecco has joined #rust-embedded
<Ecco>
Hi!
<spinfast[m]>
would rtic be possible on an armv7a gic?
IlPalazzo-ojiisa has joined #rust-embedded
<spinfast[m]>
* armv7a gic? actually let me ask in rtic-rs
<spinfast[m]>
* <del>would rtic be possible on an armv7a gic?</del> actually let me ask in rtic-rs
<Ecco>
I'd like to contribute a new HAL for an unsupported STM32 chip
<Ecco>
Who should I get in touch with?
<Ecco>
I looked at a bunch of HALs for STM32s, and it looks like there's a lot of code duplication
<Ecco>
the PAC code is well DRYed-up (a single repository generates all the STM32 PAC crates)
<Ecco>
but for HALs, well…
<spinfast[m]>
I think embassy partially deals with this a bit better than stm32-hal does, but stm32-hal is probably like the original hal in rust?
<Ecco>
(even though the chips are very similar)
<dirbaio[m]>
which stm32 chip?
<Ecco>
WBA
<dirbaio[m]>
WBA is already supported in embassy-stm32
<spinfast[m]>
Ecco: the people to discuss with are adamgreig for hal, dirbaio for embassy
<dirbaio[m]>
examples are minimal but the API is the same across all stm32 chips, so you can easily port from examples for other stm32 chips
<Ecco>
So, I've been doing a lot of STM32 development in C/C++
<spinfast[m]>
dirbaio: do you find there's a lot of slight IP block variations in st parts? imxrt parts have been remarkably consistent for the 10xx series
<Ecco>
But kind of new to rust
<dirbaio[m]>
I haven't tested the radio though
<Ecco>
And… I'm kind of struck by the fragmentation
<Ecco>
dirbaio[m]: the radio uses a proprietary ST blob
<Ecco>
it ships as a static library with C headers
<Ecco>
absolute black box
<dirbaio[m]>
there's support for the WB radio, if the WBA radio is similar it should be easy to get working
<spinfast[m]>
that's pretty common
<Ecco>
dirbaio[m]: it's not really
<dirbaio[m]>
is it not like the WB radio where the blob runs in a 2nd core?
<Ecco>
well, it's not documented at all
<Ecco>
I guess that's what happens behind the scenes?
<spinfast[m]>
* pretty common that the radio is driven by a blob
<Ecco>
but it's just not documented at all
<Ecco>
you don't even get to know if there's a second core and if it's flashed or anything
<Ecco>
just… load the blob and go
<Ecco>
so now
<Ecco>
It seems to me like the Rust ecosystem is masively fragmented
<dirbaio[m]>
in WB there's 2 parts:
<dirbaio[m]>
- the "client" lib runs in your core. It's part of ST's C HAL, it's not closed source, embassy-stm32 contains a Rust port of it that's known-working with the WB's
<dirbaio[m]>
- the blob runs entirely on the 2nd core. You don't link it with your firmware at all
<Ecco>
dirbaio[m]: interesting
<Ecco>
My understanding of WBA is that there's a C api that comes with a static lib. You don't get to know any of what happens behind the scenes.
<Ecco>
I mean, at least it's easier to flash since you don't need to worry about a second firmware for the radio core
<spinfast[m]>
Ecco: In what way exactly
<Ecco>
But truth be told I haven't even tried to mess around w/ the radio just yet
<Ecco>
spinfast[m]: fragmented? Well, there's alike a million different RTOSes, a bunch of people apparently reinventing the same thing (tockos, embassy, embedded-hal)
<Ecco>
it's… a lot to navigate
<Ecco>
And I think it's normal, the ecosystem is just not mature enough, that's totally expected
<Ecco>
it's just hard to figure out what to use
<Ecco>
Embassy looks kind of great, but that's yet another option!
<spinfast[m]>
you've listed 3 things, if I were to point at the number of C RTOS+HAL options and the pros/cons of them we'd be here all day
<Ecco>
haha true
<Ecco>
I guess that I just *wished* there was an obvious solution that everyone was using
<Ecco>
now I need to study each one and choose. that's… a lot of work and I'm lazy :-D
<spinfast[m]>
tock, embassy, and the hal have different goals in mind. Tock is trying to be more like a traditional OS with memory protection and syscalls and everything, embassy is basically hal+executor built around async/await, stm32-hal is probably closest to like a vendor sdk
<Ecco>
hmm, makes sense!
<Ecco>
Thanks for the insight`
<Ecco>
I have no idea what to chose tho
<spinfast[m]>
well in the future maybe less choice will be necessary, assuming the hal's start implementin the async APIs
<spinfast[m]>
s/implementin/implementing/
<spinfast[m]>
* well in the future maybe less choice will be necessary, assuming the hal's start implementing the async APIs in embedded-hal
<dirbaio[m]>
the stm32xxxx-hal crates are older than embassy, they started with an approach that's "copy paste everything for each stm32 family"
<spinfast[m]>
I think they're like the oldest hal around?
<dirbaio[m]>
there's 21 families, turns out maintaining 21 copies of the same code is not maintainable
<dirbaio[m]>
and different stm32xxxx-hal crates are maintained by different people, so they make different API design choices so porting code from one family to another is not always easy even if the underlying peripheral version is the same
<dirbaio[m]>
the stm32xxxx-hal crates for the more popular chips (f1, f4, h7...) do see good maintenance, there's others that are less maintained or incomplete, and for newer chips (like C0, U5, WBA) there's no stm32xxxx-hal crate at all
<dirbaio[m]>
fun fact, embasy-stm32 started as wrappers on the stm32xxx-hal crates
<dirbaio[m]>
then someone PR'd embassy-stm32f0 copypasting everything
<dirbaio[m]>
there was embassy-stm32f4 wrapping stm32f4xx-hal adding async support
<dirbaio[m]>
then embassy-stm32l0...
<dirbaio[m]>
then I nope'd out because there was no way I was going to maintain 20 copypastes of the same code
<dirbaio[m]>
and started the current approach of building a single HAL supporting all stm32 families
<dirbaio[m]>
this is why there's fragmentation, basically historical reasons
<spinfast[m]>
I mean that's definitely a benefit to mono-repoing these things... it becomes beneficial to create IP block drivers rather than part family drivers
<spinfast[m]>
and some IP blocks are used across companies entirely (lots of cadence/synopsis ip blocks...)
<spinfast[m]>
now why does st have like 5 different dma blocks is what always confused me
<spinfast[m]>
bdma/gpdma/dma/mdma
<dirbaio[m]>
and DMAMUX
<spinfast[m]>
nxp managed to create one block that doesn't suck (edma) and reuse it everywhere
<dirbaio[m]>
and several versions of DMA/BDM
<dirbaio[m]>
s/BDM/BDMA/
<spinfast[m]>
* it everywhere that I've seen
<spinfast[m]>
still... better than the brokenness that is atmel sam IPs
<dirbaio[m]>
lol
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
I split off as well; the unifying reason was part of it; primary reasons were I had trouble with the APIs, and getting feature requests merged was painful
<firefrommoonligh>
s/feature/PRs/, s/requests//
<firefrommoonligh>
* I split off as well; the unifying reason Dirbaio mentioned re multi-family sypport was part of it; primary reasons were I had trouble with the APIs, and getting PRs merged was painful
nex8192 has left #rust-embedded [Error from remote client]
<Ecco>
Does embassy have any releases / crates ?
<Ecco>
Oh, also, is it possible to use just the STM32 HAL of embassy on stable rust?
<Ecco>
Or would that require nightly?
<GrantM11235[m]>
<Ecco> "Oh, also, is it possible to..." <- Yes. You can even use the async executor too, but you don't have to
<Ecco>
I'm trying to build a sample project with stable rust and embassy-stm32
<Ecco>
it doesn't seem to be possible
<Ecco>
(it fails building the dependencies of embassy-stm32, namely embedded-io-async
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
<GrantM11235[m]>
You need to remove all the nightly features in Cargo.toml
<Ecco>
hmm, ok
<GrantM11235[m]>
It is a bit tricky to set up all the dependencies and features for the first time, but I promise it is possible 😅
<Ecco>
:-D
<dirbaio[m]>
<Ecco> "Oh, also, is it possible to..." <- you can use Rust 1.75 beta now
<dirbaio[m]>
it'll work on stable when 1.75 stable is released, on December 28th
<Ecco>
oh cool
<Ecco>
does embasys's HAL make use of async/await?
<Ecco>
ok, let me rephrase: my understanding is that "embedded-hal" (and "embedded-hal-async") are merely specifications
<Ecco>
that need to be implemented per-platform
<Ecco>
correct?
<GrantM11235[m]>
Yes
<dirbaio[m]>
yes, they're just traits
<dirbaio[m]>
embassy-stm32 provides implementations of them
<Ecco>
And embassy provides an implementation for both, for stm32 among other things
<dirbaio[m]>
both blocking and async
<Ecco>
indeed
<Ecco>
so, question: why make it a part of embassy?
<dirbaio[m]>
so you don't have to use embassy-stm32 with async, you can use it without
<dirbaio[m]>
all the basic stuff (gpio, i2c, uart, spi..) is available blocking and async
<Ecco>
no, I meant, why make embassy-stm32 a part of embassy at all?
<Ecco>
couldn't (shouldnt?) it be a separate project?
<dirbaio[m]>
because nobody cared about async back then
<Ecco>
hmm, makes sense
<dirbaio[m]>
it was unproven whether it'd be a good fit for embedded, it was more experimental
<dirbaio[m]>
it was easier to start a new HAL than to contribute async support to existing HALs
<dirbaio[m]>
especially because people have opinions
<Ecco>
Makes sense
<Ecco>
but I mean, at least on stm32, the HALs are quite a mess
<Ecco>
(and from what I'm seeing, the approach in embassy-stm32 looks a lot more sane)
<JamesMunns[m]>
I think dirbaio chose between:
<JamesMunns[m]>
* convince 20 people to fix it
<JamesMunns[m]>
* fix it
<dirbaio[m]>
and in stm32 it'd have meant contributing async support to 10 different repos maintained by 10 different people
<dirbaio[m]>
* different people, yep
<JamesMunns[m]>
Ecco: Keep in mind this is a state that grew organically over 6-7 years
<Ecco>
yeah, it makes sense
<Ecco>
but at this point, is there anything that "stm32-rs" does that embassy doesn't?
<Ecco>
(sorry embassy-stm32)
<dirbaio[m]>
yep different projects by different people started at different times with different goals
<dirbaio[m]>
when the first stm32xxx-hal crates appeared it was unproven whether Rust itself would be a good fit for embedded 🤣
<JamesMunns[m]>
No top down planning here, just a bunch of folks helping each other.
<Ecco>
yeah
<dirbaio[m]>
so "let's focus on one family to see if this new Rust thing works well" made sense then
<Ecco>
Actually I did look around embedded rust in ~2016
<Ecco>
so I kind of see what you're talking about
<JamesMunns[m]>
2018 is generally when it became more reasonable, but lots of us were poking around 2015-2017 or so :)
<Ecco>
but as of today, 1/ The STM32-HAL situation is a giant mess (code duped everywhere) 2/ It *seems* like embassy-stm32 has it all
<Ecco>
So why not ditch/archive stm32-rs altogether?
<JamesMunns[m]>
Ecco: because dirbaio isn't in charge of telling other people what to do?
<dirbaio[m]>
🙃
<dirbaio[m]>
pretty much that yep
<Ecco>
Yes, but it's very weird for newcomers
<Ecco>
And I *hope* that if technically there's a better solution, the community should be able to come to an agreement
<dirbaio[m]>
there's people/companies that have built their firmwares on stm32xx-hal and don't want to port because what they have now works well
<Ecco>
oh, yeah, this of course
<Ecco>
Like we don't need to nuke those repositories
<dirbaio[m]>
so they prefer continuing maintaining their HAL
<Ecco>
yes, this makes sense
<dirbaio[m]>
s/their/the/, s/HAL/stm32xxx-hal crate they use/
<Ecco>
well, TBH, I was actually consdering rolling my own HAL
<Ecco>
(which I've done in the past)
<Ecco>
it's fun, but well, reinventing the wheel gets old
<Ecco>
(and also I'm nowhere nearly as good as Rust as I'd need to make something useable)
<Ecco>
I guess my point is that I'm frustrated with the stm32-rs situation
<GrantM11235[m]>
If I was in charge of any of the stm32xx-hals, I would definitely archive it in favor of embassy-stm32. But I'm not, so I can't 🤷
<Ecco>
So really eventually I have two questions, really: 1/ Is embassy-stm32 better than stm32xxx-hals or not really? 2/ How about moving embassy-stm32 out of embassy and into stm32-rs?
<Ecco>
(and the reason I'm suggesting 2 is because a lot of documentation points to stm32-rs)
<dirbaio[m]>
stm32-rs is not "the official stm32 rust org"
<Ecco>
Yeah, I guess, but it's referenced everywhere
<Ecco>
or, maybe, as an alternative, create a new org
<Ecco>
but just split the stm32-hal out of embassy
<Ecco>
because, as a newcomer, it now looks very much "tied" to embassy
<Ecco>
(embassy as in an alternative to a scheduler)
<JamesMunns[m]>
It's the stm32 hal, developed by the embassy project, which has a secondary goal of also supporting non-embassy usage.
<Ecco>
yes, of course
<Ecco>
but then there's an "official" rust embedded team
<Ecco>
that makes an official HAL specification (both blocking and async)
<JamesMunns[m]>
who doesn't maintain ANY chip specific HALs.
<Ecco>
indeed
<Ecco>
correct
<Ecco>
maybe it should?
<Ecco>
or, maybe, if embassy has a great HAL, maybe it should just make it its own project?
<Ecco>
just my two cents :)
<Ecco>
Here's what I went through today: 1/ ok I've this new chip I want to mess up with 2/ Let's try and load a sample project on it. Oh, wait, apparently there's no HAL for it since the thing that everybody uses (stm32-rs) doesn't have it. Hell they don't even have a PAC for it either
<Ecco>
2/ Ok, I found a SVD file, maybe I can create a PR for their PAC.
<Ecco>
3/ But then wait, I'd need to come up witha HAL crate. And… those are all copy-pastad from each other? What the f? That's horrible
<JamesMunns[m]>
I'm gunna be a little frank here:
<JamesMunns[m]>
* opinions of folks who are new are good, and valuable, because you have a fresh take on things. However,
<JamesMunns[m]>
* It might be good to take time to ask questions and understand the state of things, and the past couple of years of history of how we got there, before asking a number of people to make significant changes to their volunteer projects, based on first impressions
<JamesMunns[m]>
like, if you show up to the Apache IRC room, and go "NGINX exists, why are you still working on this"
<Ecco>
oh, I agree with you
<JamesMunns[m]>
that conversation will likely go not well
<Ecco>
And again, I don't mean to offense anyone
<Ecco>
I'm trying to share my perspective from a fresh set of eyes
<Ecco>
as in "this is the problems that a newcomer faces"
<Ecco>
(because you guys have been at this for a while so you might not realize)
<JamesMunns[m]>
I think framing it as "this was my first impression, this was confusing, how did it end up like this", is a very reasonable point of view
<Ecco>
and 4/ I log in on IRC sort of on accident, and you guys tell me all about embassy (which I really only assumed was an alternative to a RTOS)
<Ecco>
JamesMunns[m]: yes, and that's all there is to it :)
<JamesMunns[m]>
but "why don't you just do X" is a very non-rewarding question to have to deal with, in general.
<Ecco>
yeah, sorry abotu this
<Ecco>
I guess it's another way of trying to understand
<GrantM11235[m]>
To be fair, you are not the first person to say "I can't find a stm32xx-hal" for a chip that is already supported by embassy-stm32, I agree that it is a problem
<Ecco>
(and me dealing with my frustration)
<Ecco>
I'm definitely not blaming any contributor :)
<Ecco>
ok, here's another suggestion
<Ecco>
Maybe the official embedded-rust team
<Ecco>
should link to all known HALs that implement their specification
<JamesMunns[m]>
dirbaio you should PR embassy hals there, tho IMO :)
<dirbaio[m]>
lol they're not there?
<Ecco>
nope
<JamesMunns[m]>
nope, just under no-std crates
<JamesMunns[m]>
IMO you could add either a section there under HALs or one under each of the chip families
<dirbaio[m]>
only nrf-hal listed for nrf yeah
<dirbaio[m]>
will do
<dirbaio[m]>
btw what about nrf-hal?
<dirbaio[m]>
that one IS unmaintained
<JamesMunns[m]>
Dunno if we ever hit consensus, will reping in #nrf-rs:matrix.org
<GrantM11235[m]>
Don't forget to add stm32-metapac to the list of pacs
<firefrommoonligh>
Ecco: since no one else mentioned it, [this is the STM32 HAL I built and use](https://github.com/David-OConnor/stm32-hal). Does not support WBA, but if it's similar to WB, would be easy to add, other than the radio
<firefrommoonligh>
No async
<dirbaio[m]>
WBA is U5 with radio
<firefrommoonligh>
Oh gotcha!
<dirbaio[m]>
it has GPDMA, RCC is like U5, etc
<firefrommoonligh>
FOr a second I held out hope it was STM32WiFi
<dirbaio[m]>
there's a newer STM32WB0 too ☠️
<dirbaio[m]>
which is a G0 (or C0?) with radio
<firefrommoonligh>
Hah what
<dirbaio[m]>
new cortex-m0+ chip released in 2023
<dirbaio[m]>
we're never getting rid of cortex-m0 🤣
<Ecco>
thanks firefrommoonligh
<firefrommoonligh>
I guess that's fine. None of my projects needed those, but I have a feel for when I'd use one. I feel like I always need (Strong word...) something like hardware floats
<firefrommoonligh>
s/those/M0/
<dirbaio[m]>
or atomics 😬
<firefrommoonligh>
Yea those are another thing I use in p much everything, but could obv sacrifice A/R
<firefrommoonligh>
For WiFi I'm probably going to use STM32 of choice + NRF7002-DK
<JamesMunns[m]>
dirbaio[m]: who needs data synchronization?!?! it's just interr̶̛̥̒ȕ̴̠p̷͓̭͛͌̍t̸̹̯̐̈́̚s̵̫̈́̿,̷͇̈́͝ ̵̠̤̆͑̅w̶̨̏̚ȟ̷̞̯̞á̸͚ț̶̕ ̵̨̛̲͐͝c̸̻͖̀͝ǫ̵͎͔͛u̶̹̯͑̽̓l̶̹̂d̵̡̓͌͛ ̵̻̿̾͘g̶̡͒͜o̶̹̹̖͂̈́ ̸̹̇̿ẇ̸̡̢̩̍ṟ̵̾̐̆͜o̸̗͆̀̉ṅ̷̖̎ͅg̵͓̀̃?̸̱̳̒
<firefrommoonligh>
* For WiFi I'm probably going to use STM32 of choice + NRF7002
<dirbaio[m]>
firefrommoonligh: don't, NRF7002 is cursed
<bartmassey[m]>
Henk and I think we want to start maintaining nrf-hal and microbit if we are allowed to. Hadn't quite got to asking folks. I think we'd rather do that than rewrite the Discovery Book again
<dirbaio[m]>
I was planning on porting the discovery book to embassy-nrf 😅
<dirbaio[m]>
I mean, one thing doesn't preclude the other, we can have 2 versions of it if nrf-hal stops being unmaintained
<firefrommoonligh>
Hey I have a timer module you can use!
<firefrommoonligh>
I don't have any active nRF projects, but had to use a fork to add high-level timer functionality
<firefrommoonligh>
I think I also got rid of the GPIO unwraps or something
<firefrommoonligh>
dirbaio[m]: Oh? Any recs?
<spinfast[m]>
so bonus points for having regmaps in yaml, the doc strings are easily added to every level
<firefrommoonligh>
(My main radio project now is a sub-ghz lora one, but I have some ideas for wifi)
<dirbaio[m]>
if you're using an esp32 you might as well use it as your main MCU though, instead of as a slave wifi module
<firefrommoonligh>
I need to do the homework on NDAA and espressif
<firefrommoonligh>
Might have DoD customers
<dirbaio[m]>
oof
<spinfast[m]>
dirbaio[m]: you'd think that... but xtensa is such a pita
<firefrommoonligh>
No one seems to really want to compete with ESP for WiFi (at least properly apparently), which is v surprising, given all the options for BT and LoRA
<dirbaio[m]>
newer esp32's are riscv
<dirbaio[m]>
esp32c3, esp32c6
<spinfast[m]>
and perfect as a wifi module
<GrantM11235[m]>
dirbaio[m]: Is that just ("just") because there isn't a good wpa library, or are there other considerations?
<dirbaio[m]>
with a rust wpa implementation it should be doable yep
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
<GrantM11235[m]>
Add it to the list after a certified bluetooth impl 🤣
<dirbaio[m]>
lol
<firefrommoonligh>
OK so speaking of rust libs for RF: Anyone had luck with anything for Semtech SX126x?
<firefrommoonligh>
I just ordered some boards with one wired up to a stm32g4
<firefrommoonligh>
And saves me trouble from wheel reinvention
<dirbaio[m]>
yeah ther'es been a zillion forks
<dirbaio[m]>
the lora-rs repo is the latest iteration, maybe the only maintained one
<firefrommoonligh>
Basically, there's this open source drone radio system called Express. I've been using them, and make a board that matches that with a DroneCAN interface (Using an STM32 as intermediary). I'm hitting some limitations on a current WIP project like needing many-to-one, and possibly mesh networks. I know the Semtech hardware can do it, but ELRS doesn't, so I'm going to have to learn to program the radio
<firefrommoonligh>
Looks like that list is actively in progress. Good sign.