<re_irc>
<James Munns> Unsure if "Pin<PIOA, Gpio<Unconfigured>, 23>" will offend sensibilities, but at least it's easy to convert to a degraded type if you want.
<re_irc>
<dirbaio> oh and it's not listed in the PR, but the new style allows both "Input::new(pin)" and "Input::new(&mut pin)"
<re_irc>
<James Munns> Fair, and I guess for less flexible parts than the nrf52 where you can't remap everything, you can still fall back to taking specifically a P0_23 or whatever?
<re_irc>
<dirbaio> which is handy if you want to use a pin as input/output temporarily
<re_irc>
<James Munns> (e.g. more like STM32's limited reconfig)
<re_irc>
<dirbaio> there's traits like "SckPin<T: Instance>", the drivers' "new()" fns take those
<re_irc>
<dirbaio> this means you can end up with "new()" fns with lots of params
<re_irc>
<dirbaio> but that's better than a "PINS" with lots of generics IMO
<re_irc>
<dirbaio> especially because the pin generics are only on "new()", not on the whole struct
<re_irc>
<James Munns> Yeah, I figured I'd probably type-erase the GmacPins, and just have a bunch of different constructors or builders or whatever.
<re_irc>
<James Munns> "store the destination config in the target (e.g. GMAC) pin trait/bounds" is a clever trick, and I really like that.
<re_irc>
<dirbaio> the whole struct is just "Spi<'a, SPI1>", not "Spi<'a, SPI1, PA4<Output<Alternate<AF4>>, PA5<Output<Alternate<AF4>>, PA6<Output<Alternate<AF4>>, PA7<Output<Alternate<AF4>>>"
<re_irc>
<James Munns> Instead of bounding on it, just do it.
<re_irc>
<James Munns> Yeah, fair
<re_irc>
<James Munns> tho in nrf-hal we already yeeted that by taking specifically type erased pins
<re_irc>
<James Munns> but yeah, I guess its harder to do that in stm32 land with limited reconfig
<re_irc>
<dirbaio> nrf is easy because any periph can use any pin yep
<re_irc>
<dirbaio> there's no "AF" concept even
<re_irc>
<James Munns> (Cheap cortex M7/M33 with a way higher clock speed and no radio from nordic when)
<re_irc>
<dirbaio> will be interesting to see what they do if they make chips with 100-200 pins... their "any periph can use any pin" probably scales horribly
<re_irc>
<James Munns> Yeah, no idea how they mux that internally
<re_irc>
<dirbaio> maybe they're cheating, they list many pins as "low frequency IO only"
<re_irc>
<James Munns> they'll still often work when connected to periphs though
<re_irc>
<dirbaio> we've shipped hardware with QSPI on "low frequency IO only" by mistake π
<re_irc>
<dirbaio> and it still works yup
<re_irc>
<dirbaio> so it doesn't seem to be a "hard cap"
<re_irc>
<dirbaio> dunno
<re_irc>
<James Munns> Yeah, some of those recs are for EMI noise too tho
<re_irc>
<James Munns> like "don't run HS QSPI near the antenna"
<re_irc>
<James Munns> tho I know the NFC lines also do have different qualities
<re_irc>
<James Munns> Anyway, thanks for the links! I might play around with that. Honestly I thought about only implementing type erased pins to begin with
<re_irc>
<dirbaio> with inside-out you can reuse the same Input/Output struct with both erased and non-erased
<re_irc>
<dirbaio> :D
<re_irc>
<dirbaio> "Input<PB9>", "Input<AnyPin>"
<re_irc>
<James Munns> Yeah, makes sense!
<re_irc>
<James Munns> Anyway, already shaved too many yaks on this one (polished HAL wasn't a requirement for this work, but still nice to have and a good thing to do), need to wrap up some other stuff for it tomorrow so I can "ship it".
<re_irc>
<dirbaio> how different is it from the other ATSAMxxx's?
<re_irc>
<James Munns> uhh, this is in a class that includes ATSAME, V, and S I think? Totally different from ATSAMD etc
<re_irc>
<James Munns> (this is basically their "H7" part line)
<re_irc>
<dirbaio> oh, huh
<re_irc>
<dirbaio> i'd still expect they'd have reused _some_ IP though, like H7 vs other stm32s?
<re_irc>
<James Munns> At least when searching, I didn't find any (rust) ones with the same GMAC IP, which was the bulk of the work
<re_irc>
<James Munns> really SPI is the only other peripheral I brought up, and that only took an hour or two to write
<re_irc>
<James Munns> "SAM Microcontrollers With MAC" are the ones that (up to now) had no HAL at all.
<re_irc>
<James Munns> Totally possible other peripherals (timers, adcs, serial ports, whatever) could borrow from some of the other SAM HALs, but like I said, I didn't really use any of those. (this gig is basically an ethernet connected thing that MOSTLY talks to connected SPI parts)
<re_irc>
<James Munns> the GMAC IP _is_ shared with their PIC18/PIC32 line, but that also doesn't help lol
<re_irc>
<dirbaio> oh no, not the PICs D:
<re_irc>
<James Munns> Though I think they do use the same GMAC IP in the (Cortex-A) SAM5D line, if I ever start using those for MnemOS
<re_irc>
<dirbaio> at uni there was a course using PIC18Fs
<re_irc>
<dirbaio> weird segmented/paged memory, weird compiler, weird calling convention that didn't use a stack so you couldn't write recursive code D:
<re_irc>
<James Munns> I worked on a contract (mostly HW) gig once where the main CPU was a PIC32 that was running Objective C.
<re_irc>
<James Munns> I asked to see their ISR for counting events (my external device was getting different counts than their hardware), and they sent me an Objective C file, and my brain short circuited
<re_irc>
<James Munns> Looked up their firmware team, sure enough, a bunch of ex-Apple engineers.
<re_irc>
<dirbaio> I hope they didn't use ARC at least?
<re_irc>
<James Munns> no idea
<re_irc>
<James Munns> they only shared like one file with me, and I don't have it anymore (and don't really understand enough Objective-C to really know what I was looking at then)
<re_irc>
<dirbaio> "old" objc manually manages memory like C with malloc/free
<re_irc>
<dirbaio> "new" objc makes every class heap-allocated automatically, and pointers are Arc<T>'s π
<re_irc>
<James Munns> ahhh, gotcha.
<re_irc>
<James Munns> Yeah, no idea.
<re_irc>
<dirbaio> which would suck for firmware :P
<re_irc>
<dirbaio> so probably not
<re_irc>
<James Munns> It was a fairly chunky chip if I remember correctly, like a meg of RAM
<re_irc>
<dirbaio> and Swift has inherited the "auto-ARC" thing for classes
<re_irc>
<dirbaio> and they're now talking about using Swift for embedded π€π
<re_irc>
<dirbaio> good luck making it no-alloc
<re_irc>
<James Munns> Yeah, I saw that. There was some issue where they were like "somehow rust on embedded is now popular, don't they know rust sucks to use?!?!"
<re_irc>
<dirbaio> swift is weird
<re_irc>
<kelleyk> New guy here, but Rust has been the most pleasant embedded ecosystem to pick up among anything I've ever worked with.
<re_irc>
<kelleyk> I went zero to an IP stack and a half-dozen I2C peripherals in maybe three or four light evenings.
<re_irc>
<kelleyk> (Probably mostly due to a lot of effort from folks here... so thanks!)
<re_irc>
<James Munns> > As I know, only Swift and Rust announce themselves are (modern) system-level languages in recent decades. When I first have the thought of porting Swift to the embedded world, I have compared Swift and Rust carefully. My conclusion is that Rust is too complicated for application development. But now, in 2022, you can see Rust has already gained a reputation as a system-level programming language. More and more...
<re_irc>
... people try to use Rust in embedded development 4 and they have really active community 8. Unbelievable, are people gluttons for punishment nowadaysπ ? Come on! Swift! We can do this!
<re_irc>
<dirbaio> class instances are Arc'd, but they didn't go with a full-on garbage collector, so there are weird corners of the language that have "shitty borrow checkers"
<re_irc>
<dirbaio> like "@escaping" attributes in closures
<re_irc>
<dirbaio> it's... odd
<re_irc>
<dirbaio> class instances are Arc'd, but they didn't go with a full-on garbage collector, so there are weird corners of the language that have "shitty mini borrow checkers"
<re_irc>
<dirbaio> funnily, the type/trait system is identical to Rust's
<re_irc>
<James Munns> Hey, I'm 100% for anyone (zig, swift, tinygo) messing around with embedded
<re_irc>
<James Munns> more fresh blood in the field, the better ideas we'll have to steal and start using.
<re_irc>
<dirbaio> even js or python! π»
<re_irc>
<James Munns> Sure, no gatekeeping here.
<re_irc>
<dirbaio> yeah, i'm interested to see what they come up with as well
<re_irc>
<James Munns> circuitpython is _crazy_ effective, especially for arduino-level prototyping and one-offs.
<re_irc>
<dirbaio> swift also has async/await π
<re_irc>
<dirbaio> (I dont' think it can do no-alloc though)
<re_irc>
<James Munns> Honestly tho, I'm interested to see how esp32's "provide a std" approach goes. I've always wanted it to be a thing, at least for bigger chips, and they are doing it about how I would have recommended it.
<re_irc>
<James Munns> like: not a great choice for cost-optimized products
<re_irc>
<James Munns> could be CRAZY good for prototyping/hobbyist stuff tho.
<re_irc>
<dirbaio> there's also a zephyr rust std port (hopelessly outdated though)
Socke has quit [Ping timeout: 276 seconds]
<re_irc>
<James Munns> yeah
<re_irc>
<James Munns> riot-os has been pretty active IIRC
<re_irc>
<dirbaio> I tried to see if I could run async/await on it, before starting embassy
<re_irc>
<dirbaio> hey, it's had some updates, it has an executor now
<re_irc>
<James Munns> (sorry, they => riot-os)
<re_irc>
<dirbaio> ah okay
<re_irc>
<dirbaio> I gave up because I realized it's a stupid thing to do, because
<re_irc>
<dirbaio> tcp/ip (and all networking, really) is already inherently async
<re_irc>
<dirbaio> Zephry does πMAGICπ to convert that into the blocking POSIX api
<re_irc>
<dirbaio> and then you have to do more πMAGICπ to turn that back into a rust async api
<re_irc>
<dirbaio> so in the end you have two layers of πMAGIC BLOATπ, to end up where you started
<re_irc>
<James Munns> Tempted to write a std for mnemos (π eventually π), just so it's easier for people to play around with
<re_irc>
<James Munns> but, will probably just start by building std-ish APIs in the "userspace" crate.
<re_irc>
<dirbaio> Zephyr does πMAGICπ to convert that into the blocking POSIX api
<re_irc>
<dirbaio> and the posix and bsd socket apis are horrible to be honest
<re_irc>
<dirbaio> everything's a file, all you need is an "int fd;"!
<re_irc>
<dirbaio> except not
<re_irc>
<dirbaio> you can only seek on files, you can only setsockopt() on sockets
<re_irc>
<dirbaio> but by the time you flattened everything into an "int fd", you've lost all type safety
<re_irc>
<dirbaio> and again, you got two layers canceling each other out... zephyr mushing everything into "int fd" with vtables everywhere, then rust std trying to convert that back into a sane typesafe api...
<re_irc>
<James Munns> I'm sold, I'm sold, no std :D
<re_irc>
<dirbaio> π₯
Socke has joined #rust-embedded
<re_irc>
<James Munns> Still: "use all the tools you are familiar with" is a compelling argument IMO.
<re_irc>
<James Munns> that being said, just "all the config is handled for me" might be a winning argument, that's a huge part about what is nice about circuitpython/arduino
<re_irc>
<James Munns> (and might be a good way to lower the barrier for folks who are just "testing the embedded rust waters", especially if there is a path to "production-ing" a relatively reasonable codebase)
<re_irc>
<dirbaio> for sure, for sure
<re_irc>
<James Munns> like, "OS, give me a SPI object that supports e-h async apis" might be a pretty slick middle ground
<re_irc>
<dirbaio> that's a HAL :D
<re_irc>
<James Munns> ehhhhhhhhhhh
<re_irc>
<James Munns> yes and no
<re_irc>
<James Munns> I mean, you COULD write a HAL like that
<re_irc>
<James Munns> but no one has.
<re_irc>
<dirbaio> what'd be the difference with today's hals?
<re_irc>
<James Munns> basically, "convenience at the cost of configurability"
<re_irc>
<James Munns> like, most hobbyist users don't care if they can change EVERY low level setting
<re_irc>
<dirbaio> with today's hals you can get an SPI with 3 lines of code
<re_irc>
<James Munns> you tell them "these are the SPI ports, these are the I2C ports, these are the ADCs, the rest are GPIOs". you can also copy and paste code from one target to another.
<re_irc>
<James Munns> I think we're a lot better than we were years ago! but like, the nrf52 hal does NOT look like any of the ATSAM HALs.
<re_irc>
<James Munns> (embassy's hal might be the one exception)
<re_irc>
<dirbaio> working spi in one statement! :D
<re_irc>
<James Munns> like, yeah, it's not THAT far
<re_irc>
<James Munns> but there's like 20 lines less you have to explain to a beginner.
<re_irc>
<dirbaio> no owned peripherals?
<re_irc>
<James Munns> The kernel owns the peripherals.
<re_irc>
<James Munns> you own a handle.
<re_irc>
<James Munns> (in this case, "new" would panic with a helpful message if you did something wrong)
starblue has joined #rust-embedded
<re_irc>
<James Munns> maybe slap a "?" on the new if that's not acceptable.
<re_irc>
<dirbaio> you can try creating spi0 twice, owned peripherals would catch it at compile time
<re_irc>
<James Munns> yup, I get it, not how this is handled.
<re_irc>
I guess you could do that, though then you have to go from "all the peripherals, but unconfigured", to configuring each one.
<re_irc>
<James Munns> totally understand this is suboptimal, but it's not about that.
<re_irc>
<dirbaio> for people coming from C, owned peripherals are quite weird/novel yeah
<re_irc>
<dirbaio> they make a huuuuuge difference in correctness imo, though
<re_irc>
<James Munns> (that's the tradeoff that most Rust hals aren't willing to make: imperfection/opinionated decisions)
<re_irc>
<James Munns> but, in a "hosted" environment, you aren't shit out of luck when something goes wrong
<re_irc>
<James Munns> you could can get a helpful error message, maybe even a backtrace.
<re_irc>
<James Munns> again: wouldn't build a high reliability system with this.
<re_irc>
<James Munns> but like, wanna smash on some keys and make flappy bird on a computer you built in an afternoon?
<re_irc>
<James Munns> go for it champ.
<re_irc>
<James Munns> anyway, someday maybe :)
<re_irc>
<dirbaio> if you want something easy to learn then use micropython
<re_irc>
<James Munns> then I can write the book on "hey, you did cool shit with mnemos? Here's how you port it to embassy so you can actually sell it"
<re_irc>
<James Munns> dirbaio: Nope, exactly the wrong opinion for what I'm going for.
<re_irc>
<James Munns> Same tool, different zoom level.
<re_irc>
<dirbaio> Rust itself has a steep learning curve even if you use an "easy hal"
<re_irc>
<James Munns> That's a bug, not a feature.
<re_irc>
<dirbaio> I don't think it's fixable π
<re_irc>
<James Munns> dream big.
<re_irc>
<david> I mean, there's utility in making rust easier to pick up and _use in something_
<re_irc>
<dirbaio> Rust is inherently more complex, having to think about memory management etc
<re_irc>
<david> even for someone who's picked up a bit of rust, using most of the HALs is pretty tough
<re_irc>
<James Munns> dirbaio: Yup, that's exactly what I want to pave over: Rust _lets_ you think about the memory management _when you have to_. Not everyone needs to.
<re_irc>
<James Munns> like, when I write dumbass desktop code and put everything in an Arc<Mutex<lol>>, I'm sure as hell not thinking where the memory goes.
<re_irc>
<dirbaio> you are, just by writing "Arc<>" and ".clone()"
<re_irc>
<James Munns> I'm using Rust because it's a tool I'm familiar with, that is more convenient to use than Python (for me)
<re_irc>
<david> this kind of feels like the classic arduino argument
<re_irc>
<dirbaio> "not worrying about memory management" is writing Go, Java, JS, Python
<re_irc>
<david> you want to get people into electronics/embedded? arduino is pretty good for that
<re_irc>
<david> you are introducing them to some bad habits, but it's a foot in the door
<re_irc>
<James Munns> right, I get it, Rust _let's you know how everything under the hood works_, but that doesn't mean you _have to intrinsically understand it_ to make something that works.
<re_irc>
<James Munns> david: Again, trying to take the center path here: What if people had a good, easy to start with tool, that _didn't_ teach them (outstandingly) bad practices, and had an actual path for when they want/are ready to dig deeper, if ever (and if not that's okay, you still built something cool)
<re_irc>
<James Munns> like, IMO there's no reason Rust has to be any harder to learn/use than circuitpython.
<re_irc>
<dirbaio> lol
<re_irc>
<James Munns> Β―\_(γ)_/Β―
<re_irc>
<James Munns> time for me to go to bed, I guess.
<re_irc>
<dirbaio> that's quite a statement :D
<re_irc>
<david> maybe comparing what you want to arduino was a bit harsh :P
<re_irc>
<James Munns> david: Don't get me wrong! I think Arduino has done more for the field of embedded systems than literally anything else in the last 15-20 years)
<re_irc>
<James Munns> Using it today would be like pulling teeth for me, but I won't throw it under the bus.
<re_irc>
<dirbaio> arduino, rpi
<re_irc>
<James Munns> Despite getting a computer engineering degree, it wasn't until I started fucking around with Arduino that stuff really started making sense to me.
<re_irc>
<david> I agree, I probably would have still gotten in eventually, but arduino was definitely the early foot in the door for me
<re_irc>
<James Munns> Anyway, I'm not making the argument that everyone should write all embedded rust that way. Just that maybe there's a market we're not serving currently, and serving that market might be a long term benefit to the ecosystem.
<re_irc>
<James Munns> But, obviously not everyone (or anyone?) else feels that way :)
<re_irc>
<James Munns> Anyway, nite y'all :)
<re_irc>
<dirbaio> 'nite :D
<re_irc>
<dirbaio> goddamnit it's 4am again
<re_irc>
<James Munns> yep.
<re_irc>
<david> _shakes fist at europe from across the pond_
<re_irc>
<dirbaio> and I haven't finish what I wanted to finish π
<re_irc>
<dirbaio> * finished
<re_irc>
<david> I distracted you with my embassy questions
<re_irc>
<dirbaio> it's on me for checking the chats π
<re_irc>
<firefrommoonlight> James Munns: I wish you luck. My STM32 GPIO module is a macro disaster
<re_irc>
<firefrommoonlight> James Munns: Zig seems pretty slick
<re_irc>
<firefrommoonlight> And there's embedded work going on, but it's very early stages. I think a long way off from being viable
<re_irc>
<firefrommoonlight> It's a lot cleaner than C, which I guess is the intejnt
<re_irc>
<newam> zig has pretty amazing "const" evaluation.
<re_irc>
<dirbaio> zig's not memory safe
<re_irc>
<newam> lacks the same level of memory safety as rust, which is what I am here for though
<re_irc>
<firefrommoonlight> Things like Knurling's flash and debug tools, and the SVD2Rust team allowed rust to take off
<re_irc>
<firefrommoonlight> Not sure how to even approach embedded without something like a PAC
<re_irc>
<newam> firefrommoonlight: An army of people writing drivers by hand (wish I was joking)
<re_irc>
<firefrommoonlight> Memory safety is nice, but Rust's strengths for embedded for me are more overall language niceness. Ie no single thing
<re_irc>
<firefrommoonlight> It's just a nicer, more explict lang than C or C++
<re_irc>
<firefrommoonlight> (The degree depends on the dialect of C/++ being used)
<re_irc>
<firefrommoonlight> The little things add up. No DRY with header files. no_name_spacing_every_struct_enum_and_variant
<re_irc>
<dirbaio> why'd you create a new language in 2022 that's not memory safe is beyond me
<re_irc>
<dirbaio> for embedded maybe, the bar is quite low with C and most stuff are not networky
<re_irc>
<dirbaio> but for non-embedded network services? wtf
<re_irc>
<firefrommoonlight> Yea - I think Zig's niche will be strictly OS level stuff or embedded
<re_irc>
<firefrommoonlight> Rust is flexible in that it can do applications, web programming etc, but I think Rust also really shines in teh low-level domain
<re_irc>
<dirbaio> it's been proven and proven again that humans are not capable of writing code without use-after-frees, double-frees, etc
<re_irc>
<dirbaio> and that matters a lot for OS stuff
<re_irc>
<firefrommoonlight> I mean, Rust is nice for making standalone executables too, but without good GUI tools, it's tough to make desktop apps with
<re_irc>
<dirbaio> see the vulns in linux kernel
<re_irc>
<firefrommoonlight> *I think Rust or Zig could be suitable for graphics programming too
<re_irc>
<firefrommoonlight> Rust has Vulkan bindings, albeit with the original C API (eg Ash). The Rust WGPU project is... I'm not sure yet
<re_irc>
<MasterOfTheTiger> Zig is a lot simpler than Rust, and should theoretically be a lot easier to port to more platforms as well.
<re_irc>
<bugadani> Yeah, I had expected 255 to show up in there
<re_irc>
<yatekii> Hey almindor I see that you have a mipidsi crate. It states tho that it works only over SPI. I am a bit confused. is MIPI-DSI just SPI?
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 256 seconds]
fabic_ has joined #rust-embedded
<re_irc>
<Chris [pwnOrbitals]> are Cell and UnsafeCell transparent ? is UnsafeCell<[Cell<T>; N]> always equivalent to [T; N] ?
<re_irc>
<James Munns> Unsure about Cell, but UnsafeCell is
<re_irc>
<GrantM11235> bugadani: I figured it out last night while I was trying to go to sleep. The iterator is about to return "Some(255)", but first it has to increment the state, causing the overflow
<re_irc>
<bugadani> GrantM11235: Oh I missed that it panicks, lol.
<re_irc>
<GrantM11235> I think that in release mode it should go all the way up to 255 and then repeat from zero, but I can't get it to run on the playground
<re_irc>
<jessebraham> I'm not sure if this is an issue with docs.rs or svd2rust, but I seem to be getting broken links generated in the documentation:
<re_irc>
<Phil Markgraf> Hello everyone. I'm an embedded Rust developer from Los Angeles, CA. Thank you in advance.
<re_irc>
<Phil Markgraf> We've been using Postcard (thanks James) with the COBS flavor and are now looking to add a CRC into the packet. Is there a recommended method for adding the CRC to this encoding? It seems like it needs to be added in advance of COBS encoding, if we want to use the '0' end of packet capability. But this would create an "serialize from structured data" -> "append CRC" -> "serialize into COBS" workflow... which seems...
<re_irc>
... awkward.
<re_irc>
<Oddstr13> microjson (https://crates.io/crates/microjson) looks suitable for the config parsing itself, but a lightweight filesystem abstracting away the flash page stuff would've been really nice
<re_irc>
<dirbaio> I would _not_ use a traditional block-device filesystem such as fat32 on raw flash
<re_irc>
<Oddstr13> littlefs is what's used for the esp arduino stuff iirc, which is more in lines with what I was hoping for
<re_irc>
<yruama_lairba> hello, how do you manage test in embedded project ?
<re_irc>
<Phil Markgraf> My team built a test harness on another computer to exercise the embedded system and wrote the bulk of the hardware-in-the-loop tests using that harness. We use a combination of the devices interfaces and logic analyzers sniffing I/Os to stimulate the system and measure its outputs. Wherever possible, we build code in libraries that are unit tested on a workstation in advance of incorporation in the embedded...
<re_irc>
... system. There should be many more execute-on-workstation tests than there are hardware-in-the-loop tests. (James Grenning's book "Test Driven Development for Embedded C" is pretty applicable.)
<re_irc>
<James Munns> Oh hey Phil Markgraf :D
<re_irc>
<yruama_lairba> it's too complicated for a small project :/
<re_irc>
<yruama_lairba> and since i'm writting a "thin" hal, there is not so much thing that can be unit tested
<re_irc>
<Phil Markgraf> For a small project, make a program that wiggles your hardware from a serial port. Maybe use an Arduino to monitor GPIOs.
<re_irc>
<Phil Markgraf> James Munns: Did you see my query about Postcard / COBS / CRC... above. (And thank you for a very nice library.)
<re_irc>
<James Munns> Oh! Not yet
<re_irc>
<yruama_lairba> i may just write some example to start...
<re_irc>
<James Munns> Ah, okay Phil Markgraf, so with flavors, you should be able to make a flavor something like Cobs<Crc<Slice>>, BUT
<re_irc>
<James Munns> I'm going to be working on postcard 1.0 soon, and I plan to rip out flavors. they are a little too generic-intense, and I've found that it's actually more CPU efficient to just do different "layers" in stages.
<re_irc>
<yruama_lairba> the real question i should ask is how MCU HAL are tested
<re_irc>
<James Munns> So what I'd probably do today is something like:
<re_irc>
<James Munns> Basically it's a project for "do embedded-hal things in an rpc style"
<re_irc>
<James Munns> mostly intended for writing drivers, but could also be a hardware test double
<re_irc>
<Phil Markgraf> yruama_lairba: Not sure about all HALs, but my team at a previous company hired Hanno Bruan to make a test stand to harden the HAL for the LPC845 that we were using at: https://github.com/braun-embedded/embedded-test-stand (and the folks at Ferrous added improvements).
<re_irc>
<yruama_lairba> what mean rpc please ?
<re_irc>
<James Munns> "remote procedure call"
<re_irc>
<James Munns> basically "send a command, get a response" (over a network, serial port, etc)
<re_irc>
<James Munns> Basically you model it as "fn(Request) -> Response", and pretend there is no network involved, even though there is. This is how a lot of web services work, but with tools like postcard, it's also pretty much how I write all my firmware stuff that talks over TCP or a Serial Port.
<re_irc>
<yatekii> James Munns: uh oh so I can finally replace nordic tools with embassy and your pretty-hal-machine :D
<re_irc>
<James Munns> depends which tools you mean :p
<re_irc>
<yatekii> James Munns: there is python tools for using their BLE dongle from the PC
<re_irc>
<yatekii> and the BLE dongle has a firmware that does RPC over UART with the python code.
<re_irc>
<yatekii> and it's quite broken :(
<re_irc>
<yruama_lairba> all that stuff seems a bit complicated to me.
<re_irc>
<James Munns> ohhhh
<re_irc>
<James Munns> But yeah, you totally could. pretty-hal-machine already supports the nrf52840's USB for comms, but you could also just build on top of that using embassy if you need BLE things
<re_irc>
<dirbaio> oh yeah Nordic's BLE "serialization" thing β οΈ
<re_irc>
<yatekii> XD dirbaio with the PTSD
<re_irc>
<James Munns> honestly, the pattern I've used in dozens of projects is:
<re_irc>
- make a desktop crate
<re_irc>
- make a shared, no_std, message definition crate, where the "protocol" is defined
<re_irc>
- make a firmware crate
<re_irc>
<dirbaio> I made the mistake of using that in the 2nd iteration of our product π
<re_irc>
<James Munns> then just send Cobs encoded messages back and forth in both directions
<re_irc>
<dirbaio> for the actual product, not just factory tests
<re_irc>
<James Munns> postcard literally has a "CobsAccumulator" struct exactly for this reason, feeding in a stream of bytes and getting a stream of messages out
<re_irc>
<dirbaio> it ended all scrapped, of course
<re_irc>
<yatekii> James Munns: yup :) I always wanted such a protocol to log telemetry data. and I always run into the issue that I wanted to make it nice and C compatible which is a paradox. so I always dropped it lol
<re_irc>
<dirbaio> there's like 10 customers still using it π€£
<re_irc>
<yatekii> dirbaio: ah we still do factory tests with it. it's a joke
<re_irc>
<dirbaio> they don't respond to our messages that we'll swap their hardware for free
<re_irc>
<yatekii> but we have other issues there. in the factory like 20% of BT packets get dropped
<re_irc>
<dirbaio> I want to drop support for the old protocol from the cloud π
<re_irc>
<yatekii> while in our office it all just works fine
<re_irc>
<James Munns> Funny story, my OS uses the same RPC process for syscalls
<re_irc>
<Tom> xeon + massive 1m+ gate agilex and ddr on a pcie
<re_irc>
<dirbaio> for only $99.999!
<re_irc>
<Tom> Yeah I think Agilex parts are those kind of parts that are like "if you have to ask..."
<re_irc>
<James Munns> yatekii: You can get faraday tents, btw. Or just use a space blanket and ground it
<re_irc>
<dirbaio> or just (β―Β°β‘Β°)β―οΈ΅ β»ββ» it
<re_irc>
<yatekii> James Munns: yup. I am not sure what they are doing xd I am not with them anymore :)
<re_irc>
<dirbaio> * simply
<re_irc>
<yatekii> you kinda motivated me to quit, James Munns xd
<re_irc>
<James Munns> uh oh
<re_irc>
<James Munns> not my intended inspiration output :p
<re_irc>
<9names (@9names:matrix.org)> James Munns: How effective is a space blanket?
<re_irc>
<James Munns> next you'll be writing an OS
<re_irc>
<James Munns> 9names: I dunno, never tried THAT one before. I have used a home-built copper-mesh shed though.
<re_irc>
<James Munns> (you could probably use aluminum foil too)
<re_irc>
<yatekii> James Munns: it's a good thing, dw :)
<re_irc>
<James Munns> https://www.youtube.com/watch?v=LgDnoVMh4oE seems to show -8db, which isn't nothing, though I don't think he grounded it, but honestly I don't know how good of a connection you could really make to mylar tho
<re_irc>
<James Munns> heh, or since you'd be using 2.4ghz specifically: a microwave (cut off the power cable) is literally a 2.4ghz tuned faraday cage :p