<jason-kairos[m]>
That certainly would avoid CRC collisions and be very predictable. But given the constraints (limited radio bandwidth, no access to a database, etc.), I am not sure that I could make it work while still guarding against programming/logic errors. Every device is different, and we have to empirically figure out the correct settings/parameters after it has left the factory.
<jason-kairos[m]>
* a database by the battery powered device, etc.),, * the factory. And when we change them, it is often something that is new and unpredictable, but also needs to occur quickly.
jcroisant has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
haobogu[m] has joined #rust-embedded
<haobogu[m]>
<bozgi[m]> how can i make a keypad switches easily programmable, ie. they can be changed to any other key by the user using eg. a desktop app interface
jfsimon has quit [Remote host closed the connection]
jfsimon has joined #rust-embedded
jfsimon has quit [Max SendQ exceeded]
jfsimon has joined #rust-embedded
jfsimon has quit [Remote host closed the connection]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
jfsimon has joined #rust-embedded
Mathias[m] has joined #rust-embedded
<Mathias[m]>
<jason-kairos[m]> specifically a ~200 byte structure containing settings that are mostly zeros, to check if they are the expected value or not
<Mathias[m]>
If the messages are mostly zeros, then it should be possible to compress the messages (Huffman, RLE, etc.). You can then leverage that additional space to use a larger CRC/hash. Or you can get really fancy and switch to Error Correcting Codes (e.g Reed–Solomon).
jakzale has quit [Remote host closed the connection]
jakzale has joined #rust-embedded
rainingmessages has quit [Quit: bye]
rainingmessages has joined #rust-embedded
Sonder has quit [Remote host closed the connection]
Sonder has joined #rust-embedded
<timokrgr[m]>
You mentioned that you can easily send more data to the device than receiving from it. In that case I would add a CRC alongside the configuration data. The device calculates the CRC after writing the received data compares it and simply sends back one bit ACK or NACK signal.
<timokrgr[m]>
* received data, compares
Farooq has joined #rust-embedded
<Farooq>
hmmm I think writing a firmware for Allwinner H5 will be fun
<Farooq>
this is my excuse for buying another SBC
<Farooq>
and it's a very valid excuse. "educational purposes"
<Farooq>
you know you have to invest in your education
<jannic[m]>
Again no tickets from me. Came back from vacation on Sunday evening, and this week started very busy (as usual after being away for a few days...) But I think there are already enough new tickets on the agenda.
<adamgreig[m]>
no announcements from me, but from mabez we have esp-hal 1.0.0-rc.0 out, so consider trying that out if you're using esp32!
<adamgreig[m]>
any other announcements before we move into the agenda items?
<dirbaio[m]>
there's been an Embassy release as well. pretty much every single crate got a release.
<dirbaio[m]>
many HAL improvements, especially on stm32
<KevinPFleming[m]>
zeenix[m]: And the lack of that release is why many of the Embassy examples can't be updated to defmt 1.0, because heapless 0.8 requires an older version of defmt.
<adamgreig[m]>
is it worth getting that merged for 0.9.1 vs getting 0.9.1 released with the fix from the yanked 0.9.0?
<adamgreig[m]>
i'm not up to speed on how useful 571 would be to have included
TomB[m] has joined #rust-embedded
<TomB[m]>
I have a question maybe some of you could answer, has there been any attempt at using hardware peripheral to peripheral triggering in some way with Rust and async perhaps?
<TomB[m]>
e.g. gpio edge triggers dma transfer directly
<TomB[m]>
there's kind of a weird ownership issue in these cases I feel like? e.g. dma uses some spi peripheral but software has no notion of when that is happening
<adamgreig[m]>
if it's ok we'll press on with the agenda items first, but I think that's just pretty standard chip setup no different from any other dma trigger
<dirbaio[m]>
KevinPFleming[m]: this is not preventing any upgrade, defmt 0.3 is compatible with defmt 1.0
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
adamgreig[m]: are there any blockers, review, testing needed to bring it over the line?
therealprof[m] has joined #rust-embedded
<therealprof[m]>
adamgreig[m]: Me neither, seems rather unrelated. People seem to want to have it included because 0.9 was yanked and so breakage is "fine"?
<adamgreig[m]>
historically the wg hasn't been very involved with a or r profile arm targets or aarch64 targets, but they are obvious things for the arm team to maintain and within the remit, so it probably makes sense to volunteer for those
<thejpster[m]>
engagement with a and r targets has increased a lot recently (from a low base)
<adamgreig[m]>
for the BE targets I think you're right thejpster, we don't have any meaningful way to test them, the ecosystem seems a bit behind, and they're very rarely used afaik
<thejpster[m]>
I think a free, working, simulator should be requirement for us to take on a tier 2
<adamgreig[m]>
if something is using them and wants to step up with some hardware or ideally qemu support they can always be promoted back later right
<thejpster[m]>
so, what's the process here? If the arm team get listed, how do the arm team decide they want that? and who does the work to write the new target docs?
<therealprof[m]>
Hm, are people really doing baremetal on v7 and v8?
<adamgreig[m]>
I think the best and usual process is an rfc for the arm team the same as we did before and a suitable majority (or lack of vetos anyway) to pass, then we can open a pr to rust-lang to update the target docs
<therealprof[m]>
thejpster[m]: So we're volunteering Ferrous then. 😉
<zeenix[m]>
<adamgreig[m]> is it worth getting that merged for 0.9.1 vs getting 0.9.1 released with the fix from the yanked 0.9.0?
<thejpster[m]>
> So we're volunteering Ferrous then
<thejpster[m]>
Expressly, not no.
<thejpster[m]>
We support the targets in our downstream build, Ferrocene.
<thejpster[m]>
* > So we're volunteering Ferrous then
<thejpster[m]>
Expressly not, no.
<thejpster[m]>
We support the targets in our downstream build, Ferrocene.
<thejpster[m]>
I'm asking if wg-embedded/t-arm want to do it. If they don't, the targets will fall to Tier 3.
<thejpster[m]>
(or I guess, someone else might step up)
<therealprof[m]>
thejpster[m]: I'm okay with them being Tier 3.
<adamgreig[m]>
I'll open an RFC to discuss it; I think it mainly comes down to whether we have anyone on the arm team currently with interest in them and/or think we should do it anyway if not
<adamgreig[m]>
we do already have a bunch of aarch64 stuff and the v8r may also be of interest at the least
<adamgreig[m]>
maybe less so 7a and 7r? but they're pretty mature targets that probably don't need much support anyway
<thejpster[m]>
I observe that shipping in rustup is a pretty important step if you want anyone to use a target. build-std and nightly is awful.
<thejpster[m]>
if the remit of wg-embedded is to "Enabling usage of Rust on Embedded Platforms" then getting targets into Tier 2 seems like a necessary step.
<thejpster[m]>
but obviously we're free to pick which embedded platforms
<therealprof[m]>
Wasn't the security stuff somewhat gnarly?
<adamgreig[m]>
next up, from bartmassey is a big discovery-mb2 update in https://github.com/rust-embedded/discovery-mb2/pull/56 that could do with another pair of eyes before it's merged (though he can't join the meeting today)
<adamgreig[m]>
so if anyone is happy to read over the new prose especially that would be great
<adamgreig[m]>
next up from thejpster is a reminder about https://github.com/rust-embedded/cortex-m/pull/605. I think my inclination is merge this and then backport the good things from master so we can get to 0.7.8 soon, but I haven't had time to review it yet, sorry. I'm taking a bunch of time off work at the start of august which should let me catch up a bit with rust stuff too...
<adamgreig[m]>
if that's all for now then we'll call it there, thanks everyone!
<i509vcb[m]>
<TomB[m]> I have a question maybe some of you could answer, has there been any attempt at using hardware peripheral to peripheral triggering in some way with Rust and async perhaps?
<i509vcb[m]>
For something that exists today, the Nordic PPI is probably the closest thing. Although more hardware has similar features (mspm0 event, xbar on imxrt)
<TomB[m]>
yes, this isn't uncommon at all
<TomB[m]>
but it tends to reside outside of the bounds of a typical mutex/move type ownership model
<i509vcb[m]>
<TomB[m]> there's kind of a weird ownership issue in these cases I feel like? e.g. dma uses some spi peripheral but software has no notion of when that is happening
<i509vcb[m]>
Would you need to know when this happens? Like some sort of DMA muxing?
<TomB[m]>
unless I guess you say the ppi/xbar/thing takes ownership of the dma channels and peripheral and trigger pin maybe?
<i509vcb[m]>
But yes you don't want to drop your pin mid transfer
<i509vcb[m]>
Cross triggering would probably need to own the source and target for sure
<TomB[m]>
sure but... xbar.setup_dma_event(pin, edge_event, dma_chan_x, lpspi0) kind of thing which takes ownership of this stuff seems totally reasonable?
<TomB[m]>
like have the trigger mux take ownership of all of it
<TomB[m]>
it gets goofy though, because you maybe want more of a combinator thing
<TomB[m]>
* let trigger_chain = xbar.with_pin(edge).trigger_dma(dma_x).with_periph(lpspi);
<i509vcb[m]>
And if your peripheral has a buffer which is internally managed it might be inaccessible as long as the transfer exists
<TomB[m]>
at this point you have no control over the peripheral I'd think
<TomB[m]>
its being used by the hardware, there's no way to safely share with software?
<TomB[m]>
maybe I'm wrong!
<i509vcb[m]>
Ring buffering might make it partially accessible
<i509vcb[m]>
But if one half is being used it would be inaccessible until hardware releases it
<TomB[m]>
<i509vcb[m]> And if your peripheral has a buffer which is internally managed it might be inaccessible as long as the transfer exists
<TomB[m]>
not sure what you mean by buffer, the hardware fifo?
<i509vcb[m]>
I don't know if xbar internally makes connections or has a specific "channel" instance you have a limited number of
<TomB[m]>
or are you talking about some driver buffer?
<i509vcb[m]>
TomB[m]: If you have a gpio (interrupt for example) start SPI transactions, how do you get new data into the tx buffer?
<i509vcb[m]>
Or get data out of the RX buffer
<i509vcb[m]>
(Software, not fifo)
<TomB[m]>
you setup your dma transfer ahead of time
<TomB[m]>
the whole thing is program the hardware to do all the work for you
<i509vcb[m]>
Well you don't need the with_peripheral part of the chain then?
<i509vcb[m]>
You just give the Transfer instance to xbar to trigger
<i509vcb[m]>
Although you'd have to have a way for the peripheral to give you a transfer to pass to it?
<i509vcb[m]>
(A lot of embassy drivers use the Transfer object internally)
<TomB[m]>
the with_peripheral there is meant to ensure you don't accidentally have software injecting junk into to your peripheral racing with your dma that may happen
<TomB[m]>
* the with\_peripheral there is meant to ensure you don't accidentally have software injecting junk into to your peripheral racing with your dma that may happen at any time without your software knowing
<TomB[m]>
dma half way reading spi and software comes in and starts reading the same peripheral fifo...
<TomB[m]>
bad stuff?
<dirbaio[m]>
I've found making DMA transfers own the peripheral like many older HALs do is very unergonomic
<dirbaio[m]>
in Embassy, peripherals own DMA channels and trasners instead. you .write() or .read() and that uses DMA internally. it's much simpler for the user
<dirbaio[m]>
and for advanced "trigger" stuff
<TomB[m]>
zephyr did this as well, it turned out to be a bit of a nightmare if you want to actually use all the dma features
<dirbaio[m]>
I think it's impossible to make a fully safe API with ownership semantics that exposes all the functionality
<TomB[m]>
so people go about working around it
<dirbaio[m]>
you'd end up with an extremely convoluted ownership model, borrow checker hell, and still have usage patterns that are not possible to implement
<TomB[m]>
like sound open firmware basically said screw that, and uses DMA as the sole API for moving audio around
<dirbaio[m]>
IMO it's not worth trying
jfsimon has quit [Quit: Leaving]
jfsimon has joined #rust-embedded
<dirbaio[m]>
instead i'd do two things:
<dirbaio[m]>
1. offer "pre-made" high-level drivers for concrete use cases. For example embassy-nrf's BufferedUart takes ownership of one UART, one timer, a few PPI channels and gives you a nice buffered uart implementing embedded-io that Just Works.
<dirbaio[m]>
2. offer low-level DMA, PPI helpers and let the user use them toghether with raw PAC register access
<i509vcb[m]>
We can't make a peripheral return a handle that tells xbar how to trigger it, since that would result in &self and a peripheral usually needs &mut self to do anything useful
<TomB[m]>
i mean I definitely get the ergonomics around peripheral owning a dma channel, zephyr APIs are almost the same as the embedded-hal ones (really)
<TomB[m]>
but yeah there's some desire to do this fully hardware setup triggering for sure
<TomB[m]>
lpspi.on_gpio_edge(x).transceive(...)
korbin[m] has joined #rust-embedded
<korbin[m]>
i ran into this issue doing the IMXRT1011 DMA impl
<TomB[m]>
I guess you could make the peripheral the center of this all instead
<TomB[m]>
you can't do everything then though
<TomB[m]>
because xbar event could trigger multiple things
<i509vcb[m]>
Splitter channels in mspm0 are going to have the same issue...
<TomB[m]>
or maybe you could? I dunno!
<i509vcb[m]>
Is the intention for cross triggering only for gpio, start transfer
<i509vcb[m]>
Or something like take UART RX frame and TX on SPI immediately
<TomB[m]>
the use case I have in mind is yeah a gpio interrupt triggering dma transfers, I don't have any others in mind myself off hand
<i509vcb[m]>
TomB[m]: This at least could probably be done via another constructor for a peripheral? Although that's potentially another exponential increase for some things in the number of new functions
<i509vcb[m]>
Ignore the CPU IRQ column, that's just an interrupt
<i509vcb[m]>
On another topic, the time driver in mspm0 usually has 2-4 unused channels. So all of a sudden now I have a fun situation where I can have a hardware driven ticker
enaut[m] has quit [Quit: Idle timeout reached: 172800s]
GrantM11235[m] has quit [Quit: Bridge terminating on SIGTERM]
haobogu[m] has quit [Quit: Bridge terminating on SIGTERM]
thejpster[m] has quit [Quit: Bridge terminating on SIGTERM]
whitequark[cis] has quit [Quit: Bridge terminating on SIGTERM]
KevinPFleming[m] has quit [Quit: Bridge terminating on SIGTERM]
i509vcb[m] has quit [Quit: Bridge terminating on SIGTERM]
therealprof[m] has quit [Quit: Bridge terminating on SIGTERM]
diondokter[m] has quit [Quit: Bridge terminating on SIGTERM]
bozgi[m] has quit [Quit: Bridge terminating on SIGTERM]
JamesMunns[m] has quit [Quit: Bridge terminating on SIGTERM]
Mathias[m] has quit [Quit: Bridge terminating on SIGTERM]
timokrgr[m] has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
adamgreig[m] has quit [Quit: Bridge terminating on SIGTERM]
jannic[m] has quit [Quit: Bridge terminating on SIGTERM]
TomB[m] has quit [Quit: Bridge terminating on SIGTERM]
RoyBuitenhuis[m] has quit [Quit: Bridge terminating on SIGTERM]
dirbaio[m] has quit [Quit: Bridge terminating on SIGTERM]
zeenix[m] has quit [Quit: Bridge terminating on SIGTERM]
rmsyn[m] has quit [Quit: Bridge terminating on SIGTERM]
korbin[m] has quit [Quit: Bridge terminating on SIGTERM]
jason-kairos[m] has quit [Quit: Bridge terminating on SIGTERM]
Farooq has quit [Quit: Bridge terminating on SIGTERM]