<re_irc> <@jamesmunns:beeper.com> ryankurte I haven't used RTIC 0.6, but that sounds a lot like what happened to me when I had my monotonic fraction inversed
<re_irc> <@jamesmunns:beeper.com> (in 0.5)
<re_irc> <@jamesmunns:beeper.com> Like for a 64 MHz core clock and a 1mhz timer: https://github.com/anachro-rs/anachro/blob/main/crates/groundhog-nrf52/src/lib.rs#L71
<re_irc> <@ryankurte:matrix.org> huh, that monotonic impl looks very different to the one in 0.6
<re_irc> <@ryankurte:matrix.org> worth checking but, i think if the scaling factor was incorrect the mapping from 1s to 1024 ticks would also be?
<re_irc> <@jamesmunns:beeper.com> I'm not sure :/ haven't looked at embedded-time or RTIC 6
fabic_ has joined #rust-embedded
<re_irc> <@sajattack:matrix.org> ryankurte:matrix.org: #atsamd-rs_community:gitter.im
fabic_ has quit [Ping timeout: 250 seconds]
<re_irc> <@thalesfragoso:matrix.org> Given that problem of a mutable reference (or also move ?) invalidating raw pointers.
<re_irc> <@thalesfragoso:matrix.org> Hmm, I'm questioning the soundness of the embedded-dma crate again...
<re_irc> <@thalesfragoso:matrix.org> If we move or create a mut ref to the wrapper type (like the Transfer type), wouldn't we be transitively doing the same to the buffer type which would invalidate the raw ptr that the DMA is using ? I think this is worse if the buffer type is something like `Box<T>`, but not sure if `&'a mut [u8; N]` doesn't have the same problem, i.e. does creating a &mut to a `&mut [u8; N]` invalidates the raw ptr...
<re_irc> ... reborrow ?
<re_irc> <@thalesfragoso:matrix.org> See also: https://github.com/rust-lang/unsafe-code-guidelines/issues/194
<re_irc> <@thalesfragoso:matrix.org> dirbaio help .-.
<re_irc> <@thalesfragoso:matrix.org> It could also apply to embassy's DMA futures that aren't !Unpin
PyroPeter has quit [Ping timeout: 268 seconds]
PyroPeter has joined #rust-embedded
cr1901 has quit [Ping timeout: 260 seconds]
cr1901 has joined #rust-embedded
starblue1 has quit [*.net *.split]
vancz has quit [*.net *.split]
starblue1 has joined #rust-embedded
vancz has joined #rust-embedded
unmanbearpig has joined #rust-embedded
fabic_ has joined #rust-embedded
<re_irc> <@thejpster:matrix.org> Question - how can I write a memory.x that lets me put a function after the vector table but before the reset function?
<re_irc> <@thejpster:matrix.org> It seems link.x really tightly ties the start of .text to the end of .vector_table
<re_irc> <@thejpster:matrix.org> .vector_table ORIGIN(FLASH) :
<re_irc> <@thejpster:matrix.org> {
<re_irc> <@thejpster:matrix.org> LONG(_stack_start);
<re_irc> <@thejpster:matrix.org> /* Initial Stack Pointer (SP) value */
<re_irc> <@thejpster:matrix.org> In this case it's metadata discovered by Raspberry Pi's picotool
<re_irc> <@thejpster:matrix.org> You can't INSERT BEFORE .text...
<re_irc> <@thejpster:matrix.org> SECTIONS {
<re_irc> <@thejpster:matrix.org> /* ### Picotool Info Block
<re_irc> <@thejpster:matrix.org> * Picotool only searches the second 256 bytes of Flash for this block, but that's where our vector table is.
<re_irc> <@thejpster:matrix.org> *
<re_irc> <@adamgreig:matrix.org> ah, yea, that's annoying
<re_irc> <@adamgreig:matrix.org> picotool searches 256 bytes starting at the vector table? do their C binaries not also put the vector table there?
<re_irc> <@thejpster:matrix.org> Yes, but the vector table isn't 256 bytes long
<re_irc> <@thejpster:matrix.org> It's an M0, so it's *checks notes*
<re_irc> <@adamgreig:matrix.org> 256b is only 32 vectors
<re_irc> <@thejpster:matrix.org> 0xA8
<re_irc> <@thejpster:matrix.org> 64 vectors
<re_irc> <@thejpster:matrix.org> They're four bytes each
<re_irc> <@adamgreig:matrix.org> oh, yea, my bad
<re_irc> <@thejpster:matrix.org> 0xA8 is 42 vectors
<re_irc> <@adamgreig:matrix.org> and cm0 is at most 32 interrupts plus a few exceptions and sp/rst
<re_irc> <@adamgreig:matrix.org> got it
<re_irc> <@thejpster:matrix.org> And yes, we can get picotool to scan slightly more flash if that's usful
<re_irc> <@thejpster:matrix.org> But it's suboptimal to have to scan the entire image, and more likely to hit a false positive on the magic block
<re_irc> <@adamgreig:matrix.org> I don't think it's unreasonable per se for c-m-rt to currently put .text after .vector_table, but it doesn't seem like there's any good way to stick more metadata in-between
<re_irc> <@adamgreig:matrix.org> best we could do is probably stick a new custom section into link.x for this sort of thing, but you wouldn't be able to use it without a new c-m-rt release
<re_irc> <@thejpster:matrix.org> If you removed the _stext constraint, .text would just float next to .vector_table wouldn't it?
<re_irc> <@adamgreig:matrix.org> (which can happen quickly, that's not a problem as such)
<re_irc> <@adamgreig:matrix.org> _stext is needed for r0 though
<re_irc> <@thejpster:matrix.org> But you have __stext which is defined inside .text
<re_irc> <@adamgreig:matrix.org> uh
<re_irc> <@adamgreig:matrix.org> actually sdata is what's needed for r0
<re_irc> <@thejpster:matrix.org> _stext is specifically to set the start address of _text, and is calculated as `PROVIDE(_stext = ADDR(.vector_table) + SIZEOF(.vector_table));`
<re_irc> <@thejpster:matrix.org> You don't, for example, force .rodata to start at ADDR(.text) + SIZEOF(.text)
<re_irc> <@adamgreig:matrix.org> ah, right, I recall now
<re_irc> <@adamgreig:matrix.org> that seems to do it
<re_irc> <@adamgreig:matrix.org> _stext = ORIGIN(FLASH) + 0x200;
<re_irc> <@adamgreig:matrix.org> .prereset : ALIGN(4) {
<re_irc> <@adamgreig:matrix.org> SECTIONS {
<re_irc> <@adamgreig:matrix.org> e.g. ```
<re_irc> <@adamgreig:matrix.org> something along those lines seems to work in a quick test, obviously put something better than +0x200 for stext
<re_irc> <@thejpster:matrix.org> Can you override _stext if it's already been set?
<cr1901> I think that's what PROVIDE does
<re_irc> <@adamgreig:matrix.org> been set where? you can override link.x with memory.x, yes, that's what it's there for (see docs.rs link ^)
<cr1901> if you haven't overridden the symbol, you get a default
<cr1901> otherwise use the value you set
<re_irc> <@thejpster:matrix.org> link.x contains `PROVIDE(_stext = ADDR(.vector_table) + SIZEOF(.vector_table));`
<re_irc> <@thejpster:matrix.org> Ah, I see
<cr1901> PROVIDE means "please provide this symbol to get the linker to stop bitching if it doesn't exist yet. Otherwise do nothing."
<re_irc> <@thejpster:matrix.org> s/yet/elsewhere in this file/
<re_irc> <@thejpster:matrix.org> Ah, no
<re_irc> <@thejpster:matrix.org> my bad
<re_irc> <@thejpster:matrix.org> we INCLUDE before we PROVIDE
<re_irc> <@thejpster:matrix.org> Sweet, thanks. This works.
<re_irc> <@adamgreig:matrix.org> 👍️
<re_irc> <@adamgreig:matrix.org> putting metadata after vector table is exactly what this was designed for, heh
<re_irc> <@thejpster:matrix.org> OK, one more quick question. Can build.rs tell it's building an example?
<re_irc> <@thejpster:matrix.org> My HAL build.rs is copying in a memory.x file, but only so the examples will build.
<re_irc> <@thejpster:matrix.org> But as pointed out by adamgreig , you don't want two memory.x files in your linker path (and I have one in the BSP which actually suits the board you're building for).
<re_irc> <@adamgreig:matrix.org> I have to run but https://doc.rust-lang.org/cargo/reference/environment-variables.html might have a clue
<cr1901> I would not be surprised if this is a wart of cargo due to its focus on building hosted applications... maybe open an issue on cargo repo :/?
<re_irc> <@thejpster:matrix.org> OK, thanks. I'll look into it.
<re_irc> <@thejpster:matrix.org> I'm having flashbacks to the Rust support I wrote for the Cortex-M4 IPU on the TI Sitara 3xxx series SoC.
<re_irc> <@thejpster:matrix.org> I want to make a table containing: 1: two magic numbers 2: the address of a section, 3: the address of the end of the section
<re_irc> <@xiretza:xiretza.xyz> I was a little surprised to see that the `build` option in the manifest is on a per-package basis, and can't be overridden for binaries/examples, that would have been another option of getting the wanted result
<cr1901> Sometimes the rust embedded story wrt feels like "Rust has no GC, so everything the embedded ppl need should fall into place with minimal effort"
<re_irc> <@thejpster:matrix.org> You can get the address of the section with an exported symbol from the linker (or at least a fake variable which has an address equal to the value you want) ... but you can't cast pointers to integers at compile time.
<re_irc> <@thejpster:matrix.org> --> boards/pico/examples/pico_blinky.rs:55:14
<re_irc> <@thejpster:matrix.org> |
<re_irc> <@thejpster:matrix.org> error[E0658]: casting pointers to integers in statics is unstable
<re_irc> <@thejpster:matrix.org> 55 | unsafe { &PICOTOOL_TABLE_START as *const _ as usize },
<re_irc> <@thejpster:matrix.org> cr1901: yeah
<cr1901> wrt cargo*
<re_irc> <@thejpster:matrix.org> OK file, I will make a table of pointers.
<re_irc> <@thejpster:matrix.org> But no, static array of *const u32 is not Send, so cannot exist.
<cr1901> >static array of *const u32 is not Send
<cr1901> Why not ._.? You can't do anything with it w/o unsafe
<cr1901> >However raw pointers are, strictly speaking, marked as thread-unsafe as more of a lint
<cr1901> thejpster: Most uses of raw pointers should be encapsulated behind a sufficient abstraction that Send and Sync can be derived.
<cr1901> I knew I remember reading something about this
<cr1901> I assume "unsafe is fine" for this, but even if you have #[deny(unsafe)], you can #[allow(unsafe)] for a single item, preferably w/ a comment explaining why "you know more than the compiler here"
<re_irc> <@thejpster:matrix.org> extern "C" {
<re_irc> <@thejpster:matrix.org> static PICOTOOL_TABLE_START: u32;
<re_irc> <@thejpster:matrix.org> static PICOTOOL_TABLE_END: u32;
<re_irc> <@thejpster:matrix.org> }
<re_irc> <@thejpster:matrix.org> error[E0277]: `*const u32` cannot be shared between threads safely
<re_irc> <@thejpster:matrix.org> --> boards/pico/examples/pico_blinky.rs:51:1
<re_irc> <@thejpster:matrix.org> 51 | / pub static PICOTOOL_META: [*const u32; 4] = [
<re_irc> <@thejpster:matrix.org> |
<re_irc> <@thejpster:matrix.org> To quote Kimi Raikonnen, go away and leave me alone - I know what I'm doing.
<re_irc> <@thejpster:matrix.org> I just want four 32-bit values in memory - two magic variables, one start address of some other object and one end address of that same object.
<re_irc> <@adamgreig:matrix.org> #[repr(transparent)]
<re_irc> <@adamgreig:matrix.org> thejpster: it sucks but maybe:
<re_irc> <@adamgreig:matrix.org> ```rust
<re_irc> <@adamgreig:matrix.org> pub struct MetaTable([*const u32; 4]);
<re_irc> <@thejpster:matrix.org> The cast is unsafe, but yes, unsafe impl of Sync is sufficient
<re_irc> <@thejpster:matrix.org> ```rust
<re_irc> <@thejpster:matrix.org> static __picotool_entries_end: u32;
<re_irc> <@thejpster:matrix.org> extern "C" {
<re_irc> <@thejpster:matrix.org> static __picotool_entries_start: u32;
<re_irc> <@thejpster:matrix.org> That doesn't work (more bits are missing from the header), but it compiles. Thank you adamgreig and cr1901
<re_irc> <@adamgreig:matrix.org> could even make it a const fn on PicotoolHeader that knows about hello/goodbyte values and takes two &u32
troth1 has quit [Quit: Leaving.]
troth has joined #rust-embedded
fabic_ has quit [Ping timeout: 264 seconds]
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
<re_irc> <@lachlansneff:matrix.org> Anyone have any idea how to read a sensor that says its output is 4 - 20 mA?
<re_irc> <@lachlansneff:matrix.org> I'm guessing that it means that the current draw changes, but the datasheet doesn't really say anything
<re_irc> <@newam:matrix.org> That is very common for industrial automation and instrumentation where you have long wires
<re_irc> <@newam:matrix.org> Use a resistor and sample with an ADC
<re_irc> <@lachlansneff:matrix.org> So, the current draw does change?
<re_irc> <@newam:matrix.org> It is a current source typically so your load defines the voltage range, but yeah, the current changes based on the signal.
<re_irc> <@adamgreig:matrix.org> you typically apply 24V (check datasheet) across the sensor, add a resistor (maybe 20R or 100R) in series, and measure voltage across the resistor
<re_irc> <@adamgreig:matrix.org> put the resistor on the 0V side to make it easier to plug right into the ADC
<re_irc> <@adamgreig:matrix.org> (100R gives you 0.4V to 2V full scale, so should work fairly nicely into a 3v3 ADC, or you could 130R to get even closer to full scale at the cost of slightly more "burden voltage")
<re_irc> <@lachlansneff:matrix.org> Ah thank you, that's all really helpful
<re_irc> <@thejpster:matrix.org> adamgreig: `error[E0013]: constant functions cannot refer to statics`
<re_irc> <@adamgreig:matrix.org> you can't pass the static into the constant fn?
<re_irc> <@adamgreig:matrix.org> Lachlan Sneff: be a bit wary with circuit design, for example if you accidentally shorted the sensor leads the whole 24V would be across your 100R, which would a) dump almost 6W into the resistor, probably bad for it b) dump 24V into your ADC, definitely bad for it
<re_irc> <@adamgreig:matrix.org> fuses, transient voltage suppressors, sticking an opamp with decent input protection in front, etc, can all help out
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 245 seconds]
<re_irc> <@adamgreig:matrix.org> hi room 👋! meeting time again, agenda is https://hackmd.io/wbrPWn7pSfWADETZYAW2WA, please add anything you'd like to discuss and we'll start in 5min
<cr1901> adamgreig: I can't edit the file
<cr1901> can you unlock it so I don't need to make an acct?
<re_irc> <@therealprof:matrix.org> same
<re_irc> <@adamgreig:matrix.org> oops, sorry! permissions fixed
<re_irc> <@adamgreig:matrix.org> ok, let's start!
<re_irc> <@adamgreig:matrix.org> couple of quick announcements, first stm32-rs 0.14 is finally released, thanks to the many contributors to that!
<re_irc> <@adamgreig:matrix.org> svd-parser 0.10, which is used in svd2rust especially, has been split into three separate crates, svd-rs, svd-parser, and svd-encoder, to allow it to be useful to more projects (including a rewrite of svdtools in rust)
<re_irc> <@adamgreig:matrix.org> and, cortex-m-rt versions 0.6.11 through 0.6.14 have been yanked, leaving 0.6.15 as the _only_ 0.6.X release, to help fix some confusing error messages when users tried to combine 0.6 and 0.7 in a single project
<re_irc> <@adamgreig:matrix.org> because 0.6.15 sets the `links` key, cargo knows it can't be linked against a 0.7 release, but that wasn't true of 0.6.14, so it would try and include both and then the linker would complain
<re_irc> <@adamgreig:matrix.org> now, in many cases users correctly only get 0.6.15, and in other cases they get an error about multiple cortex-m-rt versions, instead of a series of very confusing linker errors about interrupt names
<re_irc> <@adamgreig:matrix.org> thanks to newam for prompting that one
<re_irc> <@adamgreig:matrix.org> that's all the announcements from me (three in one week!), anyone else have anything?
<re_irc> <@adamgreig:matrix.org> well, shout if you remember anything later :) I had added a quick note about the discovery rewrite, which is just in final polishing up now, but has an issue around the nrf releases so is waiting on that (and probably the cortex-m-rt issue I described above, too)
<re_irc> <@adamgreig:matrix.org> onto embedded-hal, the PR for implementing traits for &T where implemented for T is merged, thanks GrantM11235!
<re_irc> <@adamgreig:matrix.org> on the [error traits](https://github.com/rust-embedded/embedded-hal/pull/296) I think we're now ready? eldruin has removed the CRC error from SPI and split NoACcknowledge into a separate data and address variant, as we discussed last week
<re_irc> <@eldruin:matrix.org> yeah except anybody raises further concerns
<re_irc> <@therealprof:matrix.org> What's the latest from ryankurte on that?
<re_irc> <@adamgreig:matrix.org> eldruin:matrix.org: _further_ concerns? surely not :P
<re_irc> <@adamgreig:matrix.org> there is https://github.com/rust-embedded/embedded-hal/pull/296#discussion_r721386337 but I think we more or less concluded last time that as far as well can tell, implementations should be OK to work out data vs addr no-ack
<re_irc> <@eldruin:matrix.org> i can talk to him
<re_irc> <@adamgreig:matrix.org> ok, [DelayUs](https://github.com/rust-embedded/embedded-hal/pull/312) unification
<re_irc> <@adamgreig:matrix.org> I think no more open concerns here? there was some chat about the name briefly but it seems like DelayUs is probably a good choice in the end
<re_irc> <@eldruin:matrix.org> yeah I think the "precision" in the name is a good point
<re_irc> <@adamgreig:matrix.org> as in, a good reason to call it DelayUs, or a good reason to reconsider the name?
<re_irc> <@adamgreig:matrix.org> the _resolution_ is microseconds in any event :P
<re_irc> <@eldruin:matrix.org> good reason to call it delayus
<re_irc> <@eldruin:matrix.org> I mean the difference between the trait name and the method names
<re_irc> <@therealprof:matrix.org> So still good to go?
<re_irc> <@eldruin:matrix.org> yeah LGTM
<re_irc> <@therealprof:matrix.org> Merging.
<re_irc> <@eldruin:matrix.org> ryan also sait it seemed reasonable
<re_irc> <@eldruin:matrix.org> great, thanks
<re_irc> <@adamgreig:matrix.org> cool, next up is the [separate buffers for spi transfer](https://github.com/rust-embedded/embedded-hal/pull/287) PR
<re_irc> <@adamgreig:matrix.org> which I think is more or less resolved now? maybe checking in with ryankurte about the impl-defined fill values, but the docstring as it stands now says "it's implementation defined" which seems a pretty fair bet
<re_irc> <@eldruin:matrix.org> I'll talk to him about both PRs
<re_irc> <@adamgreig:matrix.org> great, thanks!
<re_irc> <@adamgreig:matrix.org> ok, [CAN take 4](https://github.com/rust-embedded/embedded-hal/pull/314)
<re_irc> <@adamgreig:matrix.org> it looks like all four points I mentioned have been resolved, and eldruin pointed out the Ack error variant could be NoAcknowledge to be consistent with I2C
<re_irc> <@adamgreig:matrix.org> though in CAN world, it probably is an "ACK error" rather than the "no acknowledge" of I²C
<re_irc> <@adamgreig:matrix.org> maybe?
<re_irc> <@therealprof:matrix.org> Not too much of an idea of naming in the can world.
<re_irc> <@adamgreig:matrix.org> that's from the CAN 2.0 standard
<re_irc> <@therealprof:matrix.org> Hm, German engineering.
<re_irc> <@therealprof:matrix.org> Must be alright then.
<re_irc> <@adamgreig:matrix.org> hmm, I guess that would make I²C Duth
<re_irc> <@eldruin:matrix.org> whatever the standard says I would say
<re_irc> <@adamgreig:matrix.org> anything else on the CAN PR? I appreciate it's a bit harder to review since it's a more niche protocol
<re_irc> <@adamgreig:matrix.org> but it does have a number of implementations and an example program using it
<re_irc> <@therealprof:matrix.org> Looks all good to me.
<re_irc> <@adamgreig:matrix.org> as a practical matter, it looks like the error matching uses Self in enum variant position which clippy is very upset about
<re_irc> <@therealprof:matrix.org> Does this replace the CAN traits defined elsewhere?
<re_irc> <@therealprof:matrix.org> I think it's a MSRV problem.
<re_irc> <@adamgreig:matrix.org> yes, it's https://github.com/timokroeger/embedded-can
<re_irc> <@therealprof:matrix.org> It also complains about `non_exhaustive`.
<re_irc> <@adamgreig:matrix.org> (but with the tidyups in that PR, e.g. renaming s/try_//, error types, etc)
<re_irc> <@therealprof:matrix.org> Sure. Just wandering what this means for the hal impls. Can CAN be providded just with e-h then or is `embedded-can` still offering something on top?
<cr1901> What also complains about non_exhaustive?
<re_irc> <@therealprof:matrix.org> cr1901: This PR https://github.com/rust-embedded/embedded-hal/pull/314
<cr1901> hmmm
<re_irc> <@adamgreig:matrix.org> therealprof: embedded-can is only the traits that are being proposed for e-h, so the whole embedded-can crate could be deprecated and HALs would only need e-h
<re_irc> <@timokrgr:matrix.org> author of embedded-can here, looks like I almost missed the meeting
<cr1901> I remember reading that non_exhaustive is discouraged in general
<re_irc> <@therealprof:matrix.org> adamgreig: Thanks for the clarification.
<re_irc> <@adamgreig:matrix.org> cr1901: because non_exhaustive comes from a later rust version than the e-h MSRV, I think
<re_irc> <@timokrgr:matrix.org> I'm still a bit unsure if all controllers can actually report the defined errors
<re_irc> <@timokrgr:matrix.org> (for CAN)
<re_irc> <@adamgreig:matrix.org> hi timokrgr!
<re_irc> <@adamgreig:matrix.org> sure, I bet there are some controllers that do not, but it seems like a really safe set of errors to include given the standard literally says these are what they are, right?
<re_irc> <@therealprof:matrix.org> adamgreig: The error PR bumps the MSRV.
<re_irc> <@adamgreig:matrix.org> aah, cool, so these should be fine after that, then?
<re_irc> <@therealprof:matrix.org> adamgreig: Maybe, not sure about the other lint.
<re_irc> <@timokrgr:matrix.org> yeah, took the erros and the descriptions straight from the standard
<re_irc> <@timokrgr:matrix.org> except for overrun
<re_irc> <@emilgardis:matrix.org> Hi, I realised there's a meeting today :D
<re_irc> <@newam:matrix.org> irc_libera_cr1901:psion.agg.io: It is used in the standard library (notably in io::ErrorKins), it is a good idea when the future isn't clear
<re_irc> <@adamgreig:matrix.org> therealprof: looks like it landed in 1.37
<re_irc> <@adamgreig:matrix.org> https://github.com/rust-lang/rust/pull/61682
<re_irc> <@therealprof:matrix.org> irc_libera_cr1901:psion.agg.io: I'd double check that. `non_exhaustive` is great for forward compatibility. 😅
<re_irc> <@adamgreig:matrix.org> ah, current MSRV is 1.35, and the error PR bumps to 1.40
<re_irc> <@adamgreig:matrix.org> so it should also be fine to use the Self aliases
<re_irc> <@eldruin:matrix.org> exactly (sorry I was afk for a while)
<re_irc> <@adamgreig:matrix.org> so, CAN PR lgtm
<re_irc> <@adamgreig:matrix.org> after like 4 PRs and 3 years 😅
<re_irc> <@eldruin:matrix.org> I would have another look but it seemed fine to me too
<re_irc> <@timokrgr:matrix.org> give me a few more days on the CAN pr, I think it is missing a `Other` error variant
<re_irc> <@eldruin:matrix.org> You can mark it as a draft until you think it is ready
<re_irc> <@adamgreig:matrix.org> any other HAL PRs to check in on?
<re_irc> <@timokrgr:matrix.org> or we just merge it as is, I mean non_exhaustive let’s us add errors later
<re_irc> <@timokrgr:matrix.org> the traits themselves have matured
<re_irc> <@adamgreig:matrix.org> having `Other` to match the spi and i2c errors seems to make sense
<re_irc> <@timokrgr:matrix.org> its just the error stuff that is new
<re_irc> <@adamgreig:matrix.org> (the HALs can still have more specific error types on top, but they need to map to something in ErrorKind)
<re_irc> <@adamgreig:matrix.org> ok, let's leave the HAL stuff there for now, we can revisit some of the older PRs next week after all these recent merges :D
<re_irc> <@adamgreig:matrix.org> quick plug for the newsletter, please PR anything you'd like to mention to [the next draft](https://github.com/rust-embedded/blog/blob/master/content/2021-08-24-newsletter-30.md)!
<re_irc> <@adamgreig:matrix.org> emilgardis added a couple points, first svd2rust update to the new 0.11 svd-parser crate in https://github.com/rust-embedded/svd2rust/pull/542
<re_irc> <@adamgreig:matrix.org> I haven't seen any tricks to avoid that huge list in bors.toml, but maybe you're right and we can just add a final workflow step that needs all the previous ones to succeed, then gate bors on that?
<re_irc> <@adamgreig:matrix.org> it would be really nice for other crates like smoltcp ( dirbaio ) and stm32-rs too, if that works
<re_irc> <@emilgardis:matrix.org> I can make some prs for that, I've used it successfully in other bors workflows
<re_irc> <@adamgreig:matrix.org> nice!
<re_irc> <@adamgreig:matrix.org> that would be good to see, a lot of repos have been accumulating so many entries in their bors.toml, heh
<re_irc> <@dirbaio:matrix.org> oh yeah it's horrible, especially because github truncates it to 100 chars
<re_irc> <@adamgreig:matrix.org> like github truncating the long names with a `...` at the end that you need to tells bors about
<re_irc> <@adamgreig:matrix.org> lol
<re_irc> <@dirbaio:matrix.org> you have to put `test (nightly, std medium-ethernet proto-ipv4 proto-ipv6 socket-raw socket-udp socket-tcp socket-...`, yes with the `...` 🤣
<re_irc> <@dirbaio:matrix.org> what's the context for this bors thing?
<re_irc> <@emilgardis:matrix.org> but the svd2rust update is working fine, there is just one small regression it seems on Espressif
<re_irc> <@jessebraham:matrix.org> Yeah I had actually opened a PR on the `esp-rs/esp32` repo to fix that, got pinged this morning
<re_irc> <@jessebraham:matrix.org> If it's high-priority I can merge it myself though
<re_irc> <@emilgardis:matrix.org> im sure it can wait a little
<re_irc> <@adamgreig:matrix.org> oh, talking of esp32, I wanted to update svdtools with a detection for duplicate keys in the yaml (since it's always an error), but the svdtools CI failed on esp32 because of some duplicate keys, heh https://github.com/stm32-rs/svdtools/pull/72
<re_irc> <@adamgreig:matrix.org> if I have time I'll try and make a PR for it
<re_irc> <@jessebraham:matrix.org> I can take a look at that if you'd like
<re_irc> <@adamgreig:matrix.org> if you have time that would be great! they probably indicate mistakes in the yaml files that should be fixed anyway
<re_irc> <@adamgreig:matrix.org> otherwise i'll try and get around to it when i'm next poking svdtools
<re_irc> <@adamgreig:matrix.org> I believe the new rust version also rejects duplicate keys, not sure
<re_irc> <@adamgreig:matrix.org> ok, final agenda point is about the cross call for maintainers, https://github.com/rust-embedded/cross/issues/574
<re_irc> <@adamgreig:matrix.org> I don't have any news beyond what you can read in the thread 😭
<re_irc> <@emilgardis:matrix.org> sorry for bringing it up 😅
<re_irc> <@adamgreig:matrix.org> the tab has been open in my browser for months now 😅
<re_irc> <@adamgreig:matrix.org> I'm not really sure what the best way to proceed with it is. cross still needs maintainers
<re_irc> <@adamgreig:matrix.org> there's a number of enthusiastic volunteers
<re_irc> <@emilgardis:matrix.org> There's currently some work done in https://github.com/rust-embedded/cross/pull/591 to update lts versions, I like that :D
<re_irc> <@emilgardis:matrix.org> However, I remember some discussion about GLIBC versions, I can't find the context for it anymore though
<re_irc> <@therealprof:matrix.org> Compatibility with older Ubuntu LTS and RHEL 7.
<re_irc> <@emilgardis:matrix.org> iirc, we want to keep it as low as possible, but with LTS bumping glibc I think it's inevitable that if you need older glibc, you'll have to make your own image for compilation
<re_irc> <@therealprof:matrix.org> Some people are not ready to ditch compatibility with glibc versions still supported by upstream Rust.
<re_irc> <@therealprof:matrix.org> It's one of the cross usecases I believe to compile for those ancient but still supported Linux versions. 😅
<re_irc> <@emilgardis:matrix.org> perhaps the solution is to just provide even more images, moving over to ghcr
<re_irc> <@adamgreig:matrix.org> so a mix of more recent LTS images and some very old images for old libc?
<re_irc> <@emilgardis:matrix.org> Yes, a possiblity then could even be including SSL :3
<re_irc> <@adamgreig:matrix.org> 😢 symbol versioning sure is a mess huh
<re_irc> <@therealprof:matrix.org> Not really.
<re_irc> <@adamgreig:matrix.org> well, needing to build on ancient ubuntu/centos to get an old enough libc for your otherwise statically linked binary is annoying, anyway
<re_irc> <@therealprof:matrix.org> But nothing screams enterprise more than an ancient glibc version obviously.
<re_irc> <@adamgreig:matrix.org> I understand it's tricky and there are reasons and so forth, hence cross
<re_irc> <@adamgreig:matrix.org> hm, I have to run and we're out of time, but not sure what the answer is on cross
<re_irc> <@emilgardis:matrix.org> to be continued
<re_irc> <@adamgreig:matrix.org> the person making the recent PR bumping versions has also offered to be a maintainer
<re_irc> <@adamgreig:matrix.org> yes, TBC I guess
<re_irc> <@adamgreig:matrix.org> ok, thanks everyone for attending, good meeting! have a good week!
<re_irc> <@eldruin:matrix.org> you too!
<cr1901> Roundabout plays in the background
<re_irc> <@therealprof:matrix.org> I wish more people would shout at RedHat for still using a 9 year old glibc. Upgrading that to something a few years more recent is not rocket science...
<re_irc> <@dirbaio:matrix.org> Made a matrix room for smoltcp: https://matrix.to/#/#smoltcp:matrix.org
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
<re_irc> <@dbrgn:matrix.coredump.ch> I saw that two STM32 HALs are using rtcc/chrono for RTC handling, including its NaiveDateTime type. How are the experiences with that? I started integrating it into the STM32L0 HAL as well, one of the issues I encountered is the year: It's stored in two-digit BCD format. Is that assumed to be relative to 1970? Because if it is not, how can the RTC do proper leap year handling? (I didn't see an...
<re_irc> ... explanation of this in the datasheet...)
<re_irc> <@dbrgn:matrix.coredump.ch> (Ping eldruin as the author of rtcc)
<re_irc> <@eldruin:matrix.org> I have not done any HAL impls. I implemented the trait on several I2C RTC drivers
<re_irc> <@eldruin:matrix.org> IIRC they handle leap years for you up to 2100 or so
<re_irc> <@dbrgn:matrix.coredump.ch> Yeah, STM32L0 reference manual also says they handle leap years. However, if the year "30" is the year 0030, it's not a leap year, but if it's the year 2000, then it _is_ a leap year.
<re_irc> <@eldruin:matrix.org> if it's only two digit, it would only make sense to be 2000-based I guess
<re_irc> <@firefrommoonlight:matrix.org> I love Chrono. It's the nicest DT lib I've seen on any language. And it supports no-std, with simple copy types
<re_irc> <@firefrommoonlight:matrix.org> I'd originally used RTCC, which thinly wraps it, but ditched that for Chrono directly, since RTCC was adding complication without providing any concrete advantage
<re_irc> <@eldruin:matrix.org> the advantage was the ability to write RTC-generic code
<re_irc> <@eldruin:matrix.org> like being able to exchange your RTC chip with no code change
<re_irc> <@eldruin:matrix.org> just like with every other trait abstraction
<re_irc> <@firefrommoonlight:matrix.org> I was unable to identify a specific use case for that
<re_irc> <@dbrgn:matrix.coredump.ch> It seems to be 2000-based indeed: https://community.st.com/s/question/0D50X0000CCqHHG/is-there-a-known-stm32f091-leap-year-rtc-problem To be honest, that's the first time I come across a 2000 based RTC. And it seems that the stm32f3xx-hal and stm32f4xx-hal got that wrong (but I'd have to dobule-check).
<re_irc> <@dbrgn:matrix.coredump.ch> Or, when looking at it differently, it's year 0 based, but the leap year calculation is identical if you shift by 2000 years.
<re_irc> <@firefrommoonlight:matrix.org> RTCC re-exports Chrono types; I think it's clearer to just import Chrono directly. Not a big deal if you're familiar with both libs, but confusing for new users
<re_irc> <@dbrgn:matrix.coredump.ch> From what I can tell, stm32f3xx-hal and stm32f4xx-hal both use 1970 as year base and thus won't properly handle leap years.
<re_irc> <@firefrommoonlight:matrix.org> You could perhaps fix that by removing the ` - 1970` bit
<re_irc> <@dbrgn:matrix.coredump.ch> Yes, that should do, plus the validation. I'll probably send PRs once I finish the STM32L0 integration.
<re_irc> <@firefrommoonlight:matrix.org> *hmm maybe not
<re_irc> <@dbrgn:matrix.coredump.ch> Ah, no, not removing, but replacing it by 2000.
<re_irc> <@dbrgn:matrix.coredump.ch> It's not an ideal solution either though.
<re_irc> <@dbrgn:matrix.coredump.ch> Maybe the user should choose a year base explicitly.
<re_irc> <@firefrommoonlight:matrix.org> I'm curious what you come up with
<re_irc> <@dbrgn:matrix.coredump.ch> The worst thing is that 8 bits in the RTC_DR register are actually unused / reserved... They should simply have implemented support for 4-digit years, would make things much easier 😕
<re_irc> <@firefrommoonlight:matrix.org> eldruin: I think we're just looking at this from different perspectives and use cases. You're building a generic ecosystem for the future to make libraries compatible with each other. I'm writing firmware that uses the onboard RTC in several projects and want the code to be clear/simple/functional