Zarutian_HTC has quit [Remote host closed the connection]
<crest> what happend between stlink 1.5 and stlink 1.6?!?!?
<crest> did the authors switch their drugs?
<crest> it logs to stdout instead of stderr
<crest> and produces debug logs when asked to log only errors
iyzsong has joined #forth
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
<tabemann> hey guys
<tabemann> it's been working smoothly for me
<crest> it's not for me
<tabemann> what did you change?
<crest> i don't think it's just my problem
<crest> even their own tools spam libusb debugging messages to stdout
<crest> here is an example: https://pastebin.com/raw/U8Y46TFg
<crest> anyway would you be willing to review at my swdcom assembler code?
<tabemann> so the freebsd package suddenly got broken?
<crest> not just the port/package
<crest> upstream broke (at least on freebsd)
<crest> i built directly from upstream as well
<tabemann> I can look at your asm
<crest> i haven't written arm code before
<crest> i'm sure there some things that can be improved by someone more familar with the ISA
<tabemann> you're definitely using some optimizations to make tighter code that I've never used
* tabemann does not try to write clever code
<tabemann> but I'm gonna go eat dinner now, so I'll finish reading your code later
<crest> thx
jedb_ has joined #forth
<tabemann> back
<crest> still awake
<tabemann> here's some clues
<tabemann> whenever possible, use adds, subs, movs, etc. instructions
<tabemann> they're smaller in memory
<tabemann> they're also thumb-1 instructions
<tabemann> also, have you tried: add r0, 256+4
<tabemann> I don't know if that's kosher or not - it's definitely not kosher in thumb-1
<tabemann> bist du da?
<tabemann> crest
<crest> pong
<crest> hos would using the *s instructions help?
<crest> *how
<tabemann> crest: it would make the instructions take up 16 bits rather than 32
<crest> i need explicit comparisons
<tabemann> cmp doesn't take -s
<crest> i do use add r0, 256+4 the code compiles and works as expected
<tabemann> it just turns out that most of the thumb-1 instructions are -s instructions, even though the flags they set do nothing else followed by an instruction like beq
<crest> ok getting more compact code is always nice
<tabemann> okay, that must be compiling to a 32 bit instruction - but that's fine, because doing it the thumb-1 way in that case would actually take up more space
<crest> even if changing the status flags for no good reason feels wrong coming from out of order cpus
<tabemann> changing the status flags for no good reason is the norm on cortex-m
<crest> a single 32bit add with imm isn't longer than two 16bit adds and probably faster
<tabemann> yeah
<crest> i haven't found time to look at your pull request because of my problems with stlink 1.6
<tabemann> actually it's shorter, because you'd have to do an ldr (literal) which'd read it out of another memory location
<tabemann> crest: I already made an improvement to swd2.c so it can compile fine on both linux and bsd
<tabemann> now I just need to figure out how to do the same with the Makefile
<crest> anything that's not covered by your pull request?
<crest> let's just use cc instead of gcc or clang
<tabemann> my adding of #if __linux__ in two places to swd2.c
<tabemann> crest: there's also an issue with the library
<crest> the library name change is part of stlink 1.6
<tabemann> on my machine at least it has to be -lstlink not -lstlink-shared
<crest> which is the version in freebsd ports as well (as of a few days ago)
<crest> but the stlink logging code ist just wrong
<tabemann> maybe you'll just have to turn off all logging for the time being?
<crest> there is no way to turn of logging through the broken wrapper code
<crest> they copied the numeric values instead of using the defines
WickedShell has quit [Remote host closed the connection]
<tabemann> ugh
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<crest> oh and the new st-flash tool fails to write the flash as well
<tabemann> fuckin A
<tabemann> I don't know what I'd do without that
<crest> st-flash erase worked
<crest> at least it didn't report an error
<tabemann> how did the st-flash people manage to break things so bad
<tabemann> and how did people not notice at let it into things like freebsd?
<tabemann> *and let
<crest> i suspect the current port maintainer isn't a daily user
<crest> and it compiled
<crest> he didn't run any kind of regression testing
<tabemann> but the damn developers of st-flash should've known!
<crest> unless they don't test on freebsd
iyzsong has quit [Quit: ZNC 1.8.0 - https://znc.in]
<tabemann> that must be it
<tabemann> because I'm using 1.6.0
iyzsong has joined #forth
<tabemann> I'd say complain complain complain on the stlink people's github or wherever
<tabemann> but bbiab
<crest> i will
<crest> i tried it on the nucleo stm32l476 and the bluepill board
<crest> both fail to write
MrMobius has quit [Read error: Connection reset by peer]
<crest> wtf their latest release fails even worse than the git clone
<crest> ld: error: attempted static link of dynamic object /usr/lib/libusb.so
<crest> back to the asm code
<tabemann> back
<crest> do have any other recommendations than using the *s integer ops
<tabemann> that's the only real thing that stuck out to me as needing changing
<tabemann> and it'll work without them
<tabemann> it'll just take up more space
<tabemann> note
<tabemann> the mov r11, ... instruction has to be mov not movs
<crest> because?
<tabemann> because the movs instruction only permits access to registers <= r7
<crest> ok
<tabemann> actually
<crest> and thumb1 support is out of scope for now because i have no hardware to test it on
<tabemann> wait
<tabemann> that's ldr r11, =...
<tabemann> so forget about it
<tabemann> ldr r11, =... should be just fine
<tabemann> I don't even support M0 with zeptoforth
<tabemann> but unless I wouldn't be saving any memory otherwise I tend to prefer thumb-1 instructions
<tabemann> just for space savings
<tabemann> but I use 32-bit instructions where if I were to use 16-bit instructions I'd need two instructions, in most cases
<tabemann> crest
<tabemann> one little pet peeve
<tabemann> it's spelled "indices" even though it's pronounced "indicies"
<tabemann> English spelling is a pain
guan has quit [Ping timeout: 240 seconds]
MrMobius has joined #forth
arrdem has quit [Read error: Connection reset by peer]
arrdem has joined #forth
arrdem has quit [Read error: Connection reset by peer]
<crest> tabemann: thx
<crest> does stlink 1.6.1 work for you?
<tabemann> haven't tried it
<tp> bak
<tp> stlink is a mess, open solaris complained about all kinds of things before it gave up
<crest> is there a better library?
<tp> no, you have to read the spec and make your own ;-)
<tp> rdrop-exit has made his own I think
<crest> at that point it would probably be easier to just write my own swd programmer firmware for a cheap board
<tp> actualy I think rdrop-exit uses a ftdi cable and their closed source jtag library
<tp> maybe ftdi also do a swd library (closed)
<crest> i was thinking about using a blue pill
<crest> just because they're cheap and should be fast enough
<tp> what about the swd interface you have on your own L476 boards ?
<crest> and there is forth code for the usb
<tp> thats what stlink talks to
<crest> with the right firmware a blue pill could use the existing usb modem driver
reepca` has quit [Read error: Connection reset by peer]
reepca` has joined #forth
<tp> then youre wasting the swd interface on your L476
<tp> and anyway, your L476 already has a STM32F103 on it, same as a blue pill
<crest> the problem is if yout lift the lid of libstlink a wiff of rotting corpse escapes
<tp> it sure does. Im not advocating using it
<tp> it's a frigging mes
<crest> why use the defines from the header
<tp> what I'm saying is that your nucleo (and all discoveries) have a blue pill mcu on one end already
<crest> lets just copy their numerical values
<crest> *aaaargggghhhhh*
<crest> sure but i don't want to wipe that one yet
<tp> you can save the firmware first
<tp> it's just a micro'
<crest> they didn't enable the read out protection?
<tp> but sure, if you have to find a use for your blue pills, why not
<tabemann> back
<tabemann> stlink on debian seems to be poorly maintained
<tp> I dont think so, or it must have been defeated because you can get them off the web
<tabemann> when I installed the latest it was missing one significant header file
<tp> tabemann, yeah, it's a horrorshow
<crest> tabemann: i just filed a problem report against the freebsd port as well
<tp> besides, the stm32f103 security has been broken, you cant secure your firmware on it
<crest> to use the damn libstlink you require headers from the stlink src directory
<crest> the ones from their include directory even unconditonally #include them
<tp> it's 16 year old, broken, has serious problems
<crest> there is no way to use include/stlink.h unless you also copy most headers from their src directory
<tp> open solaris complained about a bunch of missing M4 declarations
<tp> with stlink
<crest> probably because it's written by embedded devs that just want this one feature (e.g. support for the latest mcu) yesterday
<crest> after all it has 109 open and 436 issues on github
<tp> crest, why not just impliment only the base support you need with (whatever) for swdcom and flash the chip with the serialbootloader ?
<crest> because i swdcom needs a working libstlink with headers to build
<crest> one that doesn't spam stdout with multiple lines for every usb command
<tp> how does it compare to openocd ?
<crest> i haven't used openocd
<crest> because libstlink 1.5 just worked
<crest> and had a short but useful doc/developer.txt and example-app
<tp> openocd seems a lot more professional, tho I havent seen the code
<tabemann> back
<crest> btw they didn't upgrade their example-app
<crest> their example app is incompatible with the new open api that requires a fourth argument
<crest> (the swd/jtag clock)
arrdem has joined #forth
guan has joined #forth
<crest> which versions of libstlink did you use?
<tabemann> back
<tabemann> I'm trying out stflash 1.6.1 compiled from source
<tabemann> and I'm having much of the same problems
<tabemann> stupid sloppy programmers
<tabemann> they don't even document what should go in the freq parameter
<crest> on which operating systems?
<tabemann> on linux!
<crest> timeouts as well?
<tabemann> and I can't even run swd2 now
<crest> stupid amount of debugging messages?
<tabemann> tno
<tabemann> no
<tabemann> it can't even find the shared library!
<tabemann> and st-flash is appearing as non-existent
<tabemann> oh wait it's in /usr/local/bin
<crest> on linux?!?
<tabemann> but when I enter st-flash from the command line it says it can't find it
<tabemann> when enter /usr/local/bin/st-flash it says it can't find libstlink.so.1
* crest just started listening to eisregen again to get ideas how to deal with the culprit
<crest> why do you need cmake to build a project with just 22 .c files?
<crest> wtf their mmap.c fakes mmap with malloc+read and munmap with free on the memory
<crest> what is going on in that codebase
<tabemann> fucking hell!
<tabemann> fucking hell!
<tabemann> it doesn't work for me either!!!!
<crest> tabemann: i fixed the typo and used 16bit opcode in the obvious places
<tabemann> did these people ever test their code!!!!!
<crest> probably on their macbook with an stlink v3
<crest> i just happen to have a mac running macos 10.15 which they claim to support
<tabemann> them and their macbooks can go to hell
arrdem has quit [Ping timeout: 240 seconds]
<crest> okay the mmap code is just for windows with mingw
<crest> did you look into their CMakeLists.txt
<tp> guys, openocd works fine with swd as well. I think stlink is just a hack job
<tp> but openocs also allows telnet connections
<tp> openocd
<tp> hmm oops thats gdb
<crest> set(STLINK_HEADERS
<crest> include/stlink/backend.h
<crest> include/stlink/commands.h
<crest> include/stlink.h
<crest> include/stlink/chipid.h
<crest> include/stlink/flash_loader.h
<tp> openocd has a ton more facilities than stlink
<crest> include/stlink/reg.h
<crest> src/logging.h
<crest> src/md5.h
<crest> src/sg.h
<crest> src/usb.h
<crest> )
<crest> why oh why didn't someone notice the glaring problem in that
<crest> why install any headers at all if they have missing dependencies?
<crest> i used stlink because it had a simple to use api
<crest> not the most elegant api but good enough
<crest> and stlink 1.5.0 just worked
<crest> i had my first prototype working in a few hours
<crest> by comparison openocd is about as approachable as the stm32l476 reference manual
arrdem has joined #forth
guan has quit [Ping timeout: 256 seconds]
<tp> he the STM reference manuals are complete and detailed, tech love them
arrdem has quit [Ping timeout: 260 seconds]
<tp> dont knock a STM ref manual before you try a Chinese one for something like the GS32VF103, it's a nightmare and had a ton of errors
<tp> who knocks an acccurate detailed reference for a complex thing ?
reepca` has quit [Read error: Connection reset by peer]
reepca` has joined #forth
guan has joined #forth
<crest> i do
arrdem has joined #forth
<crest> i didn't say the stm ref man isn't useful
<crest> or precise
<crest> just that it falls far shor of what is needed
<crest> the customers stm cares about know how to deal with it
<crest> and just call their STM contact person if something isn't clear
<crest> the rest of the world just has to survive on their scraps
<tp> 125 downloads of my stm32f103-diages ine the last few days
reepca` has quit [Read error: Connection reset by peer]
guan has quit [Read error: Connection reset by peer]
reepca` has joined #forth
guan has joined #forth
<tabemann> back
<tabemann> I had to revert to 1.6.0
<tabemann> and it worked perfectly after I did
<tabemann> why in hell was 1.6.1 such a royal fuckup
<tabemann> I posted not one but two issues on the stlink github
<tabemann> one was to point out that A) st-link write didn't work
<tabemann> one was to point out that they really screwed up with their handling of headers
<crest> i agree
dave0 has quit [Quit: dave's not here]
<crest> i just tried the 1.6.0 tarball from github on freebsd
<crest> and it works
<tp> tabemann, with 109 open issues dont expect a fast reply
<tabemann> it seems like they made a lot of changes, more than one would expect from a patch-level version update
<crest> the build directory layout is different as well
<tabemann> and they were sloppy in the process
<tabemann> they also now have .rpm and .deb builds
<crest> but they claim to follow semantic versioning ROFL
<tabemann> to me it seems like that it should be 6.1.0 rather than 1.6.1
<tabemann> that is semantic versioning
<crest> naah
<crest> they just fucked up
<crest> it happens
<tabemann> they fucked up, yes, but they also tried to roll out a lot of changes
<tabemann> they even changed the command line format
<crest> in incompatible ways?
<crest> or just options?
<tabemann> I tried entering st-flash write zeptoforth.bin 08000000
<tabemann> and it complained
<crest> 0x
<tabemann> I had to enter st-flash write zeptoforth.bin 0x08000000
<crest> i didn't know that the 0x was optional
<crest> *used to be
* tabemann suspects that zeptoforth will always be at 0.x
<crest> turns out that inside if-then blocks it doens't matter which endcoding i used
<crest> i assume that branching would still be slower for a single instruction on each path
<tabemann> that looks right to me
<crest> i used the shell-storm.org asm -> (quoted) hex webinterface to check the output length
<crest> some instructions required a 32bit encoding for other reasons e.g. larger imm values
<crest> in those cases i kept the version without flag updates
<tabemann> yeah, I noticed that with AND
<tabemann> AND immediate is always 32-bit
<tabemann> welche Zeit ist es in Deutschland?
<crest> 7am
<crest> oder auf deutsch: Es ist 7 Uhr morgens.
<tabemann> I should get to bed myself, as I've got work to do tomorrow morning
<crest> that sucks
<tabemann> ja
<tabemann> g'night
reepca` has quit [Ping timeout: 246 seconds]
_whitelogger has joined #forth
jedb_ is now known as jedb
jsoft has quit [Ping timeout: 256 seconds]
gravicappa has joined #forth
jsoft has joined #forth
jsoft has quit [Max SendQ exceeded]
jsoft has joined #forth
dddddd has quit [Ping timeout: 246 seconds]
jedb has quit [Ping timeout: 246 seconds]
jedb has joined #forth
andrei-n has joined #forth
iyzsong has quit [Quit: ZNC 1.8.0 - https://znc.in]
iyzsong has joined #forth
jedb has quit [Ping timeout: 258 seconds]
jedb_ has joined #forth
TCZ has joined #forth
iyzsong has quit [Quit: ZNC 1.8.0 - https://znc.in]
iyzsong has joined #forth
dddddd has joined #forth
TCZ has quit [Quit: Leaving]
TCZ has joined #forth
reepca has joined #forth
iyzsong has quit [Quit: ZNC 1.8.0 - https://znc.in]
TCZ has quit [Quit: Leaving]
iyzsong has joined #forth
iyzsong has quit [Quit: ZNC 1.8.0 - https://znc.in]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Ping timeout: 264 seconds]
Zarutian_HTC has joined #forth
Zarutian_HTC has quit [Ping timeout: 265 seconds]
jedb_ has quit [Ping timeout: 264 seconds]
jsoft has quit [Ping timeout: 256 seconds]
Zarutian_HTC has joined #forth
TCZ has joined #forth
TCZ has quit [Quit: Leaving]
WickedShell has joined #forth
<andrei-n> Hello. Do you use ROBODoc with Forth? If so, I would like to see some examples...
dave0 has joined #forth
andrei-n has quit [Quit: Leaving]
<crest> tabemann: the stlink developers responded
TCZ has joined #forth
gravicappa has quit [Ping timeout: 258 seconds]
<tp> tabemann, NOTICE: This bug report may be closed without further notice, if not enough information is provided! ... ACHTUNG!!!! if not enough information is provided the bug will go away and fix itself!!!!
TCZ has quit [Quit: Leaving]
WickedShell has quit [Remote host closed the connection]
jsoft has joined #forth