<tabemann>
you can do things like : larger > [: ." larger" ;] [: ." not larger" ;] choose ;
<crc>
are te if/else/then forms more efficient than using quotations in zeptoforth?
rdrop-exit has joined #forth
jsoft has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<rdrop-exit>
good morning Forthwrights c[]
<tp>
morning Forthlings
<rdrop-exit>
tabemann, I assume the reason you continue to use IF is that it's more efficient both in space and speed
iyzsong has joined #forth
<tabemann>
rdrop-exit: that too
<tp>
I have a question, it's regarding Mecrisp-Stellaris so may not be answerable: Ive made a simple scheduler, all it does is run a word every 1000 tics in a endless loop. Is there a simple way to pass control to the terminal during the time it isnt running the word. Must I use a multitasker ?
<rdrop-exit>
hi tp
<tp>
g'day Zen Guru of Forthiness
<tabemann>
hey guys
<tp>
g;day tabemann
<tabemann>
I don't know about mecrisp-stellaris, but doing that in zeptoforth requires a multitasker
<tabemann>
of course the zeptoforth idiom is to have two tasks, one for the REPL and one for the asynchronous stuff, which all goes in a single scheduler
<tabemann>
like I have a blinky demo that has two task but eight different asynchronous actions all sharing one of those two tasks
<tp>
veltas, I agree with a lot Chuck's C sentiments, but I'm not into color Forth as I can still read 12 pt text on a large hires screen
<tp>
tabemann, so the terminal is just a normal Forth task in a non multitasking system ?
<tp>
tabemann, and this gets back to what you said the other day re not being able to read the TIB any old time ?
<tabemann>
in zeptoforth the REPL is the first task that is created, and is only special in that dictionary space is stolen from it each time another task is created
<tabemann>
the issue with the TIB is that you can't write into it at any given time, because the REPL may be reading from it at that time
<tabemann>
which is why the USART interrupt can't inject data directly into the TIB
<tp>
aha
<tabemann>
(I just realized a way that zeptoforth is different from Mecrisp-Stellaris - it supports interrupts and sleeping right out of the box)
<tp>
Mecrisp-Stellaris supports interrupts right out of the box
<tp>
it also has some additional sleeping words
<tp>
that arent part of the core
<tabemann>
at least from what I gathered mecrisp-stellaris doesn't use interrupt-driven IO in the kernel itself (which is also true of zeptoforth)
<tabemann>
however, is there extra code the user can load which enables it?
<tabemann>
I didn't see any for stm32l476
<tp>
no interrupts are needed for any default Mecrisp-Stellaris although they are enabled. You can turn interrupts off and Mecrisp-Stellaris runs normally
<tp>
cortex-m doesn't have a "interrupt-driven IO" facility afaik, the closest to that would be MSP430
<tp>
and "mecrisp" can use that for the USART
<tp>
tabemann, do you mean 'USART' when you say " interrupt-driven IO" ?
<tabemann>
I mean IO driven by the USART interrupt
<tp>
tabemann, "IO" in the hardware sense refers to *any* peripheral
<tabemann>
well yes
<tp>
tabemann, typically "IO" is used by programmers in a very limited sense in my experience
<tp>
I only mention it as the use of "IO" is very ambiguous to hardware people
<tabemann>
in this case I mean serial IO
<tp>
tabemann, in that case, no, Mecrisp-Stellaris has no facility for USART interrupts as default and I'm not aware of any
<tp>
tabemann, probably because matthias leaves that to the users and only provides the basics as he hates cortex-m
<tp>
tabemann, I think I may have see a user contributed serial interrupt contribution for one of the many cortex-m variants
TCZ has quit [Quit: Leaving]
<tp>
tabemann, there is ethernet terminal access for the M4 Ti-Tiva and it is flawless
<tabemann>
I specifically implemented interrupt-driven serial IO in the code packaged with zeptoforth because it resolves problems I was seeing with IO with multitasking
<tp>
thats as standard
<tabemann>
and also because it enables sleeping
<tp>
tabemann, and I think thats fantastic, I wish Mecrisp-Stellaris had it out of the box
<tabemann>
the problem was that if one of the tasks was a bit too slow, serial IO'd get all fucked up
<tp>
I've noticed that with Mecrisp-Stellaris multitasking myself
<tabemann>
whereas by handling serial IO in an interrupt handler, serial IO is much smoother and far less error-prone
<tp>
and that makes perfect sense
<tp>
maybe i'll copy your code into Mecrisp-Stellaris :)
<tabemann>
lol
<tp>
tabemann, as the serial stuff is slow, does it take up a big slice of interrupt handler time ?
<tp>
hmm; Oil prices in the US have crashed below zero for the first time in history as demand for energy plummets amid the coronavirus pandemic. The plunge into negative territory led to a bizarre situation where traders were being paid more than $40 to buy a barrel of oil.
<tabemann>
yeah I heard about that
<tp>
I could handle that, being paid to fill up my car!
<tabemann>
I'd be worried what that'd do to the economy though
<tabemann>
beyond what's already going on
<tp>
yeah, I'm only jesting
<tp>
tabemann, I'll have to have a look at your code now, re interrupt driven IO
<tp>
tabemann, I remembered you needed a buffer but eventually were able to do with a smallish one ?
<tabemann>
I decided to go for a bigger one, to give slow tasks more leeway
<tabemann>
if one wants to save memory though one can always shrink the buffers
<tabemann>
okay, more documentation on lambdas and combinators has been committed...
Zarutian_HTC| has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
<Zarutian_HTC|>
forth going functional
rdrop-exit has quit [Quit: Lost terminal]
rdrop-exit has joined #forth
<rdrop-exit>
It's like deja vu all over again -- Yogi Berra
dddddd has quit [Ping timeout: 256 seconds]
dave0 has quit [Quit: dave's not here]
jedb_ has joined #forth
jedb has quit [Ping timeout: 256 seconds]
reepca` has quit [Ping timeout: 240 seconds]
gravicappa has joined #forth
jsoft has quit [Ping timeout: 265 seconds]
rdrop-exit has quit [Ping timeout: 256 seconds]
mtsd has joined #forth
rdrop-exit has joined #forth
ntry has joined #forth
rdrop-exit has quit [Read error: Connection reset by peer]
rdrop-exit has joined #forth
rdrop-exit has quit [Ping timeout: 256 seconds]
rdrop-exit has joined #forth
TCZ has joined #forth
xek has joined #forth
rdrop-exit has quit [Ping timeout: 250 seconds]
dys has joined #forth
ntry has quit [Remote host closed the connection]
ntry has joined #forth
rdrop-exit has joined #forth
ntry has quit [Remote host closed the connection]
ntry has joined #forth
jsoft has joined #forth
rdrop-exit has quit [Ping timeout: 256 seconds]
rdrop-exit has joined #forth
TCZ has quit [Quit: Leaving]
WickedShell has quit [Remote host closed the connection]
jsoft has quit [Ping timeout: 256 seconds]
dddddd has joined #forth
TCZ has joined #forth
<rdrop-exit>
c[]
<jackdaniel>
a predator sitting besides a letter c.. a moment later
<jackdaniel>
[c]
<rdrop-exit>
ouch :)
<rdrop-exit>
you broke my coffee cup
<jackdaniel>
sorry about that!
<rdrop-exit>
np, have plenty more c[]
<tp>
C[c] a bigger predator lurks nearby
<rdrop-exit>
my poor little espresso cup
* tp
finishes off a few utils in his blue pill developer edition binary
<rdrop-exit>
blue pillers await with bated breath
ntry has quit [Quit: Leaving]
<tp>
I've told both of them to be patient
<rdrop-exit>
:-))
<tp>
:)
dave0 has joined #forth
TCZ has quit [Quit: Leaving]
mtsd has quit [Quit: Leaving]
TCZ has joined #forth
jedb__ has joined #forth
jedb_ has quit [Ping timeout: 250 seconds]
jsoft has joined #forth
<DKordic>
tabemann: ""lambda""? How to create ""mk-counter""?