<thalesfragoso[m]>
Sure, because it was way easier to write your own than trying to integrate everything
<thalesfragoso[m]>
Even today I wouldn't dare doing it with the usual pac interface
<firefrommoonligh>
thalesfragoso: I built a HAL that works on a bunch of families, and it wasn't a big deal
<thalesfragoso[m]>
The big deal is to make it complete and tested
<firefrommoonligh>
Sure, but... It's already more complete and has fewer bugs than any individual yxx one
<firefrommoonligh>
(other than being missing many H7-specific features)
<thalesfragoso[m]>
Didn't you just added usart support ?
<firefrommoonligh>
Yeah. That was the last big missing feature
<firefrommoonligh>
The yxx ones generally (with maybe a few exceptions) don't even implement low power, timers>1s, DACs etc
<thalesfragoso[m]>
Hmm, do you have DMA, I2S and SDIO support ?
<firefrommoonligh>
No
<firefrommoonligh>
Shit
<firefrommoonligh>
Adding I2S and SDIO to errata
<adamgreig-m>
presumably at least some of it was able to be based off existing work in all the various single-family HALs, too?
<firefrommoonligh>
Yep
<thalesfragoso[m]>
<firefrommoonligh "Sure, but... It's already more c"> I'm not trying to discourage you or anything, but this is a bold statement
<firefrommoonligh>
Yea - in hindsight I don't think I can back it up. I'm biased by my own use cases
<firefrommoonligh>
I take it back
<firefrommoonligh>
Some of the modules are fresh (usart, gpio, DAC, low_power, clocks, timers, flash). Some are copy+paste with minor mods (SPI, I2C, USB, QSPI, CRC, ADC)
delnoch[m] has joined ##stm32-rs
<therealprof[m]>
<henrik_alser[m] "Ps. therealprof I forgot it's an"> The mandatory pull-ups on the bus will reverse drive the LDO with a higher voltage than the output of the LDO.
<henrik_alser[m]>
<therealprof[m] "The mandatory pull-ups on the bu"> Yes i meant if you were using only the ones after the reg, either way it's only a 100uA or so so wouldn't upset the internal feedback divider too much
<therealprof[m]>
<dirbaio[m] "or maybe just due to how it happ"> That is exactly how it happened!
<henrik_alser[m]>
Connecting them before the reg would mean the maximum input voltage rating of the ssd1306 pins could be exceeded if running at 3V
<henrik_alser[m]>
But at 3.3V it should be fine anyway
<therealprof[m]>
Okay, I just did some measurements and of course that's exactly how it is done.
<henrik_alser[m]>
> <@therealprof:matrix.org> The mandatory pull-ups on the bus will reverse drive the LDO with a higher voltage than the output of the LDO.
<henrik_alser[m]>
* Yes i meant if you were using only the ones after the reg, either way it's only a 50-100uA or so so wouldn't upset the internal feedback divider too much
<henrik_alser[m]>
* But at 3.3V input it should be fine anyway
<henrik_alser[m]>
* But at 3.3V input it should be fine either way
<henrik_alser[m]>
(And in operation that excess current will be sinked by the ssd1306 anyway, so no reverse current should flow into the ldo output)
<henrik_alser[m]>
What’s on your benches today folks?
<korken89[m]>
Propietary radio ICs :D
<korken89[m]>
WIth an NDA so dense that they own me, my soul, my cat, my wife and all unborn children
<korken89[m]>
Now I just need to figure out how I can make an open source crate from it :D
<henrik_alser[m]>
Oh, that's unusually high? I'd expect an order of magnitude less?
<henrik_alser[m]>
Depends on formula and brand of course
<korken89[m]>
I see below 1 uA for 4.7 uF we ahve
<korken89[m]>
* I see below 1 uA for 4.7 uF we have
<korken89[m]>
But the 47 uA is weird
<henrik_alser[m]>
Ahh, so it's just 10 of those in parallel :P
<korken89[m]>
Haha nah
<korken89[m]>
X5R, 6.3V, 47uF
<henrik_alser[m]>
Internally i mean, haha
<korken89[m]>
Haha yeah maybe
<korken89[m]>
We will probably replace the cap the next production round
<korken89[m]>
But for now we have 300 units in the field at ~400m below ground
<korken89[m]>
Potted
<korken89[m]>
Not replacing there xD
<diondokter[m]>
UWB in the mines?
<korken89[m]>
Yeah
<korken89[m]>
That's what our company does
<diondokter[m]>
Cool!
<korken89[m]>
Submeter positioning
<korken89[m]>
* Submeter positioning in mines
<korken89[m]>
And mroe
<korken89[m]>
* And more
<diondokter[m]>
I see how that could be useful :D
<korken89[m]>
We position with what they have (like WiFi), but also have our own infrastructure for areas they want high accuracy :)
<diondokter[m]>
Sweet!
<henrik_alser[m]>
<korken89[m] "We will probably replace the cap"> Yeah i don't know how much better the X7R is in terms of leakage current... (I guess NP0 is out of the picture at those values haha)
<henrik_alser[m]>
Wow, cool stuff!
<korken89[m]>
I think we just got bad luch
<korken89[m]>
* I think we just got bad luck
<korken89[m]>
I took a random 47 uF that fit the specs
<korken89[m]>
Did not think about leakage then
<henrik_alser[m]>
Yes probably!
<korken89[m]>
Still was a Samsung or Kemet
<korken89[m]>
But... One should always measure
<henrik_alser[m]>
I’d guesstimated the insulation resistance to be in the range of 500Mohms.uf
<henrik_alser[m]>
So 10Megs or so for 47uF
<korken89[m]>
Yeah
<korken89[m]>
I think I got bad luck
<korken89[m]>
But one learns from ones mistakes
<korken89[m]>
Plus we just got a Joulescope
<korken89[m]>
So now I'm measuring everything I can xD
<henrik_alser[m]>
Woah!
<korken89[m]>
Best tool ever
<henrik_alser[m]>
Can imagine! I’m not in the low-power business (i waste Watts just to heat tube cathodes 😎) but being a guy from Småland i’m always interested in savings of course :P
<korken89[m]>
Hehe
<korken89[m]>
I'd like to try the Nordic power measurement board
<korken89[m]>
But it's nigh impossible to get
<diondokter[m]>
Seem like you'll get a chance on Mouser at least in the store that delivers to NL
<adamgreig-m>
definitely strong competition in this space, hah
<adamgreig-m>
I was looking at using bitvec in my jtag crate since i need to do a bunch of treating u8 arrays as single bit arrays, but it's such a huge dependency! i ended up just having my own 100-line bitvec mod https://github.com/adamgreig/jtagdap/blob/master/src/bitvec.rs
<korken89[m]>
Hehe, yeah I did something similar
<korken89[m]>
I hope we get native support
<korken89[m]>
diondokter: Sorry, I don't have time right now to try the PR.
<diondokter[m]>
Ok, np
<korken89[m]>
I'll try to give it a try tonight
<diondokter[m]>
:)
ServerStatsDisco has joined ##stm32-rs
<korken89[m]>
diondokter: Yoooo, I have another weird access question for `device-driver` :)
<diondokter[m]>
Go ahead :)
<korken89[m]>
So, when the command bytes are sent in a transaction, the chip in question responds with the status register at the same time (this is the only way to read the status register)
<korken89[m]>
Is there a way to always with all transations get this byte?
<korken89[m]>
The read/write_register does not seem to allow this
<diondokter[m]>
Not right now, no
<korken89[m]>
I'm wondering if I can put it in the `Ok()` part of the return
<korken89[m]>
It's currently not used
<dirbaio[m]>
you can store it in a variable in self and add a method to get it out
<korken89[m]>
Somehow
<diondokter[m]>
Hmmmm interesting. I guess this can come up more.
<dirbaio[m]>
so everytime you do some read/write the status reg is updated "as a side effect"
<korken89[m]>
<dirbaio[m] "you can store it in a variable i"> Neat idea
<diondokter[m]>
Also true
<dirbaio[m]>
and user can get it out anytmie
<dirbaio[m]>
* and user can get it out anytime
<korken89[m]>
This is actually fine as well :)
<korken89[m]>
Thanks! :D
<diondokter[m]>
Yeah, since it's a macro everything is generated as if it's your own structs and implementations. It's easy to add stuff to it
<korken89[m]>
Yeah, quite nice
<diondokter[m]>
I tested the Debug stuff as well by first adding it in manually and then shipping things over to the macro one by one
<korken89[m]>
:)
<korken89[m]>
I realized I'm way to used to proc-macros
<diondokter[m]>
Haha
<korken89[m]>
I can barely read macros-by-example anymore xD
<diondokter[m]>
I gotta learn that stuff at some point too
<korken89[m]>
Come join us in RTIC, experience in proc-macros guaranteed :D
<diondokter[m]>
lol
<diondokter[m]>
:D
<korken89[m]>
* Come join us in RTIC, experience in proc-macros guaranteed side-effect :D
<korken89[m]>
Hehe :D
<dirbaio[m]>
can confirm, proc macros are bad for your health
<diondokter[m]>
Well, these 'normal' macros too haha
<diondokter[m]>
What's actually the proper name of all the macros? Because there's the attribute style, the macro_rules! style without using macro_rules! to define it and the macro_rules! style with using macro_rules! to define it
<dirbaio[m]>
> macro_rules! style without using macro_rules! to define it
<dirbaio[m]>
wut, what's that?
<agg>
as in function-style proc macro
<agg>
the macro_rules! ones are called macros-by-example
<agg>
the procedural macros can be function-like, derive, or attribute
<dirbaio[m]>
last week while messing with defmt's proc macros I got into a state where rustc would exitcode 1, but not print any error message at all
<diondokter[m]>
<korken89[m] "diondokter: This was quite neat "> Yep, I decided that you should be able to access the raw data and construct from raw data.
<therealprof[m]>
Plus they're actually easier to debug once you've reached intermediate levels of macro complexity.
<dirbaio[m]>
how do you debug proc macros outputting bad syntax?
<dirbaio[m]>
`cargo expand` only works if the proc macro outputs good syntax
<diondokter[m]>
I know rtic just dumps the entire thing in the target folder
<dirbaio[m]>
all I can get is "huehue missing `;` somewhere in the macro output, fuck you`
<dirbaio[m]>
* all I can get is "huehue missing `;` somewhere in the macro output, fuck you"
<korken89[m]>
<dirbaio[m] "how do you debug proc macros out"> Experience ™️
<korken89[m]>
This is what 80% of my time with RTIC is
<diondokter[m]>
Wow, that's a very `C` answer XD
<korken89[m]>
The expansion helps though from RTIC
<korken89[m]>
You usually get a rust-analyzer error in the expanded file on the right line
<korken89[m]>
Usually
<dirbaio[m]>
oh hmm
<dirbaio[m]>
from inside the macro, you write the output to a file?
<dirbaio[m]>
that's a neat solution if your macro works on "top level" stuff because that stuff is parseable in its own file
<korken89[m]>
<dirbaio[m] "from inside the macro, you write"> Yes
<korken89[m]>
Quite nice "half expanded"
<korken89[m]>
Not as much as with `cargo expand`
<korken89[m]>
Usually the expanded file can be placed in a project and compiled as is as well
<korken89[m]>
If you build an RTIC project, check `target/rtic-expansion.rs`
<dirbaio[m]>
neat
<therealprof[m]>
Expanded macro-by-example code is a jungle as soon as you're doing more than just basic stuff.
<korken89[m]>
Unfortunately yes
<diondokter[m]>
I know 🤡
<therealprof[m]>
proc-macros are pretty much the same what svd2rust is doing... yeah, I'm aware you have an aversion to that...
<therealprof[m]>
The only really major annoyance is that it has to live in another crate...
<korken89[m]>
diondokter: One thing I realize from the expanded code, when I have a 1 bit value it is still going through `try_into()` for the `Bit` enum even though it can't fail. Does this potentially bloat?
<dirbaio[m]>
compiler should be able to optimize it out
<diondokter[m]>
It shouldn't
<diondokter[m]>
Can't wait for `!` to be stabilized
<korken89[m]>
Cool!
<dirbaio[m]>
you can use `core::convert::Infallible` as a replacement for `!`
<diondokter[m]>
It implements From and TryFrom is the auto implementation
<peauters[m]>
looking at the hal, I dont see the pwm constructors taking dma channels as an input
<peauters[m]>
is it possible to do it in the hal?
<peauters[m]>
* is it possible to do it in using the hal?
<peauters[m]>
any good place to start if I was gonna try and implement it from "scratch"
<thalesfragoso[m]>
<peauters[m] "any good place to start if I was"> The reference manual, probably
<peauters[m]>
thats where I went
<peauters[m]>
felt like I was staring into the abbys
<peauters[m]>
this is all because I mucked up my pcb design and the pin I assigned for writing to some addressable rgb LEDs, isnt on any of the spi peripherals
<peauters[m]>
but I remembered seeing someone control the leds using pwm
<peauters[m]>
but the timing was very tight, so they used DMA to set the duty cycles
<peauters[m]>
I think its doable, just gotta get my brain around it
dirbaio[m] has quit [Ping timeout: 245 seconds]
dirbaio[m]1 has joined ##stm32-rs
<peauters[m]>
alas I'm stumbling at "wtf implements StaticWriteBuffer"
<peauters[m]>
so Transfer::init on the stm32f4xx crate requires a peripheral, where the peripheral is PeriAddress + a vaild DMASet
<peauters[m]>
I can't work out where I get that peripheral
<thalesfragoso[m]>
<peauters[m] "alas I'm stumbling at "wtf imple"> Usually `&'static mut [u8; N]`, or a `Box` variant
<thalesfragoso[m]>
<peauters[m] "I can't work out where I get tha"> Probably a timer, but not sure if we added support for pwm timer
<peauters[m]>
<thalesfragoso[m] "Usually `&'static mut [u8; N]`, "> I eventually got there working back through the traits =o)
<peauters[m]>
<thalesfragoso[m] "Probably a timer, but not sure i"> so, I can see support for Mem -> Perph for the CCR registers of Timers
<peauters[m]>
i.e `impl DMASet<Stream6<DMA1>, Channel3, MemoryToPeripheral> for CCR2<TIM2>`
<thalesfragoso[m]>
Great, there you go
<peauters[m]>
so after reading the manual, that seems to be how you would set the duty cyces
<peauters[m]>
cycles
<thalesfragoso[m]>
That was a bug where those CCR weren't pub, not sure if I fixed that already, maybe
<peauters[m]>
but the Pwm traits dont have any "with_dma" on them afaict
<peauters[m]>
they're structs in dma::trait
<peauters[m]>
which is where I'm confused
<thalesfragoso[m]>
Just a few peripheral abstractions have DMA support
<thalesfragoso[m]>
Timer/pwm isn't one of them
<thalesfragoso[m]>
You will need to use the pac
<peauters[m]>
I'm happy to have a go at adding them
<peauters[m]>
read hacking until something kinda works
<thalesfragoso[m]>
Great, and I will happily review them :)
<firefrommoonligh>
Please do. I've dodged it because it seems tough. The RMs have some guidance on a per-peripheral basis
<peauters[m]>
i had a look at some of the other hals but they seem a little different
<peauters[m]>
if anyone fancies giving me a little direction, I'll poke at it a bit and see if I can get somewhere close
<firefrommoonligh>
L4xx hal has it for USART only (AFAIK), and it's been described by people who know it better than I as unsound
<firefrommoonligh>
I just built a new USART mod since modding the existing DMA ones was beyond my level
<firefrommoonligh>
* I just built a new USART module since modding the existing DMA ones was beyond my level
<thalesfragoso[m]>
<firefrommoonligh "L4xx hal has it for USART only ("> It just need a drop impl
<thalesfragoso[m]>
But yeah, unsound, but relatively easy to fix
<peauters[m]>
ha, was just looking a the stm32f1xx hal at the serial impl and last commit is by you thalesfragoso
<peauters[m]>
=o0
<peauters[m]>
* =o)
<thalesfragoso[m]>
Hope I didn't break something, but the dma implementation on the F4 is considerable different than F1
<peauters[m]>
thats what I'm seeing
<thalesfragoso[m]>
Yeah, I went overboard on that one
<peauters[m]>
do you know who I can reach out to to ask about it?
<thalesfragoso[m]>
Generics everywhere
<thalesfragoso[m]>
Maybe me, although I haven't played with pwm plus dma
<peauters[m]>
which is the best impl on the f4xx crate to look at for an example of using dma?
<thalesfragoso[m]>
There are exactly two drivers using DMA, ADC and USART
<thalesfragoso[m]>
But they were kinda easy, just a couple of lines, the DMA driver was made with that in mind
<thalesfragoso[m]>
To handle the maximum things related to DMA
<thalesfragoso[m]>
So others drivers just need to enable a DMA bit and implement the PeriAdress + DMASet for the HAL type
<thalesfragoso[m]>
Unfortunately, for pwm you have 4 channels inside one single type
<thalesfragoso[m]>
So you would need to somehow separate them without running into data races
<thalesfragoso[m]>
If you don't separate them, then you would be able to use just one channel (versus 4)
<thalesfragoso[m]>
* There are exactly two drivers using DMA: ADC and USART
<peauters[m]>
1 is better than none?
<thalesfragoso[m]>
It's a start :)
<peauters[m]>
thanks for your time. its a bit late in the uk, so will have to take a look in the morning
<peauters[m]>
if its ok, I might ping a few questions at some point next week
<thalesfragoso[m]>
No problem, feel free to ask anything :)
<peauters[m]>
cheers, have a good weekend
<firefrommoonligh>
Do any STM32 HALS use DMA beyond USART and ADC?
<firefrommoonligh>
Does anyone know why some periphs (eg USART, DAC) registers are described as `DAC_CR` etc, while others (eg SPI, GPIO) are described as `SPIx_CR` ? When both have a sep reg block per periph. Ie there's still `USART1`, `USART2` periphs and reg blocks.
<firefrommoonligh>
* Does anyone know why some periphs (eg USART, DAC, I2C) registers are described as `DAC_CR` etc, while others (eg SPI, GPIO) are described as `SPIx_CR` ? When both have a sep reg block per periph. Ie there's still `USART1`, `USART2` periphs and reg blocks.