06:53 <re_irc> <korken89> Hi all, does anyone know of a logging aggregation lib that can be used with embedded? I'm sending logs for our embedded systems that we have in field (by sending the internal "defmt" logs), but it sometimes generates so much logs that I'd like aggregate them somehow. And preferable not write my own, it feel like someone before me should have had this problem xD

06:53 <re_irc> <korken89> Used with embedded is misleading, just that I can shove the embedded logs into in a backend service

06:55 <re_irc> <korken89> What I have is UUID (of the embedded MCU), log-level, log-message for now

06:59 <re_irc> <korken89> And lets say 10 000 units in the field say "error X" I'd like to see that 10 000 units has reported error X and not sift through 10 000 lines of error X

06:59 <re_irc> <korken89> Or something like that

06:59 <re_irc> <korken89> I'm not sure what I want tbh, but 10k lines of the same error is not what I want xd

06:59 <re_irc> <korken89> * xD

07:04 <re_irc> <K900> I'd look into sentry.io

07:04 <re_irc> <K900> If it's error logs specifically

07:06 <re_irc> <K900> I don't think the official SDK will run on no_std

07:06 <re_irc> <K900> But you can have some sort of proxy inbetween

07:24 <re_irc> <korken89> Ah yeah

07:24 <re_irc> <korken89> I don't need no_std :D

07:25 <re_irc> <korken89> I'm getting the logs to our backend today, just need the aggregation

07:25 <re_irc> <korken89> I'll give sentry a look!

07:25 <re_irc> <korken89> I hope I can host it ourselves

07:27 <re_irc> <K900> You can

07:28 <re_irc> <K900> It's open source

07:28 <re_irc> <korken89> Nice!

07:29 <re_irc> <K900> And the SDK is definitely worth looking into too

07:30 <re_irc> <K900> It can give you lots of info for basically free

07:31 <re_irc> <korken89> Thanks for the tip! I'll start reading into it!

17:28 <re_irc> <James Munns> The other, more embedded focused version would probably be Memfault, but I know they also offer a bunch of other stuff (OTA, cohort management, etc)

17:28 <re_irc> <James Munns> but, if you're already at the "get logs to a PC" stage, you'd probably be just as happy with sentry AFAIK

