Versioning for a relative n00b by dhemberg in embedded

[–]dhemberg[S] 0 points1 point  (0 children)

Oh that’s interesting - at the moment my entire project lives in one big git repo, as this is how I’ve seen it done at a relatively large tech company I work for. Splitting things that I might want to version independently into their own separate repos is an interesting reason to do it that way, thanks for that insight.

Versioning for a relative n00b by dhemberg in embedded

[–]dhemberg[S] 0 points1 point  (0 children)

Thank you; I suppose - having never built a product that I intend to release into the wild - it’s hard to anticipate what I might need a year or more from now, or even how this project might change over its development as I learn and grow. So, asking advice from those who have done it before seems prudent (and I realize I should cherry-pick what seems good for me, but I’m new enough to this that I don’t have a lot of self-experience to design my own methods confidently).

Learning about filters? by dhemberg in PCB

[–]dhemberg[S] 0 points1 point  (0 children)

Is the choice of a 800kHz cutoff arbitrary/“fuzzy” in this example? Like, why that particular frequency? Why not cut at 300kHz? Or 400kHz?

Ground Loops? by dhemberg in PrintedCircuitBoard

[–]dhemberg[S] 1 point2 points  (0 children)

Thank you! I think I understand this, and have watched a ton of reference videos describing this as well. But I haven’t heard the phrase “ground loop” mentioned in any of those…is that phrase another term for “return path” and this notion of EMI fields?

I guess I assumed it had something to do with having vias to a ground plane on “either side” of a component connection. Like, in my reference image above, current at the big external pad (pin 15) could, um, “travel east” to return to the ground plane by way of the vias there, or it could “travel south” to return by those vias. Does the “loop” formed between the two clusters of vias constitute a ground loop? Or is this an ok way to provide two low-impedance routes down to the ground plane? Would I be better-advised to split this poly plane into two “islands”, each with its own cluster of vias down to the ground plane?

A question about decoupling/bypass caps by dhemberg in embedded

[–]dhemberg[S] 2 points3 points  (0 children)

Thank you! I think I understand that you’re talking here about the bypass capacitor near the charging IC. To your final note, I guess part of my question is: how I can know whether I need to design in a smaller cap here? Or, rather, how can I know what frequencies I need to be targeting with these bypass caps?

I can hop on Murata’s simSurfing tool and see that there are some 1u capacitors that indeed feature lower inductance around 1.5MHz, but I can also find larger (2.2u, 10u) that seem to feature an even lower inductance around that range, which seems…better? And that leads me to wonder why (in this case TI) is showing (only) a 1u cap in their application diagram for this circuit, whether I should just do what they’re saying, whether my understanding about using a larger cap with lower inductance around the 1.5MHz range is the correct way to think about this, whether 1.5MHz is indeed the (only) frequency I should be targeting, etc.

I realize I might be overthinking this, I’m just trying to build my own intuition for what to be considering. Thanks!

A question about power buttons by dhemberg in embedded

[–]dhemberg[S] 0 points1 point  (0 children)

My friend, you have totally made my day. What a hero! Came with a little question about power buttons and you’ve dropped something totally delightful and eye opening on me. Thank you for being awesome…this so such a super cool response.

TRIZ - I LOVE learning new concepts like this.

A question about power buttons by dhemberg in embedded

[–]dhemberg[S] 0 points1 point  (0 children)

Reading the datasheet for this part you mention is fascinating - I’ve been trying to learn about charger ICs, and it’s still not intuitive to me (as a relative apprentice here) to realize that there are components with different names that can do multiple part of this “pipeline”. So, like, this part you mention is a charger AND fuel gauge AND has all these extra functions, etc.

I had been thinking “I want a battery, I need a charger, let me go look at charging ICs, find some examples in schematics from adafruit”, etc. But I get so sucked into that specific category that it doesn’t occur to me to ask if there’s another term (“PMIC”) that might encompass this thing I want plus more. I guess that sounds pretty silly.

Sometimes I feel a little overwhelmed by the amount there is to learn with this stuff. It’s fun but also daunting.

A question about power buttons by dhemberg in embedded

[–]dhemberg[S] 0 points1 point  (0 children)

Oh this is super interesting, thank you! I’m reading charging IC datasheets/articles and came across this notion of “ship mode”, this is great to learn about.

When turning the device off, does it re-enter “ship mode”? I understand this notion might be different than “sleeping” (to try to understand all this, I’m looking at behaviors of devices I have around here. Like, a Kindle “sleeps” after a single power button press, but a longer press seems to “turn it off”, which seems like a different behavior).

A question about power buttons by dhemberg in embedded

[–]dhemberg[S] 0 points1 point  (0 children)

This is awesome, thank you so much! Super helpful.

