05:31 <andodeki2[m]> How are you guys?

05:31 <andodeki2[m]> Di we have support for TI C2000 series microcontroller?

08:17 <davidmpye[m]> Hi - I have a design question. If you were writing a parser for a protocol - ie that produces a struct (with various values in), which is copies from an array of bytes, is it reasonable for that struct to implement TryFrom to take the array of bytes, and generate the struct that the bytes represent? Or is there a better design pattern? :-)

08:18 <davidmpye[m]> (I was leaning TryFrom because if the byte array is malformed in some way, the TryFrom can fail)

09:18 <JamesMunns[m]> <andodeki2[m]> "How are you guys?..." <- > <@andodeki2:matrix.org> How are you guys?

09:18 <JamesMunns[m]> > Di we have support for TI C2000 series microcontroller?

09:18 <JamesMunns[m]> The C2000 is a DSP core, I don't think it's supported by LLVM at all, or Rust.

09:19 <JamesMunns[m]> davidmpye `TryFrom` is reasonable, most parsing libraries tend to have their own traits, like `Deserialize` from `serde`, but you could use `TryFrom` instead.

09:24 <JamesMunns[m]> TryFrom also takes ownership, so you probably want to implement it for `TryFrom<&[u8]>` I guess?

09:43 <vollbrecht[m]> <JamesMunns[m]> "> <@andodeki2:matrix.org> How..." <- yeah, they have this inhouse delfino c28x cores. Unfortunatly compilers are pretty limited to what you get from TI here. Sad, because this controllers have really good quality hardware peripherals.

09:43 <vollbrecht[m]> But yeah the last time i programmed one was through Matlab that generated the C code and then run with that. While Matlab is nice for a lot of stuff i really dont like to write my controller code in it :D

09:45 <vollbrecht[m]> I know a lot of people still uses this chips in high power electronics, in there control loops etc.

09:45 <JamesMunns[m]> The last time I programmed one of those was in university, like 13 years ago at this point :D

09:46 <JamesMunns[m]> But to be fair, I've never worked in typical DSP places like audio or switching electronics or motor control

09:51 <davidmpye[m]> <JamesMunns[m]> "TryFrom also takes ownership, so..." <- Yep, that was my thought. And it'll return either parsed struct or an error

09:54 <JamesMunns[m]> davidmpye[m]: Yeah, I think that's fine. Eventually you might want you own trait, but if it's for a specific protocol or whatever, it should be okay.

09:54 <JamesMunns[m]> It gets trickier if you want to do recursive/derive type stuff. e.g. you have a struct that has 4 fields you parse separately, because then you might run into issues if say `u32` already impls `TryFrom<&[u8]>` (I don't think it does, but also with the orphan rules i'm not sure if you could implement that)

09:54 <JamesMunns[m]> JamesMunns[m]: > <@jamesmunns:beeper.com> Yeah, I think that's fine. Eventually you might want you own trait, but if it's for a specific protocol or whatever, it should be okay.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/XUOqhLDdzjeSojoHpqKNSVmN>)

09:56 <davidmpye[m]> I'll have to copy the bytes into the struct though as I can't just slice the buffer up, as otherwise the contents won't be valid once the next packet arrives and overwrites the buffer?

09:57 <davidmpye[m]> It's a fairly niche 9 bit serial protocol specific to vending machines (MDB)

09:57 <JamesMunns[m]> You'll either need to buffer partial messages, or have the whole message at once, yes

09:58 <JamesMunns[m]> Not sure how MDB handles framing, or determining whether you have a whole message

09:58 <davidmpye[m]> Interestingly, quite simply. The slave device sets the 9th bit on the last byte of it's reply

10:00 <JamesMunns[m]> Ah, nice! Love to see "out of band" signalling :D

10:00 <davidmpye[m]> Also, because all messages are in reply to a poll or specific query from the master, most are of fixed length

10:00 <JamesMunns[m]> (at least out of the data bits)

10:00 <davidmpye[m]> But even if they aren't, you know if you got the end by the 9th bit

10:02 <davidmpye[m]> Of note, PIOs are excellent for implementing a 9 bit serial uart

10:02 <davidmpye[m]> Some of the atmel at series have 9 bit hw support but most newer mcus don't have 9 bit support in their onboard uart peripherals these days because only a few niche cases use it

10:03 <JamesMunns[m]> STM32s I think have it pretty commonly

10:03 <JamesMunns[m]> I was looking for RS-485 support recently

10:04 <JamesMunns[m]> but yeah, nRF52 and RP2040 (at least in the hardware serial port) didn't support 9-bit

