00:00:00 --- log: started forth/20.06.11
00:01:11 --- quit: Zarutian_HTC (Ping timeout: 264 seconds)
00:52:40 <tp> crest, ping, problem with Makefile "nothing to compile"
00:53:13 <jackdaniel> it should print somethign mroe consoling, like "All good."
00:53:34 <tp> Makefiles are like that, they have no heart
01:04:21 --- quit: jedb (Read error: Connection reset by peer)
01:11:28 --- join: jedb joined #forth
01:16:25 --- join: mtsd joined #forth
01:32:30 --- join: andrei-n joined #forth
01:43:16 --- quit: klys (Ping timeout: 256 seconds)
01:43:35 --- join: klys joined #forth
02:05:01 --- join: jedb_ joined #forth
02:06:35 --- quit: jsoft (Ping timeout: 264 seconds)
02:07:23 --- quit: jedb (Ping timeout: 246 seconds)
02:19:13 --- quit: gravicappa (Ping timeout: 258 seconds)
02:44:52 --- quit: WickedShell (Remote host closed the connection)
03:25:16 --- quit: andrei-n (Quit: Leaving)
03:30:16 <crest> tp: pong
03:31:15 <crest> cd swdcom && gitpull && make clean && make
03:31:34 <crest> you also have to run the latest bootstrap.fs
03:35:21 --- join: iyzsong joined #forth
04:39:29 --- join: dddddd joined #forth
05:53:49 --- quit: mtsd (Quit: Leaving)
07:40:07 --- quit: iyzsong (Quit: ZNC 1.8.0 - https://znc.in)
08:59:38 --- join: gravicappa joined #forth
10:19:28 --- join: WickedShell joined #forth
10:35:56 --- quit: jedb_ (Ping timeout: 256 seconds)
11:02:50 --- join: Zarutian_HTC joined #forth
11:03:55 --- quit: Zarutian_HTC (Client Quit)
11:04:15 --- join: Zarutian_HTC joined #forth
12:24:50 --- quit: Zarutian_HTC (Remote host closed the connection)
12:31:58 --- join: dave0 joined #forth
12:34:28 --- join: andrei-n joined #forth
12:52:53 --- quit: reepca (Read error: Connection reset by peer)
12:53:11 --- join: reepca joined #forth
12:57:32 --- quit: proteusguy (Ping timeout: 256 seconds)
12:58:19 --- quit: proteus-guy (Ping timeout: 265 seconds)
13:09:45 --- join: proteusguy joined #forth
13:09:45 --- mode: ChanServ set +v proteusguy
13:11:06 --- join: proteus-guy joined #forth
13:34:12 <crest> tp: did it work for you?
13:40:50 --- join: TCZ joined #forth
13:42:38 --- join: Zarutian_HTC joined #forth
13:52:22 --- join: X-Scale` joined #forth
13:53:23 --- quit: X-Scale (Ping timeout: 256 seconds)
13:53:24 --- nick: X-Scale` -> X-Scale
14:00:56 <crest> tp: i got the serial port working
14:12:54 --- quit: andrei-n (Quit: Leaving)
14:26:52 <crest> damn it the virtual com port gets suck for some reason
14:27:16 <crest> oh shit even with ascii-xfr -s -l200 it gets stuck after a few lines
14:27:33 <crest> asci-xfr -s -c 10 works so far but is even slower
14:38:54 --- quit: TCZ (Quit: Leaving)
15:03:08 --- quit: gravicappa (Ping timeout: 260 seconds)
16:25:25 --- quit: dave0 (Quit: dave's not here)
16:35:32 --- join: dave0 joined #forth
17:19:58 <tp> crest, no your makefile is missing something
17:20:08 <crest> strange
17:20:22 <tp> have a look at it ?
17:20:27 <crest> sure
17:20:29 <tp> there is no target
17:20:52 <crest> the makefile defines two targets swd2 and clean
17:21:00 <crest> and marks clean as phony
17:21:49 <crest> the stlink virtual com port hangs on uploads
17:21:59 <tp> CC?=clang
17:22:00 <tp> CSTD=c99
17:22:00 <tp> WARN=-Weverything # Excessive
17:22:00 <tp> CFLAGS+=-std=$(CSTD)
17:22:00 <tp> CFLAGS+=$(WARN)
17:22:01 <tp> CFLAGS+=-I/usr/local/include
17:22:03 <tp> CFLAGS+=-L/usr/local/lib
17:22:05 <tp> LDFLAGS+=-lstlink-shared
17:22:07 <tp> swd2: swd2.c
17:22:09 <tp> 	$(CC) $(CFLAGS) -o $(.TARGET) $(.ALLSRC) $(LDFLAGS)
17:22:11 <tp> .PHONY: clean
17:22:13 <tp> clean:
17:22:15 <tp> 	rm -f swd2
17:22:19 <crest> looks good
17:22:31 <tp> oh
17:22:34 <crest> that makefile defines two targets (swd2 and clean)
17:23:03 <tp> apologies I was using gmake
17:23:05 <tp> !
17:23:09 <tp> make works
17:23:35 <tp> now I can try it :)
17:26:59 <crest> yeah gmake lacks the long names $(.TARGET) and $(.ALLSRC)
17:28:54 <tp> ahh, sorry for wasting your time
17:29:48 <tp> I was thinking, rather than using lower bits of R11 for status, why not assign a ram cell after the buffer ?
17:30:02 <tp> that way you wont need to halt the cpu ?
17:30:40 <tp> and as you know the buffer address, the ram cell would be buffer + 1 so youd know that also
17:37:50 <tp>  ./swd2 20001D58
17:38:09 <tp> 2020-06-12T10:37:03 WARN common.c: unknown chip id! 0xffff0040
17:38:09 <tp> Failed to open the debugger.
17:56:55 <crest> if i knew any address in sram i why not pick the buffer start address?
17:57:21 <crest> i need r11 to discover where in sram the buffer is stored
17:57:48 <crest> the memory layout is <indicies> <buffer> <buffer>
18:05:15 <crest> i have a working swd-key? in assembler
18:14:48 --- join: jedb joined #forth
18:56:30 --- join: boru` joined #forth
18:56:33 --- quit: boru (Disconnected by services)
18:56:36 --- nick: boru` -> boru
19:10:23 <tabemann> hey guys
19:19:06 <tabemann> ist jemand hier?
19:24:29 <tabemann> crest
19:24:38 <crest> no
19:24:42 <crest> i'm sleeping
19:24:50 <tabemann> ich vestehe es
19:25:00 <crest> i'm not stupid enough to hack through the night ... again
19:25:02 <tp> early night at 04:30 am ?
19:26:15 <tabemann> ich werde dich schlafen lassen
19:27:14 <crest> my assembler code crashes after a receiving a few bytes
19:27:51 <tabemann> mein Deutsch ist nicht gut genug, die Kommentare von Matthias zu verstehen
19:28:01 <crest> mine is :-P
19:35:53 <crest> does this make any sense:
19:35:56 <crest> @ -----------------------------------------------------------------------------
19:35:56 <crest>   Wortbirne Flag_visible, "swd-key" @ ( -- c )
19:35:56 <crest> @ -----------------------------------------------------------------------------
19:35:56 <crest>    dup
19:35:57 <crest>    ldrb r0, [r11, #1]
19:35:58 <crest> 1: ldrb r1, [r11, #0]
19:36:01 <crest>    cmp r0, r1
19:36:03 <crest>    beq 1b
19:36:05 <crest>    
19:36:07 <crest>    add r1, r0, 4
19:36:09 <crest>    ldrb tos, [r1, r11]
19:36:12 <crest>    add r0, 1
19:36:14 <crest>    strb r0, [r11, #1]
19:36:16 <crest>    bx lr
19:36:19 <crest> r11 + 0 is the RX ring buffer read index
19:36:30 <crest> r11 + 1 the RX ring buffer write index
19:37:10 <tabemann> it's not compatible with multitasking
19:37:15 <crest> why not?
19:37:22 <crest> not that multitasking should be enabled
19:37:28 <crest> because it doesn't yield?
19:37:33 <tabemann> you'll want a PAUSE in there
19:37:33 --- join: jsoft joined #forth
19:37:42 <crest> okay let's ignore that for now
19:38:10 <crest> i don't see how it can crash after a few bytes
19:38:16 <crest> (unhandled interrupt 3)
19:38:57 <tabemann> wwwaaaaaiiittt
19:38:59 <crest> ?
19:39:11 <tabemann>    ldrb tos, [r1, r11]
19:39:24 <crest> yes?
19:39:41 <tabemann> oh actually it doesn't matter which order you put r1 and r11 in
19:40:19 <crest> and ldrb does zero extends doesn't it
19:40:34 <crest> so there is no way for something to remain in the upper 24 bits
19:40:43 <tabemann> ldrb doesn't zero extend
19:41:15 <crest> what does it do instead?
19:41:28 <crest> preserve the upper bits?
19:41:46 <tabemann> oh I realized a problem
19:41:56 <crest> that would explain everything (the index would include lots of undefined) upper bits
19:41:57 <tabemann> you can't test for r0 equals r1
19:42:02 <crest> why not?
19:42:11 <tabemann> because that means you're empty
19:42:34 <crest> the RX buffer is empty if both indicies are equal
19:42:55 <tabemann> oh wait it's key not emit
19:43:14 <crest> i wait until they differ
19:44:04 <tabemann> okay, forget everything I've said
19:44:23 <tabemann> it looks like it should work
19:44:33 <crest> but how does ramallot work?
19:44:51 <crest> could it be that i'm overwriting memory that doesn't belong to me?
19:45:16 <crest> i added this to terminal.s
19:45:17 <crest> .equ SWD_Size, 4 + (2 * 256)
19:45:17 <crest> ramallot SWD_Base, SWD_Size
19:45:58 <crest> @ -----------------------------------------------------------------------------
19:45:58 <crest>   Wortbirne Flag_visible, "swd-init"
19:45:58 <crest> @ -----------------------------------------------------------------------------
19:45:58 <crest>    ldr r11, =SWD_Base
19:45:58 <crest>    eor r0, r0
19:45:59 <crest>    str r0, [r11]
19:46:01 <crest>    bx lr
19:46:40 <crest> could terminal.s be too late?
19:46:51 <tabemann> that looks like it should be good
19:46:57 <crest> maybe something already summed up all the allocations
19:47:18 <tabemann> wait a second
19:47:22 <tabemann> it might be too late
19:47:28 <tabemann> if you're automatically reading r11
19:47:50 <tabemann> unless you boot mecrisp-stellaris
19:47:53 <tp> maybe it's taken by Mecrisp-Stellaris ?
19:48:00 <tabemann> and then attach swdcom
19:48:11 <tp> you need to exclude ram from Mecrisp-Stellaris first
19:48:22 <tp> or it will use it
19:48:25 <tabemann> ramallot is static, at compile time
19:48:28 <crest> isn't that what the ramallot macro is for?
19:48:45 <tp> mecrisps ram allotment is hardwired
19:49:12 <tabemann> and that's what crest is doing
19:49:21 <tabemann> adding another hardwired ram allotment
19:49:26 <tp> matthias says he always excludes the ram he needs when making a special buffer outside Mecrisp-Stellaris 
19:50:04 <crest> fuck forth-core.s does contain the sume
19:50:05 <crest> *sum
19:50:32 <tp> the ram allotment is specified in source/cpu.s
19:50:53 <crest> that's not the problem
19:51:00 <tp> where cpu = your cpu
19:51:17 <tp> ok
19:51:34 <crest> after all static allocations are done in the code
19:51:50 <crest> the .equ RamDictionaryAnfang
19:51:52 <crest> is the problem
19:52:15 <crest> the memory layout is all your static allocations followed by the ram dictionary
19:52:29 <crest> allocations after that are invalid
19:54:58 <crest> with the memory corruption fixed it works
20:00:50 <tabemann> do you have a version of your code that doesn't use the integrated assembly, but rather just has the inline instructions?
20:01:34 <tabemann> because I don't want to modify my kernel, but rather to rely upon code loaded after the fact
20:01:53 <tabemann> because integrating it with the kernel will make it harder to integrate with my multitasker
20:02:28 <crest> 1048576 bytes transferred in 11.618941 secs (90247 bytes/sec)
20:03:10 <crest> i transmitted 1MiB in less than 12 seconds
20:03:29 <crest> (without further processing on the stm32l476)
20:03:38 <crest> supposedly running at 48mhz
20:04:19 <crest> with one start and stop bit per frame that is the optimal throughput of a 902470 baud serial port
20:05:26 <crest> once i finish this code it should simplify porting mecrisp to new chips a lot
20:05:49 <tp> wow
20:05:52 <tp> thats fast!
20:05:57 <tabemann> nice
20:06:27 <crest> because you don't have to configure a single gpio pin or interrupt to get a fast and reliable console
20:06:40 <tp> which is ideal on a cortex-m
20:08:17 <crest> afk
20:28:53 <tabemann> I can confirm that it works on zeptoforth
20:29:13 <tabemann> not with the assembly version, but just the version with the inline mov r11, r6 instruction
20:29:31 <tp> nive
20:29:33 <tp> nice
20:29:38 <tp> I had a error
20:30:03 <tp> ./swd2 20001D58
20:30:09 <tp> 2020-06-12T10:37:03 WARN common.c: unknown chip id! 0xffff0040
20:30:41 <tp> is that how you start the new inline version ?
20:30:52 <tabemann> no
20:30:56 <tabemann> I just do ./swd2
20:30:59 <tp> ./swd2 by itself didnt do anything
20:31:05 <tabemann> pull the latest
20:31:11 <tp> I di
20:31:13 <tp> did
20:31:24 <tabemann> I just pulled the latest like a few minutes ago
20:31:26 <tp> I always build from the latest
20:31:50 <tabemann> I stashed my version, pulled, then unstashed, allowing it to merge
20:32:38 <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
20:32:49 <tp> swdcom% git pull
20:32:49 <tp> Already up to date.
20:33:07 <tabemann> tp: have you installed bootstrap.fs?
20:33:16 <tp> why do git users always think that fossil users cant use a scm ?
20:33:21 <tp> yep
20:33:24 <tp> all the latest
20:33:26 <tabemann> hmm
20:33:30 <tp> recompiled the c file
20:33:48 <tabemann> I dunno, because it works for me, and I'm not even using the standard out-of-the-box code
20:34:24 <tp> how long after you ran sw2 did it respond ?
20:34:30 <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
20:34:35 <tabemann> instantaneously
20:34:47 <tabemann> oh question
20:35:09 <tp> maybe it's my M0
20:35:11 <tabemann> did you restart mecrisp-stellaris after you loaded bootstrap.fs?
20:35:33 <tabemann> the instruction used by bootstrap.fs is thumb-0
20:35:36 <tp> hmm, I really cant recall, gurss i better do it again!
20:35:38 <tabemann> *thumb-1
20:35:46 <tp> oh yeah I did
20:36:01 <tp> it comes up with the buffer address
20:36:11 <tabemann> you're using the old version
20:36:20 <tabemann> the new version doesn't display the buffer address
20:36:35 <tp> odd
20:36:52 <tp> ok, I'll do it again and advise, thanks for the tips!
20:39:08 <tp> tabemann, 
20:39:10 <tp> it does
20:39:13 <tp> : init ( -- )
20:39:13 <tp>         swd-init
20:39:14 <tp>         ." The swd buffer address is: " swd hex. cr
20:39:14 <tp>         72MHz swd-console ;
20:39:21 <tp> thats the init line
20:39:28 <tp> on the latest version
20:39:36 <tabemann> my bad
20:39:48 <tabemann> it's my version which doesn't display the address
20:39:55 <tp> ah
20:40:05 <tabemann> I didn't copy that from crest's code
20:40:18 <tabemann> I must've just figured I wouldn't need it
20:40:19 <tp> mine is slightly different as well but does use the original init stuff
20:40:27 <tp> true
20:40:36 <tp> but your terminal is still locked out ?
20:40:51 <tp> once swd-console runs ?
20:40:57 <tabemann> yes
20:48:29 <tp> i end up with swdcom % ./swd2 and nothing
20:48:38 <tp> and the serial terminal still works
20:49:21 <tp> mt swd programmer dualcolor led is wobulating tho
20:49:35 <tabemann> hmm
20:49:52 <tp> if I run sed2 with the buffer address it complains about the cpu type
20:49:55 <tp> swd2
20:49:59 <tabemann> I can switch back and forth between SWD and serial with swd-console and serial-console
20:50:09 <tp> 2020-06-12T10:37:03 WARN common.c: unknown chip id! 0xffff0040
20:50:19 <tp> I'm guessing it's something like that
20:50:27 <tabemann> probably
20:50:58 <tp> the actual chip ID is 0x0040 and valid
20:51:18 <tp> the chip id is only 16 bits
20:51:50 <tabemann> hmm
20:52:28 <tp> I use it in my f103-diagnostics
20:59:20 <tabemann> I see obviously 32-bit chip ids in other places, such as other people complaining about ST-Link not talking to their MCUs
20:59:44 <tp> really ?
21:00:24 <tp> the ID is a DBG thing and specified in the doc
21:00:58 <tp> I'm guessing stlink is screwing up
21:01:07 <tabemann> sounds like it
21:01:47 <tp> i tried to compile openocd under free solaris and it complained about heaps of stuff. Sometine Linux source is pretty bad
21:02:05 <tp> sometimes
21:02:24 <tabemann> the big thing is that linux programmers only test their code under linux
21:02:44 <tabemann> I too have written code that works just fine under linux but which breaks under freebsd
21:02:53 <tabemann> but it's a two-way street
21:03:04 <tabemann> I had to hack up swdcom to get it to run under linux
21:04:03 <tabemann> (in addition to having to hack up the stlink header files because they were broken due to the mis-maintenance of them by the debian people)
21:09:42 <nmz> freebsd doesn't even have seq
21:10:12 <nmz> they use jot instead
21:10:14 <nmz> so linux programmers should just rely on busybox for shellscripts, and well, apparently freebsd has that abi emulator
21:13:11 <tp> yeah
21:13:47 <tp> when I started with linux full time in 1996 I used to compile everything
21:29:13 <tabemann> back
21:33:52 <tp> i compiled hpux,solaris,ibm (whatever) and with the odd library change they mostly all compiled
21:34:26 <tp> yet nowadays Linux is so specialised it's hard to compile on another unix system
21:35:11 <tp> but Linux had the most mindshare by a long way, it rules the world now
21:35:14 <tp> has
21:41:05 <tabemann> okay, I just did my first pull request
21:41:20 <tabemann> some work will be needed more merging swd2.c and Makefile
21:41:41 <tabemann> because my files are written for Linux, while crest's files are written for FreeBSD
21:42:04 <tp> but swdcom hasnt been updated since we last spoke ?
21:42:30 <tabemann> I made updates locally on my machine, then forked and moved them into the fork
21:42:56 <tabemann> then submitted a pull request between crest's code and the code in my fork
21:43:10 <tp> yeah, the Linux version will need changes, I use FreeBSD and it doesnt work for me because of the chip id
21:43:18 <tp> ahh
21:43:19 <tp> nice
21:43:32 <tabemann> the Makefile needed changes as well for me
21:43:36 <tp> so youre the Linux version maintainer ?
21:43:42 <tabemann> basically yeah
21:43:50 <tabemann> my code also includes the zeptoforth support
21:43:54 <tp> cool, youre the perfect person
21:43:55 <tabemann> but that doesn't need merging
21:44:00 <tp> naturally :)
21:44:25 <tp> swdcom is a great idea, makes it all so much easier
21:44:35 <tp> a much more modern cortex-m Forth
22:00:26 <tp>  ./swd2 
22:00:27 <tp> 2020-06-12T14:58:18 WARN common.c: unknown chip id! 0xffff0040
22:00:27 <tp> Failed to open the debugger.
22:00:27 <tp> Abort (core dumped)
22:03:56 <tabemann> ugh
22:04:08 <tabemann> I do have to go to bed -got work tomorrow
22:04:10 <tp> ill try the latest stlink
22:04:17 <tp> nighto!
22:04:21 <tabemann> that's probably a good idea
22:04:31 <tabemann> g'night
22:14:25 --- join: gravicappa joined #forth
22:33:23 --- quit: _whitelogger (Remote host closed the connection)
22:36:24 --- join: _whitelogger joined #forth
22:55:22 --- quit: dys (Ping timeout: 256 seconds)
22:55:39 --- quit: WickedShell (Remote host closed the connection)
23:06:05 --- join: dys joined #forth
23:08:59 --- quit: dddddd (Remote host closed the connection)
23:24:28 --- join: mtsd joined #forth
23:59:59 --- log: ended forth/20.06.11