ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
fabic has joined #rust-embedded
<re_irc> <willeml> Well, I got gdb going, and narrowed it down to the "bx" instruction (after that instruction it just freezes) that's the branch instruction to actually start executing the OS code.
<re_irc> Trying to write a bootloader for stm32f7...
<re_irc> <willeml> And the problem is that the registers are not getting set correctly...
<re_irc> <James Munns> What are you doing to jump to the application?
<re_irc> <willeml> I am using "cortex_m::asm::bootstrap"
<re_irc> <dirbaio> there "r1" has already got the wrong value?
<re_irc> <willeml> according to the "info registers" in gdb r0 is "0x88888888" and r1 is "0x88888888" which are the wrong values
<re_irc> <dirbaio> maybe troubleshoot your XIP settings
<re_irc> <James Munns> that sounds like "everything is broken already"
<re_irc> <dirbaio> sounds like they don't match well with the qspi flash chip you have
<re_irc> <dirbaio> like, you read once and you get back valid data, you read again and you don't
<re_irc> <willeml> And now I am trying without reading twice
<re_irc> <willeml> Read works with my code, but not with the stuff in bootload
<re_irc> <James Munns> Also, it'd be interesting to see what happens if you set a breakpoint on that asm line, if you're single stepping asm to get there
<re_irc> <James Munns> (so: don't single step, set a breakpoint and then run to that line from start)
<re_irc> <willeml> I have a breakpoint set on "lib::__bootload" which is the where the asm is
<re_irc> <James Munns> sometimes having the debugger single step can mask hard faults and stuff
<re_irc> <willeml> I guess I will just add a +22 or whatever
<re_irc> <dirbaio> willeml: make a "stress test" in your code that reads random addrs from the flash
<re_irc> <dirbaio> and check it always reads correct data
<re_irc> <willeml> So random read, not sequential read of individual bytes separately?
<re_irc> <James Munns> you can also "break 0x08000488" or something like that
<re_irc> <dirbaio> something like that
<re_irc> <dirbaio> dunno
<re_irc> <dirbaio> like, sounds like XIP mapping is not working right
<re_irc> <dirbaio> if that doesn't work, bootload won't work for sure
<re_irc> <dirbaio> for i in 0..1000 { ((FLASH_ADDR + (i*4321 % FLASH_SIZE)) as *const u8).read_volatile() }
<re_irc> then read addr 0 and 1 again, and print them to see if they're still OK or return 0x8888_8888
<re_irc> <dirbaio> for i in 0..1000 { ((FLASH_ADDR + (i*4321 % FLASH_SIZE)) as *const u8).read_volatile() } then read addr 0 and 4 again, and print them to see if they're still OK or return 0x8888_8888
<re_irc> <James Munns> willeml what happens if you break RIGHT BEFORE that ISB instruction?
<re_irc> <willeml> So at isb or at msr?
<re_irc> <James Munns> AT 480
<re_irc> <James Munns> (so don't execute the ISR)
<re_irc> <dirbaio> there's no point in debugging "bootload" if XIP doesn't work :P
<re_irc> <James Munns> yeah
<re_irc> <willeml> James Munns: Registers are the same
<re_irc> <James Munns> gotcha
<re_irc> <willeml> I will try the stress test
<re_irc> <James Munns> What flash part are you using?
<re_irc> <James Munns> that seems to be the issue you have? But not much info there...
<re_irc> <James Munns> Did you enable QE mode on your flash part?
<re_irc> <willeml> QE mode?
<re_irc> <James Munns> Quad mode
<re_irc> <James Munns> "Quad Enable"
<re_irc> <willeml> I enabled QPI
<re_irc> <James Munns> Locally? Did you also send a quad enable command?
<re_irc> <James Munns> (some chips you have to tell them to go into quad mode before they'll do it)
<re_irc> <willeml> Yeah, I sent it the enable QPI command
<re_irc> <willeml> "0x38"
<re_irc> <James Munns> does your chip support that mode?
<re_irc> <willeml> Yes
emerent has quit [Ping timeout: 248 seconds]
<re_irc> <willeml> (there is a C++ OS using it)
<re_irc> <James Munns> gotcha!
<re_irc> <willeml> Well, now something is completely broken, more broken than it was yesterday... "(0x90000000u32 as *const u32).read_volatile()" doesn't work
emerent has joined #rust-embedded
<re_irc> <James Munns> btw 0x38 is the "quad program command"
<re_irc> <James Munns> you probably need to do a write to register 0x06 first to enable QE in the status register
<re_irc> <willeml> 0x02 is supposed to do it
<re_irc> <James Munns> Yeah
<re_irc> <willeml> I'll try 0x06
<re_irc> <James Munns> 0x02 command to register 0x06 should do it
<re_irc> <wembly> is there a 4pin resistive touch screen driver i'm just completely missing/not finding on
<re_irc> <willeml> There is some other config of the qspi.dcr and
<re_irc> <James Munns> (0x02 is the value, 0x06 is the address)
<re_irc> <James Munns> It might be worth reading back register 0x06 (Status Register 2), and see what it is
<re_irc> <James Munns> (should be a 16 bit value)
<re_irc> <willeml> Oh, I am using volatile write enable (0x50) instead of write enable (0x06) as the address
<re_irc> <James Munns> What flash chip are you using?
<re_irc> <willeml> AT25SF641
<re_irc> <willeml> 8MB Adesto QSPI flash
<re_irc> <James Munns> looking...
<re_irc> <firefrommoonlight> yruama_lairba: use defmt::println!;
<re_irc> <firefrommoonlight> I guess more line teh "println!" normal macro, but that's the functionality I think most people use in most programming languagse
<re_irc> <firefrommoonlight> Ie, in Python, JS, embedded Rust and Desktop rust, it's that with teh new line every time for me
<re_irc> <yruama_lairba> firefrommoonlight: i meaned there is not variant without the newline
<re_irc> <James Munns> willeml 0x50 enables write, but not Quad mode
<re_irc> <firefrommoonlight> I don't mean to suggest "This is the way I do it, you should be happy with it too!", but... I'm genuinely curious what you use "print!()" for, especially given that reaction
<re_irc> <dirbaio> printing a single line in "parts" probably
<re_irc> <firefrommoonlight> (The flip side of this is I'm considering what I'm missing...)
<re_irc> <firefrommoonlight> Hmm.. I guess I would use a println for that too, but with multiple "{}" sections
<re_irc> <firefrommoonlight> Btw, for anyone who forgot about or missed the update... You can now use "println!", "format!" etc with Python F-string style var-in-brackets
<re_irc> <firefrommoonlight> println!("{myvar}")
<re_irc> <firefrommoonlight> * println!("{myvar}");
<re_irc> <willeml> Wait really? Since when?
<re_irc> <firefrommoonlight> a few months ago?
<re_irc> <dirbaio> doesn't work with defmt though, does it?
<re_irc> <firefrommoonlight> OOh haven't tried
<re_irc> <firefrommoonlight> I re-discovered it on a Rust desktop app
<re_irc> <James Munns> oh wait, maybe I'm full of shit, please hold
<re_irc> <James Munns> re-reading my most recent QSPI flash code :D
<re_irc> <willeml> Lol
<re_irc> <willeml> Memory mapped mode with qpi mode was working 24 hours ago
<re_irc> <dirbaio> some flashes also have weird "XIP modes" where you only send the addr, not the command
<re_irc> <James Munns> Then probably ignore me :p
<re_irc> <firefrommoonlight> You're right, it doesn't work in defmt
<re_irc> <firefrommoonlight> * f-strings don't
<re_irc> <firefrommoonlight> oh well
<re_irc> <dirbaio> :(
<re_irc> <dirbaio> so whatever "mode" you're using, it should match exactly between the stm32 qspi peripheral config, and the flash config
<re_irc> <willeml> I guess I should read the data sheet, again... and also read up on xip or qspi modes and stuff
<re_irc> <James Munns> an "easy" fix is to skip the quad enable stuff
<re_irc> <James Munns> and do regular spi just to test
<re_irc> <dirbaio> nrf's qspi can't use these fancy "XIP modes", rp2040 can and does, dunno about stm32
<re_irc> <James Munns> it'll be slower, but that's your chip's default mode
<re_irc> <yruama_lairba> is defmt usable across crate ?
<re_irc> <dirbaio> having a lib print stuff using defmt, instead of the main crate? yes
<re_irc> <James Munns> (now I'm wondering how MY code actually works :p)
<re_irc> <James Munns> I think I actually have a copy/paste error? but that's confusing...
<re_irc> <yruama_lairba> dirbaio: there is a spacial thing to do ?
<re_irc> <dirbaio> no, you just add "defmt" as a dep in the lib's cargo.toml and use it
<re_irc> <dirbaio> in the lib, use ONLY "defmt"
<re_irc> in the main crate, use "defmt", "defmt-rtt" as usual
<re_irc> <James Munns> The AT25SF641 support both Standard/Dual/Quad Serial Peripheral interface (SPI) and Quad Peripheral Interface
<re_irc> (QPI). However, SPI mode and QPI mode cannot be used at the same time. The ‘Enable QPI’ instruction is the only way
<re_irc> to switch the device from SPI mode to QPI mode.
<re_irc> In order to switch the device to QPI mode, the Quad Enable (QE) bit in Status Register 2 must be set to 1 first, and an
<re_irc> <James Munns> (that's instruction 0x38)
<re_irc> <willeml> James Munns: I'll try to figure that out lol, I mean shouldn't be too hard considering I hacked together a semi working qpi one
<re_irc> <James Munns> you can write status register 2 with 0x01 or 0x31
<re_irc> <willeml> For single? or for quad?
<re_irc> <James Munns> so, there's a flag in status register two, that is QE, or "Quad Enabled"
<re_irc> <James Munns> it's whether the chip will let you use quad read/write commands
<re_irc> <James Munns> you have to SET that flag first, with the 0x01 (plus two data bytes) or 0x31 (plus one data byte) commands.
<re_irc> <James Munns> (basically, write both SR1 and SR2, or just SR2)
<re_irc> <willeml> so 0x01 or 0x31
<re_irc> <willeml> or am I overthinking this
<re_irc> <James Munns> that's the register address, yes
<re_irc> <James Munns> So you'll need to send:
<re_irc> - Write enable (0x06)
<re_irc> - Write SR2 (0x31, 0x02)
<re_irc> <dirbaio> willeml: from this pic it looks like they're already doing that
<re_irc> <James Munns> yup.
<re_irc> <James Munns> I am being negative helpful.
<re_irc> <willeml> Except instead of 0x06 I am doing 0x50
<re_irc> <James Munns> I think that should work
<re_irc> <James Munns> sorry for the noise willeml :/
<re_irc> <willeml> No problem, it's making me think
<re_irc> Also I think I really broke it that's for sure, even indirect mode is broken now
<re_irc> <James Munns> I'm gunna go to bed instead of trying to wrap my head around qspi
<re_irc> <James Munns> also, thanks for bringing this up, I'm pretty sure this code is wrong:
<re_irc> <James Munns> which... is mind boggling because it works
<re_irc> <willeml> Haha, code that works but shouldn't, always confusing but kindof nice
<re_irc> <dirbaio> why is it wrong?
<re_irc> <James Munns> (I send a 0x06 opcode to write the status register, which is wrong, and should be 0x01)
<re_irc> <James Munns> AND I ask the nrf to send the write enable for me, so it's sending "0x06 0x06 [ SR1 ] [SR2 ]" instead of "0x06 0x01 [ SR1 ] [ SR2 ]"
<re_irc> <dirbaio> hmm I'm doing this
<re_irc> <James Munns> (maybe I got lucky and QE is enabled by default on that part, and it's just ignoring me?)
<re_irc> <dirbaio> which is _again_ different?? 🤣
<re_irc> <James Munns> At least for the GD24Q16C (my chip), QE is 0x2
<re_irc> <James Munns> "LB" is 0x4
<re_irc> <James Munns> The LB bit is a non-volatile One Time Program (OTP) bit in Status Register (S10) that provide the write protect control
<re_irc> and status to the Security Registers. The default state of LB is 0, the security registers are unlocked. LB can be set to 1
<re_irc> individually using the Write Register instruction. LB is One Time Programmable, once it’s set to 1, the Security Registers
<re_irc> will become read-only permanently
<re_irc> <dirbaio> ah, this is not standard? wtf?
<re_irc> <dirbaio> my chip is "MX25R1635F"
<re_irc> <yruama_lairba> how we call device that capture digital io to show chronograms ?
<re_irc> <James Munns> I think the bit order is flipped?
<re_irc> <James Munns> but should be bit 2?
<re_irc> <dirbaio> yruama_lairba: logic analyzer
<re_irc> <yruama_lairba> dirbaio does that cost ?
<re_irc> <willeml> Well, all my code is completely borked, even my dfu usb thing doesn't work anymore... just crashes
<re_irc> <James Munns> Same on willeml's part
<re_irc> <dirbaio> I think they're just different
<re_irc> <James Munns> That first screenshot is from the chip you linked
<re_irc> <James Munns> I think you might have an off by one bit error :p
<re_irc> <dirbaio> do I??
<re_irc> <dirbaio> 0x40 is bit 6 isn't it
<re_irc> <James Munns> oh
<re_irc> <dirbaio> 🤣
<re_irc> <dirbaio> don't scare me more
<re_irc> <James Munns> why is your msb/lsb order reversed?
<re_irc> <dirbaio> where do you see it's reversed?
<re_irc> <willeml> msb/lsb order?
<re_irc> <James Munns> yeah, maybe its just different
<re_irc> <James Munns> yeah, I thought it was reversed
<re_irc> <James Munns> but its not
<re_irc> <James Munns> it's just different
<re_irc> <James Munns> (0x40 vs 0x02, it's a palindrome :p)
<re_irc> <James Munns> see
<re_irc> <dirbaio> ahh 🤣
<re_irc> <James Munns> shoulda gone to bed 15 minutes ago
<re_irc> <James Munns> no more thinking about qspi tonight
<re_irc> <dirbaio> I see now
<re_irc> <dirbaio> lolololol
<re_irc> <James Munns> good luck willeml :p
<re_irc> <willeml> lol, thanks, and gn
<re_irc> <James Munns> I'm just reducing the SNR of this conversation
<re_irc> <willeml> SNR?
<re_irc> <James Munns> signal to noise ratio
<re_irc> <willeml> Oh haha
<re_irc> <willeml> Ok I got it working again, I have to do the init of flash before I init the clocks... But it does not hold up to the stress test dirbaio posted.
<re_irc> <dirbaio> nice!! 🔥
<re_irc> <dirbaio> at least you can repro it easier now
<re_irc> <willeml> I spoke to soon, it's entirely random... Now it dosen't work again, zero changes to the code
fabic has quit [Ping timeout: 272 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
cr1901_web has joined #rust-embedded
<re_irc> <jannic> willeml: do your power cycle your board between attempts? Config written to the flash chip might not be reset, otherwise.
<re_irc> <willeml> I don't, that's probably it
<re_irc> <willeml> jannic: I just tried, now it works again, but only the first 2 memory mapped reads work, the second ones fail... At least that's one problem solved! Unfortunately power cycling the board is not easy as it's on a battery... I guess I need to figure out how to properly reset the flash.
fabic has joined #rust-embedded
<re_irc> <jannic> RP2040 uses a rather convoluted method to bring the flash chip to a known state:
<re_irc> However, I guess that's only needed because the procedure should be compatible with many different flash chips. If you target one specific chip, there's probably a simpler reset sequence.
cr1901_web has quit [Quit: Client closed]
aspe has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
aspe has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
fabic has joined #rust-embedded
dreamcat4 has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
fabic has joined #rust-embedded
explore has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 276 seconds]
dreamcat4 has quit [Quit: Connection closed for inactivity]
<re_irc> <Chris [pwnOrbitals]> Hey everyone, does anyone have experience with picolibc ? One of my C dependencies needs it and I’m struggling to get it working, I managed to build it using the Meson crate but struggling to link with it
<re_irc> <Chris [pwnOrbitals]> * can’t manage
fabic has joined #rust-embedded
explore has quit [Quit: Connection closed for inactivity]
fabic has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
crabbedhaloablut has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
<re_irc> <Chris [pwnOrbitals]> (got it working, linker arguments weirdnesses)
seds_ has joined #rust-embedded
edm_ has joined #rust-embedded
limpkin_ has joined #rust-embedded
mattgirv has joined #rust-embedded
re_irc_ has joined #rust-embedded
badboy_ has joined #rust-embedded
inara` has joined #rust-embedded
cyrozap-ZNC has joined #rust-embedded
wose has quit [*.net *.split]
Socke has quit [*.net *.split]
limpkin has quit [*.net *.split]
re_irc has quit [*.net *.split]
cyrozap has quit [*.net *.split]
mattgirv_ has quit [*.net *.split]
edm has quit [*.net *.split]
seds has quit [*.net *.split]
badboy has quit [*.net *.split]
inara has quit [*.net *.split]
edm_ is now known as edm
seds_ is now known as seds
re_irc_ is now known as re_irc
Socke has joined #rust-embedded
wose has joined #rust-embedded
fabic has quit [Ping timeout: 240 seconds]
dreamcat4 has joined #rust-embedded
<re_irc> <James Munns> Plugging here, in case anyone has been quietly thinking about bare metal Cortex-A for any targets:
<re_irc> <James Munns> (interested in both "folks who work at a company that would sponsor/contract this work", or "hobbyists who want to hack along on a specific Cortex-A chip")
<re_irc> <James Munns> Or, if anyone knows any Application-format RISC-V chips (like 500MHz-1GHz, 64+MB of RAM), that are available and documented, I'm open to those too :D
<re_irc> <James Munns> Only one I've found is the MangoPi with an Allwinner D1s, but I don't know if those are actually shipping yet (or have any available docs?)
<re_irc> <adamgreig> FPGA when :D
<re_irc> <adamgreig> make a custom async-friendly cpu 🤔
<re_irc> <James Munns> Oh, good point, a Zynq might be interested too
<re_irc> <adamgreig> probably not going to win on cost though
<re_irc> <James Munns> I guess I'll learn how to make CPUs after I feel satisfied with writing an OS.
<re_irc> <adamgreig> room meeting time again! agenda is, please add anything you would like to announce or discuss, we'll start in 5 min
<re_irc> <adamgreig> James Munns: i found today so i guess making cpus it is
<re_irc> <thejpster> I got a couple of FPGA boards here that I just found out are now in LiteX.
<re_irc> <James Munns> Oh neat? Is that like a web version of nand2teris?
<re_irc> <James Munns> * nand2tetris?
<re_irc> <adamgreig> i think the end point is not quite as far along as tetris
<re_irc> <adamgreig> but you do make a little computer and it is all fun click and drag stuff
<re_irc> <adamgreig> starting two a couple relays for your first nand gate, heh
<re_irc> <adamgreig> * with
<re_irc> <thejpster> The Neotron 9X was a SAM9X60D5M. SDRAM stacked in the package, so no fancy routing required.
<re_irc> <adamgreig> ok, let's start! fairly short agenda I think. couple of announcements, svd2rust 0.24 is out, and we now have automatic release and prerelease binaries available to download off the github releases page
<re_irc> <adamgreig> and, the embedded-themed CTCFT meeting was yesterday, the recording isn't up yesterday but will be on
<re_irc> <adamgreig> does anyone have anything else to announce?
<re_irc> <therealprof> I haven't checked, do we have any material for a newsletter?
<re_irc> <adamgreig> hm, nothing on the draft
<re_irc> <therealprof> Hm, indeed.
<re_irc> <adamgreig> on the cortex-m front there's a new PR for a 0.7.5 release that would allow using inline-asm on stable and backports a bugfix from 0.8; the PR's ready for review but I haven't gotten around to actually testing it yet (though CI passes)
<re_irc> <therealprof> It's been a while.
<re_irc> <therealprof> adamgreig: LGTM but I don't have time to try it.
<re_irc> <adamgreig> yea, I expect we could comb through some old minutes to dig up some items for a newsletter too
<re_irc> <therealprof> I think James Munns posted a few blog posts meanwhile.
<re_irc> <adamgreig> I'll report back when I get a chance to test but if anyone else does first, even better. It's a pretty small code change at least
<re_irc> <therealprof> That would be good material. 😉
<re_irc> <therealprof> Could also go through the last few TWIR, there were a number of embedded posts.
<re_irc> <therealprof> Not sure why people announce there but not in the embedded newletter. E.g. there was at least one super interesting one about LoRaWAN by tweedegolf.
<re_irc> <adamgreig> I guess that TWIM has a couple more readers than the REWG newsletter
<re_irc> <therealprof> Sure, but more is better, no? ;))
<re_irc> <adamgreig> I don't have anything to report on the other cortex-m PRs from last week, if I can get some testing of the 0.7.5 PR in I'll try to at least push a couple of those along
<re_irc> <therealprof> * 😉
<re_irc> <eldruin> we could also go over the r-e twitter feed and have a look at the RTs
cr1901_ has joined #rust-embedded
<re_irc> <therealprof> At least the frequency of the newsletter is low enough that people interested in embedded are less likely to miss interesting things.
<re_irc> <eldruin> we should put the CTCFT in the newsletter as well, along with the recording link
<re_irc> <therealprof> Right.
<re_irc> <eldruin> maybe James Munns and/or dirbaio write a blog post about that as well?
cr1901 has quit [Ping timeout: 248 seconds]
<re_irc> <therealprof> I noticed that embedded currently seems to pick up some steam. Plenty of bugreports in cargo-binutils, discovery and various other crates lately.
<re_irc> <therealprof> Getting the word out certainly can't harm.
<re_irc> <therealprof> "defmt" is unfortunately causing a ton of trouble at the moment.
<re_irc> <thejpster> Oh no. In what way?
<re_irc> <therealprof> Seems probe-rs related tooling is expecting defmt 0.3 but e.g. the discovery book is using 0.2.
<re_irc> <therealprof> Also e.g. the microbit crate is still using 0.2 due to "rubble" having a hard dependency on 0.2 and for some reason the examples can't use different versions of the crates which confused the heck out of me earlier today...
<re_irc> <thejpster> Deps on examples are a pain generally.
<re_irc> <therealprof> Not sure why but the build is complaining about linking problems. Maybe "defmt" is playing some linker tricks to get stuff done?
dc740 has joined #rust-embedded
<re_irc> <thejpster> It does involve magic - the host tool has to dip into the ELF to find your strings, and such like. I could believe that linking multiple incompatbile versions was barred using linker foo.
<re_irc> <thejpster> So yeah, all the defmt = 0.2 crates will need updating.
<re_irc> <therealprof> error: failed to select a version for `defmt`.
<re_irc> ... which satisfies git dependency `rubble` of package `ble-beacon v0.1.0 (/Users/egger/OSS/microbit/examples/ble-beacon)`
<re_irc> ... required by package `rubble v0.0.4 (`
<re_irc> versions that meet the requirements `^0.2.3` are: 0.2.3
<re_irc> <therealprof> It's a bit annoying to have hard dependencies in such middleware crates.
<re_irc> <therealprof> It's a lot more annoying that simply the presence of such an example can break everything.
<re_irc> <adamgreig> I guess ideally rubble needs updating first, then?
<re_irc> <adamgreig> and then microbit and discovery?
<re_irc> <adamgreig> 0.3's been out for a while, but it is a breaking change and has the same issue as PACs and cortex-m etc of only being able to exist once per build
<re_irc> <therealprof> I don't think discovery is blocked by rubble. Can't find the issue though, maybe it was on another repo.
<re_irc> <therealprof> "cargo-binutils" also seems to make problems again lately on some systems.
<re_irc> <eldruin> discovery will be blocked by microbit though
<re_irc> <therealprof> Hm, could be.
<re_irc> <therealprof> Who knew that examples could be so intrusive. 😅
<re_irc> <thejpster> I mean better that than examples that live off in a dark corner and go bit rotten?
<re_irc> <therealprof> Rubble seems to be rather dormant, though. Maybe we should just take the hit and remove the "ble-beacon" example and move on.
<re_irc> <adamgreig> is it possible to rework to use the softdevice crates instead?
<re_irc> <therealprof> No idea, doesn't sound trivial to me. Also, softdevice... meh.
<re_irc> <adamgreig> anything to report on the embedded-hal front in the last ten mins or so?
<re_irc> <eldruin> nothing from me
<re_irc> <adamgreig> 👍️ OK, any last minute items from anyone?
<re_irc> <adamgreig> let's wrap up there then, thanks everyone!
<re_irc> <thejpster> Apropos nothing, I see Arm now do AWS instances with their hardware simulator installed
<re_irc> <thejpster> Using the Fixed Virtual Platform desktop software product for testing and CI was a bit of a pain.
<re_irc> <thejpster> This might be better? At least it’s designed for pipeline use.
<re_irc> <thejpster> And it lets us do v8.1-M support in advance of silicon shipping.
cr1901_ is now known as cr1901
iyed has joined #rust-embedded
iyed has quit [Client Quit]
dc740 has quit [Remote host closed the connection]
cr1901_ has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
cr1901_ has quit [Ping timeout: 240 seconds]