12:03 <therealprof[m]> <jason-kairos[m]> Does cortex M3/M4 etc. have better code density than M0/M0+? (ie. how many bytes of flash needed for the same program between the two)...

12:03 <therealprof[m]> Yes, M0(+) is missing some important instructions like multiple load/store, CAS, integer division, 32x32->64 bit multiplication, saturated arithemtics and long jumps which can have a significant impact on code size. OTOH, some of those features can also cause code bloat on >=M3 due to compilers assuming you'd rather prefer to go fast...

13:22 <thejpster[m]> *Technically* it's Arm architecture v6 M-Profile (Armv6-M) that is missing these features. But yes, Cortex-M0 and Cortex-M0+ both implement Armv6-M and nothing more. And I think Armv6-M does include LDM/STM (load multiple / store multiple)?

13:22 <thejpster[m]> Cortex-M3 implements Armv7-M, and so has these features. Armv7-M is basically fully Armv6-M compatible.

13:22 <thejpster[m]> Pendantry, perhaps, but I find it easier to talk about an archtecture revision (Armv7E-M, say), rather than the set of processors which implement that architecture (which changes occassionally as new processors are released).

14:36 <jason-kairos[m]> I've got a silly question, perhaps a Friday brain fart... (full message at <https://catircservices.org/_irc/v1/media/download/Aai4QFMHdbZHA053E5qVYRDrLoaAmQ9E6qpCY0DS8ib5Fw01ssOMDkYtwTcAG1giNlYDrXpedtSyU2QB20i3kim_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9LV1haYnZyc2dZaVdkU0RRTGZjT2FYZ2U>)

14:38 <jason-kairos[m]> For some reason, I feel like I'd be very prone to implement this sort of comparison incorrectly.

14:39 <jason-kairos[m]> * I've got a silly question, perhaps a Friday brain fart... (full message at <https://catircservices.org/_irc/v1/media/download/AVQQtvtLzMr-HfDvFdTL0E453GDDiftIiFkMc3chWIHHc9WzRa-cpmbDBRdph33He6vxZh3IGoPBPw1wH8Nr5mW_8AAAAAAAAGNhdGlyY3NlcnZpY2VzLm9yZy9VeUZKQ0dPS1dNa2ZWSmxsZHVUeFBqeVI>)

14:56 <therealprof[m]> <thejpster[m]> *Technically* it's Arm architecture v6 M-Profile (Armv6-M) that is missing these features. But yes, Cortex-M0 and Cortex-M0+ both implement Armv6-M and nothing more. And I think Armv6-M does include LDM/STM (load multiple / store multiple)?...

14:56 <therealprof[m]> I still fail to wrap my head around what's part of the architecture and part of the ISA. There're some optional features in ARMv6-M which M0 and M0+ IIRC don't implement, then there's also the Thumb instruction compression which ARMv6-M only supports most of the T1 instructions but few T2 instructions (which can be up to 32bit wide and thus much more powerful) which ARMv7-M supports much more extensively. You're probably right

14:56 <therealprof[m]> about LDM/STM and their variants but I'm pretty sure ARMv7-M has much more powerful variants which the Rust `copy` functions lower into (and are used by the initialisation code) which generates a bit of bloat for those processors because of the faulty assumption that everyone wants to have those functions as performant as possible...

15:02 <phloopy[m]> Total noob question—I’m new to rust and embedded dev (but experienced in other languages and platforms). I’m really liking the idea of a Pi Pico 2 W + Rust for a project but I need a syncing database like convex.dev for it. Is the state of embedded rust mature enough that the existing rust client for convex is likely to work on the Pico?

15:03 <diondokter[m]> phloopy[m]: Rust is mature enough. But the real question is whether the convex client is no_std or not

15:03 <dirbaio[m]> https://github.com/get-convex/convex-rs

15:03 <dirbaio[m]> it's not

15:03 <diondokter[m]> Was just looking too

15:06 <phloopy[m]> RIP

15:06 <dirbaio[m]> so you can't use it. you can only use no-std crates

15:06 <dirbaio[m]> the only exception is esp32xxx chips with esp-idf-hal (not esp-hal) which have a (partial) rust std port

15:07 <dirbaio[m]> but IIUC it still won't run most libs unmodified, you have to do some porting/patching

15:07 <dirbaio[m]> and even if you get it working, it's likely you'll run out of flash or RAM fast, because libs that aren't designed for embedded are typically quite wasteful with memory

15:07 <wassasin[m]> It might be easier to have a backend service running somewhere that sits in between your embedded device and convex

15:07 <diondokter[m]> wassasin[m]: Yeah, this'd be my advice too