17:29 <re_irc> <James Munns> (and while I know some of the folks at memfault and they are interested in Rust, I don't think they have any kind of official support for it)

19:48 <re_irc> <korken89> Yeah I have their stuff a look, but it looks like it's exclusively for C

19:48 <re_irc> <korken89> Would be quite nice to have a simple logging aggregator for defmt logs with some metadata

19:50 <re_irc> <korken89> I more or less got sentry working though

19:50 <re_irc> <korken89> A bit overkill, but hey it works :D

21:15 <re_irc> <kristoff 🇧🇪 🇪🇺> hi all, Small question. I'm interested in diving into rust, mainly for on microcontrollers.

21:15 <re_irc> What is the most easy-to-use development environment to start out with rust?

21:15 <re_irc> My platform is ubuntu (20.04LTS).

21:15 <re_irc> I have devices from arduino,STM32F1 and F4, ESP32 and longan-nano (RV32).

21:17 <re_irc> <kristoff 🇧🇪 🇪🇺> I did find some blog-posts for rust on arduino, stm32 and on RV, but they all seems to have something that did not work

21:17 <re_irc> <adamgreig> which arduino? overall any of them can run rust, but of those four the stm32f4 is probably the most widely used already

21:19 <re_irc> <kristoff 🇧🇪 🇪🇺> I have a couple of uno's, some nano, a nano every and a mega (I think)

21:19 <re_irc> <kristoff 🇧🇪 🇪🇺> I have a lot of STM32F103's, and also a STM32F4 discovery board

21:20 <re_irc> <kristoff 🇧🇪 🇪🇺> ah yes, I also have a BBC microbit too (which I bought half a year ago, and not yet used) .. if that is an option

21:20 <re_irc> <kristoff 🇧🇪 🇪🇺> * option?

21:21 <re_irc> <adamgreig> the arduinos that have AVR processors require a little bit more work to get started with because of the less common architecture, though it's possible

21:21 <re_irc> <adamgreig> yea, the micro:bit is also very well supported, in fact there's a whole book on getting started with rust on one: https://docs.rust-embedded.org/discovery/microbit/

21:22 <re_irc> <kristoff 🇧🇪 🇪🇺> adamgreig: ah .. that is interesting !

21:22 <re_irc> <adamgreig> the stm32f1, stm32f4, and microbit (v1 and v2) are all ARM Cortex-M microprocessors, so from Rust's point of view those are all the same, and various people work on libraries to help support the specific chips

21:22 <re_irc> <adamgreig> but yea, if you are just getting started the discovery book for the microbit might be a good option

21:24 <re_irc> <kristoff 🇧🇪 🇪🇺> looks very interesting .. thanks ...

21:24 <re_irc> I'll start with that!

21:24 <re_irc> <adamgreig> if you have any questions or get stuck anywhere please feel free to ask here, or you can use the discussions on the github repository too https://github.com/rust-embedded/discovery/discussions

21:25 <re_irc> <kristoff 🇧🇪 🇪🇺> thanks

21:26 <re_irc> <kristoff 🇧🇪 🇪🇺> I'll first see how far I can get on myself, and pop in here if I get stuck for some reason !

21:27 <re_irc> <kristoff 🇧🇪 🇪🇺> what's your development enviroment ? linux?

21:28 <re_irc> <adamgreig> mine is, yes, though on the whole rust makes it very easy to develop on mac or windows too

21:29 <re_irc> <adamgreig> vscode is very popular with the rust-analyzer plugin and works everywhere; I use vim on linux (also with rust-analyzer)

21:30 <re_irc> <adamgreig> for actually programming your devices, you can use the common tools like openocd, but for cortex-m and risc-v there's also http://probe.rs which has a vscode extension, or the "cargo-embed" (https://crates.io/crates/cargo-embed) command to load your code onto the microcontroller, or there's also https://crates.io/crates/probe-run

21:30 <re_irc> <adamgreig> (the discovery book covers this too)

21:33 <re_irc> <kristoff 🇧🇪 🇪🇺> i'll start with the same setup you have .. just gvim .. I can move to vscode later, if needed

21:33 <re_irc> <kristoff 🇧🇪 🇪🇺> just oging over the book now ... interesting ..

21:34 <re_irc> <kristoff 🇧🇪 🇪🇺> just wondering .. this is mainly about the peripherals ..

21:35 <re_irc> <kristoff 🇧🇪 🇪🇺> how do you talk to somehing like timers and interrupts

21:35 <re_irc> <kristoff 🇧🇪 🇪🇺> are the HALs layered?

21:36 <re_irc> <kristoff 🇧🇪 🇪🇺> one for arm cortex ...

21:36 <re_irc> another one for the chip

21:36 <re_irc> and another one for the board (chip + other chips?)

21:38 <re_irc> <kristoff 🇧🇪 🇪🇺> ok .. found it .. at "board" level, there is the BSP

21:38 <re_irc> <adamgreig> the diagram at the top of this page gives some hints https://docs.rust-embedded.org/book/start/registers.html

21:39 <re_irc> <adamgreig> on the whole I would say BSPs are a bit less common in rust because you often don't really need them, but yea, that's the "board" level and it would usually pull together drivers for your various peripherals, give you pin names that match the board (instead of the chip), etc

21:39 <re_irc> <adamgreig> there's a HAL For the CPU in the cortex-m crate, and a "PAC" (peripheral access crate) that provides direct register access for a specific microcontroller, like the stm32f4 crate, and a HAL that uses the PAC to provide a high-level interface, like the stm32f4xx-hal crate

21:40 <re_irc> <adamgreig> then lots of drivers for other chips like accelerometers, displays, that sort of thing that you talk to over i²c or spi or uart, which are written to run on lots of different microcontrollers

21:40 <re_irc> <adamgreig> the HALs mostly all implement a shared set of traits so that drivers can be generic and work with lots of HALs

21:41 <re_irc> <kristoff 🇧🇪 🇪🇺> wauw ! Nice!

21:42 <re_irc> <kristoff 🇧🇪 🇪🇺> was this all designed like this from the start? When rust was developed?

21:44 <re_irc> <adamgreig> all of this is basically a community effort, not part of rust-the-language at all, though the shared HAL traits are developed by the "embedded working group", which is part of the rust project

21:45 <re_irc> <kristoff 🇧🇪 🇪🇺> nice :-)

21:46 <re_irc> <adamgreig> yea! the success of the shared traits and how well portable drivers actually work is really really nice

21:46 <re_irc> <adamgreig> like, in most cases the same drivers will work on a raspberry pi running linux, on a modern desktop linux, on an 8-bit AVR in an arduino, on a cortex-m, on a risc-v soft-core inside an FPGA...

21:49 <re_irc> <kristoff 🇧🇪 🇪🇺> ok .. i'll start read and experimenting now .. thank you for your great help

21:57 <re_irc> <kristoff 🇧🇪 🇪🇺> * reading