ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
<mameluc[m]> I am having some trouble with defmt-serial. Only some of the stuff gets written. My program "ends" in a sys_reset and I think not everything gets written to the serial port before that. Is there any way to "wait" until all is written?
<JamesMunns[m]> 0.7 had a pretty big soundness hole that I think was fixed in 0.8. I think 0.8 allows you to get the serial port back, which you probably could flush from?
<JamesMunns[m]> lol
<JamesMunns[m]> try defmt::flush() and see if that does you.
<mameluc[m]> lol indeed :D too focusend on only defmt-serial
<mameluc[m]> works like a charm 👍️
<JamesMunns[m]> (definitely update to 0.8 tho :p)
<mameluc[m]> okay almost worked. now it doesn't print what was in the beginning of the program, only whats at the end 😅
<dirbaio[m]> it won't print stuff before defmt-serial is initialized
<mameluc[m]> first "loop" it does print, later no
<mameluc[m]> loop as in power on -> do stuff -> reset
<JamesMunns[m]> are you using rzcobs encoding for defmt?
<mameluc[m]> hmm idk what that is
<mameluc[m]> `socat /dev/ttyUSB0,rawer,b115200,crnl STDOUT | defmt-print`
<mameluc[m]> ah I am always loosing the first message... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/FZlVyBvdyTfFWXxRJBqxrXJI>)
<mameluc[m]> adding a dot made it work
<JamesMunns[m]> if you use rzcobs you could try manually sending a zero on the wire, it shouldn't be necessary tho
<mameluc[m]> like release serial and then write zero to serial?
<JamesMunns[m]> or before you call defmt serial init on startup
<mameluc[m]> Ill try that tomorrow, thanks!
<mameluc[m]> this whole way of resetting the core is kind of strange anyway. I think defmt stuff lives in SRAM1 that gets nuked on sys_reset anyway
<mameluc[m]> but I don't understand what really goes on anyway
<JamesMunns[m]> defmt-serial doesn't have a ringbuffer like defmt-rtt does
<JamesMunns[m]> it's basically just a blocking write to serial
<JamesMunns[m]> (really making sure: you're using v0.8 right?)
<mameluc[m]> yes
<mameluc[m]> what is the default encoding?
<JamesMunns[m]> I think it's not rzcobs
<mameluc[m]> I was thinking if the first frame gets corrupted
<mameluc[m]> ah it is default
<mameluc[m]> rzcobs - Reverse Zero-compressing COBS encoding (rzCOBS). This is the default encoding.
<mameluc[m]> raw - raw data, that is no encoding.
<JamesMunns[m]> ah jk:
<JamesMunns[m]> yeah
<JamesMunns[m]> it'd be useful to see the raw serial, something like:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/QyVjSlgHVJYYkoZpQDudtbYC>)
<JamesMunns[m]> that way you could see where the mess up was
<JamesMunns[m]> > `crnl’ causes explicit character conversions.
<JamesMunns[m]> that might be bad too
<mameluc[m]> defmt-print didn't like "raw"
<mameluc[m]> but --show-skipped-frames confirms there is some malformed frames
<JamesMunns[m]> thats going to replace 0x0D to 0x0D 0x0A
<JamesMunns[m]> that's probably corrupting your frames, I bet the first log has intern ID 0x0D :p
<mameluc[m]> ah, idk where I copied that from
<JamesMunns[m]> it makes sense for plaintext but not binary
<mameluc[m]> ah I took it from the readme
<mameluc[m]> less malformed frames but still the first after reset is malformed
<mameluc[m]> could be some glitches on reboot
<mameluc[m]> I go in to standby so the pins are left floating. Should probably pull the serial pins
<mameluc[m]> thanks for the help, now time to sleep
<JamesMunns[m]> <JamesMunns[m]> "thats going to replace 0x0D to..." <- Update:
<JamesMunns[m]> I think after reading https://github.com/3ndG4me/socat/blob/3f33a20e3556558c459ece8582d8ef4a7e9f1fb2/socat.c#L1403-L1413, with the input as CRNL and the output as default (raw?), it will drop \r characters, basically dropping any bytes with the value 0x0D.
<JamesMunns[m]> so, it just drops any bytes that happen to be 13. I think.
gauteh[m] has joined #rust-embedded
<gauteh[m]> socat on Mac is buggy, better to use stty and cat, if you're on mac
linfax has joined #rust-embedded
Guest7282 has joined #rust-embedded
<jannic[m]> <JamesMunns[m]> "0.7 had a pretty big soundness..." <- Shouldn't 0.7 be yanked in such a case?
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]
JomerDev[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]> <jannic[m]> "Shouldn't 0.7 be yanked in..." <- I would say so. I'm unsure which other versions had a similar issue.
NazarSolomakha[m has joined #rust-embedded
<NazarSolomakha[m> Hi everyone! I'm in search of a Middle or Senior Rust developer with a strong background in hardware applications. We're offering a fully remote, contract position working with drone technology for a U.S. company. If you know someone perfect for this role and they get hired, our company, upstaff.com, will happily offer a $1,000 USD bonus as a thank you.
<NazarSolomakha[m> * Hi everyone! I'm in search of a Middle or Senior Rust developer with a strong background in hardware applications. We're offering a fully remote, contract position working with drone technology for a U.S. company. If you know someone perfect for this role and they get hired, our company, upstaff.com, will happily offer a $1,000 USD bonus as a thank you.
<NazarSolomakha[m> My contact is ns@upstaff.com
<mameluc[m]> <JamesMunns[m]> "Update:..." <- > <@jamesmunns:beeper.com> Update:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/LciVImPtzEJyMfigsRpkqEos>)
<JamesMunns[m]> uart probably wants pull UPS, not pull DOWNS
<JamesMunns[m]> typical UARTS idle high
<JamesMunns[m]> and if the pullups are on the MCU, they probably won't help much more than enabling the uart? it's still going to glitch on reset.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/epJtToIjWlEGgCytQGwCxCrb>)
<mameluc[m]> with pull ups I get "malformed frame skipped" but yes generally it should probably be pull up. This works well enough for me and I can confirm crnl is probably better not used
<mameluc[m]> this is with "malformed frame" on the first message. Hard for me to tell what it is supposed to be but the waveforms look good enough. Probably just some glitching when I re-init the uart the way I do
<JamesMunns[m]> you could add some delay before reset or after reset to make it more clear
<JamesMunns[m]> I'm spoiled by saleae and the serial decoder :D
<mameluc[m]> I have a serial decoder on this analog discovery too but I don't know what the bytes are supposed to be. Are the defmt messages deterministic, would the first messages always be 1 or something?
<JamesMunns[m]> the first thing is making sure what you're getting out of socat matches what the logic analyzer says
<JamesMunns[m]> (no changed/corrupted/missed bytes)
<JamesMunns[m]> if they match, you probably don't have to worry about looking at the logic analyzer. (we're trying to bisect the problem).
<JamesMunns[m]> If they DO match, you can first at least check if the rzcobs encoding is right, you can decode each frame as it ends with a `0x00` byte
<JamesMunns[m]> if THAT all looks fine, then you have to figure out the payload of the message, but you can also probably guess a bit at that by the content. defmt prints are basically interned IDs, so they'll always be something like "1 means 'hello'", "2 means 'init'", etc.
<JamesMunns[m]> you can see if there's something weird about the first message on the second loop
<JamesMunns[m]> like 0x01 becomes 0x81 or something
<mameluc[m]> with pullups the logic analyzer understands the serial but socat doesn't. tee:ing to a log file gives nothing. With pulldown it works. strange
<JamesMunns[m]> I wonder if the reset happens "too soon", some chips only mark `flush` done once the last bits are in the shift register
<JamesMunns[m]> pull down might hold the line low enough to complete a stop condition correctly?
<mameluc[m]> good point, a little delay would not hurt
<JamesMunns[m]> at 115200, I'd delay 100us or so to allow for a full character time
<JamesMunns[m]> could use embassy time or just cortex_m delay/nop loop
haobogu[m] has quit [Quit: Idle timeout reached: 172800s]
<mameluc[m]> still a delay would not help the first loop but good to have it there
<JamesMunns[m]> What does the scope trace look like with the delay? do the chars before/after the gap look reasonable? which one is socat glitching on?
<JamesMunns[m]> btw with tee, you need to open the resulting file with a hex editor, like xxd or hexyl, it's gunna be all control characters
<JamesMunns[m]> dunno if you tried to look at it with a text editor or something
<mameluc[m]> yup
<JamesMunns[m]> (idk if tee is trying to do buffering and just never actually seeing a newline and never flushing)
<mameluc[m]> when I get something in the file it matches perfectly with what the analyzer says
<mameluc[m]> when it doesn't work I get nothing
<mameluc[m]> but eh, this will have to do for now.
<mameluc[m]> Seems like it sometimes works and sometimes not
<mameluc[m]> thanks for the help debugging 👍️
<JamesMunns[m]> I've never found pipe utils for binary serial data that I love. I almost always end up writing a small tool with `serialport-rs` or `tokio-serial`.
<JamesMunns[m]> It's likely you could very quickly fork https://github.com/knurling-rs/defmt/tree/main/print to open a serial port directly to avoid OS meddling
<JamesMunns[m]> (if you're on an M-series mac, I've had problems with serialport, but tokio-serial seems to work)
<JamesMunns[m]> I've been using the patches from https://github.com/serialport/serialport-rs/issues/49, maybe it's fixed now
<JamesMunns[m]> Anyway, good luck, maybe just add some sacrificial dummy logs on startup so you don't miss anything important :D
<JamesMunns[m]> I would guess it's getting out of sync or corrupted on reboot, that's the whole point of rzcobs, it allows for resynchronization after one corrupted packet, which means that you can recover
<JamesMunns[m]> On a reset you'll get two `0x00` back to back, I think this can cause the decoder to print the "malformed" message
<JamesMunns[m]> it trims leading zeros on EVERY push, which might not be right, and could cause you to drop frames if you get unlucky
<JamesMunns[m]> like, if a "successful" set of messages are:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/IylOsqBDhWUEMSAFMHIAoPGz>)
<JamesMunns[m]> ah j/k that branch only triggers on empty
IlPalazzo-ojiisa has joined #rust-embedded
<AdamHott[m]> I trying to get the rusty-probe working to debug an app on the raspberry pi pico w. I soldered 2.54mm pin headers to the SWD through-holes on the pico, and soldered 2.54m pin headers to the pads on the rusty-probe.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/HUSgOoTGCTMSxGcaGydGUYNj>)
<dirbaio[m]> make sure you have the latest probe-rs version
<AdamHott[m]> the firmware?
<AdamHott[m]> do i need to flash the probe?
<AdamHott[m]> or you mean the cli app?
<dirbaio[m]> the probe-rs cli tool yep
<AdamHott[m]> probe-rs 0.21.1
<dirbaio[m]> latest is 0.22. run the command in https://probe.rs/ to update
<AdamHott[m]> same problem
<dirbaio[m]> what does the rusty-probe usb get recognized like?
<dirbaio[m]> (dunno what the macos equivalent of lsusb is)
<AdamHott[m]> same as the pico - RPI-RP2
<AdamHott[m]> two of those mounted
<dirbaio[m]> ahh it's in bootloader mode
<dirbaio[m]> it shouldn't
<dirbaio[m]> you don't have to press the BOOT button on the probe btw
<dirbaio[m]> you only need that if you want to flash the probe itself with a newer firmware
<dirbaio[m]> try unplugging and plugging it back in, without pressing BOOT
<AdamHott[m]> the pico or the probe?
<dirbaio[m]> the probe
<dirbaio[m]> like
<dirbaio[m]> unplug the pico for now, or you'll get confused
<dirbaio[m]> and then unplug+plug the probe without pressing BOOT
<AdamHott[m]> and run the same command to flash the app?
<AdamHott[m]> but won't that flash the app on the probe?
<dirbaio[m]> after you do that, does it still show up in bootloader mode? the RPI-RP2 drive
<AdamHott[m]> the RPI-RP2 gets recognized with the probe
<AdamHott[m]> *as the probe
<dirbaio[m]> then it's missing firmware 😬
<dirbaio[m]> follow the instructions here to flash it
<dirbaio[m]> after you do that, the RPI-RP2 drive should no longer show up for the probe, and probe-rs should start working
<dirbaio[m]> (korken89 Noah is it intended that they don't come with firmwaer?)
<dirbaio[m]> s/firmwaer/firmware/
korken89[m] has joined #rust-embedded
<korken89[m]> They will come with firmware
<korken89[m]> I sent Adam Hott a prototype I build by hand
<dirbaio[m]> ahh okay
<AdamHott[m]> wow one step forward two steps back, I run: DEFMT_LOG=off cargo build --release --bin app
<AdamHott[m]> from the root of the firmware, and I get: error: failed to install component: 'llvm-tools-preview-aarch64-apple-darwin', detected conflict: 'lib/rustlib/aarch64-apple-darwin/bin/llc'
<AdamHott[m]> korken89[m]: thanks again!
<dirbaio[m]> something in your rustup is broken, no idea what
<dirbaio[m]> you can remove llvm-tools-preview from here tho https://github.com/probe-rs/rusty-probe-firmware/blob/master/rust-toolchain.toml#L3
<dirbaio[m]> or maybe try rustup update
<AdamHott[m]> I updated rustup and removed the llvm-tools-preview, tried to build again with previous command: error: failed to install component: 'rust-std-thumbv7m-none-eabi', detected conflict: 'lib/rustlib/thumbv7m-none-eabi/lib/liballoc-ea6fba2d727bcf6d.rlib'
<AdamHott[m]> thanks by the way for all the help
<dirbaio[m]> lol
<dirbaio[m]> maybe try completely removing rustup rm -rf ~/.rustup
<dirbaio[m]> and resintalling it
<dirbaio[m]> these errors make no sense
<sjm42[m]> I have a sincere question. I already have a CMSIS-DAP probe and a BlackMagic debug probe, both are flashed on an STM32F411 "black pill" board.
<sjm42[m]> Should I obtain a rusty probe too, and why? Yeah, I fully agree that just coolness is also a thing. 🙂
<AdamHott[m]> dirbaio[m]: totally don't make sense, here's my rustup show output:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/IALFdVJFWpjHkprrqsyCVkAU>)
<korken89[m]> sjm42[m]: > <@sjm42:matrix.org> I have a sincere question. I already have a CMSIS-DAP probe and a BlackMagic debug probe, both are flashed on an STM32F411 "black pill" board.
<korken89[m]> > Should I obtain a rusty probe too, and why? Yeah, I fully agree that just coolness is also a thing. 🙂
<korken89[m]> If you want a probe that supports high speed and 1.8-3.3v IO voltages it could be something consider :)
<AdamHott[m]> I'm reinstalling let see
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<AdamHott[m]> <dirbaio[m]> "these errors make no sense" <- I uninstalled everything and reinstalled everything and successfully flashed the probe! I have to run for now, but will test more later! Thanks for everything, as always dirbaio korken89 We will solve this!
diondokter[m] has quit [Quit: Idle timeout reached: 172800s]
linfax has quit [Ping timeout: 264 seconds]
RoyBuitenhuis[m] has quit [Quit: Idle timeout reached: 172800s]
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
<JamesMunns[m]> postcard-rpc v0.4 released, now with optional serial deps (for y'all using it with TCP/UDP), and nicer macros :)
mabez[m] has quit [Quit: Idle timeout reached: 172800s]
<korken89[m]> Nice!
firefrommoonligh has joined #rust-embedded
<firefrommoonligh> Hey speaking of postcard and [de]ser, do y'all have a favorite way of serializing structs and enums in a low-code way that uses a fixed format?
<firefrommoonligh> I wonder if maybe Serde could help here
<firefrommoonligh> * postcard and \[de, * [de\]ser, do, * a fixed/flexible format?
diondokter[m] has joined #rust-embedded
<diondokter[m]> Hey all, so there's this undocumented C api and it takes some function pointers to be able to abstract something. I need to provide implementations.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/eYIQUwcCgmgAnBuRRQejnyWB>)
<dirbaio[m]> still working on the nrf71? 👀
<diondokter[m]> Yeah...
<diondokter[m]> But through the OSAL
<dirbaio[m]> but back to the "wrap the C driver" strat instead of "yolo RiiR"?
<diondokter[m]> Yup
<dirbaio[m]> last I checked these dma_map/dma_unmap were implemented as noops in their OSAL
<diondokter[m]> Getting stuck on this DMA thing. At some point it just starts reading from the address I give it. I don't know how to turn that into SPI reads
<diondokter[m]> Really?
<dirbaio[m]> it seems to be some weird remnant from other wifi chips working over PCI, where you have to setup some IOMMU or something to do DMA
<diondokter[m]> Hmmm
<dirbaio[m]> or maybe they were noops and unused
<dirbaio[m]> I don't remember
<diondokter[m]> Well, it's used now... I can't actually find the zephyr implementation of this
<diondokter[m]> Hmmm yeah maybe I have to look more into those. So far haven't understood those interfaces
<dirbaio[m]> whatever that is
<dirbaio[m]> their names and docs make no sense for what these functions do today 🤷
<diondokter[m]> Ok, so I've invented my own bus device types, but maybe I'm supposed to use their SPI or QSPI types?
<diondokter[m]> Yeah...
<dirbaio[m]> there's quite a bit of logic into their spi/qspi impls yeah
<diondokter[m]> It's really weird how their BAL works. Almost no docs
<diondokter[m]> Like, come on man
<diondokter[m]> Oh!
<diondokter[m]> They already implement the BAL ops!
<diondokter[m]> I just need to pass that
<diondokter[m]> Gotcha
<dirbaio[m]> why nrf71? just curious
<diondokter[m]> Why work on it?
<dirbaio[m]> yea
<dirbaio[m]> vs something else, like esp32
<diondokter[m]> Mostly curiosity. And apparently I have a desire to go insane
<dirbaio[m]> 🤣🤣🤣🤣
<dirbaio[m]> okay
<diondokter[m]> I've gotten much further than the last try a year ago haha
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<dirbaio[m]> I don't get what they're doing with the nrf71
<dirbaio[m]> I wouldn't be surprised if sales flop due to it being impossible to use with other RTOSs/MCUs due to the driver being like this
<diondokter[m]> I actually spoke with two Dutch people from nordic today. When I told them I was trying to use the nrf70 with no zephyr and the OSAL layer, they didn't say anything but their faces said I was mad for trying hahaha
<dirbaio[m]> so they KNOW 🤣
<dirbaio[m]> but why
<dirbaio[m]> why do they do this
<diondokter[m]> They're all in on Zephyr
<diondokter[m]> They don't care about anything else
<dirbaio[m]> for their MCUs sure
<dirbaio[m]> but if you want to drive sales of a non-MCU wifi chip you want to make it easy for literally everyone to use it, no matter what MCU/RTOS they're using
<dirbaio[m]> i'd believe it's a big brain play to boost sales of their MCUs if the nrf71 was exceptionally good. like in price or features
<dirbaio[m]> but ... it's not the case:|
<dirbaio[m]> * the case :|
<dirbaio[m]> in a world that esp32 exists
<dirbaio[m]> s/that/where/
<diondokter[m]> Well, they think that the overlap of people wanting to use nordic chips and people wanting to use zephyr is 100% I think
<dirbaio[m]> nordic MCUs sure
<diondokter[m]> 🤷‍♂️
<dirbaio[m]> ¯\_(ツ)_/¯ indeed
<JamesMunns[m]> <firefrommoonligh> "Hey speaking of postcard and [de..." <- Do you mean "design your own", or "describe an existing/external binary format"
pbsds has quit [Ping timeout: 264 seconds]
pbsds has joined #rust-embedded
fuse117[m] has joined #rust-embedded
<fuse117[m]> <diondokter[m]> "Well, they think that the..." <- My colleague and I have spoken with at least two Nordic people in the US over the last month or two. They did seem to assume we were using Zephyr and also inquired into to why we weren't working with them to deploy our products (prototypes). I am not sure how or why we would work with them to deploy devices. The questions were actually a tad confusing. However, they became really
<fuse117[m]> interested when we said that w were running baremetal Rust. They have asked to have some follow-on meetings to learn more about what we are doing and how.
<fuse117[m]> s/w//
<diondokter[m]> Oh yeah, especially Nordics engineers are into Rust. Seems to me it's mostly higher (technical) management holding off the boat
<diondokter[m]> But really, they care most about sales. If there's enough sales for Rust projects, it'll get important to them
<fuse117[m]> "they care most about sales"... don't we all
<diondokter[m]> Well, they want the chicken before they invest in an egg
<diondokter[m]> * the chicken first before they
<dirbaio[m]> > inquired into to why we weren't working with them to deploy our products (prototypes). I am not sure how or why we would work with them to deploy devices
<dirbaio[m]> probably wanted to sell you their iot deployment fleet management cloud thingy https://nrfcloud.com
<fuse117[m]> On of the individuals we spoke is an engineer, and he certainly showed the most interest in Rust. The other was sales manager. He seemed more interested in the market my colleague and I are trying to get into.
<fuse117[m]> dirbaio[m]: > <@dirbaio:matrix.org> > inquired into to why we weren't working with them to deploy our products (prototypes). I am not sure how or why we would work with them to deploy devices... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XlHMGcozdNVDtyCJlsGVNkdW>)
<fuse117[m]> We reached out to ask about the new nrf54H/L chips. We are considering them for some future work.
<fuse117[m]> dirbaio: for new chips like that, what effort goes into to building support for them in embassy?
<dirbaio[m]> there may or may not be embassy nrf54 support in the pipeline 😅
<diondokter[m]> I've heard their peripherals are the same/very similar to existing nordic stuff, so it should be pretty doable
<dirbaio[m]> base is easy, adding a new chip here https://github.com/embassy-rs/embassy/tree/main/embassy-nrf/src/chips
<diondokter[m]> Though CANbus is new!
<dirbaio[m]> then there's new peripherals but you don't have to implement them to get basic stuff working
<dirbaio[m]> then there's the trustzone shit which you can ignore by running in S mode and pretending it doesn't exist
tiwalun[m] has joined #rust-embedded
<tiwalun[m]> <dirbaio[m]> "there may or may not be embassy..." <- nrf54l or nrf54h? very different things
<dirbaio[m]> L, maybe H too
<tiwalun[m]> Nice, L should be a lot easier to handle with baremetal. The H has lots of security things.
<dirbaio[m]> well as long as it doesn't have a "Rust prevention module"... 🤣
<tiwalun[m]> Rust code can run on it, that has already been tried AFAIK
<tiwalun[m]> So no worries there
<diondokter[m]> dirbaio[m]: Zephyr?
<dirbaio[m]> 🦀
<dirbaio[m]> hardware DRM that tries to detect you're not using Zephyr and bricks the chip
<JamesMunns[m]> <dirbaio[m]> "hardware DRM that tries to..." <- That can be the ninth clause of their nine clause bsd license
<JamesMunns[m]> "thou shalt not reverse engineer"
<JamesMunns[m]> "thou shalt not run anything but zephyr"
<diondokter[m]> Finally, the good code!
<diondokter[m]> Yes, the casts are required because they keep casting everything to void pointers for some reason
<JamesMunns[m]> 🦋 is this object oriented programming?
dnm has quit [Ping timeout: 252 seconds]
therealprof[m] has joined #rust-embedded
<therealprof[m]> The story I've been told is that Nordic got tired by the huge amount of work they have to spend on developing all custom BSPs and explaining it's use to people so they decided on picking up a modern embedded OS and put their efforts into that instead. Makes a ton of sense to me.
<therealprof[m]> s/it's/its/
dnm has joined #rust-embedded
<diondokter[m]> therealprof[m]: Makes sense because Zephyr is pretty popular. But it might be the wrong basket for them to have put all their eggs in if it turns out people are gonna move to something else. But the embedded space is very conservative, so... maybe that won't happen
<therealprof[m]> Well, I do think it also became popular because of Nordics endorsement.
<therealprof[m]> It's actually not too different from a lot of other companies (NXP, ST, Cypress/Infineon), who put a shitload of work into not only creating customising some OS but building a whole ecosystem with IDE and whatnot around it.
<therealprof[m]> s/creating//
<diondokter[m]> In my opinion that makes a ton of sense for C. You can't do abstraction well in C.
<diondokter[m]> But with Rust with async and embedded-hal and the other common traits I feel we do it much better
<therealprof[m]> Zephyr is actually quite nice if it is what one is looking for.
<therealprof[m]> It is a whole operating system, so you get things like processes, networking stack, a shell with utilities. It's quite fun to play around with.
<therealprof[m]> Not sure how or if I would use it for a real project though.
<therealprof[m]> It has all the same diseases an old no-MMU suffers from: Crashes due to buggy drivers, stack overflows, out of memory situation, lack of determinism...
<therealprof[m]> * old no-MMU OS suffers from:
<dirbaio[m]> so all the good old C issues :D
<thejpster[m]> To be fair Classic MacOS has those issues and it was written in Pascal
<therealprof[m]> I don't think those are C issues.
<therealprof[m]> Linux is also written in C and has none of those problems.
<dirbaio[m]> Linux can also crash due to shit drivers
<dirbaio[m]> as nvidia users will know 🥲
<dirbaio[m]> Linux has much more users than zephyr so its drivers are usually better
<therealprof[m]> Sure. I also wrote my fair share of bugs. But if a driver crashes, then it's in most cases only the driver that crashes, not the whole kernel. And if a user space application crashes, then well, the OS couldn't care less.
<dirbaio[m]> yeah...
<dirbaio[m]> so an MMU mitigates C problems, so Rust helps much more in no-mmu systems 🦀
<therealprof[m]> I don't think a MMU mitigates C problems but I fully agree that Rust is a much better fit, especially without MMU.
<therealprof[m]> But interacting with an OS running on an MCU is just so much fun and it doesn't exist in Rust.
SanchayanMaity has quit [Ping timeout: 252 seconds]
SanchayanMaity has joined #rust-embedded
AmanieudAntras[m has quit [Quit: Idle timeout reached: 172800s]
amaanq[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> what doesn't exist ... an OS for an MCU written in Rust?
whitequark[cis] has joined #rust-embedded
<dirbaio[m]> embassy 🙃
<whitequark[cis]> do you classify embassy as an OS?
<whitequark[cis]> I wouldn't disagree with that, it's just a little surprising
<dirbaio[m]> yes and no?
<dirbaio[m]> yes because it gives you the things a typical C RTOS gives you (tasks, mutexes, IPC, scheduling, preemption)
<dirbaio[m]> no because the mechanism it uses to do that is different: async, which is transformed into state machines by the compiler, instead of a real OS kernel doing context switching etc
<whitequark[cis]> it could be classified as an exokernel
<whitequark[cis]> but also, is tokio an OS?
<whitequark[cis]> (I don't think I would disagree with that either! tokio as a semi-transparent virtualization layer)
<dirbaio[m]> tokio isn't an OS because it's not self-contained, it calls into Linux
<dirbaio[m]> OSs talk to the hardware
<M9names[m]> OS's often talk through a hypervisor - is software indistinguishable from hardware not software any more?
<dirbaio[m]> hypervisors pretend to be hardware
<M9names[m]> if i wrote an program that hosted other programs and only talked the hardware exclusively through an API provided by BIOS/EFI, is that not an OS?
<dirbaio[m]> no, that's an EFI application :)
<M9names[m]> i think we're going to have to agree to disagree about this definition 😄
<dirbaio[m]> I guess you'll say "and MS-DOS is a BIOS application then?" :P
<dirbaio[m]> MS-DOS didn't just use the BIOS though?
<dirbaio[m]> yeah
<dirbaio[m]> I guess defining "OS" is hard 🤣
<JamesMunns[m]> This goes back to my "Wanting an RTOS is often an X/Y problem"
<JamesMunns[m]> like sometimes you do really want specifically:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/wlnnDbZPhssDQHLwoPHKeyas>)
<JamesMunns[m]> like I wouldn't call embassy an rtos, and even after suggesting rtic call themselves a "hardware accelerated rtos", I feel like those are both "I can't believe it's not RTOS" lol
<JamesMunns[m]> they certainly have RTOS aesthetics