<re_irc>
<@j2j4l:matrix.org> dkhayes117: AFAIK, BLE and Bluetooth in general in nrf is still far from ready...
cr19011 is now known as cr1901
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
starblue has joined #rust-embedded
starblue3 has quit [Ping timeout: 272 seconds]
<re_irc>
<@therealprof:matrix.org> nRF is certainly a contender, something from STM32 like an F4 would be another choice.
<re_irc>
<@lachlansneff:matrix.org> This isn't exactly an embedded-rust question, but if I wanted to store logs/data on a storage device that I could remove and look at with a computer, would an SD card be a reasonable choice?
<re_irc>
<@lachlansneff:matrix.org> Does embedded rust have a good sd card library?
<re_irc>
<@therealprof:matrix.org> Yes and yes. I don't think there're a lot other choices?
<re_irc>
<@lachlansneff:matrix.org> Yeah that only other thing I can think of is storing it in flash, and then report over bluetooth or something later on.
<re_irc>
<@lachlansneff:matrix.org> I guess that doesn't really quite fit in the criteria I stated
<re_irc>
<@lachlansneff:matrix.org> Well, basically what I'm planning on doing is a thrust-vector control system for a hobby rocket, so I need something that can withstand the vibration and impacts.
<re_irc>
<@9names:matrix.org> could also implement USB MSC host on your embedded device, but SD card would be easier
<re_irc>
<@adamgreig:matrix.org> SD card will probably survive vibes OK, but you can buy SMD devices that are electrically SD cards, which would be a lot more robust
<re_irc>
<@9names:matrix.org> ah yeah, vibration makes things tricky. i wonder if the connector on the pine64 eMMC module would be more vibration-proof
<re_irc>
<@adamgreig:matrix.org> i once lost a micro SD card in black rock desert when my hobby rocket tore itself to pieces at mach 3 and the airflow ripped the µsd holder off the pcb
<re_irc>
<@adamgreig:matrix.org> and spent like 12 hours scouring the desert floor for this micro sd card
<re_irc>
<@lachlansneff:matrix.org> adamgreig: How do you grab data off them?
<re_irc>
<@9names:matrix.org> did you find it?
<re_irc>
<@adamgreig:matrix.org> no, rip
<re_irc>
<@9names:matrix.org> :'(
<re_irc>
<@adamgreig:matrix.org> Lachlan Sneff: best bet is probably usb/rf via the mcu
<re_irc>
<@adamgreig:matrix.org> but it's still a lot faster to write than onboard flash or spi flash
<re_irc>
<@adamgreig:matrix.org> and you can use your mcu's sd card peripheral to interface (assuming it has one) which is v fast
<re_irc>
<@adamgreig:matrix.org> yea, if you're not a dummy like me and keep the pcb inside the rocket at all times it should be fine
<re_irc>
<@lachlansneff:matrix.org> Jeez, wow
<re_irc>
<@lachlansneff:matrix.org> That's a girthy hobby rocket
<re_irc>
<@adamgreig:matrix.org> i had a second avionics, same pcb, that did manage to hold onto its sd card, and that one wrote write until the wiring was all ripped apart etc etc, so vibes weren't the issue
<re_irc>
<@therealprof:matrix.org> SD cards built-in flash controllers. For raw flash you have to do wear levelling and magic yourself.
<re_irc>
<@therealprof:matrix.org> That makes SD cards very interesting for data logging applications.
<re_irc>
<@adamgreig:matrix.org> therealprof: yea, I'm talking about these niche solder-down SD cards in like SOIC packages
<re_irc>
<@adamgreig:matrix.org> rather than raw flash
<re_irc>
<@therealprof:matrix.org> Also there're "enhanced specs" industrial versions.
<re_irc>
<@therealprof:matrix.org> I was refererring to an earlier message from Lachlan Sneff.
<re_irc>
<@adamgreig:matrix.org> things to beware of with sd cards: many will occasionally need to pause writes while they do housekeeping, maybe for 100ms, so keep a decent buffer on your side
<re_irc>
<@therealprof:matrix.org> adamgreig: You mean eMMC probably?
<re_irc>
<@adamgreig:matrix.org> no
<re_irc>
<@adamgreig:matrix.org> distinct thing
<re_irc>
<@adamgreig:matrix.org> emmc is more of a pain due to typically large bga packages and higher pin count
<re_irc>
<@therealprof:matrix.org> Ah okay. eMMC would also be an option. 😉
<re_irc>
<@adamgreig:matrix.org> but yea i think you will be totally fine with µSD
<re_irc>
<@lachlansneff:matrix.org> Say I was using RTIC. How should I go about writing the logs to an SD card during idle times?
<re_irc>
<@lachlansneff:matrix.org> Would I have to worry about a write being interrupted by other things?
<re_irc>
<@adamgreig:matrix.org> you'd usually have the idle task fill a write-sized buffer (maybe 512b or 4k or something), then trigger a DMA transfer when it's ready
<re_irc>
<@adamgreig:matrix.org> it won't all be happy DMA because of managing the filesystem and so forth, assuming you do use a filesystem
<re_irc>
<@adamgreig:matrix.org> but anything timing-critical will use the mcu's sd card peripheral (or spi interface)
<re_irc>
<@adamgreig:matrix.org> so shouldn't matter if it's interrupted
<re_irc>
<@lachlansneff:matrix.org> I don't think the mcu I'd be using has an SDMMC
<re_irc>
<@adamgreig:matrix.org> (probably you use some queues from heapless or bbqueue or something to shuttle data from the other tasks into the idle task's buffer)
<re_irc>
<@therealprof:matrix.org> therealprof: I take that back, you're right, it's a pain and not suitable; I was thinking of something else but can't remember what it was called.
<re_irc>
<@adamgreig:matrix.org> ah, shame, it's a lot quicker, but spi works too and basically same deal
<re_irc>
<@lachlansneff:matrix.org> If I don't use a filesystem, how would I go about reading it later on?
<re_irc>
<@adamgreig:matrix.org> computer can read it raw
<re_irc>
<@adamgreig:matrix.org> obviously more of a pain
<re_irc>
<@lachlansneff:matrix.org> I'd have to mount it as a block device or somethin?
<re_irc>
<@adamgreig:matrix.org> on linux it's the difference between "mount -t vfat /dev/sda1 /mnt/sdcard" and then "cat /mnt/sdcard/log.txt" and just "cat /dev/sda"
<re_irc>
<@lachlansneff:matrix.org> Gotcha
<re_irc>
<@adamgreig:matrix.org> you wouldn't really need to mount it at all, I guess, or maybe in loopback for perms or something
<re_irc>
<@firefrommoonlight:matrix.org> j2j4l: I was surprised about this, given that's the chip's main target
<re_irc>
<@adamgreig:matrix.org> I would probably try and use a filesystem, though I haven't tried in rust I understand they exist and it will make life easier for not much overhead
<re_irc>
<@9names:matrix.org> I've used a "fixed" filesystem, with a hardcoded FAT and a single large file so you can do raw read/write from the micro without any filesystem
<re_irc>
<@adamgreig:matrix.org> nice, that's an option too
<re_irc>
<@adamgreig:matrix.org> if only i'd done that rocket in rust back in 2014, maybe it would have survived the aerodynamic loading better 🤔
<re_irc>
<@thalesfragoso:matrix.org> embedded-sdmmc(-rs) uses 512 bytes read/writes, so if you use DMA for that you can sustain some interruptions
<re_irc>
<@therealprof:matrix.org> Yeah, FAT is pretty much the defacto standard for such applications.
<re_irc>
<@therealprof:matrix.org> Trivial to implement and ubiquitously supported.
<re_irc>
<@thalesfragoso:matrix.org> I have a fork of embedded-sdmmc working with a embassy driver if async floats your boat
<re_irc>
<@j2j4l:matrix.org> therealprof: Fragmentation can be real pain. Given you write logs in small chunks. But if it's for a short-lived rocket, than should be ok 🙂
<re_irc>
<@adamgreig:matrix.org> somewhere in between, it was operating the various pyrotechnic recovery systems so did IMU and online state estimation and so on, but no active control of trajectory
<re_irc>
<@adamgreig:matrix.org> much harder to get permission to launch active guided rockets at this scale
<re_irc>
<@9names:matrix.org> j2j4l: that's why the fixed option is good. single contiguous file at a fixed offset, no need for your MCU to ever read/update the FAT while logging
<re_irc>
<@lachlansneff:matrix.org> Actually, just thought of this: what about writing data to a flash chip, and then dumping that onto the sd card as a well-behaved file at landing?
<re_irc>
<@thalesfragoso:matrix.org> firefrommoonlight: The hardware part is easy, the hard part is the stack
<re_irc>
<@thalesfragoso:matrix.org> but we do have rubble and nrf-softdevice
<re_irc>
<@adamgreig:matrix.org> in my experience (using a 4-bit wide sd card interface and sd peripheral, not SPI), there was more than enough time to manage the FS and write out to the file, the write bandwidth is pretty high
<re_irc>
<@lachlansneff:matrix.org> Well, doesn't hurt to try
<re_irc>
<@adamgreig:matrix.org> you could also just write to a single large pre-allocated file at runtime and then after the flight read from that and write back to a small file, without needing a second flash chip
<re_irc>
<@lachlansneff:matrix.org> What's the danger of corrupting the file system if the card pops out?
<re_irc>
<@adamgreig:matrix.org> I guess a raw flash IC would have more deterministic write timings though
<re_irc>
<@adamgreig:matrix.org> eh
<re_irc>
<@adamgreig:matrix.org> assuming you tidy up after each block, you might lose the final block, but it was probably only half written anyway, and you can probably recover it manually if you really need to later
<re_irc>
<@adamgreig:matrix.org> so i wouldn't expect it to be an issue
<re_irc>
<@lachlansneff:matrix.org> Awesome. This is great info
<re_irc>
<@lachlansneff:matrix.org> Thank you everyone
<re_irc>
<@lachlansneff:matrix.org> One more thing: Where do y'all suggest ordering pcbs that can do PnP at the factory?
<re_irc>
<@lachlansneff:matrix.org> I normally order from jlcpcb, but the shipping time is very long
<re_irc>
<@adamgreig:matrix.org> can you just pay them more? I usually get <=1 week shipping from them to the UK, dunno what it's like for you
<re_irc>
<@adamgreig:matrix.org> suspect you'll pay a bunch more for locally assembled boards
<re_irc>
<@lachlansneff:matrix.org> Ah, you’re probably right
<re_irc>
<@lachlansneff:matrix.org> Well, I have the next week off to design the board and the TVC system itself, so I’m sure I’ll have a bunch of questions then
<re_irc>
<@adamgreig:matrix.org> nice!
<re_irc>
<@adamgreig:matrix.org> what sort of motors?
<re_irc>
<@lachlansneff:matrix.org> Probably just some metal-geared servos from adafruit
<re_irc>
<@lachlansneff:matrix.org> There’s not a lot of force here
<re_irc>
<@adamgreig:matrix.org> delta arm sort of thing?
<re_irc>
<@lachlansneff:matrix.org> Yes, if I’m visualizing what you mean by that correctly
<re_irc>
<@lachlansneff:matrix.org> I just decided to do this project this morning, so it’s still pretty fluid
<re_irc>
<@adamgreig:matrix.org> heh, fun
<re_irc>
<@adamgreig:matrix.org> sounds fun!
<re_irc>
<@lachlansneff:matrix.org> I find that I need to immediately get as much done as possible when I start or I just keep putting it off forever haha
<re_irc>
<@lachlansneff:matrix.org> That’s what happened to my atomic force microscope project
<re_irc>
<@lachlansneff:matrix.org> I designed some boards and got them shipped, and learned how to program FPGAs, but the early phases took so long that I lost interest
<re_irc>
<@adamgreig:matrix.org> is that how you ended up writing a gtkwave replacement?
<re_irc>
<@lachlansneff:matrix.org> Yeah
<re_irc>
<@lachlansneff:matrix.org> I’ve been periodically working on that though
<re_irc>
<@lachlansneff:matrix.org> I got fed up with gtkwave and decided that the world needed something better
<re_irc>
<@lachlansneff:matrix.org> Of course I haven’t gotten it in a usable state yet
<re_irc>
<@lachlansneff:matrix.org> I keep rewriting how it stores and processes value changes
fabic has quit [Ping timeout: 258 seconds]
emerent has quit [Remote host closed the connection]
<re_irc>
<@lachlansneff:matrix.org> Ah, turns out the MCU I have does have an SDIO peripheral
<re_irc>
<@lachlansneff:matrix.org> I’ll definitely try that out
<re_irc>
<@henrik_alser:matrix.org> 🙌
fabic has quit [Ping timeout: 258 seconds]
<re_irc>
<@henrik_alser:matrix.org> Heard good things about MacroFab too
<re_irc>
<@jorgeig:matrix.org> Zuubek: I'm in the same boat as you, and I can tell you that RTIC makes things way simpler as a Rust beginner!
<re_irc>
<@jorgeig:matrix.org> started writing code to handle interrupts, mutexes for shared resources, etc. and while it helped me learn, it wasn't sustainable for project use
<re_irc>
<@jorgeig:matrix.org> well it was, it's how I always did it in C, I just didn't wanna bother with it while also learning Rust haha
<re_irc>
<@ryan-summers:matrix.org> I'm very happy to allow RTIC to remove all the boilerplate from my code :)
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
neceve has joined #rust-embedded
fabic has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@stu_:matrix.org> Hey people 👋,
<re_irc>
<@stu_:matrix.org> We are currently working on an RTOS for the Nintendo Switch, which is based on a Cortex-A processor, so we want a good and "rusty" way of interacting with the hardware.
<re_irc>
<@stu_:matrix.org> We already tried using the `cortex-a` crate, however, it is really thin and doesn't give us much of an advantage.
<re_irc>
<@stu_:matrix.org> Thus we decided that we will write our own `cortex-a` like crate, with abstractions for everything that the Cortex-A has to offer.
<re_irc>
<@therealprof:matrix.org> stu_ That sounds most excellent and exciting!
<re_irc>
<@therealprof:matrix.org> Do you have anything to look at already?
<re_irc>
<@therealprof:matrix.org> Have you sketched out a plan for cortex-a already?
<re_irc>
<@stu_:matrix.org> Not yet, as we just started with the project. In a few days we will definitely have something to look at.
<re_irc>
<@stu_:matrix.org> We are currently thinking much about how to structure the crate and what APIs we can provide and how they should look like
tokomak has quit [Ping timeout: 258 seconds]
<re_irc>
<@therealprof:matrix.org> I think a great way to drive this forward is if you had a GH issue somewhere with some context and information. Then can put it on agenda for the WG meetings (happening each Tuesday 20:00 CEST here and everyone is invited to particapte) and have a discussion to get some opinions and maybe come up with a...
<re_irc>
... roadmap.
<re_irc>
<@stu_:matrix.org> Alright, thank you!
<re_irc>
<@stu_:matrix.org> Should the issue be in the `wg` repository or `cortex-a`?
<re_irc>
<@therealprof:matrix.org> `cortex-a` sounds good. At least that will also alert the Cortex-A team which usually is not chatting here.
<re_irc>
<@therealprof:matrix.org> If you would be able to link the issue here (once created) that'd be great, otherwise the active people would miss it. ;)
<re_irc>
<@stu_:matrix.org> Will do that!
<re_irc>
<@stu_:matrix.org> I'm pretty sure that we will also have a general structure of the crate ready by Thursday.
<re_irc>
<@i_am_the_carl:matrix.org> I used Tokio on desktop recently and loved how simple it was to get high efficiency IO with a single thread.
<re_irc>
<@i_am_the_carl:matrix.org> I was wondering, has anyone used something like Tokio on an embedded device?
<re_irc>
<@i_am_the_carl:matrix.org> I feel like it could work if you just leave out the standard library and runtime.
<re_irc>
<@thalesfragoso:matrix.org> i_am_the_carl: Does embassy count ?
<re_irc>
<@i_am_the_carl:matrix.org> I didn't know it was a thing until you mentioned it.
<re_irc>
<@i_am_the_carl:matrix.org> This looks really nice. Thank you for pointing me that way.
<re_irc>
<@thalesfragoso:matrix.org> No problem, there's also TockOS
<re_irc>
<@thalesfragoso:matrix.org> But I haven't used it
<re_irc>
<@i_am_the_carl:matrix.org> It looks like it's still pretty early in development but that's most of the Rust embedded ecosystem so I'm fine with that.
<re_irc>
<@i_am_the_carl:matrix.org> Honestly your "unstable" features are more stable than some "stable" features from companies that charge far too much for their embedded compilers.
<re_irc>
<@thalesfragoso:matrix.org> And GAT won't be incomplete anymore :)