00:00:48
##forth
<lf94>
yep tabemann it's working perfectly
00:00:51
##forth
<lf94>
fucking YES
00:01:29
##forth
<lf94>
I accidentally reversed HIGH/LOW also
00:05:32
##forth
<xentrac>
congratulations!
00:05:46
##forth
<lf94>
next phase: figure out what's up with the timer
00:05:52
##forth
<xentrac>
are they actually Raspberry Pi products?
00:05:55
##forth
<xentrac>
or are they clones?
00:06:05
##forth
<lf94>
looks like the real chip on there
00:06:25
##forth
<xentrac>
maybe you can test if they fixed the erratum with the power wastage ;)
00:06:28
##forth
<lf94>
RPI Foundation has been good for these microcontrollers
00:06:45
##forth
<lf94>
In terms of selling to product manufacturers
00:07:00
##forth
<lf94>
How do I test that
00:11:40
##forth
<lf94>
I love how clean my Forth looks
00:13:32
##forth
<lf94>
Oh nice the timer is working
00:15:45
##forth
<tabemann>
back
00:15:54
##forth
<lf94>
we're so back
00:15:56
##forth
<lf94>
B)
00:16:33
##forth
<lf94>
variable paddle.request-check 0 paddle.request-check !
00:16:36
##forth
<lf94>
Is there really no nicer way to do this
00:19:33
##forth
<tabemann>
I personally would put that in the initialization word
00:19:40
##forth
<tabemann>
because that won't work if you compile this to flash
00:19:44
##forth
<lf94>
true
00:20:04
##forth
<tabemann>
it's likely to crash things if you compile to flash actually
00:20:15
##forth
<lf94>
Initialization word is the ugliest so far
00:20:27
##forth
<tabemann>
nah
00:21:27
##forth
<lf94>
Im so so motivated right now
00:22:11
##forth
<lf94>
what's a good symbol for append
00:22:20
##forth
<lf94>
I'm having issue of event data overwriting other data lol
00:22:45
##forth
<tabemann>
use separate bits for each kind of data, as I originally did
00:22:58
##forth
<tabemann>
or use separate bytes for them
00:23:14
##forth
<lf94>
I mean the name to call this :)
00:23:18
##forth
<lf94>
event!+ ?
00:23:24
##forth
<tabemann>
separate bytes have some advantages in some case for atomicity
00:23:28
##forth
<xentrac>
lf94: oh, that's good! I didn't know that!
00:23:33
##forth
<tabemann>
that'd work
00:27:44
##forth
<lf94>
Yep this is working great
00:27:51
##forth
<tabemann>
nice
00:27:55
##forth
<lf94>
Tempted to go fix up my iambic paddle now
00:27:59
##forth
<lf94>
even the timer is working
00:28:16
##forth
<xentrac>
-· -··
00:28:26
##forth
<xentrac>
-·-·-·-·-·
00:29:00
##forth
<lf94>
I can't tell if it's the pins being shitty or a logic error when placing the 2nd one on
00:29:08
##forth
<lf94>
I can get both . and - to appear sequenced
00:29:17
##forth
<lf94>
But it's like the timing matters?
00:29:32
##forth
<tabemann>
you're using one byte to store both values
00:29:43
##forth
<lf94>
no no this is a diff issue
00:29:52
##forth
<lf94>
if you have your rp2350 / rp2040 you'll see what I mena
00:29:59
##forth
<lf94>
refresh the gist
00:31:15
##forth
<tabemann>
what exactly do you mean?
00:31:34
##forth
<lf94>
it's not related to event! word
00:31:37
##forth
<lf94>
it's something else
00:32:24
##forth
<tabemann>
what do you mean by "appear sequenced"?
00:32:37
##forth
<lf94>
each character shows up one after the other at a fixed rate
00:32:41
##forth
<lf94>
.-.-.-.-.-
00:32:52
##forth
<tabemann>
that's what I saw
00:33:04
##forth
<lf94>
Right, but do you find it hard to like, make it happen?
00:33:15
##forth
<lf94>
I find I have to almost time it for the 2nd character to start showing
00:33:23
##forth
<tabemann>
no, it was occurring constantly as soon as START was executed
00:33:34
##forth
<lf94>
oh weird, not the case for me
00:33:44
##forth
<lf94>
I'm talking about when you ground both
00:35:29
##forth
<tabemann>
paddle.request-check @ LEFT and if
00:35:29
##forth
<tabemann>
output.dot
00:35:29
##forth
<tabemann>
output.dash
00:35:31
##forth
<tabemann>
RIGHT paddle.request-check bic!
00:35:33
##forth
<tabemann>
then
00:35:35
##forth
<tabemann>
then
00:35:42
##forth
<tabemann>
you check one, unset it, then next time around you check the other, and unset that
00:35:47
##forth
<lf94>
Yes
00:35:51
##forth
<lf94>
That's right behavior
00:36:00
##forth
<lf94>
and then when both are unset, it "resets" the request register
00:36:33
##forth
<tabemann>
so you're saying it's doing this continuously even though it's edge-triggered?
00:36:38
##forth
<lf94>
Yep!
00:36:51
##forth
<lf94>
That's behavior of an iambic paddle controlled by an electric keyer
00:36:59
##forth
<lf94>
It sends out . and - at a fixed rate
00:37:04
##forth
<lf94>
as you hold them down
00:39:21
##forth
<tabemann>
please explain for a second what exactly you're seeing
00:39:31
##forth
<tabemann>
tell me like I'm five :)
00:39:40
##forth
<xentrac>
tiny letters on a computer screen
00:39:50
##forth
<lf94>
I'm seeing it's difficult to trigger - at the same time.
00:39:59
##forth
<lf94>
It's possible, but seems ... hard
00:40:18
##forth
<lf94>
You will see if you try on you rp
00:41:14
##forth
<tabemann>
try moving GPIO_PADDLE_LEFT INTR_GPIO_EDGE_LOW! inside the IF ... THEN
00:41:26
##forth
<tabemann>
so it is called only if the condition is detected
00:41:44
##forth
<tabemann>
so if there is a slight timing difference between the two signals it won't erroneously fail to detect one of them
00:42:03
##forth
<tabemann>
do it for all of those, btw
00:42:30
##forth
<lf94>
ok
00:43:45
##forth
<lf94>
I think that helped
00:44:04
##forth
<lf94>
I can't tell if it's just me touching the pins too that's just...wonky
00:44:08
##forth
<lf94>
I'm using 3 alligator clips
00:44:20
##forth
<lf94>
One on ground, and then 2 attached the end of that one
00:44:30
##forth
<lf94>
and then touching the 2 pins with the 2 non-alligator ends
00:44:40
##forth
<tabemann>
are you touching the metal parts
00:44:47
##forth
<lf94>
Of course lol
00:45:14
##forth
<lf94>
GND alligator-----pin alligators <===== pins
00:45:22
##forth
<lf94>
hard to show in text lol
00:45:42
##forth
<lf94>
then those 2 pins ===== gpio 14 and 15
00:45:48
##forth
<lf94>
on header pins
00:46:00
##forth
<lf94>
so it's like trying to touch 2 thin pieces of metal with 2 other pieces of metal
00:46:08
##forth
<lf94>
thin metal*
00:46:40
##forth
<tabemann>
I don't think you're going to get decent signals this way
00:47:00
##forth
<lf94>
lol
00:47:07
##forth
<lf94>
Ok, I should maybe then bring out my paddle at this point
00:47:10
##forth
<lf94>
and hook it up
00:47:20
##forth
<tabemann>
yeah
00:47:53
##forth
<lf94>
: turnkey ... ; also right? for auto start?
00:48:25
##forth
<tabemann>
yeah
01:10:07
##forth
<lf94>
Sorry, taking me some time to adjust the paddle
01:10:12
##forth
<lf94>
I haven't adjusted it at all since I got it
01:10:18
##forth
<lf94>
(Google "Bencher BY-1" :)
01:10:40
##forth
<lf94>
(You pretty much made the cheapest electronic keyer money can buy :D)
01:10:53
##forth
<lf94>
(That goes with these iambic paddles)
01:10:59
##forth
<lf94>
(The paddle itself has zero electronics)
01:11:33
##forth
<tabemann>
ah
01:11:58
##forth
<lf94>
Does the "left" and "right" and "paddles" make sense now? XD
01:12:24
##forth
<tabemann>
oh I figured they were buttons you pressed on the paddle to generate dots and dashes
01:13:29
##forth
<tabemann>
oh I see
01:15:28
##forth
<xentrac>
they're paddle-shaped buttons
01:15:43
##forth
<tabemann>
yeah
01:16:00
##forth
<xentrac>
you can move your hand left and right without moving your fingers relative to your hand in order to switch between dots and dashes
01:16:10
##forth
<xentrac>
except when you're doing the Iambic Squeeze
01:16:40
##forth
<xentrac>
the original version of the device was called a "bug", was purely mechanical, and did not support the Iambic Squeeze
01:19:58
##forth
<tabemann>
the iambic squeeze I presume involves literally squeezing both paddles together at once to generate a dot and then a dash?
01:22:04
##forth
<xentrac>
yeah, when both paddles are pressed, it alternates between dots and dashes
01:22:09
##forth
<lf94>
yep!
01:24:20
##forth
<tabemann>
when you're involving sub-cup of coffee pricing, though, and you're not doing mass production...
01:25:19
##forth
<xentrac>
oops, sorry
01:25:26
##forth
<tabemann>
oftentimes the tooling for those uber-cheap parts can be uber-expensive
01:25:46
##forth
<lf94>
Also, we've implemented our own software solution that'll work on literally anything
01:25:49
##forth
<tabemann>
custom programmers and ICE's and like
01:26:12
##forth
<lf94>
It's Forth. I bet I could get this working on GBForth with little changes
01:26:13
##forth
<xentrac>
the PMS150C is well supported by free tooling, although it's an OTP part
01:26:31
##forth
<tabemann>
well the software would have to be adapted to run on anything other than an RP2040 (with minor modifications it should work on an RP2350)
01:26:37
##forth
<lf94>
I could probably use the link cable port
01:27:00
##forth
<xentrac>
some of Forth's advantages would not really be in play on the PMS150C
01:27:04
##forth
<tabemann>
xentrac: what about the price of the programmer though
01:27:32
##forth
* tabemann tends to be skeptical of ultra-cheap microcontrollers himself
01:28:55
##forth
<tabemann>
no, I mean the physical hardware
01:29:05
##forth
<xentrac>
yeah, that's what I'm talking about
01:29:17
##forth
<xentrac>
it's not free as in price, but as in open-source hardware
01:30:14
##forth
<tabemann>
ah
01:30:25
##forth
<tabemann>
I thought you meant free programming software
01:31:11
##forth
<xentrac>
the NY8A054E is Nyquest's own weird 8-bit PIC-like architecture, and I don't think anything supports it
01:31:39
##forth
<tabemann>
also, why spend 27.76 on a device, even if it's oepn hardware, just so you can claim to have spent only $0.026 USD on the MCU itself
01:31:45
##forth
<tabemann>
if you're not doing mass production
01:31:47
##forth
<tabemann>
*open
01:31:57
##forth
<xentrac>
I've sometimes seen the NY8A051 family as cheap as 1.58¢
01:32:09
##forth
<xentrac>
oh, because you want to build a device containing more than one computer
01:32:51
##forth
<tabemann>
but you're making an electronic keyer that will require only one MCU
01:35:33
##forth
<xentrac>
for a hello-world project, yeah
01:36:08
##forth
<tabemann>
also, such uber-cheap MCU's tend to be very limited
01:36:57
##forth
<tabemann>
when you can spend under $2 for an RP2350 and the corresponding Winbond QSPI flash chip...
01:37:41
##forth
<xentrac>
they're very limited indeed, yes
01:37:56
##forth
<xentrac>
transistors are also very limited
01:38:06
##forth
<xentrac>
but sometimes people use them in electronics designs anyway
01:39:33
##forth
<xentrac>
these microcontrollers are cheaper than not just discrete logic gates but even most discrete transistors (because they are smaller and can handle less power than the transistors)
01:41:13
##forth
<xentrac>
often people use soldering irons that cost more than US$28 to solder the discrete transistors to their boards, too ;)
01:41:53
##forth
<tabemann>
you're not going to sell me on Padauk or Nyquest ultra-cheap, very limited MCU's
01:43:29
##forth
<xentrac>
that's okay; maybe you don't do electronics
01:44:44
##forth
<tabemann>
like the Nyquest has a program memory (that's ROM not RAM) of *2K words*
01:45:03
##forth
<xentrac>
some of the Padauk microcontrollers have even less
01:45:20
##forth
<xentrac>
I think the smallest one is 512 words (and again PROM, not RAM or Flash)
01:45:53
##forth
<tabemann>
2K words of code is *nothing*
01:46:13
##forth
<xentrac>
I've written an HTTP server that's less instructions than that
01:46:25
##forth
<MrMobius>
heh
01:46:45
##forth
<xentrac>
on Linux though
01:46:46
##forth
<tabemann>
I presume you used a separate ESP8285 or ESP32 chip to provide the networking
01:46:54
##forth
<MrMobius>
2K words is way more than you need for your electric toothbrush or whatever else a lot of microcontrollers go into
01:46:54
##forth
<xentrac>
so it doesn't include the TCP/IP stack!
01:46:57
##forth
<tabemann>
which is kind of cheating here
01:47:31
##forth
<tabemann>
MrMobius: thing is, are we producing electric toothbrushes in the millions here?
01:47:43
##forth
<MrMobius>
it's fun to cram a whole retrocomputer into a microcontroller but the vast majority of them never get used for anything like that
01:47:52
##forth
<xentrac>
don't think of them as alternatives to an RP2350. they aren't. they're alternatives to things like a 555 or an op-amp active filter or a video interface chip
01:48:04
##forth
<MrMobius>
tabemann: I dont care. the point is, 2K words is not *nothing* as you said
01:48:33
##forth
<xentrac>
512 instructions is way more than enough to do what a 555 does
01:49:52
##forth
<xentrac>
(and without the external components the 555 needs)
01:50:04
##forth
<tabemann>
yeah, and you better get your code right before you produce a part, as otherwise you're going to have literally unsolder your chip and solder in a new one if the code ever needs to change
01:50:08
##forth
<lf94>
ok!
01:50:10
##forth
<lf94>
All adjusted
01:50:12
##forth
<lf94>
hooking it up now
01:50:30
##forth
<xentrac>
but, like I said, maybe you don't do electronics, so you don't understand why someone would want that kind of thing
01:50:58
##forth
<xentrac>
I mean, literally unsoldering components and soldering in new ones is par for the course when your circuit has a design error?
01:51:28
##forth
<tabemann>
xentrac: it's just that I'm not looking for parts to replace 555's here
01:51:43
##forth
<tabemann>
sure, that 2 cent padauk chip may be more than adequate when you're replacing a 555
01:52:26
##forth
<tabemann>
xentrac: I appreciate being able to update code after something is assembled
01:53:07
##forth
<xentrac>
yeah, it's a definite plus
01:55:04
##forth
<xentrac>
running a neural network
01:55:54
##forth
<xentrac>
and several people have gotten them to generate the waveform needed to drive a string of WS2812 RGB LEDs
02:02:04
##forth
<lf94>
Nice it works
02:02:22
##forth
<lf94>
I think it'd work better with solid core wire?
02:03:40
##forth
<
xentrac>
> I had a problem with my wESP32 where the BD5228 I was using to sequence the Ethernet PHY reset wasn’t always working correctly (see https://www.crowdsupply.com/silicognition/wesp32/updates/the-phy-reset-saga). The PMS150C was perfect to fix this: writing the program was trivial, the micro fit where the old chip used to be and I could make it generate the exact signals I wanted. For significantly less
02:03:46
##forth
<xentrac>
than the price of the chip it was replacing, even factory programmed, it did exactly what I wanted it to do.
02:05:30
##forth
<xentrac>
in more detail:
02:05:32
##forth
<xentrac>
> There are plenty of supervisors that monitor multiple voltages and generate a reset, but I couldn’t find any low cost options that monitor one input and generate two reset signals with separate delays.
02:06:00
##forth
<xentrac>
now, plausibly this is not a problem you can relate to, which would explain why you think "2K words of code is *nothing*"
02:07:12
##forth
<xentrac>
but it's actually a pretty common sort of problem in electronics. when the specific problem you have is *so* common that TI makes a part that solves it for you out of the box, that's one thing. But often you're trying to solve a problem that's *almost*, but not exactly, like everybody else's problem
02:08:44
##forth
<lf94>
Ok think I'm coming to the phase of this project where I solder some thicker wiring to this
02:08:46
##forth
<lf94>
and longer wires
02:10:00
##forth
<tpbsd>
"<tabemann> when you can spend under $2 for an RP2350 and the corresponding Winbond QSPI flash chip..." ... thats nonsense tabemann, youve left out the PCB cost and the assembly cost at the pcb fab, (such as JLCPCB) as SMT requires the correct tools and assembly, now because it's a pcb, what about the 3.3v regulator, caps etc ?
02:11:29
##forth
<lf94>
Ok so I think there's a bug on release
02:11:34
##forth
<lf94>
But we'll come back to that
02:12:45
##forth
<tpbsd>
tabemann, youre another case of a programmer talking about stuff they have no practical experience with, especially comments such as " 2K words of code is *nothing*", thats more nonsense. 2K is heaps for many small embedded tasks when assembly is used (or Mecrisp-Across). Often less than 1K words is plenty
02:13:58
##forth
<lf94>
oh shit
02:14:18
##forth
<lf94>
tabemann: is it possible for the timer interrupt to be interrupted multiple times by a gpio interrupt before it fires, thus firing many times?
02:14:44
##forth
<tpbsd>
tabemann, you have to actually start building and finishing small embedded projects, documenting them and showcasing them to the world to get some experience before you blather on about embedded as tho you actually have real experience, when you don't.
02:15:58
##forth
<xentrac>
tabemann did build a pretty awesome Forth though
02:16:08
##forth
<xentrac>
I should probably take your advice too, though, tpbsd
02:16:27
##forth
<lf94>
Why don't you guys think he has the experience
02:16:34
##forth
<lf94>
I think tabemann probably has a shit ton
02:16:48
##forth
<xentrac>
I think he has a shit-ton of experience with computers and none with electronics
02:18:13
##forth
<xentrac>
I don't have nearly as much experience with electronics as tpbsd, but easily enough experience to have run into electronics problems where a 3¢ or 5¢ programmable chip that will emit waveforms on cue would have made my life a lot easier
02:19:24
##forth
<tpbsd>
he does, at programming
02:19:53
##forth
<tpbsd>
but programming experience isnt hardware experience, don't confuse them
02:20:19
##forth
<lf94>
Right, but I've not seen anything that would point them to being inexperienced here
02:20:37
##forth
<lf94>
Other than not agreeing on some particular philosophy
02:21:39
##forth
<xentrac>
tpbsd: btw, where do you showcase your documented projects?
02:25:36
##forth
<xentrac>
lf94: it's not really a question of philosophy. if you've encountered problems like my reset-sequencing example above, or just about anything you'd use a 555 for, and you've solved them with discrete logic and timer and comparator chips, something like the PMS150C is just an obviously better solution, regardless of what your philosophy is. if those problems aren't part of your reference set, 2K words of
02:25:42
##forth
<xentrac>
code might seem like nothing to you
02:26:47
##forth
<xentrac>
basically, if you can't understand why someone would ever use a PMS150C, you can't understand why someone would ever use a transistor or a 555, because you haven't
02:30:57
##forth
<MrMobius>
xentrac: is there a flash version of the same 3 cent chip?
02:31:16
##forth
<MrMobius>
so you can flash one for testing and use the 3 cent chip when youre done
02:33:25
##forth
<xentrac>
yes, it's like 15¢
02:33:41
##forth
<xentrac>
they also sell ICEs
02:33:48
##forth
<MrMobius>
that would make me slightly more interested
02:33:58
##forth
<MrMobius>
although documentation and community are the selling point
02:36:14
##forth
<tpbsd>
MrMobius, the initial PADUAK 2c chips all disappeared when covid hit, they were OTP and the ICE plus flashing routine was proprietary. The ICE unit itself was around $1000 USD back then
02:37:07
##forth
<xentrac>
I've been impressed with Padauk's documentation, although I've read a lot of it in Chinese
02:37:09
##forth
<lf94>
Will level low / high interrupts fire a lot
02:37:23
##forth
<xentrac>
community doesn't seem to exist
02:37:29
##forth
<tpbsd>
MrMobius, many suspected that the series was just a experimental production of a few million units on old cheap FAB's and when they were all sold, that ws it
02:37:45
##forth
<xentrac>
yeah, but LCSC has them in stock now; see link above
02:38:04
##forth
<MrMobius>
interesting
02:40:20
##forth
<tpbsd>
those OTP's also had very few internal peripherals, and were 8 bit. At the same time they were selling I was buying MSP430 with 4KB FRAM, 16 bit and lots of internal peripherals for $0.20 each, I have about 2,000 in stock as a result
02:41:07
##forth
<xentrac>
because their power dissipation is pretty bad (high)
02:41:33
##forth
<tpbsd>
whats more the MSP430 dont need a ICE as they are infinitely reprogrammable being FRAM and have JTAG for GDB
02:41:37
##forth
<lf94>
I think doing these inputs on edge low/high is causing me problems
02:41:57
##forth
<xentrac>
the two-"core" versions of the chip are interesting in the "few internal peripherals" department, because you can program one of the "cores" to act as an internal peripheral
02:42:18
##forth
<xentrac>
you get faster response that way than you get with an interrupt handler on most chips
02:42:32
##forth
<xentrac>
infinitely reprogrammable is a pretty big plus
02:44:15
##forth
<tpbsd>
they haven't determined the lifespan of FRAM yet as doing that would take years
02:45:24
##forth
<xentrac>
they've had years though
02:47:18
##forth
<xentrac>
10¹⁰ cycles is only a few minutes, but maybe TI's chips don't fail that fast
02:47:33
##forth
<xentrac>
but even 10¹⁵ is only a couple of years
02:47:48
##forth
<xentrac>
(if you're testing by writing the same memory location repeatedly the entire time)
02:50:45
##forth
<MrMobius>
I think TI was saying 10^13 at one point
02:51:02
##forth
<MrMobius>
and removed the wording about "unlimited" at some point
02:51:35
##forth
<tpbsd>
MrMobius, that rings a bell, but they also said that the test pieces hadnt failed at that point, they just got tired of waiting and stopped the test
02:52:54
##forth
<tpbsd>
in any event the actual rewrite time was so high, it doesnt really matter what it is to all practical purposes
02:53:10
##forth
<MrMobius>
right. unlimited for all practical purposes
02:53:15
##forth
<tpbsd>
yeah
02:53:37
##forth
<tpbsd>
anyone rewriting endlessly will use ram anyway
02:53:56
##forth
<MrMobius>
it applies to reads to though right?
02:55:03
##forth
<tpbsd>
well a read is the same as a write (iirc) in that a rewrite is needed immediately to refresh after the read, but this is taken care of internally to the FRAM chip
02:55:24
##forth
<tpbsd>
it's transparent to the controlling mcu
02:55:36
##forth
<tabemann>
lf94, the GPIO interrupt can fire as many times as possible at any time
02:55:53
##forth
<tabemann>
if the priorities are set in a certain way they can even fire *during* the timer interrupt
02:56:09
##forth
<lf94>
I think I may need to debounce
02:56:17
##forth
<tabemann>
you will
02:56:24
##forth
<xentrac>
what do you mean about the rewrite time being high?
02:57:10
##forth
<lf94>
tabemann: Is a cheap way to do this like... simply only accept what happens in a short amount of time? or maybe average out the inputs?
02:57:39
##forth
<lf94>
start o xxo o xo xo xo o xo o x_oxox_o x_xo xoxoo x_o x_o x_o x_xo x_ox_o x_ox_xo o xoox_o x_o xo o x_xo o xox_xoxo xox_xoo x_o xxo o x_o xxo xoxo xo xo x_xo o xoxo
02:57:51
##forth
<lf94>
^ raw edge inputs, x is fall, o is rise
02:58:04
##forth
<lf94>
(_ is the system doing a dash lol)
02:58:24
##forth
<lf94>
we can see pairs of xo canceling each other out
02:58:59
##forth
<tabemann>
lf94: probably the easiest way to do it is with the GPIO interrupt notifying a task, which implements the debounce
02:59:11
##forth
<lf94>
You love your tasks B)
02:59:16
##forth
<lf94>
Let's zoom into one part
02:59:19
##forth
<lf94>
xxo
02:59:39
##forth
<lf94>
Here, it did a "release" (space) right after, because o has some sorta output priority
02:59:49
##forth
<lf94>
But it really shouldve interpreted this as an x
03:01:03
##forth
<tabemann>
basically you have the task wait on a notification, and then it waits for the signal to settle
03:02:16
##forth
<tabemann>
I'll be back later
03:02:22
##forth
<lf94>
Maybe I should instead use edges as notifiers but levels as the actual value?
03:02:25
##forth
<lf94>
ok!
03:02:32
##forth
<MrMobius>
ideally it would read the button repeatedly and wait for it to stop oscillating rather than just waiting
03:03:11
##forth
<lf94>
This is my code so far MrMobius
03:11:18
##forth
<lf94>
Going to implement this
03:15:48
##forth
<xentrac>
lf94: which one, StateShift or PingPong?
03:15:56
##forth
<lf94>
PingPong I think
03:16:11
##forth
<tpbsd>
MrMobius, Ive always set a delay after a button interrupt and then checked back at the end of the delay, usually around 20mS. if the logic level is the same, it means bouncing has stopped and the button has been pressed, otherwise it's ignored
03:16:33
##forth
<xentrac>
20ms is too long for an iambic keyer, but 1ms is probably fine
03:16:46
##forth
<lf94>
This is really, really nice.
03:17:11
##forth
<lf94>
I gotta say, my iambic paddle is actually quite good for bouncing, as you see from the output above
03:17:29
##forth
<lf94>
< 6ms window should be more than enough
03:17:38
##forth
<xentrac>
6ms is probably still too long
03:17:42
##forth
<MrMobius>
tpbsd: the problem with that is if it's still bouncing after 20ms you might catch it when the level is still the same but it's not done bouncing
03:17:57
##forth
<xentrac>
I feel like both of these algorithms are making things harder than they need to because they're worried about noise. I don't think you're going to have noise, just bouncing
03:18:18
##forth
<xentrac>
lf94: where's the output above?
03:18:34
##forth
<lf94>
xentrac: look for x's and o's
03:18:47
##forth
<xentrac>
oh, I saw that but I don't know how to interpret it. what's the timescale?
03:19:33
##forth
<lf94>
Hard to articulate
03:19:47
##forth
<lf94>
But if you see xxo it's literally like < 30ms
03:19:57
##forth
<xentrac>
30ms is a very, very long time
03:20:10
##forth
<lf94>
probably less then, it's from me tapping the key
03:20:18
##forth
<tpbsd>
not mechanically speaning it isnt
03:20:30
##forth
<lf94>
Google "Bencher BY-1"
03:20:38
##forth
<tpbsd>
30ms is a very, very FAST time, mechanically speaking
03:20:38
##forth
<lf94>
I'm like tapping the top of the triangle
03:21:01
##forth
<tpbsd>
it's only very fast 'electronically' speaking
03:21:29
##forth
<xentrac>
it's a very long time in terms of morse code keying latencies
03:22:31
##forth
<tpbsd>
Ive tested many pushbuttons myself going back 40 years, I hardly need a Ganssle chart of the same thing
03:22:38
##forth
<xentrac>
he says of his tests: "Toss out those two samples and the other 16 switches exhibited an average 1557 µsec of bouncing, with, as I said, a max of 6200 µsec."
03:23:12
##forth
<xentrac>
but he also had a button that bounced for 150+ milliseconds
03:23:20
##forth
<tpbsd>
then there is the range of bouncing exhibited by identical pushbuttons of the same model
03:23:22
##forth
<xentrac>
which would be unusable for purposes like this
03:23:56
##forth
<xentrac>
but a lot of them were reliably sub-millisecond
03:24:26
##forth
<xentrac>
for an iambic keyer you often have to time your switch closings and openings to within three dit times
03:25:36
##forth
<tpbsd>
xentrac, hardly important for most push buttons as people are very slow and 20ms is fine in general
03:26:44
##forth
<tpbsd>
specialist cases such as the 'iambic' keyer will need fine tuning but theyre the exception to key debounce, not the rule
03:27:53
##forth
<xentrac>
> Latency matters! For very simple tasks, people can perceive latencies down to 2 ms or less. Moreover, increasing latency is not only noticeable to users, it causes users to execute simple tasks less accurately. If you want a visual demonstration of what latency looks like and you don’t have a super-fast old computer lying around, check out this MSR demo on touchscreen latency.
03:28:38
##forth
<tpbsd>
xentrac, you love to argue about anything don't you ? and as long as you have enough links you can go all day. What happens when you actually have to speak from experience, are you struck dumb ?
03:29:08
##forth
<tpbsd>
xentrac, have you ever measured the bouncing of a switch yourself ?
03:29:49
##forth
<xentrac>
I do tend to be fairly argumentative. I understand I'm not going to educate *you* but other people may be reading the conversation and profit from the links.
03:30:08
##forth
<xentrac>
Yes, I've measured the bouncing of switches, but it's been decades.
03:30:43
##forth
<lf94>
For some visuals
03:30:45
##forth
<lf94>
:)
03:31:23
##forth
<lf94>
This whole setup is so stupid beautiful.
03:31:42
##forth
<tpbsd>
thats hot of my scope and the switch Im debouncing is a rotary switch
03:31:44
##forth
<xentrac>
lf94: it is!
03:32:04
##forth
<tpbsd>
read about it all here
03:32:04
##forth
<lf94>
Knowing it's forth on the rp2040 makes my brain explode
03:32:36
##forth
<xentrac>
tpbsd: what's the timescale? 9.8 milliseconds per division seems implausible
03:32:50
##forth
<lf94>
The ultimate would be a RP2040 _inside a USB cable
03:33:09
##forth
<lf94>
Where it has like 10 wires
03:33:14
##forth
<lf94>
hooked up to GPIOs
03:33:16
##forth
<lf94>
that you can use
03:33:43
##forth
<lf94>
I'm a dummy I can do that today
03:33:54
##forth
<lf94>
I can make this tiny USB device look like one end
03:34:04
##forth
<xentrac>
lf94: have you measured the bounce times of your paddles?
03:34:13
##forth
<lf94>
I dont even know where I'd start
03:34:21
##forth
<xentrac>
do you have an oscilloscope?
03:34:24
##forth
<lf94>
no :(
03:34:26
##forth
<lf94>
I want one though
03:34:30
##forth
<lf94>
some day
03:34:33
##forth
<xentrac>
maybe use your sound card
03:34:50
##forth
<lf94>
good idea
03:34:55
##forth
<xentrac>
with like 1 volt
03:35:03
##forth
<xentrac>
or less
03:35:17
##forth
<lf94>
Can't I directly hook this up to the mic port
03:35:26
##forth
<lf94>
and the friction itself will cause little blips
03:35:35
##forth
<xentrac>
"this"?
03:35:37
##forth
<lf94>
the paddle
03:36:04
##forth
<lf94>
(rp2040 obv. not involved at all in this)
03:36:23
##forth
<lf94>
...let me implement the debouncer first.
03:36:26
##forth
<xentrac>
I forget how much phantom power is
03:36:31
##forth
<lf94>
Because this is still cool
03:36:34
##forth
<lf94>
a cool idea I want to try
03:36:38
##forth
<xentrac>
maybe?
03:36:46
##forth
<lf94>
maybe what
03:37:05
##forth
<xentrac>
maybe you can directly hook up the paddles to the mic port without a separate power source
03:38:07
##forth
<tpbsd>
xentrac, it's what you read, the scope doesnt lie
03:38:07
##forth
<xentrac>
lf94: you might try asking in ##electronics
03:38:25
##forth
<lf94>
I'm just gonna do it
03:38:27
##forth
<lf94>
for science
03:38:27
##forth
<xentrac>
tpbsd: the scope's output is inadequately labeled to interpret
03:38:29
##forth
<lf94>
lol
03:40:12
##forth
<xentrac>
I'm going to bed
03:40:26
##forth
<xentrac>
goodnight! and don't blow up your motherboard by connecting multiple volts to the mic input
03:43:38
##forth
<lf94>
lol
03:43:41
##forth
<lf94>
night
03:44:23
##forth
<xentrac>
tpbsd: Jack Ganssle's oscilloscope traces are labeled so I can tell what they're saying. Yours aren't
03:44:33
##forth
<lf94>
What cheap scope do you guys recommend
03:44:38
##forth
<lf94>
or even mid tier I guess
03:55:19
##forth
<tpbsd>
xentrac, learn to read a scope then ?
03:55:44
##forth
<tpbsd>
xentrac, ok, so you can't read a scope, why am I not surprised ?
04:04:44
##forth
<MrMobius>
but mostly use the multimeter part
04:14:15
##forth
<
tpbsd>
lf94, I have 3 scopes, a Tek 3904 analog storage mainframe with DSO plugin, thats reserved for specialist instances, and my main scope is a HP54601 DSO (https://www.youtube.com/watch?v=Je-y-tE1J4w) used to make the waveforms I pasted the URL's for above. I paid $4600 AUD for it new in 1994 and it's still going :)
04:15:31
##forth
<tpbsd>
oops Tek7623A mainframe
04:16:19
##forth
<tpbsd>
lf94, these days there are so many scopes to choose from, mainly chinese, the RIGOL brand is pretty good and very cheap compared to my old HP
04:16:51
##forth
<tpbsd>
as are all the Hantek units, which are cheaper as they use a local PC to display the video
04:35:07
##forth
<lf94>
My thinkpad is always around me when hacking, so that sounds nice.
04:38:26
##forth
<MrMobius>
tpbsd: you mean recording video or something? the scope functionality works in real time
04:40:07
##forth
<tpbsd>
MrMobius, no I only mean the display for the waveform etc, as that unit doesnt have a display does it ?
04:40:22
##forth
<tpbsd>
oops!
04:40:27
##forth
<tpbsd>
my BAD!
04:40:37
##forth
<tpbsd>
I see it does have a small lcd display
04:40:48
##forth
<MrMobius>
it's not bad actually
04:41:38
##forth
<tpbsd>
sorry, I assumed it was just a box with a couple of BNC probe connectors and a USB out
04:41:42
##forth
<lf94>
Wow - so small!
04:41:55
##forth
<tpbsd>
like the early hanteks
04:43:07
##forth
<tpbsd>
lf94, if MrMobius has one you know it's going to be pretty good!
04:43:25
##forth
<lf94>
Nice.
04:43:29
##forth
<lf94>
Price is very good too
04:43:31
##forth
<lf94>
256
04:43:33
##forth
<lf94>
CAD
04:46:09
##forth
<tpbsd>
it looks perfect to start with
04:46:33
##forth
<tpbsd>
and maybe to finish with depending how far you go
15:04:04
##forth
<nmz>
xentrac: that's exactly what I was looking for yeah
15:04:07
##forth
<nmz>
thanks
18:51:21
##forth
<lf94>
tabemann: so my issue with debouncing is... I'm not using a timed window to check for it.
18:51:40
##forth
<lf94>
I really like what one Reddit user described: use the edge rise/fall as the start of the timer window.
18:51:44
##forth
<lf94>
I'll do this later
18:52:06
##forth
<lf94>
I implemented the EvenOdd and PingPong algorithms but they're useless without this polling window :)
19:38:57
##forth
<xentrac>
nmz: happy to help!
19:49:29
##forth
<xentrac>
lf94: your sound card is fine for measuring time intervals down to about 30μs though, so it's fine for measuring switch bounce. where it falls down is faster signals (an entry-level oscilloscope has 20MHz of bandwidth instead of 20kHz) and any kind of absolute measurement
19:49:52
##forth
<xentrac>
you can use any audio editor such as Audacity to see the waveforms
19:50:56
##forth
<xentrac>
it sucks at absolute measurement because the input is not calibrated to absolute voltages, because its analog filtering induces some phase shift at more than a few kHz (though some sound cards can be quite good at this), and because the input is ac-coupled
19:51:10
##forth
<xentrac>
so you can't tell 5V dc from 0V dc
20:09:21
##forth
<tabemann>
back
20:20:42
##forth
<xentrac>
by "absolute measurement" I mean "absolute voltage measurement". it's fine for absolute duration measurement