crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
IlPalazzo-ojiisa has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
emerent has joined #rust-embedded
DepthDeluxe_ has joined #rust-embedded
sigmaris has joined #rust-embedded
DepthDeluxe_ has quit [Ping timeout: 260 seconds]
<re_irc>
<jobroe> Good Morning, I'm looking for a microcontroller board which supports wifi. I would like to build a "button" which controlles my WLED via JSON-API. Any recommondations ?
<re_irc>
< (@k900:0upti.me)> ESP32 or Pi Pico W are basically your only options for availability reasons
<re_irc>
<Félix | Totem> : I've no idea. I don't even understand those words.
<re_irc>
< (@xiretza:xiretza.xyz)> there is certainly one problem, though it doesn't explain the symptoms by itself: you are driving all the columns at the same time (one high, all others low), which will break as soon as you press two keys on different columns at the same time - you need open collector/open drain outputs, not push-pull
<re_irc>
< (@xiretza:xiretza.xyz)> * in the same row
<re_irc>
<Félix | Totem> : It's not at the same time, though. I do it one after the other.
<re_irc>
< (@xiretza:xiretza.xyz)> you also need some kind of biasing on your input pins, since they will be floating if no switch is pressed - they're not connected to anything. you need to check if the board already contains discrete pullup/pulldown resistors, and if not, use the pullups/pulldowns built into the GPIO peripheral
<re_irc>
< (@xiretza:xiretza.xyz)> Félix | Totem: you are, the pin doesn't magically stop existing when you're not currently looking at it in the current iteration
<re_irc>
< (@xiretza:xiretza.xyz)> the column pins are always driven low, except for one iteration, where each is driven high for one iteration
<re_irc>
I just saw that high and low are reversed tho
<re_irc>
<Félix | Totem> : Thanks
<re_irc>
< (@xiretza:xiretza.xyz)> Félix | Totem: oh, sorry, didn't see that you had enabled the internal pull-ups on the inputs - that explains your current problem then! you're telling it to connect a resistor to each input pin that pulls it high if nothing is connected that would pull it low (i.e. a pressed switch that is connecting the row to a low column)
<re_irc>
< (@xiretza:xiretza.xyz)> therefore all the inputs are high when nothing is being pressed
<re_irc>
<Félix | Totem> : I'm not sure to understand. Does t replace the open drain you're talking about?
<re_irc>
< (@xiretza:xiretza.xyz)> Félix | Totem: no, you still need open drain outputs if more than one key can be pressed at the same time
<re_irc>
<Félix | Totem> : And should I set_high before, then set_low after? Or the opposite?
<re_irc>
< (@xiretza:xiretza.xyz)> if you use open drain outputs, then you need pull-downs on your inputs
<re_irc>
< (@xiretza:xiretza.xyz)> sorry no, pull-downs
<re_irc>
<Félix | Totem> There is no method “floating”, so I'm not sure how disable the column
<re_irc>
<Félix | Totem> +to
<re_irc>
< (@xiretza:xiretza.xyz)> that's because all your colums are floating, except for one, which is being pulled to ground - the row inputs for which a switch is pressed on that column will be driven low (through the switch), all the others will be pulled high by the pullups
<re_irc>
< (@xiretza:xiretza.xyz)> sorry no, pull-ups
<re_irc>
< (@xiretza:xiretza.xyz)> Félix | Totem: "set_low()" for low, "set_high()" for floating
* re_irc
(@k900:0upti.me) makes a note for embedded-hal v3
<re_irc>
<Félix | Totem> The second one: switch to the upper side makes it float
<re_irc>
<Félix | Totem> * switching
<re_irc>
< (@xiretza:xiretza.xyz)> Félix | Totem: yeah, it's basically a missing abstraction, the hardware register is only ever 0 or 1, what happens depends on the pin configuration
<re_irc>
< (@k900:0upti.me)> Looks like there's actually kind of an RFC for this already
<re_irc>
< (@xiretza:xiretza.xyz)> : tristate is a whole other can of worms too
<re_irc>
<Félix | Totem> : That's totally clear now. I always forget that I don't read the electric current directly, but only a bit in the CPU.
<re_irc>
< (@xiretza:xiretza.xyz)> what we'd need are a bunch of traits that offer "set_high()", "set_low()", "set_floating()" methods each, and then implement a subset of those traits based on the pin state
<re_irc>
col.set_low().into_ok_(); // The pin is ON
<re_irc>
<Félix | Totem> * "row.is_low" and "is_high"
<re_irc>
< (@xiretza:xiretza.xyz)> you need "into_pull_up_input"
<re_irc>
< (@xiretza:xiretza.xyz)> right now the inputs are always low, either through the closed switch to the grounded column, or through the pull-down - you can't tell the difference
<re_irc>
<Félix | Totem> : And now it works. That's so cool, thanks a lot 😁
emerent has quit [Ping timeout: 246 seconds]
emerent has joined #rust-embedded
DepthDeluxe_ has joined #rust-embedded
<re_irc>
<Félix | Totem> My board can play some audio (8 bits I think), does someone have some resource about how to use it? I have this definition in C:
<re_irc>
#define AUDIO_PIN A5
<re_irc>
#define AUDIO_PIN_ALT A4
<re_irc>
#define AUDIO_PIN_ALT_AS_NEGATIVE
<re_irc>
< (@xiretza:xiretza.xyz)> what does the C++ code do?
<re_irc>
< (@xiretza:xiretza.xyz)> does it just bit-bang the pin or does it use a peripheral?
<re_irc>
< (@k900:0upti.me)> I'm guessing "A" means "analog" here
<re_irc>
I guess it bit-bang the pin, as you says. The audio is really simple
<re_irc>
<Félix | Totem> : I'm afraid to read the QMK source code 😅
<re_irc>
< (@k900:0upti.me)> Actually no, it's just the pin mapping
<re_irc>
< (@ryankurte:matrix.org)> : the macros? in general they -should- but i'm sure there are plenty of cases they don't (macros are hard)...
<re_irc>
you can always manually implement "Encode" and "Decode", but it'd be great to have issues / test cases to reproduce any broken cases so we can improve em
<re_irc>
< (@ryankurte:matrix.org)> ahh i found the issue, thanks!