00:00:00 --- log: started forth/20.06.12 00:03:29 --- join: Keshl_ joined #forth 00:03:32 --- quit: Keshl (Read error: Connection reset by peer) 01:08:24 --- quit: reepca (Read error: Connection reset by peer) 01:08:34 --- join: reepca` joined #forth 01:08:59 --- quit: jedb (Ping timeout: 264 seconds) 01:15:44 --- join: jedb joined #forth 01:17:01 --- join: jedb_ joined #forth 01:20:26 --- quit: jedb (Ping timeout: 256 seconds) 01:33:35 --- quit: rprimus (Ping timeout: 272 seconds) 01:33:42 --- join: rprimus joined #forth 01:47:00 --- join: Croran joined #forth 03:32:46 --- join: iyzsong joined #forth 03:34:31 tp: did you install the latest bootstrap.fs on the target microcontroller? 03:34:54 crest I did 03:35:05 crest I always use the latest 03:35:41 commit 33cf768f128b3dc9dd8cea2121a3b03422288558 03:36:09 it may be a stlink-1.5 and cortex-mo isue 05:22:53 --- quit: iyzsong (Quit: ZNC 1.8.0 - https://znc.in) 05:23:05 --- quit: dave0 (Quit: dave's not here) 05:24:15 --- join: iyzsong joined #forth 05:42:41 --- nick: jedb_ -> jedb 05:47:47 --- quit: jedb (Ping timeout: 246 seconds) 05:48:08 --- join: jedb joined #forth 06:14:49 --- quit: mtsd (Quit: Leaving) 06:25:51 --- join: dddddd joined #forth 07:00:05 --- quit: iyzsong (Quit: ZNC 1.8.0 - https://znc.in) 07:01:32 --- join: iyzsong joined #forth 07:03:03 --- quit: iyzsong (Client Quit) 07:17:56 crest: did you see my pull request? 07:20:15 okay, I should be off to work 07:32:23 --- quit: dys (Ping timeout: 264 seconds) 08:24:51 --- join: TCZ joined #forth 08:37:11 --- quit: Zarutian_HTC (Ping timeout: 264 seconds) 08:49:00 --- join: Zarutian_HTC joined #forth 09:51:13 --- join: WickedShell joined #forth 09:56:40 --- join: dys joined #forth 10:18:33 --- quit: Zarutian_HTC (Quit: Bye) 10:28:09 --- quit: jedb (Ping timeout: 256 seconds) 11:01:41 tabemann: i did and it's the first pull request i received as well 11:02:26 of couse i have nothing against the zeptoforth boostrap but i'll have to look over the C code 11:02:41 the changes to Makefile aren't acceptable in its current form because they hardcode gcc 11:03:10 even gmake should provide a default CC value 11:03:32 but given that i just use std=c99 the default compiler should do 11:03:59 i just wanted the latest clang for its static analyzers 11:08:42 --- quit: TCZ (Quit: Leaving) 11:35:20 --- quit: jsoft (Ping timeout: 246 seconds) 11:53:40 tp: did you get swdcom working again? 11:54:58 crest, no, I have to set up another pc to try the latest stlink 11:55:48 tp: did you change something in your hardware setup compared to the last working configuration? 11:56:10 maybe your devd rules don't allow non-root access to this stlink 11:56:23 they do have different product ids 11:56:58 at least my cheap stlink clone and the one the nucleo board different product ids 11:57:14 and yes my error handling is simple and brutal 11:57:20 almost no recovery 11:57:33 no, my hardware is the same 11:57:44 it just reports terse error message and commits suicide 11:57:46 the user rules worked before 11:58:12 i need the command you executed e.g. ./swd2 or ./swd2 addr 11:58:17 ./swd2 11:58:18 2020-06-12T14:58:18 WARN common.c: unknown chip id! 0xffff0040 11:58:18 Failed to open the debugger. 11:58:37 that's an error from libstlink 11:58:41 yeah 11:58:50 it failed to find any (supported) programmer 11:59:18 thats why everything is the same as your prev version that was working 11:59:19 have attempted to unplug and reconnect the programmer? 11:59:39 (stupid question but sometimes stupid things work) 11:59:49 um, Im not sure 11:59:57 I cn easily try it again 11:59:57 maybe your stlink firmware is hung 12:00:07 disconnect it from all power sources 12:00:15 could be, Im not a massive stlink fan 12:00:34 disconnect the swd connection as well 12:00:41 i've seen stange things happen 12:00:55 the stlink dualcolor led was wobulating like with the prev version so it's connected 12:01:06 e.g. a msp430 is efficient enough to run from a max232 tx pin if you send enough data 12:01:23 yeah, theyre the lowest of the low power 12:01:39 --- join: Zarutian_HTC joined #forth 12:01:48 the pcb in question contained a msp430, the firmware a little power management 12:02:12 if you disconnected the pc polling the sensor values it crashed after a while 12:02:38 turns out the battery was in the wrong way and the diode protecting the pcb from stupid users worked 12:04:20 afterward the developer ran a resistor in parallel with the mcu to increase power consumption :-P 12:04:43 repowered the board, running ./swd2 as root 12:04:59 #./swd2 12:05:09 nothing, but not segfaulting 12:05:28 swd programmer led is wobulating 12:06:57 sounds like your user just lacked access permissions to the device node in /dev/usb/* 12:07:27 nicer error handling / reporting is on my todo list 12:07:58 same when running as normal user 12:08:12 no core files now 12:08:20 maybe the power down did that 12:08:52 i have look into how to reset the programmer (without resetting the target as well) 12:08:54 but it's hung up in stlink somewhere, perhaps the unrecognised mcu 12:09:09 i'm not sure if that's possible 12:09:24 ill install FreeBSD 12.1 on a small spare pc and try stlink 1.6 12:09:37 it could be that the SWD protocol has too much state for this to ever work 12:09:38 --- quit: reepca` (Read error: Connection reset by peer) 12:09:44 i cant install it on this old 11.2 box as it's to old 12:09:58 i just want to avoid resetting the target at without user permission 12:10:08 --- join: reepca` joined #forth 12:10:50 I've found stlink slightly flakey anyway 12:11:06 i generally use the serial bootloader for reflashing 12:14:39 --- quit: gravicappa (Ping timeout: 265 seconds) 12:17:29 --- join: gravicappa joined #forth 12:27:25 but they're cheap and fast 12:27:40 true 12:27:44 the protocol includes checksumming and handshakes 12:27:50 serial bootloaders are as fast 12:28:09 so they're a lot better than plaintext over serial 12:28:11 but at least cortex-m gives the choice of everything 12:28:46 sure i could buy a 10Mb/s usart with deep buffers for the host 12:29:00 and implement dma transfers and crc32 checksumming 12:29:07 I think swd is a better choice if it works 12:29:11 it works 12:29:15 cheaper and easier 12:29:38 and the great thing about swd that you don't have to know anything about the mcu peripherals to get a working console 12:29:49 besides, my mcu is compiling as fast as it cant at 460800 baud 12:29:50 this could be very useful to bring up new chips 12:30:03 thats a enormous benefit 12:30:15 just hook up the swd pins and get started 12:30:23 absolutely 12:30:35 btw i found a workaround for the limitations of ramallot 12:30:56 matthis has spent so much time setting up diferent usarts 12:31:08 i could just call the ram_allot part of the allot at startup 12:31:14 the usart on the mo is different to the M3 etc 12:37:11 transmissions from the stm32l476 to the host are even faster now 12:37:15 130661 bytes transferred in 1.259149 secs (103769 bytes/sec) 12:38:26 you would have to run a USART at 1037690 baud 8n1 to match that 12:40:18 that definitely blows my system away 12:40:42 of course my mcu cant compile faster than about 115200 baud anyway 12:40:46 youre sull 12:40:51 yours will 12:41:16 i have to slow it down a little by calling "pause" 12:41:21 ... installing 12.1 atm 12:41:31 otherwise it breaks multitasking 12:41:51 i dont run multitasking 12:41:59 the overhead should be quite low 12:42:12 because only swd-key? and swd-emit? have to call pause 12:42:23 i suspec that the mcu has cycles to spare anyway 12:42:30 probably 12:42:39 it's nice to have the option tho 12:43:02 I only have 8KB ram so more than 2 tasks really eats into my ram 12:43:24 you could reduce the data stack size to 32 cells and the return stack even further 12:44:04 writing clean 32bit code for a microcontroller feels strange 12:44:19 i keep wanting to avoid memory accesses because that's oh so slow 12:44:48 e.g. i wanted to use 16bit loads to check load two 8bit indicies at the same time 12:45:21 but on cortex-m3/m4 one more ram access is faster than the required bit shifting 12:45:52 its not like i have multiple (simple) integer pipelines starved by a one or two load store units 12:46:05 *it's 12:46:53 on the ppc74xx could execute up to four instructions per cycle under the right cirumstances 12:47:28 but had to find ways to avoid memory accesses because there was a single load/store unit 12:49:04 oh the system i nice enough to reset r11 to zero on reset 12:49:39 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 12:51:00 dont the registers have random data at reset ? 12:51:23 doesn't look like it 12:52:31 nice of arm to reset them 12:52:33 or maybe the "random" value just ends up to be zero (most of the time?) 12:52:40 nah 12:52:53 they would be anything 12:53:23 e.g. 32 bit powerpc starts with 0xDEADBEEF in all registers 12:53:43 thats cool 12:53:52 i haven't found any reference to r11 anywhere else in the code 12:54:06 Mecrisp-Stellaris doesnt use R11 12:54:07 but mecrisp could still initialize it with load multiple instructions 12:54:31 i could even wrap the existing default console 12:54:43 problem is that thumb1 cant really use R11 12:54:56 and only switch over to swdcom once something connects 12:54:58 why? 12:55:05 it's only available for a couple of instructions in thumb1 12:55:25 no Mecrisp-Stellaris user will use R11 anyway 12:55:33 as long as mov is one of them the difference is small 12:55:48 Forth people use Forth not assembly except in specific cases 12:55:52 but to be honest i don't care corext m0 right now because i can't test it 12:56:02 if we wanted to use assembly, we wouldnt use Forth 12:56:07 sure 12:56:12 I appreciate that 12:56:13 mecirsp uses a lot more assembler than required for 98% of the performance 12:56:19 *mecrisp 12:56:44 well mecrisp is written in assembler, that doesnt mean that it's users use assembler 12:56:58 matthias loves assembler 12:57:09 just not thumb? 12:57:20 no, he hates thumb 12:57:35 thumb1 or thumb2? 12:57:36 matthias doesnt like cortex-m isa 12:57:54 he a equal opportunity thimbx hater 12:58:07 because while i'm still guessing a lot of time i like the isa 12:58:07 and cortex-m isa is hrrible 12:58:23 matthias loves msp430 isa 12:58:35 and so do I, it's so easy to use 12:58:36 sure msp430 is a programmers dream 12:58:50 a bit like motorola 6800 isa 12:59:00 but with forth, who cares ? 12:59:07 but thumb2 offers 2 operand encoding for common cases 12:59:16 cortex-m is easy with Forth 12:59:17 but has a longer 3 operand format if that fits better 12:59:32 things like the IT instruction are also nice to have 13:00:03 there are pros and cons 13:00:13 the TBB and TBH instructions could be used for a really fast token threaded forth 13:00:15 wait till you look into low power 13:00:31 msp430 is *one* command for low power 13:00:33 that's not what i would consider part of the instruction set 13:00:56 cortex-m is a 3 month brain burn 13:01:04 as a tech, it is to me 13:01:07 it is complex beast 13:01:17 youre a programmer, Im a tech, we have different goals 13:01:37 i know that i know next to nothing about the chip 13:02:39 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 13:02:42 it took me over a day to get the stupid usart remapped from a non existing pin to the default part 13:02:59 and the usart is the easiest of all 13:03:24 turned out was looking in the wrong part of the documention 13:03:29 there is a *massive* learning curve with cortex-m 13:03:46 thats standard, something we all learn at the beginning 13:03:52 that's because the all the cortex-m combine stuff from multiple vendors 13:03:56 the doc is across many places 13:04:01 exactly 13:04:08 the code is created and documented by arm 13:04:09 all the core stuff is arm doc 13:04:20 all the peripheral stuff is STM 13:04:30 and in the middle ... might be anywhere 13:04:30 and arm is designed to support this 13:04:46 and it does, it's immensly useful 13:04:57 thats why I use it and not msp430 13:04:58 so there multiple fast busses from the cpu to the rest of the SoC 13:05:07 a msp430 is tiny by comparison 13:05:12 it is 13:05:33 and has few peripherals in comparison 13:05:45 no RTC on a msp430 13:05:59 which a cortex-m user takes for granted 13:06:36 how much power does the whole msp430 consume with good code compared to just the cortex-m3 rtc? 13:07:02 crap FreeBSD 12.1 uses stlink-1.5.0_2 same as I have here 13:07:19 switch to the latest packages 13:07:39 they are both capable of minuscule power usage 13:07:43 mkdir -p /usr/local/etc/pkg/repos 13:08:05 but where you get it in 5 minutes with msp430, it takes 3 months with cortex-m 13:08:32 echo 'FreeBSD: { url: "pkg+http://pkg.FreeBSD.org/${ABI}/latest" }' > /usr/local/etc/pkg/repos/FreeBSD.conf 13:08:35 k 13:08:36 pkg update 13:08:41 pkg upgrade -yf 13:09:30 updating packages 13:09:53 depending on your connection to the freebsd package cdn this can take a while 13:10:07 we finally got a faster mirror for most of europe 13:10:15 and better routing 13:10:21 323.6kB/s 13:10:34 only needs 6mb 13:10:38 now i finally get >20MB/s at home as well 13:10:44 nice 13:10:52 I'm on a slow adsl link 13:10:56 i'm spoiled by my work infrastructure 13:11:29 i'm used to an onsite package repo, 10gb/s links and ssds 13:11:48 it didnt update stlink, looks like I'll have to build it 13:12:11 nothing like that here unless one works at a university 13:12:34 i'm using stlink 1.5 as well 13:12:46 oh 13:12:58 i just installed stlink from the official package repo and it worked for me 13:13:10 ill try 1.6 and see if that fixes the mcu not recognised issue 13:13:18 which mcu? 13:13:33 yeah worked for me up until the R11 stuff 13:13:43 stm32f051 cortex-m0 13:13:57 it's a bonafide chip, the ID is valid 13:20:34 this chip is used in all STM32F0 Discoveries 13:21:30 i port of the bootstrap code to assembler is working 13:21:45 but my assembler code won't work on a cortex m0 13:21:48 nice! 13:21:53 thats ok 13:21:59 and *FAST* 13:22:13 thumb2 ? 13:22:19 yes 13:30:45 is there a IT instruction in thumb1? 13:30:59 i dont know 13:31:18 i dont do much thumb assy 13:31:29 mainly some usart reconfigs 13:34:04 i'm tempted to claim the default serial port symbol names 13:35:07 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 13:35:29 ahh, why not ? 13:35:44 minimal source changes are good 13:35:44 doesn't feel "right" as a programmer 13:36:12 i tempted to make my code overly complex 13:36:16 changes have to stay in terminal.s 13:36:49 that way you can get matthias to accept them on a per mcu basis, he will never accept changes to the mainline code 13:36:49 and keep the usart as serial console until swdcom connects 13:37:22 the only change to the main code is a conditional ramallot 13:37:54 he wont accept that I think 13:38:09 terminal.s code changes are ok 13:38:29 terminal.s changes are trivial to keep as patch 13:38:33 but you never know, just ask 13:38:51 sure, but hes ok with that is someone maintains it 13:39:11 it's the common code he wont change 13:39:23 i want to move from ramallot to a call to ram_allot in swd init anyway 13:39:44 that way the code is selfcontained in terminal.s 13:40:16 --- join: TCZ joined #forth 13:40:39 nice 13:40:55 do you know how to get a pkg from https://www.freshports.org/devel/stlink ? 13:41:05 i cant find any link to dl a package there 13:41:51 because there is none 13:41:57 freshports is just a search engine 13:42:01 that explains it 13:42:18 i parses mailing lists and svn commits 13:42:27 and indexes the result 13:42:27 stlink advises to go there for a package 13:42:47 I've dl the latest stlink texane 13:44:09 iirc the freebsd (build) had some problems the last few days 13:46:48 well I'm getting nowhere 13:51:37 --- join: X-Scale` joined #forth 13:52:48 --- quit: X-Scale (Ping timeout: 260 seconds) 13:52:48 --- nick: X-Scale` -> X-Scale 14:57:10 --- quit: TCZ (Quit: Leaving) 15:07:09 --- quit: gravicappa (Ping timeout: 260 seconds) 15:22:33 --- join: dave0 joined #forth 16:06:04 --- join: jsoft joined #forth 16:10:21 tabemann: around? 17:19:51 --- quit: Zarutian_HTC (Remote host closed the connection) 17:21:53 what happend between stlink 1.5 and stlink 1.6?!?!? 17:22:11 did the authors switch their drugs? 17:22:29 it logs to stdout instead of stderr 17:22:51 and produces debug logs when asked to log only errors 17:27:51 --- join: iyzsong joined #forth 17:29:53 --- join: X-Scale` joined #forth 17:31:08 --- quit: X-Scale (Ping timeout: 256 seconds) 17:31:09 --- nick: X-Scale` -> X-Scale 17:32:14 hey guys 17:33:01 it's been working smoothly for me 17:33:21 it's not for me 17:33:30 what did you change? 17:33:49 i don't think it's just my problem 17:34:02 even their own tools spam libusb debugging messages to stdout 17:34:46 here is an example: https://pastebin.com/raw/U8Y46TFg 17:35:10 anyway would you be willing to review at my swdcom assembler code? 17:35:42 so the freebsd package suddenly got broken? 17:36:03 not just the port/package 17:36:11 upstream broke (at least on freebsd) 17:36:54 i built directly from upstream as well 17:37:22 I can look at your asm 17:38:55 https://github.com/Crest/swdcom/blob/master/terminal.s 17:41:30 i haven't written arm code before 17:41:48 i'm sure there some things that can be improved by someone more familar with the ISA 17:44:13 you're definitely using some optimizations to make tighter code that I've never used 17:44:19 * tabemann does not try to write clever code 17:45:08 but I'm gonna go eat dinner now, so I'll finish reading your code later 17:45:13 thx 17:49:50 --- join: jedb_ joined #forth 18:24:13 back 18:24:25 still awake 18:28:01 here's some clues 18:28:16 whenever possible, use adds, subs, movs, etc. instructions 18:28:25 they're smaller in memory 18:28:56 they're also thumb-1 instructions 18:30:05 also, have you tried: add r0, 256+4 18:30:19 I don't know if that's kosher or not - it's definitely not kosher in thumb-1 18:42:12 bist du da? 18:42:40 crest 18:43:02 pong 18:44:03 hos would using the *s instructions help? 18:44:06 *how 18:44:22 crest: it would make the instructions take up 16 bits rather than 32 18:44:23 i need explicit comparisons 18:44:38 cmp doesn't take -s 18:45:39 i do use add r0, 256+4 the code compiles and works as expected 18:45:40 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 18:46:03 ok getting more compact code is always nice 18:46:13 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 18:46:31 even if changing the status flags for no good reason feels wrong coming from out of order cpus 18:47:01 changing the status flags for no good reason is the norm on cortex-m 18:47:11 a single 32bit add with imm isn't longer than two 16bit adds and probably faster 18:47:19 yeah 18:47:48 i haven't found time to look at your pull request because of my problems with stlink 1.6 18:47:52 actually it's shorter, because you'd have to do an ldr (literal) which'd read it out of another memory location 18:48:17 crest: I already made an improvement to swd2.c so it can compile fine on both linux and bsd 18:48:52 now I just need to figure out how to do the same with the Makefile 18:48:54 anything that's not covered by your pull request? 18:49:19 let's just use cc instead of gcc or clang 18:49:24 my adding of #if __linux__ in two places to swd2.c 18:49:36 crest: there's also an issue with the library 18:49:48 the library name change is part of stlink 1.6 18:49:52 on my machine at least it has to be -lstlink not -lstlink-shared 18:50:09 which is the version in freebsd ports as well (as of a few days ago) 18:50:22 but the stlink logging code ist just wrong 18:51:14 https://github.com/stlink-org/stlink/blame/develop/src/logging.c#L59 18:51:16 maybe you'll just have to turn off all logging for the time being? 18:51:30 there is no way to turn of logging through the broken wrapper code 18:52:54 compare this to https://svnweb.freebsd.org/base/releng/12.1/lib/libusb/libusb.h?revision=352546&view=markup#l222 18:53:09 they copied the numeric values instead of using the defines 18:53:24 --- quit: WickedShell (Remote host closed the connection) 18:54:56 ugh 18:55:48 --- join: boru` joined #forth 18:55:50 --- quit: boru (Disconnected by services) 18:55:53 --- nick: boru` -> boru 18:58:35 oh and the new st-flash tool fails to write the flash as well 18:59:08 fuckin A 18:59:26 I don't know what I'd do without that 18:59:28 st-flash erase worked 18:59:37 at least it didn't report an error 19:00:00 how did the st-flash people manage to break things so bad 19:00:21 and how did people not notice at let it into things like freebsd? 19:00:26 https://pastebin.com/3vZ87Nce 19:00:27 *and let 19:00:41 i suspect the current port maintainer isn't a daily user 19:00:45 and it compiled 19:00:58 he didn't run any kind of regression testing 19:01:28 but the damn developers of st-flash should've known! 19:02:20 unless they don't test on freebsd 19:02:41 --- quit: iyzsong (Quit: ZNC 1.8.0 - https://znc.in) 19:02:52 that must be it 19:02:58 because I'm using 1.6.0 19:03:02 --- join: iyzsong joined #forth 19:04:55 I'd say complain complain complain on the stlink people's github or wherever 19:04:59 but bbiab 19:05:51 i will 19:06:34 i tried it on the nucleo stm32l476 and the bluepill board 19:06:48 both fail to write 19:07:25 --- quit: MrMobius (Read error: Connection reset by peer) 19:09:18 wtf their latest release fails even worse than the git clone 19:09:26 ld: error: attempted static link of dynamic object /usr/lib/libusb.so 19:18:03 back to the asm code 19:18:30 back 19:18:50 do have any other recommendations than using the *s integer ops 19:19:16 that's the only real thing that stuck out to me as needing changing 19:19:19 and it'll work without them 19:19:26 it'll just take up more space 19:19:28 note 19:19:41 the mov r11, ... instruction has to be mov not movs 19:19:51 because? 19:20:00 because the movs instruction only permits access to registers <= r7 19:20:04 ok 19:20:25 actually 19:20:37 and thumb1 support is out of scope for now because i have no hardware to test it on 19:20:45 wait 19:20:54 that's ldr r11, =... 19:20:57 so forget about it 19:21:13 ldr r11, =... should be just fine 19:21:41 I don't even support M0 with zeptoforth 19:22:07 but unless I wouldn't be saving any memory otherwise I tend to prefer thumb-1 instructions 19:22:11 just for space savings 19:22:42 but I use 32-bit instructions where if I were to use 16-bit instructions I'd need two instructions, in most cases 19:30:28 crest 19:31:03 one little pet peeve 19:31:25 it's spelled "indices" even though it's pronounced "indicies" 19:31:40 English spelling is a pain 19:34:56 --- quit: guan (Ping timeout: 240 seconds) 19:36:07 --- join: MrMobius joined #forth 19:36:59 --- quit: arrdem (Read error: Connection reset by peer) 19:39:50 --- join: arrdem joined #forth 19:43:51 --- quit: arrdem (Read error: Connection reset by peer) 19:46:17 tabemann: thx 19:46:42 does stlink 1.6.1 work for you? 19:47:59 haven't tried it 19:50:34 bak 19:51:15 stlink is a mess, open solaris complained about all kinds of things before it gave up 19:59:09 is there a better library? 19:59:42 no, you have to read the spec and make your own ;-) 20:00:08 rdrop-exit has made his own I think 20:00:13 at that point it would probably be easier to just write my own swd programmer firmware for a cheap board 20:00:51 actualy I think rdrop-exit uses a ftdi cable and their closed source jtag library 20:01:21 maybe ftdi also do a swd library (closed) 20:01:30 i was thinking about using a blue pill 20:01:44 just because they're cheap and should be fast enough 20:01:59 what about the swd interface you have on your own L476 boards ? 20:02:00 and there is forth code for the usb 20:02:25 with the right firmware a blue pill could use the existing usb modem driver 20:02:25 thats what stlink talks to 20:02:25 --- quit: reepca` (Read error: Connection reset by peer) 20:02:44 --- join: reepca` joined #forth 20:03:00 then youre wasting the swd interface on your L476 20:03:27 and anyway, your L476 already has a STM32F103 on it, same as a blue pill 20:03:31 the problem is if yout lift the lid of libstlink a wiff of rotting corpse escapes 20:03:49 it sure does. Im not advocating using it 20:04:01 it's a frigging mes 20:04:13 why use the defines from the header 20:04:29 what I'm saying is that your nucleo (and all discoveries) have a blue pill mcu on one end already 20:04:31 lets just copy their numerical values 20:04:37 *aaaargggghhhhh* 20:05:01 sure but i don't want to wipe that one yet 20:05:41 you can save the firmware first 20:05:47 it's just a micro' 20:06:06 they didn't enable the read out protection? 20:06:16 but sure, if you have to find a use for your blue pills, why not 20:06:31 back 20:06:41 stlink on debian seems to be poorly maintained 20:06:50 I dont think so, or it must have been defeated because you can get them off the web 20:06:57 when I installed the latest it was missing one significant header file 20:07:01 tabemann, yeah, it's a horrorshow 20:07:22 tabemann: i just filed a problem report against the freebsd port as well 20:07:38 besides, the stm32f103 security has been broken, you cant secure your firmware on it 20:07:44 to use the damn libstlink you require headers from the stlink src directory 20:07:59 the ones from their include directory even unconditonally #include them 20:08:03 it's 16 year old, broken, has serious problems 20:08:42 there is no way to use include/stlink.h unless you also copy most headers from their src directory 20:08:43 open solaris complained about a bunch of missing M4 declarations 20:08:48 with stlink 20:09:25 probably because it's written by embedded devs that just want this one feature (e.g. support for the latest mcu) yesterday 20:10:10 after all it has 109 open and 436 issues on github 20:10:11 crest, why not just impliment only the base support you need with (whatever) for swdcom and flash the chip with the serialbootloader ? 20:10:38 because i swdcom needs a working libstlink with headers to build 20:11:04 one that doesn't spam stdout with multiple lines for every usb command 20:11:11 how does it compare to openocd ? 20:11:18 i haven't used openocd 20:11:27 because libstlink 1.5 just worked 20:11:48 and had a short but useful doc/developer.txt and example-app 20:11:54 openocd seems a lot more professional, tho I havent seen the code 20:12:01 back 20:12:03 btw they didn't upgrade their example-app 20:12:37 their example app is incompatible with the new open api that requires a fourth argument 20:12:51 (the swd/jtag clock) 20:16:25 --- join: arrdem joined #forth 20:18:32 --- join: guan joined #forth 20:27:43 which versions of libstlink did you use? 20:33:49 back 20:34:06 I'm trying out stflash 1.6.1 compiled from source 20:34:17 and I'm having much of the same problems 20:34:35 stupid sloppy programmers 20:34:59 they don't even document what should go in the freq parameter 20:35:08 on which operating systems? 20:35:13 on linux! 20:35:22 timeouts as well? 20:35:22 and I can't even run swd2 now 20:35:35 stupid amount of debugging messages? 20:36:59 tno 20:37:00 no 20:37:06 it can't even find the shared library! 20:37:18 and st-flash is appearing as non-existent 20:38:30 oh wait it's in /usr/local/bin 20:38:39 on linux?!? 20:38:40 but when I enter st-flash from the command line it says it can't find it 20:39:10 when enter /usr/local/bin/st-flash it says it can't find libstlink.so.1 20:40:21 * crest just started listening to eisregen again to get ideas how to deal with the culprit 20:41:01 why do you need cmake to build a project with just 22 .c files? 20:42:22 wtf their mmap.c fakes mmap with malloc+read and munmap with free on the memory 20:42:28 what is going on in that codebase 20:42:45 fucking hell! 20:42:51 fucking hell! 20:42:58 it doesn't work for me either!!!! 20:43:17 tabemann: i fixed the typo and used 16bit opcode in the obvious places 20:43:19 did these people ever test their code!!!!! 20:43:38 probably on their macbook with an stlink v3 20:44:16 i just happen to have a mac running macos 10.15 which they claim to support 20:44:37 them and their macbooks can go to hell 20:44:56 --- quit: arrdem (Ping timeout: 240 seconds) 20:45:15 okay the mmap code is just for windows with mingw 20:45:43 did you look into their CMakeLists.txt 20:45:54 guys, openocd works fine with swd as well. I think stlink is just a hack job 20:46:12 but openocs also allows telnet connections 20:46:15 openocd 20:46:32 hmm oops thats gdb 20:46:54 set(STLINK_HEADERS 20:46:54 include/stlink.h 20:46:54 include/stlink/backend.h 20:46:54 include/stlink/chipid.h 20:46:54 include/stlink/commands.h 20:46:55 include/stlink/flash_loader.h 20:46:58 openocd has a ton more facilities than stlink 20:46:59 include/stlink/reg.h 20:47:02 src/logging.h 20:47:04 src/md5.h 20:47:06 src/sg.h 20:47:08 src/usb.h 20:47:10 ) 20:47:39 why oh why didn't someone notice the glaring problem in that 20:47:54 why install any headers at all if they have missing dependencies? 20:49:29 i used stlink because it had a simple to use api 20:49:48 not the most elegant api but good enough 20:50:03 and stlink 1.5.0 just worked 20:50:21 i had my first prototype working in a few hours 20:51:00 by comparison openocd is about as approachable as the stm32l476 reference manual 20:51:48 --- join: arrdem joined #forth 20:52:38 http://openocd.org/doc-release/doxygen/structcortex__m__common__coll__graph.png 20:53:11 --- quit: guan (Ping timeout: 256 seconds) 20:53:39 or http://openocd.org/doc-release/doxygen/targetarm.html 20:58:45 he the STM reference manuals are complete and detailed, tech love them 20:59:29 --- quit: arrdem (Ping timeout: 260 seconds) 20:59:45 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 21:00:12 who knocks an acccurate detailed reference for a complex thing ? 21:00:35 --- quit: reepca` (Read error: Connection reset by peer) 21:00:49 --- join: reepca` joined #forth 21:10:28 --- join: guan joined #forth 21:11:24 i do 21:11:29 --- join: arrdem joined #forth 21:11:35 i didn't say the stm ref man isn't useful 21:11:37 or precise 21:12:09 just that it falls far shor of what is needed 21:12:31 the customers stm cares about know how to deal with it 21:12:54 and just call their STM contact person if something isn't clear 21:13:41 the rest of the world just has to survive on their scraps 21:14:20 125 downloads of my stm32f103-diages ine the last few days 21:14:21 --- quit: reepca` (Read error: Connection reset by peer) 21:14:55 --- quit: guan (Read error: Connection reset by peer) 21:14:57 --- join: reepca` joined #forth 21:15:24 --- join: guan joined #forth 21:20:52 back 21:20:57 I had to revert to 1.6.0 21:21:07 and it worked perfectly after I did 21:21:19 why in hell was 1.6.1 such a royal fuckup 21:21:39 I posted not one but two issues on the stlink github 21:22:08 one was to point out that A) st-link write didn't work 21:22:30 one was to point out that they really screwed up with their handling of headers 21:33:10 i agree 21:33:19 --- quit: dave0 (Quit: dave's not here) 21:33:27 i just tried the 1.6.0 tarball from github on freebsd 21:33:31 and it works 21:36:03 tabemann, with 109 open issues dont expect a fast reply 21:36:09 https://github.com/stlink-org/stlink/issues/976#issuecomment-638309076 21:37:29 it seems like they made a lot of changes, more than one would expect from a patch-level version update 21:37:50 the build directory layout is different as well 21:37:53 and they were sloppy in the process 21:38:03 they also now have .rpm and .deb builds 21:38:27 but they claim to follow semantic versioning ROFL 21:39:03 to me it seems like that it should be 6.1.0 rather than 1.6.1 21:39:26 that is semantic versioning 21:39:36 naah 21:39:58 they just fucked up 21:40:01 it happens 21:40:18 they fucked up, yes, but they also tried to roll out a lot of changes 21:40:41 they even changed the command line format 21:40:48 in incompatible ways? 21:40:59 or just options? 21:41:02 I tried entering st-flash write zeptoforth.bin 08000000 21:41:05 and it complained 21:41:08 0x 21:41:22 I had to enter st-flash write zeptoforth.bin 0x08000000 21:41:37 i didn't know that the 0x was optional 21:41:42 *used to be 21:43:02 * tabemann suspects that zeptoforth will always be at 0.x 21:46:57 tabemann: do those changes make sense to you: https://github.com/Crest/swdcom/commit/326c6d4a9754bdc5d2efcb932f4cdd009d8ef689?diff=split 21:47:38 turns out that inside if-then blocks it doens't matter which endcoding i used 21:48:36 i assume that branching would still be slower for a single instruction on each path 21:50:30 that looks right to me 21:51:29 i used the shell-storm.org asm -> (quoted) hex webinterface to check the output length 21:52:24 some instructions required a 32bit encoding for other reasons e.g. larger imm values 21:52:56 in those cases i kept the version without flag updates 21:54:41 yeah, I noticed that with AND 21:54:48 AND immediate is always 32-bit 22:02:18 welche Zeit ist es in Deutschland? 22:02:38 7am 22:03:15 oder auf deutsch: Es ist 7 Uhr morgens. 22:04:36 I should get to bed myself, as I've got work to do tomorrow morning 22:04:42 that sucks 22:04:53 ja 22:07:55 g'night 22:34:44 --- quit: reepca` (Ping timeout: 246 seconds) 22:45:24 --- quit: _whitelogger (Remote host closed the connection) 22:48:24 --- join: _whitelogger joined #forth 22:52:03 --- nick: jedb_ -> jedb 22:52:45 --- quit: jsoft (Ping timeout: 256 seconds) 23:05:13 --- join: gravicappa joined #forth 23:59:59 --- log: ended forth/20.06.12