<sajattack[m]1>
Somewhat offtopic but idk if there's a better place to ask... what's the equivalent of cargo bloat for the linux kernel or c binaries in general? Some kind of objdump?
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
ana_briated has joined #rust-embedded
ana_briated has quit [Remote host closed the connection]
ana_briated has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
M9names[m] has joined #rust-embedded
<M9names[m]>
nm is what i usually use for binaries in general, can't say I've tried it on the Linux kernel.
<M9names[m]>
You'd only be able to see the size of drivers that are compiled in, not those built as modules.
<M9names[m]>
but most of the bloat in Linux is all the firmware that is shipped with it, not the kernel itself
That_Crow has joined #rust-embedded
That_Crow has quit [Remote host closed the connection]
exark has quit [Read error: Connection reset by peer]
exark_ has joined #rust-embedded
pcs38 has joined #rust-embedded
<adamgreig[m]>
thejpster: the teams repo pr merged so you're now in the arm team properly
<thejpster[m]>
Nice
<wassasin[m]>
<rafael[m]> "I looked into this, and learned..." <- Sounds like something else is going on still, but OK. Glad you found the faulty operation
LeandroMarceddu[ has quit [Quit: Idle timeout reached: 172800s]
pcs38 has quit [Quit: leaving]
sroemer has quit [Quit: WeeChat 4.4.3]
sroemer has joined #rust-embedded
sroemer has quit [Changing host]
sroemer has joined #rust-embedded
Maebli[m] has joined #rust-embedded
<Maebli[m]>
James Munns: how would you integrate defmt logging into postcards? If I want to add a meta info layer ontop of the defmt protocol. also how would this easily be decoded in code
<JamesMunns[m]>
I'd probably suggest going the other direction: piping defmt through something like postcard-rpc
<JamesMunns[m]>
you could collect defmt info into something like defmt-bbq, then consume it from a task and send as a postcard-rpc Topic
047ABD9UT has quit [Ping timeout: 260 seconds]
078AA6DO6 has quit [Ping timeout: 272 seconds]
<Maebli[m]>
<JamesMunns[m]> "I'd probably suggest going the..." <- yeah thats the direction i was meaning to go transport defmt via postcard
<JamesMunns[m]>
then yeah! I'd probably suggest checking out defmt-bbq, or maybe my newer bbq2 crate which is async. You'd feed defmt data into the queue, then take batches of it at a time and send as a Topic of `&[u8]` data or so
<JamesMunns[m]>
I'm working on something similar, I should be able to make it public in the next couple of days
<Maebli[m]>
awesome!
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Meeting this week?
<JamesMunns[m]>
I'm around if Adam is busy, hey @room ! Impromptu meeting this week, if you have any announcements, feel free to share while I go find the agenda :)
<bartmassey[m]>
In passing: thanks to guptaarnav for restarting Disco Book work with me! We're looking forward to rapid progress again.
<rmsyn[m]>
dirbaio[m]: reasons :)
<i509vcb[m]>
wassasin: iirc you did want to be told about the async traits for gpio I don't know if it got missed
<JamesMunns[m]>
Not on the HAL team, but that PR looks reasonable to me i509vcb!
<JamesMunns[m]>
Okay, last call, anyone have anything else to share or discuss? Otherwise I'll call it early, and hope adamgreig is doing okay somewhere out there :D
<dirbaio[m]>
i'm a bit concerned about ecosystem split. The vast majority of gpios are blocking, so it's possible drivers assume blocking but expanders implement only async
<dirbaio[m]>
but it's not a reason to blockit
<dirbaio[m]>
we can ship it and then let the ecosystem evolve and see what happens
<JamesMunns[m]>
yeah, I think that could happen, but we aren't really any worse off than we are today
<dirbaio[m]>
yeah
<i509vcb[m]>
Yeah the split was discussed when I first brought up the discussion a day or two before I opened that
<JamesMunns[m]>
I think a big PR to the embassy-hals would probably seed most of the ecosystem
<i509vcb[m]>
JamesMunns[m]: Its certainly a proof of concept there, certainly not the final shape of the postcard RPC stuff for it
<JamesMunns[m]>
but yeah, hunting down drivers that *could* be async would probably be the "long tail" for this
<dirbaio[m]>
merginated
<JamesMunns[m]>
Speaking of, at some point I want to get pretty-hal-machine (basically: remote controlled embedded-hal impls) back up to shape, with modern postcard-rpc/poststation
pcs38 has joined #rust-embedded
<JamesMunns[m]>
that way you can use something like an rp2040 as a "USB to anything" adapter for SPI/I2C/GPIO/UART/etc
<i509vcb[m]>
PC programmable PIO could be a interesting thing
<TomB[m]>
would be nice to have sort of a defacto way of testing interfaces and software... does spi/i2c/uart/gpio/usb/eth behave like the API says? I've been thinking about that awhile now
<TomB[m]>
usb to anything could be neat in that regard, if there's some way of boxing in what valid/invalid behavior might be
<JamesMunns[m]>
I do want to start using poststation.rs for more "hardware test rack" stuff.
<i509vcb[m]>
The mspm0 parts have a loopback mode for their i2c/spi/uart so those can be largely self tested
<TomB[m]>
in the past I kept thinking an fpga would be the thing, but then how do you validate the validation tool
<JamesMunns[m]>
poststation handles most of the plumbing, if you have the kinds of problems that aren't bothered by 1-2ms of USB round trip latency, or if you are willing to write a bit more custom firmware :D
<JamesMunns[m]>
I do want to have "off the shelf" firmware for like the RP2040/2350 tho for basic pretty-hal-machine usage
<JamesMunns[m]>
so folks don't have to buy and rpi just because they want some GPIOs :D
<JamesMunns[m]>
Anyway, I think we're socializing now! I'll call the meeting officially over, hope everyone has a good week!
<bartmassey[m]>
Yeah, I just bought a couple of US$25 boards that were basically this for I2C and for SPI, with a display and stuff.
<bartmassey[m]>
Thanks for running the meeting!
ian_rees[m] has joined #rust-embedded
<ian_rees[m]>
Bus Pirate is pretty handy for USB to random protocols https://buspirate.com/
<rmsyn[m]>
TomB[m]: with manual review of the code, and more (different) validation tools / testing.
<rmsyn[m]>
"I heard you like validation tools, so I validated your validation tool using a validation tool of a validation tool"
<bartmassey[m]>
Bus Pirate has been hit-or-miss for me, but I haven't tried to use it that much. I keep hearing good things.
<JamesMunns[m]>
ian_rees[m]: Yeah exactly! The idea behind pretty-hal-machine is you can do stuff like write drivers *on your PC*
<TomB[m]>
rmsyn[m]: hah yeah... at some point its I guess did you inspect it all with a scope and see with your eyeballs that it works?
<JamesMunns[m]>
so you don't have to keep reflashing the MCU: you can just attach and "proxy" comms over USB.
<TomB[m]>
the ultimate validation tool, in the chair with eyes
<bartmassey[m]>
Need better scope and better eyeballs, I'm afraid
<JamesMunns[m]>
I do want to figure out the saleae automation stuff at some point
<JamesMunns[m]>
it would be very easy to set up one GPIO as a trigger source, then do a capture by toggling a GPIO low, then doing a SPI/I2C transaction
<TomB[m]>
libsigrok is a thing
<JamesMunns[m]>
Or steal some of the "rp2040 PIOs as a logic analyzer capture source" stuff, if you don't need particularly deep sample buffers.
<TomB[m]>
thought I had just seen a project using a pico as a LA with MHz of bandwidth, no idea on capture length
<JamesMunns[m]>
yeah, there's a couple, it's limited to your ram depth + usb capture speed, good for a couple 100k samples or so
<JamesMunns[m]>
which can cover a lot for small i2c/spi transfer bursts!
<TomB[m]>
but the MHz of bandwidth always feels like a marketing gimick when your plots look jacked up because some level was waffling about just enough
<JamesMunns[m]>
Just not like "steady state display rendering" or so
<Lumpio->
Blast from the past issue
<Lumpio->
I think I even bought an RPi Pico to maybe play with the "raw gadget" stuff but never got around to it
<ian_rees[m]>
I've kinda gone off the Saleae stuff, bought a Logic16 Pro ages back for IIRC US$500 and here we are years later with only marginally better software, device costs ~3x as much
<Lumpio->
The Linux gadget stuff does require hardware though. You could test USB classes purely in software by somehow duct-taping embasys/usb-device on top of USB-IP though. That is purely software.
<ian_rees[m]>
would be good to give usb-device seems we've got some good back-burner ideas but get kinda stuck on cutting releases since the whole ecosystem needs to use the same version of usb-device
<Lumpio->
It could've be used to validate USB class drivers against the Linux drivers which should give some indication at least as to if they're correctly implemented
<i509vcb[m]>
<JamesMunns[m]> "I do want to have "off the shelf..." <- The logical end conclusion would be zephyr-like native-sim setup but using that for talking to the hardware
<TomB[m]>
i509vcb[m]: renode does this
<Lumpio->
ian_rees[m]: Blame me, it was my first Rust project and I didn't know that interfaces should go in their own crate lol
<Lumpio->
I think embassy might've done it better
<TomB[m]>
but right, once again I'd point to the "how do you validate the tool you are using to validate against" kind of story
<ian_rees[m]>
Lumpio-: haha no problem, I think there's also been an issue where there's like one person at a time who's motivated so it's hard to build momentum
<TomB[m]>
like all sims... it has its limits imho
dygear[m] has joined #rust-embedded
<dygear[m]>
<rmsyn[m]> "I just got done with the initial..." <- This is exactly what I'm looking for. ❤️ The RP2350 Metro has an SD Card on it.
<i509vcb[m]>
yeah the sims do have that issue
<ian_rees[m]>
* give usb-device some attention, seems we've
<TomB[m]>
I like the dirbaio method better, bunch of boards on a shelf, ultimately you know it works on the thing you are trying to use in the real world... even if there's some hassles to this
<JamesMunns[m]>
i509vcb[m]: It's fair, but IMO it ends up being a lot easier to plug a $5 dev board in over USB than making an accurate sim.
<rmsyn[m]>
dygear[m]: let me know if you need help implementing the traits for the RP2350. I'm working on a default implementation of the `Sdmmc::init` trait method, along with some others that can be implemented using the `SdmmcOps` trait methods
<i509vcb[m]>
HIL does work, but yeah also a logistics issue then rises
<Lumpio->
HIL is the only way to know if your hardware driver is correct
<JamesMunns[m]>
At least when it comes to "plumbing", I really am trying to make poststation the go-to answer for "how do I manage talking to lots of boards over USB reliably"
<TomB[m]>
i509vcb[m]: ideally the vendor does it
<Lumpio->
You can write unit tests all day but then you're testing your assumption of how the chip works and not the actual chip
<ian_rees[m]>
Lumpio-: the HCD in one of the later comments seems to be an in-software host controller, IIRC it requires a custom kernel build but that's about all
<Lumpio->
USB-IP is part of the standard kernel!
<i509vcb[m]>
TomB[m]: Yeah that is the expectation, but reality is that at least something sneaks by the vendor
<Lumpio->
It's a very simple mapping of Linux USB URBs to TCP
<TomB[m]>
i509vcb[m]: chip errata are *proof* of this
<i509vcb[m]>
RPi got burned by pin IP vendor for example
<dirbaio[m]>
most of the usb bugs are not in the classes, they're in the lower level driver
<TomB[m]>
like nrf52 having a non-functioning spi block
<Lumpio->
yes
<Lumpio->
But the actual hardware drivers cannot be tested without the actual hardware.
<Lumpio->
So if you want to do something in software, testing classes against OS drivers is probably the furthest you can go
<i509vcb[m]>
I don't know if this an issue, but chips with very few errata can feel like a minefield waiting for me to stumble into
<i509vcb[m]>
Like are the bugs all gone or do we not know of them?
<TomB[m]>
i509vcb[m]: sam e70 was like that...
<TomB[m]>
* like that... when I was trying to use it to develop a new sensor API for zephyr
<dygear[m]>
<rmsyn[m]> "let me know if you need help..." <- That's awesome thanks! I'm not super sure about the license tho, at the first step. I had the initial release https://github.com/Dygear/rp2350-metro MIT Licensed, that is kind of a "these are the things you can do out of the box example of Embassy on the Adafruit RP2350 Metro" (It's a mouthful, I should really slim that down, LOL.) So I'm wondering what I should do about the GPL side of
<dygear[m]>
this right now. But it looks great. I should be able to wire up the pins needed to make this work fairly easily I think?
<TomB[m]>
i509vcb[m]: I think in the sam e70 case microchip just didn't care anymore? I dunno, its a weird part... on paper a pretty nice cortex-m7, but I ran into weird quirks with spi and dma and other things
<rmsyn[m]>
dygear[m]: I understand if you want to keep it MIT licensed, but I feel pretty strongly on the GPL for stuff I write myself.
<i509vcb[m]>
I've been doing stuff with the I.mxrt1011 but I don't like how few erratta NXP has for how complicated the chip is
<TomB[m]>
i509vcb[m]: I've amazingly not run into a single hardware bug with it
<TomB[m]>
I think 90% of it was recycled from the i.mx 6
<TomB[m]>
so... maybe many bugs were worked out already
<rmsyn[m]>
if your project is non-commercial, I would be willing to grant a GPL exemption to use the MIT license on that project
<rmsyn[m]>
I'm not a lawyer, though. so I don't know how that would translate to derivative works of your project, or other downstream dependencies
<TomB[m]>
i509vcb[m]: also I noticed the other day nxp themselves are selling this part for like... $2 at quantity 1 which is wildly cheap for what it is 🤷 tempted to have a stock pile...
<rmsyn[m]>
if it's commercial, we can talk about it in another channel
<i509vcb[m]>
I would have ordered from NXP some of those but it's $29 shipping where I can get a few at mouser for far cheaper shipping
<i509vcb[m]>
Its the cheapest part I can find with a built-in usb-hs phy
<dygear[m]>
rmsyn[m]: Yeah, I don't know that it would be. I'm playing with it right now to see where it goes. I want to eventually use the HSTX port on the Metro or Feather board to run the Raspberry Pi Touch 2 display for a time clock interface. So I don't want to tread on any toes there if that's where this project ends up. Right now, I really just want to put Rust in front of more people at Adafruit so they take it a little more seriously.
<dygear[m]>
It was dead simple to get the Metro and Feather projects up and running including the neopixel doing its RGB rainbow thing in like under 30 minutes for both boards. I really feel like Embassy is first class for the Adafruit boards and they should mention the project as a possibility on their product pages.
<TomB[m]>
i509vcb[m]: about the only real downside of the 1011 is the 128k sram, that part is pretty constraining especially since its xip only... so if you enable icache/dcache there's half the sram gone, unless you can fit your image all in 64k...
<TomB[m]>
* about the only real downside of the 1011 is the 128k sram, that part is pretty constraining especially since its external flash only... so if you enable icache/dcache there's half the sram gone, unless you can fit your image all in 64k...
<i509vcb[m]>
I'd really just be using the part to blast off data over usb
<i509vcb[m]>
The alternative is run from RAM, but that's also another issue
<dygear[m]>
Yeah, you know what. I can just take my learning from this and use it elsewhere, but make the entire thing GPL. Showing Adafruit a working example of their board running Rust (2024 Edition none the less) and getting everything in the easiest way possible over crates.io I think is a huge selling point. Having access to the SD Card is the cherry on top as currently, I don't think their own in house CircuitPython has access to it as of
<dygear[m]>
Yeah, I saw that one too. That was the initial plan. I work primarily as a Paramedic, so I've been thinking about this aspect or the project in between calls. You popping in with that was like perfect timing LOL.
<dygear[m]>
By the way, if anyone sees anything that I got wrong in the read-me please do let me know.
<adamgreig[m]>
Aah sorry everyone, I had tradespeople round til late and 7 just came and went. 6 months since my house flooded and I'm still ripping out floorboards sigh. Thanks for handling the meeting James Munns ❤️
ello has joined #rust-embedded
ello_ has joined #rust-embedded
ello_ has quit [Ping timeout: 246 seconds]
ello has quit [Ping timeout: 246 seconds]
ello has joined #rust-embedded
ello_ has joined #rust-embedded
pcs38 has quit [Quit: leaving]
<i509vcb[m]>
<JamesMunns[m]> "(here's an example of what it..." <- I wonder if there should be some way to describe a whole transaction like the embedded-hal traits?
<i509vcb[m]>
Obviously transaction length needs some limit