00:00:00 --- log: started forth/20.06.09
00:06:58 --- quit: guessgood (Quit: Connection closed)
00:21:36 --- quit: andrei-n (Ping timeout: 240 seconds)
00:22:17 --- join: andrei-n joined #forth
00:23:16 --- join: mtsd joined #forth
00:30:52 --- quit: andrei-n (Ping timeout: 256 seconds)
01:20:20 --- quit: reepca (Ping timeout: 246 seconds)
02:03:28 --- join: jedb_ joined #forth
02:06:04 --- quit: jedb (Ping timeout: 256 seconds)
02:11:25 --- join: TCZ joined #forth
02:13:18 --- join: scj joined #forth
02:13:26 --- quit: Zarutian_HTC (Ping timeout: 256 seconds)
02:16:46 --- quit: scj (Remote host closed the connection)
02:33:29 --- quit: jsoft (Ping timeout: 246 seconds)
02:39:35 --- quit: cantstanya (Remote host closed the connection)
02:41:56 --- join: cantstanya joined #forth
02:55:53 --- quit: TCZ (Quit: Leaving)
03:10:49 --- join: andrei-n joined #forth
03:22:10 --- quit: mtsd (Quit: Leaving)
03:32:56 --- join: Zarutian_HTC joined #forth
03:39:22 --- join: iyzsong joined #forth
03:58:31 --- quit: cantstanya (Remote host closed the connection)
04:01:30 --- join: cantstanya joined #forth
04:40:50 --- quit: jedb_ (Ping timeout: 256 seconds)
04:42:28 --- quit: APic (Ping timeout: 256 seconds)
04:44:47 --- join: APic joined #forth
04:51:58 --- join: dddddd joined #forth
05:08:20 --- join: jedb joined #forth
05:21:24 --- quit: Zarutian_HTC (Ping timeout: 260 seconds)
05:26:13 --- quit: crc_ (Quit: ZNC 1.7.4 - https://znc.in)
05:30:34 --- join: crc_ joined #forth
05:52:15 --- join: TCZ joined #forth
06:28:59 --- quit: TCZ (Quit: Leaving)
06:29:16 --- quit: andrei-n (Quit: Leaving)
07:14:43 --- quit: iyzsong (Quit: ZNC 1.8.0 - https://znc.in)
08:16:29 --- join: proteus-guy joined #forth
08:45:47 --- join: cmtptr_ joined #forth
08:47:46 --- quit: cmtptr (Ping timeout: 265 seconds)
09:18:26 --- quit: jedb (Ping timeout: 256 seconds)
09:19:22 --- join: WickedShell joined #forth
09:30:33 --- join: Zarutian_HTC joined #forth
09:55:50 --- quit: Zarutian_HTC (Ping timeout: 256 seconds)
10:41:30 --- quit: dys (Ping timeout: 256 seconds)
11:44:32 --- join: xek joined #forth
12:46:56 --- join: Zarutian_HTC joined #forth
12:52:30 --- nick: cmtptr_ -> cmtptr
13:14:17 --- quit: xek (Ping timeout: 260 seconds)
13:46:38 --- join: dave0 joined #forth
14:27:08 --- quit: gravicappa (Ping timeout: 246 seconds)
14:33:05 --- join: TCZ joined #forth
16:00:01 --- quit: TCZ (Quit: Leaving)
16:25:54 --- join: X-Scale` joined #forth
16:26:50 --- quit: X-Scale (Ping timeout: 246 seconds)
16:26:51 --- nick: X-Scale` -> X-Scale
16:28:13 <tp> crest, ping
16:29:01 <crest> pong
16:30:01 <crest> i cleaned up the code a little
16:30:05 <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 ?
16:30:26 <tp> Mecrisp-Stellaris has a few unused registers
16:30:41 <crest> but that would take the register away from the user
16:31:04 <crest> i had a different idea
16:31:10 <tp> doesnt matter, there are a few spares and most users dont touch them
16:31:16 <crest> ich stlink is supposed to have its own serial number
16:31:25 <crest> and i just wanted to cache the address per serial number
16:32:07 <tp> i think I understand how your swdcom works now :)
16:32:23 <crest> do you want to test your understanding?
16:32:37 <crest> look at the latest version on github
16:32:39 <tp> it's quite superficial, but sure
16:32:47 <tp> ok will do
16:32:50 <crest> i cleaned it up a little a few minutes ago
16:33:28 <tp> whats the git update command ?
16:33:51 <crest> git pull
16:33:51 <tp> (I dont use git, dont like it)
16:34:17 <crest> i agree that git has an annoying and at times dangerous interface
16:34:34 <tp> I've ben spoilt by fossil
16:34:51 <crest> if only fossil had something like git add -p
16:35:23 <crest> but the largest problem with fossil is mindshare
16:35:50 <tp> aha a Makefile
16:35:52 <crest> oh and i make heavy use of git annex to keep my media archive synced
16:36:12 <tp> I'm not trying to convert anyone
16:37:12 <tp> i just noticed that my disco board SWD interface 'dual color led' cycles when swdcom is connected, it looks funky
16:37:26 --- join: X-Scale` joined #forth
16:37:33 <tp> also happens when using swd to flash or with gdb etc
16:37:47 --- quit: X-Scale (Ping timeout: 264 seconds)
16:38:11 --- nick: X-Scale` -> X-Scale
16:38:15 <tp> agree fossil mindshare is minimal probably always will be, same as freebsd
16:39:17 <tp> if i wanted a OS with the greatest mindshare Id still be using windows or Linux 
16:40:00 <tp> so how do you fetch the $address in regard to a stlink serial number ?
16:40:34 <crest> you would have to set it once
16:40:41 <tp> before you can access the buffers you need to know the $address ?
16:40:52 <crest> your idea to put the base address into a register a good one
16:41:06 <crest> i just don't want to "steal" a precious register from the programmer
16:41:06 <tp> the problem with setting it is you need a serial connection to make it work
16:41:15 <tp> theyre NOT precious
16:41:19 <tp> this is Forth
16:41:41 <crest> i think i have a better idea
16:42:01 <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.
16:42:32 <crest> i'll fill the ring buffers with some magic pattern and scan for it on connect
16:42:33 <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)
16:42:33 <tp> r 9 	Unused, available for your special purposes. You may get a error/warning ‘Use low registers’
16:42:33 <tp> r 10 	Unused, available for your special purposes.
16:42:33 <tp> r 11 	Unused, available for your special purposes.
16:42:33 <tp> r 12 	Unused, but saved automatically on interrupt entry.
16:43:12 <tp> r8 - r12 are not generally available under Mecrisp-Stellaris on a cortex-mo anyway
16:43:31 <tp> being restricted under thumb1
16:44:18 <tp> and anyway, once the address is fetched, a user can use that register as it's not needed ?
16:44:52 <crest> correct
16:45:10 <crest> unless i wanted to allow users to relocate the buffer at runtime *shudder*
16:46:14 <crest> it looks like the covid19 backlog has been cleared. my stm32l476 boards should arrive in a few hours
16:46:27 <tp> awesome
16:46:40 <tp> it's a great board, modern flash
16:46:49 <tp> tabemann loves his unit
16:47:34 <tp> wow, i haven't looked at swd2.c before, you have put a lot of work into that!
16:49:21 <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
16:50:11 <tp> screen runs to conclusion but mt batch file needed sleep before using the logfile, it's a pain
16:50:45 <tp> so id set the sleep for the longest expected time and just wait if it's shorter ...
16:55:47 <crest> i just added proper signal handling for SIGINT and SIGTERM
16:57:38 <tp> i just loaded up your latest on my test board, works great!
16:58:00 <tp> it's fast!
17:01:03 <tp> what does that imply to a tech like me ?
17:01:17 <tp> I've heard the terms but dont know what they mean
17:07:59 --- join: jedb joined #forth
17:08:53 <crest> SIGINT and SIGTERM?
17:09:01 <tp> yes
17:09:05 <crest> that ctrl+c is safe now
17:09:09 <tp> ahh
17:09:12 <tp> thanks
17:09:25 <crest> in unix signals are like userspace interrupts
17:09:39 <tp> oh
17:09:49 <tp> what ctrl+d ?
17:09:55 <tp> what was
17:10:02 <crest> they allow the kernel signal the running thread async
17:10:42 <crest> ctrl+d is used to encode end of transmission
17:10:53 <tp> ah
17:11:27 <crest> ctrl+c causes the kernel to a signal to the process running in the foreground on the terminal you pressed it in
17:11:51 <crest> the default handler for SIGTERM just kills the process
17:12:34 <crest> pkill swd2 would do almost the same it would send SIGTERM instead of SIGINT
17:12:39 <crest> but both have the same default handler
17:12:49 <tp> swdcom is almost good enuf to replace my current setup, all it needs is a automated way to get the $address and some way to receive scripted output from the mcu
17:13:08 <tp> ah, that makes sense
17:13:27 <crest> would it be good enough to wait for some pattern in the output
17:13:35 <crest> and output everything before that pattern
17:13:36 <tp> sure
17:13:54 <tp> in fact thats the best way anyway
17:14:11 --- join: Zarutian_HTC| joined #forth
17:14:23 --- quit: Zarutian_HTC (Read error: Connection reset by peer)
17:14:35 <crest> i really want to implement proper file uploading without disconnecting the user from the forth system
17:15:20 <crest> and i don't know how much swdcom impacts the realtime properties of the system by stealing cycles from shared busses
17:15:22 <tp> in a way, that method is legacy
17:15:31 <crest> which method?
17:15:41 <tp> file uploading without disconnecting the user from the forth system
17:15:46 <crest> why?
17:16:13 <tp> a more modern way is to upload independently and feed errors into a editor
17:16:29 <crest> think about it like running tee on your output
17:16:40 <tp> because a Forth system doesnt need the terminal always connected
17:16:56 <tp> yes, I did that last night, works great
17:17:05 <crest> you can keep a scrollable interactive connection
17:17:12 <crest> and still upload from your editor
17:17:25 <crest> if i get it correct
17:17:55 <tp> I only use the terminal when experimenting, just a few lines here and there. Modern micros arent that easy to experiment with, they usually need a dozen lines uploaded and thats easier from a editor I find
17:18:27 <tp> in the old days they didnt have all the stuff a micro has now
17:19:03 <crest> i want to write some words, upload them try them out and move on
17:19:18 <crest> e.g. : blink ( pin speed -- ) ... ;
17:19:50 <tp> youll nedd more than that
17:20:51 <tp> I've written tons of embedded forth, I find it's easier from a editor, click make, the source is uploaded... why do it by hand in a terminal ?
17:21:01 <tp> is this some retro fetish ? ;-)
17:21:29 <crest> maybe because my vim setup isn't done yet?
17:22:40 <tp> in my case it's all done thru a make file, works with vim or any editor that has a make button
17:22:47 <tp> nothing special there
17:23:31 <tp> frankly I love forth, it's all I use, but I couldnt make anything the old Forth way, it's just far too sloe
17:23:34 <tp> slow
17:24:19 <tp> embedded tech has moved on and in some ways, Forth hasnt kept up
17:24:26 --- nick: Zarutian_HTC| -> Zarutian_HTC
17:24:37 <tp> mainly in the source upload area
17:26:23 <tp> I mean, Matthias and Robert Clausecker have just designed a edu board for teaching assembly and maybe forth, it's based on a MSP430 because cortex-m is too complex
17:27:45 <tp> and cortex-m is massively complex, you need special tools to deal with it, the old terminal is just not capable
17:28:01 --- quit: pareidolia_ (Quit: ZNC 1.7.3 - https://znc.in)
17:28:15 --- join: pareidolia joined #forth
17:28:37 <crest> you could use something like swdcom for a hosted forth on supported controllers
17:29:11 <tp> like I'm testing now ?
17:29:43 <crest> like running the compiler on the host instead of the target
17:30:04 <tp> oh I getya
17:30:49 <tp> matthias created mexrisp-across that uses a cortex-m4 as the host and crosscompiles for a MSP430, works incredibly well
17:31:20 <tp> he uses jtag from the host to the target
17:31:29 <tp> as Ti dont have swd
17:32:00 <tp> crest, a tehered Forth for cortex-m would be amazing
17:32:31 <tp> matthias wond do one because he doesnt like cortex-m
17:33:11 <crest> why did he write such a powerful forth system for them if he dislikes them?
17:33:35 <tp> he ported mecrisp over to mecrisp-stelaris
17:33:52 <tp> he wrote mecrisp on msp430 first
17:34:02 <crest> sure msp430 has a "nicer" instruction set for compiler writers
17:34:38 <tp> 'nicer' is a understatement :) it's as smooth as silk, thumb1 is like sandpaper
17:35:24 <crest> its a pdp11 that traded addressing modes for registers
17:35:39 <tp> for instance matthias wrote a fully contained, bootable, no side effect, no strange pin states, blinky for MSP430 in 14 bytes
17:36:04 <tp> the best he can do for cortex-m is 28 bytes
17:36:25 <crest> you can beat that on a CDP1802 that doesn't make it a well designed instruction set
17:36:39 <tp> i started with motorola 6800 assembly, so Im drawn to msp430 assy myself
17:37:18 <tp> I have a CDP1802 mcu here somewhere
17:37:34 <tp> I never used it, didnt like it
17:37:35 <crest> given that crazy CDP1802 instruction a multistack machine is about the most efficient code you can reasonably write for it
17:37:57 <crest> i have a soft spot for it because i taught myself assembler on it
17:38:03 <crest> (in an emulator)
17:38:52 <crest> i got bored enough in school write and assembler code on paper
17:38:57 <tp> funny how our first micro is our favorite
17:39:12 <crest> and could read the raw code the code in head
17:39:19 <tp> crest, do you have a actual original CDP1802 ?
17:39:37 <tp> matthias is like that with MSP430, he thinks in assembler
17:40:12 <crest> i got cdp1802 membership card for christmas two years ago
17:40:34 <crest> its the only working 1802 i ever owned
17:41:20 <crest> hooking "modern" chips to it is annoying with the multiplexed bus
17:42:30 <tp> amazing, the cosmac cpu is still available ?
17:42:43 <tp> it's 40 years old!
17:44:52 <crest> getting a working one isn't easy
17:46:24 <crest> i used to much solder in assembling mine so the stacked boards don't fit into the can "case" but it works
17:46:26 <crest> http://www.retrotechnology.com/memship/mem_revI_build_1.jpg
17:48:21 <crest> 32K ram, the cpu, 8 leds and a few switches
17:49:44 <tp> as a tech it doesnt do anything for me, Ive wired countless switches and pcbs, I guess for a software guy it's cool
17:50:02 <tp> it's the equivalent of me showing you some of my C code
17:50:11 <tp> youd be like "meh"
17:50:55 <tp> or probably 'yuk'
17:51:17 <tp> perhaps even 'thats disgusting'
17:59:40 <crest> :-)
18:02:38 <tp> as a retro thing, it's probably the best Ive seen, shame it's so compact tho
18:04:01 <tp> i much prefer this https://mecrisp-stellaris-folkdoc.sourceforge.io/chips.html?highlight=mcu#this-months-hot-mcu
18:04:13 <tp> $0.90 each
18:09:47 --- quit: Keshl (Quit: Konversation terminated!)
18:14:01 --- join: Keshl joined #forth
18:16:27 --- quit: Zarutian_HTC (Read error: Connection reset by peer)
18:16:27 --- join: Zarutian_HTC| joined #forth
18:18:07 <crest> its just a retro thing
18:18:35 <crest> its supposed to be as (un)usable as the original $80 kit decades ago
18:18:46 <crest> just with a little more memory
18:19:08 <tp> heh
18:20:13 <tp> my 0.90 stm32 has SRAM: 512 Kbytes and 16 Kbytes I/D cache
18:20:18 <tp> of ram
18:34:02 <tp> crest, compiling the latest
18:34:04 <tp> swdcom% make
18:34:05 <tp> cc -O2 -pipe -std=c99 -Weverything -I/usr/local/include -L/usr/local/lib -o swd2 swd2.c  -lstlink-shared
18:34:05 <tp> swd2.c:453:28: error: called object type 'struct timespec' is not a function or function pointer
18:34:05 <tp>                 struct timespec now = now();
18:37:52 <crest> fixed
18:38:09 --- quit: jedb (Ping timeout: 260 seconds)
18:38:10 <tp> cool
18:38:18 <crest> i introduced a name collsion between the function now and the variable now
18:38:21 <crest> i renamed the function
18:39:05 <tp> no problem, I dont understand most of it anyway
18:39:14 <tp> (technician)
18:39:37 <tp> working :)
18:40:25 <tp> ctrl+c = Closing ST-LINK/V2 handle.
18:41:30 <tp> i found a problem with one of my Forth apps last night thanks to swdcom
18:42:25 <crest> how?
18:43:08 <tp> I use 'calltrace.fs' to show me what exception has crashed my project and it printed the usual calltrace stuff after my program ran. But this time instead of needing to reset the board, it all kept working. The board had reset and swdcom didnt care
18:43:34 <tp> I dont know yet, but it doesnt show up with my screen system
18:44:08 <tp> it's a ihex dumper and I suspect that it's reading memory it shoudnt
18:44:36 <tp> i reverted to my old ihex dumper and it works fine with swdcom
18:44:49 <tp> so the problem is in my code somewhere
18:45:59 <tp> it's kinda cool to have a terminal not affected by the board reset, tho I can see it on the still connected serial terminal while swdcom is runing
18:47:11 <crest> on reset my init word atomically overwrites all ring buffer read and write positions with zeroes
18:47:33 <tp> yes
18:47:54 <tp> because I dont use your clock stuff Ive added :
18:48:14 <tp> : swdcom ( -- )
18:48:15 <crest> you should keep the 0 swd !
18:48:15 <tp>     0 swd !
18:48:15 <tp>     ." The swd buffer address is: " swd hex. cr
18:48:15 <tp>     swd-console
18:48:15 <tp>  ;
18:48:25 <tp> and i just call swdcom
18:48:29 <tp> from init
18:48:55 <crest> that should work
18:49:23 <tp> that way I just grab the same block of code (and watch out for a change of naming) and drop it into my project
18:49:30 <tp> yeah works fine as expected
18:49:59 --- join: jedb joined #forth
18:58:38 --- join: boru` joined #forth
18:58:41 --- quit: boru (Disconnected by services)
18:58:44 --- nick: boru` -> boru
19:04:41 --- quit: dddddd (Ping timeout: 246 seconds)
19:08:33 <tp> crest, if you add this ".equ debug, 1" to mecrisp-stellaris-stm32f103.s and recompile then .regs will show the mcu registers
19:10:36 <crest> is there an existing word to write to a register?
19:10:53 <crest> something like $1234567 0 reg!
19:11:22 <tp> no, only if the 'assembler-m0' is uploaded
19:11:39 <tp> but it's obvious from the assembly what happens
19:11:58 <tabemann> back
19:12:00 <tabemann> hey guys
19:12:30 <tp> hey tabemann, swdcom is coming along nicely thanks to crest, ctrl+c now exits properly
19:12:48 <crest> and requires a m0 instead of m3/m4
19:13:16 <tp> crest, no, the m3/m4 are backward compatible
19:13:49 <tp> crest or you can do inline machine code using output from your favorite m3/m4 assembler
19:14:21 <crest> loading a constant into a register about as easy as things get
19:14:29 <tp> exactly
19:14:40 <crest> or even better just move from the top of stack register
19:14:42 <tp> I suggest R11
19:14:48 <crest> makes sense
19:14:51 <tp> Mecrisp-Stellaris doesnt use it
19:14:51 <crest> not saved by hardware
19:15:45 <tp> crest and a register should be easy to read with swd ?
19:17:40 <crest> stlink_read_reg()
19:17:59 <tp> that easy ?
19:18:04 <tp> it cnt be that easy!
19:18:08 <crest> should be
19:18:11 <tp> cant
19:18:37 <tp> seems a easy way to find the buffer address ?
19:18:57 <tp> I'm ready and keen to test ;-)
19:19:08 <tabemann> back
19:20:07 <tp> tabemann, we are looking at using a register to convey the swdcom buffer address to the C program
19:20:16 <tp> or at least considering it
19:20:17 <tabemann> so I hear
19:21:07 <crest> it would be easy to add a way to wait for swdcom to connect as well
19:21:19 <tp> crest, wants to use spooky electron entanglement at a distance but all I could come up with was a unused register
19:21:33 <crest> just put a connected flag in the low bit of the register
19:22:17 <tp> crest or use another spare register ?
19:22:40 <crest> why?!?
19:22:47 <tp> only if easier
19:23:00 <crest> doesn't make a difference
19:23:00 <tabemann> a lower bit seems like a better idea, as it does not expend more register space
19:23:00 <tp> doesnt the buffer address use all 32 bits ?
19:23:07 <tabemann> why should it
19:23:21 <tabemann> if it's word-aligned, it doesn't use the bottom two bits
19:23:40 <crest> no it's always word aligned (multiple of 4)
19:23:43 <tabemann> and forcing the buffer to be word-aligned is easy
19:24:35 <tp> this is my bugger address
19:24:40 <tp> buffer!
19:24:43 <tp> $20001D58 bin. 
19:24:44 <tp> 3322222222221111111111
19:24:44 <tp> 10987654321098765432109876543210 
19:24:44 <tp> 00100000000000000001110101011000
19:24:56 <tp> so bits 0 and 1 are always unused ?
19:24:59 <tp> always 0 ?
19:25:16 <tabemann> yep
19:25:25 <tp> programmer magic!
19:25:25 <tabemann> that's the truth of any word-aligned address
19:25:38 <tp> I'm just a poor technician
19:26:13 <tp> so ok, one register does it all!
19:26:34 <tabemann> it's like how ARM determines whether code is Thumb or ARM - by exploiting an unused lower bit thanks to the fact that Thumb instructions are always halfword aligned and ARM instructions are always word aligned
19:26:45 <tp> and that would do away with the need for a serial port!
19:26:56 <tabemann> did you hear that Applie is switching to ARM for the Mac?
19:27:05 <tp> no I didnt
19:27:14 <tp> they fall out with intel ?
19:27:27 <tabemann> apparently they want thinner, lower power machines
19:27:45 <tp> sadly lower power means slower computers
19:27:49 <tabemann> and x86-64 is just too higher power for them
19:28:20 <tp> unless the new arm mac has 100 arm cpus and runs parallel software ?
19:28:36 <tabemann> well it's gonna have a lot of cores
19:28:43 <tabemann> both CPU cores and GPU cores
19:28:45 <tp> that makes sense
19:28:59 <tp> turn them on and off as needed
19:29:03 <tabemann> also Apple wants to design their own processor chips
19:29:08 <tp> hell, Id want one myself
19:29:10 <tabemann> rather than buy them from Intel
19:29:31 <tp> thats a good reason to use arm
19:29:33 <tabemann> i.e. what they're already doing with the iPhone and iPad
19:30:19 <tp> intel has to be really hurting thesedys
19:30:41 <tabemann> well macs are really only a smidgen of the market
19:30:46 <tp> they utterly screwed the embedded pooch, major fails
19:30:53 <tp> yeah
19:31:01 <tp> this I7 is pretty good
19:31:04 <tabemann> but the thing is that the future is ARM
19:31:14 <tp> seems to be
19:31:31 <crest> i want to use a simple xor-shift rng to fill both ring buffers from a known seed
19:31:57 <tp> cortex-m is a bit addictive, fast and capable and ornery enough to challenge a tech like me
19:32:29 <tp> crest, why ?
19:32:42 <crest> preserve the register for other uses
19:32:48 <tp> does it matter whats in the ring buffer at startup ?
19:32:59 <tabemann> oh you're going to search memory for pattern?
19:33:01 <crest> no because it is logically empty
19:33:02 <tp> but you dont know the address of the ring buffer ?
19:33:03 <crest> yes
19:33:16 <crest> and a xor-shift rng is very small
19:33:19 <crest> and fast
19:33:27 <tp> you have to search all of ram across different mcu's ?
19:33:47 <tabemann> the problem is you have to know where the RAM is
19:34:01 <tp> some have 8kb, others 1/2 MB of ram
19:34:10 <tabemann> and while these Cortex-M chips all have ram at $20000000
19:34:20 <tabemann> you don't know how much RAM there is
19:34:33 <tp> and if you search past the end wont you cause a exception ?
19:35:01 <tabemann> maybe because it's SWD you don't cause a processor exception but just an error on the SWD end
19:35:07 <tp> no one using Mecrisp-Stellaris is going to use R11
19:35:13 <tp> maybe
19:35:26 <tp> that would make much more sense
19:35:42 <tp> i guess crest will find out :)
19:35:58 <tp> ... no stone left unturned
19:36:29 <tp> plus crest will have a awesome dev board to work with shortly
19:36:41 <tp> the L476!
19:37:14 <tp> and then he can donate the blue pills to a homeless shelter ;-)
19:37:16 <tabemann> and you'll get to try out zeptoforth!
19:37:53 <tabemann> blue pills are like for people who would be arduino users but are too masochistic for that
19:38:08 <tp> hahahah
19:38:38 <tp> well .... arduino runs on the bluepill
19:38:45 <tp> most use arduino on it
19:38:46 <crest> https://gist.github.com/Crest/9b99a12c4cfdafcbe856e9de21e02161
19:38:50 <tabemann> I can understand using a chip like that if you've got some insane profit margin to meet
19:39:16 <tabemann> but if you're just hacking on chips for the hell of it, why not an L4 or even a G
19:39:54 <crest> tabemann: because lots of things run on a blue pill and copy & paste ready tutorials are easy to find?
19:40:13 <tp> tabemann, no, no manufacturer would *ever* use a stm32f103 in a new product (outside of china)
19:40:41 <tabemann> crest: that is true
19:41:06 <tp> tabemann, a manufacturer would get brand new STM's from STMicro for $0.010 each in volume
19:41:06 <crest> and they're cheap enough that you can oder 3 or 5 just try them
19:41:10 <tabemann> tp: the key words are "outside of china"
19:41:34 <tp> tabemann, yeah, but if you buy Chinese made gear youre going to suffer
19:41:40 <crest> tp, tabemann: https://gist.github.com/Crest/9b99a12c4cfdafcbe856e9de21e02161
19:41:48 <tp> tabemann, it's all a gigantic waste of money
19:43:38 <tp> crest so how long to searc 1/2MB or ram for deadbeef via swd ?
19:43:43 <tabemann> crest: let me know how that goes so I can include it into zeptofoorth
19:44:16 <tp> crest, I guess you havent read my bluepill rant ?
19:44:17 <crest> the more intersting question is how do find out the start of ram?
19:44:20 <crest> tp: i have
19:44:24 <tabemann> $20000000
19:44:28 <crest> always?
19:44:39 <tabemann> with STM32 it seems to always be that
19:44:46 <tp> people have wasted *days* with counterfeit mcus in bluepills
19:45:00 <tp> yes, always $20000000
19:45:01 <crest> is the ram size discoverable?
19:45:07 <tp> no
19:45:15 <tabemann> just trust me, it's always $20000000
19:45:19 <tp> there is a flash size register
19:45:28 <tp> but no ram size register
19:45:34 <crest> *sigh*
19:46:06 <tabemann> crest: can you detect accessing RAM outside the addressing space without crashing the board?
19:47:17 <tp> anyone remember 'tandy electronics' ? 35 years ago I used to have this contest with a friend, we would each buy the same electronics part from tandys, be it a led or a chip and have a race to see who found the defect first
19:47:29 <crest> tabemann: i have no idea
19:47:47 <crest> gn8
19:47:57 <tp> because *all* the parts tandys sold came from the manufacturer 'reject bin'
19:48:15 <tp> even if tandy forgot to mention it
19:48:33 <tp> afterall, hobbyists cant tell ....
19:48:49 <tabemann> nacht
19:49:02 <tp> crest will sonn find out tho :)
19:49:45 <tp> i dunno why there is no ram size register, it would be so handy
19:49:53 <tabemann> the blinkenlichten I have running on the F407 board are mesmerizing
19:51:03 <tp> tabemann, did you notice the 2color led on the SWD section goes all wobulating when swdcom is connected ?
19:51:11 <tabemann> yep
19:51:13 <tp> it's very cool
19:51:38 <tp> i think crest has invented a winner
19:52:31 <tp> with auto buffer adddress detection it saves pins and a usb-serial dongle plus terminal software, not to mention end of line delays etc
19:52:36 <tabemann> once connecting without having to read an address off the serial is working, I won't even need this serial dongle hooked up to my machine so it can talk to the F407
19:53:16 <tabemann> the only thing is I'd have to rework my build scripts
19:53:21 <tp> the only downside is 516 bytes of ram
19:53:46 <tp> which isnt a problem for me even with my puny F0
19:54:04 <tabemann> and for my L4 and F4 that isn't much at all
19:54:35 <tp> I tested swdcom uploading dissasembler-m0 last night .. fast as, no errors!
19:55:41 <tabemann> what might make sense is converting the swdcom functionality into assembly and integrating it into the kernel
19:56:00 <tp> i was thinking about that
19:56:09 <tp> and it's not hard
19:56:11 <tabemann> so there's no need to upload it via serial
19:56:23 <tp> there is no need to do that
19:56:34 <tp> one just uses a premade binary
19:56:36 <tp> :)
19:56:42 <tp> Ive made some already
19:56:50 <tabemann> but I mean so you can make the premade binary with it
19:56:53 <tp> but yeah, assembly is best
19:57:00 <tabemann> so you don't ever need to use serial
19:57:11 <tp> I've already made binaries with it
19:57:21 <tp> flash and go
19:57:46 <tabemann> the only problem with it, though, with zeptoforth, is that the standard forth code that goes along with it requires a number of reboots while being installed
19:57:51 <tp> but it does need init which isnt optimum
19:58:11 <tp> frankenforth ;-)
20:00:19 <tabemann> for building zeptoforth I'll probably just use serial though
20:01:21 <tp> tabemann, but you produce binaries now so thats no problem ?
20:01:30 <tabemann> yeah
20:01:36 <tp> a build system will always have special aspects
20:04:57 <tabemann> I might add a "warm boot" system, though, that'll avoid the complications of cold rebooting
20:14:35 <tabemann> yep, in the process of adding warm rebooting
20:16:47 <tabemann> yehaw! installation is so much smoother using warm reboots
20:16:55 <tabemann> so it's not halting each time it's cold rebooted
20:23:56 <tabemann> I didn't even expect that it'd be as smooth as it was
20:24:59 <tp> i have no idea id Mecrisp-Stellaris warm boots
20:26:28 <tabemann> what my warm boot is that I jump to the reset handler
20:26:31 <tabemann> nothing else
20:26:58 <tabemann> no hardware reset
20:27:27 <tabemann> note that a cold reboot is still needed in cases
20:27:36 <tabemann> e.g. erasing flash always invokes a cold reboot
20:28:10 <tabemann> and if one needs to change hardware configuration in an init word, a cold reboot is recommended
20:30:29 <tabemann> I found with codeload3.py reboots were often troublesome on the L4
20:30:38 <tabemann> during code loading
20:30:47 <tabemann> it should work better with warm rebooting
20:32:08 <tp> hopefully
20:55:00 <tabemann> okay, all seems well with the L4 build
20:55:10 <tabemann> the F4 build should go fine
20:55:35 <tabemann> as I've had more problems with the upload for the L4 build than the F4 build with the way the integrated USB-Serial works
20:55:47 <tp> then you can use swdcom ?
20:56:08 <tp> yeah, stlink2.1 ?
20:56:24 <tp> Id just reflash it to stlink2.0
20:56:43 <tp> or maybe reflash it to jlink
20:57:13 <tp> i hate stlink2.1 on my nucleo and plan tp replace it sometime
21:01:17 <tabemann> yeah, I'm using stlink 2.1, but I'm not using the whole "virtual drive" functionality a la micropython
21:01:47 <tp> yeah, but 2.1 is very slow compared to 2.o I find
21:02:02 <tabemann> I haven't noticed any speed problems
21:02:11 <tabemann> just garbage in the USB-Serial upon boot
21:02:45 <tp> I *think* that 2.1 uses a faster mcu than the stm32f103 tho so a backward flsh might not be possible
21:08:32 <tabemann> how do you flash the SWD programmer?
21:08:46 <tabemann> I'd've thought that'd've been completely hidden from the user
21:09:26 <tp> nah
21:10:00 <tp> it can be done with a windos utility or solder some wires and use swd
21:10:09 <tp> i use the latter
21:10:34 <tp> i upgraded my swd-1.0 boards to 2.0 that way
21:12:12 <tp> damn, matthias has altered 2.2.4 Mecrisp-Stellaris and it means I cant add a \r to the \n print outputs!!!
21:12:31 <tp> ill have to use a earlier version
21:16:24 <tabemann> agh
21:16:50 <tabemann> you could always use zeptoforth ;)
21:17:02 <tp> hehe, youve a long way to go yet
21:17:03 <tabemann> which use CRLF as the Lord intended
21:17:10 <tp> amen brother!
21:17:27 <tp> matthias is adamant he wont change it
21:17:55 <tp> but he makes it for him, not for me
21:19:39 <tabemann> on that note, though, the big things mecrisp-stellaris has that zeptoforth doesn't are register assignment and fixed point numbers
21:19:59 <tabemann> it has enough that 32-bit fixed point numbers could be implemented with it
21:20:02 <tp> and theyre bigies
21:20:18 <tabemann> I could just port 32-bit fixed point numbers from hashforth
21:20:19 <tp> it's very healily optimised
21:20:25 <tp> heavily
21:21:13 <tabemann> the machine code generator could be reduced in size, yes
21:21:18 <tp> i use Fixed Point (s31.32) a lot
21:21:53 <tp> I admit you have a lot of nice extras, and one can choose them
21:22:08 <tp> I do think Zeptoforth will grow into a nice Forth
21:22:22 <tp> of course I cant use it as Im a M0 iser
21:22:26 <tp> user
21:22:52 <tp> my 480 brand new stm32f051 cortex-m0's will be used!
21:23:00 <tabemann> lolol
21:23:19 <tp> theyre absolutely beautiful, sooo purty!
21:23:29 <tp> 5x5x1.2mm, theyre tiny
21:23:47 <tp> their 0.5mm pin spacing is easily soldered
21:23:51 <tabemann> the thing about s31.32 fixed point - how in heck do you implement it without supporting *128* bit numbers internally
21:23:59 <tp> they run up t0 98khz
21:24:09 <tabemann> with hashforth I supported them... by supporting 128 bit numbers under the hood
21:24:29 <tabemann> but hashforth targeted a 64-bit machine, while the M4 is 32-bit
21:24:37 <tp> i guess he uses 4 32 bit registers per number ?
21:24:52 <tp> i dunno man, Im just a user
21:25:08 <tp> ok the previous version accepted my changes :)
21:26:06 <tp> I did get matthias to accept my stm32f051 RTS addition as a compile time option tho, and he loved my color additions and made them mainline
21:26:30 <tabemann> cool
21:29:08 --- quit: crc_ (Quit: ZNC 1.7.4 - https://znc.in)
21:30:44 --- join: jackdani1l joined #forth
21:31:01 --- quit: jackdaniel (Ping timeout: 246 seconds)
21:31:43 --- join: crc_ joined #forth
21:32:16 <tp> i was surprised
21:32:58 <tp> youve added a beep to your error output which is awesome, now you need to color the error msg in red so it's easily found :)
21:33:22 <tp> it's hard to find a error in a ton of source
21:35:27 <tabemann> good idea
21:35:47 <tabemann> but I don't implement it today, because I should get to bed soon
21:36:05 <tabemann> *won't
21:36:16 <tp> hehe
21:36:20 <tp> no problemo 
21:36:33 <tabemann> I've already made a patch-level release 0.6.1 today
21:36:40 <tp> fortH without at least a error beep sucks
21:36:42 <tabemann> because one will want warm reboots
21:37:01 <tp> cool, ill try it after you ad color error 
21:37:18 <tabemann> and filtering input for control characters is always a plus
21:37:24 <tp> oh yeah
21:37:33 <tp> that will be fun to try
21:38:11 <tabemann> now it'll print garbage if you hit an arrow key, but it won't actually put the escape code in the buffer along with echoing it
21:38:20 <tabemann> so one can just backspace over the garbage
21:38:56 <tabemann> (another thing to do in the future is implement a proper line editor)
21:39:13 <tp> nice
21:39:24 <tp> new we just need readline ?
21:39:38 <tabemann> e4thcom will do at the present
21:39:57 <tabemann> and I probably won't implement readline - too expensive space-wise
21:40:14 <tabemann> just left and right errow and inserting text into the buffer
21:40:36 <tabemann> either no history or a very minimal history to save on RAM
21:40:45 <tp> aha
21:41:03 <tp> one advantage of swdcom I guess
21:41:09 <tp> it's all done at the pc ?
21:41:30 <tabemann> well, one advantage of e4thcom
21:41:56 <tp> dont say the #includes as thats sucky
21:42:01 <tabemann> anyways, I'm falling asleep, so g'night
21:42:08 <tp> nighto!
21:56:47 --- quit: Zarutian_HTC| (Read error: Connection reset by peer)
21:56:53 --- join: Zarutian_HTC joined #forth
22:04:55 --- join: gravicappa joined #forth
22:36:04 --- quit: WickedShell (Remote host closed the connection)
22:42:13 --- join: dys joined #forth
23:07:12 --- join: jsoft joined #forth
23:14:29 --- quit: dys (Ping timeout: 272 seconds)
23:22:06 --- join: dys joined #forth
23:39:09 --- quit: dys (Ping timeout: 260 seconds)
23:59:59 --- log: ended forth/20.06.09