<re_irc>
<@dirbaio:matrix.org> I've gone through all rust-analyzer.* and nothing :D :D
<re_irc>
<@metreo:matrix.org> yay
<re_irc>
<@dirbaio:matrix.org> i'm using the nightly channel btw
<re_irc>
<@metreo:matrix.org> ... oh no
<re_irc>
<@dirbaio:matrix.org> on the stable channel it does seem "install another version" does work
<re_irc>
<@metreo:matrix.org> yeah you can try changing `rust-analyzer.updates.channel`
<re_irc>
<@dirbaio:matrix.org> but stable RA always gives me "proc macro server crashed"
<re_irc>
<@dirbaio:matrix.org> I think you need nightly RA if you use nightly Rust?
<re_irc>
<@metreo:matrix.org> uhh well if you're using a nightly only feature that would make sense
<re_irc>
<@metreo:matrix.org> I just recall solving that problem by using nightly
<re_irc>
<@dirbaio:matrix.org> even on the GH releases page there's just one tag saying "nightly"
<re_irc>
<@dirbaio:matrix.org> no way to download earlier nightlies
<re_irc>
<@dirbaio:matrix.org> wtf?
<re_irc>
<@dirbaio:matrix.org> > memory allocation of 140394323341974 bytes failed
<re_irc>
<@dirbaio:matrix.org> > [ERROR proc_macro_api::process] proc macro server crashed, server process state: Ok(Some(ExitStatus(ExitStatus(134)))), server request error: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }
<re_irc>
<@metreo:matrix.org> what about `rustup` right?
<re_irc>
<@metreo:matrix.org> yeah that's a classic error message
<re_irc>
<@metreo:matrix.org> and the prior releases _are_ listed on the GH page...
<re_irc>
<@metreo:matrix.org> I don't know that nightly RA necessarily corresponds to the nightly rustc, but if you find out it might be interesting to know
<re_irc>
<@thalesfragoso:matrix.org> I've been using stable RA with nightly rust without problems
<re_irc>
<@dirbaio:matrix.org> maybe it's because i'm on a super old nighlty (from may)
<re_irc>
<@dirbaio:matrix.org> updating it requires updating embassy
<re_irc>
<@dirbaio:matrix.org> and updated embassy uses nrf pac 0.10, while nrf-hal uses pac 0.9
<re_irc>
<@dirbaio:matrix.org> aaaaaaaa
<re_irc>
<@dirbaio:matrix.org> > warning: Linking globals named 'error: cortex-m-rt appears more than once in the dependency graph': symbol multiply defined!
<re_irc>
<@dirbaio:matrix.org> > error: failed to load bc of "cortex_m_rt-4a9e3711f9eef980.cortex_m_rt.3aa2ca53-cgu.0.rcgu.o":
<re_irc>
<@dirbaio:matrix.org> thankfully it's a tcp issue only
<re_irc>
<@dirbaio:matrix.org> can be workarounded from the server
<re_irc>
<@dirbaio:matrix.org> phew :D
<re_irc>
<@jamesmunns:matrix.org> I would not wish that "stomach drop" feeling on anyone :p
<re_irc>
<@dirbaio:matrix.org> it's always tcp
<re_irc>
<@dirbaio:matrix.org> cursed tcp
<re_irc>
<@firefrommoonlight:matrix.org> Durations, freqs etc, alternatively, can be handled with intergers or floats, with appropriate function (etc) documentation
<re_irc>
<@firefrommoonlight:matrix.org> In the spirit of keeping it simple. Although I buy the idea of special types as not much more complex, and providing a check you don't accidentally use an unrelated integer, or use the wrong unit
<re_irc>
<@firefrommoonlight:matrix.org> To bring it full circle, I might be overreacting to the STM32hal's use of the Hertz method that caused several issues. I'm open to standardizing APIs around a smart duration or freq type. Ie, I'm close to 50/50 on that vice int/float
<re_irc>
<@firefrommoonlight:matrix.org> With the standard float-on-embedded caveats implying
<re_irc>
<@firefrommoonlight:matrix.org> A smart type would make sure you don't dork up the units
<re_irc>
<@firefrommoonlight:matrix.org> Although keeping things in SI seconds/Hertz is another way
<re_irc>
<@dirbaio:matrix.org> seconds only works if you use floats...
<re_irc>
<@dirbaio:matrix.org> and mandating using floats in e-h will be very unpopular
<re_irc>
<@firefrommoonlight:matrix.org> I buy that
<re_irc>
<@firefrommoonlight:matrix.org> For the non-FPU MCUs, and performance penalty of compiling for FPU targets as you've mentioned previously
<re_irc>
<@firefrommoonlight:matrix.org> Seconds is a bit chunky for use without floats. You could do `set_freq()` in Hz, and `set_period()` dual constructors, where the latter uses micros or something
<re_irc>
<@firefrommoonlight:matrix.org> You dodge the floats, and keep the builtin types, if that's your approach
starblue1 has quit [Ping timeout: 265 seconds]
starblue1 has joined #rust-embedded
fabic_ has quit [Remote host closed the connection]
fabic has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 256 seconds]
_whitelogger has joined #rust-embedded
Foxyloxy has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> Cortex-m question: Is it generally always a good idea to enable the icache (instructions cache) for performance?
<re_irc>
<@dirbaio:matrix.org> I guess yes
<re_irc>
<@dirbaio:matrix.org> nordic's docs says one downside is it uses more power
<re_irc>
<@dirbaio:matrix.org> but the difference is so tiny I haven't been able to measure it
<re_irc>
<@firefrommoonlight:matrix.org> Nice!
<re_irc>
<@dirbaio:matrix.org> it's literally a "GO FASTER" bit
<re_irc>
<@firefrommoonlight:matrix.org> I'll use it as a default!
<re_irc>
<@firefrommoonlight:matrix.org> Probably put it in HAL examples too
<re_irc>
<@dirbaio:matrix.org> one gotcha is maybe you need to flush the icache after writing to flash
<re_irc>
<@firefrommoonlight:matrix.org> Hmm.. I'll look into that. I'm using builtin flash on one of my projects
DepthDeluxe has quit [Ping timeout: 260 seconds]
PyroPeter has quit [Ping timeout: 252 seconds]
PyroPeter has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 268 seconds]
Foxyloxy has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 260 seconds]
Foxyloxy has joined #rust-embedded
dcz_ has joined #rust-embedded
dcz has joined #rust-embedded
dcz_ has quit [Ping timeout: 252 seconds]
emerent_ has joined #rust-embedded
emerent is now known as Guest1871
emerent_ is now known as emerent
Guest1871 has quit [Ping timeout: 268 seconds]
fabic has quit [Ping timeout: 268 seconds]
gsalazar has joined #rust-embedded
gsalazar has quit [Read error: Connection reset by peer]
gsalazar has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
starblue1 has quit [Ping timeout: 252 seconds]
<re_irc>
<@sympatron:matrix.org> What are the use cases e-h is trying to solve with durations? If it's only for delays you might get away with something simple like a single duration trait. It just needs to have a method to get the resolution or something. Otherwise it will be very hard for hals to implement, because a 5us delay has to be handled differently than a 100ms delay.
<re_irc>
<@dirbaio:matrix.org> which is not the same as arm's icache which is only on beefier cores like the M7
<re_irc>
<@firefrommoonlight:matrix.org> Oh, so that's not what you use `cp.SCB.enable_icache()` for...
<re_irc>
<@firefrommoonlight:matrix.org> Hypothesis: The cortex-m icache may only me on M7 and M33?
gsalazar_ has joined #rust-embedded
gsalazar has quit [Ping timeout: 252 seconds]
DepthDeluxe has joined #rust-embedded
gsalazar_ is now known as gsalazar
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #rust-embedded
Foxyloxy has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
gsalazar has quit [Remote host closed the connection]
gsalazar has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
<re_irc>
<@almindor:matrix.org> did anyone ever used Qemu to emulate a board? is it difficult to set up a custom target? (e.g. peripherals, memory layout)
DepthDeluxe has quit [Ping timeout: 260 seconds]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 268 seconds]
gsalazar has quit [Ping timeout: 265 seconds]
<re_irc>
<@newam:matrix.org> almindor: I have used it at work to simulate a full SoC. Getting the boot sequence working is a bit annoying because the overall boot sequence is not designed with embedded in mind, if you have a single core system it is a lot easier. Flash/RAM is dead simple to implement. Peripherals take time, but are easy enough write, just a giant switch statement with a case for each register.
<re_irc>
<@newam:matrix.org> The only gotcha that I keep encountering is that a lot of the ARM IP is not parametric with regards to synthesis parameters (GIC security options for the A series notably), and can be quite difficult to change in some cases.
<re_irc>
<@newam:matrix.org> Other than that it is pretty easy to use if you know C, it just takes a bit of time to find your way around the code.
<re_irc>
<@newam:matrix.org> There is an open RFC to add rust support to QEMU; that will be a game changer if it gets merged because a lot of the logic would be much easier to write with `match`.
troth has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> sounds like crazy work if you need to emulate peripherals etc with a minimum of timing accuracy
<re_irc>
<@almindor:matrix.org> newam:matrix.org: Is there any example of this in the wild?
<re_irc>
<@newam:matrix.org> There is zero timing accuracy in QEMU, yeah. All event driven. QEMU is real fast though, much faster than SystemC models. Full chip simulation for an SoC takes half an hour to execute just the ROM. We use it at work to develop firmware while the SoC is still being designed/changed, works real well for that.
<re_irc>
<@newam:matrix.org> almindor: Xilinx has an open source fork that implements some of their SoC's, though it is a major version out of date.
<re_irc>
<@newam:matrix.org> Pebble (smart watch) also has a fork with their entire smart watch emulated. Also out of date.
<re_irc>
<@newam:matrix.org> If you're doing cortex-m things there should be enough in-tree to work from.
<re_irc>
<@newam:matrix.org> I will warn you there are no (good) developer docs for QEMU. The only way to learn it is to dive in and start modifying code to make what you want.
<re_irc>
<@almindor:matrix.org> thanks! I'll scrounge around and see if it's worth the effort
cr19011 is now known as cr1901
<re_irc>
<@jacobrosenthal:matrix.org> what about renode? I keep meaning to check that out
dcz has quit [Ping timeout: 265 seconds]
<re_irc>
<@cryptollision:matrix.org> jacobrosenthal: mess of C# and other `mono` goodness
<re_irc>
<@oddstr13:matrix.org> henrik_alser:matrix.org: Thanks, I'll have a look at them.
<re_irc>
<@oddstr13:matrix.org> What complicates this so much is that I need to not block on read :P
<re_irc>
<@henrik_alser:matrix.org> oddstr13:matrix.org: Yeah, those examples will show you examples of non blocking reads using DMA (when `wait()` is called in the transfer complete interrupt it will return immediately)
<re_irc>
<@henrik_alser:matrix.org> If you have multiple events triggering the same interrupt you can check `is_done()` on the Transfer so you don't risk blocking on `wait()`
<re_irc>
<@henrik_alser:matrix.org> (or if you just wanna poll it without using interrupts)
<re_irc>
<@oddstr13:matrix.org> I have not yet started looking into interrupts, right now I'm basically just busy-waiting polling USB-serial and the radio