<tp>
I've heard the terms but dont know what they mean
jedb has joined #forth
<crest>
SIGINT and SIGTERM?
<tp>
yes
<crest>
that ctrl+c is safe now
<tp>
ahh
<tp>
thanks
<crest>
in unix signals are like userspace interrupts
<tp>
oh
<tp>
what ctrl+d ?
<tp>
what was
<crest>
they allow the kernel signal the running thread async
<crest>
ctrl+d is used to encode end of transmission
<tp>
ah
<crest>
ctrl+c causes the kernel to a signal to the process running in the foreground on the terminal you pressed it in
<crest>
the default handler for SIGTERM just kills the process
<crest>
pkill swd2 would do almost the same it would send SIGTERM instead of SIGINT
<crest>
but both have the same default handler
<tp>
swdcom is almost good enuf to replace my current setup, all it needs is a automated way to get the $address and some way to receive scripted output from the mcu
<tp>
ah, that makes sense
<crest>
would it be good enough to wait for some pattern in the output
<crest>
and output everything before that pattern
<tp>
sure
<tp>
in fact thats the best way anyway
Zarutian_HTC| has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
<crest>
i really want to implement proper file uploading without disconnecting the user from the forth system
<crest>
and i don't know how much swdcom impacts the realtime properties of the system by stealing cycles from shared busses
<tp>
in a way, that method is legacy
<crest>
which method?
<tp>
file uploading without disconnecting the user from the forth system
<crest>
why?
<tp>
a more modern way is to upload independently and feed errors into a editor
<crest>
think about it like running tee on your output
<tp>
because a Forth system doesnt need the terminal always connected
<tp>
yes, I did that last night, works great
<crest>
you can keep a scrollable interactive connection
<crest>
and still upload from your editor
<crest>
if i get it correct
<tp>
I only use the terminal when experimenting, just a few lines here and there. Modern micros arent that easy to experiment with, they usually need a dozen lines uploaded and thats easier from a editor I find
<tp>
in the old days they didnt have all the stuff a micro has now
<crest>
i want to write some words, upload them try them out and move on
<crest>
e.g. : blink ( pin speed -- ) ... ;
<tp>
youll nedd more than that
<tp>
I've written tons of embedded forth, I find it's easier from a editor, click make, the source is uploaded... why do it by hand in a terminal ?
<tp>
is this some retro fetish ? ;-)
<crest>
maybe because my vim setup isn't done yet?
<tp>
in my case it's all done thru a make file, works with vim or any editor that has a make button
<tp>
nothing special there
<tp>
frankly I love forth, it's all I use, but I couldnt make anything the old Forth way, it's just far too sloe
<tp>
slow
<tp>
embedded tech has moved on and in some ways, Forth hasnt kept up
Zarutian_HTC| is now known as Zarutian_HTC
<tp>
mainly in the source upload area
<tp>
I mean, Matthias and Robert Clausecker have just designed a edu board for teaching assembly and maybe forth, it's based on a MSP430 because cortex-m is too complex
<tp>
and cortex-m is massively complex, you need special tools to deal with it, the old terminal is just not capable
<crest>
i introduced a name collsion between the function now and the variable now
<crest>
i renamed the function
<tp>
no problem, I dont understand most of it anyway
<tp>
(technician)
<tp>
working :)
<tp>
ctrl+c = Closing ST-LINK/V2 handle.
<tp>
i found a problem with one of my Forth apps last night thanks to swdcom
<crest>
how?
<tp>
I use 'calltrace.fs' to show me what exception has crashed my project and it printed the usual calltrace stuff after my program ran. But this time instead of needing to reset the board, it all kept working. The board had reset and swdcom didnt care
<tp>
I dont know yet, but it doesnt show up with my screen system
<tp>
it's a ihex dumper and I suspect that it's reading memory it shoudnt
<tp>
i reverted to my old ihex dumper and it works fine with swdcom
<tp>
so the problem is in my code somewhere
<tp>
it's kinda cool to have a terminal not affected by the board reset, tho I can see it on the still connected serial terminal while swdcom is runing
<crest>
on reset my init word atomically overwrites all ring buffer read and write positions with zeroes
<tp>
yes
<tp>
because I dont use your clock stuff Ive added :
<tp>
: swdcom ( -- )
<crest>
you should keep the 0 swd !
<tp>
." The swd buffer address is: " swd hex. cr
<tp>
;
<tp>
0 swd !
<tp>
swd-console
<tp>
and i just call swdcom
<tp>
from init
<crest>
that should work
<tp>
that way I just grab the same block of code (and watch out for a change of naming) and drop it into my project
<tp>
yeah works fine as expected
jedb has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
dddddd has quit [Ping timeout: 246 seconds]
<tp>
crest, if you add this ".equ debug, 1" to mecrisp-stellaris-stm32f103.s and recompile then .regs will show the mcu registers
<crest>
is there an existing word to write to a register?
<crest>
something like $1234567 0 reg!
<tp>
no, only if the 'assembler-m0' is uploaded
<tp>
but it's obvious from the assembly what happens
<tabemann>
back
<tabemann>
hey guys
<tp>
hey tabemann, swdcom is coming along nicely thanks to crest, ctrl+c now exits properly
<crest>
and requires a m0 instead of m3/m4
<tp>
crest, no, the m3/m4 are backward compatible
<tp>
crest or you can do inline machine code using output from your favorite m3/m4 assembler
<crest>
loading a constant into a register about as easy as things get
<tp>
exactly
<crest>
or even better just move from the top of stack register
<tp>
I suggest R11
<crest>
makes sense
<tp>
Mecrisp-Stellaris doesnt use it
<crest>
not saved by hardware
<tp>
crest and a register should be easy to read with swd ?
<crest>
stlink_read_reg()
<tp>
that easy ?
<tp>
it cnt be that easy!
<crest>
should be
<tp>
cant
<tp>
seems a easy way to find the buffer address ?
<tp>
I'm ready and keen to test ;-)
<tabemann>
back
<tp>
tabemann, we are looking at using a register to convey the swdcom buffer address to the C program
<tabemann>
so I hear
<tp>
or at least considering it
<crest>
it would be easy to add a way to wait for swdcom to connect as well
<tp>
crest, wants to use spooky electron entanglement at a distance but all I could come up with was a unused register
<crest>
just put a connected flag in the low bit of the register
<tp>
crest or use another spare register ?
<crest>
why?!?
<tp>
only if easier
<crest>
doesn't make a difference
<tabemann>
a lower bit seems like a better idea, as it does not expend more register space
<tp>
doesnt the buffer address use all 32 bits ?
<tabemann>
why should it
<tabemann>
if it's word-aligned, it doesn't use the bottom two bits
<crest>
no it's always word aligned (multiple of 4)
<tabemann>
and forcing the buffer to be word-aligned is easy
<tp>
this is my bugger address
<tp>
buffer!
<tp>
$20001D58 bin.
<tp>
3322222222221111111111
<tp>
10987654321098765432109876543210
<tp>
00100000000000000001110101011000
<tp>
so bits 0 and 1 are always unused ?
<tp>
always 0 ?
<tabemann>
yep
<tp>
programmer magic!
<tabemann>
that's the truth of any word-aligned address
<tp>
I'm just a poor technician
<tp>
so ok, one register does it all!
<tabemann>
it's like how ARM determines whether code is Thumb or ARM - by exploiting an unused lower bit thanks to the fact that Thumb instructions are always halfword aligned and ARM instructions are always word aligned
<tp>
and that would do away with the need for a serial port!
<tabemann>
did you hear that Applie is switching to ARM for the Mac?
<tp>
no I didnt
<tp>
they fall out with intel ?
<tabemann>
apparently they want thinner, lower power machines
<tp>
sadly lower power means slower computers
<tabemann>
and x86-64 is just too higher power for them
<tp>
unless the new arm mac has 100 arm cpus and runs parallel software ?
<tabemann>
well it's gonna have a lot of cores
<tabemann>
both CPU cores and GPU cores
<tp>
that makes sense
<tp>
turn them on and off as needed
<tabemann>
also Apple wants to design their own processor chips
<tp>
hell, Id want one myself
<tabemann>
rather than buy them from Intel
<tp>
thats a good reason to use arm
<tabemann>
i.e. what they're already doing with the iPhone and iPad
<tp>
intel has to be really hurting thesedys
<tabemann>
well macs are really only a smidgen of the market
<tp>
they utterly screwed the embedded pooch, major fails
<tp>
yeah
<tp>
this I7 is pretty good
<tabemann>
but the thing is that the future is ARM
<tp>
seems to be
<crest>
i want to use a simple xor-shift rng to fill both ring buffers from a known seed
<tp>
cortex-m is a bit addictive, fast and capable and ornery enough to challenge a tech like me
<tp>
crest, why ?
<crest>
preserve the register for other uses
<tp>
does it matter whats in the ring buffer at startup ?
<tabemann>
oh you're going to search memory for pattern?
<crest>
no because it is logically empty
<tp>
but you dont know the address of the ring buffer ?
<crest>
yes
<crest>
and a xor-shift rng is very small
<crest>
and fast
<tp>
you have to search all of ram across different mcu's ?
<tabemann>
the problem is you have to know where the RAM is
<tp>
some have 8kb, others 1/2 MB of ram
<tabemann>
and while these Cortex-M chips all have ram at $20000000
<tabemann>
you don't know how much RAM there is
<tp>
and if you search past the end wont you cause a exception ?
<tabemann>
maybe because it's SWD you don't cause a processor exception but just an error on the SWD end
<tp>
no one using Mecrisp-Stellaris is going to use R11
<tp>
maybe
<tp>
that would make much more sense
<tp>
i guess crest will find out :)
<tp>
... no stone left unturned
<tp>
plus crest will have a awesome dev board to work with shortly
<tp>
the L476!
<tp>
and then he can donate the blue pills to a homeless shelter ;-)
<tabemann>
and you'll get to try out zeptoforth!
<tabemann>
blue pills are like for people who would be arduino users but are too masochistic for that
<tp>
crest so how long to searc 1/2MB or ram for deadbeef via swd ?
<tabemann>
crest: let me know how that goes so I can include it into zeptofoorth
<tp>
crest, I guess you havent read my bluepill rant ?
<crest>
the more intersting question is how do find out the start of ram?
<crest>
tp: i have
<tabemann>
$20000000
<crest>
always?
<tabemann>
with STM32 it seems to always be that
<tp>
people have wasted *days* with counterfeit mcus in bluepills
<tp>
yes, always $20000000
<crest>
is the ram size discoverable?
<tp>
no
<tabemann>
just trust me, it's always $20000000
<tp>
there is a flash size register
<tp>
but no ram size register
<crest>
*sigh*
<tabemann>
crest: can you detect accessing RAM outside the addressing space without crashing the board?
<tp>
anyone remember 'tandy electronics' ? 35 years ago I used to have this contest with a friend, we would each buy the same electronics part from tandys, be it a led or a chip and have a race to see who found the defect first
<crest>
tabemann: i have no idea
<crest>
gn8
<tp>
because *all* the parts tandys sold came from the manufacturer 'reject bin'
<tp>
even if tandy forgot to mention it
<tp>
afterall, hobbyists cant tell ....
<tabemann>
nacht
<tp>
crest will sonn find out tho :)
<tp>
i dunno why there is no ram size register, it would be so handy
<tabemann>
the blinkenlichten I have running on the F407 board are mesmerizing
<tp>
tabemann, did you notice the 2color led on the SWD section goes all wobulating when swdcom is connected ?
<tabemann>
yep
<tp>
it's very cool
<tp>
i think crest has invented a winner
<tp>
with auto buffer adddress detection it saves pins and a usb-serial dongle plus terminal software, not to mention end of line delays etc
<tabemann>
once connecting without having to read an address off the serial is working, I won't even need this serial dongle hooked up to my machine so it can talk to the F407
<tabemann>
the only thing is I'd have to rework my build scripts
<tp>
the only downside is 516 bytes of ram
<tp>
which isnt a problem for me even with my puny F0
<tabemann>
and for my L4 and F4 that isn't much at all
<tp>
I tested swdcom uploading dissasembler-m0 last night .. fast as, no errors!
<tabemann>
what might make sense is converting the swdcom functionality into assembly and integrating it into the kernel
<tp>
i was thinking about that
<tp>
and it's not hard
<tabemann>
so there's no need to upload it via serial
<tp>
there is no need to do that
<tp>
one just uses a premade binary
<tp>
:)
<tp>
Ive made some already
<tabemann>
but I mean so you can make the premade binary with it
<tp>
but yeah, assembly is best
<tabemann>
so you don't ever need to use serial
<tp>
I've already made binaries with it
<tp>
flash and go
<tabemann>
the only problem with it, though, with zeptoforth, is that the standard forth code that goes along with it requires a number of reboots while being installed
<tp>
but it does need init which isnt optimum
<tp>
frankenforth ;-)
<tabemann>
for building zeptoforth I'll probably just use serial though
<tp>
tabemann, but you produce binaries now so thats no problem ?
<tabemann>
yeah
<tp>
a build system will always have special aspects
<tabemann>
I might add a "warm boot" system, though, that'll avoid the complications of cold rebooting
<tabemann>
yep, in the process of adding warm rebooting
<tabemann>
yehaw! installation is so much smoother using warm reboots
<tabemann>
so it's not halting each time it's cold rebooted
<tabemann>
I didn't even expect that it'd be as smooth as it was
<tp>
i have no idea id Mecrisp-Stellaris warm boots
<tabemann>
what my warm boot is that I jump to the reset handler
<tabemann>
nothing else
<tabemann>
no hardware reset
<tabemann>
note that a cold reboot is still needed in cases
<tabemann>
e.g. erasing flash always invokes a cold reboot
<tabemann>
and if one needs to change hardware configuration in an init word, a cold reboot is recommended
<tabemann>
I found with codeload3.py reboots were often troublesome on the L4
<tabemann>
during code loading
<tabemann>
it should work better with warm rebooting
<tp>
hopefully
<tabemann>
okay, all seems well with the L4 build
<tabemann>
the F4 build should go fine
<tabemann>
as I've had more problems with the upload for the L4 build than the F4 build with the way the integrated USB-Serial works
<tp>
then you can use swdcom ?
<tp>
yeah, stlink2.1 ?
<tp>
Id just reflash it to stlink2.0
<tp>
or maybe reflash it to jlink
<tp>
i hate stlink2.1 on my nucleo and plan tp replace it sometime
<tabemann>
yeah, I'm using stlink 2.1, but I'm not using the whole "virtual drive" functionality a la micropython
<tp>
yeah, but 2.1 is very slow compared to 2.o I find
<tabemann>
I haven't noticed any speed problems
<tabemann>
just garbage in the USB-Serial upon boot
<tp>
I *think* that 2.1 uses a faster mcu than the stm32f103 tho so a backward flsh might not be possible
<tabemann>
how do you flash the SWD programmer?
<tabemann>
I'd've thought that'd've been completely hidden from the user
<tp>
nah
<tp>
it can be done with a windos utility or solder some wires and use swd
<tp>
i use the latter
<tp>
i upgraded my swd-1.0 boards to 2.0 that way
<tp>
damn, matthias has altered 2.2.4 Mecrisp-Stellaris and it means I cant add a \r to the \n print outputs!!!
<tp>
ill have to use a earlier version
<tabemann>
agh
<tabemann>
you could always use zeptoforth ;)
<tp>
hehe, youve a long way to go yet
<tabemann>
which use CRLF as the Lord intended
<tp>
amen brother!
<tp>
matthias is adamant he wont change it
<tp>
but he makes it for him, not for me
<tabemann>
on that note, though, the big things mecrisp-stellaris has that zeptoforth doesn't are register assignment and fixed point numbers
<tabemann>
it has enough that 32-bit fixed point numbers could be implemented with it
<tp>
and theyre bigies
<tabemann>
I could just port 32-bit fixed point numbers from hashforth
<tp>
it's very healily optimised
<tp>
heavily
<tabemann>
the machine code generator could be reduced in size, yes
<tp>
i use Fixed Point (s31.32) a lot
<tp>
I admit you have a lot of nice extras, and one can choose them
<tp>
I do think Zeptoforth will grow into a nice Forth
<tp>
of course I cant use it as Im a M0 iser
<tp>
user
<tp>
my 480 brand new stm32f051 cortex-m0's will be used!
<tabemann>
lolol
<tp>
theyre absolutely beautiful, sooo purty!
<tp>
5x5x1.2mm, theyre tiny
<tp>
their 0.5mm pin spacing is easily soldered
<tabemann>
the thing about s31.32 fixed point - how in heck do you implement it without supporting *128* bit numbers internally
<tp>
they run up t0 98khz
<tabemann>
with hashforth I supported them... by supporting 128 bit numbers under the hood
<tabemann>
but hashforth targeted a 64-bit machine, while the M4 is 32-bit
<tp>
i guess he uses 4 32 bit registers per number ?
<tp>
i dunno man, Im just a user
<tp>
ok the previous version accepted my changes :)
<tp>
I did get matthias to accept my stm32f051 RTS addition as a compile time option tho, and he loved my color additions and made them mainline
<crest>
but the debugger stlink_read_reg and stlink_read_all_reg return garbage
<crest>
because i don't believe that all 16 registers are equal to $f3de9b08
TCZ has quit [Quit: Leaving]
<crest>
okay the core has to be halted for the debugger to inspect the register file
jamzattack has left #forth ["ERC (IRC client for Emacs 28.0.50)"]
WickedShell has joined #forth
<crest>
tp_: christmas came early
<crest>
i figured out how to read from the register file and reset the target system
<crest>
now ctrl+c resets the system
<crest>
but it isn't the same as pressing the reset button because it look like it doesn't reset the hardware and "just" jumps to the reset interrupt
<crest>
(i assume)
<crest>
because the serial output on reset is garbled
<crest>
for now i keep the address in R11
<crest>
but preserved the option override it from the command line
<crest>
e.g. to use R11 for something else
<crest>
or to avoid halting the cpu to access the register file
<crest>
for some as yet unknown reason you now have to hit ctrl+c to continue after a reset
<WilhelmVonWeiner>
pointfree: have you considered banning wengchunkn from r/Forth
<WilhelmVonWeiner>
everything he posts is unrelated garbage
<veltas>
Sir, this is an Arby's
Zarutian_HTC has joined #forth
<WilhelmVonWeiner>
a what
jedb_ has quit [Ping timeout: 256 seconds]
<veltas>
Just reading the reddit and wengchunkn posted a link to that hilariously bad tweet about that forth code that was formatting people's hard driver, I think that's relevant