<firefrommoonligh>
Presumably all the USART interrupt types fire on the main `USART1` interrupt handler, right?
<wallacejohn[m]>
firefrommoonlight: Yeah; you usually just check which specific interrupt fired in the status register.
<firefrommoonligh>
Hmm. It looks like the `USART1` interrupt isn't firing at all.
<wallacejohn[m]>
Enabled in NVIC + enabled in the UART interrupt enable bit?
<firefrommoonligh>
Yep. Hmm. More narrowing-down. I can get the RXNE bit to fire. It may have to do with the char it's recognizing for the CMIE bit
<firefrommoonligh>
* Yep. Hmm. More narrowing-down. I can get the RXNE interrupt to fire. It may have to do with the char it's recognizing for the CMIE bit
<firefrommoonligh>
The field you set it with is weird; set up at 3:0 and 7:4 in ref manual, but 7, and 6:0 in PAC
<adamgreig-m>
which stm32 and field is that?
<adamgreig-m>
ADD in USART_CR2 on L4x2?
<firefrommoonligh>
l4, and USART_CR2 ADD
<firefrommoonligh>
I just read the reg: It's not getting set
<adamgreig-m>
the split in the RM doesn't seem relevant, it occupies bits 24 to 31 contiguous
<firefrommoonligh>
(Even though I'm disabling the RE bit and waiting for it to clear before attempting)
<adamgreig-m>
I think the only reason the RM splits it is because the two halves are sometimes used in different modes?
<firefrommoonligh>
Ie, both teh `add`, and `addm7` fields aren't taking effect, which explains the lack of interrupt firing
<firefrommoonligh>
Oh wow, that threw me for a loop!
<adamgreig-m>
it's just merged ADD[0:3] and ADD[4:7] which are contiguous
<firefrommoonligh>
I can now see that ADDM7 is something diff in RM
<adamgreig-m>
in fact it looks like ADDM7 is to toggle between using all of ADD or only ADD[7:4]
<firefrommoonligh>
Oh nice!
<adamgreig-m>
so the whole 8-bit ADD field is in the right place and just the RM splits it to show you which half is used when ADDM7 is 0
<adamgreig-m>
but if ADDM7 is set to 1, the whole ADD field is used
<adamgreig-m>
that might be why your writes are not going through? not sure though, seems like it should still save them
<firefrommoonligh>
Hmm... The write goes through with `ue` cleared, but not `re` (only) cleared
<firefrommoonligh>
Althouigh RM specifies either is fine. Going to clear `ue` before setting and not worry about that yet... and your note about ADDM7 may very well come up here; I think I need the 7 bits!
<firefrommoonligh>
Thank you very much. I think I'm still doing something wrong as it's not firing, but you just cleared up several misconceptions that were also causing it not to work
<firefrommoonligh>
I feel good about the ADD and ADDM7 setting code now
<adamgreig-m>
weird that it's not going through unless UE is cleared though
<firefrommoonligh>
Yea...
<firefrommoonligh>
Just changing the bit I'm clearing adn checking from `re` to `ue` causes it to take
<firefrommoonligh>
Got it working - the issue was on the device I was talking to's end!
<peauters[m]>
next up will be adding rotary encoders, LEDs and then a case
<TeXitoi[m]>
cases are overrated
<peauters[m]>
lol
<agg>
doesn't look like there's much that could be wrong with sda/scl on the pcb...
<agg>
have you used a multimeter to check continuity from the solder of the pin on the top of the blackpill to the solder of the pin on the oled?
<agg>
you had it working using internal pullups on a breadboard, right?
<peauters[m]>
yup
<peauters[m]>
* yup to both
<peauters[m]>
also, not working on both backpills I socketed
<agg>
definitely not something silly like swapping clock and data around going to the oled?
<agg>
seems like it should just work :/
<peauters[m]>
I don't know enough about PCB design to know if i screwed something up with having the ground pour close to the lines, or not matching the trace length (didn't think it was needed for slow stuff like this)
<agg>
it's not, your pcb should be totally fine for i2c
<peauters[m]>
double checked, but will check again
<therealprof[m]>
I had a quick glance at your firmware. Just curious since there're so many empty functions... are sure you're actually sending raster data to the display? 😅
Mathias[m] has quit [Quit: Idle for 30+ days]
<peauters[m]>
yer, it works on the bread board
<henrik_alser[m]>
Depending on how long you run your traces, trace width and pcb stackup your capacitance to ground will be higher than your flying leads hookup. I know this is a hot topic around here haha, but in my experience, using the internal 40k pullups is too slow for these speeds to be reliable, i did some measurements recently on a minimal hookup that didn’t work, which confirmed the math, but @therealprof reportedly nev
<henrik_alser[m]>
had a single problem using them so your mileage may vary... 🤷🏻♀️ Would be nice to see a scope picture of those waveforms to see if this could be an issue, or if you can solder in some external pullups just to verify this is not the problem
<peauters[m]>
i tried hooking up a scope yesterday, but I must say I was a bit lost
<peauters[m]>
I'd need a 4k2 from 3v3 to scl and a seperate one to sda?
<henrik_alser[m]>
Anything in the range 1k-10k would do fine
<peauters[m]>
its worth a try for sure
<peauters[m]>
lemme break out the iron
<henrik_alser[m]>
I usually go with 2k2 if i don’t need to save battery
<peauters[m]>
cool, will do
<peauters[m]>
and disable the internal pull ups?
<firefrommoonligh>
We've had chat about internal vs external PUs on I2C lines a few times recently. Bottom line: It will probably be fine either way, although you may run into issue at high speeds if using internal, and you need to consider the consequences of what happens to devices on the line when the MCU is off
<firefrommoonligh>
agg helped me with an issue where a datasheet explicitly recommended NOT having any PU on the SCL line, and leaving it PushPull, although this won't work if any device on the line needs clock stretching
<firefrommoonligh>
* agg helped me with an issue where a datasheet explicitly recommended NOT having any PU on the SCL line for low-power modes, and leaving it PushPull, although this won't work if any device on the line needs clock stretching
<henrik_alser[m]>
<peauters[m] "and disable the internal pull up"> It doesnt matter if you leave them on
<henrik_alser[m]>
(Internal vs 2k2 for ~30pf bus capacitance approx)
<firefrommoonligh>
Btw, STM32s in stop mode will keep their PU state - not sure about standby etc
<agg>
(fwiw i'm with henrik_alser[m] here; i always put external pullups for i2c, the internals are too weak and poorly specified, even if it does work in some cases)
<korken89[m]>
We run only the internal ones in our products xD
<korken89[m]>
100 kHz
<korken89[m]>
So far no problem hopes it wont bite
<peauters[m]>
so, I stuck a 2k2 from 3v3 to scl and another to sda
<peauters[m]>
still no luck
<peauters[m]>
logic analyser just shows both lines go high and dont go low at all
<peauters[m]>
so I broke out the scope, but this will be my first time trying to debug with it
<henrik_alser[m]>
Oh it doesnt even clock out the address or what?
<peauters[m]>
got the gnd lines to gnd and one probe on the resistor connected to scl (on the scl side) and another on the sda
<peauters[m]>
nope nothing henrik_alser
<peauters[m]>
it makes me think there is a short between 3v3 and the scl, right? but I've checked every solder joint and everything looks ok
<henrik_alser[m]>
And you checked the connection of 3v3 and GND between the oled and the blackpill?
<peauters[m]>
yep, but let me try again
<peauters[m]>
yep, they are good
<peauters[m]>
and if I measure voltage across gnd and vcc on the oled, I get 3v3
<peauters[m]>
and the same for scl and sda
<henrik_alser[m]>
Ok! And if you ohm check between scl/sda and 3v3? No short?
<peauters[m]>
1.5K between scl and 3v3, same on sda and 3v3 (checking at the oled pins)
<peauters[m]>
no continuity
<henrik_alser[m]>
Where do you connect the GND probe when you mesure 3v3? At the oled? Not at the blackpill?
<peauters[m]>
at the oled
<henrik_alser[m]>
Ok
<henrik_alser[m]>
And triple checked the pinout?
<agg>
you could try changing the firmware to use those pins as a normal gpio output and just toggling them high/low with a delay in-between
<agg>
then you can use the scope to check the voltage at the oled does go high/low
<agg>
(for bonus points, set the pins to open-drain-output instead of push-pull-output and check that works)
<peauters[m]>
applies head to desk violently
<peauters[m]>
i believe I've found the problem
<peauters[m]>
I'm so super dumb
<firefrommoonligh>
Me too bro
<peauters[m]>
on my bread board i was using pb8/pb9. I thought I had setup up the bb the same as the pcb
<peauters[m]>
but, alas the pcb is set up for pb6 and pb7
<agg>
oh noooo
<agg>
at least that should be an easy fix
<peauters[m]>
yep
<peauters[m]>
thanks so much all
<peauters[m]>
sorry it turned out so benign
<henrik_alser[m]>
It’s usually the most obvious thing that is the hardest to find haha
<peauters[m]>
IT WORKS!!!!
<peauters[m]>
hurrah
<peauters[m]>
thanks again all
<peauters[m]>
😁
<TeXitoi[m]>
photo with oled working please!
<peauters[m]>
will do, just putting header back on the other board so I can get both
<firefrommoonligh>
Not surprised - I don't think anyone was based on how the chat reverted to checking for shorts on the board etc. I've found when it looks like I'm doing everything right, but have no contact from a periph or bus, it's usually something like this
<firefrommoonligh>
In my case, the root cause is often a bad solder job etc
<therealprof[m]>
Good enough for me. That's my MCUmeter with two devices hooked on the I2C bus and builtin PUs on a STM32F042.
<therealprof[m]>
The timings could use a bit of tweaking though, they don't seem ideal. Unfortunately the F0 I2C peripheral has a ton of knobs to tune the timings.
<henrik_alser[m]>
Interesting! Looks more like my 10k curves did... Sure none of the devices have pullups on board?
<therealprof[m]>
Very sure.
<therealprof[m]>
One is a TI INA260. "Both SCL and SDA connect to the bus and require external pullup resistors.". The other is a SSD1306. 😉
<agg>
looks like about one time constant in 200ns, with 80k pullup that's a bus capacitance of 2.5pF which seems unusually small
<agg>
tricky to measure these things directly though
<henrik_alser[m]>
Is it 500ns per division? With 40k pullups i get it to be like 12pf total? Super strange, the scope alone would be 9.5pf and most device pins usually around 10pf each last time i checked?
<agg>
1µs/div
<agg>
I was doing 63% of 3.3v for 2v, 1v/div, looks like about 1/5 of a time division for 2v?
<agg>
with 4k7 pullup it would be 42pF bus capacitance
<agg>
or three pins and a probe...
<henrik_alser[m]>
Ahh, haha i was looking at the meaured rise time 635ns, (10-90%) but maybe it’s not the one displayed
<agg>
could be 10-90% rise time
<henrik_alser[m]>
Either way i don’t understand how it’s possible
<henrik_alser[m]>
But glad it works!
<agg>
maybe the ssd1306 pcb has some pullups onboard? the adafruit ones do afaict
<therealprof[m]>
Yes, it's 10-90%.
<therealprof[m]>
Nope, no pull-ups. I just double checked.
<agg>
datasheet says "all pins except for PA10" are 30-50kR, and PA10 is 7-14kR
<henrik_alser[m]>
Wow, so that’s 8pf, lower than the 10x probe
<henrik_alser[m]>
Or using active probe?
<henrik_alser[m]>
Or coax 21:1?
<therealprof[m]>
WYSIWYG, it's all in the picture. 😉
<agg>
i make it less still, it's going 2V in 200ns from a 3v3 supply through say 40kR, 5pF?
<agg>
second pic is 500ns/div
<henrik_alser[m]>
Haha i believe you, just trying to understand
<henrik_alser[m]>
Why it does not compute 🤔
<agg>
i only have an spi oled to test with i think, hmmmm
<henrik_alser[m]>
All my oleds have 10k onboard so cant try either
<agg>
I guess just a blackpill with nothing hooked up to its i2c at all should do it too
<agg>
my passive probe is 11pF tho, hm
<therealprof[m]>
So you want me to go back to the basement and fire up all the stuff again, is that what you're saying? 😅
<agg>
what i would be really interested in seeing is the same waveform with only the stm32 and the ina connected, no oled
<agg>
but i can basically do that myself
<agg>
i have a blackpill here at least, presumably can make it just keep trying to do an i2c read with nothing connected
<henrik_alser[m]>
My scope pictures above was into a single dac i2c control interface
<therealprof[m]>
That'd be easy to achieve since the display is plug-in.
<agg>
would certainly be interesting, if anything removing the display should decrease the capacitance so make it charge even faster
<agg>
gotta run for dinner, will have a play with a blackpill by itself later this evening
<agg>
nice distraction from the exactly 1000 unrouted nets in this pcb :/
<therealprof[m]>
LOL or not. Firmware doesn’t like devices not responding…
<therealprof[m]>
But I triple checked, there're no passive PUs on either of the SSD1306 displays (I checked 4). If anything it would have to be an active PU managed by the chip.
<agg>
Ah, foiled by i2c naks
<agg>
Makes sense for the oleds to not have pull-ups but does mean the whole thing is very confusing...
<agg>
Presumably if the stm32 was accidentally driving push-pull it would be way way faster than this, too, so that doesn't seem likely (plus of course the code sets open drain)
<henrik_alser[m]>
In spice it looks just like my measurement 🤔
<therealprof[m]>
SSD1306 datasheet also says: "Both the data and clock signals must be connected to pull-up resistors."
<henrik_alser[m]>
What a baffler!
<peauters[m]>
hi all
<peauters[m]>
back again
<peauters[m]>
soldered the headers back on the other side of the keyboard, stuck a oled on it, booted it up and getting BusWriteError again =o(
<peauters[m]>
hooked up a logic analyser and I can see the data being sent and acks.
<peauters[m]>
looked at the init code and afaict its getting all the way through sending the data, it even goes on to send more, but the result seems to be from init
<peauters[m]>
i r confused
<peauters[m]>
from what i understand i2c has acks built in, and the LA is showing data + ack
<peauters[m]>
crisis over, reflowed some joints and it seems fixed for now
Sijmen has quit [Ping timeout: 245 seconds]
Sijmen has joined ##stm32-rs
adamgreig-m has quit [Ping timeout: 245 seconds]
BobMcWhirter[m] has quit [Ping timeout: 245 seconds]
adamgreig-m has joined ##stm32-rs
BobMcWhirter[m] has joined ##stm32-rs
<henrik_alser[m]>
therealprof: Did you ohm it between the SCL/SDA and Vcc pin headers or at the actual SSD1306 Vcc line, after the LDO (if it has one)? The pullups on the oled modules i've seen are usually connected after the regulator...
<firefrommoonligh>
I just followed the recipes in the RM. Doesn't use DMA
<firefrommoonligh>
Should work on any STM32. I'm still confused about the various EH methods
<firefrommoonligh>
This just reads to and writes from u8 arrays
<firefrommoonligh>
* Should work on any STM32. I'm still confused about the various EH methods, nb etc.
<dirbaio[m]>
on any? how
<dirbaio[m]>
USARTv1 and USARTv2 are completely different
<firefrommoonligh>
Ah fuck you're right I jumped the gun
<firefrommoonligh>
Failing to compile on G0 PAC
<firefrommoonligh>
probalby others 2
<firefrommoonligh>
I'll ref that spreadsheet
<firefrommoonligh>
I used teh L4 RM to build it
<dirbaio[m]>
that's usartv2 :)
<firefrommoonligh>
It was pretty simple though. The complexity of the stm32yxx hal serial modules is mainly in DMA, TSP, and EH-related stuff
<dirbaio[m]>
unfortunately async without DMA sucks, I'll have to suck it up and do DMA 🤪
<firefrommoonligh>
Actually these changes look like minor feature-gating. Ie the failures on G0 were minor
<dirbaio[m]>
and there's also USARTv3 which adds a PRESC reg and some more interrupt flags :P
<firefrommoonligh>
There are already a fuckload of interrupt flags. no more lps
<dirbaio[m]>
not sure if you can completely ignore the PRESC.. :S
<firefrommoonligh>
This is solvable
<dirbaio[m]>
and for USARTv1 you'll have to write a completely different driver
<dirbaio[m]>
F4 is USARTv1
<dirbaio[m]>
it's fun shit
<firefrommoonligh>
Going to skip that
<therealprof[m]>
<henrik_alser[m] "therealprof: Did you ohm it betw"> The pin headers. It would be weird if it pulled up the I2C lines to a locally generated voltage but I haven't checked that.
<henrik_alser[m]>
Pulled one out of the drawer, it has the 4k7 pullups R6 R7 connected there after the regulator
<therealprof[m]>
But if there's a LDO it has at least 0.3V drop so I can only pull-up to 3V at best.
<firefrommoonligh>
Btw, let me know if you need a schematic or anything for making the PCB
<firefrommoonligh>
dirbaio: now the suart works on usartv3. Although maybe need to set the prescaler, or leave it at default of 0
<dirbaio[m]>
cool
<therealprof[m]>
And it would reverse feed the LDO and some really don't appreciate that...
<dirbaio[m]>
btw: are you going to configure/check AFs in the future? or leave up to the user to configure the pins like right now?
<firefrommoonligh>
Let the user do it
<dirbaio[m]>
interesting
<firefrommoonligh>
I appreciate the value in compile errors for misconfig, but it's not worth the extra complexity in both user and HAL code
<firefrommoonligh>
*Complexity, and lack of flexibility
<firefrommoonligh>
There are so many issues that crop up on teh HALs regarding not being able to do something on GPIO that should be easy
<firefrommoonligh>
I appreciate compile errors for catching subtle memory issues etc, but the user should have some concept of how to configure pins, or be able to C+P examples at least
<dirbaio[m]>
on embassy I was thinking of doing AF config automatically, but also let the user pass in a "PhantomPin" or something indicating "assume this pin is in use, but I'll configure it myself"
<firefrommoonligh>
As in, the periphs config the GPIOs?
<henrik_alser[m]>
Yeah the ssd1306 usually run at 3V and logic hi is 0.8*Vdd = 2.4V
<henrik_alser[m]>
Many use a reverse current protection diode, although most are fine with sinking a couple mA in my experience
<dirbaio[m]>
the HAL knows which AF is needed to use PD9 for TX so it'd set the AF automatically
<firefrommoonligh>
I considered that, but ultimately decided not to due to wanting pin config to be explicit in user code. Ie automatically doing it would make exceptions tough
<dirbaio[m]>
no need to do .into_alternate() blah
<firefrommoonligh>
For example, there isn't just one right way to config a pin, even if a majority of cases are the same
<firefrommoonligh>
Your code is more concise for the user and works in most case, but I don't like hiding it
<dirbaio[m]>
what multiple ways to config the TX pin would there be?
<dirbaio[m]>
pushpull vs opendrain?
<firefrommoonligh>
There isn't. But there is in I2C!
<firefrommoonligh>
I'm going for consistency and explicitness
<firefrommoonligh>
Although I don't dislike your idea the way I dislike the traditional TSP way
<firefrommoonligh>
I think having the periph config is fine, I just chose the other option
<dirbaio[m]>
what are the multiple ways in i2c?
<dirbaio[m]>
(the config struct is so that I can add new config options without breaking changes)
<firefrommoonligh>
This lets the device not leach power from the SCL pin in sleep mode
<firefrommoonligh>
Although in the majority of cases, you will config OpenDrain
<firefrommoonligh>
(SCL is left at default of PP)
<firefrommoonligh>
And as discussion here shows, there's mixed opinions on hardware vs internal PUs
<dirbaio[m]>
oh, huh yeah
<dirbaio[m]>
well I was planning on stashing these in Confihg
<dirbaio[m]>
* well I was planning on stashing these in Confg
<dirbaio[m]>
* well I was planning on stashing these in the Config
<firefrommoonligh>
Another reason I'm not auto-configuring: I'm letting the UART struct and module just deal with the USART reg block; GPIO just deal with GPIO block (and a bit of EXTI and SYSCFG)
<dirbaio[m]>
for example if you want to do opendrain uart, you'd have a field in Config for that
<dirbaio[m]>
defaulting to PushPull
<firefrommoonligh>
Yeah - your approach is fine too
<dirbaio[m]>
it's true it mixes gpio with uart 🤷♂️
<dirbaio[m]>
the design is more like
<dirbaio[m]>
hat does the user want? an uart on PD9 and PD10, so give them exactky that
<dirbaio[m]>
* hat does the user want? an uart on PD9 and PD10, so give them exactly that
<dirbaio[m]>
with advanced stuff in Config that the user can touch if desired, or just use the defaults
<dirbaio[m]>
the user doesn't care about AFs
<firefrommoonligh>
You're right - your approach results in cleaner user code. You might sway me eventually
<dirbaio[m]>
the user doesn't care that EXTI needs to write to SYSCFG regs, so no stuff like `&mut syscfg` required
<dirbaio[m]>
the user doesn't care how GPIO regs are organized, so no need to split ports. Pins come already split in Peripherals
<dirbaio[m]>
and no `&mut rcc` to split a port either
<dirbaio[m]>
this is all ultra WIP, that USART example is just a stub testing that the trait shenanigans are possible 😂
<dirbaio[m]>
but I'm hopeful
<firefrommoonligh>
I'm mainly working on this HAL for my own projects, since the yxx ones are thoroughly unusable. And would like to be able to change MCUs on my projects, start a new project with a new MCU etc without changing all the code
<firefrommoonligh>
But also would like to make it so others have an easy time; will make the project more robust over time
<firefrommoonligh>
* I'm mainly working on this HAL for my own projects, since the yxx ones are unusable. And would like to be able to change MCUs on my projects, start a new project with a new MCU etc without changing all the code
<dirbaio[m]>
throughly unusable ☠️
<firefrommoonligh>
* I'm mainly working on this HAL for my own projects, since the yxx ones are thoroughly unusable. And would like to be able to change MCUs on my projects, start a new project with a new MCU etc without changing all the code
<firefrommoonligh>
It sounds like your motivation is async?
<dirbaio[m]>
well for embassy the problem is they're different to each other
<firefrommoonligh>
As in, you need to be able to unify HALs to make them work with async?
<dirbaio[m]>
no
<dirbaio[m]>
it can work on top of the HALs
<dirbaio[m]>
at least as long as they have good DMA support which f4 does
<dirbaio[m]>
but I don't want to write embassy-stm32f4, embassy-stm32f7, embassy-stm32h7, embassy-stm32l0, embassy-stm32l4, embassy-stm32g0...
<dirbaio[m]>
with tons of "copypaste everything then change little things"
<dirbaio[m]>
and also many hals are written with ubermacros, which forces embassy to use macros too
<firefrommoonligh>
Makes sense
<firefrommoonligh>
I think your approach may be the best for that situation
<firefrommoonligh>
Our goals are different, but we end up doing a lot of overlapping work. Unfortunately, I don't think there's much code-sharing we can do, since your work on cross-MCUing is PAC level, where mine is HAL-level. Does that sound right?
<firefrommoonligh>
We do have a lot of API-design overlap though, ie ideas and approaches
<dirbaio[m]>
yea kindof
<dirbaio[m]>
the PAC stuff is so that the need for #cfg and macros is reduced in the HAL
<dirbaio[m]>
there'll still be some
<dirbaio[m]>
and there's going to be code generation in the HAL too
<dirbaio[m]>
all the peripherals and Instance impls and the GPIO AF maps
<dirbaio[m]>
* because writing these by hand sucks
<firefrommoonligh>
It's long, but explicit
<dirbaio[m]>
it's all autogenerated from the stm32-data yamls, so who cares if it's long :D
<firefrommoonligh>
Those `paste` and `cfg_if` blocks I use are kind of messy and tough to read, but beat the alternative of DRY across multiple repos, crates, and teams
<dirbaio[m]>
if you used consistent PACs you wouldn't need those :)
<dirbaio[m]>
but agree it's still better than copypasting code across 10 hals 😂
<firefrommoonligh>
Or going through 10 maintainers all with different amounts of avail time, philosophies etc
<firefrommoonligh>
It's impossible
<dirbaio[m]>
yea :(
<firefrommoonligh>
I'll use your PAC if you can pull it off
<henrik_alser[m]>
(therealprof: Also in this case it's not a steady DC reverse bias current - with a 10uF output bypass cap vs the 4k7 "feeding" resistor, that 400kHz waveform will be attenuated like 100dB)
<henrik_alser[m]>
Ok time to sleep over here, gn8 folks! Thanks for today
<henrik_alser[m]>
* (therealprof: Also in this case it's not a steady DC reverse bias current - with a 10uF output bypass cap vs the 4k7 feeding resistor, that 400kHz "ripple" will be attenuated like 100dB at the regulator's output node)
<adamgreig-m>
dirbaio: sounds very nrf-y, instead of having loads of different config options inside each peripheral to control how it sets up the gpio, why not just let the user set up the gpio :p
<dirbaio[m]>
because 99% of the time you want PushPull UART TX
<dirbaio[m]>
and OpenDrain I2C SDA/SCL
<dirbaio[m]>
for advanced usecases you have the PhantomPin escape hatch
<dirbaio[m]>
it's like the h7-hal's new_unchecked. Inits the peripheral assuming the user will configure the pins :)
<dirbaio[m]>
and if it's a sufficiently common advanced usecase it can be put in the Config struct
<adamgreig-m>
yea, I guess that sounds fair enough as a compromise
<dirbaio[m]>
with PhantomPin you can do your crazy "switch pins between SPI and GPIO fast without reinitializing SPI" hack :)
<adamgreig-m>
stm32f411 on blackpill with internal pullups, probing the i2c scl pin directly
<henrik_alser[m]>
Ps. therealprof I forgot it's an open drain configuration, so actually it won't reverse bias the regulator at all since it never drives the pin high
<henrik_alser[m]>
Yeah that looks reasonable adamgreig
<adamgreig-m>
at 400kHz it seems you'd be lucky if it worked at all
<henrik_alser[m]>
Yeah that's been my experience too, and resistors are cheap so...
<adamgreig-m>
but it's maybe just creeping about the VIH threshold in time, so perhaps it would be ok if no one touches the bus lines :P
<adamgreig-m>
really want to buy a fancier probe one day, which they didn't cost more than a sensible oscilloscope
<adamgreig-m>
* really want to buy a fancier probe one day, wish they didn't cost more than a sensible oscilloscope
<adamgreig-m>
i lost a good ebay auction in the uk for one a few weeks ago and regret not bidding higher
<henrik_alser[m]>
Have you tried a DIY coax with 1k input terminated into 50 ohms?
<henrik_alser[m]>
21:1
<adamgreig-m>
no, though I have been meaning to try it out
<henrik_alser[m]>
Works a charm
<adamgreig-m>
I'd quite like one that's AC coupled and 1:1 for measuring power supply noise too
<adamgreig-m>
my scope frontend isn't sensitive enough to see the noise through a 21:1 probe :p
<adamgreig-m>
(I mean ideally I'd like one of the fancy power rail probes... there was an interesting article on making one yourself a while back, it doesn't look especially hard but I think the devil is in the details)
<adamgreig-m>
(would be nice to have it integrate with my scope so the scope controls the offset voltage too instead of having to use a pot or something...)
<adamgreig-m>
do you solder it in or use a little pth resistor as a probe tip or what?
<henrik_alser[m]>
Yeah i use it as a probe tip (as described in the Howard Johnson book)
<adamgreig-m>
i should try making one that plugs into the sensepeek pcbite arms
<adamgreig-m>
hmm, wonder if i could use the coax that comes with their probes
<adamgreig-m>
presumably it's the lossy type you make rc probes out of... hmm
<henrik_alser[m]>
For power supply ripple measurements i've been using a low noise opamp amplifier stage with known gain and just cap couple the input to it, then scope the output
<adamgreig-m>
seems reasonable
<adamgreig-m>
seems like it could also be built in to a pcbite probe pcb :p
<adamgreig-m>
wonder how you'd do power, maybe a usb-c port...
<adamgreig-m>
power the opamp off the power supply you're probing 💀
<henrik_alser[m]>
<adamgreig-m "hmm, wonder if i could use the c"> Yeah make sure it's 50 ohms
<henrik_alser[m]>
<adamgreig-m "power the opamp off the power su"> Would probably work with todays 120dB+ PSRR opamps
<henrik_alser[m]>
Hehe
<adamgreig-m>
yep that would bring it well below the scope noise floor :p still seems kinda unwise
<adamgreig-m>
wish you could just buy the keysight probe connector from farnell for £5 or whatever, presumably it has some power rails you could use instead
<henrik_alser[m]>
Yeah probably better off with a known source :)
<adamgreig-m>
yes, it seems it carries +-12v and +-(3 to 6)v
<henrik_alser[m]>
Cool! Or just get a cheap meanwell module and hang some LCLC stages on it
<adamgreig-m>
yea, but how to feed the power into the tiny pcbite board? even usb-c is a bit chunky for it, and now you need another cable hanging off too
<adamgreig-m>
maybe a little psu box in one of those mini enclosures that feeds a dc bias to the probe coax and plugs into the scope, hm
<adamgreig-m>
could put usb connector on that and power it from the scope front panel usb
<adamgreig-m>
give the box a pcb-mount bnc socket and it could directly attach to the scope
<adamgreig-m>
well, big talk, i'll have to actually try it out sometime
<henrik_alser[m]>
Meanwell also has this nice triple +/-15v and 5V wall wart
<henrik_alser[m]>
I've been using it a lot in audio applications even without filtering
<henrik_alser[m]>
GP25A14E-R1B
<henrik_alser[m]>
Oh, forgot i have to sleep... Have a fun night everyone!
<adamgreig-m>
goodnight!
<dirbaio[m]>
sleep? what's that
<henrik_alser[m]>
Don't know for sure, but thought i'd give it a try!
<henrik_alser[m]>
gn8!
<thalesfragoso[m]>
I think the meta-pac might be a game changer for unifying HALs, before that I wouldn't even try, tons of cfg and macros, and you would need a lot of maintainers to test things right
<thalesfragoso[m]>
With the different peripheral versions you just care about the peripheral versions instead of 100 families
<thalesfragoso[m]>
I think the lack of man-power was the main reason HALs are separated
<dirbaio[m]>
or maybe just due to how it happened? someone came along and wanted to run Rust stuff on stm32f4 so they did the F4 hal
<dirbaio[m]>
then someone else wanted to run Rust stuff on L0 so they did the L0 hal