<SosthneGudon[m]>
I also notice that none of the older releases have a corresponding gh release, only tags.
<diondokter[m]>
I should really try out some release tooling at some point. There are so many little steps you can forget
<SosthneGudon[m]>
We've been using trusted publishing for pypi at Nitrokey, we'll probably start using it for crates.io too now that it's available. It'd probably make sense to use it here too
<zeenix[m]>
Since the release notes are already ready when we release, it really should be automated IMO
AdamHorden has quit [Ping timeout: 256 seconds]
lulf[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has quit [Quit: Idle timeout reached: 172800s]
chrysn[m] has joined #rust-embedded
<chrysn[m]>
I'm trying to get familiar with the new heapless views. It *feels* like this should enable my application to take a `&mut [u8]` (or a `&mut [MaybeUninit<u8>]`), eg. a driver's buffer, and use a Vec to write into that as a cursor, eventually destructuring it again (telling the length).
<chrysn[m]>
But I didn't find it in the docs between VecStorage and ViewVecStorage; am I missing it? Or is this something that could be added compatibly?
<KevinPFleming[m]>
I don't think that's what Views are for, at least based on reading the release notes yesterday. They are only useful when the underlying storage is already a heapless container and you want to pass around references without having to include the generic parameter that indicates the size of the container.
glitchy has quit [Remote host closed the connection]
<DavidBrown[m]>
<thejpster[m]> Godbolt generally requires functions to be no_mangle in order for it to show you their assembly...
<DavidBrown[m]>
Either `no_mangle` or `pub` seems sufficient, combined with the codegen-units = 1. No mangle makes the symbol public in the obj file. Even just `#[used]` seems sufficient, to at least make the symbol present. Both no mangle and pub will make the symbol public in the object, but in my case, these aren't referenced by any, it's just a small static struct placed in an init linker section, that the OS scans during various phases of
<diondokter[m]>
Lemme check if there's a reason...
<diondokter[m]>
danielb[m]: Public now :)
<diondokter[m]>
Just note that I'm not actually proposing this now and it probably needs some work. But it's probably close to what I would propose
<dcz[m]>
at first blush, overflow looks awkward; I would like to handle it and continue measuring but it's not clear with this API
<dcz[m]>
for the "wait" API I'd like to know the value where overflow happens, assuming the overflow is the timer hardware's wrap value and not integer overflow
<danielb[m]>
Alarm looks slightly redundant with DelayNs, one handling an OverflowError and the other not seems a source of confusion
<diondokter[m]>
dcz[m]: If the `max-api` is there too, you can check ahead of time
<diondokter[m]>
But if you emulate an alarm, you get into some awkward things. A real alarm is nicer for api and its overflow error is never encountered if the wait time value is within the max range
<dcz[m]>
would this all work with interrupts?
<diondokter[m]>
dcz[m]: Depends on the implementation. But for the alarm at least I think that would be normal yeah
<dcz[m]>
okay, I have no clue how interrupts are supposed to work with embedded-hal Rust :P
<dcz[m]>
messing about with async to learn now
<diondokter[m]>
You create the timer with your HAL. Any async HAL can already do interrupts. Once set up, you just pass the timer object to the driver
<diondokter[m]>
For just a timer that doesn't do anything fancy, it won't need interrupts
<dcz[m]>
so a correctly written async HAL enables interrupts, and I just need to register a handler?
<TomB[m]>
async hal's should signal wakers on interrupts, which then effectively queues your async task into the executor kind of like a traditional work queue
<diondokter[m]>
In practice though, I would think most people would use an embassy-time backed timer and alarm
<dcz[m]>
ah, I wrote my own crappy async runtime XD
<diondokter[m]>
There's an example of that in the repo
<dcz[m]>
can't find how to run embassy or rtic on the gd32vf103
<TomB[m]>
afaik lpi2c/lpspi are from motorola turned into freescale
<TomB[m]>
* into freescale, bought by NXP
korbin[m] has joined #rust-embedded
<korbin[m]>
<diondokter[m]> We were working on an I2C slave trait proposal too....
<korbin[m]>
i paced around and thought about a recursive implementation to capture all the common I2C slave flows at a type level, i think it can be done
<korbin[m]>
there are some tricky cases since i think a lot of chips don't allow detection of a lot of the events at the time you need to know
<korbin[m]>
clock stretching is pretty much required
<TomB[m]>
the ibi, hot plug, and dynamic addressing add a lot of hassles to save a few wires over spi imho
<diondokter[m]>
<korbin[m]> there are some tricky cases since i think a lot of chips don't allow detection of a lot of the events at the time you need to know
<diondokter[m]>
Yeah, a trait would need to be super bare bones if it is to be implemented on 90% of available hardware
<diondokter[m]>
Anyways, for the timer, if you see something, feel free to open an issue to discuss things.
<diondokter[m]>
When I get back around to it, I can include it
<TomB[m]>
they updated the terms in i2c spec to match i3c as well 4 years ago or so now, controller+target
<TomB[m]>
which is fine, but of course this has been around for decades so...
<TomB[m]>
confusion abound
fjeauntyd[m] has quit [Quit: Idle timeout reached: 172800s]
<whitequark[cis]>
i remember coming up with better names for glasgow before it was like a widely acknowledged problem
<whitequark[cis]>
of course mine did not match the spec once it was updated
WSalmon has joined #rust-embedded
<i509vcb[m]>
What will be very fun is embassy-nxp where we have conflicting terms between chips
<i509vcb[m]>
MCX uses controller/target, imxrt and lpc use the old names
Mathias[m] has quit [Quit: Idle timeout reached: 172800s]
<TomB[m]>
eh, at a register/vendor level this stuff probably makes no sense to change so long as the public APIs/docs match the spec I guess, impl i2c::Target/i2c::Controller vs i2c::Master/i2c::Slave kind of thing I guess
<TomB[m]>
mcx also has flexcomm to contend with anyways, which means a reconfigurable peripheral block that can be done in a number of ways and split etc
<TomB[m]>
Honestly a pain point in Zephyr is this stuff is typically done using devicetree in really awkward ways... some vendors have i2c/uart/spi nodes and you are supposed to "know" that you can only enable one of those at the 0 peripheral index kind of thing
<TomB[m]>
rust has the nice ability to maybe have like a const fn constructor perhaps?
<i509vcb[m]>
nrf iirc just takes ownership of the peripheral whether you want spis, spim, etc
<korbin[m]>
i looked at the gowin i3c impl, it's enormous
<TomB[m]>
and likely full of bugs
<TomB[m]>
truly
<TomB[m]>
let me know when all the i3c implementations work perfectly to the specs at a hardware level let alone a software level... I swear its the kitchen sink bus
<i509vcb[m]>
Oof the pin tool metadata is slow to read lol...
jason-kairos[m] has joined #rust-embedded
<jason-kairos[m]>
and I thought I2C was complex (compared to SPI)
<i509vcb[m]>
TI does have a few Cortex-R5 MCUs with PCIe peripherals lol
<jason-kairos[m]>
PCIe on a "MCU" that actually sounds like fun, and useful
<jason-kairos[m]>
Can anyone point me to one of the MCUs? I don't see it in digikey
<i509vcb[m]>
There is also a dual and quad core variant
sypher3[m] has quit [Quit: Idle timeout reached: 172800s]
Lumpio- has quit [Read error: Connection reset by peer]
<i509vcb[m]>
I didn't realize it used DDR4?
<jason-kairos[m]>
Ah, so it is the AM series. I initially saw the AM6421 and which it ran Linux and thought "maybe that isn't a microcontroller"
<jason-kairos[m]>
s/which/that/
<jason-kairos[m]>
* Ah, so it is the AM series. I initially saw the AM6421 and that it advertised oit ran Linux and thought "maybe that isn't a microcontroller"
<jason-kairos[m]>
I guess you could could probably boot it without external DDR memory. But I speculate most of the software / drivers / BSP might be for some sort of real OS
<jason-kairos[m]>
* Ah, so it is the AM series. I initially saw the AM6421 and that it advertised it ran Linux and thought "maybe that isn't a microcontroller"
<i509vcb[m]>
No Cortex-A cores so I'm certainly curious what it would be doing?
<i509vcb[m]>
Data logging to an NVMe SSD?
<jason-kairos[m]>
I built the sort of things that the AM2431 was made for - real time industrial control
<jason-kairos[m]>
shuffling bits around between cameras, IO modules, sensors, etc. fast
<jason-kairos[m]>
* In a previous life I built, * I built/designed the
<jason-kairos[m]>
All the real processing is done elsewhere - it's just there for communications and controlling simple things (eg. 16x servos, 32 position sensors, a display, etc.)
<jason-kairos[m]>
but I feel like it's a struggle to call it a microcontroller if it doesn't have embedded flash
<i509vcb[m]>
That better not mean imxrt-like FlexSPI setup...
Lumpio- has joined #rust-embedded
glitchy has quit [Remote host closed the connection]