<GrantM11235[m]>
`dyn` is required to use different pin types in the same array. If you have `where T: Trait [T; N]`, all the elements must have the same type, but with `[&dyn Trait; N]` they can be different types
<dicklessgreat[m]>
GrantM11235[m]: It seems like this dyn is not for different pins but for internal trait which is used to handle ShiftRegister8, ShiftRegister16, Shiftregister24...etc as the same in generics.
<GrantM11235[m]>
hmm, yeah that does seem unnecessary
<GrantM11235[m]>
I think you can simplify the decompose method to be a single array::from_fn
<dicklessgreat[m]>
GrantM11235[m]: Thanks. I'll take a look.
<GrantM11235[m]>
hmm, you might be able to use const generics to unify the all the different sizes of shift registers. Then you could get rid of the trait and the big macro
<J[m]1>
idk what a fluffy chat is I just thought it is funny, but it didnt open so.. also I'm not using lebre office whoever is inviting me
<J[m]1>
ok bye
onsdag[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has joined #rust-embedded
Guest7282 has left #rust-embedded [Disconnected: Replaced by new connection]
starblue has quit [Ping timeout: 276 seconds]
starblue has joined #rust-embedded
huszty[m] has joined #rust-embedded
<huszty[m]>
Hey! I have an STM32 based project where I use `heapless::spsc` queues to pass commands from interrupt handlers to other lower priority RTIC tasks for later execution. Currently I have an enum that explains the different commands in the queue, so I can match on the receiver side. I wonder if I could use any closures of Fn pointers to make the commands transparent to the delivery logic (i.e. to not expand the enum and the receiver
<huszty[m]>
I am not using any allocator and other dynamic stuff at the moment. Is it possible this way?
<huszty[m]>
side always to add more command types). The idea is that the closure could capture data from the interrupt handler and would be able to use them when executed on the receiver side, where the resources are available to manipulate.
<dirbaio[m]>
you can send function pointers just fine fn(), lowercase
<dirbaio[m]>
sending closures Fn(), uppercase is harder, because Fn is a trait, not a type.
<dirbaio[m]>
the actual type is an "anonymous struct" that contains the function pointer and all the variables captured by the closure
<dirbaio[m]>
so the way you'd usually send them is `Box<dyn Fn(...)>`, but it requires alloc.
<dirbaio[m]>
you can't send dyn Fn(..) because it's an unsized type (size is not known at compile time, since it could be any of these anonymous structs)
<dirbaio[m]>
I honestly don't recommend it, just send an enum and do a match on the other side.
<dirbaio[m]>
* I honestly don't recommend it, just send an enum and do a match on the other side, it's much simpler.
<huszty[m]>
Thanks dirbaio ! Yes, this was my conclusion after some failed attempts and some googling. Sending `fn()` is naturally not enough as it cannot capture any env if I am not mistaken. Will stick with the enum+match. 👍️
spinfast[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has joined #rust-embedded
chodzikman[m] has joined #rust-embedded
<chodzikman[m]>
I'd also recommend sending enums as this easier to review and audit than passing arbitrary functions, but an idea on that note - couldn't heapless introduce stack allocated Fn with max size?
<JamesMunns[m]>
heapless doesn't really have a "pool allocator with max size per element". It would be possible to build, but doesn't exist currently. They do have a pool allocator, but all elements must be of the same type (and all closures have unique, un-nameable types)
<chodzikman[m]>
I don't mean pool allocator but an in-place constructor, similarly to `Vec<T,usize>`
<JamesMunns[m]>
yeah, the issue is all of your Ts are different types
<dirbaio[m]>
you could apply it to any dyn Whatever, yes
<JamesMunns[m]>
if you mean "make a blob of 512 bytes, and allocate closures in it of different sizes", you can also do that with different allocator crates
<JamesMunns[m]>
(but that's problematic if you are sending it from one place to another over a channel)
<dirbaio[m]>
this is not really an allocator, it's more like a "wrapper that pads size up to a compile-time-known N"
<dirbaio[m]>
you can send that over a channel, it's all owned memory
<dirbaio[m]>
if your closures are small it wouldn't be that terrible
<dirbaio[m]>
but still, an enum is way more simple
<JamesMunns[m]>
<JamesMunns[m]> "heapless doesn't really have a..." <- I guess that's what I meant by this, "a pool of N blobs, where each blob can hold an owned closure up to size M" (the pool can also be a channel, same diff honestly), but maybe I wasn't explaining it well.
<chodzikman[m]>
I see what you mean now
<chodzikman[m]>
btw, this is similar to what defmt does under the hood, right?
<JamesMunns[m]>
Uh, not sure I follow.
<chodzikman[m]>
but instead of function pointer there is a string literal pointer
<JamesMunns[m]>
Defmt uses interned string IDs, not actual pointers
<JamesMunns[m]>
It uses the linker to create a unique ordered ID for each format string
<chodzikman[m]>
never read defmt code, but I always imagined that these are pointers to a section that does not land on an MCU but pointers to them are inlined
<JamesMunns[m]>
Nope, lemme find the docs for you.
<chodzikman[m]>
I am reading it rn, thanks :)
<JamesMunns[m]>
I guess it does sort of use a pointer, but it's not a pointer to a string, really
<chodzikman[m]>
that's an intersting read - finally I had a trigger to look at it instead of postponing it to infinity 😅
<Noah[m]1>
is it just me or is building linux images from non-linux virtually impossible?
<Noah[m]1>
like all the tools I find always want some existing filesystem or some non M1 docker version, vagrant, etc.
<dirbaio[m]>
as in, embedded linux images? yep, don't try
<Noah[m]1>
yes, exactly
<Noah[m]1>
I just wasted like 2 days
<Noah[m]1>
why is it so bad -.-
<dirbaio[m]>
building linux images requires tons of linux shit, it kinda makes sense
<chodzikman[m]>
what do you use? buildroot? yocto?
<Noah[m]1>
I wanna run on raspbi CM4 (building the factory testing HW platform finally dirbaio) so pi-gen. Since that was not working I tried packer, but that also sucks because it requires ARM plugins that need privileged docker mounts that dont work on mac because it needs the linux device file etc. and ofc it's all in go and the readme is completely broken and non-helpful
<Noah[m]1>
so yeah I guess I have to work from a VM, which is even better because VirtualBox does not even run on M1
<Noah[m]1>
dirbaio: I disagree, it does not make sense. it makes sense that you need the same arch without virtualization, but you can build the skeleton no matter what OS you are on :)
<Noah[m]1>
like it's just copy pasting files mostly
<Noah[m]1>
in 2023 I kinda expect that.
<dirbaio[m]>
well *that's* especially cursed, dpkg is nuts
<dirbaio[m]>
> pi-gen
<Noah[m]1>
but everytime I touch anything that's linux-y I get a non functional readme with non-functional code ... and well a non-functional product .. great stuff
<dirbaio[m]>
I once made a script to build arch linux arm images for rpi, ended up working but also filling me with regret
<chodzikman[m]>
yep, Debian legacy is extremely hostile when you want reproducible and portable builds
<dirbaio[m]>
Noah[m]1: it's not just copying files around, you're building an ext4 image so you need an ext4 fs driver
<dirbaio[m]>
and you can't simply build it to a macos dir and cp -r it later because there's special files with special attrs that you can't have on a macos fs
<dirbaio[m]>
like device nodes in /dev
<Noah[m]1>
dirbaio[m]: fair, but could use stage 2 or so
<dirbaio[m]>
my recommendation is stay away from rpis and embedded linux 🤣
<dirbaio[m]>
for factory testing
<dirbaio[m]>
I regret it
<dirbaio[m]>
we're moving to plain old x86 pcs
<dirbaio[m]>
the rpi gpios are not that great. there's not many, they're extremely easy to fry so you'll want external circuitry anyway, there's no ADC so you'll want external SPI ADC or something anyway...
<JamesMunns[m]>
One of my goals is to make a bus-pirate-like version of pretty-hal-machine that runs on the RP2040, so if you need "Linux but with a handful of GPIOs/SPI/UART/I2C", you can just use an RP2040 and a USB port instead
<dirbaio[m]>
so it's more flexible and way wayyyyyyy easier to build a "USB to SWD+GPIO+ADC+SPI+UART+whatever" out of an rp2040 or similar, than to go full raspi embedded linux
<JamesMunns[m]>
if you promise to be gentle, you can just use a bare rp2040, or add some better isolation if you want it to not be totally disposable (which you'd need for the rpi anyway if you want it to not get fried either)
<dirbaio[m]>
for dev you can just plug it in to your dev machine instead of crosscompiling shit to the rpi every time you want to test something
<JamesMunns[m]>
JamesMunns[m]: if anyone needs this for a project, btw, `postcard-rpc` is built specifically to make this possible, and I just need a customer for it to prioritize it, or I'll build it eventually :D
<dirbaio[m]>
if your device is 12v powered, and for some reason +12v and gpios get connected before GND, you get 12v on the gpios
<dirbaio[m]>
it's super easy to fry shit
<dirbaio[m]>
* fry shit like that
<JamesMunns[m]>
I do want to try using the waveshare "rp2040 in a pi-zero form factor" board, to support cases where people have HATs and stuff already built for rpis
Guest7282 has left #rust-embedded [Error from remote client]
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<Noah[m]1>
<JamesMunns[m]> "One of my goals is to make a bus..." <- we are making a full box with onboard probe, powersupply, some ADCs, DACs, etc to do full testing all integrated with a nice lib and it can run all the tooling directly.
Guest7282 has joined #rust-embedded
<Noah[m]1>
<dirbaio[m]> "we're moving to plain old x86..." <- well if there was really good options ... I actually like the CM4. just the linux is meh
<JamesMunns[m]>
Nice!
<JamesMunns[m]>
If you aren't using postcard-rpc already, you might enjoy it :)
<Noah[m]1>
JamesMunns[m]: I will look into it!
<dirbaio[m]>
why sell the whole machine with a linux in it?
<dirbaio[m]>
vs selling a usb gadget the customer can use in any PC?
<dirbaio[m]>
you'll get customers wanting to use Windows because their other factory stuff is Windows (happened to me! :D)
<dirbaio[m]>
you'll get customers wanting to do custom stuff to the OS, like install a VPN or extra programs
<Noah[m]1>
dirbaio[m]: because it makes things easier and shortens time. imagine you have a box that already has all the IOs, FW, SW etc + 2 buttons & corresponding pins to start/stop test runs
<JamesMunns[m]>
"we'll give you SSH access but that blows the support fuse permanently" :p
<Noah[m]1>
yeah fair
<Noah[m]1>
maybe we just need to make a better USB lib
<Noah[m]1>
JamesMunns[m]: along those lines was my thought. but then I realized that building linuxes is more cursed than I thought.
<Noah[m]1>
back in the day when I was big into this shit with all sorts of build systems and chips I apparently used linux only, which I forgot
<dirbaio[m]>
then you'll want to support OTA updates of your linux
<Noah[m]1>
and now I fell on my face
<dirbaio[m]>
(and no apt update is not OTA updates)
<dirbaio[m]>
* (and no, apt update is not OTA updates)
<dirbaio[m]>
then you'll have to fight with the weirdass rpi boot process
<Noah[m]1>
dirbaio[m]: not really required. they can rebuild the image, but I see the issue
<dirbaio[m]>
the rpi blob doing mistery patches to your device tree
<dirbaio[m]>
the uboot a/b partition setup all the tools use (like mender etc) doesn't really work in the rpi uboots patched to death
<Noah[m]1>
dirbaio[m]: the idea would be that you just patch over a stage 2 (I believe) slim RPi
<dirbaio[m]>
👻
<vollbrecht[m]>
at scale i think the biggest issue is just sd-cards die constantly on such machines :D such a hassle.
<dirbaio[m]>
hahaha that too
<dirbaio[m]>
it's not that bad if you patch the os to make the rootfs readonly
<dirbaio[m]>
(something raspbian does not do)
<vollbrecht[m]>
yeah also ramfs etc for logging
<vollbrecht[m]>
cause systemd logs shit in record speed
<dirbaio[m]>
⚡️💩
<vollbrecht[m]>
so use a newer rpi with pcie + nvme support :D
<vollbrecht[m]>
but yeah x86 than comes close if you compare just prices/ not thinking about power / efficiency etc
<Noah[m]1>
vollbrecht[m]: we don't use SD cards ofc :) eMMC ftw
<vollbrecht[m]>
i wonder if this new milk-v boards will be everywhere in a couple of years
<danielb[m]>
<vollbrecht[m]> "i wonder if this new milk-v..." <- You mean will they age like milk(-v)?
<Noah[m]1>
dirbaio: I hate when you have compelling arguments and I was already locked on a stupid approach :P
ziguana[m] has joined #rust-embedded
<ziguana[m]>
hi, is this a good place to talk about stm32-rs? i'm looking to upgrade a crate to use embedded-hal 1.0.0 traits, and want to know if someone's already doing it
<Noah[m]1>
ziguana[m]: #stm32-rs:matrix.org
<dirbaio[m]>
if you're looking for a stm32 HAL that already supports embedded-hal 1.0.0, there's embassy-stm32
<ziguana[m]>
great, thanks! looks fairly extensive, will use it as inspiration
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
korken89[m] has joined #rust-embedded
<korken89[m]>
For people more well versed in ethernet, is there any advantage in using MII instead of RMII other than the reduced EMI thanks to half the clock speed?
therealprof[m] has joined #rust-embedded
<therealprof[m]>
Not that I'm aware. The larger amount of connections needed is often also a downside. A lot of chips even drop support for MII alltogether.
<therealprof[m]>
I've never even seen a chip implenting GMII in the wild as that starts to get crazy... RGMII sure but I think most people moved on to SMII and later serial versions...
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
<adamgreig[m]>
there are some niche technical reasons around receive buffer latency
<adamgreig[m]>
single interface clock means you might have slight rate mismatches so there's a little elastic buffer in the phy and that can cause some slight jitter in receive timing
crabbedhaloablut has quit [Client Quit]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Client Quit]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit []
barnabyw[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has joined #rust-embedded
K900 has quit [Quit: Idle timeout reached: 172800s]
dsvsdveg[m] has quit [Quit: Idle timeout reached: 172800s]
crabbedhaloablut has quit []
AliGasimzade[m] has quit [Quit: Idle timeout reached: 172800s]