15:08 <dirbaio[m]> the whole point of convex is not needing a backend (assuming it's like firebase and co)

15:08 <phloopy[m]> dirbaio[m]: Unfortunately it’s the PIO features of the RP2350 in particular that makes the Pico 2 especially suitable for this project.

15:09 <dirbaio[m]> you might want to look at lighter protocols that do have nostd libs. mqtt, http, coap

15:10 <dirbaio[m]> and yeah you'll need some kind of backend

15:10 <phloopy[m]> Yeah, the backup plan was a different Pi that runs the syncing stuff and then forwards it on to the pico for interfacing with the hardware.

15:10 <dirbaio[m]> or write a convex nostd client

15:11 <dirbaio[m]> * nostd client, not sure how easy that'd be

15:11 <dirbaio[m]> it seems it uses weboskcets, I think there are websocket nostd libs

15:13 <KevinPFleming[m]> someone in the Embassy room has a design which combines an RPi CM5 and an RP2040, sounds like something similar would work here

15:14 <dirbaio[m]> writing a small backend seems easier than making the device be a whole rpi+pico and managing both the linux side and the embedded side etc

15:16 <phloopy[m]> Maybe—sync is hard.

15:16 <phloopy[m]> Are there any existing syncing databases (or non-databases) for embedded rust?

15:17 <dirbaio[m]> do you need to actually sync? so the Pico stores it on flash and can query it offline?

15:18 <dirbaio[m]> how big is the dataset, how often does it change?

15:19 <phloopy[m]> I need realtime control from the cloud. Dataset isn’t large though, MBs at a time.

15:20 <diondokter[m]> phloopy[m]: For embedded that's gigantic

15:20 <dirbaio[m]> yea. the pico has 256k ram, 2mb flash

15:20 <diondokter[m]> A normal modern microcontroller has in the range of 128-1024kb flash

15:20 <phloopy[m]> Oof.

15:21 <dirbaio[m]> yeah maybe you'll need a full fat linux rpi 😅

15:21 <dirbaio[m]> depends on what the dataset is and the pico does I gues

15:22 <dirbaio[m]> s/gues/guess/

15:22 <firefrommoonligh> I would use a QSPI flash chip for that

15:22 <dirbaio[m]> maybe you can preoprocess/precompute/filter as much as possible in the backend so that the pico is as dumb as possible and needs as little data as possible

15:26 <phloopy[m]> The pico can stream the data if it doesn’t have to handle the sync part. I like the idea of using the PIO to control light strips; my understanding so far is that I’d be able to control 12 of them using PIO simultaneously with perfect timing, but using GPIO on a compute module wouldn’t be as reliable and would have a lower limit of available strips.

15:29 <diondokter[m]> phloopy[m]: Yeah, sounds like you'll want some backend the pico can connect to.

15:29 <diondokter[m]> The backend syncs the state and only streams commands to the pico.

15:31 <phloopy[m]> Bummer! Maybe they’ll add PIO features to the bigger Pi’s eventually and I can get it down to one system.

15:31 <phloopy[m]> Thanks for all the help!

15:31 <dirbaio[m]> actually the pi 5 does have pio

15:31 <dirbaio[m]> https://www.raspberrypi.com/news/piolib-a-userspace-library-for-pio-control/

15:34 <phloopy[m]> Awesome! I’ll look into that. Looks like it’s just a single PIO block though so can only drive 4 strips. Promising news for future versions though!

15:34 <jason-kairos[m]> Has anyone here ever tried to use LLVM's newish MC/DC test coverage with Rust?

15:44 <thejpster[m]> yes

19:28 <thejpster[m]> today I tried and failed to run a big-endian Arm program in QEMU. It *supports* it, but when you do semihosting, reads from memory are byte-swapped within each word. So, the ":tt\x00" string we pass a pointer to is found in target memory as "\x00tt:", which obviously doesn't work.

19:28 <thejpster[m]> Does anyone have any working big-endian hardware? Without a platform to test on, the target should probably go to Tier 3.

19:29 <thejpster[m]> I hacked up the string, so it would appear to qemu as ":tt", and then I saw lleHt ,o sihs sihimeitso !gn. Yeah, that's byte-swapped alright.

19:31 <thejpster[m]> the strings look fine in a hexdump of .rodata, so pretty sure it's a QEMU bug. They don't officially support qemu-system-arm in big-endian mode, because none of the machines they emulate work with big-endian processors (I was just hope that as I didn't use any of the peripherals, and only did semihosting, that wouldn't matter).

19:46 <whitequark[cis]> wait until you discover how big-endian support in LLDB works

19:46 <whitequark[cis]> (it's the same thing)

19:47 <whitequark[cis]> also the gdbserver protocol doesn't have any command to expose endianness and the LLDB-custom command that does has its result ignored in release builds and hits an assert in debug builds