<re_irc>
<yruama_lairba> and i do not really a hal, it's more a close to hardware API that feel nicer than general pac API
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
fabic_ has joined #rust-embedded
<re_irc>
<aholtzma> dirbaio: Note it actually compiles with thumb7. My understanding is thumb6 is Cortex-M0 and thumb7 is Cortex-M3? In any case I have an stm32l0 with Cortex-M0.
<re_irc>
<aholtzma> I guess it just doesn't work on thumb6. Which is really too bad, because it has a tiny amount of memory and I want to see why the stack is blowing up 😆
nort has quit [Quit: I Quit!]
nort has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
emerent is now known as Guest5762
Guest5762 has quit [Ping timeout: 248 seconds]
creich has quit [Quit: Leaving]
fabic_ has quit [Ping timeout: 246 seconds]
fabic_ has joined #rust-embedded
Amadiro__ has joined #rust-embedded
Amadiro_ has quit [Ping timeout: 248 seconds]
fabic_ has quit [Ping timeout: 240 seconds]
fabic_ has joined #rust-embedded
hen6003 has joined #rust-embedded
<re_irc>
<jhbruhn> This might be of interest for people developing embedded-applications which require some way of updating the firmware via something that is not the debug-port (e.g. serial, usb, bluetooth, wifi, nbiot, ...): I have (as part of my master thesis) written a library which abstracts away the painful but reoccuring parts of a firmware updating scheme (partition/bank management, swapping of said banks, communication between...
<re_irc>
... bootloader an firmware, management of linker scripts for bootloader and application) into a common library called _moonboot_ and just open-sourced it: https://crates.io/crates/moonboot
<re_irc>
I plan on improving the documentation with an example project etc, currently it is a bit lackluster, but the gist is: the library provides a framework, while the user still provides their own bootloader/firmware (obviously). The bootloader though only consists of hardware-specific inits and a function call to the bootloader. The library is built with hardware abstractions in mind, although it until now has only been tested and...
<re_irc>
... used for cortex-m processors which have all their memory in a single address space (e.g. stm32 and the likes). If someone is interested and/or has any questions, feel free to ask here or on github!
<re_irc>
<ryan-summers> jhbruhn: Do you have any examples of the crate? Would be useful for potential users to see, at a high level, what the API looks like so they can judge if it's useful :)
fabic_ has quit [Ping timeout: 276 seconds]
<re_irc>
<ryan-summers> Sounds like a cool tool though, and very useful. Writing bootloaders is always a chore
<re_irc>
<jhbruhn> ryan-summers: Not yet, although I absolutely plan on doing that because I know that projects like these can turn out rather complicated.
<re_irc>
On especially important point for me was to centralise the configuration (bank addresses and sizes) into Rust code, from which the bootloader and firmware derive their configuration but also linker scripts can be generated (if desired).
<re_irc>
<ryan-summers> Yeah, I'm curious to see how the synchronization works. I assume you use a build.rs to dynamically generate the linker file?
<re_irc>
<ryan-summers> ah, proce-macro based
<re_irc>
<ryan-summers> * proc-macro
<re_irc>
<jhbruhn> Only build.rs based for now, the proc-macros is only used for one global pre-jump handler declaration for now
<re_irc>
<ryan-summers> Also, have you ever taken a look at https://github.com/AirborneEngineering/blethrs? (Generic ethernet bootloader using smoltcp) - would be interesting to see how that would work with moonboot
<re_irc>
<jhbruhn> Although I would prefer a proc-macro based implementation, but that was not a priority for me yet. One good thing about having this shared, fixed configuration is that the bootloader does not have to resort to magic-values stored as markers for bank-starts, which is done in other (not only rust based) bootloaders
<re_irc>
<jhbruhn> I think I have stumbled upon this. One concept I think have to point out further in the documentation/description of moonboot is that the bootloader is supposed to be for systems which are structured in a 3-bank fashion (bootloader, firmware, update-storage).
<re_irc>
The only(!) task the bootloaders has is to exchange the firmware and update-storage bank, if requested to do so. This means that the old firmware downloads a new image, stores that into update-storage, and tells the bootloader to do the exchange. This scheme has the advantage of sharing the driver/rust-runtime/communication protocols of the firmware with the update process (very useful for over-the-air updates for example, as was...
<re_irc>
... my usecase). The disadvantage is that one has to pay for more flash-space, because the update-bank has to be as large as the firmware-bank.
<re_irc>
<jhbruhn> Another advantage is that the bootloader can revert to the previous firmware if it detects that a boot of the new firmware has failed for whatever reason
<re_irc>
<jhbruhn> ryan-summers: So, an implementation of this bootloader would leave all network communications in the application-specific firmware, also implementing the firmware-update-acquirement there (which could repurpose the protocols of the applicaiton if desired). Then it would hand over to the moonbootloader and apply the update
<re_irc>
<ryan-summers> The update storage need not be always in flash. I'm currently working on a product for a customer where the staged image has to be kept in EEPROM, since we don't have nearly enough flash otherwise
<re_irc>
<ryan-summers> I could imagine using traits and such you could abstract away the concept of "where" the staged image is at
<re_irc>
<ryan-summers> But in general, I would also argue that the actual "application" should never even have the capability to modify flash, since that introduces a big security hole imo
<re_irc>
<ryan-summers> At least from the concept of safety critical devices
<re_irc>
<jhbruhn> ryan-summers: Correct, I had that in mind while designing this library, although some modifications would still have to be made to allow storage in different mediums.
<re_irc>
<ryan-summers> But it is definitely interesting to see the generic ops of the bootloader abstracted away - they are quite generic
<re_irc>
<jhbruhn> ryan-summers: Alternatively, if available, an MPU could take care of "locking" the firmware region to be writable from the bootloader only. I tried to do that once for cortex-m but failed due to time and lack of knowledge about the MPU
<re_irc>
<ryan-summers> Also +1 on using the apps communication protocol. The downside of this architecture though is that if the app ever is non-functional, your device is also bricked
<re_irc>
<ryan-summers> E.g. if you have a bad release
<re_irc>
<jhbruhn> Yep, another improvement would be to introduce a minimal update channel in the bootloader. But that is application-specific again (UART? ETH?)
<re_irc>
<ryan-summers> Yeah, it gets a lot worse when you have custom, radio-based protocols. Code starts getting duplicated
<re_irc>
<jhbruhn> Although, as long as the broken firmware does not boot at all and results in the bootloader being executed again (via a hardfault handler for example), or the broken firmware is working okay-enough to detect it's state of brokenness, the firmware can relate to a previous working version which is still stored in the update-bank (or in a 4th golden-image bank, if one implements such logic)
<re_irc>
<jhbruhn> ryan-summers: Which was the reasoning of putting the update-acquirement into the firmware itself. This library was "in accordance to" the SUIT reference which was recently published by the IETF. quotation marks because there is not much explicitly specified about the bootloader to be flexible
<re_irc>
<jhbruhn> Which was the reasoning of putting the update-acquirement into the firmware itself. This library was developed "in accordance to" the SUIT reference which was recently published by the IETF. quotation marks because there is not much explicitly specified about the bootloader to be flexible. Such over-the-air updates have a lot of specific code (signature /checksum checking, protocols, serialization/deserialization,...
<re_irc>
... wireless drivers, ...)
<re_irc>
<Chris [pwnOrbitals]> Could anyone point me to a simple method to serialize/deserialize long byte arrays using Serde ? const generics support isn’t here as far as I can tell, and crates like serde_with aren’t no_std compatible...
<re_irc>
<yruama_lairba> is there a hal using the regular builder pattern ?
<re_irc>
<yruama_lairba> i'm mean, hal having a separate type for the setup and the hal
<re_irc>
<yruama_lairba> because, in a certain point of view GPIO Pin hal use the builder pattern but the builder and the builded is the same type
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<Lachlan> Can SWD/probe-rs do bidirectional comms?
<re_irc>
<korken89> Lachlan: Yes
<re_irc>
<korken89> "rtt_target" together with "cargo embed" supports that
<re_irc>
<korken89> (up/down channels)
<re_irc>
<Lachlan> Ah sweet
<re_irc>
<Lachlan> I may have to use that
<re_irc>
<Lachlan> The bus I was going to use isn’t working
<re_irc>
<Lachlan> Might have to communicate over swd from the raspi that’s in the loop
<re_irc>
<riskable> Does anyone have any experience with "hidapi"? I want to make my firmware work with OpenRGB and the PC side of things seems pretty straightforward ("it just uses hidapi") but WTF do you implement in the firmware to "talk" to hidapi? Anyone have any examples? I mean, I know how to setup a USB device with a specific serial number and version string (that "hidapi" knows how to read) but beyond that... What do you do?
<re_irc>
<riskable> burrbull: What does "probe-rs" have to do with talking back and forth with "hidapi"? That's all SWD stuff, right?
<re_irc>
<riskable> Like, a debugging probe will connect directly to debug pins and won't be talking over USB Human Interface Device _<stuff>_
<re_irc>
<Lachlan> They probably meant to reply to me
<re_irc>
<yruama_lairba> hi, i have extrem difficulty to find in pac documentation what is the reader type of a registers
<re_irc>
<Chris [pwnOrbitals]> is anyone aware of a way to erase/rewrite a flash sector on stm32 from the board itself ? I’d like to store some config data there so to overwrite it I’d need to erase the sector but I believe it’s not trivial (cf probe-rs code) so maybe a crate has this implemented already ?
<re_irc>
<Chris [pwnOrbitals]> +(onboard)
<re_irc>
<yruama_lairba> i generally ending using "let () = my_register.read()" to get that, but some i get some stuffprefixed with "_" indicating private stuff
<re_irc>
<yruama_lairba> anyway there is an application notice somewhere for eeprom emulation on stm32
<re_irc>
<yruama_lairba> i read it once, but this look tricky to implment
<re_irc>
<Chris [pwnOrbitals]> yruama_lairba: Well that’s weird, it seems to need stdlib and doesn’t provide the interface to the flash, only an API (read / write / page_erase) that I’d need to write myself... which is back to square 1
<re_irc>
This way, you "only" have to implement the logic for reading/writing/erasing of pages. The handling of which page has to get erased etc is done by these implementations
<re_irc>
<dirbaio> you want the FLASH peripheral
<re_irc>
<dirbaio> some stm32 hals have impls for it
<re_irc>
<dirbaio> some impl the embedded-storage traits, some don't
<re_irc>
<dirbaio> if your HAL doesn't have it, you'll have to impl it yourself
<re_irc>
<Chris [pwnOrbitals]> ok got it ! thanks ! also embedded-storage looks great too, thanks for the link
<re_irc>
<dirbaio> which stm32 chip?
<re_irc>
<Chris [pwnOrbitals]> stm32f746
<re_irc>
<Chris [pwnOrbitals]> looks like the HAL actually provides the flash erase
<re_irc>
<yruama_lairba> i there a way to get a modifiable copy of register content ?
<re_irc>
<burrbull> .modify(|r, w| ...) where r is current state of register, w is writer
<re_irc>
<yruama_lairba> i'm mean i'd like to have a config object that manipulate that work on register copy, and then put that copy on the peripheral register
<re_irc>
<dirbaio> not possible with svd2rust pacs
<re_irc>
<yruama_lairba> ok, so i just need to use another internal representation
<re_irc>
<dirbaio> with stm32-metapac you can do it
<re_irc>
x.set_wren(true); // you can modiy fields
<re_irc>
let mut x = flash.cr().read(); // x stores the register value as u32
<re_irc>
flash.cr().write_value(x); // you can write it back to the reg
<re_irc>
<dirbaio> is that what you meant?
<re_irc>
<yruama_lairba> yes
fabic_ has joined #rust-embedded
<re_irc>
<yruama_lairba> exept i don't need to read the register content, i just wanted to have an internal representation close to the device
<re_irc>
<dirbaio> like, create the value yourself?
<re_irc>
<dirbaio> like this?
<re_irc>
<dirbaio> let mut x = pac::flash::regs::Cr(0); // create it from a u32
<re_irc>
x.set_wren(true); // you can modiy fields
<re_irc>
flash.cr().write_value(x); // you can write it back to the reg
<re_irc>
<yruama_lairba> almost, i wanted to have the default register value
<re_irc>
<adamgreig> hi room, meeting time again! agenda is https://hackmd.io/plAb8xtxS_mtWc_eukW57A, please add anything you'd like to discuss or announce and we'll start in ~5min :)
<re_irc>
<James Munns> Oh, btw I had a chat with Jane Lusby from the libs team, to talk about error handling in embedded rust. She might drop by to say hi and to schedule a chat, especially with HAL team members
<re_irc>
<James Munns> (we talked about embedded Hal a lot)
<re_irc>
<adamgreig> cool!
<re_irc>
<caspinol> dirbaio: Hmm, so i am doing that and yet compiler tells me the Transfer trait is not implemented for the SPI instance. I'll see if i'm maybe doing soemething else wrong
<re_irc>
<adamgreig> std::error in core when lol
<re_irc>
<dirbaio> std::error is actually quite bloated, I don't think using it for embedded would be a good thing
<re_irc>
<newam> adamgreig: I saw mention of this, what does that actually get us though?
<re_irc>
<James Munns> That's actually part of what we talked about!
<re_irc>
<James Munns> Both the core and the bloat part
<re_irc>
<James Munns> My opinion was there was more demand for core::io traits than core::error, because we usually don't do the "chain and report" sorry of workflow
<re_irc>
<James Munns> (but don't let me detail the meeting, i mostly just gave her some background and context)
<re_irc>
<dirbaio> oh yeah core::io would be nice, same for async...
<re_irc>
<James Munns> My opinion was there was more demand for core::io traits than core::error, because we usually don't do the "chain and report" sort of workflow
<re_irc>
<burrbull> caspinol: different alpha versions are incompatible. Maybe this is problem
<re_irc>
<adamgreig> ok, i've found some leftover easter chocolate, let's start 🥚
<re_irc>
<adamgreig> first up, embedded-hal 1.0.0-alpha.8 was released! ever closer to the full 1.0.0, thanks eldruin for sorting it out
<re_irc>
<adamgreig> I didn't have any other announcements from the week, dirbaio do you want to mention your shiny new website or maybe some other time?
<re_irc>
<dirbaio> Sure! Yesterday we launched the new Embassy website https://embassy.dev/
<re_irc>
<Forest Anderson> (Sorry, is the meeting happening here in chat? First time here :) )
<re_irc>
<adamgreig> this includes the very new and cool SPI traits which should help sharing one SPI bus between lots of drivers, too
<re_irc>
<adamgreig> Forest Anderson: yep, it's just in chat here, hi!
<re_irc>
<dirbaio> I hope it does a better job at outlining the project's vision clearly: a "batteries-included" framework for productive Rust embedded development. Kinda what you'd expect from a C RTOS, including ergonomics and concurrency (except it's not really a RTOS. Async is much lighter there's no "kernel")
<re_irc>
<dirbaio> * lighter,
<re_irc>
<dirbaio> also crates.io release coming, the only missing bit is embedded-hal-async release :)
<re_irc>
<James Munns> Oh if we're doing announcements, I also wrote a post on the first version of my general purpose homebrew PC OS, MnemOS: https://jamesmunns.com/blog/mnemos-initial-release/ (there is a kernel)
<re_irc>
<James Munns> (less exciting than embassy ATM, tho)
<re_irc>
<adamgreig> the new embassy website looks really good :D
<re_irc>
<adamgreig> ok, moving on to briefly mention that I still hope to get a new cortex-m-rt release out soonish, but moving house is still kicking my arse like a month later, so Hopefully Soon ™️
<re_irc>
<adamgreig> if anyone has a cortex-m7 handy they could test on too that would be neat
<re_irc>
<adamgreig> basically the original version of asm::delay ran about 4 instructions per loop, so it divided the number of cycles by 4 and did that many iterations
<re_irc>
<James Munns> Oh, i should be able to test that on a same70
<re_irc>
<adamgreig> some time later it became apparent cortex-m7 would dual issue and run twice as fast, so we doubled the number of loop iterations on cortex-m 0.7, which meant everyone on a cortex-m0/m3/m4 suddenly had twice as long a delay, but that was "OK" according to our docs
<re_irc>
<adamgreig> but it seems like perhaps now actually the cortex-m7 is _still_ twice as fast (perhaps it was 4x at first?) and is only delaying half the number of CPU cycles requested
<re_irc>
<adamgreig> it's not clear we can really solve this well in general, it's always meant to be a very crude delay; it might be we just leave the behaviour as-is but document that on some CPUs it might not even delay for as many cycles as you asked for
<re_irc>
<dirbaio> doesn't the speed also depend on whether you're running from ram or flash, whether you've enabled flash cache/accelerator...?
<re_irc>
<adamgreig> or perhaps there's some asm wizardry possible that the cm7 can't dual issue and will slow it down to the same IPC as a cortex-m0
<re_irc>
<adamgreig> yes, outside of the CPU itself any flash wait states without a flash cache of some kind will potentially slow it down a bunch
<re_irc>
<adamgreig> the docs already said it may take _longer_ (e.g. an interrupt might happen or you have flash wait states etc)
<re_irc>
<adamgreig> but it's sort of a bug that it's quicker
<re_irc>
<GrantM11235> I think it would be better to deprecate it in favor of a delay routine that doesn't make any promises about how many cycles it takes
<re_irc>
<adamgreig> I think in most implementations you end up with no wait states for a couple of instruction hot loop, most things have enough flash cache to handle that?
<re_irc>
<adamgreig> why deprecate it?
<re_irc>
<dirbaio> I think people use "asm::delay()" because it's easy to use, no need for an owned CYCCNT thing you have to pass around
<re_irc>
<adamgreig> especially if the new routine has the same implementation, I'd rather just update the docs
<re_irc>
<adamgreig> yea
<re_irc>
<adamgreig> and for many of those use cases it's "good enough"?
<re_irc>
<James Munns> I can at least test it at zero wait states (12mhz) and six wait states (300mhz), and reference it against the 32khz clock
<re_irc>
<GrantM11235> I think it is better for the user to figure out how many delay loops they need
<re_irc>
<dirbaio> so maybe we could have a better (not using asm loops) AND easy-to-use delay thingy (doesn't require owned singletons)?
<re_irc>
<adamgreig> if we were arduino and had millis() that returned ms since boot and you could delay_ms() globally anywhere, yea...
<re_irc>
<James Munns> (asm delay was very handy for me when bringing up the atsame70)
<re_irc>
<adamgreig> though I guess sometimes you do want the very fine control that asm::delay gives
<re_irc>
<adamgreig> but: this is cortex-m land, we don't have much to use except counting cycles, really
<re_irc>
<newam> dirbaio: CYCCNT doesn't require ownership to get the count, only to set it up.
<re_irc>
<adamgreig> DWT/CYCCNT is optional and not on cm0, SYSTICK is kinda funky and applications probably want it (anyway we already provide an e-h Delay impl for Systick right)
<re_irc>
<adamgreig> so I think this sort of very basic "delay a few loop iterations" is worth having, even if a chip specific HAL might provide an easier to use alternative
<re_irc>
<dirbaio> so maybe "give up" instead
<re_irc>
<dirbaio> and document it as "this does N loops of <asm blob>"
<re_irc>
<adamgreig> yea
<re_irc>
<GrantM11235> adamgreig: "delay a few loop iterations" is useful, "try to delay a certain number of clock cycles, but it is always wrong" isn't as useful
<re_irc>
<adamgreig> you could bravely say it retires N instructions
<re_irc>
<GrantM11235> dirbaio: exactly
<re_irc>
<adamgreig> the loop is just "1: subs r0, #1; bne 1b"
<re_irc>
<dirbaio> maybe also a table of "M0-M4 is 4 cycles/loop, M7 is 2, etc" with a warning
<re_irc>
<adamgreig> yea
<re_irc>
<dirbaio> +of "might depend on actual chip and flash waitstates etc, be sure to measure if you care about exact delay"
<re_irc>
<GrantM11235> Oh, and maybe it should take a "NonZeroU32"
<re_irc>
<adamgreig> at the moment it delays for 1+cycles/2 iterations, where cycles is the input argument
<re_irc>
<adamgreig> so in practice it retires cycles+2 instructions
<re_irc>
<dirbaio> "NonZeroU32" would be annyoing if the delay amount is the output of some math that could yield 0
<re_irc>
<adamgreig> well, plus some more for function entry/exit, plus some for computing that number and loading it into the register
<re_irc>
<adamgreig> so the +2 for rounding up the input is lost in that constant factor anyway
<re_irc>
<GrantM11235> dirbaio: you need it to be nonzero if your loop is "sub, bnz"
<re_irc>
<dirbaio> so it currently hangs if it's zero? 😂
<re_irc>
<GrantM11235> No, it adds one to the count
<re_irc>
<dirbaio> dunno, you probably can write the loop in a way that works with 0
<re_irc>
<adamgreig> which won't overflow either :P
<re_irc>
<adamgreig> maybe, but I'm inclined to not change the current behaviour, and just better document what it will do?
<re_irc>
<adamgreig> lots of people presumably have now calibrated it for their application
<re_irc>
<adamgreig> (and there's no pressing need to change it, I think?)
<re_irc>
<adamgreig> if it was like, we can change it to something that's always exactly this number of clock cycles on all CPUs, maybe that would be compelling enough to make a behavioural change
<re_irc>
<GrantM11235> I would vote to keep it the same but deprecate it (once we have a better option)
<re_irc>
<adamgreig> I can't really imagine what a better option would be, but sure, if we do invent some much better thing we could deprecate (or just replace the current implementation with it, to avoid burning the name)
<re_irc>
<adamgreig> OK, that's probably enough on this one for now, thanks everyone! if anyone would like to have a crack at updating the docs and opening a PR please go ahead (or ask here later if you want to discuss it more), otherwise someone on cortex-m will get to it sooner or later :p
<re_irc>
<GrantM11235> adamgreig: I think that a raw "sub, bnz" loop is better
<re_irc>
<adamgreig> what do you mean "raw"?
<re_irc>
<adamgreig> like, without the 1+c/2?
<re_irc>
<adamgreig> you just specify number of iterations and it must be non-zero?
<re_irc>
<GrantM11235> adamgreig: exactly
<re_irc>
<adamgreig> what's the advantage?
<re_irc>
<GrantM11235> It is very basic and doesn't try to make promises it can't keep
<re_irc>
<GrantM11235> And if you are hand-calibrating a delay loop value, you don't need to worry that it will change on you later
<re_irc>
<adamgreig> fair
<re_irc>
<adamgreig> I guess I feel like what we have now is so functionally similar that it doesn't make sense to go through deprecating and making a new thing with a different name, though
<re_irc>
<adamgreig> anyway, I guess that's a discussion for another time, I think it's clear what to do about it atm
<re_irc>
<adamgreig> ..which it looks like will be merged and released any second now :D
<re_irc>
<eldruin> yep, I'm on it
<re_irc>
<adamgreig> any other e-h stuff to talk about, eldruintherealprof?
<re_irc>
<adamgreig> * eldruin / therealprof?
<re_irc>
<therealprof> Not from me.
<re_irc>
<eldruin> not at the moment, just looking forward to feedback about the new SPI traits
neceve has joined #rust-embedded
<re_irc>
<adamgreig> 👍️ great
<re_irc>
<adamgreig> Forest Anderson, did you want to talk about the CTCFT theme?
<re_irc>
<Forest Anderson> Hey! So I just want to bring up the Rust Cross-Team Collaboration Fun Times meetup. The CTCFT is a place to give talks directed to Rust team members, you can learn more here: https://rust-lang.github.io/ctcft/
<re_irc>
A suggested theme for May was "Embedded Rust", and I wanted to see if there was interest here to talk about some of the pain points/areas for improvement that Rust Embedded is looking for in the language. We already have a bit of an idea of what we want to explore:
<re_irc>
- Explain embedded to people in the Rust project so we understand better what embedded means
<re_irc>
<Forest Anderson> Also, to mention, we haven't settled on the Embedded theme for May yet, but if there are more topics proposed once we meet to decide on the theme, I imagine it will help make the choice :)
<re_irc>
<James Munns> Always happy to give a "what does embedded rust look like" overview, i think I mentioned that in another issue, since I've given that talk a lot
<re_irc>
<James Munns> But also happy to not, if anyone else feels inspired :)
<re_irc>
<Forest Anderson> James Munns: Yes, I think something like this would work quite nice :)
<re_irc>
<Forest Anderson> I think it would be cool to have a few topics. Maybe a survey of the ecosystem in one, and a list of pain points in another. We don't like splitting up talks too much with too many speakers, but I think those would be two good separations of talks
<re_irc>
<James Munns> Wrt issue 28, I do think the Ferrous Systems folks are most relevant for that (skade is already on that thread)
<re_irc>
<dirbaio> happy to present as well, about Rust async+embedded and the work we've been doing in Embassy.
<re_irc>
<eldruin> PSA the first embedded-hal-async alpha release is out! Special thanks to dirbaio for driving this and also everyone else involved! https://crates.io/crates/embedded-hal-async
<re_irc>
<dirbaio> Rust async is quite unique in that it can run with no runtime, no OS, no alloc, and still allow you to write concurrent code
<re_irc>
<dirbaio> async is THE reason I've switched from C to Rust :)
<re_irc>
<James Munns> eldruin: Thanks for getting that out eldruin !
<re_irc>
<Forest Anderson> I think a good course of action is I'll create a topic proposal for James Munns to give an overview of the ecosystem and considerations/constraints. Then maybe another topic could be suggested along the lines of async work being done? I know that's a hot topic within the Rust teams as well, since the async WG is making big moves right now.
<re_irc>
<James Munns> dirbaio: Plus no split stacks, which is still like the #1 issue i see in freertos projects :p
<re_irc>
<James Munns> dirbaio would definitely be much better for the async talk :D
<re_irc>
<adamgreig> yea, for two topics it sounds like James Munns doing an ecosystem overview and dirbaio talking about async/embassy would be a nice combo
<re_irc>
<adamgreig> good chance to pester people about !Leak too, heh
<re_irc>
<James Munns> I'm bad at complaining, so if anyone wants to remind me about stuff that sucks (or is perceived to suck), let me know so i can complain righteously.
<re_irc>
<dirbaio> Forest Anderson: will do!
<re_irc>
<James Munns> Will do!
<re_irc>
<adamgreig> thanks James Munns dirbaio :D
<re_irc>
<adamgreig> anyone have anything else to discuss today?
<re_irc>
<W.C. Pannell> Vaguely related to the WG: Embedded Online Conference is next week and someone is doing a talk on embedded Rust. There may be a small bump in new folks following
<re_irc>
<adamgreig> cool! got a link or anything?
<re_irc>
<James Munns> (porting mnemos to the 52840-dk a lot of people have)
<re_irc>
<James Munns> Similarly, if anyone is super knowledgeable about QEMU or other tools like Renode, I'd love help porting the kernel there too :p
<re_irc>
<James Munns> Or really any other cortex M4/M7 of your choice, tho that will require fleshing out a few more compat interfaces that don't totally exist yet
<re_irc>
<James Munns> But regardless, happy to mentor anyone interested in any part or port. I'm gonna go write sound card drivers :p
<cr1901>
agg: I promise I was reading :P. I was reading the backlog on phone
<re_irc>
<dirbaio> anyone here familiar with the iso14443a rfid protocol?
<re_irc>
<James Munns> oh no, not again
<re_irc>
<dirbaio> probably not, but gonna ask just in case: when doing collision resolution (multiple cards in the field), how do you learn the ATQA values of each individual card? Sending REQA/WUPA yields the bitwise OR of all the ATQAs, and doing it after selecting one card doesn't help, because it wakes up all cards again
<re_irc>
<James Munns> godspeed you, RFID warrior
nort has joined #rust-embedded
neceve has quit [Ping timeout: 276 seconds]
<re_irc>
<Lachlan Sneff> So, it seems like the CAN controller on the stm32f1 isn’t sending data at the bitrate the CAN_BTR says it should be
<re_irc>
<Lachlan Sneff> It’s sending data at around 300 kHz, but it’s supposed to be 500
<re_irc>
<Lachlan Sneff> I have another device on the bus sending data at 500 correctly
<re_irc>
<Lachlan Sneff> ^ from looking at the oscilloscope
gsalazar has quit [Ping timeout: 272 seconds]
<re_irc>
<adamgreig> Could it be an stm32 clocking issue, like expecting a 12MHz HSE but using 8MHz HSI or whatever?
<re_irc>
<adamgreig> It's a shame can isn't somehow self clocking or only had one baud rate or something, it's like the one configurable feature of the line protocol
<re_irc>
<Lachlan Sneff> Yeah, hmm
<re_irc>
<Lachlan Sneff> Could I see by hooking the oscilloscope up the external crystal?
<re_irc>
<Lachlan Sneff> And the pclk1 is the correct clock to use when calculating CAN_BTR?
<re_irc>
<Lachlan Sneff> The crystal is at least labeled 36 MHz
<re_irc>
<Lachlan Sneff> And that’s what I have in software
<re_irc>
<James Munns> Not generally, unless you have a very high impedance probe
<re_irc>
<James Munns> The capacitance/resistance of the probe will effect it
<re_irc>
<James Munns> But if it says 36, youre probably fine
<re_irc>
<dirbaio> get a timer to print something every second, check it's indeed every second
<re_irc>
<adamgreig> You can use the stm32 MCO to output the sysclk and check on scope
<re_irc>
<adamgreig> Lachlan Sneff: Is that in spec? I thought a lot of F1 was at most 16MHz HSE xtal
<re_irc>
<James Munns> Lachlan Sneff: Have you played with stm32cubemx?
<re_irc>
<adamgreig> 1-25MHz if you feed a clock signal, 4-16MHz if using a crystal, for stm32f103 anyway, I guess this must be 105 or 107 for can
<re_irc>
<Lachlan Sneff> Oh very interesting
<re_irc>
<Lachlan Sneff> Let me check the datasheet
<re_irc>
<Lachlan Sneff> That would be easy to fix
<re_irc>
<burrbull> Need to add assert on input values
<re_irc>
<Lachlan Sneff> The datasheet says the hse can go up to 50 MHz
<re_irc>
<James Munns> What stm32 part?
<re_irc>
<Lachlan Sneff> What’s interesting, is the can bus frequency on the ‘scope is a little more than a half the frequency I’m setting, even when configuring different baud rates
<re_irc>
<Lachlan Sneff> It’s an stm32f105VB
<re_irc>
<burrbull> Lachlan Sneff: Hse 3-25 Mhz for 105/107
<re_irc>
<James Munns> yeah
<re_irc>
<adamgreig> Yea, 1-50MHz if you feed a clock signal, 3-25MHz if you use a crystal
<re_irc>
<Lachlan Sneff> Ahhh
<re_irc>
<James Munns> just loaded stm32cube
<re_irc>
<adamgreig> This might not be your actual problem but it's probably worth fixing anyway before chasing ghosts
<re_irc>
<Lachlan Sneff> Would the internal oscillator be good enough?
<re_irc>
<James Munns> yeah
<re_irc>
<Lachlan Sneff> I’ve heard it’s not repeatable enough for can
<re_irc>
<James Munns> oh
<re_irc>
<adamgreig> Good enough to check your clock is about right on a scope, not great for actually talking can
<re_irc>
<Lachlan Sneff> I’ll try it
<re_irc>
<adamgreig> It's about 2% accurate
<re_irc>
<kevlan> It's probably enough to get something working on the bench, just may not work reliably across temperatures. CAN can afford a decent amount of clock drift between nodes depending on how the timing bits are setup.
<re_irc>
<adamgreig> AN1798 tells you how to work out clock accuracy requirements for CAN, it depends on bit rate and bus length and stuff but 0.5 to 1.5% isn't uncommon, so 2% on hsi isn't great but should work on the bench yea
<re_irc>
<Lachlan Sneff> The can frequency seems to be the same with the internal oscillator
<re_irc>
<Lachlan Sneff> Yeah, I really should’ve used it, sorry
<re_irc>
<James Munns> it has a visual gui tool for all these calcs
<re_irc>
<Lachlan Sneff> I have it on my laptop, I just hate the ui
<re_irc>
<James Munns> fair, its pretty bad lol
<re_irc>
<Lachlan Sneff> But I’ll look it at when I get back to my computer
<re_irc>
<adamgreig> if you also dislike cubemx, you can work through the calculations by hand following the reference manual
<re_irc>
<James Munns> but at this, and pin mapping, its golden
<re_irc>
<adamgreig> (this is usually my approach for chips i already know well)
<re_irc>
<adamgreig> (because i already know most of the surprises to look out for in those chips...)
<re_irc>
<Lachlan Sneff> Yeah, that makes sense
<re_irc>
<Lachlan Sneff> Thank you for all the advice everyone!
<re_irc>
<Lachlan Sneff> I suspect it’s rounding down to 9 MHz
<re_irc>
<James Munns> I hope this was the problem!
<re_irc>
<adamgreig> yea, seems plausible
<re_irc>
<dirbaio> if the hal is rounding, why doesn't it configure the CAN baudrate based on the rounded freq?
<re_irc>
<James Munns> also any reason you limit sysclk to 36mhz?
<re_irc>
<Lachlan Sneff> Cause the can baud rate is set with a raw register value
<re_irc>
<Lachlan Sneff> Yeah, I believe I remember the Hal not being able to find a configuration that worked with a higher frequency
<re_irc>
<burrbull> Can baudrate depends on pclk, not sysclk
<re_irc>
<Lachlan Sneff> But that was a while ago, may be remembering incorrectly
<re_irc>
<adamgreig> CAN baudrate config is complicated, there's a divider to get the length of each time slice and then separately you set how many such slices in each segment, depending on Things
<re_irc>
<dirbaio> Lachlan Sneff: ohh ugh :D
<re_irc>
<James Munns> ohhh, you cant crank the internal osc over 9x
<re_irc>
<Lachlan Sneff> adamgreig: Yeah, I calculated it by hand to check if the calculator site was right. It’s pretty complex
<re_irc>
<James Munns> and it has a div2
<re_irc>
<James Munns> so 36m is max with internal osc
<re_irc>
<burrbull> 8*9=72
<re_irc>
<Lachlan Sneff> burrbull: I’ll check this tomorrow and will let y’all know! I bet it’s this though, thanks!
<re_irc>
<James Munns> thers a div2
<re_irc>
<James Munns> so its 4 * 9
<re_irc>
<burrbull> Anyway f1xx-hal supports alternative way to pass rcc Config with fixed prescalers