10:05 <JamesMunns[m]> RS-485 often uses 9-bit serial to do addressing, so the 9th bit is used to signal "address" vs "data", and STM32 has 9-bit address matching abilities so you can ignore data until you are addressed

10:05 <davidmpye[m]> The master uses 9th bit to indicate address, the slave uses 9th bit for end of message

10:06 <davidmpye[m]> It does have some similarities to 485

10:06 <JamesMunns[m]> Yeah, only so creative you can get on a shared medium, I suppose :)

10:06 <JamesMunns[m]> I ended up using a "line break" for signalling instead and using 8-bit bytes because more devices supported that in hardware

10:07 <JamesMunns[m]> (and I didn't feel like learning how to write PIO code, but it's more than capable :D)

10:07 <davidmpye[m]> It's a shared optoisolated bus running at 9k6 so in theory even bitbanging would work, but why when you have pio

10:08 <JamesMunns[m]> yeah, bitbanging OUT is pretty easy at 9600 baud, but doing it reliably IN means pretty much busy looping

10:08 <JamesMunns[m]> so definitely a good use for the PIO :D

10:12 <davidmpye[m]> It was only a relatively minor charge to the stock 8 bit uart example for me. Still rewriting bits or my project from c into rust as I learn more of it

13:05 <omniscient_[m]> Ooh. I've been doing some RS-485 work recently but in C, not in Rust yet.

13:24 <korken89[m]> <rmsyn[m]> "https://codeberg.org/weathered-..."; <- Thank you, that was great inspiration! I almost have a working parser for the generated C headers. I thought I could use `lang-c` but it trashed the comments in the generated file.

13:32 <korken89[m]> nom to the rescue as always eh? :D

17:25 <bartmassey[m]> <vollbrecht[m]> "yeah, they have this inhouse..." <- > <@vollbrecht:matrix.org> yeah, they have this inhouse delfino c28x cores. Unfortunatly compilers are pretty limited to what you get from TI here. Sad, because this controllers have really good quality hardware peripherals.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uoNFEyROuJKFUMSVJMHANYOg>)

17:39 <chrysn[m]> I'm low-key looking into how to spool log data on a device and then pull it out over the network.

17:40 <chrysn[m]> AIU, in the serialized format, there is no way to determine from a data stream when one record ends and the next starts without the string information.

17:42 <chrysn[m]> The best I found in terms of keeping track is defmt-bbq, which (using some internal framing) can recover from an overflow.

17:44 <chrysn[m]> But that means that an overflow is necessary before a message can be processed, so it can't keep the last (say) 2KiB of values around for when a client connects, but needs to stay in the overflow condition and only then starts reporting -- whereas with the current implementation of text based logging in coap-scroll-ring-server, I can let the buffer overwrite itself freely, and at any time a client can connect and read the full

17:44 <chrysn[m]> buffer (provided it is fast enough to keep up -- but even if everything is too fast, it can keep a snapshot).

17:47 <chrysn[m]> Have other framing methods been explored? My current approaches (which I'd hope to narrow down are):... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/iqnaHRlNCaUIKdCyhlRzWmOp>)

17:47 <chrysn[m]> (Messing with defmt internals and changing the serialization format would be a 4th option, but I'm not that desparate yet :-) )

17:52 <dirbaio[m]> <chrysn[m]> "AIU, in the serialized format..." <- Defmt encoded with rzcobs (the default) separates records with a zero byte

17:52 <jduck[m]> I think the typical approach is ring buffer(s). Of course dropping can happen but what can you really do about that? If you don't care to empty the ring buffer then no one is really looking at the log entries anyway

17:52 <JamesMunns[m]> chrysn[m]: I've proposed this to the defmt devs, btw

17:52 <chrysn[m]> Great, thanks – I misunderstood its description to mean that it only emits zeros on overflow so that resyncs can happen

17:52 <JamesMunns[m]> chrysn[m]: Looking at using postcard (and probably still rzcobs)

17:53 <JamesMunns[m]> Agreed that rzcobs is enough to split frames tho

18:44 <PedroFerreira[m]> does anyone have a sample config for OpenOCD + RTT?

18:46 <PedroFerreira[m]> i can't seem to find anything on the web

18:56 <PedroFerreira[m]> trying openocd -f interface/cmsis-dap.cfg -f target/rp2350.cfg -c "adapter speed 5000" -c "rtt setup 0x20020000 2048 \"SEGGER RTT\"; init; rtt start"; but it tells me that it can't find the control block

18:58 <PedroFerreira[m]> according to readelf, it should be at 0x200203f0

19:09 <PedroFerreira[m]> hm... maybe the whole thing is blowing up even before there is a control block in RAM

19:21 <PedroFerreira[m]> (yeah, that was it)