<tp>
is that how you start the new inline version ?
<tabemann>
no
<tabemann>
I just do ./swd2
<tp>
./swd2 by itself didnt do anything
<tabemann>
pull the latest
<tp>
I di
<tp>
did
<tabemann>
I just pulled the latest like a few minutes ago
<tp>
I always build from the latest
<tabemann>
I stashed my version, pulled, then unstashed, allowing it to merge
<tabemann>
then I modified my bootstrap.fs, named bootstrap_zepto.fs to work with it, loaded it up, rebooted, compiled swd2.c, started sw2, and it worked
<tp>
swdcom% git pull
<tp>
Already up to date.
<tabemann>
tp: have you installed bootstrap.fs?
<tp>
why do git users always think that fossil users cant use a scm ?
<tp>
yep
<tp>
all the latest
<tabemann>
hmm
<tp>
recompiled the c file
<tabemann>
I dunno, because it works for me, and I'm not even using the standard out-of-the-box code
<tp>
how long after you ran sw2 did it respond ?
<tabemann>
but rather a hacked-up swd2.c so it works on linux, and a hacked-up bootstrap.fs so it works with zeptoforth and its multitasker
<tabemann>
instantaneously
<tabemann>
oh question
<tp>
maybe it's my M0
<tabemann>
did you restart mecrisp-stellaris after you loaded bootstrap.fs?
<tabemann>
the instruction used by bootstrap.fs is thumb-0
<tp>
hmm, I really cant recall, gurss i better do it again!
<tabemann>
*thumb-1
<tp>
oh yeah I did
<tp>
it comes up with the buffer address
<tabemann>
you're using the old version
<tabemann>
the new version doesn't display the buffer address
<tp>
odd
<tp>
ok, I'll do it again and advise, thanks for the tips!
<tp>
tabemann,
<tp>
it does
<tp>
: init ( -- )
<tp>
swd-init
<tp>
." The swd buffer address is: " swd hex. cr
<tp>
72MHz swd-console ;
<tp>
thats the init line
<tp>
on the latest version
<tabemann>
my bad
<tabemann>
it's my version which doesn't display the address
<tp>
ah
<tabemann>
I didn't copy that from crest's code
<tabemann>
I must've just figured I wouldn't need it
<tp>
mine is slightly different as well but does use the original init stuff
<tp>
true
<tp>
but your terminal is still locked out ?
<tp>
once swd-console runs ?
<tabemann>
yes
<tp>
i end up with swdcom % ./swd2 and nothing
<tp>
and the serial terminal still works
<tp>
mt swd programmer dualcolor led is wobulating tho
<tabemann>
hmm
<tp>
if I run sed2 with the buffer address it complains about the cpu type
<tp>
swd2
<tabemann>
I can switch back and forth between SWD and serial with swd-console and serial-console
<crest>
it failed to find any (supported) programmer
<tp>
thats why everything is the same as your prev version that was working
<crest>
have attempted to unplug and reconnect the programmer?
<crest>
(stupid question but sometimes stupid things work)
<tp>
um, Im not sure
<tp>
I cn easily try it again
<crest>
maybe your stlink firmware is hung
<crest>
disconnect it from all power sources
<tp>
could be, Im not a massive stlink fan
<crest>
disconnect the swd connection as well
<crest>
i've seen stange things happen
<tp>
the stlink dualcolor led was wobulating like with the prev version so it's connected
<crest>
e.g. a msp430 is efficient enough to run from a max232 tx pin if you send enough data
<tp>
yeah, theyre the lowest of the low power
Zarutian_HTC has joined #forth
<crest>
the pcb in question contained a msp430, the firmware a little power management
<crest>
if you disconnected the pc polling the sensor values it crashed after a while
<crest>
turns out the battery was in the wrong way and the diode protecting the pcb from stupid users worked
<crest>
afterward the developer ran a resistor in parallel with the mcu to increase power consumption :-P
<tp>
repowered the board, running ./swd2 as root
<tp>
#./swd2
<tp>
nothing, but not segfaulting
<tp>
swd programmer led is wobulating
<crest>
sounds like your user just lacked access permissions to the device node in /dev/usb/*
<crest>
nicer error handling / reporting is on my todo list
<tp>
same when running as normal user
<tp>
no core files now
<tp>
maybe the power down did that
<crest>
i have look into how to reset the programmer (without resetting the target as well)
<tp>
but it's hung up in stlink somewhere, perhaps the unrecognised mcu
<crest>
i'm not sure if that's possible
<tp>
ill install FreeBSD 12.1 on a small spare pc and try stlink 1.6
<crest>
it could be that the SWD protocol has too much state for this to ever work
reepca` has quit [Read error: Connection reset by peer]
<tp>
i cant install it on this old 11.2 box as it's to old
<crest>
i just want to avoid resetting the target at without user permission
reepca` has joined #forth
<tp>
I've found stlink slightly flakey anyway
<tp>
i generally use the serial bootloader for reflashing
gravicappa has quit [Ping timeout: 265 seconds]
gravicappa has joined #forth
<crest>
but they're cheap and fast
<tp>
true
<crest>
the protocol includes checksumming and handshakes
<tp>
serial bootloaders are as fast
<crest>
so they're a lot better than plaintext over serial
<tp>
but at least cortex-m gives the choice of everything
<crest>
sure i could buy a 10Mb/s usart with deep buffers for the host
<crest>
and implement dma transfers and crc32 checksumming
<tp>
I think swd is a better choice if it works
<crest>
it works
<tp>
cheaper and easier
<crest>
and the great thing about swd that you don't have to know anything about the mcu peripherals to get a working console
<tp>
besides, my mcu is compiling as fast as it cant at 460800 baud
<crest>
this could be very useful to bring up new chips
<tp>
thats a enormous benefit
<crest>
just hook up the swd pins and get started
<tp>
absolutely
<crest>
btw i found a workaround for the limitations of ramallot
<tp>
matthis has spent so much time setting up diferent usarts
<crest>
i could just call the ram_allot part of the allot at startup
<tp>
the usart on the mo is different to the M3 etc
<crest>
transmissions from the stm32l476 to the host are even faster now
<crest>
130661 bytes transferred in 1.259149 secs (103769 bytes/sec)
<crest>
you would have to run a USART at 1037690 baud 8n1 to match that
<tp>
that definitely blows my system away
<tp>
of course my mcu cant compile faster than about 115200 baud anyway
<tp>
youre sull
<tp>
yours will
<crest>
i have to slow it down a little by calling "pause"
<tp>
... installing 12.1 atm
<crest>
otherwise it breaks multitasking
<tp>
i dont run multitasking
<crest>
the overhead should be quite low
<crest>
because only swd-key? and swd-emit? have to call pause
<crest>
i suspec that the mcu has cycles to spare anyway
<tp>
probably
<tp>
it's nice to have the option tho
<tp>
I only have 8KB ram so more than 2 tasks really eats into my ram
<crest>
you could reduce the data stack size to 32 cells and the return stack even further
<crest>
writing clean 32bit code for a microcontroller feels strange
<crest>
i keep wanting to avoid memory accesses because that's oh so slow
<crest>
e.g. i wanted to use 16bit loads to check load two 8bit indicies at the same time
<crest>
but on cortex-m3/m4 one more ram access is faster than the required bit shifting
<crest>
its not like i have multiple (simple) integer pipelines starved by a one or two load store units
<crest>
*it's
<crest>
on the ppc74xx could execute up to four instructions per cycle under the right cirumstances
<crest>
but had to find ways to avoid memory accesses because there was a single load/store unit
<crest>
oh the system i nice enough to reset r11 to zero on reset
<crest>
so i could just add some polling code to the swdcom startup to read r11 and resume the core for a few milliseconds if it's zero
<tp>
dont the registers have random data at reset ?
<crest>
doesn't look like it
<tp>
nice of arm to reset them
<crest>
or maybe the "random" value just ends up to be zero (most of the time?)
<tp>
nah
<tp>
they would be anything
<crest>
e.g. 32 bit powerpc starts with 0xDEADBEEF in all registers
<tp>
thats cool
<crest>
i haven't found any reference to r11 anywhere else in the code
<tp>
Mecrisp-Stellaris doesnt use R11
<crest>
but mecrisp could still initialize it with load multiple instructions
<crest>
i could even wrap the existing default console
<tp>
problem is that thumb1 cant really use R11
<crest>
and only switch over to swdcom once something connects
<crest>
why?
<tp>
it's only available for a couple of instructions in thumb1
<tp>
no Mecrisp-Stellaris user will use R11 anyway
<crest>
as long as mov is one of them the difference is small
<tp>
Forth people use Forth not assembly except in specific cases
<crest>
but to be honest i don't care corext m0 right now because i can't test it
<tp>
if we wanted to use assembly, we wouldnt use Forth
<tp>
sure
<tp>
I appreciate that
<crest>
mecirsp uses a lot more assembler than required for 98% of the performance
<crest>
*mecrisp
<tp>
well mecrisp is written in assembler, that doesnt mean that it's users use assembler
<tp>
matthias loves assembler
<crest>
just not thumb?
<tp>
no, he hates thumb
<crest>
thumb1 or thumb2?
<tp>
matthias doesnt like cortex-m isa
<tp>
he a equal opportunity thimbx hater
<crest>
because while i'm still guessing a lot of time i like the isa
<tp>
and cortex-m isa is hrrible
<tp>
matthias loves msp430 isa
<tp>
and so do I, it's so easy to use
<crest>
sure msp430 is a programmers dream
<tp>
a bit like motorola 6800 isa
<tp>
but with forth, who cares ?
<crest>
but thumb2 offers 2 operand encoding for common cases
<tp>
cortex-m is easy with Forth
<crest>
but has a longer 3 operand format if that fits better
<crest>
things like the IT instruction are also nice to have
<tp>
there are pros and cons
<crest>
the TBB and TBH instructions could be used for a really fast token threaded forth
<tp>
wait till you look into low power
<tp>
msp430 is *one* command for low power
<crest>
that's not what i would consider part of the instruction set
<tp>
cortex-m is a 3 month brain burn
<tp>
as a tech, it is to me
<crest>
it is complex beast
<tp>
youre a programmer, Im a tech, we have different goals
<crest>
i know that i know next to nothing about the chip
<tp>
the main thing is that msp430 core is tightly integrated with the peripherals, cortex-m just has all the peripherals lumped in, they are far from tightly integrated
<crest>
it took me over a day to get the stupid usart remapped from a non existing pin to the default part
<tp>
and the usart is the easiest of all
<crest>
turned out was looking in the wrong part of the documention
<tp>
there is a *massive* learning curve with cortex-m
<tp>
thats standard, something we all learn at the beginning
<crest>
that's because the all the cortex-m combine stuff from multiple vendors
<tp>
the doc is across many places
<tp>
exactly
<crest>
the code is created and documented by arm
<tp>
all the core stuff is arm doc
<tp>
all the peripheral stuff is STM
<tp>
and in the middle ... might be anywhere
<crest>
and arm is designed to support this
<tp>
and it does, it's immensly useful
<tp>
thats why I use it and not msp430
<crest>
so there multiple fast busses from the cpu to the rest of the SoC
<crest>
a msp430 is tiny by comparison
<tp>
it is
<tp>
and has few peripherals in comparison
<tp>
no RTC on a msp430
<tp>
which a cortex-m user takes for granted
<crest>
how much power does the whole msp430 consume with good code compared to just the cortex-m3 rtc?
<tp>
crap FreeBSD 12.1 uses stlink-1.5.0_2 same as I have here
<crest>
switch to the latest packages
<tp>
they are both capable of minuscule power usage
<crest>
mkdir -p /usr/local/etc/pkg/repos
<tp>
but where you get it in 5 minutes with msp430, it takes 3 months with cortex-m
<crest>
depending on your connection to the freebsd package cdn this can take a while
<crest>
we finally got a faster mirror for most of europe
<crest>
and better routing
<tp>
323.6kB/s
<tp>
only needs 6mb
<crest>
now i finally get >20MB/s at home as well
<tp>
nice
<tp>
I'm on a slow adsl link
<crest>
i'm spoiled by my work infrastructure
<crest>
i'm used to an onsite package repo, 10gb/s links and ssds
<tp>
it didnt update stlink, looks like I'll have to build it
<tp>
nothing like that here unless one works at a university
<crest>
i'm using stlink 1.5 as well
<tp>
oh
<crest>
i just installed stlink from the official package repo and it worked for me
<tp>
ill try 1.6 and see if that fixes the mcu not recognised issue
<crest>
which mcu?
<tp>
yeah worked for me up until the R11 stuff
<tp>
stm32f051 cortex-m0
<tp>
it's a bonafide chip, the ID is valid
<tp>
this chip is used in all STM32F0 Discoveries
<crest>
i port of the bootstrap code to assembler is working
<crest>
but my assembler code won't work on a cortex m0
<tp>
nice!
<tp>
thats ok
<crest>
and *FAST*
<tp>
thumb2 ?
<crest>
yes
<crest>
is there a IT instruction in thumb1?
<tp>
i dont know
<tp>
i dont do much thumb assy
<tp>
mainly some usart reconfigs
<crest>
i'm tempted to claim the default serial port symbol names
<crest>
that way my code wouldn't require any changes to files outside of terminal.s as soon as the allocation has been replaced by a call to ram_allot
<tp>
ahh, why not ?
<tp>
minimal source changes are good
<crest>
doesn't feel "right" as a programmer
<crest>
i tempted to make my code overly complex
<tp>
changes have to stay in terminal.s
<tp>
that way you can get matthias to accept them on a per mcu basis, he will never accept changes to the mainline code
<crest>
and keep the usart as serial console until swdcom connects
<crest>
the only change to the main code is a conditional ramallot
<tp>
he wont accept that I think
<tp>
terminal.s code changes are ok
<crest>
terminal.s changes are trivial to keep as patch
<tp>
but you never know, just ask
<tp>
sure, but hes ok with that is someone maintains it
<tp>
it's the common code he wont change
<crest>
i want to move from ramallot to a call to ram_allot in swd init anyway
<crest>
that way the code is selfcontained in terminal.s