<JamesMunns[m]>
diondokter[m]: that's the great thing about ub! sometimes it does work!
<JamesMunns[m]>
it might just give you bizzare-ass nonlinear adc readings!
<diondokter[m]>
No, the readings are very good haha
<JamesMunns[m]>
at room temperature? :p
<diondokter[m]>
That's true!
<diondokter[m]>
Fine. I'll change the clock haha
<dirbaio[m]>
ADC overclock ⚡️⌛️⚡️
nadja has quit [Server closed connection]
nadja has joined #rust-embedded
<JamesMunns[m]>
Reading STM32G0-Analog-ADC-ADC.pdf, the ADC is a "Successive-approximation ADC", but basically it means it takes the input, charges a capacitor, then samples and holds that. It seems that the "too quick" sample time failure mode only presents with high-impedance signals. If you're plugging something relatively low resistance into the ADC, it'll read fine. If you have it though a huge voltage divider (like to read a battery
<JamesMunns[m]>
voltage), it might read low if you don't give it enough capture time.
<JamesMunns[m]>
so like, if you are reading between a 2k/5k voltage divider (or like just direct from a PSU), overclock away! If you run it between a 200k/500k voltage divider, you might not collect enough coloumbs and read too low of a value.
<diondokter[m]>
Hmmm yeah. Well in my situation so far it was a 0-60v signal through a 120/10k divider
<diondokter[m]>
Working on my induction heater. That voltage is gonna go up later when I'm not scared of blowing up another IGBT :P
<diondokter[m]>
So might be fine yeah
<JamesMunns[m]>
oh wow, this slide tells you what IP they use for the ADCs
<JamesMunns[m]>
and lots of the USB IP is synopsis too
<diondokter[m]>
The 'or' is there because I don't remember which one
<diondokter[m]>
The one that does LoRa
<dirbaio[m]>
ah, wl then
<JamesMunns[m]>
I was having trouble figuring out some of the allwinner D1 drivers, until I realized their USB OTG IP was all from mentor graphics, which has lots of leaked docs
<mameluc[m]>
wl series uses SX126x to be exact
<dirbaio[m]>
they just glued a semtech SXsomething. you talk to it via an on-die SPI even, with the same protocl you'd talk to a discrete SXsmoething 🤪
<dirbaio[m]>
didn't even try to connect it to an APB like a real peripheral 🤪
<diondokter[m]>
Yeah, I've done lora in 2017-2019 with an SX1276. Pretty nice chips though!
<diondokter[m]>
But I have no clue why they have so many variants. They're all pretty much the same! Even chips meant for the same frequency band
firefrommoonligh has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
JamesMunns[m]: Yeah, I guess this just means the ADC is fabbed on 90nm TSMC nodes, tho "TSMC090 ADC" does show a lot of research papers and some synopsis IP references, haven't gone to check the verilog to see if it looks remotely like the STM32G0 one tho
<mameluc[m]>
first time using stm32 for me and I happened to get in to the stm32wl chip. Basically m0+ and m4 cores, some trippy peripherals and a semtech chip glued together. Idk how common it is to have two cores like that
<diondokter[m]>
Ok, final sample speed ends up being 2285714.5 without overclock (but with a 32mhz synchronous clock)
<diondokter[m]>
Most STM chips are single core
<JamesMunns[m]>
mameluc[m]: not uncommon, especially for a lot of radio processors
M9names[m] has joined #rust-embedded
<M9names[m]>
Fairly common for chips with wireless comms to have 2 cores, allows vendors to run a blob without having to care as much about how it impacts user code
<mameluc[m]>
ah thats why
<dirbaio[m]>
yeah, nrf52 doesn't do the two cores thing and it's a bit of a pain
<mameluc[m]>
there is also some trickery to hide the keys without a secure element
<dirbaio[m]>
guess that's why they added the 2nd code in the nrf53
<JamesMunns[m]>
dirbaio[m]: and they totally started doing it for nrf53 + nrf91
<dirbaio[m]>
nrf91 also so they can make their IP unreversengineereable
<JamesMunns[m]>
tho all the old "M4+M0" cores I saw were *cursed*, like they had very little coherency between cores, and it's not like the m0 can do atomics for synchronization
<JamesMunns[m]>
but yeah, they generally expect you to run their blob(s) on the m0 core, and use their staticlibs to handle talking to them, good luck if you decide not to do that.
<mameluc[m]>
makes sense for stuff that is more complicated than jiggling some spi
<dirbaio[m]>
except if the blob is C
<dirbaio[m]>
and assumes you run a RTOS
<dirbaio[m]>
so they fail to give you nonblocking APIs
<dirbaio[m]>
(looking at you Nordic)
<JamesMunns[m]>
yeah, that's pretty common for vendors
<JamesMunns[m]>
the only supported use case is "copy and paste our sample project then tweak a few things, but not too much"
<mameluc[m]>
without vendors our jobs would be so much nicer. Id probably be a carpenter