<rwnd[m]>
I might try it privately, the embassy suggestion seems p cool
pflanze has quit [Read error: Connection reset by peer]
pflanze has joined #rust-embedded
ivche has quit [Ping timeout: 268 seconds]
lockna_ has quit [Server closed connection]
lockna has joined #rust-embedded
<AlexandervanSaas>
<geky[m]> "Plus humans tend not to pull out..." <- If the whole device is powered mid write of then you don't need to pull the sd card to get corruption.
<AlexandervanSaas>
Apparently one strategy to avoid corruption is pre-allocating a file so the metadat doesn't need to be updated as data is written to the file.
<AlexandervanSaas>
as far as I can see the different Rust crates for FAT don't expose low-level control like this (yet)
<Alistair[m]>
<AlexandervanSaas> "> <@al:alistair23.me> I know you..." <- I don't think there are any examples of it with an SD card. That would be up to you to do
<AlexandervanSaas>
That's fine of course. I'm happy to mess around with this
<ryan-summers[m]>
Oh sorry, you prefaced saying you were already using that
<ryan-summers[m]>
<AlexandervanSaas> "> <@al:alistair23.me> I know you..." <- Why does sequential-storage have a boundary at 16MB? As far as I understand it, it uses u32s internally for pointers
<diondokter[m]>
It doesn't
<diondokter[m]>
Everything is u32 yeah
<ryan-summers[m]>
You could easily write an embedded-storage adapter for an SD card that just pretends to be a flash NOR chip
<AlexandervanSaas>
Yeah sorry, I meant that NOR flash chips have a 16MB limit (correct?)
<ryan-summers[m]>
I don't see why they'd have a limit there?
<diondokter[m]>
ryan-summers[m]: Only thing is that NAND flash is much less reliable
<AlexandervanSaas>
SD cards do internal wear leveling
<AlexandervanSaas>
You can't address the raw flash directly
<diondokter[m]>
NAND has way more bitflips IIRC
<ryan-summers[m]>
Yeah, with the downside that your latency is variable because there's a little M0+ or something inside the SD card running the wear leveling algorithms
<ryan-summers[m]>
I've used eMMC flash (which I believe is NAND) without problems in the past
<ryan-summers[m]>
eMMC is basically just soldered-on SD card
<AlexandervanSaas>
ryan-summers[m]: I read something that they use 24 bit addresses. I also haven't been able to find any bigger ones
<AlexandervanSaas>
(what you can use with SPI)
<AlexandervanSaas>
s/what/that/
<ryan-summers[m]>
I think all SD cards support a SPI interface
<ryan-summers[m]>
Its part of the JEDEC standard to boostrap things from what I recall
<AlexandervanSaas>
I meant SPI flash chips
<ryan-summers[m]>
Oh, sorry yeah
<ryan-summers[m]>
As an aside, 16MB is an absurd amount of memory. Are you writing like raw strings to it? You could potentially compress the logs using something like defmt as an alternative approach
<ryan-summers[m]>
Also you could move to something like QSPI external flash, lots of chips have QSPI or OCTOSPI drivers for larger external flash memorys and will handle mapping them for you automagically
<AlexandervanSaas>
I'm logging sensor data serialized with postcard. For debugging I want to log 10-50 bytes at ~100Hz
<ryan-summers[m]>
Yeah you could look at something like an eMMC chip too. That's what I did when I was writing firmware for a camera that was streaming MP4 at 60Mbps
<ryan-summers[m]>
And the benefit there is you can go pretty large for pretty cheap. I think lots of the chips are behind NDAs from the manufacturers though, but an SD card is essentially the same. Not sure why you couldn't use that for sequential-storage
<AlexandervanSaas>
I assume it's possible but I haven't looked into it yet. Using FAT seemed convenient because you can easily get the files from the SD card.
<ryan-summers[m]>
If you want to eject it out of your embedded device and then look at it on a PC, yeah. If you have to transmit it via USB for offload or something it doesn't matter much
<AlexandervanSaas>
Using sequential storage on top on an SD card that already does wear leveling seems a bit redundant.
<ryan-summers[m]>
But even if you used it in raw mode you could write alittle PC-side util that decoded the raw contents of the SD card without mounting it
<ryan-summers[m]>
Where you could probably use sequential-storage again to handle deserialization on the std target
<ryan-summers[m]>
* Where you could probably use sequential-storage again to handle deserialization on the std PC side
<diondokter[m]>
AlexandervanSaas: Well, it does more than just that to be fair.
<diondokter[m]>
It's well tested, has some nice datastructures and does CRC checks.
<AlexandervanSaas>
Ha yeah sorry I didn't mean to sell it short
<JamesMunns[m]>
Personal announcement, just put up a new podcast episode talking to folks at RustNL and Oxidize: https://onevariable.com/blog/cwj-ep017-on-the-road/, first half with folks from the organizing team, second half with thejpster talking about Rust and prototyping and the Neotron :)
Henk[m] has joined #rust-embedded
<Henk[m]>
Do I just reply to in the GH discussion to add points for the agenda?
<JamesMunns[m]>
(oh, adamgreig, do you want announcements there too? or announcements here and agenda there?)
<adamgreig[m]>
I've been copying announcements into the top description for the record
<Henk[m]>
Personal announcement: I'm leaving Tweede golf, sadly, and will start at Mainmatter in August. I'll still be doing Rust, but the embedded stuff is just going to be on a hobby basis
<JamesMunns[m]>
Congrats!
<Henk[m]>
Thanks!
<Henk[m]>
* Thanks! <3
<Henk[m]>
* Thanks! ❤️
<adamgreig[m]>
ok, let's get started! the leftover points from last week were about the cortex-m-rt detecting linker script idea, and scheduling a meeting to discuss the project goals proposals
adamhott[m] has joined #rust-embedded
<adamhott[m]>
<JamesMunns[m]> "Announcement: Foundation..." <- I've got this side project I've been working on, a quadruped robot. I'd like to submit a proposal for it to create tools to learn how to build robots in rust with this, submit a proposal for a grant. But I'd need to be on the WG. I already started working on the documentation with Henk, can I be added to the WG under the documentation group so I can submit a proposal?
<adamhott[m]>
What I plan to contribute to the WG is the Discovery Book stuff.
<adamgreig[m]>
I understand the grants are specifically for working on WG projects/goals
<adamhott[m]>
ah ok
<adamgreig[m]>
the project fellowships, anyway
<adamhott[m]>
Not like just because you're on the WG, you can submit a proposal for whatever.
<JamesMunns[m]>
Yeah, there's two categories, that I'm just realizing are a little confusing:
<JamesMunns[m]>
1. "Project Fellowships": Supporting ongoing work done by the project/wgs
<JamesMunns[m]>
2. "Project Goal Fellowships", specifically the accepted Project Goals we talked about last week
<JamesMunns[m]>
(there's also a community fellowship grant category but more clearly named :D)
<adamhott[m]>
Ok I'll submit a proposal to the WG, who do I sent it to?
<JamesMunns[m]>
Maybe add to the agenda next week to discuss once you have your ideas together? Not sure if we have a process for "add a new book", etc.
<adamhott[m]>
Ok, I'll add it for next week. Sounds good!
<adamgreig[m]>
on the scheduling meetings front, the other thing we could schedule is a meeting to go over the remaining triage issues; maybe goals next week and triage two weeks after that?
<adamgreig[m]>
I'm not sure if the goals needs a full week or not, or if we want to put another impl-meeting in between those
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Which triage issues again?
<JamesMunns[m]>
I think this was "burn down all the long-open issues on all the wg/ repos"?
therealprof[m] has joined #rust-embedded
<therealprof[m]>
bartmassey[m]: Open GH issues.
<bartmassey[m]>
Ah that. +1
<adamgreig[m]>
OK, let's plan for goals july 23 and triage aug 6 then
<adamgreig[m]>
looks like James Munns's item about the PR is already resolved
<adamgreig[m]>
bartmassey, want to say anything about discovery status?
<JamesMunns[m]>
adamgreig[m]: ty dirbaio!
<bartmassey[m]>
I think the minutes have most of the interesting bits. Everybody cool with me moving ownership of the book repo to rust-embedded sometime this week? I won't update the main branch until we've resolved the publishing stuff.
<therealprof[m]>
@jamesmunns:beeper.com Any notes from your side bar you had after the last meeting?
<JamesMunns[m]>
General explaining and a lot of chat messages I need to turn into docs
<JamesMunns[m]>
#wg-embedded-static-mut:matrix.org - if anyone wants to go back and read :)
<adamgreig[m]>
bartmassey[m]: sounds good. so that's moving discovery-mb2 to rust-embedded and keeping the same name?
<bartmassey[m]>
I've been working on a super-secret plan to save static mut 😀. Discussed it with a few people — will bring it here when it's ready.
<bartmassey[m]>
adamgreig: yes, that
<adamgreig[m]>
sgtm
<therealprof[m]>
Same.
<adamgreig[m]>
I think you should have the relevant permissions but lmk if not
<bartmassey[m]>
Thanks!
<JamesMunns[m]>
bartmassey[m]: I'd be interested to hear :D
<bartmassey[m]>
I've looked like an idiot in public enough lately, so won't discuss it until it's baked at least halfway. Will say that failing some such plan I'm ready to give up on static mut as has been discussed for many years apparently.
<adamgreig[m]>
I think that just leaves James Munns's point about a new all-hands then?
<JamesMunns[m]>
Yep! Discussion is ongoing and planning for an all hands in the NL - a bit like RustNL this year, but bigger
<adamhott[m]>
Awesome!
<JamesMunns[m]>
there's not totally clear numbers on how many spots they'll have for WGs, nor what the WGs might look like next year
<JamesMunns[m]>
but for capacity planning, they're interested in rough counts of how many people on the WG would be interested in attending.
<JamesMunns[m]>
(there will likely be SOME space made available to the WG for meetings, like RustNL this year! but not sure if they'd have room for the whole WG)
<JamesMunns[m]>
(there are also discussed venues and cities and some tentative plans - they are at the "check if it would make sense" stage before booking soon-ish)
<therealprof[m]>
Even if I knew the dates, my planning only goes up to April at the moment. 😅
<JamesMunns[m]>
That's way further than me :)
<Henk[m]>
therealprof[m]: That's still very impressive though
<adamgreig[m]>
does anyone have any other points they want to discuss this week?
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]>
therealprof[m]: Same here but 2024
<Henk[m]>
You guys plan?
<bartmassey[m]>
Thanks all!
<Henk[m]>
See you in a couple of weeks, I'm on vacation till August 13th
<Henk[m]>
Bye bye!
<henrik_alser[m]>
Henk[m]: Enjoy! 🥳
<JamesMunns[m]>
Thanks all!
<adamhott[m]>
Thanks everyone!
<adamgreig[m]>
thanks all :) see you next week to discuss project goals!
<rmsyn[m]>
thanks all <3
<AlexandervanSaas>
diondokter ryan-summers I'm trying get sequential-storage working on an SD card using the SD SPI driver from here https://github.com/MabezDev/embedded-fatfs. It's a little awkward because it requires implement the `NorFlash` trait for the SD card driver which doesn't really make sense.
<dirbaio[m]>
also I don't think read/write are guaranteed to be called with multiples of the block size
<dirbaio[m]>
so you probably want to "cache" one block
<geky[m]>
<AlexandervanSaas> "I found this issue in the..." <- I just wanted to say interesting find, it's funny that you can write metadata before data in FAT. The idea is so backwards to modern logging/cow fs design
<AlexandervanSaas>
<dirbaio[m]> "also I don't think read/write..." <- I'm taking a walk rn but zi think embedded-storage says addresses need to be aligned.
<dirbaio[m]>
erase is aligned to erase size (sector size)
<dirbaio[m]>
ah you've set READ_SIZE and WRITE_SIZE to the block size, 512 bytes
<dirbaio[m]>
yeah in that case they'll be aligned
<dirbaio[m]>
but then sequential-storage will probably waste a lot of space with padding (?)
<dirbaio[m]>
because those are typically 1 byte or 4 bytes
<dirbaio[m]>
only erase size is typically "big"
<dirbaio[m]>
on actual nor flashes
<Vicente[m]>
leds.blue.blink_loop(2).await;
<Vicente[m]>
I'm on the point of doing https requests okay on my RP pico w with reqwless. Now I want to connect to a websocket server. Has anyone experience on this who can guide me on what are the best packages/advices to do it?
<AlexandervanSaas>
<dirbaio[m]> "ah you've set READ_SIZE and..." <- Don't SD cards have a fixed 512 byte block size?
<AlexandervanSaas>
I guess I could read a block, update it in memory and write it back.
<AlexandervanSaas>
Is that what you mean with "cache"?
Socke has quit [Server closed connection]
Socke has joined #rust-embedded
<AlexandervanSaas>
Yeah I guess that could work. I'll tinker with it tomorrow.
jxsl has quit [Ping timeout: 252 seconds]
<diondokter[m]>
<dirbaio[m]> "but then sequential-storage will..." <- Yep, because of that the word size is limited to 32 bytes max. Not really a technical reason, but something is likely wrong if the word size is larger than that
<diondokter[m]>
I guess it would help if s-s had a flush function...
<diondokter[m]>
But the traits don't have that
<diondokter[m]>
<AlexandervanSaas> "Yeah I guess that could work. I..." <- Yeah, that's probably what you have to do
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
M9names[m] has joined #rust-embedded
<M9names[m]>
<AlexandervanSaas> "Don't SD cards have a fixed..." <- No, block size is not fixed. You'll need to query your card to check the block size
<diondokter[m]>
M9names[m]: If that's true, then that might be a problem because the traits have defined this as a constant.
<diondokter[m]>
Is there a reasonable upper bound like 4k? And is it always a nice power of 2?
<M9names[m]>
I'd have to re-check the spec, have not looked at it in a long time and don't have the specifics in my brain any more
<M9names[m]>
A quick glance at the Wikipedia page suggests that even though the block size is variable, later standards mandate that it is always 512. So maybe my advice has been obsolete for a decade or two :/