2025-06-21 20:51:34 tabemann: _here we again_ 2025-06-21 20:51:44 Finally have time to try and finish this project. 2025-06-21 20:51:46 hey lf94 2025-06-21 20:52:08 Spent the last 2 evenings after work finding our little pet cornsnake. Found it this morning _inside_ the fridge. 2025-06-21 20:52:19 So tired 2025-06-21 20:52:27 did it survive the refrigeration? 2025-06-21 20:52:52 That's the thing, it was inside at the bottom of the unit - like between the inside of the bridge and its walls 2025-06-21 20:52:59 Near the warm compressor 2025-06-21 20:53:01 :) 2025-06-21 20:53:05 ah 2025-06-21 20:53:18 Anyway. 2025-06-21 20:53:26 On the last episode of ZeptoForth Fun... 2025-06-21 20:53:40 I was having issues with any pin interrupt firing 2025-06-21 20:53:58 Let's see what code I had here... 2025-06-21 20:55:08 do you have a gist or pastebin of your latest code? 2025-06-21 21:00:17 oh I found your bug 2025-06-21 21:00:18 ['] gpio-handler IO_IRQ_BANK0 vector! 2025-06-21 21:00:30 VECTOR! takes a vector index, not an IRQ index 2025-06-21 21:00:32 that should be 2025-06-21 21:00:37 ['] gpio-handler IO_IRQ_BANK0 16 + vector! 2025-06-21 21:01:39 lf94 2025-06-21 21:01:49 whoop! Sorry tabemann , chatting in another channel 2025-06-21 21:02:02 I can get you the latest code :) 2025-06-21 21:02:07 You probably do have it though 2025-06-21 21:02:09 that looks familira 2025-06-21 21:02:19 https://gist.github.com/lf94/95d4b82c94ad8a6467708d6219c8cf6b < this is what I have 2025-06-21 21:03:52 hit refresh 2025-06-21 21:03:59 I updated it with whatever I had on disk 2025-06-21 21:04:52 yeah, you've still got that line of code there 2025-06-21 21:05:03 you'll need to change it before it will work 2025-06-21 21:05:34 and I suggest you reboot if you haven't yet, because the old code will scribble on the vector table 2025-06-21 21:05:46 Oh this thing has been unplugged and replugged so many times lol 2025-06-21 21:05:53 Do I still need to reboot if I do that 2025-06-21 21:05:59 Roger! 2025-06-21 21:06:31 no 2025-06-21 21:06:42 power cycling will do the same thing here 2025-06-21 21:10:24 nice nice 2025-06-21 21:13:22 have you tried it with my suggested change? 2025-06-21 21:14:57 Adjusting GPIO quickly 2025-06-21 21:15:09 https://www.raspberrypi.com/documentation/microcontrollers/pico-series.html 2025-06-21 21:15:22 When I use GPIO1 is that pin 0 ? 2025-06-21 21:15:41 Like what's it's indexed at in the handler 2025-06-21 21:15:46 I guess that doesn't matter for our current test 2025-06-21 21:16:21 GPIO1 is pin 2 2025-06-21 21:16:50 remember, on the Pico pins are 1-indexed and take GND pins into account while GPIO's are 0-indexed and skip over GND pins 2025-06-21 21:17:16 On mine they're 0 indexed lol. 2025-06-21 21:17:28 On the board itself it starts at 0 2025-06-21 21:18:22 GPIO0 is pin 1, GPIO1 is pin 2, GND is pin 3, GPIO2 is pin 4, etc. 2025-06-21 21:18:26 https://ae-pic-a1.aliexpress-media.com/kf/S007c8bf2d9db4132b9be27ade740d1a2s.jpg_960x960q75.jpg_.avif 2025-06-21 21:18:39 I see now. 2025-06-21 21:18:48 I really needed *this* pinout diagram and not the other one. 2025-06-21 21:18:52 Completely different lol. 2025-06-21 21:19:04 ah 2025-06-21 21:19:19 Pin 9 is GPIO12 2025-06-21 21:19:21 on the backside 2025-06-21 21:19:23 like what lol. 2025-06-21 21:20:09 those look like they are meant for use with pogo pins or something 2025-06-21 21:20:34 you *could* solder something onto them if you're good at soldering (I'm not) 2025-06-21 21:21:59 be aware of that those images don't seem to involve actual rotation of the board as you would get in Real Life when handling it 2025-06-21 21:22:42 heh 2025-06-21 21:22:48 I'm looking for the code upload script you've got... 2025-06-21 21:22:54 _checks README_ 2025-06-21 21:23:30 Ah, codeload3! 2025-06-21 21:23:48 utils/codeload3.sh -B 115200 -p serial 2025-06-21 21:24:47 yeah it's named codeload3 because there was originally a codeload.py written by the maintainer of STM8eForth, and I got in touch with him and asked him if I could use his script and if he could adapt it for Python 3, which he graciously did, hence codeload3.py 2025-06-21 21:25:06 ah nice 2025-06-21 21:25:09 then someone else wrote a wrapper around it in shell so it would automatically locally install pySerial with pip if it was not already installed 2025-06-21 21:25:15 I would honestly put codeload3.sh right at the top 2025-06-21 21:25:24 It's easy to lose 2025-06-21 21:25:29 But it's massively useful 2025-06-21 21:25:53 yeah 2025-06-21 21:26:05 Why is /dev/ttyACM0 not working 2025-06-21 21:26:07 lol 2025-06-21 21:26:30 It's present in /dev/ 2025-06-21 21:26:38 $ ~/Downloads/zeptoforth-1.10.0/utils/codeload3.sh -B 115200 -p /dev/ttyACM0 serial start.fth 2025-06-21 21:26:40 Error: TTY device /dev/ttyACM0 invalid 2025-06-21 21:26:59 maybe you don't have your dialout group set up properly 2025-06-21 21:27:08 ohhh 2025-06-21 21:27:15 Yep that did it 2025-06-21 21:27:17 sudo helped 2025-06-21 21:28:16 Fuck yea! 2025-06-21 21:28:23 That did it - we got some hellos! 2025-06-21 21:28:43 Oh shit lol 2025-06-21 21:29:02 I guess there's enough ... voltage drop? for the interrupt to fire on edge fall! 2025-06-21 21:29:06 From my hand 2025-06-21 21:29:09 That's amazing 2025-06-21 21:29:51 cool! 2025-06-21 21:30:21 which hemisphere are you in? 2025-06-21 21:30:28 Northern 2025-06-21 21:30:36 I'm in Cana 2025-06-21 21:30:40 Montreal Canada 2025-06-21 21:30:53 so it's summer where you are, so if there's any moisture on your hands to conduct electricity... 2025-06-21 21:31:06 I'm holding onto the coil of copper 2025-06-21 21:31:26 I thought I'd have to touch the pin to ground 2025-06-21 21:31:37 you're the ground 2025-06-21 21:31:38 But no; the act of my hand touching a bunch of copper is enough 2025-06-21 21:31:40 yea! 2025-06-21 21:31:48 Very cool 2025-06-21 21:32:47 so it works! 2025-06-21 21:33:15 next is see if the timer interrupt is working correctly 2025-06-21 21:33:40 one minor note, though 2025-06-21 21:34:55 you're not supposed to write to the console inside an interrupt handler, like that set up with SET-ALARM 2025-06-21 21:35:05 What should I do? 2025-06-21 21:35:25 create a task which you notify 2025-06-21 21:35:30 and have that task to the output 2025-06-21 21:36:39 sounds complex lol 2025-06-21 21:37:25 Why shoulnt I do it inside the interrupt handler? 2025-06-21 21:37:49 I'm already thinking of a solution: variable output -> tight running interrupt that checks this 2025-06-21 21:37:54 flush the output 2025-06-21 21:37:58 etc 2025-06-21 21:42:22 https://gist.github.com/tabemann/fb7724a563c6bec0db6983b4d1c36af4 2025-06-21 21:43:28 the reason is that if outputting to the console blocks, and if the outputting interrupt is higher priority/same priority but lower index than the USB or UART interrupt being used for the console... 2025-06-21 21:44:07 also, even if you make it lower priority, it will try to switch tasks if it blocks, which is probably not what one wants 2025-06-21 21:44:19 try that 2025-06-21 21:44:59 ah gotchya. 2025-06-21 21:47:49 Oh wow 2025-06-21 21:48:04 Ok, you were talking about a real interface you've written 2025-06-21 21:48:07 This is sick 2025-06-21 21:49:17 task notifications are a nice feature of zeptoforth 2025-06-21 21:49:41 and unlike most of the other intertask communication constructs in zeptoforth, it's safe to notify a task from within an interrupt handler 2025-06-21 21:49:57 they're very lightweight and fast too 2025-06-21 21:50:04 Would you feel bad if I tried to do this with another timer interrupt ? 2025-06-21 21:50:28 no, it's not good practice in zeptoforth to talk to the console with a timer interrupt 2025-06-21 21:50:45 for the reason I mentioned above 2025-06-21 21:50:46 Ah, shoot! Ok in this case, is that a hot loop? how is it waiting? 2025-06-21 21:50:55 Where does the "task go" to run? 2025-06-21 21:51:13 0 mailbox ! 2025-06-21 21:51:14 0 [: 2025-06-21 21:51:14 mailbox-right and if output.dash then 2025-06-21 21:51:16 again 2025-06-21 21:51:18 ;] 320 128 768 spawn output-task ! 2025-06-21 21:51:20 mailbox 1 output-task @ config-notify 2025-06-21 21:51:24 output-task @ run 2025-06-21 21:51:37 the task that is running is between [: and ;], which define a 'quotation' 2025-06-21 21:51:51 A quotation on a whole routine? :o 2025-06-21 21:51:51 you could make it a separate word if you wanted to though 2025-06-21 21:52:00 first time Ive seen this in a forth, very cool! 2025-06-21 21:52:14 it's not standard ANS Forth, even though many Forths have these 2025-06-21 21:52:28 Ah ok. I will refactor it to be a separate word then, I'd like to try and stick to what's normally available in forths 2025-06-21 21:52:43 Right, the most I've seen is ' (quote) 2025-06-21 21:52:49 But it's much weaker 2025-06-21 21:52:51 quotations are your friend, and are idiomatic zeptoforth :) 2025-06-21 21:53:14 I'll move to more idiomatic zeptoforth when i'm a bit more experienced in normal forth hehe 2025-06-21 21:53:19 ['] will make an xt out of a named word as a literal compiled into the word being, well, compiled 2025-06-21 21:53:24 (hope you understand <3) 2025-06-21 21:53:48 320 128 768 spawn <- what's this do 2025-06-21 21:53:49 ' won't do what you want it to here 2025-06-21 21:54:04 No no I know, I mean I think it's the closest thing I've seen to "quotation" in forth 2025-06-21 21:54:13 SPAWN creates a new task (but does not start it) 2025-06-21 21:54:13 I know it's to get the xt in most cases 2025-06-21 21:54:47 we store the spawn id into output-task 2025-06-21 21:54:48 it has the signature ( ... x0 count xt ram-dict-size data-stack-size return-stack-size -- task ) 2025-06-21 21:54:54 Oh! 2025-06-21 21:54:59 the sizes are all in bytes 2025-06-21 21:55:04 woooow 2025-06-21 21:55:12 That's really, REALLY dang nice! 2025-06-21 21:55:30 and everything before count is copied into the stack that xt is initially executed with 2025-06-21 21:55:43 count is how many things you want to copy 2025-06-21 21:55:44 mailbox 1 taskid config-notify <- and this? 2025-06-21 21:56:06 that configures the task to have one mailbox, at address MAILBOX 2025-06-21 21:56:29 oh you can do mailbox 2 even? 2025-06-21 21:56:29 you need to do that before you can notify the task 2025-06-21 21:56:37 if you make MAILBOX a double cell 2025-06-21 21:56:40 OK do tasks actually "sleep" ? 2025-06-21 21:57:04 note that a task can only wait on one mailbox at a time, but a trick I use here is I use multiple bits in that mailbox as flags 2025-06-21 21:57:21 nice 2025-06-21 21:57:28 That sounds like a weird pattern though right? 2025-06-21 21:57:37 Wouldn't you spawn multiple tasks with their own mailbox 2025-06-21 21:57:41 WAIT-NOTIFY-SET-INDEFINITE will indefinitely wait on a mailbox, when the mailbox is notified it will return its value and atomically set it to the value passed in 2025-06-21 21:57:53 tasks are expensive in zeptoforth 2025-06-21 21:58:04 Ah. 2025-06-21 21:58:10 and also you can make this deterministic 2025-06-21 21:58:26 Can't I have a hot loop at the end of my program that instead does some checking? 2025-06-21 21:58:28 it will always check for the MAILBOX-LEFT bit before checking for the MAILBOX-RIGHT bit 2025-06-21 21:59:16 whereas if you make two separate tasks for this with separate mailboxes, you can't guarantee the order in which they will be serviced 2025-06-21 21:59:35 it isn't recommended to notify the main task 2025-06-21 21:59:45 Lemme show you what I mean 2025-06-21 21:59:53 so you'll need to put in a spinwait or a spin-with-pause wait if you do that 2025-06-21 21:59:56 Basically a hot loop at the end that's always checking some value 2025-06-21 22:00:05 and you handle all 'events' here 2025-06-21 22:00:08 whereas WAIT-NOTIFY-SET-INDEFINITE does not spin 2025-06-21 22:00:12 I guess an event loop is what I'm saying 2025-06-21 22:00:37 you're going to be creating flags and then checking them in your loop you mean? 2025-06-21 22:00:42 ya 2025-06-21 22:00:51 variable event <- has event flags 2025-06-21 22:01:00 variable event.data <- holds the data 2025-06-21 22:01:46 why have separate events and data when the events can be characterized as singular entities? 2025-06-21 22:01:59 literally the only reason is "simpler" 2025-06-21 22:02:04 otherwise I agree 2025-06-21 22:02:11 I guess "cheaper" too 2025-06-21 22:02:13 you'll have to spin or spin-with-pause then 2025-06-21 22:02:27 Mhm. How do you spin-with-pause? 2025-06-21 22:02:35 it might be cheaper in RAM, but it's not cheaper in CPU time 2025-06-21 22:02:44 Right, much more $ cpu 2025-06-21 22:03:07 BEGIN CHECK-MY-EVENT? IF DO-STUFF THEN PAUSE AGAIN 2025-06-21 22:03:27 Oh there is a pause word, beeeaauty 2025-06-21 22:03:48 PAUSE results in a task voluntarily reliquishing control and getting rescheduled 2025-06-21 22:04:06 it's not ANS Forth but basically any multitasking Forth has it 2025-06-21 22:04:18 awesome 2025-06-21 22:05:16 note that if you have no other tasks here you *could* omit the PAUSE, but as soon as you have multiple tasks omitting the PAUSE will result in the spinning task unnecessarily sucking up lots of CPU time 2025-06-21 22:05:42 note that in some cases this is desirable if you are waiting short periods of time though 2025-06-21 22:06:10 short periods of time being like < 1 ms 2025-06-21 22:06:45 https://gist.github.com/lf94/95d4b82c94ad8a6467708d6219c8cf6b 2025-06-21 22:07:01 'stupid simple' I know 2025-06-21 22:07:39 the problem with this approach is that if a dot and a dash occur in very close succession one of them might get lost 2025-06-21 22:08:01 I believe they can't due to the interrupt logic 2025-06-21 22:08:09 Always N time between each 2025-06-21 22:08:48 no, LEFT and RIGHT could be detected by the interrupt at the same time 2025-06-21 22:09:15 Would they really be at the same time 2025-06-21 22:09:21 and then you would always get a single dash 2025-06-21 22:09:23 One surely needs to be processed first? 2025-06-21 22:09:41 Yeah. When both are pressed, they are then time sequenced 2025-06-21 22:09:53 That's the behavior of electronic keyers for this device 2025-06-21 22:09:55 with your code RIGHT always wins 2025-06-21 22:10:17 I'd like LEFT to always win but yea that's intentional 2025-06-21 22:10:44 How is it that RIGHT wins first =_= 2025-06-21 22:11:09 :noname 2025-06-21 22:11:09 ALARM_PROCESS_PADDLE clear-alarm-int 2025-06-21 22:11:10 LEFT paddle.request-check bic! 2025-06-21 22:11:12 then 2025-06-21 22:11:14 paddle.request-check @ RIGHT and if 2025-06-21 22:11:16 output.dash 2025-06-21 22:11:18 RIGHT paddle.request-check bic! 2025-06-21 22:11:19 Oh because of the overwrite? 2025-06-21 22:11:20 then 2025-06-21 22:11:24 paddle.request-check.none? if paddle @ paddle.request-check ! then 2025-06-21 22:11:26 1000 1000 * 1 * set-alarm-process-paddle 2025-06-21 22:11:28 ; is paddle.on.timer 2025-06-21 22:11:30 you set a dot for LEFT then you set a dash for RIGHT 2025-06-21 22:11:32 yes 2025-06-21 22:11:46 Agh ok yea, gotta fix that 2025-06-21 22:11:54 The intent is 100% for LEFT to always win first 2025-06-21 22:12:07 then you need to switch around the order of those two 2025-06-21 22:12:25 I'd rather use else 2025-06-21 22:12:33 Too hard to decipher otherwise 2025-06-21 22:12:37 you could use ELSE too 2025-06-21 22:12:52 That was a really good catch though 2025-06-21 22:12:57 You're amazing man lol 2025-06-21 22:14:58 Hm 2025-06-21 22:15:01 Nothing for some reason 2025-06-21 22:15:59 EVENT_HAS_DATA event = if 2025-06-21 22:16:00 should be 2025-06-21 22:16:03 EVENT_HAS_DATA event @ = if 2025-06-21 22:16:07 derp 2025-06-21 22:16:15 I really need to write a forth linter 2025-06-21 22:16:25 It'd help so much with memorization 2025-06-21 22:17:12 going to refactor to : event.has event @ EVENT_HAS_DATA = ; 2025-06-21 22:17:31 or maybe event.data.has 2025-06-21 22:17:45 note that you can just make EVENT a boolean 2025-06-21 22:17:52 so you just do event @ if 2025-06-21 22:18:06 no need for EVENT_HAS_DATA or like 2025-06-21 22:18:12 yea 2025-06-21 22:18:23 Trying to have *some* amount of abstraction though :p 2025-06-21 22:18:26 It's mostly for practice 2025-06-21 22:18:40 I may need to reuse this event mental model in the future (likely) 2025-06-21 22:18:50 I ordered 8 more RP2040 this morning :) 2025-06-21 22:18:52 but that's like writing if(TRUE == foo) { bar(); } in C 2025-06-21 22:19:09 yep yep, totally. 2025-06-21 22:19:17 It's mostly a mental exercise for me 2025-06-21 22:20:59 Nevermind you're right for this, and in most cases, this'll always be true/false 2025-06-21 22:21:30 variable event 2025-06-21 22:21:32 variable event.data 2025-06-21 22:21:34 : event! event.data ! Event.HasData event ! ; 2025-06-21 22:21:36 : event? event @ FALSE <> ; 2025-06-21 22:21:38 Beauty 2025-06-21 22:21:49 Whoops Event.HasData -> should just be "TRUE" 2025-06-21 22:22:20 you can just write : event? event @ ; 2025-06-21 22:22:31 Or right because of how if works 2025-06-21 22:22:34 perfect 2025-06-21 22:22:52 Hm, but still, feels bad 2025-06-21 22:23:05 I feel like `if` should consume -1 or 0 2025-06-21 22:23:10 never anything else 2025-06-21 22:23:14 Is that a bad way to think? 2025-06-21 22:23:39 but if event is a boolean... 2025-06-21 22:23:46 it would be -1 or 0 anyways 2025-06-21 22:24:04 and in any case, at least I myself frequently use IF with values other than -1 or 0 2025-06-21 22:24:12 For now it is but in another project it could be something else 2025-06-21 22:24:17 Like 0 and a bunch of flags 2025-06-21 22:24:22 Ok ok, nice. 2025-06-21 22:24:32 e.g. FOO @ BAR AND IF BAZ THEN 2025-06-21 22:24:33 Yeah, recently, I realized I could use `if` with 0 or anything-but-0 2025-06-21 22:24:45 Not sure why I boxed myself into thinking I needed 0 or -1 2025-06-21 22:25:19 probably Python or like :) 2025-06-21 22:25:59 Isn't there a particular word in forth that requires true to be -1? 2025-06-21 22:26:04 I swear there was 2025-06-21 22:26:25 it is recommended that when passing a *boolean* value into another word to use -1 or 0 2025-06-21 22:26:45 just in case that word then passes it into any of AND XOR or NOT 2025-06-21 22:26:59 but IF is safe to use with any value 2025-06-21 22:27:34 (NOT is INVERT in ANS Forth BTW) 2025-06-21 22:28:07 I mean... for and, xor, or... it makes sense 2025-06-21 22:28:08 (this was decided by committee because in figFORTH NOT was like C ! but Forth-83 NOT was a bitwise inverse) 2025-06-21 22:28:13 because they're all bitwise 2025-06-21 22:28:17 yeah 2025-06-21 22:28:50 Yea hm, still not working 2025-06-21 22:29:11 (refresh) 2025-06-21 22:29:53 Ah maybe 0 event ! 2025-06-21 22:29:55 Should be inside 2025-06-21 22:30:02 yes. 2025-06-21 22:30:34 nope still nothing 2025-06-21 22:31:23 is there a (normal) LED on your board? 2025-06-21 22:31:29 nope 2025-06-21 22:31:33 because you could try toggling it on input 2025-06-21 22:31:34 It's the multicolor one 2025-06-21 22:31:39 in your interrupt handler 2025-06-21 22:31:41 :( 2025-06-21 22:31:53 I mean this was working before 2025-06-21 22:31:56 In the interrupt handler 2025-06-21 22:32:08 I'll try removing the pause 2025-06-21 22:32:47 put 0 event ! as FALSE event ! inside the IF ... THEN 2025-06-21 22:32:57 Ooop got one - randomly 2025-06-21 22:33:36 also, you need to initialize EVENT and EVENT.DATA 2025-06-21 22:33:52 because you are using them uninitialized here 2025-06-21 22:34:01 I thought variable set as 0 by default 2025-06-21 22:35:42 Weird touching the 3.3v to the pins causes them to fire randomly too 2025-06-21 22:36:16 Gotta be something basic going on 2025-06-21 22:37:47 VARIABLE does not initialize things in zeptoforth 2025-06-21 22:41:50 are you touching the pins to GND? 2025-06-21 22:42:25 Yeah. 2025-06-21 22:48:30 Added more elses 2025-06-21 22:48:33 Same deal though 2025-06-21 22:48:47 (refresh) 2025-06-21 22:49:20 Adding back `type` to the gpio handler 2025-06-21 22:49:25 Just to see if it's reaching 2025-06-21 22:50:43 no need for 0 event.data ! in event.clear 2025-06-21 22:50:55 also, the way its written it may try to output null bytes 2025-06-21 22:51:11 It's not reaching the gpio handler 2025-06-21 22:51:15 aaaaaaaaaa 2025-06-21 22:51:36 removing the event loop 2025-06-21 22:52:04 Nope nothing is working at all 2025-06-21 22:52:08 maybe it's the emit? <_> 2025-06-21 22:52:56 Something's fucked with this wire maybe 2025-06-21 22:53:06 I took it off ground and now it's showing output 2025-06-21 22:53:16 Maybe my pins are not configured correctly still 2025-06-21 22:54:27 you configured it to trigger on both falling and rising edges 2025-06-21 22:54:41 Righth 2025-06-21 22:55:05 try adding: 2025-06-21 22:55:13 FALSE GPIO_PADDLE_LEFT PADS_BANK0_PDE! 2025-06-21 22:55:13 Maybe these headers I soldered on are fucked 2025-06-21 22:55:17 and 2025-06-21 22:55:17 ok 2025-06-21 22:55:22 FALSE GPIO_PADDLE_RIGHT PADS_BANK0_PDE! 2025-06-21 22:55:49 oh shit maybe that worked 2025-06-21 22:56:22 I'm seeing stack overflow immediately 2025-06-21 22:56:25 on the upload 2025-06-21 22:56:29 with my "hello" :o 2025-06-21 22:56:33 So it definitely did something 2025-06-21 22:56:51 God damn if this is it that's crazy 2025-06-21 22:57:04 I would expect PUE to make PDE false implicitly 2025-06-21 22:58:39 it doesn't 2025-06-21 22:58:43 they're two separate bits 2025-06-21 22:58:52 that's kinda crazy dont you think? 2025-06-21 22:59:08 yeah this is working now I think 2025-06-21 22:59:36 I think I know why it is 2025-06-21 22:59:48 you're using the same GPIO as one of the serial console GPIO's 2025-06-21 23:00:00 Oh my fuck really :facepalm: 2025-06-21 23:00:08 if you were using GPIO's other than 0 or 1 PDE would be FALSE by default 2025-06-21 23:00:16 I'll try 14 and 15 instead 2025-06-21 23:01:45 I was using GPIO 7 and 8 though? 2025-06-21 23:02:02 my bad yes 2025-06-21 23:02:05 ignore my comment 2025-06-21 23:02:29 I keep getting stack underflow now 2025-06-21 23:02:33 hmmm 2025-06-21 23:03:06 (refresh) anything that pops out? 2025-06-21 23:04:18 Gotta be something in my gpio handler 2025-06-21 23:05:05 Yep 2025-06-21 23:05:21 It's blasting output 2025-06-21 23:05:38 Maybe edge high/low is bad... 2025-06-21 23:05:50 level high low might be the way to go 2025-06-21 23:07:30 don't do level high 2025-06-21 23:08:00 I tried your code with the stuff commented out and it didn't do anything for me, good or bad 2025-06-21 23:08:29 From what I understand gpio-handler is being fired a stupid amount of times 2025-06-21 23:08:34 with the current setup 2025-06-21 23:08:59 That shouldnt be the case - it should fire _once_ per edge rise, and _once_ per edge fall 2025-06-21 23:09:07 Maybe I need to clear all the edge registers 2025-06-21 23:10:40 Now nothing is firing 2025-06-21 23:10:48 I feel so stupid lol. 2025-06-21 23:13:25 Wanna break out your RP2040 ? :D. 2025-06-21 23:15:11 back 2025-06-21 23:15:19 oh I know why! 2025-06-21 23:15:22 I'm using an RP2350 2025-06-21 23:15:28 it's got a different interrupt! 2025-06-21 23:15:54 _cocks gun_ 2025-06-21 23:15:57 Lol 2025-06-21 23:20:11 something is weird for me 2025-06-21 23:20:32 it's outputting dots and dashes continually as .-.-.-.- with one character being output every second 2025-06-21 23:31:06 now I moved the EVENT! inside the GPIO interrupt handler and nothing happens 2025-06-21 23:36:55 hmm it still isn't working for me 2025-06-21 23:40:58 okay, for starters, you need to always check every GPIO edge in the GPIO interrupt handler 2025-06-21 23:41:11 you can't do IF this ELSE that THEN 2025-06-21 23:41:21 because both may be true 2025-06-21 23:41:36 and if you don't clear both, it'll potentially loop forever 2025-06-21 23:41:44 but fixing that still didn't fix it 2025-06-21 23:42:26 okay, I'll be away for a bit 2025-06-21 23:45:56 Sorry, Dad had called 2025-06-21 23:46:01 Ok sounds good! 2025-06-21 23:48:33 tabemann: that was it 2025-06-21 23:48:36 I needed to clear both 2025-06-21 23:48:41 It's actually working perfectly now 2025-06-21 23:48:44