<wassasin[m]>
<wassasin[m]> "Basically every task only has..." <- I believe so yes
crabbedhaloablut has quit [Read error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
cinemaSundays has joined #rust-embedded
<thejpster[m]>
I've been thinking about how we move from defmt 0.3 to defmt 1.0 and begin our commitment to stability, just like the Rust Project did when they released 1.0.
cinemaSundays has quit [Quit: Connection closed for inactivity]
netcreature has quit [Quit: WeeChat 3.5]
sroemer has quit [Ping timeout: 272 seconds]
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
TomB[m] has joined #rust-embedded
<TomB[m]>
Do people here feel like CHERI adds much if Rust is already being used?
<TomB[m]>
I keep looking at the papers/talks/etc about CHERI and it always to me seems as if its solving a similar issue in a different way, but maybe I'm looking at it all wrong
<JamesMunns[m]>
It strikes me as "what if you smashed together a runtime sanitizer as an mmu". I think it's the same as the mpu discussion from before: it probably is less useful (if ever?) for safe code, might be useful for FFI and unsafe code, might not be the best return on value.
<barafael[m]>
I'm trying to update a serial-based driver (ublox-core) to e-h-1. I only need to read NMEA sentences from the serial port. These are messages delimited by \r\n. What's the best practice? I don't want to do the ring buffer dance for my manual LinesCodec manually...
<barafael[m]>
(and yes :) I have heard the SDR episode on framing) :D
<dirbaio[m]>
read byte-by-byte until you find \r\n, yes
<dirbaio[m]>
i'm afraid 🥲
<JamesMunns[m]>
bbqueue has a "read all available" method, so you could impl a driver that just shoves bytes into it, and maybe hits a waker every time an Rx occurs? I don't think this exists already "off the shelf" tho
<barafael[m]>
huh. I think this is an interesting gap in the ecosystem. Codecs for embedded-io? With predefined codecs for LinesCodec, BytesCodec, COBS, LengthDelimitedCodec, etc. It's just no_std tokio_util::framed::Codec
<barafael[m]>
I don't want to buffer in a BufRead, then buffer in a LinesReader, then write into a buffer from there?! Seems inefficient. I think I have to make an implementation of BufRead that observes line delimiters
<M762spr[m]>
I think its because map, once the prefix is stripped is [50, 0, 0, 0...] and those trailing 0's are mucking it up behind the scenes. calling "2".parse() works
<M762spr[m]>
* I think its because msg, once the prefix is stripped is \[50, 0, 0, 0...\] and those trailing 0's are mucking it up behind the scenes. calling "2".parse() works
whitequark[cis] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
I think parse splits on whitespace
<JamesMunns[m]>
the null char is valid utf-8 but it's probably not a valid separator
<M762spr[m]>
hm any suggestion on how to make this work? I don't know where to chop the slice since I don't know what utf-8 number will be coming in. it may be more than one digit
<JamesMunns[m]>
(split on the first non-ascii-num char?)
<M762spr[m]>
ah that's similar to what I was working on but I didn't know is_ascii_digit() was a thing. that makes it easier thanks!
<M762spr[m]>
I hate that I have to put this much logic into parsing a simple number but I guess it is what it is 🙃
<JamesMunns[m]>
I have lots of opinions about protocols and framing 😅. Not sure if you're building something new or integrating with something off the shelf.
RockBoynton[m] has joined #rust-embedded
<RockBoynton[m]>
where is deftmt_rtt's buffer stored? I see from the lib.rs it there is a link_section attribute, but doesn't that need to be defined to be in flash or ram somewhere?
<dirbaio[m]>
I htink the advantage of putting it in .uninit.defmt-rtt.BUFFER instead of .uninit is you can change where it goes with a custom linker script
<RockBoynton[m]>
ok so I don't think that was stopping me from what I really want to do;
<RockBoynton[m]>
I want to put some large buffer in flash memory, and I define a section in the linker script and put the link section attribute on the buffer, I get this error message when I run:
<RockBoynton[m]>
`ERROR probe_rs::cmd::run: Failed to attach to RTT continuing...`
<JamesMunns[m]>
Does the buffer look like it's in the right place in cargo nm --release -- -nS?
<JamesMunns[m]>
(also - not the defmt buffer, right? you mean some other unrelated read only buffer in flash?)
<RockBoynton[m]>
JamesMunns[m]: yes actually I want it read/write though
<JamesMunns[m]>
RockBoynton[m]: you can't really put read/write data in flash like that?
<JamesMunns[m]>
like, you can't generally transparently write to flash like that.
<RockBoynton[m]>
oh I have to use the flash peripheral from the device then?
<JamesMunns[m]>
yes, and handle erases (which are very slow) and writes (which are slow) manually
<JamesMunns[m]>
you could write a defmt backend that writes to flash, but it will be very slow and significantly impact your app's running speed
<JamesMunns[m]>
or you could use something like defmt-bbq, write to a ring buffer, and write to flash, but it can't be the flash you're running code out of, or it will likely make your CPU stall.
<RockBoynton[m]>
no the defmt thing was just me trying to see why I couldn't read to some flash memory linker section but I understand now I can't just do that
<RockBoynton[m]>
I really just want to be able to read/write some data to flash at run time. I was hoping to use the internal flash, even use a different bank. But I also have an external flash I can use as a last resort
<JamesMunns[m]>
You'll have to check, if you do have two banks, you can usually write to a bank if you are not running code out of that bank
<JamesMunns[m]>
but most flash parts stall access (at least to that bank) when doing an erase or write to it.
<RockBoynton[m]>
I mean that is what I was trying to do here
<RockBoynton[m]>
FLASH is one bank and DATA is another, this is the stm32h743
<RockBoynton[m]>
with 2 MB flash
<RockBoynton[m]>
each bank is 1 M
<JamesMunns[m]>
makes sense! if it's just "write stuff", yeah, you can probably do that!
<JamesMunns[m]>
(using it to store defmt data directly is probably not well advised, as it will still be very slow because defmt does blocking writes with critical sections!)
<JamesMunns[m]>
but if it's "not defmt data", then could be reasonable, as long as it isn't in the critical path
<RockBoynton[m]>
well, I do want to write/read structured rust data, not really considering using defmt at all here