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