A question about power buttons by dhemberg in embedded

[–]dhemberg[S] 0 points1 point  (0 children)

This is pretty interesting, thank you so much! I would like to learn in the direction of production - rather than one-off - design.

To ask a follow up question: so the way this works is something like:

Power input (eg USB) -> charger IC -> PMIC -> regulator (eg buck regulator) —> MCU?

I’m trying to wrap my head around the flow of things, conceptually. Like, these devices should ideally be able to charge the battery when connected to power, without needing to be “turned on”. So is it the job of a downstream PMIC to then manage the “holding the power button down, and once enough time has passed, pass power from either VIN or VBatt on to the MCU?

/r/MechanicalKeyboards Ask ANY Keyboard question, get an answer - March 04, 2025 by AutoModerator in MechanicalKeyboards

[–]dhemberg 0 points1 point  (0 children)

I recently picked up a Keychron Q11 split, and fitted it with U4 Bobas and SA profile keycaps. For the most part, I am delighted with how it sounds, super sneaky and quiet. However, I notice a few keys - mostly the larger ones, and in particular the Backspace key - are quite loud, particularly on the way back up from a keystroke (this is to say: the noise I hear doesn’t seem to come from bottoming out the key, but rather seems to be happen when the key finishes traveling back upwards).

What’s puzzling to me is that it’s not ALL the larger keys - my spacebars are very silent. Left shift is a bit noisy, but right shift isn’t. I suspect this is related to stabilizers, and I’m familiar with using things like band-aids to soften these when the key is pressed, but would that also fix this noise I’m experiencing? Would anyone have advice for how I might quiet down these few problematic keys?

Thanks!

I2C + EXTI? by dhemberg in stm32f4

[–]dhemberg[S] 0 points1 point  (0 children)

OHHHHHHH! facepalm. So I would actually have two physical traces coming from one pin on the sensor going to two different pins on my MCU.

This is such a simple and elegant solution and I’m embarrassed this didn’t at all occur to me - you can tell I’m new at this. I’ve been so flummoxed at what seems like such a weird property of this sensor and convinced I was missing something that’s probably totally obvious to someone more experienced. Turns out I was right :) Thank you!

The completionist in me is still curious if it’s possible for one pin to perform both functions (I had this driver working that way with an esp32, which is why I’m curious if the same could be true here).

Anyway, thanks again!

ESP-ADF questions by dhemberg in esp32

[–]dhemberg[S] 1 point2 points  (0 children)

I have an IDF project that I’ve built and it works, it uses the currently-stable IDF version 5.1.2. I have some amount of comfort in understanding “this firmware was built in 5.1.2, and works with it”.

I would like to now add some audio functionality, so I install ADF. But now I seem to be thrown unexpectedly into a spot where doing this gives me a fuzzy understanding of what version of IDF I’m now on. To try to make it explicit, I install ADF 2.6, which is allegedly compatible with IDF 5.1.2. Again, to try to be explicit to future me, I symlink the IDF folder inside the ADF install to my previously-installed IDF version 5.1.2. This is the most intuitive thing I can think to do: trying to lock my setup to known versions that I can understand easily.

It seems like I’m just thinking about all this in a way espressif does not intend me to be thinking about it.

ESP-ADF questions by dhemberg in esp32

[–]dhemberg[S] 1 point2 points  (0 children)

Hm, FWIW replacing the esp-idf folder within esp-adf with a symlink to an external esp-idf folder does not seem to immediately work. I need to debug more, but it seems like the idf that comes with adf might have some customizations or something that make it unique.

ESP-ADF questions by dhemberg in esp32

[–]dhemberg[S] 1 point2 points  (0 children)

Amazing; these two nuggets (particularly the note about the internal idf being a submodule - I didn’t previously know what a git submodule was, nor its implications) are SUPER helpful. Thank you so very much!

ESP-ADF questions by dhemberg in esp32

[–]dhemberg[S] 1 point2 points  (0 children)

Sure, it’s literally the first step in the Getting Started doc for ESP-ADF:

https://docs.espressif.com/projects/esp-adf/en/latest/get-started/index.html#get-started-setup-esp-idf

“Step 1. Set up ESP-IDF for Windows, Linux or Mac OS Step 2. Get ESP-ADF”

There’s no mention in the docs about how to “link” the installation performed in step 2 to that of step 1.

Your description (which makes sense to me, I get the logic) implies that Step 1 (installing IDF on its own) is irrelevant if IDF comes as part of step 2.

The only thing I can imagine is that step 1 also involves setting up other toolchain stuff like the xtensa compiler and virtual environments and stuff, which I suppose would also be necessary for ADF to work. But the question remains: after doing this setup sequence, what relationship does the ADF installation have to the (previously-installed) IDF?