<gauteh[m]>
Hi. Does anyone have experience with the bitvec crate? If I've got a bitslice or bitvec, how do I change the ordering interpretation in the easiest way? Msb or Lsb is defined upfront, but I don't see how I can get a bitslice with different ordering
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiisa has joined #rust-embedded
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
Ralph[m]1 has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
jessebraham[m] has joined #rust-embedded
<jessebraham[m]>
Is there any suggested way to update HALs to use PACs generated using the latest `svd2rust`? Because as of now it looks like I'm going to be spending a couple days fixing thousands of errors and uh not stoked on that
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
what's the breaking change?
<dirbaio[m]>
ah the "always use methods" thing
<dirbaio[m]>
* methods" thing?
<jessebraham[m]>
Mostly yeah, there are a couple others I don't understand yet
<jessebraham[m]>
Maybe we should just switch to chiptool if I have to change every single register access anyway 🙃
<jessebraham[m]>
I will just ignore the PAC updates for now lol
<dirbaio[m]>
chiptool also does "always use methods"
<jessebraham[m]>
Yeah, I just meant I have to change everything regardless haha
<spinfast[m]>
dirbaio: would you accept patches to split chiptools svd/yaml -> IR + transforms from the generator part?
<spinfast[m]>
1. imxrt uses a custom generator, 2. I'd love to reuse the IR for a i2c/spi regmap generator
<spinfast[m]>
so there's two new generators already
<spinfast[m]>
I mean I guess they're already seperate, but right, I don't need the generator part for like, taking yaml descriptions of wm8960 and generating a regmap
<dirbaio[m]>
hmm but you can just not use the generator part, right?
<spinfast[m]>
yeah that's true at least for the i2c codec stuff
<spinfast[m]>
to sort of un-fork the imxrt raltool (which would be nice) though I think might require the added generator and some other changes going up?
<dirbaio[m]>
about i2c, I did kinda that for an i2c driver a while ago
<spinfast[m]>
like it does some other things as well that I don't think chiptool does, like trying to merge IRs where registers are the same and stuff
<spinfast[m]>
it also doesn't generate any wrapper fns, there's a few base types for Register/RWRegister/etc and then macros to take module names and fields and such
<spinfast[m]>
which turns out to be really fast to compile and pretty easy to use imo
<spinfast[m]>
* use imo, it followed an idea adamgreig concocted in stm32ral
<dirbaio[m]>
dirbaio[m]: > <@dirbaio:matrix.org> about i2c, I did kinda that for an i2c driver a while ago
<dirbaio[m]>
but it's very unfinished, it needs modifications to common.rs I didn't post
<dirbaio[m]>
driver that uses it is not opensource
<dirbaio[m]>
I just used that once, pasted the generated code into the driver, then never touched it again 😅
<spinfast[m]>
yeah I mean. that's kind of the thing right, its like once you have the regmap generated its not likely to be updated (unless there was a mistake in the yaml)
<spinfast[m]>
though I kind of want to leave that as part of the build.rs build for wm8960, I want to try and go from yaml -> rust -> driver kind of thing for regmaps
<spinfast[m]>
I hate writing them by hand
<spinfast[m]>
there's at least some possibility of ripping a regmap out of a pdf datasheet with python perhaps
<spinfast[m]>
this codec has 56 registers... some of them have a lot more
<spinfast[m]>
like they have all sorts of routing/mixing/control capabilities
<spinfast[m]>
* output codec (actually pretty small, thought it'd be crazy, I saw some other one recently though with some crazy register set, not this one)
<spinfast[m]>
* e.g. <del>Cirrus Logic, * output codec</del> actually this one has a pretty small register set, thought it'd be crazy, I saw some other one recently though with some crazy register set, not this one
<dirbaio[m]>
could be good to support multiple "generator flavors" in chiptool if there's appetite for it
<dirbaio[m]>
memory-mapped svd2rust-style (the current one)
<dirbaio[m]>
memory-mapped raltool-style
<dirbaio[m]>
i2c/spi regs, svd2rust-style (the i2c branch
<dirbaio[m]>
* i2c branch)
<dirbaio[m]>
I have zero bandwidth to work on it myself, but will take PRs
<dirbaio[m]>
for example if you want to "rescue" the i2c branch
<dirbaio[m]>
* i2c branch, feel free
<spinfast[m]>
I’ll take a look, thanks!
<dirbaio[m]>
that gist has all the missing bits
<dirbaio[m]>
it's not the perfect design though, for example it hardcodes u8
<dirbaio[m]>
but on many i2c/spi chips registers are indeed u8 only, and not having annoying generics is nice
burrbull[m] has joined #rust-embedded
<burrbull[m]>
<jessebraham[m]> "Is there any suggested way to..." <- `cargo fix` maybe?
<jessebraham[m]>
Hmm I was under the impression that only fixed lints, maybe I’m mistaken
<burrbull[m]>
I never used it. Just a thought.
<thejpster[m]>
has anyone used ThreadX? It seems quite nice. Made a Rust wrapper for it.
<spinfast[m]>
<thejpster[m]> "has anyone used ThreadX? It..." <- It does look pretty nice, and I guess has safety certs which is cool. Rust wrapper would be neat
<spinfast[m]>
hard to imagine there being much "safe" rust to be found by rewriting what it provides
<spinfast[m]>
s/"//
<spinfast[m]>
s/"//, s/"//
<thejpster[m]>
Yeah it’s just annoying you need cmake and gcc to build it
oleidinger[m] has joined #rust-embedded
<oleidinger[m]>
Hey there,
<oleidinger[m]>
I was wondering if anybody was already able to interface with an OV2640 camera module? I wasn't able to find any driver that was *directly* talking to the HW via its GPIO pins. I'm using an esp-eye module (ESP32 + OV2640) in case that matters and programming it using embassy.
IlPalazzo-ojiisa has joined #rust-embedded
<spinfast[m]>
<thejpster[m]> "Yeah it’s just annoying you need..." <- that's always the annoying part
<spinfast[m]>
* annoying part, and usually particular versions of these things if you are being careful
<spinfast[m]>
I guess that would mean to build the certified versions you'd need a safety certified c compiler as well? aren't those really expensive?
<thejpster[m]>
Tools are qualified, code is certified
<thejpster[m]>
And yes qualified C compilers have historically been closed source and very expensive. But we didn’t like that so we made Ferrocene open source and very reasonably priced.
<thejpster[m]>
* qualified, code (or, the whole product development) is certified
<thejpster[m]>
If you wanted to use a certified C library with Ferrocene you would compile both pieces separately and link them together. I assume Microsoft used to sell you a pre compiled ThreadX lib. Unsure how Eclipse Foundation are going to manage this.
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiis1 has joined #rust-embedded
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
sirhcel[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Ping timeout: 276 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
crabbedhaloablut has quit []
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
thomas25 has quit [Ping timeout: 260 seconds]
rjmp[m] has joined #rust-embedded
<rjmp[m]>
Am I right to infer that embassy cant really be used on stable?
<dirbaio[m]>
it will be on December 28th, when 1.75 is out