ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to and logged at, code of conduct at
starblue has quit [Ping timeout: 246 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
Socke has quit [Quit: WeeChat 3.3]
seds has quit [*.net *.split]
badboy_ has quit [*.net *.split]
ni has quit [*.net *.split]
Rondom has quit [*.net *.split]
badboy has joined #rust-embedded
Rondom has joined #rust-embedded
ni has joined #rust-embedded
seds has joined #rust-embedded
seds has quit [Changing host]
seds has joined #rust-embedded
Abhishek_ has quit [*.net *.split]
edm has quit [*.net *.split]
edm has joined #rust-embedded
Abhishek_ has joined #rust-embedded
ni has quit [Changing host]
ni has joined #rust-embedded
<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
<re_irc> <korken89> Used with embedded is misleading, just that I can shove the embedded logs into in a backend service
<re_irc> <korken89> What I have is UUID (of the embedded MCU), log-level, log-message for now
<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
<re_irc> <korken89> Or something like that
<re_irc> <korken89> I'm not sure what I want tbh, but 10k lines of the same error is not what I want xd
<re_irc> <korken89> * xD
<re_irc> <K900> I'd look into
<re_irc> <K900> If it's error logs specifically
<re_irc> <K900> I don't think the official SDK will run on no_std
<re_irc> <K900> But you can have some sort of proxy inbetween
gsalazar has joined #rust-embedded
<re_irc> <korken89> Ah yeah
<re_irc> <korken89> I don't need no_std :D
<re_irc> <korken89> I'm getting the logs to our backend today, just need the aggregation
<re_irc> <korken89> I'll give sentry a look!
<re_irc> <korken89> I hope I can host it ourselves
<re_irc> <K900> You can
<re_irc> <K900> It's open source
<re_irc> <korken89> Nice!
<re_irc> <K900> And the SDK is definitely worth looking into too
<re_irc> <K900> It can give you lots of info for basically free
<re_irc> <korken89> Thanks for the tip! I'll start reading into it!
Socke has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 248 seconds]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
Foxyloxy has quit [Ping timeout: 260 seconds]
Foxyloxy has joined #rust-embedded
diagprov has joined #rust-embedded
fabic has joined #rust-embedded
<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)
<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
<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)
bjc has quit [Remote host closed the connection]
fabic has quit [Ping timeout: 256 seconds]
<re_irc> <korken89> Yeah I have their stuff a look, but it looks like it's exclusively for C
<re_irc> <korken89> Would be quite nice to have a simple logging aggregator for defmt logs with some metadata
<re_irc> <korken89> I more or less got sentry working though
<re_irc> <korken89> A bit overkill, but hey it works :D
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> hi all, Small question. I'm interested in diving into rust, mainly for on microcontrollers.
<re_irc> What is the most easy-to-use development environment to start out with rust?
<re_irc> My platform is ubuntu (20.04LTS).
<re_irc> I have devices from arduino,STM32F1 and F4, ESP32 and longan-nano (RV32).
<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
<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
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> I have a couple of uno's, some nano, a nano every and a mega (I think)
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> I have a lot of STM32F103's, and also a STM32F4 discovery board
<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
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> * option?
<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
<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:
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> adamgreig: ah .. that is interesting !
<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
<re_irc> <adamgreig> but yea, if you are just getting started the discovery book for the microbit might be a good option
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> looks very interesting .. thanks ...
<re_irc> I'll start with that!
<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
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> thanks
<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 !
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> what's your development enviroment ? linux?
<re_irc> <adamgreig> mine is, yes, though on the whole rust makes it very easy to develop on mac or windows too
<re_irc> <adamgreig> vscode is very popular with the rust-analyzer plugin and works everywhere; I use vim on linux (also with rust-analyzer)
<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 which has a vscode extension, or the "cargo-embed" ( command to load your code onto the microcontroller, or there's also
<re_irc> <adamgreig> (the discovery book covers this too)
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> i'll start with the same setup you have .. just gvim .. I can move to vscode later, if needed
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> just oging over the book now ... interesting ..
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> just wondering .. this is mainly about the peripherals ..
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> how do you talk to somehing like timers and interrupts
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> are the HALs layered?
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> one for arm cortex ...
<re_irc> another one for the chip
<re_irc> and another one for the board (chip + other chips?)
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> ok .. found it .. at "board" level, there is the BSP
<re_irc> <adamgreig> the diagram at the top of this page gives some hints
<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
<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
<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
<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
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> wauw ! Nice!
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> was this all designed like this from the start? When rust was developed?
<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
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> nice :-)
<re_irc> <adamgreig> yea! the success of the shared traits and how well portable drivers actually work is really really nice
<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...
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> ok .. i'll start read and experimenting now .. thank you for your great help
<re_irc> <kristoff šŸ‡§šŸ‡Ŗ šŸ‡ŖšŸ‡ŗ> * reading
Amadiro__ has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 256 seconds]
diagprov has quit [Quit: diagprov]
bjc has joined #rust-embedded
diagprov has joined #rust-embedded
diagprov has quit [Client Quit]
diagprov has joined #rust-embedded
diagprov has quit [Client Quit]
diagprov has joined #rust-embedded