2025-06-15 00:19:25 <xentrac     > : minop over >r  2dup > >r  xor r> and  r> xor ;
2025-06-15 00:20:08 <xentrac     > I was playing with a RISC-V branch-free min (as a stand-in for CMOV problems) and it occurred to me to translate it to assembly
2025-06-15 00:20:15 <xentrac     > uh, to Forth
2025-06-15 00:20:58 <xentrac     > I am not happy with the result
2025-06-15 00:21:41 <xentrac     > six stack manipulations for four actual computational operations
2025-06-15 00:29:31 <forthBot    > Environment for cleobuline inactive, freeing...
2025-06-15 00:33:12 <xentrac     > forthBot: : minop over >r  2dup > >r  xor r> and  r> xor ;
2025-06-15 00:33:12 <forthBot    > Unknown word in definition: over
2025-06-15 00:33:13 <forthBot    > Error: Definition discarded due to error
2025-06-15 00:33:20 <xentrac     > forthBot: : minop OVER >r  2dup > >r  xor r> and  r> xor ;
2025-06-15 00:33:21 <forthBot    > Unknown word in definition: >r
2025-06-15 00:33:21 <forthBot    > Error: Definition discarded due to error
2025-06-15 00:33:26 <xentrac     > forthBot: : minop OVER >R  2dup > >r  xor r> and  r> xor ;
2025-06-15 00:33:26 <forthBot    > Unknown word in definition: 2dup
2025-06-15 00:33:26 <forthBot    > Error: Definition discarded due to error
2025-06-15 00:33:43 <xentrac     > forthBot: : minop OVER >R  2DUP > >R  XOR R> AND  R> XOR ;
2025-06-15 00:33:43 <forthBot    > Unknown word in definition: 2DUP
2025-06-15 00:33:44 <forthBot    > Error: Definition discarded due to error
2025-06-15 00:34:09 <xentrac     > anyway I feel like you could probably write a simpler branch-free min
2025-06-15 00:57:04 <MrMobius    > forthBot: : minop OVER >R  OVER OVER > >R  XOR R> AND  R> XOR ;
2025-06-15 00:57:58 <MrMobius    > forthBot: 3 5 minop .s
2025-06-15 00:57:58 <forthBot    > Error: Unknown word: .s
2025-06-15 00:58:01 <MrMobius    > forthBot: 3 5 minop .S
2025-06-15 00:58:02 <forthBot    > <2> 1 1
2025-06-15 00:59:59 <xentrac     > hmm, that doesn't look like 3
2025-06-15 01:02:18 <MrMobius    > works in seems to work in gforth
2025-06-15 01:02:46 <xentrac     > yeah, it does
2025-06-15 01:02:51 <xentrac     > forthBot: 3 4 > .
2025-06-15 01:02:51 <forthBot    > 0
2025-06-15 01:02:58 <xentrac     > forthBot: 4 3 > .
2025-06-15 01:02:58 <forthBot    > 1
2025-06-15 01:03:08 <xentrac     > oh, that's the problem, it's using the wrong value for "true"
2025-06-15 01:03:13 <MrMobius    > forthBot: : foo 3 >R R> .S ; foo
2025-06-15 01:03:13 <forthBot    > <3> 1 1 3
2025-06-15 01:03:59 <MrMobius    > I like -1 as true
2025-06-15 01:04:33 <xentrac     > I originally wrote the code on RISC-V, which also uses 1 for "true"
2025-06-15 01:04:54 <xentrac     > so I had to invert the logic and subtract 1 from it
2025-06-15 01:05:01 <xentrac     > in Forth that isn't necessary
2025-06-15 01:07:41 <MrMobius    > xentrac: is this from Hacker's Delight by chance?
2025-06-15 01:08:07 <MrMobius    > too bad there isnt a sign extension instruction for a single bit :P
2025-06-15 01:09:31 <xentrac     > no, my original version was longer:
2025-06-15 01:10:06 <xentrac     > minop:  slt t0, a0, a1          # set t0 to "is a0 < a1?" (0 or 1)
2025-06-15 01:10:07 <xentrac     >         addi t0, t0, -1         # convert 0 to -1 (a0 ≥ a1) and 1 to 0 (a0 < a1)
2025-06-15 01:10:09 <xentrac     >         and t1, t0, a1          # t1 is now either 0 or, if a0 ≥ a1, a1
2025-06-15 01:10:12 <xentrac     >         xori t0, t0, -1         # negate t0.  I don’t think RISC-V has a NOT
2025-06-15 01:10:14 <xentrac     >         and t2, t0, a0          # t2 is now either 0 or, if a0 < a1, a0
2025-06-15 01:10:17 <xentrac     >         or a0, t1, t2           # put the smaller of a0 and a1 into a0
2025-06-15 01:10:20 <xentrac     >         ret
2025-06-15 01:10:29 <xentrac     > but then I gradually cut it down to:
2025-06-15 01:10:44 <xentrac     > minopmin4:
2025-06-15 01:10:44 <xentrac     >         slt a2, a0, a1
2025-06-15 01:10:46 <xentrac     >         xor a0, a0, a1
2025-06-15 01:10:49 <xentrac     >         ret
2025-06-15 01:11:20 <xentrac     > hopefully all the instructions are obvious other than `slt`
2025-06-15 01:13:55 <xentrac     > I don't think Hacker's Delight has a branchless conditional move in it
2025-06-15 01:14:00 <xentrac     > that's sort of out of its scope
2025-06-15 01:16:44 <MrMobius    > nah, it's heavy on branchless stuff
2025-06-15 01:19:45 <xentrac     > but mostly on computing things rather than just moving them around
2025-06-15 01:20:27 <MrMobius    > branchless min starts on p42 of my copy
2025-06-15 01:25:06 <xentrac     > I'll take a look
2025-06-15 01:25:11 <MrMobius    > one of them uses movne for the generic RISC architecture it describes. MIPS v4 got movn but not on RISCV
2025-06-15 01:26:05 <xentrac     > well, the context of this was that I was trying to measure how much it costs RISC-V to not have conditional move instructions in contexts where you need constant execution time
2025-06-15 01:27:05 <MrMobius    > it does make me think about what instructions to add to the 7400 logic computer im planning
2025-06-15 01:27:36 <xentrac     > the RV32I instruction set is quite pleasingly boring
2025-06-15 01:27:54 <MrMobius    > some things either were never popular or maybe got added to some arch ive never seen
2025-06-15 01:28:27 <MrMobius    > like loading one of two values based on carry which is kind of like cmov
2025-06-15 01:28:32 <xentrac     > although Graeme Smecher's Minimax shows how you can get a significantly smaller design
2025-06-15 01:29:11 <xentrac     > Minimax implements *only* the RV32IC compressed instructions, plus a few more
2025-06-15 03:02:58 <forthBot    > Environment for xentrac inactive, freeing...
2025-06-15 03:03:13 <forthBot    > Environment for MrMobius inactive, freeing...
2025-06-15 03:15:47 <cleobuline  > forthBot:  LOAD ini.fth
2025-06-15 03:15:47 <forthBot    > File ini.fth with moon loaded
2025-06-15 03:15:52 <cleobuline  > forthBot: : minop OVER >R  2DUP > >R  XOR R> AND  R> XOR ;
2025-06-15 03:19:46 <cleobuline  > forthBot:  1 2 minop .S
2025-06-15 03:19:46 <forthBot    > <1> 1
2025-06-15 03:19:59 <cleobuline  > forthBot:  3 1 minop .S
2025-06-15 03:19:59 <forthBot    > <2> 1 1
2025-06-15 03:20:25 <cleobuline  > forthBot:   43 5 MIN .S
2025-06-15 03:20:25 <forthBot    > <3> 1 1 5
2025-06-15 03:20:38 <cleobuline  > forthBot:   43 5 MAX  .S
2025-06-15 03:20:39 <forthBot    > <4> 1 1 5 43
2025-06-15 03:21:48 <xentrac     > cleobuline: that definition of minop doesn't work because > produces the wrong "true" value, 1 instead of -1
2025-06-15 03:22:16 <cleobuline  > ha
2025-06-15 03:22:58 <cleobuline  > true is just 0 <>
2025-06-15 03:29:36 <tpbsd       > not here on Mecrisp-Stellaris Forth on Cortex-M " 4 2 > . -1  ok."
2025-06-15 03:30:12 <tpbsd       > everyone has their own opinion of the truth ;-)
2025-06-15 03:47:56 <cleobuline  > false == 0
2025-06-15 03:48:09 <cleobuline  > anny number id true
2025-06-15 03:48:24 <cleobuline  > is
2025-06-15 03:56:11 <lf94        > tabemann_: Does INTR_GPIO_EDGE_HIGH@ return 0 (off) and 1 (on) or 0 and -1?
2025-06-15 03:56:18 <lf94        > Not clear to me
2025-06-15 03:58:50 <cleobuline  > forthBot:  : test IF  -1 ELSE 0 THEN ;
2025-06-15 03:58:58 <cleobuline  > forthBot:  5 test .
2025-06-15 03:58:58 <forthBot    > -1
2025-06-15 03:59:15 <cleobuline  > forthBot: : minop OVER >R  2DUP > test >R  XOR R> AND  R> XOR ;
2025-06-15 03:59:37 <cleobuline  > forthBot:  2 3 minop
2025-06-15 03:59:41 <cleobuline  > forthBot:  .
2025-06-15 03:59:41 <forthBot    > 1
2025-06-15 04:00:01 <cleobuline  > forthBot:  3 2  minop
2025-06-15 04:00:04 <cleobuline  > forthBot:  .
2025-06-15 04:00:04 <forthBot    > 1
2025-06-15 04:04:03 <tabemann_   > lf94: 0 and -1
2025-06-15 04:04:16 <tabemann_   > bit@ always returns a boolean, and booleans in Forth are 0 and -1
2025-06-15 04:04:25 <lf94        > niice!
2025-06-15 04:04:29 <lf94        > ok cool thank you :D
2025-06-15 04:04:45 <lf94        > I'm writing a program for an electronic keyer for morse code
2025-06-15 04:04:54 <lf94        > i'll be sure to send you a video after :)
2025-06-15 04:05:31 <lf94        > tabemann_: my second question would be: am I setting up interrupts correctly
2025-06-15 04:05:53 <lf94        > https://gist.github.com/lf94/6cafbffbc0c9711fc4f397dff1f68f3f
2025-06-15 04:06:35 <tabemann_   > just so you know, you're not defining CONSTANT's right
2025-06-15 04:06:51 <tabemann_   > you define, say, a constant foo to be $FFFF as:
2025-06-15 04:06:55 <tabemann_   > $FFFF constant foo
2025-06-15 04:07:13 <tabemann_   > i.e. the value goes before the word CONSTANT
2025-06-15 04:08:28 <tabemann_   > also, VECTOR! takes an exception vector index, *not* an IRQ index
2025-06-15 04:09:09 <tabemann_   > a vector index is an IRQ index plus 16
2025-06-15 04:10:04 <tabemann_   > also, you don't need OR! and INVERT ... AND!
2025-06-15 04:10:13 <tabemann_   > OR! is already implemented as BIS!
2025-06-15 04:10:23 <tabemann_   > and INVERT ... AND! is already implemented as BIC!
2025-06-15 04:10:57 <tabemann_   > also, START has to be defined *before* TURNKEY
2025-06-15 04:11:45 <tabemann_   > remember that in Forth you can only refer to things declared before itself; if you want to refer to something defined afterwards you have to declare it beforehand with DEFER and then set it later with IS -- but in this case simply switching their order would suffice
2025-06-15 04:14:05 <lf94        > haha thanks. yeah it's been a minute since i wrote forth and I always tend to f up the constants :D
2025-06-15 04:14:45 <lf94        > tabemann_: oh shit thank you for BIS and BIC!
2025-06-15 04:15:05 <lf94        > this is awesome help
2025-06-15 04:15:10 <tabemann_   > they stand for "BIt Set" and "BIt Clear"
2025-06-15 04:15:16 <lf94        > I figured hehe
2025-06-15 04:15:40 <tabemann_   > note that ! is part of the name
2025-06-15 04:15:46 <tabemann_   > BIS! and BIC!
2025-06-15 04:15:59 <lf94        > Right, usually used to indicate "store"
2025-06-15 04:16:17 <lf94        > My Forth memory is a bit fuzzy but it's not entirely gone heh
2025-06-15 04:16:29 <lf94        > It's been about... 5? months
2025-06-15 04:16:42 <MrMobius    > cleobuline: 1 is true in C but it should be -1 in Forth
2025-06-15 04:16:55 <cleobuline  > ok
2025-06-15 04:16:56 <lf94        > I should really write a Forth linter in Forth
2025-06-15 04:17:06 <lf94        > To catch simple stuff like constants being wrong
2025-06-15 04:17:28 <tabemann_   > TRUE being -1 enables not having separate 'bit' and 'logical' operations as C has
2025-06-15 04:17:44 <MrMobius    > cleobuline: https://forth-standard.org/standard/core/TRUE
2025-06-15 04:17:49 <cleobuline  > forthBot:  QUIT
2025-06-15 04:17:50 <forthBot    > Environment for cleobuline has been freed.
2025-06-15 04:17:56 <cleobuline  > forthBot:  WORDS
2025-06-15 04:17:56 <forthBot    > USERNAME .S . + - * / MOD DUP DROP SWAP OVER ROT >R R> R@ R@UL R!UL = < > AND OR NOT XOR & | ^ ~ << >> CR EMIT VARIABLE @ ! +! DO LOOP I WORDS LOAD CREATE ALLOT ." CLOCK BEGIN WHILE REPEAT AGAIN SQRT UNLOOP +LOOP PICK CLEAR-STACK PRINT NUM-TO-BIN PRIME? FORGET STRING S" "S 2DROP IMAGE TEMP-IMAGE CLEAR-STRINGS DELAY EXIT CONSTANT MICRO MILLI ROLL DEPTH APPEND MOON-PHASE MOON-RISE-SET
2025-06-15 04:18:01 <lf94        > tabemann_: beautiful.
2025-06-15 04:18:13 <lf94        > tabemann_: is BIS! and BIC! part of forth standard?
2025-06-15 04:18:13 <tabemann_   > old figFORTH's though had 1 for TRUE IIRC, but it's generally considered to not have been a win
2025-06-15 04:18:16 <cleobuline  > AND OR NOT XOR & | ^ ~ << >>
2025-06-15 04:18:43 <cleobuline  > in forthBot yu have c like bit operators
2025-06-15 04:19:13 <lf94        > tabemann_: how do I setup a proper interrupt then btw?
2025-06-15 04:19:57 <tabemann_   > lf94: not to my knowledge -- zeptoforth's BIS! and BIC! were taken from Mecrisp-Stellaris, and IMHO ought to have been in ANS Forth
2025-06-15 04:20:26 <tabemann_   > lf94: your interrupt setup was almost right
2025-06-15 04:20:49 <tabemann_   > you just have to use the IRQ 16 + to get the vector, and when servicing the interrupts you have to clear them
2025-06-15 04:21:10 <lf94        > Is there no simpler way? Would I have then struggled for a bit around this?
2025-06-15 04:21:36 <lf94        > Where would I have learned about the 16 + ?
2025-06-15 04:21:51 <tabemann_   > e.g. 8 INTR_GPIO_EDGE_HIGH! clears the edge high interrupt for GPIO 8
2025-06-15 04:21:56 <lf94        > I know it's not Zeptoforth's reponsibility to teach this, but it couldbe good in the documentation...
2025-06-15 04:22:38 <tabemann_   > lf94: from the ARM Cortex-M0 and ARM Cortex-M33 reference manuals
2025-06-15 04:23:06 <lf94        > :D.
2025-06-15 04:23:25 <lf94        > Would you accept a small documentation addition mentioning this? :)
2025-06-15 04:23:32 <lf94        > I'll open a PR
2025-06-15 04:23:51 <tabemann_   > if you make a PR make it against the 'devel' branch
2025-06-15 04:24:01 <lf94        > Also your project is absolutely amazing. I was wondering if you accept monetary donations
2025-06-15 04:24:42 <tabemann_   > the key thing to remember is that there's vectors for which there are no IRQ's, such as PendSV
2025-06-15 04:24:57 <tabemann_   > and these vectors are those lower than 16
2025-06-15 04:25:10 <lf94        > Ahhh.
2025-06-15 04:25:31 <tabemann_   > oh, no donations are needed (at one point I did consider starting one of those buy-me-a-beer/buy-me-a-coffee things but decided against it)
2025-06-15 04:25:56 <lf94        > The project is just so well done I feel youve given a real gift to the world
2025-06-15 04:26:24 <lf94        > And it has a good chance of living for a long, long time
2025-06-15 04:26:32 <tabemann_   > really, just the fact that people use it and get something out of it makes me happy
2025-06-15 04:26:42 <lf94        > Considering RP2040 and RP2350 will be produced in the hundreds of millions
2025-06-15 04:27:55 <tabemann_   > lately I've been working on PicoCalc support; I don't have my PicoCalc yet but have been using an ST7789V and a couple speakers and driver boards I own to emulate much of the functionality of a PicoCalc
2025-06-15 04:29:00 <lf94        > Wow crazy you mention this, I saw this just the other day too
2025-06-15 04:29:03 <lf94        > It's a cute little device
2025-06-15 04:29:12 <tabemann_   > (I also integrated a keyboard emulation mode because I don't have a PicoCalc keyboard on hand)
2025-06-15 04:29:45 <tabemann_   > I ordered mine on April 20th and was told last week that mine would be amongst a shipment sent to the shipping company yesterday
2025-06-15 04:31:38 <lf94        > This could be a cool device to make games for in forth
2025-06-15 04:31:53 <lf94        > right on the device, that can be reprogrammed in real time
2025-06-15 04:31:59 <tabemann_   > I got one specifically to be a portable Forth machine
2025-06-15 04:32:05 <lf94        > I guess the Python support can do the same
2025-06-15 04:32:11 <lf94        > I figured :p
2025-06-15 04:32:40 <lf94        > Question @ interrupts: so there are 16 interrupts with no configuration?
2025-06-15 04:32:49 <lf94        > (0 through 15)
2025-06-15 04:32:57 <lf94        > So that's why we need to 16 + right?
2025-06-15 04:33:33 <tabemann_   > yeah
2025-06-15 04:33:53 <tabemann_   > actually 15 though, because vector 0 is actually the initial stack pointer
2025-06-15 04:34:12 <tabemann_   > which is used on bootup by the ARM architecture
2025-06-15 04:34:18 <lf94        > ah
2025-06-15 04:34:34 <tabemann_   > note that these can be configured, but aren't configured with NVIC
2025-06-15 04:34:58 <tabemann_   > e.g. many of these interrupts can have their priority set, but not all of them
2025-06-15 04:35:24 <tabemann_   > some of them have priorities fixed in hardware (e.g. Hard Fault)
2025-06-15 04:36:07 <lf94        > Right. The only experience I have with interrupts is on the Nintendo Game Boy and I recall there is a similar system
2025-06-15 04:36:28 <lf94        > You can go to a fixed number of "reset vectors" with "RST I" where I is the number
2025-06-15 04:36:39 <lf94        > Otherwise you enable/disable "standard" interrupts
2025-06-15 04:38:13 <tabemann_   > likewise, you can't disable the hard fault exception handler
2025-06-15 04:39:46 <tabemann_   > CPSID/CPSIE has no effect on it
2025-06-15 04:49:23 <tabemann    > the biggest thing to remember about interrupts is you always have to clear the condition that caused the interrupt or otherwise you will enter an infinite loop, with the interrupt handler being called forever
2025-06-15 04:49:39 <lf94        > Oh, I was reading that say, timer interrupts, clear themselves?
2025-06-15 04:51:24 <lf94        > Is there a better name for these exception vector interrupts
2025-06-15 04:51:34 <lf94        > Instead of IRQ_XXX ?
2025-06-15 04:51:53 <lf94        > Maybe VEIRQ?
2025-06-15 04:51:58 <lf94        > erm, EVIRQ
2025-06-15 04:53:02 <tabemann    > no, you have to clear timer interrupts by setting INTR (note that my TIMER::CLEAR-ALARM-INT also clears any pending timer interrupt)
2025-06-15 04:53:53 <tabemann    > I would just do <your IRQ number> constant foo-irq and the vector being foo-irq 16 + constant foo-vector
2025-06-15 04:54:54 <lf94        > ah ok.
2025-06-15 04:56:23 <MrMobius    > cleobuline: you can have separate bitwise and logical operations but that is also not how other Forths do it
2025-06-15 04:56:55 <MrMobius    > not that you have to do it like everyone else but if you want your bot to be more or less standard, you'll need to do it how  most other forths do
2025-06-15 04:57:17 <tabemann    > separate bitwise and logical operations are definitely not traditional in the Forth world
2025-06-15 04:57:43 <tabemann    > and I don't just mean that they're not separate in ANS, but rather that Forths across the board separate the two
2025-06-15 04:57:54 <tabemann    > *don't separate the two
2025-06-15 04:59:18 <tabemann    > Forths normally just have AND, OR, XOR, and what in ANS is INVERT but where I personally prefer NOT
2025-06-15 04:59:58 <lf94        > tabemann: what is force btw?
2025-06-15 05:00:39 <tabemann    > (ANS INVERT is a design-by-committee naming because the ANS people couldn't choose between figFORTH NOT, which acted like C !, and Forth 83 NOT, which acted like what became ANS INVERT)
2025-06-15 05:00:55 <tabemann    > lf94, what do you mean?
2025-06-15 05:01:11 <lf94        > There's a few functions in gpio.fs that take a "force" or output a "force"
2025-06-15 05:03:13 <tabemann    > "force" in that context is basically manually triggering an interrupt in software (when setting it) or getting whether an interrupt has been triggered in software (when getting it)
2025-06-15 05:03:26 <tabemann    > it's not really something you normally have to concern yourself with
2025-06-15 05:07:44 <lf94        > oh nice!
2025-06-15 05:07:50 <lf94        > could be useful :)
2025-06-15 05:20:28 <lf94        > clear-alarm stops the alarm right?
2025-06-15 05:21:28 <tabemann    > CLEAR-ALARM clears the armed alarm, CLEAR-ALARM-INT stops the triggered alarm interrupt and any pending interrupt
2025-06-15 05:22:56 <tabemann    > oh, btw, there is one other thing about your code -- you don't set your GPIO's as inputs or as pull-up's or pull-down's (note that internal pull-downs are borked on the RP2350, and need either external pull-downs or a hack that isn't suitable to what you're doing)
2025-06-15 05:30:04 <lf94        > Why are internal pulldowns broken on rp2350? :s
2025-06-15 05:31:46 <tabemann    > the company the RPi people farmed out the GPIO pad development took a small request to slightly change the pads and completely redesigned them, incorrectly, and I gather the way they were implemented was such that it wasn't caught by the RPi people's own testing
2025-06-15 05:33:53 <lf94        > that's crazy right?
2025-06-15 05:34:10 <lf94        > from what I know most internal pull downs in microcontrollers are...standard to have
2025-06-15 05:34:44 <tabemann    > the hack is to switch on input enable right before reading them, and then disabling input enable right after reading
2025-06-15 05:34:48 <lf94        > I think I need pull-up for this
2025-06-15 05:36:07 <lf94        > So I think I'm almost done alreday
2025-06-15 05:38:44 <lf94        > https://gist.github.com/lf94/da8204d94069bd920ff237abbf53c8b3
2025-06-15 05:39:09 <lf94        > there is one problem other than the pull-up/down/input missing: is the way I set a timer correct? can I reference the func that's setting it?
2025-06-15 05:40:30 <lf94        > I forgot the '
2025-06-15 05:40:39 <lf94        > to make it into an xt
2025-06-15 05:42:29 <tabemann    > CLEAR-ALARM-INT takes an alarm index
2025-06-15 05:42:43 <tabemann    > and you mean ['] here
2025-06-15 05:43:05 <tabemann    > to reference the func that is setting it to
2025-06-15 05:43:12 <tabemann    > use DEFER
2025-06-15 05:43:14 <tabemann    > like
2025-06-15 05:43:27 <tabemann    > DEFER FOO-ALARM-HANDLER
2025-06-15 05:43:29 <tabemann    > :NONAME
2025-06-15 05:43:37 <lf94        > ahhh yes defer
2025-06-15 05:43:38 <tabemann    > FOO-ALARM CLEAR-ALARM-INT
2025-06-15 05:44:01 <lf94        > I really can't just use ['] ?
2025-06-15 05:44:16 <lf94        > oh whoops @ clear-alarm-int
2025-06-15 05:44:33 <tabemann    > you can't just use ['] alone
2025-06-15 05:44:43 <lf94        > ah.
2025-06-15 05:44:46 <lf94        > defer it is!
2025-06-15 05:45:06 <tabemann    > also, the alarm is set to a specific microsecond explicitly
2025-06-15 05:45:49 <lf94        > oh shit right
2025-06-15 05:46:04 <lf94        > It has to be <internal counter> + N right?
2025-06-15 05:46:15 <tabemann    > so you have to do US-COUNTER-LSB YOUR-US-INTERVAL + ['] YOUR-HANDLER YOUR-ALARM-INDEX SET-ALARM
2025-06-15 05:46:37 <tabemann    > and with defer, e.g., to make an infinite loop that will explode the stack do
2025-06-15 05:46:39 <tabemann    > DEFER FOO
2025-06-15 05:46:49 <tabemann    > :NONAME FOO ; IS FOO
2025-06-15 05:49:00 <lf94        > yessir
2025-06-15 05:49:18 <lf94        > lol
2025-06-15 05:49:48 <lf94        > to _not_ explode the stack I do: defer foo\n :noname ( stuff here ) ; is foo - right?
2025-06-15 05:50:01 <tabemann    > yeah
2025-06-15 05:52:30 <lf94        > On second thought I think I do need pull-down
2025-06-15 05:52:47 <lf94        > when one side of the paddle goes down, it should pull a pin to ground
2025-06-15 05:53:16 <tabemann    > no
2025-06-15 05:53:23 <tabemann    > just tie the other end of the paddle to GND
2025-06-15 05:53:27 <tabemann    > and do a pull-up
2025-06-15 05:53:42 <tabemann    > so when the paddle goes down, the GPIO will go low
2025-06-15 05:53:47 <lf94        > I'm tying it to the rp2040's gnd
2025-06-15 05:53:55 <lf94        > yea
2025-06-15 05:53:57 <lf94        > that's what I meant
2025-06-15 05:53:57 <tabemann    > yeah
2025-06-15 05:54:03 <lf94        > oh that's a pull up
2025-06-15 05:54:21 <tabemann    > pull down is the opposite
2025-06-15 05:54:29 <lf94        > sorry i was thinking literally what you described
2025-06-15 05:54:37 <lf94        > but i find the configuration naming weird lol
2025-06-15 05:54:52 <tabemann    > pull down is when you pull the GPIO low and tie the other end to VCC
2025-06-15 05:55:03 <tabemann    > so when the circuit is closed it goes high
2025-06-15 05:55:36 <lf94        > ah it's from the framing of the gpio being pulled, right.
2025-06-15 05:56:04 <tabemann    > btw, unless you need internal pulldowns or floating pins I would suggest an RP2350
2025-06-15 05:56:19 <tabemann    > even at a lower clock it is faster than the RP2040 and it has gobs more SRAM
2025-06-15 05:56:35 <tabemann    > it also has hardware single-precision floating point
2025-06-15 05:56:38 <lf94        > I'm using a cute little RP2040 USB thing from Aliexpress
2025-06-15 05:56:57 <lf94        > they are quite cheap
2025-06-15 05:57:45 <lf94        > I've used Zeptoforth with it before ;)
2025-06-15 05:57:53 <lf94        > I may have shown you on Discord
2025-06-15 05:58:11 <lf94        > I hooked it up to a PS4 controller and made it control it like a macro system
2025-06-15 05:58:21 <tabemann    > yeah, I remember that
2025-06-15 05:58:25 <lf94        > That was the last time I touched forth lol
2025-06-15 05:59:30 <tabemann    > I should note that RP2350 boards are (almost) as cheap as RP2040 boards
2025-06-15 06:01:00 <lf94        > Yeah I'll probably start buying those instead
2025-06-15 06:01:07 <lf94        > This USB form factor those is really, _really_ nice.
2025-06-15 06:01:15 <lf94        > though*
2025-06-15 06:01:32 <tabemann    > I wouldn't be surprised if you could find something similar running an RP2350
2025-06-15 06:02:39 <lf94        > They are so convenient to hack with
2025-06-15 06:02:48 <lf94        > no cable is really nice
2025-06-15 06:05:29 <tabemann    > my normal way of doing things is to solder pins onto a board, plug it into a little breadboard, and then plug jumper cables into the breadboard
2025-06-15 06:06:41 <lf94        > PULL_UP GPIO_MINE GPIO_CTRL_INOVER! look right?
2025-06-15 06:07:20 <lf94        > Heh. I like to be able to slap in the uC, program the forth to manipulate external hardware objects, and hit the ground running. :D
2025-06-15 06:07:24 <tabemann    > no
2025-06-15 06:07:40 <tabemann    > TRUE GPIO_MODE PADS_BANK0_PUE!
2025-06-15 06:07:46 <tabemann    > *GPIO_MINE
2025-06-15 06:07:53 <lf94        > Oh damn, way off.
2025-06-15 06:07:53 <tabemann    > TRUE GPIO_MINE PADS_BANK0_PUE!
2025-06-15 06:08:29 <lf94        > I shouldve simply searched 'pull up'
2025-06-15 06:08:37 <lf94        > I was too busy searching "PULL_UP" lol
2025-06-15 06:09:42 <tabemann    > you'll also need TRUE GPIO_MINE PADS_BANK0_OD! and TRUE GPIO_MINE PADS_BANK0_IE!
2025-06-15 06:10:12 <tabemann    > if you're using an RP2350 you'll also need at the end FALSE GPIO_MINE PADS_BANK0_ISO!
2025-06-15 06:10:16 <lf94        > Is OD really necessary?
2025-06-15 06:10:19 <tabemann    > however there's an easier way to do this
2025-06-15 06:10:23 <tabemann    > yeah
2025-06-15 06:10:28 <lf94        > I don't think I'd ever accidentally output
2025-06-15 06:10:41 <tabemann    > you need output disable if you're doing things this way
2025-06-15 06:10:43 <tabemann    > however
2025-06-15 06:10:46 <tabemann    > you can just use:
2025-06-15 06:10:54 <tabemann    > PIN INPUT
2025-06-15 06:11:00 <lf94        > Ah the pin interface
2025-06-15 06:11:01 <tabemann    > GPIO_MINE INPUT-PIN
2025-06-15 06:11:09 <tabemann    > GPIO_MINE PULL-UP-PIN
2025-06-15 06:11:12 <lf94        > To be honest I like being exposed a bit to this lower level interface
2025-06-15 06:11:20 <lf94        > I'm learning a lot
2025-06-15 06:12:06 <lf94        > I dont understand though why I need output disabled still
2025-06-15 06:12:11 <lf94        > If I never output
2025-06-15 06:12:14 <tabemann    > the thing that will trip you up if you switch to the RP2350 is PADS_BANK0_ISO!
2025-06-15 06:12:37 <lf94        > Right, but I should "just know that", shouldn't I?
2025-06-15 06:12:43 <lf94        > How are the C folks smoothing that out?
2025-06-15 06:12:50 <tabemann    > if you're using a GPIO like a normal GPIO both OD and IE must be both TRUE or both FALSE at once
2025-06-15 06:13:03 <lf94        > Ah ok.
2025-06-15 06:13:10 <lf94        > Otherwise it's undefined behavior?
2025-06-15 06:13:32 <tabemann    > if you're using it as something other than a normal GPIO, though, it's different
2025-06-15 06:14:09 <tabemann    > if you're using it as an alternate function you need to set OD to FALSE and IE to TRUE
2025-06-15 06:14:34 <lf94        > Ah right this stuff is coming back to me slowly
2025-06-15 06:14:39 <lf94        > I remember reading about this when doing the PS4 controller thing
2025-06-15 06:14:53 <tabemann    > also, if you're using an RP2350 you should set ISO to TRUE before you change these things and then to FALSE afterwards
2025-06-15 06:15:00 <lf94        > Right right.
2025-06-15 06:15:06 <tabemann    > this is a new feature with the RP2350 to avoid, well, glitchiness
2025-06-15 06:15:40 <lf94        > sounds so broken
2025-06-15 06:15:47 <tabemann    > nah
2025-06-15 06:15:48 <lf94        > makes me want to avoid the rp2350 entirely lol
2025-06-15 06:15:54 <tabemann    > it's the opposite
2025-06-15 06:16:05 <tabemann    > the glitchiness is because IE and OD can't be written in the same instruction
2025-06-15 06:16:38 <tabemann    > ISO makes it so that the GPIO does nothing while it is TRUE
2025-06-15 06:16:50 <tabemann    > so you can safely do whatever you want with its configuration without second thoughts
2025-06-15 06:17:02 <tabemann    > the RP2040 doesn't have this
2025-06-15 06:17:17 <lf94        > Ah.
2025-06-15 06:17:18 <tabemann    > so you have to take a bit more care when changing GPIO pad settins with the RP2040
2025-06-15 06:17:25 <lf94        > Ok that framing makes it better
2025-06-15 06:17:45 <lf94        > https://gist.github.com/lf94/f84836abfdcd1f9dc97f1b5084b26608
2025-06-15 06:17:48 <lf94        > Think it's done
2025-06-15 06:17:55 <lf94        > I'll see probably tomorrow lol
2025-06-15 06:17:56 <forthBot    > Environment for cleobuline inactive, freeing...
2025-06-15 06:18:55 <tabemann    > oh, characters can't be specified with 'x'
2025-06-15 06:19:10 <tabemann    > e.g. to get a character literal for the letter x you do [CHAR] x
2025-06-15 06:19:28 <lf94        > gforth lied to me
2025-06-15 06:19:30 <lf94        > :p
2025-06-15 06:19:36 <lf94        > (gforth let me do that)
2025-06-15 06:20:23 <tabemann    > SET-ALARM requires an alarm index
2025-06-15 06:20:41 <tabemann    > alarm indices are from 0-3
2025-06-15 06:20:51 <tabemann    > ( us xt index -- )
2025-06-15 06:21:23 <lf94        > blah
2025-06-15 06:21:39 <tabemann    > also you don't need: ALARM_PROCESS_PADDLE alarm-set? if exit then
2025-06-15 06:21:47 <lf94        > I do
2025-06-15 06:22:03 <lf94        > I have a full flowchart you havent seen yet
2025-06-15 06:22:11 <lf94        > requires to check if a timer is already on
2025-06-15 06:22:33 <lf94        > I think maybe its placement may be bad
2025-06-15 06:22:49 <tabemann    >   paddle.on.left  VECTOR_LEFT  vector!
2025-06-15 06:22:49 <tabemann    >   paddle.on.right VECTOR_RIGHT vector!
2025-06-15 06:22:57 <lf94        > Yeah, the placement is bad
2025-06-15 06:23:03 <lf94        > my defer needs to live higher up too
2025-06-15 06:23:05 <tabemann    > should have ['] paddle.on.left
2025-06-15 06:23:11 <lf94        > oop! nice
2025-06-15 06:23:12 <tabemann    > and ['] paddle.on.right
2025-06-15 06:23:18 <tabemann    > no your defer is fine
2025-06-15 06:23:41 <tabemann    > also you don't need to define TRUE and FALSE -- they're already defined
2025-06-15 06:23:56 <lf94        > no there are 2 other calls to on.timer that are higher than it
2025-06-15 06:24:05 <lf94        > yeah I know I was being silly with that one :p
2025-06-15 06:24:07 <tabemann    > oh gotcha
2025-06-15 06:24:17 <lf94        > gonna update the gist
2025-06-15 06:24:20 <lf94        > 2 sec
2025-06-15 06:25:36 <lf94        > Same URL, refresh
2025-06-15 06:26:11 <tabemann    > oh NVIC_ISER_SETENA! takes an IRQ index and not a vector index
2025-06-15 06:28:39 <tabemann    > oh and one biggie
2025-06-15 06:29:00 <lf94        > =_=
2025-06-15 06:29:08 <lf94        > Do I need a different word then?
2025-06-15 06:29:18 <tabemann    > there is only one GPIO interrupt per CPU core that is shared between all GPIO's
2025-06-15 06:29:21 <tabemann    > on the RP2040
2025-06-15 06:29:49 <tabemann    > actually, it isn't a per CPU core interrupt, from checking the refman again
2025-06-15 06:30:00 <tabemann    > it's IRQ 13
2025-06-15 06:30:21 <tabemann    > so vector 29
2025-06-15 06:30:41 <tabemann    > IO_IRQ_BANK0 that is
2025-06-15 06:31:18 <lf94        > -> only one gpio interrupt per cpu core <- what's wrong with that
2025-06-15 06:32:25 <tabemann    > you're using two interrupts, one for each GPIO you're reading
2025-06-15 06:32:46 <tabemann    > and also you're using IRQ's 0 and 1 for them, which are actually timer interrupts
2025-06-15 06:33:28 <lf94        > I'm using 0 16 + and 1 16 +
2025-06-15 06:33:32 <tabemann    > you should be just listening to IRQ 13 and servicing both paddles in one interrupt handler
2025-06-15 06:33:49 <tabemann    > the 16 + turns an IRQ into a vector index
2025-06-15 06:33:54 <lf94        > How can I differentiate the paddles ?
2025-06-15 06:34:25 <tabemann    > you check the GPIO's separately in the same interrupt handler
2025-06-15 06:34:59 <tabemann    > all GPIO's use the same IRQ and the same interrupt vector
2025-06-15 06:35:15 <lf94        > Which is 13
2025-06-15 06:35:26 <lf94        > Ok ok ok, nice.
2025-06-15 06:35:42 <lf94        > I understand what you're saying now. That's a little odd I'd say, but maybe not surprising
2025-06-15 06:36:20 <tabemann    > you always have to check the GPIO's to make sure they have triggered the right things inside the interrupt handler anyways
2025-06-15 06:36:46 <tabemann    > and you do do that, except you frob the alarms regardless of their actual trigger state
2025-06-15 06:40:35 <lf94        > I'm readin https://ocw.cs.pub.ro/courses/eap/laboratoare/02 now
2025-06-15 06:40:57 <lf94        > I'd be so screwed without you helping me
2025-06-15 06:41:17 <lf94        > How the hell did I do the ps4 thing so easily
2025-06-15 06:41:31 <lf94        > Maybe I ended up using the pin interface you wrote
2025-06-15 06:41:40 <lf94        > and it was only output
2025-06-15 06:42:20 <tabemann    > dealing with interrupts is definitely harder than just doing output with PIN
2025-06-15 06:43:26 <lf94        > You mentioned I'd have to clear the interrupt flag, but wouldn't that only be true for interrupts triggered by LEVEL_* ?
2025-06-15 06:43:35 <lf94        > (and timer I guess)
2025-06-15 06:43:45 <tabemann    > no, you have to clear it regardless
2025-06-15 06:44:01 <lf94        > ah, no I guess not - right. they are like "please process the interrupt request" but they will stay as 1
2025-06-15 06:44:05 <lf94        > if not cleared
2025-06-15 06:44:07 <lf94        > gotchya
2025-06-15 06:45:52 <tabemann    > the general rule with exceptions is you always have to clear the condition that triggered the interrupt or otherwise you'll loop forever
2025-06-15 06:47:00 <tabemann    > the only exception are interrupts like SysTick, PendSV, and SVC
2025-06-15 06:47:07 <tabemann    > *the main exceptions
2025-06-15 06:53:01 <lf94        > Is there no constant for IO_IRQ_BANK0 ?
2025-06-15 06:53:23 <lf94        > Oh found it
2025-06-15 06:53:33 <lf94        > or not
2025-06-15 06:53:37 <lf94        > Only in RP2350
2025-06-15 06:54:28 <tabemann    > yeah, I just noticed that
2025-06-15 06:54:32 <tabemann    > an oversight on my part
2025-06-15 06:57:23 <tabemann    > just added it in the source code, will be in the next release
2025-06-15 06:59:34 <lf94        > ok I think  igot it
2025-06-15 06:59:53 <lf94        > https://gist.github.com/lf94/43d114c58ac33f64b2b39c382e2f3029
2025-06-15 07:00:22 <lf94        > oh whoops
2025-06-15 07:00:25 <tabemann    > 13 constant IO_IRQ_BANK0 13 should be just 13 constant IO_IRQ_BANK0
2025-06-15 07:00:44 <lf94        > sorry yea copypasta
2025-06-15 07:00:49 <lf94        > VECTOR_LEFT/RIGHT gotta go too
2025-06-15 07:02:19 <tabemann    > VECTOR_LEFT, e.g., should be GPIO_PADDLE_LEFT
2025-06-15 07:02:32 <tabemann    > same with VECTOR_RIGHT and GPIO_PADDLE_RIGHT
2025-06-15 07:02:33 <lf94        > updated
2025-06-15 07:02:36 <lf94        > yep yep got it B)
2025-06-15 07:02:48 <lf94        > it's all making sense now
2025-06-15 07:03:09 <tabemann    > also, you're doing:
2025-06-15 07:03:10 <tabemann    >   ALARM_PROCESS_PADDLE alarm-set? if exit then
2025-06-15 07:03:10 <tabemann    >   paddle.on.timer
2025-06-15 07:03:12 <tabemann    > twice
2025-06-15 07:04:02 <lf94        > Oh right because they arent separate anymore
2025-06-15 07:04:17 <lf94        > actually on my god _yes_
2025-06-15 07:04:22 <lf94        > cleans it right up
2025-06-15 07:04:49 <lf94        > updated
2025-06-15 07:05:41 <tabemann    > one other thing, just as a matter of course, I would check the conditions and only trigger that code if at least one of them was true
2025-06-15 07:06:00 <tabemann    > the reason is that if in the future you ever wanted to trigger separately on another GPIO
2025-06-15 07:06:09 <tabemann    > you might not want to call that code
2025-06-15 07:06:30 <lf94        > am I not doing that?
2025-06-15 07:06:51 <tabemann    > you're calling that code whenever the IO_IRQ_BANK0 handler gets called
2025-06-15 07:06:56 <lf94        > Right
2025-06-15 07:07:24 <lf94        > I have conditions in all those routines though
2025-06-15 07:07:59 <tabemann    > I suppose it's not necessary
2025-06-15 07:07:59 <lf94        > (I think Im misunderstanding what you're getting at)
2025-06-15 07:08:15 <lf94        > You want me to "lift" the conditions higher I'm guessing?
2025-06-15 07:10:15 <tabemann    > what I mean is I'd only call paddle.on.timer if at least one of the edge conditions was true
2025-06-15 07:10:42 <lf94        > Ohhh
2025-06-15 07:10:55 <lf94        > ...yes, that was the intent. excellent catch
2025-06-15 07:11:04 <tabemann    > it's not truly necessary as IO_IRQ_BANK0 *should* only be called if at least one of them are true in this particular code example
2025-06-15 07:11:20 <tabemann    > but if you ever want to listen to another GPIO as well it would become necessary
2025-06-15 07:11:21 <lf94        > I swear man, you're amazing programming
2025-06-15 07:11:23 <lf94        > programmer
2025-06-15 07:11:25 <lf94        > I'm so tired
2025-06-15 07:11:37 <lf94        > ah right
2025-06-15 07:11:41 <lf94        > but still
2025-06-15 07:12:06 <lf94        > you're right this doesn't actually intentionally encode I only want that to fire if any of those 4 edge conditions are true.
2025-06-15 07:12:15 <lf94        > I'll fix it
2025-06-15 07:15:25 <lf94        > I love forth
2025-06-15 07:15:35 <lf94        > update
2025-06-15 07:15:54 <lf94        > so beautifully added
2025-06-15 07:16:56 <tabemann    > okay, you don't need those extra TRUE's
2025-06-15 07:17:22 <tabemann    > because you've already got those DUP's
2025-06-15 07:17:34 <lf94        > heh you caught me before i removed them ;p
2025-06-15 07:17:45 <tabemann    > and anyways, if you didn't use DUP's and you used TRUE's you'd also need to add ELSE FALSE THEN's as well
2025-06-15 07:17:45 <lf94        > f5
2025-06-15 07:18:27 <lf94        > yea they were part of an earlier moment - im really really tired heh.
2025-06-15 07:19:13 <lf94        > you could probably test this with your own rp2040 easily
2025-06-15 07:19:40 <lf94        > I'm not at home, but I brought a paper clip with me
2025-06-15 07:19:55 <lf94        > to tap gnd and the proper gpio
2025-06-15 07:20:02 <lf94        > To trigger stuff
2025-06-15 07:21:18 <tabemann    > I'm getting tired too; I'm going to call it a night shortly
2025-06-15 07:22:41 <lf94        > heh, sounds good. thank you again for all your help.
2025-06-15 07:23:41 <tabemann    > oh no problem
2025-06-15 07:23:44 <tabemann    > g'night!
2025-06-15 13:08:07 <cleobuline  > forthBot:  S" Patricia  qui prend son petit dejeuner avec des tartines "S IMAGE
2025-06-15 13:08:23 <forthBot    > https://i.ibb.co/rGybBgzm/mforth-image-Ageri-S.png
2025-06-15 13:08:59 <cleobuline  > good morning
2025-06-15 15:08:23 <forthBot    > Environment for cleobuline inactive, freeing...
2025-06-15 16:09:47 <lf94        > morning!
2025-06-15 16:09:51 <lf94        > Time to test this out
2025-06-15 16:37:30 <tabemann    > back
2025-06-15 16:37:33 <tabemann    > hey lf94
2025-06-15 16:45:14 <lf94        > morning tabemann !
2025-06-15 16:45:18 <lf94        > I havent started yet
2025-06-15 16:45:24 <lf94        > ate breakfast first
2025-06-15 16:45:59 <lf94        > I forget how to upload zeptoforth programs to the rp2040
2025-06-15 16:46:05 <lf94        > It was pretty easy
2025-06-15 16:46:32 <lf94        > dont tell me - reviewing the docs :)
2025-06-15 16:46:44 <lf94        > I want to do a PR after on where I had trouble and add to the docs
2025-06-15 16:55:54 <lf94        > Ah right, picocom, eth4com, etc...
2025-06-15 16:56:07 <lf94        > e4th
2025-06-15 16:57:10 <lf94        > Haha, nice. So yeah this RP2040 already has Zeptoforth from my last project
2025-06-15 16:57:13 <lf94        > > Built for rp2040, version 1.10.0, on Sat Feb 8 12:10:34 PM CST 2025
2025-06-15 16:57:33 <lf94        > It really has been 4 months then since my last Forth hacking
2025-06-15 16:59:10 <lf94        > Surface README doesn't remind me how to push entire forth files
2025-06-15 16:59:57 <lf94        > > codeload3.sh
2025-06-15 16:59:59 <lf94        > :o
2025-06-15 17:05:03 <lf94        > Yep got it, amazing
2025-06-15 17:05:14 <lf94        > Would be useful to have that more prominent
2025-06-15 17:05:41 <lf94        > How the heck do you include modules?
2025-06-15 17:05:45 <lf94        > Trying to include gpio.fs
2025-06-15 17:08:10 <lf94        > ah just "import"
2025-06-15 17:08:28 <tabemann    > back
2025-06-15 17:09:09 <lf94        > I keep getting stack underflow lol
2025-06-15 17:09:29 <lf94        > https://gist.github.com/lf94/4026749bfb818aea75aa696e236ef664
2025-06-15 17:09:48 <tabemann    > no, it's:
2025-06-15 17:09:50 <tabemann    > gpio import
2025-06-15 17:09:59 <tabemann    > gpio isn't a file you're including
2025-06-15 17:10:02 <tabemann    > this isn't C
2025-06-15 17:10:22 <tabemann    > rather it is a wordlist/module you are importing into the current search order
2025-06-15 17:10:36 <tabemann    > and I suggest you reboot at this point
2025-06-15 17:10:39 <lf94        > Agh sorry. It's been a bit
2025-06-15 17:10:44 <lf94        > Gotchya, will o
2025-06-15 17:10:46 <lf94        > do
2025-06-15 17:11:01 <lf94        > import gpio made sense to me because I thought `import` was a parse word
2025-06-15 17:11:13 <tabemann    > no, GPIO is a constant
2025-06-15 17:11:23 <tabemann    > whose value is a wordlist/module ID
2025-06-15 17:11:58 <lf94        > ahhh :)
2025-06-15 17:12:07 <lf94        > thinking too filesystem x)
2025-06-15 17:12:10 <lf94        > > unable to parse: alarm-set?
2025-06-15 17:12:17 <lf94        > I guess this isnt the correct word
2025-06-15 17:12:31 <tabemann    > you also need: timer import
2025-06-15 17:12:35 <lf94        > oh!
2025-06-15 17:12:37 <lf94        > right!
2025-06-15 17:12:54 <lf94        > sorry lol I feel like I'm annoying you with my mistakes :)
2025-06-15 17:13:06 <tabemann    > also, you'll need: interrupt import
2025-06-15 17:13:10 <lf94        > Nice, it all parsed
2025-06-15 17:14:00 <tabemann    > I suggest you try running START now (TURNKEY only does anything if you've compiled to flash and then rebooted)
2025-06-15 17:14:11 <lf94        > Yea I actually removed turnkey for now
2025-06-15 17:15:38 <lf94        > To be clear, to completely reset the device (bring zepto back to a starting state), I can do restore-state?
2025-06-15 17:20:27 <tabemann    > no
2025-06-15 17:20:32 <tabemann    > do REBOOT
2025-06-15 17:21:06 <tabemann    > RESTORE-STATE erases everything in flash after its 'factory state' and *then* reboots
2025-06-15 17:21:27 <tabemann    > if you just want to erase what you've compiled into RAM REBOOT will suffice
2025-06-15 17:22:16 <lf94        > oh I wanted that, a complete complete restore
2025-06-15 17:22:32 <lf94        > To be sure I had nothing of my previous project on here
2025-06-15 17:22:50 <lf94        > welp grounding pin 8 is not doing anything :')
2025-06-15 17:24:02 <lf94        > I need to go do some Father's day stuff
2025-06-15 17:24:15 <lf94        > https://gist.github.com/lf94/95d4b82c94ad8a6467708d6219c8cf6b
2025-06-15 17:24:33 <lf94        > ttyl, surely it's something basic
2025-06-15 17:26:55 <tabemann    > one error I always make with RP2040 and RP2350-based boards it to confuse GPIO numbering with pin numbering
2025-06-15 17:28:02 <tabemann    > good luck with your project!
2025-06-15 17:49:49 <tabemann    > hey szilard