starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #rust-embedded
fabic has joined #rust-embedded
tokomak has joined #rust-embedded
fabic has quit [Remote host closed the connection]
fabic has joined #rust-embedded
PyroPeter has quit [Ping timeout: 250 seconds]
PyroPeter has joined #rust-embedded
dcz_ has joined #rust-embedded
dcz_ has quit [Ping timeout: 252 seconds]
dcz_ has joined #rust-embedded
tokomak has quit [Ping timeout: 260 seconds]
dcz_ has quit [Ping timeout: 265 seconds]
dcz_ has joined #rust-embedded
<re_irc> <> ;( i'm stuck on a dma issue
<re_irc> <> i don't understance what happen but my dma transfert don't want to run. when i set the "en" bit, i laways get the disabled value when reading it back
<re_irc> <> it soo much anoying because i just took a code that was working and adapted for RTIC context
fabic has quit [Ping timeout: 252 seconds]
<re_irc> <> If you have the code to share I'd take a look :)
<re_irc> <> There is quite a good one in stm32l4xx hal
<re_irc> <> korken89: i'm using stm32f4 chip and i'm bypassing the stm32f4xx hal
<re_irc> <> Well you can copy the implementation then
<re_irc> <> So you don't walk in the same pitfalls :)
<re_irc> <> i'm not sure a generic hal can be used for what i want to do
<re_irc> <> A friend of mine wants to customize and run my keyboard firmware but he's not the type that would have an easy time setting up a Rust build environment for embedded use... Is there a service that can build a firmware from a Github repo? If not I'll stand one up
<re_irc> <> i want to use 2 dma stream in circular mode and on the same buffer
<re_irc> <> It all depends on what you want to do, plus seeing how the DMA used is used may help you find issues with your implementation
<re_irc> <> github actions can do exactly that :)
<re_irc> <> Yeah I figured there'd be something like that already
tokomak has joined #rust-embedded
<re_irc> <> korken89: here it is
<re_irc> <> but there is many line of code
<re_irc> <> and many unsafty :p
<re_irc> <> korken89: does my code too ugly to be read by somone else ? ;)
<re_irc> <> I had a look, but it's too mixed together for me to make sense of it
<re_irc> <> lol, this is what i feared
<re_irc> <> unfortunatly, i don't know how to make it mor clear
<re_irc> <> i guess i should go back to something that work and implement dma separately
<re_irc> <> yruama_lairba: I'd probably look at DMA once there're no more options to do what needs doing without.
<re_irc> <> therealprof: ok, i want to use it for optimization, mainly by reducing context switching
<re_irc> <> i didn't made measurement, but i think it worth to reduce by ~100 the number of triggered interuption
<re_irc> <> expecially when initially i have 48 000*4 interruptions during normal operation
<re_irc> <> Do you need to reduce the amount of interrupts?
<re_irc> <> therealprof: i want to reduce the penalty due to interrupts execution
dcz_ has quit [Ping timeout: 252 seconds]
<re_irc> <> i wonder how i could determine the average cpu cycle to fully execute my interrupt
<re_irc> <> it depends on what features your CPU has. ARM CPUs have a trace peripheral included with the core for measuring things like this.
<re_irc> <> newam: have you a doc for it ?
<re_irc> <> Depends on your core. If you do have an ARM core you'll want to look at the ARMvX-M architecture reference manual (you probably want v6 or v7).
<re_irc> <> This is for v7:
<re_irc> <> I think the arm i use is a cortex m4
<re_irc> <> Yup, that's v7
<re_irc> <> A simple place to start is the cycle counter. Literally counts CPU cycles, you sample it twice, compare the difference. The name is DWT.CCNT or something like that.
<re_irc> <> There are more advanced features, but they take time to setup.
<re_irc> <> ok, i just need to count cpu cycle
<re_irc> <> thanks to gave me DWT.CCNT because the arm doc difficult to understand
<re_irc> <> ```rs
<re_irc> <> use cortex_m::peripheral::{Peripherals, DWT};
<re_irc> <> peripherals.DWT.enable_cycle_counter();
<re_irc> <> let mut peripherals = Peripherals::take().unwrap();
<re_irc> <> DCB.enable_trace() ? it's required ?
<re_irc> <> Yup. Most of the time you don't want to spend the power to keep debug features enabled (for release firmware)
<re_irc> <> will do that later
<re_irc> <> newam: your code deosn't work here, i don't know how to get CorePeripherl from rtic context
<re_irc> <> i tried use the unsafe `stm32::DCB::ptr()` but `enable_trace()` is not defined ???
<re_irc> <> I think you need to dereference the pointer. Try `unsafe {*(stm32::DCB::ptr()).enable_trace()}`
<re_irc> <> i finally got it from rtic, i was context.core.DCB
<re_irc> <> and i did my measure, execution of my interrupt is 100~200 cpu cycle
<re_irc> <> this is almost ten time more than i expect
<re_irc> <> if i calculate correctly, i spend 20~40% of cpu time inside my interruption
<re_irc> <> so it really worth to use dma to handle I2S transfer
<re_irc> <> with dma, i estimate less than 0.1% time spended in interuption to handle the same transfer