vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
Socke has joined #rust-embedded
majors_ has joined #rust-embedded
majors has quit [Ping timeout: 260 seconds]
cinemaSundays has joined #rust-embedded
<barafael[m]>
Mattia: I've used the channels from embassy-sync with a CriticalSectionMutex to talk to the rp2040 dual core
<Mattia[m]>
Would that approach work for the [STM32MP2](file:///home/mattiaf/Downloads/stm32mp253f.pdf) for instance, talking from a Linux environment on the A-53 to an embassy environment on the M33?
<Mattia[m]>
<thejpster[m]> "I implemented virtIO vrings in..." <- Looks good and fairly simple actually
Makarov has quit [Ping timeout: 256 seconds]
Makarov has joined #rust-embedded
<thejpster[m]>
Hopefully someone has produced better abstractions in the seven years since I wrote that
Makarov has quit [Ping timeout: 256 seconds]
<barafael[m]>
<Mattia[m]> "Would that approach work for the..." <- I believe that should work, yes
Makarov has joined #rust-embedded
explodingwaffle1 has quit [Quit: Idle timeout reached: 172800s]
cinemaSundays has quit [Quit: Connection closed for inactivity]
Makarov has quit [Ping timeout: 256 seconds]
sroemer has quit [Ping timeout: 252 seconds]
Makarov has joined #rust-embedded
haobogu[m] has joined #rust-embedded
<haobogu[m]>
If I want to use postcard to serialize/deserialize a struct, but the struct cannot derive serde::Serialize/Deserialize(since it contains other structs from a separate crate, which doesn't impl Serialize/Deserialize), can I use postcard? If I can, how? Do I have to implement serde::Serialize/Deserialize manually for my struct?
<dirbaio[m]>
you can wrap the other crate's types with a newtype
<dirbaio[m]>
and impl Serialize/Deserialize for that
<dirbaio[m]>
* for that manually
<dirbaio[m]>
so you can still use derive for your struct
<dirbaio[m]>
it's probably less work to impl serialize/deserialize manually for just the other crate's types than for your entire struct
JamesMunns[m] has joined #rust-embedded
<JamesMunns[m]>
If it's for a binary, and not a library you want to publish, I would say it'll be much easier to fork the repo, add the derives, and use cargo's patch directives to use your version
<JamesMunns[m]>
Most crates are pretty open to PRs adding serde impls behind a feature, as well.
Makarov51 has joined #rust-embedded
Makarov has quit [Ping timeout: 256 seconds]
ivmarkov[m] has joined #rust-embedded
<ivmarkov[m]>
Generic question, sorry - seeking for opinions:
<ivmarkov[m]>
- How much would the MPU unit of the MCU (that is, where available - i.e. on some arm chips; Espressif RISCV does not seem to support it?) matter in a future embedded development, especially in regulated domains? I haven't seen anybody taking advantage of it and designing their MCU software with memory protection enabled, but maybe I'm not looking carefully enough and deep enough?
<ivmarkov[m]>
(Context is Rust embedded development of course, not C.)
wassasin[m] has joined #rust-embedded
<wassasin[m]>
ivmarkov: HighTec has implemented a Rust framework for embedded development heavily leveraging the MPU in the Infineon Aurix family
<wassasin[m]>
Basically every task only has the intended peripherals and memory regions whitelisted by macro's before entering a task
<JamesMunns[m]>
ivmarkov IMO, the MPU is still useful for defending against driver bugs, unsafe code, systemic issues like stack overflows, and FFI. For "all safe code" outside of an RTOS (with mutually distrustful components), IMO it is less relevant.
<ivmarkov[m]>
wassasin[m]: Thanks! From a very superficial look, this seems like a wrapper around a C kernel - PXROS, right?
<ivmarkov[m]>
ivmarkov[m]: Or am I completely off?
<wassasin[m]>
ivmarkov[m]: Yeah the OS is C, unsure what the name is. But the setup they have is you can just write Rust tasks with some macro attributes and it just works
<ivmarkov[m]>
JamesMunns[m]: Thanks! Still trying to understand - do you mean - in layman's terms - a simple "two regions" memory protection? As in the kernel is one, and then all "user-space" tasks lumped into a single region, or more like real big-OS "processes", where each task is protected by the others in its own memory region?
<JamesMunns[m]>
ivmarkov[m]: Most of my point was "no OS", like bare metal or embassy tasks.
<JamesMunns[m]>
WITH an RTOS, you could either do two region protections, which is what tockos does I think.
<ivmarkov[m]>
JamesMunns[m]: So - assuming "no kernel" thing like Embassy - you would say it would be up to the user to distribute its workload into its own memory protected regions? Maybe M tasks to N regions?
<ivmarkov[m]>
* - assuming a "no kernel"
<ivmarkov[m]>
* - assuming a "no kernel", * N regions? And then each region with its own executor (of sorts)?
<ivmarkov[m]>
thejpster[m]: So essentially "3) Tasks are Binaries (dynamic linking)" is what you are referring to?
<ivmarkov[m]>
<wassasin[m]> "Yeah the OS is C, unsure what..." <- Btw, this is all modering, using `async/await` and so on?
<ivmarkov[m]>
s/modering/modern/
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
<ivmarkov[m]> "Generic question, sorry - seekin..." <- you may looked for the wrong keywords on the riscv esp's. For example on the esp32c6 its called the PMS system and it comes with a PMS ( physical memory protection) and APM ( Access permition management). The later can have up to "16" master configuration where you can configure different ranges and settings accross 4 different types of access.
<ivmarkov[m]>
<vollbrecht[m]> "you may looked for the wrong..." <- Was looking at the c3, t.b.h.
<ivmarkov[m]>
<ivmarkov[m]> "Was looking at the c3, t.b.h." <- Hmmm, you are right, even the C3 has a PMS
<thejpster[m]>
<ivmarkov[m]> "So essentially "3) Tasks are..." <- I guess my point is that to configure the MPU you need to know where stuff lives. If you compile all your stuff into a flat binary (with or without a bootloader), you can't program the MPU to hide thread 1 from thread 2 because they are all mixed together. You could maybe program the MPU to hide the stack of thread 1 from the stack of thread 2.
<thejpster[m]>
thejpster[m]: Once you start allocating well defined regions to your threads, you can program the MPU to hide them from each other. That basically, to me, implies that you need "Tasks are binaries"
<thejpster[m]>
thejpster[m]: because that involves running the linker multiple times, and produces unique address ranges that you can give to the MPU
<thejpster[m]>
thejpster[m]: embassy is very much a tool for making flat binaries. So it can't really use the MPU at all, beyond some very basic stack overflow protection.
<thejpster[m]>
thejpster[m]: and it doesn't even have multiple stacks - all the async tasks share the same stack.
<ivmarkov[m]>
thejpster[m]: Yes, I was speculating that - I don't know - multiple executors perhaps, and (if possible at all) isloation on the executors boundary?
<ivmarkov[m]>
* the executors' boundary?
<haobogu[m]>
<JamesMunns[m]> "If it's for a binary, and not..." <- unfortunately, it's a library. I'll try wrap it first, thanks for the advice!
<dirbaio[m]>
my hot take is MPU / trustzone is mostly irrelevant with embedded Rust
<dirbaio[m]>
s/with/in/
<ivmarkov[m]>
dirbaio[m]: ... because of language-level guarantees (i.e. Midori all over again) or because with so little RAM and flash, MPU is your last concern?
<dirbaio[m]>
use cases for MPU that are still relevant with Rust:
<dirbaio[m]>
- Allow running *untrusted apps*.
<dirbaio[m]>
- Stack overflow detection (though thumbv8's MSPLIM is much better)
<dirbaio[m]>
the main use case that everyone wants trustzone/MPU for is improving security/resiliency
<dirbaio[m]>
assuming your firmware is going to get pwned because C is security swiss cheese, so you try to sandbox things so if someone pwns you at least they can't extract keys or overwrite the bootloader
<ivmarkov[m]>
OK, so essentially you are saying "we are having language level guarantees (Rust) so why bother"?
<ivmarkov[m]>
"untrusted apps on an MCU" - can't even imagine this case. As in... why?? We barely fit in there, let alone another vendor having its space there?
<dirbaio[m]>
which in many cases is a somewhat misguided goal. Keys aren't that important. For example if someone pwns my smartlock the concern is that they can open the door by toggling the gpio that moves the motor, I don't give a shit if the keys are safe at that point. (this applies to both Rust and C btw)
<dirbaio[m]>
but with Rust, the difference is now we have a realistic shot at making firmware that's not security swiss cheese
<dirbaio[m]>
and with Rust your time is probably better spent elsewhere
<dirbaio[m]>
like spend 1 man-week auditing all unsafe.
<dirbaio[m]>
* all unsafe. that's likely to also improve security 1%
<dirbaio[m]>
(numbers totally invented, but you get my point)
<ivmarkov[m]>
Yes yes, language level guarantees and Midori all over again :) Sorry if I sound like a broken recorsd, but that's my gist of your position.
<ivmarkov[m]>
s/recorsd/record/
<dirbaio[m]>
and doing sandboxing properly is very hard
<ivmarkov[m]>
JamesMunns[m]: Sure, but assuming your stack is Rust (language level guarantees) who cares, so to say?
<dirbaio[m]>
and has nontrivial code size, ram size, speed impacts
<thejpster[m]>
<ivmarkov[m]> "Yes, I was speculating that..." <- I have a universal answer that applies to almost all computer science questions.
<thejpster[m]>
It depends.
<JamesMunns[m]>
ivmarkov[m]: Sure, once the full stack is safe rust :)
<ivmarkov[m]>
JamesMunns[m]: It is? I mean, putting aside some `unsafe {}`?
<JamesMunns[m]>
But really, hardware abilities, like DMA, or indirect key loading, etc., also has the ability to cause problems
<ivmarkov[m]>
* `unsafe {}`? With `embassy-net`, that is.
<JamesMunns[m]>
practically it might not be the best use of your time. I mostly agree with JP and dirbaio
<thejpster[m]>
wassasin: do you have first-hand experience of the Hightec product?
<ivmarkov[m]>
wassasin: mentioned the car industry. Maybe there? You know, I don't want to lose my breaks, becuase an OTa update failed miserably, and the two tasks share a common executor, common addressing spacew etc.?
<thejpster[m]>
I'm not aware of anyone doing networking with a pure Rust stack right now.
<ivmarkov[m]>
s/becuase/because/, s/OTa/OTA/
<diondokter[m]>
I recommend starting with a threat-model and only then deciding which technical solutions you want to employ to cover the acceptable and unacceptable risks for your application
<thejpster[m]>
maaaaybe someone using the STM32 Ethernet MAC and smoltcp. But pretty sure most chips are using blobs.
<dirbaio[m]>
unsurprisingly, proxying all your SPI screen drawing through an "SPI task" destroys performance. To get decent perf the author ends up merging the display and SPI tasks, which defeats the point of sandboxing because SPI's DMA is able to write to all physical memory...
<dirbaio[m]>
so it's not "you sprinkle some MPU on your code and it's now magically secure". it's haaaaard 🥲
<ivmarkov[m]>
* wassasin: mentioned the car industry. Maybe there? You know, I don't want to lose my brakes, because an OTA update failed miserably, and the two tasks share a common executor, common addressing space etc.?
<ivmarkov[m]>
BTW, besides the Infineon thing, Tock claims to have it (MPU usage on MCUs).
<dirbaio[m]>
thejpster[m]: my company, Akiles 🙃
<dirbaio[m]>
(and many others using Embassy)
<thejpster[m]>
with Wi-Fi?
<dirbaio[m]>
wifi, ethernet
<thejpster[m]>
you have a pure Rust 802.11g stack?
<ivmarkov[m]>
dirbaio[m]: Yes, but wifi is on a separate chip so you get "isolation" "for free"
<ivmarkov[m]>
You are cheating a bit :)
<dirbaio[m]>
it's espressif's blob, but it's off chip so if it gets pwned the product is not compromised
<ivmarkov[m]>
* "for free", right?
<JamesMunns[m]>
still counts if you aren't handing remote DMA control to your network chip like some of the crazy hw offloading stuff that are the reason we have IOMMUs now lol
<dirbaio[m]>
rp2040+cyw43 is the same. you can get pretty secure against wifi firmware exploits
<thejpster[m]>
I can see my definition of "pure Rust" was insufficiently precise
<dirbaio[m]>
with nrf91 if you run your app in S mode (and DON'T use libmodem because it has exploits) you're also secure against modem exploits
<dirbaio[m]>
s/has/blindly/, s/exploits/trusts pointers sent by the modem/
danielb[m] has joined #rust-embedded
<danielb[m]>
to be fair, no matter how secure a stack is if the application level is written by D-Link
<dirbaio[m]>
and
<dirbaio[m]>
MPU/trustzone usually don't help against exploits in the vendor blobs because the blobs typically need DMA access that can write all physical memory.
<dirbaio[m]>
that's the case with nrf's BLE blob 🥲
<dirbaio[m]>
in nrf53/54 you can at least set RADIO to NS so its DMA can't access S memory, and run the blob in NS. So code you run in S mode is safe against exploits
<dirbaio[m]>
but ... complexity 💀
i509vcb[m] has joined #rust-embedded
<i509vcb[m]>
nrf's wifi at least lives on another chip but talking to it over Q(SPI) is annoying. Let alone the rest of the issues around it.
<i509vcb[m]>
* nrf's wifi at least lives on another chip but talking to it over (Q)SPI is annoying. Let alone the rest of the issues around it.
<diondokter[m]>
We're working on getting some funding to make the trustzone-m support in the compiler better.
<diondokter[m]>
Our work so far was sponsored by *company*, but that dried up
<dirbaio[m]>
i509vcb[m]: only wifi chip in the market that you talk to it with the SPI flash protocol :D
<i509vcb[m]>
I've had to get a little creative with regards to some unsafe because some of the structs you need to build will blast away 3K of stack in one go
<i509vcb[m]>
At worst case sizes
<i509vcb[m]>
And don't forget the 70K in flash for storing the firmware blob to upload
<i509vcb[m]>
Although I wonder if that could be further conpressed
m5zs7k has quit [Read error: Connection reset by peer]
<JamesMunns[m]>
the STM32C0 and STM32U0 come in itty bitty wlcsp packages too
<JamesMunns[m]>
The G030 is my go-to "I need a tiny chip to do one or two things" choice. Either TSSOP20 or LQFP. JLC stocks them for super cheap
<i509vcb[m]>
From the sysconfig data there are apparently unreleased wlcsp packages for the mspm0
<thejpster[m]>
I like the 8-sot-32 though. Hand solderable, but still 2mm x 2mm on the board. The SO-8 looks about 6mm x 4mm.
<thejpster[m]>
I couldn't hand load a WLCSP
<JamesMunns[m]>
ahh, I didn't realize it was that small
<thejpster[m]>
it's the size of an 8 pin SOT-32 jellybean transistor.
<i509vcb[m]>
I personally find the slightly larger chips more interesting since 1K of RAM is tight
<JamesMunns[m]>
8K (on the G0) is definitely a little small, but not unreasonably so. It's still comfortable using defmt or postcard, even with a healthy static rx/tx buffer for UART or for feeding smartleds
<thejpster[m]>
ooh, "Two 5V-tolerant open-drain IO". So it can be a PS/2 keyboard controller.
<i509vcb[m]>
I can at least flash the C1104 with Rust code, but I'm currently doing a bunch of data generation stuff
<i509vcb[m]>
I do need to force defmt to have a small buffer but it fits
<JamesMunns[m]>
these days tho, if I don't have a good reason not to, I'm just sprinkling rp2040s on everything
<thejpster[m]>
this is like, hmm, I could use a flip-flop. Or I could use a Cortex-M0+. They take up the same space and cost about the same.
<JamesMunns[m]>
(good reasons: floating points, power consumption, size, total bom count)
<JamesMunns[m]>
thejpster[m]: I've made this case for port expanders
<thejpster[m]>
I am offended by how much the MCP23S17 costs.
<JamesMunns[m]>
you can get like a QFN32 stm32g0 for the cost of a simple 16 pin i2c port expander
<i509vcb[m]>
The pio pretty much makes it a programmable io expander
<JamesMunns[m]>
plus if you want to make your port expander also have like, two smartled channels, or a few adcs, or an external serial port, it's easy
<thejpster[m]>
Also the STM32G0 is £1.11 in 10-off and this new MSPM0C is £0.44 in 10-off.
<JamesMunns[m]>
thejpster[m]: the G0 was like 45 cents/ea in 10s from JLC last time I ordered
<JamesMunns[m]>
LCSC stocks them for way cheaper
<thejpster[m]>
My issue with the RP2040 is it needs a crystal and flash, and I struggle to hand-load a QFN because there's No legs,.
<thejpster[m]>
I'm assuming the relative price still holds? Let's see.
<JamesMunns[m]>
they have one or two packages available
<thejpster[m]>
The MSPM0L I think is older than the MSPM0C, which is the new one. Might take a while for parts to trickle through and databases to be updated.
<JamesMunns[m]>
the F6P6TR was always thecheapone, they seem to be out of stock tho
<JamesMunns[m]>
if you order with assembly with JLC (which is what I do), I think you get a discount off the list LCSC price, but you do pay a 3$ reel loading fee because it's not a basic part
<JamesMunns[m]>
so at 10 boards the reel fee is almost the same as the MCUs at $0.40/ea
<JamesMunns[m]>
Maybe they're moving to the C0s now that those are available now in qty
<i509vcb[m]>
What I'd be interested to see the math on is the L222x as a LCD driver and IO expander in one
<i509vcb[m]>
Or even just as the former
<JamesMunns[m]>
the downside tho: you have to write software lol
<i509vcb[m]>
Yeah unfortunately the software bit is a bit slow from me
<JamesMunns[m]>
For one-offs, I've been throwing RP2040 XIAOs or Solder Party RP2040 stamps on things. They're $5-10/ea, but it's a whole RP2040, usb port, and headers/castellations (and the stamp also has a lipo circuit and smartled). It's actually cheaper than placing my own parts, if I can get away without doing assembly, or doing just some basic part jellybeans
<JamesMunns[m]>
* usb port (edit: only the XIAO), and
<JamesMunns[m]>
I have so many boards on my parts bins that have never had firmware flashed on them, because I ordered 5-10 boards and only ever used 3-4 :p
<JamesMunns[m]>
so, having a stack of modules that I can only assemble as I need is actually net cost effective, I think lol
<i509vcb[m]>
I've liked the pico for a similar reason, but I really do wish there was USB 2 HS...
<i509vcb[m]>
Maybe I'll try to PIO bit bang ULPI some day
<JamesMunns[m]>
I totally agree. I was bummed that wasn't in the pico 2
<JamesMunns[m]>
that being said... I don't think I've ever really had a project that ran into a limit at 12mbps
<i509vcb[m]>
Even if you had to provide your own phy I wouldn't mind
<JamesMunns[m]>
but there's definitely projects that could benefit from 480mbps instead
<i509vcb[m]>
I'm already up against the limits of USB-FS in a project I have where I am trying to get a 50khz signal over USB
<JamesMunns[m]>
huh, 50khz of what?
<JamesMunns[m]>
(and is the issue with latency or throughput?)
<i509vcb[m]>
Throughput really
<i509vcb[m]>
I can always look at the data later
<JamesMunns[m]>
I'm trying to think if I've ever benchmarked the bandwidth of the rp2040
<i509vcb[m]>
16-bit values from an ADC, but it's really a 12-bit one
<JamesMunns[m]>
I know I was able to get 7-8mbps on the nrf52
<JamesMunns[m]>
(out of the total 12mbps)
<i509vcb[m]>
(And the rp2040's ADC has an ENOB of 8.6)
<i509vcb[m]>
Ah right maybe I did math wrong
<JamesMunns[m]>
are you using cdc-acm? or your own bulk/isochronous transfers?
<JamesMunns[m]>
theoretically, you should be able to do 30 bytes at 50khz (you can't practically probably), but if it's just a single 16-bit adc sample at 50khz that should be very doable
<i509vcb[m]>
I'd probably need to use bulk transfers for the ADC stuff at least
<JamesMunns[m]>
I guess I have the parts handy, lemme see how fast I can get postcard-rpc to do loopback on the RP2040
<i509vcb[m]>
Although the ADC isn't the only part. This project is the arm debugger, current analyzer and logic analyzer in one
Ralph[m]1 has quit [Quit: Idle timeout reached: 172800s]
mheld[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
so, depending on packet size, postcard-rpc can hit 2.5-4.5mbps total, doing a very silly loopback (literally copying the frame directly back)
<JamesMunns[m]>
but that's also doing like... message routing, and doesn't count header overhead, etc.
<JamesMunns[m]>
so, this is not a really good test of "how fast can USB go", because I'm also sort of benchmarking both the host and embedded side of postcard-rpc lol
<JamesMunns[m]>
but "at least that fast" for the raw connection, using bulk transfers (and probably a lot faster if you are just spamming bulk transfers upwards)
henrik_alser[m] has joined #rust-embedded
<henrik_alser[m]>
<JamesMunns[m]> "you can get like a QFN32 stm32g0..." <- I like to use them because they are firmwareless and Just Work :)
<henrik_alser[m]>
Use them a lot for daughtercards
<JamesMunns[m]>
(oh, I get slightly faster speeds if I remember to actually do my alloc OUTSIDE of the timing period lol, not a ton faster tho, another 0.1mbps or so)
<henrik_alser[m]>
But yeah if you need more than just gpios it makes sense!
<JamesMunns[m]>
yeah, totally onboard with "any software is a liability"
<henrik_alser[m]>
I typically reach for the 9555 line (i2c)
<henrik_alser[m]>
More reasonably priced :)
<henrik_alser[m]>
(Unless you need spi speed of course)
<henrik_alser[m]>
I mostly flip relays and read buttons
<henrik_alser[m]>
* mostly flip analog switches/relays and
<henrik_alser[m]>
So speed is not a concern there
<henrik_alser[m]>
It’s really neat when you wanna be able to build like 1-8 channel devices (using solder bridges for address select) using the same controller and device boards
<henrik_alser[m]>
And just wrap the firmware drivers around the port expander
<henrik_alser[m]>
* firmware drivers for the modules around the
<i509vcb[m]>
<JamesMunns[m]> "so, depending on packet size..." <- From that I can seem to also run the logic analyzer bit a 100kHz and keep the current sensing part at 50kHz and still have maybe 200kbps left
<i509vcb[m]>
* From that I can seem to also run the logic analyzer bit a 100kHz with 8 channels and keep the current sensing part at 50kHz and still have maybe 200kbps left
<thejpster[m]>
<i509vcb[m]> "Maybe I'll try to PIO bit bang..." <- I think the clock is the problem. The RP2350 can take up to 50 MHz on a GPIO pin as an external clock signal, but ULPI runs at 60 MHz.
<i509vcb[m]>
I'd think the pio would need to manage the clock, but maybe 50MHz is too much for it
<i509vcb[m]>
s/50MHz/60MHz/
<adamgreig[m]>
ok, let's start, sorry it's a bit late! no announcements from me, but I see Henk has added one about the next book sprint which is on jan 25th, please consider joining in if you're interested in helping update that documentation!
<adamgreig[m]>
ok, so bartmassey do you wanna talk about your item first, then we'll continue the discussion from last week about e-h 0.2?
<adamgreig[m]>
ah, or if he's not here yet, we can talk about e-h first and come back, mabez?
mabez[m] has joined #rust-embedded
<mabez[m]>
I don't add much to add from last week tbh :D, but I put the PR together
<adamgreig[m]>
PR lgtm, so I think just up to hal team to discuss/merge
<mabez[m]>
I suppose one thing to mention is that I can concede that not every HAL author will agree with me, but I don't thing as a wg we should be promoting the use of 0.2 eh
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Ah sorry, got distracted
<bartmassey[m]>
I agree that "promoting" 0.2 would be a bad idea at this point. Not sure about tolerating 😀. It feels to me hard to advocate moving every existing thing until reasonable alternatives to the deleted APIs for key functionality have been stabilized.
<danielb[m]>
probably worth menitoning that since we are pushing for 1.0 we won't be able to provide interfaces that are themselves not stable
<adamgreig[m]>
right, HAL authors can do what they want, but right now our transition doc says "we strongly recommend implement both"
<adamgreig[m]>
which I think made sense at the time since 1.0 was very new, but it's been about 11 months now
<adamgreig[m]>
ok, if there's nothing else to discuss about that, bartmassey?
<bartmassey[m]>
Sure
<bartmassey[m]>
As noted in the minutes, Philipp Oppermann and I have spent a bunch of time lately looking at the Embedded OS tutorial hosted by us
<bartmassey[m]>
I need to get in touch directly with Andre Richter, but in the meantime we've been looking at a number of cleanups and improvements
<bartmassey[m]>
The thing is getting a steady trickle of attention right now, so it seems warranted to spend some effort on it.
<bartmassey[m]>
(Also, we've got it to run on the Pi Zero 2 W, which is nice since it's a cheap and readily available board)
<bartmassey[m]>
Just wanted any feedback anyone had on any of this as we get going
<bartmassey[m]>
(Actually, scratch "Embedded" above. The goal is to teach "real" OS in Rust, with VM and multicore and everything.)
<adamgreig[m]>
sounds great! getting it updated for a modern and cheaper pi seems good
<adamgreig[m]>
i've got a pi02w sitting around too, could give it a go
rmsyn[m] has joined #rust-embedded
<rmsyn[m]>
bartmassey[m]: is the OS hosted under `rust-embedded` group? looking to check out the project
<bartmassey[m]>
rmsyn: Yes, let me grab the link
<adamgreig[m]>
i believe andre's job situation meant he had to stop contributing to open source things, but i'm sure he'd be happy to discuss and to see it getting updated
<adamgreig[m]>
here's on matrix if you want to try getting in touch with him that way
<bartmassey[m]>
Oh, perfect thanks!
<bartmassey[m]>
Anyway, just wanted folks to know what we were up to. I'll let you know in a few weeks when we're ready for testing some stuff; in the meantime if you want to help out ping me 😀
<adamgreig[m]>
cool, thanks!
<adamgreig[m]>
anyone else have anything to discuss this week?
<adamgreig[m]>
great, if not let's wrap up here :) thanks everyone, see you next week!
<bartmassey[m]>
👋
apirkle has quit [Remote host closed the connection]