<tp>
I'll measure the free ram before after swdcom is installed nextime
<crest>
in that case dedicating 516 byte to i/o buffers hurts a lot more
<tp>
cortex-m units have plenty of ram
<tp>
nah, it's not a problem for me
<tp>
i never run short of ram
<crest>
techs and their puny code bases :-P
<tp>
Mecrisp-Stellaris takes abut 1.5KB of the ram
<tp>
yeah, I just make real world things work, I'm not generating bitcoins on my micro
<tp>
I designed and sold a bunch of solid particulate level detectors about 20 years ago that used a PIC micro with 1K flash and 78 bytes of ram. I had plenty of each left over
<tp>
those units were still in use a decade later
<crest>
why change a working system?
<crest>
you can think of the ring buffers of the two arrays they are
<crest>
and my swdcom as a special purpose debugger
<tp>
crest, almost 3am again!
<crest>
it just polls one of the array and writes to the other
<tp>
crest I've githubbed and I'm setting the test up with your new code
<crest>
this version shouldn't transpose your source code in garbage
<crest>
(during fast uploads)
<tp>
nerly ready to test
<tp>
it takes me a while because I have to reflash a new Mecrisp-Stellaris, edit your code, load it, make a binary then test
<tp>
Ram Total:8192 Used:2080 Free:6112
<tp>
Mecrisp-Stellaris RA 2.5.3 with M0 core for STM32F051 by Matthias Koch
<tp>
The swd buffer address is: 20001D58
<tp>
ok.
<tp>
--- Mecrisp-Stellaris RA 2.5.3 ---
<tp>
words4
<tp>
2over 2tuck 2rot 2-rot
<tp>
2dup 2drop 2swap 2nip
<tp>
2>r 2r> 2r@ 2rdrop
<tp>
looks as fast as beore
<tp>
:)
<crest>
i did nothing that should make it slower to fix the bug
<tp>
Ill try a file upload
<tp>
will I need to exit the terminal first ?
<crest>
yes
<crest>
you have to press ctrl + d to get out of swd2 correctly
<tp>
oh
<crest>
ctrl+c isn't caught and kills swd2 without a clean shutdown
<crest>
this can cause problems the next time
<tp>
it's probably a cooincidence but I note that stlink no longer works on this machine, Ive had to flash via serial bootloader
<crest>
it could be stuck because you killed swd2 the "wrong" way
<crest>
if it writes a core file the stlink hasn't been properly released
<crest>
but in the last version killing it the wrong way was the only way
<crest>
because the correct ways hadn't been implemented yet
<tp>
aha
<tp>
serial is at least a easy way and works with openindiana
<crest>
i don't know if there is a good way to recover from this without unplugging the stlink
<tp>
but youre right, open solaris is dead
<tp>
looks like I'll stay with freebsd, I think it's the only choice now
<tp>
(if one must have ZFS)
<tp>
unplugging is no problem
<crest>
zfs on linux is a thing
<tp>
not bootable zfs
<crest>
it's possible
<tp>
openzfs is incompatible with the gpl
<crest>
not a problem
<tp>
yeah, it's possible to mate a horse and a donkey but not easy
<crest>
you're just not allowed to distribute the result
<tp>
have you converted a Linux distro to bootable openzfs ?
<tp>
it's not trivial
<crest>
no but i know several people booting arch from zfs for years
jedb has joined #forth
<tp>
yeah but arch users are used to that kind of stuff
<tp>
your average debian user would find it daunting
<crest>
my opinion of the average debian and ubuntu user isn't printable
<tp>
sure having ZFS filesystems in Linux is trivial, they have packages for it
<tp>
hahah
<tp>
Closing ST-LINK/V2 handle.
<crest>
that sounds good
<tp>
swd2 $add < gcd.fs
<tp>
add: Undefined variable.
<tp>
hmm why is $add there ?
<crest>
it should read $addr
<crest>
its the base address of the buffer printed to the serial console before the switch
<tp>
crest, the F4 seris are the heavy duty MCU's they are faster, bigger, much higher end
<tp>
I dont need them for any of my real world projects
<crest>
but how much harder are they to configure?
<tp>
no harder
<tabemann>
the only real disadvantages to the F4 are if you want lower power or you want nicer flash erasure characteristics
<tp>
just more of everything
<crest>
are there breakout boards to allow people to play with them
* tabemann
finds the L4s and the F4s to be equally easy to configure
<tp>
and tabemann is the F4 expert here
* tabemann
hates the F4's huge flash sectors
<tp>
crest, any discovery or nucleo board is a breakout board
<tabemann>
both of my DISCOVERY boards come with loads of pins to attach things to
<tp>
crest, they are all easy once one gets used to cortex-m
<tp>
the f0 series are for small projects that only need 33 onboard peripherals bwah!
<tabemann>
fundamentally the main things that differ between Cortex-M chips are A) the flash controller B) the U(S)ARTs C) whether they support thumb-2 and D) how much flash and RAM they have
<tp>
a F7 has 97 thats *NINETY SEVEN* onboard peripherals !
<tp>
tabemann, has summarised it very succinctly
<tabemann>
and yes, whether they have fuckloads or fuckloads upon fuckloads of peripherals
<crest>
because i don't want to spend time on that
<tp>
crest that NUCLEO-F401RE? will absolutely rin Mecrisp-Stellaris withut porting
<tabemann>
crest: there's tons of chips and boards mecrisp supports
<crest>
supporting the register allocator would be nice as well
<tp>
tabemann, crest has the supported hardware list
<crest>
is there a reason why so few targets have a -ra suffix
<tabemann>
or you could always invest in an L476 or F407 and install zeptoforth ;) ;) ;)
<tp>
only that the binary hasnt been made for that chip, it's a compile time option
<crest>
ok
<tp>
as Mecrisp-Stellaris comes with premade and ready to run binaries
<tabemann>
and getting the toolchain for arm-none-eabi is easy if you run linux or freebsd
<tp>
yeah it all works with FreeBSD
<tp>
including making a binary for Mecrisp-Stellaris
<tabemann>
(unlike getting the toolchain for risc-v, which is an absolutely massive pain in the ass)
<tp>
tabemann, tried uploading a Forth sourcefile cia swdom yet ?
<tp>
swdcom
<tabemann>
tp: do I use #include like e4thcom?
<tp>
tabemann, like this: ./swd2 20001D58 < gcd.fs
<tp>
tabemann, kill the terminal first
<tp>
tab, no it's still a ceta release
<tabemann>
ceta?
<tp>
before beta ;-)
<tabemann>
that's alpha
<tp>
oh...
<tp>
Im a technician, no one told me bwahahahah
<tabemann>
lol
<tp>
I'm the hardware guy
<crest>
tp: looks like i'm gettin two NUCLEO F411RE boards in case i break one
<tp>
crest, re the F411RE, as it's a older unit it has older flash
<crest>
than the 401?
<tp>
and the older flash is SLOW to flash compared to the L476
<tp>
but the board is solid and proven
<tp>
the MCU is solid and proven, just older
<crest>
with 128kB sram i can keep enough code in sram to keep me busy for a while
<tabemann>
now I've got my board displaying blinkenlichten, all thanks to swdcom
<tp>
tabemann :)
<crest>
tabemann: good to hear that the code works for you
<crest>
feel free to send a pull request
<tp>
tabemann, your impression re speed of upload, terminal response etc ?
<tabemann>
tp: very, very fast
<tp>
crest, is a legend!
<tabemann>
despite the fact that no comments or whitespace were being taken out of the code
<tp>
yes!
<tp>
crest, some of the boards have a lot more ram
<tp>
tabemann whats in the L476 ?
<tp>
oh same 1 Mbyte of Flash memory, 128 Kbytes of RAM
<tp>
in LQFP100 package
<tp>
crest, the older flash also has much larger blocks compared to the L476
<crest>
so you would recomend to spend 1€ more on a NUCLEO L476RG
<tabemann>
hmm my code seems to indicate it has 96K of RAM, even though I thought it had more
<tp>
tabemann, crests code would run on Zeptoforth methinks ?
<tp>
tabemann, with a bit of tabemann massaging
<tabemann>
eyes
<tabemann>
whoops
<tabemann>
yes
<tabemann>
it is runningo on zeptoforth, with some massaging
<tp>
oh1
<tp>
you ran it on zeptoforth instead of Mecrisp-Stellaris ?
<tabemann>
yes
<tp>
hahah, you could have mentioned that!
<crest>
i think he did
<tp>
we assumed you meant you had it running on Mecrisp-Stellaris
<tp>
oh, I must have missed that, apologies
<tabemann>
there's a single disadvantage to using swdcom - it feed literally every character entered into zeptoforth
<tabemann>
and zeptoforth, well, can we say it doesn't really filter its input
<tabemann>
it'll echo every character entered aside from DELETE and CR
<tabemann>
and it will put the character in its input buffer
<tabemann>
verbatim
<tabemann>
feeds*
<tp>
tabemann, but you dont see any of that with swdcom atm
<tabemann>
tp: mecrisp-stellaris probably more strictly filters the characters entered
<tabemann>
I should program that into zeptoforth
<tp>
tabemann, Mecrisp-Stellaris does filter comments
<tabemann>
no, I mean like characters < $20
<tabemann>
control characters
<tp>
but filtering comments takes time which is why I strip them automatically before upload
<tabemann>
no I mean when the user is interactively using the terminal
<tabemann>
and say, they hit up
<tabemann>
with zeptoforth, the cursor will literally go up one line
<tabemann>
and the control characters will be entered in the input buffer verbatime
<crest>
i went with the STM32L476RG
<crest>
1MB flash and 128kB ram for my crazy ideas
<tp>
tabemann, ahh thats why my terminal is almost unusable with Zeptoforth @
<tp>
crest, a very excellent choice!
<crest>
tp: my debugger attack on the serial-key? and serial-key should be possible
<crest>
i just have to put hardware breakpoints at their addresses
<tp>
crest, the STM32L476RG is not too old, has all the cool low power stuff and a zillion resources
<crest>
load the data into the registers and skip the program coutner over the status register reads
<crest>
but that would be a lot harder to implement than just putting data into writable memory mapped i/o registers
<tp>
crest, aNd faster ?
<crest>
than what?
WickedShell has quit [Remote host closed the connection]
<tp>
your existing swdcom technique ?
<crest>
no
<crest>
probably orders of magnitude slower
<crest>
but it would be possible to inject the bootstrap code into an unmodified image that way
<tp>
oh
<crest>
its not useful
<tp>
so you can load swdcom remotely ?
<crest>
you could load the target code into the target through the stlink
<tp>
aha
<crest>
it's just my curious hacker mindset that send me down that path
<tp>
tho Ive worked around the issue of needing a serial terminal to load swdcom by making a bootable binary and the address by blinking the disco board leds
<crest>
writing the four functions in assembler would also solve the problem
<tabemann>
back
<crest>
but i wanted to do it in forth
<tp>
crest, so a future swdcom may install itself ?
<crest>
maybe
<tp>
hackers are definitely a breed apart from us mortal electronics techs :)
<crest>
i know next to nothing about the analog world just next to the mcu
<tp>
one cant be a expert in both fields, just one is more than enough
<crest>
can someone tell me what happens in a stm32 on reset?
<crest>
what does the chip do on reset?
<crest>
is there some code in mask rom to bring the hardware into a sane state?
<tp>
sure, a lot happens
<crest>
is it a hardwired state machine?
<tp>
in that url I pasted earlier of USART1 it showed the reset state of every register
<crest>
but how does it get into reset state?
<tp>
it resets all the registers to the reset state
<crest>
but how?
<tp>
there are a number of ways, the technical manual for the mcu explains everything
<crest>
are those all set-reset registers hooked to a single reset line?
<tp>
no one knows *how* it's done
<crest>
someone at ST should know
<tp>
all the interrupt vectos are set
<tabemann>
back again
<tp>
vectors
<crest>
but it sounds like i shouldn't hope to be able to protect the usb controller from resets
<crest>
and revive the usb modem idea
<tp>
and in your new STM32L476RG there are probably 100+ interrupt vectors
<tabemann>
what I do is load all the setup code initially via serial, and either export it via ihex to a binary or just use it as is, and then load the swdcom code when it's all done
<tp>
crest, resets happen under controled circumstances such as pressing the reset button, low power voltage, hard exception
<tp>
crest, but otherwise wont happen
<tabemann>
as long as one avoids those situations, one should be fine
<tabemann>
and also, at least in zeptoforth, the location of the buffer won't change across reboots
<crest>
is there any electrical connection between the two parts of a nucleo board?
<tp>
tabemann, I've already made a bootable Mecrisp-Stellaris binary with swdcom using my ihex method
<tp>
crest, sure, the power, swd etc
<tabemann>
tp: then you just need to record down that magic address somewhere
<tp>
tabemann, I've written a alpha level word that blinks the board led to convey the swdcom address
<tabemann>
in binary? lol
<tp>
no, in decimal, like a car fault code led
<tp>
it's easy to do'
<tp>
short flashes for 1 - 9 and a long flash for 0
<tabemann>
you could do morse code
<tp>
then youd have to know morse, I already know decimal
<tp>
it blinks, you count them, you write them down, it's easy
<tabemann>
with morse code one could do hexadecimal
<crest>
sure he could also use a DAC to output each digit as $x * 100mV for one second
<tp>
and you only have to do it once
<tp>
crest, thats also a idea :)
<tp>
but watching the led requires no aditional gear
<tabemann>
with zeptoforth and swdcom, you just attach a serial terminal first then boot
<tabemann>
and the address is right there on the serial terminal
<tabemann>
no counting involved
<crest>
if you rewrite the code in assembler you can make it part of the image and extract the location from the symbols file
<tp>
it's already a bootable binary
dave0 has quit [Quit: dave's not here]
<crest>
unless zeptoforth is fastly different
<tp>
tabemann, I'm trying to use a method that requires no serial terminal
<tp>
tabemann not everyone has a serial dongle
<tabemann>
that is true - the age in which every machine came with a serial port is long past
<crest>
often the chipset still includes the serial port
<crest>
but it isn't exposed to the user
<tabemann>
yeah
<tp>
fortunately usb-3.3v dongles are a $0.90 commodity
<tp>
so it's not an issue
<tabemann>
cheap FTDI clones straight from china
<tabemann>
cheap enough that if the FTDI firmware updates brick the cloned chipset, oh well
<tabemann>
the problem is when real live products include those cheap FTDI clones, and they get bricked
<tabemann>
and then people wonder why, inexplicably, the serial ports on their expensive equipment no longer work
dddddd has quit [Ping timeout: 256 seconds]
<tp>
updates ???
<tabemann>
yeah
<tp>
who updates a usb-3.3v dongle ????
<tabemann>
there was an FTDI driver update that was designed to brick any of the chinese FTDI clones
<crest>
don't install the official driver and use a the one included in linux and *bsd?
<tp>
crest, hahah, FreeBSD makes updating easy providing you run a current release
<crest>
just be careful going from 11.x to 12.x and follow the official steps
<crest>
no just make installkernel installworld ; etcupdate ; etcupdate resolve
<crest>
i managed to mess up (an recover) one system by skipping the correct steps and reboots
<tp>
crest, I never update I always do a new install
<tp>
then I just import my zfs array
<crest>
my desktop/workstation still runs my second ever freebsd installation
<tabemann>
I'm a debian user and I've gone years upon years without doing a fresh install
<tp>
tabemann, we are sorry to hear that ;-)
<tabemann>
lol
<tp>
tabemann, will now be known as 'cruft-boi'
<crest>
i moved this system from 32bit to 64bit, from ufs to zfs etc.
<tabemann>
why install from fresh when one can do sudo apt update ; sudo apt upgrade
<crest>
tabemann: because you want to end up in a well defined state
<crest>
my desktop is the only system i refuse to wipe
<tabemann>
I don't want to have to reinstall everything I've installed on here
<crest>
tabemann: ansible?
<tp>
tabemann, Linux users are born to suffer I guess
<tabemann>
nah, there are linux users who will install everything from scratch too
<tabemann>
I just don't like doing things this way
<tp>
tabemann, who install from scratch ?
<tp>
I dont
<tabemann>
oh, and by the way, doing clone (from ihex.fs) to dump everything in the ram of my F407 board (which includes lots of empty filler space due to the limitations of flash erasure on it) is almost instantaneous
<tp>
new install doesnt = from scratch
<tp>
tabemann, with swdcom ?
<tabemann>
yes
<tp>
wow, I havent tried that yet
<tp>
shame you cant capture it yet
<tabemann>
whereas dumping it all with serial at 115200 baud takes about half a minute
<tp>
yeah, it's slow
<crest>
you can capture swdcom
<tp>
hmm
<crest>
echo dump | ./swd2 $addr | tee log.txt
<tp>
swd2 address <ihex >log.txt ?
<crest>
okay make that (echo dump ; sleep 1) |
<tp>
crest, you have to start the ihex dump first
<tp>
ahh thats 'dump' ?
<tp>
tis I have to try!
<crest>
the problem is that there is no nice way to wait
<crest>
swd2 quits on end of file
<tp>
why wait ?
<crest>
because it stops reading the output as well
<crest>
and you want to capture the output
<tp>
oh <doh>
<tp>
so just tee ?
<crest>
also possible
<tp>
swd2 address | tee log.txt
<crest>
just tee and remove the execess around the ihex
<tp>
i have to do that anyway, i have a script that does it all
<crest>
also you could restore the serial console first
<tp>
my dump has a start and end keyword
<crest>
and patch your dump code to call swd-emit instead of emit
<crest>
nothing (of value) is lost be deconnecting and reconnecting
<crest>
swdcom stores the buffer in the target ram
<crest>
that allows swd2 to terminate without losing that buffer
<tabemann>
back
<tp>
swdcom is vry cool, a magnificient concept
<tabemann>
okay, it isn't instantaneous
<tp>
hahah
<tabemann>
it needs more than one second to read all the data
<tabemann>
but it still is really fast
<tp>
10 hours ?
<tabemann>
compared to serial
<tabemann>
lol
<tp>
al we need is error feedback from uploads
<tp>
and we are there
<tp>
at least as far as using screen goes
<crest>
i my current state i would do more harm than good to the code
<tp>
thats used on my pc where all my Forth source is written
<tp>
zero comments leave the pc to the Forth target
<tabemann>
okay, I should get to bed
<tabemann>
g'night guys
<tabemann>
and crest, thank you for swdcom
<tp>
night tabemann
<tp>
yes crest, thank you for swdcom
<crest>
:-)
<tabemann>
oh, and btw tp
<tabemann>
I committed code for zeptoforth which fixes the control characters problem
<tp>
tabemann, cool!
<tabemann>
so if you hit up you'll just get garbage like [A
<crest>
tabemann: how does zeptoforth compare to mecrisp? what made you start your own forth?
<tabemann>
rather than having the cursor actually move up a line while corrupting the input buffer
<crest>
did you write down a comparison somewhere?
<tabemann>
crest: I've never really compared zeptoforth to mecrisp; I just wanted to write my own forth for an embedded platform, and Cortex-M4 MCUs seemed like a good target
<crest>
ok
<tp>
crest, tabemann is a Forth implementer, thats what they do
<crest>
:-P
<tabemann>
note that parts of zeptoforth, particularly the serial console and the flash controller code are heavily based off of mecrisp-stellaris
<tabemann>
while the vast majority of zeptoforth is a completely new implementation, independent of mecrisp-stellaris
<tabemann>
note that in ways mecrisp-stellaris is more mature than zeptoforth, particularly because it has RA which zeptoforth lacks
<tp>
Zeptoforth does have a ton of extra facilities; kitchesink.fs, theanswertoeverything.fs
<tabemann>
in other ways zeptoforth has advantages, like as long as one uses a "full" binary one gets interrupt-driven serial IO out of the box along with power management
<tabemann>
it also has wordlists, as of version 0.6.0, integrated into the core of zeptoforth, whereas VOCs in mecrisp-stellaris are an experimental extra
<crest>
adding powermangement wouldn't hard
<crest>
but having it built in is nice
<tp>
crest, wanna bet ?
<tabemann>
crest: the key thing is that power management is integrated with multitasking
<crest>
tp: not optimal powermanagement
<crest>
but sleeping instead of polling
<crest>
with wakeups by the usart interrupts
<tp>
crest, dont coment on stm32 power management until you try and implement it
<tabemann>
yep, zeptoforth has that
<crest>
tp: i played with it
<crest>
and it looked like it worked
<tabemann>
note that zeptoforth only uses "sleep" mode, not "stop" mode or any of the other modes
<tp>
crest, which level of power management did you use ?
<tp>
there are three modes
<crest>
just the idle until interrupt instruction
<crest>
nothing deeper
<tp>
sleep ?
<tp>
there is no idle mode
<crest>
WFI? WFE? something like that
<tabemann>
you mean WFI with the default power management option
<tp>
I've done a comprehensive study with power measurements
<tabemann>
that's what I use as well
<tp>
WFI is required to enter any of the THREE modes
<tp>
or WFE
<crest>
one step better than just polling the usart status register all the time
<tp>
what happens after the WFI depends on the setup before WFI is called
<tp>
crest, maybe, maybe not
<crest>
exactly
<crest>
that was before i had a stlink to even samlpe the program counter
<tp>
crest at least the board you have ordered has all the latest power resources
<tabemann>
the thing about sleep mode is that it doesn't save as much power, but it is quickest to get out of that state
<tp>
the STm32F103 in the blue pill has only coarse power control
<crest>
and i have no idea how the debugger interferes with sleeping
<tp>
tabemann, is right
<tabemann>
in the case of zeptoforth, the systick is constantly waking up the processor, so it is necessary to exist the power management mode - and return to it - as fast as possible
<tp>
various sleep modes will result in a long wake up of the usart with missing characters unless allowed for
<tp>
low power is a MASSIVE study on it's own
<tabemann>
and also because if input is being continuously fed in, as tp says, it'll lose characters if it's not as fast as possible
<crest>
tabemann: only without reliable flow control
<tp>
I know a very smast and capable embedded programmer who spent 3 months getting the lowest power on a commercial product, he said it nearly drove him crazy
<crest>
you could use a timer to poll the swd ring buffers
<crest>
you could even increase sleep time after a period of inactivity
<crest>
to keep uploads fast but otherwise poll at a human friendly rate
<tp>
in the end his product used about 8 nA in sleep !
<crest>
after a few minutes without transfers you could go into even deeper sleep
<tabemann>
actually, with how I have it working right now, it's going to sleep and not being woken up, until a systick wakes up the processor
<tabemann>
mind you systick is occurring at 1/10 ms intervals
<tp>
whereas it needs input data to wake it
<tabemann>
so it can transfer data in either direction as up to 255 bytes per 1/10th of a millisecond
<crest>
with swdcom?
<tabemann>
yes
<tabemann>
it's a limitation imposed by the fact that I'm not having it busywait
<tabemann>
but rather having it be woken up by systick
<tabemann>
do stuff
<tabemann>
then go back to sleep
<crest>
that's 2.55MB/s
<tp>
nevertheless Zeptoforth doesnt use much power, a great job by tabemann
<crest>
(in theory)
<tabemann>
okay, I should actually go to bed now
<tp>
hehe
<tabemann>
g'night guys for reals now
<tp>
and crest1
<tp>
and crest!
<crest>
gn8 guys
<tabemann>
yeah, you go to bed too, it's even later for you
<tp>
night tabemann and crest
<tabemann>
n8
<tp>
it's 3pm here
gravicappa has joined #forth
<tp>
see swd
<tp>
0000A00C: 603E str r6 [ r7 #0 ]
<tp>
0000A010: 0476 lsls r6 r6 #11
<tp>
0000A00A: 3F04 subs r7 #4
<tp>
0000A00E: 2680 movs r6 #80
<tp>
0000A012: 36EA adds r6 #EA
<tp>
0000A014: 0176 lsls r6 r6 #5
<tp>
0000A016: 3618 adds r6 #18
<tp>
0000A018: 4770 bx lr
<tp>
Bytes: 16 ok.
<tp>
lol, not much
proteus-guy has quit [Ping timeout: 256 seconds]
reepca has quit [Read error: Connection reset by peer]
reepca has joined #forth
dys has quit [Ping timeout: 256 seconds]
dys has joined #forth
andrei-n has joined #forth
guessgood has joined #forth
guessgood has quit [Quit: Connection closed]
andrei-n has quit [Ping timeout: 240 seconds]
andrei-n has joined #forth
mtsd has joined #forth
andrei-n has quit [Ping timeout: 256 seconds]
reepca has quit [Ping timeout: 246 seconds]
jedb_ has joined #forth
jedb has quit [Ping timeout: 256 seconds]
TCZ has joined #forth
scj has joined #forth
Zarutian_HTC has quit [Ping timeout: 256 seconds]
scj has quit [Remote host closed the connection]
jsoft has quit [Ping timeout: 246 seconds]
cantstanya has quit [Remote host closed the connection]
cantstanya has joined #forth
TCZ has quit [Quit: Leaving]
andrei-n has joined #forth
mtsd has quit [Quit: Leaving]
Zarutian_HTC has joined #forth
iyzsong has joined #forth
cantstanya has quit [Remote host closed the connection]
<tp>
hey I had a lot of fun playing with swdcom last night, it's very impressive! I was thinking could you save the #address in a register and get it that way ?
<tp>
Mecrisp-Stellaris has a few unused registers
<crest>
but that would take the register away from the user
<crest>
i had a different idea
<tp>
doesnt matter, there are a few spares and most users dont touch them
<crest>
ich stlink is supposed to have its own serial number
<crest>
and i just wanted to cache the address per serial number
<tp>
i think I understand how your swdcom works now :)
<crest>
do you want to test your understanding?
<crest>
look at the latest version on github
<tp>
it's quite superficial, but sure
<tp>
ok will do
<crest>
i cleaned it up a little a few minutes ago
<tp>
whats the git update command ?
<crest>
git pull
<tp>
(I dont use git, dont like it)
<crest>
i agree that git has an annoying and at times dangerous interface
<tp>
I've ben spoilt by fossil
<crest>
if only fossil had something like git add -p
<crest>
but the largest problem with fossil is mindshare
<tp>
aha a Makefile
<crest>
oh and i make heavy use of git annex to keep my media archive synced
<tp>
I'm not trying to convert anyone
<tp>
i just noticed that my disco board SWD interface 'dual color led' cycles when swdcom is connected, it looks funky
X-Scale` has joined #forth
<tp>
also happens when using swd to flash or with gdb etc
X-Scale has quit [Ping timeout: 264 seconds]
X-Scale` is now known as X-Scale
<tp>
agree fossil mindshare is minimal probably always will be, same as freebsd
<tp>
if i wanted a OS with the greatest mindshare Id still be using windows or Linux
<tp>
so how do you fetch the $address in regard to a stlink serial number ?
<crest>
you would have to set it once
<tp>
before you can access the buffers you need to know the $address ?
<crest>
your idea to put the base address into a register a good one
<crest>
i just don't want to "steal" a precious register from the programmer
<tp>
the problem with setting it is you need a serial connection to make it work
<tp>
theyre NOT precious
<tp>
this is Forth
<crest>
i think i have a better idea
<tp>
You can use r0, r1, r2 and r3 freely; you need to push/pop r4 and r5 before use, and you can use r6/r7 and r13/r14 as stacks.
<crest>
i'll fill the ring buffers with some magic pattern and scan for it on connect
<tp>
r 8 Unused, available for your special purposes. Keep in mind that on M0, only a few opcodes are available for them (MOV, ADD, CMP, as far as I know)
<tp>
r 11 Unused, available for your special purposes.
<tp>
r 10 Unused, available for your special purposes.
<tp>
r 12 Unused, but saved automatically on interrupt entry.
<tp>
r 9 Unused, available for your special purposes. You may get a error/warning ‘Use low registers’
<tp>
r8 - r12 are not generally available under Mecrisp-Stellaris on a cortex-mo anyway
<tp>
being restricted under thumb1
<tp>
and anyway, once the address is fetched, a user can use that register as it's not needed ?
<crest>
correct
<crest>
unless i wanted to allow users to relocate the buffer at runtime *shudder*
<crest>
it looks like the covid19 backlog has been cleared. my stm32l476 boards should arrive in a few hours
<tp>
awesome
<tp>
it's a great board, modern flash
<tp>
tabemann loves his unit
<tp>
wow, i haven't looked at swd2.c before, you have put a lot of work into that!
<tp>
I can get a manual dictionary dump in intelhex now, works great, but can't automate it as you said, swdcom terminates too fast
<tp>
screen runs to conclusion but mt batch file needed sleep before using the logfile, it's a pain
<tp>
so id set the sleep for the longest expected time and just wait if it's shorter ...
<crest>
i just added proper signal handling for SIGINT and SIGTERM
<tp>
i just loaded up your latest on my test board, works great!