00:00:00 --- log: started forth/20.03.07
01:34:08 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in)
01:40:10 --- quit: dddddd (Ping timeout: 260 seconds)
02:03:44 --- quit: X-Scale (Ping timeout: 258 seconds)
02:06:20 --- join: X-Scale` joined #forth
02:06:47 --- nick: X-Scale` -> X-Scale
02:26:38 --- join: xek_ joined #forth
05:07:23 --- quit: xek_ (Ping timeout: 265 seconds)
06:01:57 --- quit: dave0 (Quit: dave's not here)
06:03:24 --- join: dddddd joined #forth
06:23:11 --- join: jfe joined #forth
06:48:37 --- quit: Keshl (Read error: Connection reset by peer)
06:48:40 --- join: Keshl_ joined #forth
07:05:10 --- join: tpbsd joined #forth
07:05:10 --- quit: tpbsd (Changing host)
07:05:10 --- join: tpbsd joined #forth
07:05:11 --- quit: tp (Read error: Connection reset by peer)
08:59:48 --- quit: jpsamaroo (Ping timeout: 240 seconds)
08:59:58 --- join: jpsamaroo joined #forth
10:00:49 --- join: xek_ joined #forth
10:21:06 --- join: TwoNotes joined #forth
10:25:04 --- quit: TwoNotes (Client Quit)
11:10:32 --- quit: jsoft (Ping timeout: 255 seconds)
11:15:32 <tabemann> hey tpbsd
11:51:56 --- quit: gravicappa (Ping timeout: 255 seconds)
12:27:27 --- join: MrMobius joined #forth
13:18:03 --- join: dave0 joined #forth
13:58:07 --- quit: dddddd (Remote host closed the connection)
14:10:05 --- quit: xek_ (Ping timeout: 260 seconds)
14:23:01 --- join: TwoNotes joined #forth
15:03:56 --- quit: MrMobius (Ping timeout: 268 seconds)
15:04:03 --- join: [1]MrMobius joined #forth
15:04:12 --- nick: [1]MrMobius -> MrMobius
15:19:25 --- quit: djinni (Quit: Leaving)
15:22:01 --- quit: jfe (Ping timeout: 240 seconds)
15:22:18 --- join: jfe joined #forth
15:23:40 --- quit: actuallybatman (Quit: Lost terminal)
15:23:49 --- join: jsoft joined #forth
15:27:33 --- quit: jfe (Ping timeout: 260 seconds)
15:30:41 --- join: djinni joined #forth
15:38:17 --- quit: djinni (Ping timeout: 255 seconds)
15:53:37 --- join: jfe joined #forth
15:56:46 --- join: djinni joined #forth
16:10:14 --- quit: jfe (Ping timeout: 255 seconds)
16:16:59 <tpbsd> hey tabemann 
16:17:59 --- quit: MrMobius (Quit:  HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...)
16:29:04 --- join: MrMobius joined #forth
16:45:52 --- quit: jedb (Read error: Connection reset by peer)
16:46:28 --- quit: X-Scale (Ping timeout: 240 seconds)
16:46:57 --- join: jedb joined #forth
16:47:05 --- join: X-Scale` joined #forth
16:47:39 --- nick: X-Scale` -> X-Scale
16:59:13 --- quit: MrMobius (Read error: Connection reset by peer)
17:09:51 --- join: iyzsong joined #forth
17:14:49 --- join: MrMobius joined #forth
17:36:56 <tabemann> hey tp
17:46:05 --- quit: MrMobius (Ping timeout: 255 seconds)
17:48:12 <tpbsd> hey tabemann 
17:48:25 <tpbsd> whats new ?
17:53:09 --- join: MrMobius joined #forth
18:04:01 <tabemann> working on CORNERSTONE
18:04:33 <tabemann> had a stupid bug where I was changing compilation to RAM compilation before executing DOES> in CORNERSTONE
18:04:57 <tpbsd> oops
18:05:04 <tpbsd> bugs-r-us
18:05:29 <tpbsd> I'm working on a bug atm also
18:06:32 <tpbsd> once thats fixed I can publish my new binary and article on using the STM32 'TSC' Touch Sense Controller
18:09:04 <tabemann> okay, CORNERSTONE now works
18:09:21 <tabemann> for some reason, for the sake of redundance, I have both MARKER and CORNERSTONE
18:10:07 <tpbsd> does marker name and set the cornerstone ?
18:10:36 <tpbsd> Mecrisp-Stellaris cornerstone takes a name as the marker
18:11:23 <tpbsd> regarding RTS
18:12:05 <tabemann> they're two different words doing two different things
18:12:10 <tpbsd> you can set it from a Forth Word if you don't want to do the assembly
18:12:14 <tpbsd> ah
18:12:19 <tabemann> a marker deletes itself when executed, a cornerstone does not
18:12:34 <tpbsd> nice
18:13:03 <tpbsd> my cornerstone deletes everything back to it when executed
18:14:00 <tpbsd> i just remembered you use the USB connection on the stm32l476
18:14:46 <tabemann> yes, I do
18:15:37 <tpbsd> so forget about hardware handshaking
18:16:14 --- quit: MrMobius (Ping timeout: 255 seconds)
18:16:24 <tpbsd> my Forth driver mentions 'backflow' which is supposed to provide some form of flow control
18:17:03 <tpbsd> it does need a millisecond or so line delay to have time to work
18:22:50 <tabemann> back
18:23:30 <tabemann> I just realized that I had to put creating a CORNERSTONE at the very end of a source file
18:23:47 <tabemann> because the way I had flash writes written, CORNERSTONE is slow
18:24:02 <tabemann> slow enough that the next character is sent before it's done
18:24:22 <tabemann> and because I'm using screen and not e4thcom...
18:24:51 <tpbsd> or RTS
18:25:24 <tabemann> yeah
18:25:50 <tabemann> I'm wonder if XON/XOFF would help
18:26:54 <tpbsd> thats even harder to implement, I tried it once
18:27:34 <tpbsd> but I have a note from Matthias on that
18:28:35 <tpbsd> The XON/XOFF mechanism is fine in theory, but often enough, there are buffers quite large in the USB-serial bridge, and the XON/XOFF characters reach the PC for effect when the small UART buffers in microcontroller have been already overflown far beyond their capacity. Try it, but I think the RTS/CTS handshake is the better choice for you. I prefer virtually timing-agnostic four way interlocked handshake like in GPIB (IEEE-488) bus, but I know no widely 
18:28:36 <tpbsd> spread interface that currently offers this scheme.
18:28:36 <tpbsd> XON and XOFF should be inserted into quit, I think (untested):
18:28:36 <tpbsd> : handshake-quit ( -- )
18:28:37 <tpbsd>   begin
18:28:39 <tpbsd>     xon
18:28:43 <tpbsd>     query
18:28:45 <tpbsd>     xoff
18:28:47 <tpbsd>     interpret
18:28:49 <tpbsd>     ."  ok." cr
18:28:51 <tpbsd>   again
18:28:53 <tpbsd> ;
18:28:55 <tpbsd> ' handshake-quit hook-quit ! quit
18:36:47 --- join: jfe joined #forth
18:50:32 --- join: boru` joined #forth
18:50:35 --- quit: boru (Disconnected by services)
18:50:37 --- nick: boru` -> boru
18:59:22 <tabemann> well I got e4thcom's ACK/NAK mode (with the noforth plugin) working
18:59:29 <tabemann> and it loaded much, much faster
19:00:08 <tpbsd> yeah, it's the easiest choice to impliment
19:00:36 <tpbsd> people who start with e4thcom have a smooth Forth ride
19:00:40 --- quit: dave0 (Quit: dave's not here)
19:01:08 --- quit: iyzsong (Ping timeout: 240 seconds)
19:01:19 <tpbsd> remember 'jsoft' ? he built a Cortex-M0 clock in record time as a first time Forther
19:01:31 <tpbsd> he used e4thcom from the start
19:01:39 <tabemann> I've seen that name around here
19:02:41 <tpbsd> he built a blingy clock that looks like a car tachometer and uses neopixels
19:03:10 <tpbsd> he did the whole thing including the pcb etc
19:04:14 <tabemann> wow
19:05:31 <tpbsd> in only a few weeks!
19:05:43 <tpbsd> simply amazing
19:05:59 <tabemann> even zeptoforth took like four or so months
19:06:01 <tpbsd> a few weeks of spare time
19:06:16 <tpbsd> afterwork for him
19:06:22 <tabemann> mind you zeptoforth was also written in spare time
19:06:49 <tpbsd> matthias took 2 years for Mecrisp (MSP430)
19:07:08 <tabemann> mecrisp seems more complete than zeptoforth
19:07:20 <tpbsd> definitely 
19:07:21 <tabemann> e.g. I have yet to write a multitasker for zeptoforth
19:08:06 <tpbsd> tons of words, fixed-point, multitask, assembler, dissasembler, interrupts etc
19:08:44 <tpbsd> heaps of example code
19:08:46 <tabemann> yeah, I have yet to write fixed-point, an assembler, or a disassembler, and my interrupt handling is rudimentary
19:09:18 <tpbsd> matthias is still stuck on a unified interrupt design for the GD32VF103 risc-v
19:09:20 <tabemann> note that many of these things for me will be optional modules the user can load
19:09:48 <tpbsd> he managed it with msp430, cortex-m and ICE, but risc-v is a problem
19:10:15 <tabemann> okay, time to put my daughter to bed
19:10:18 <tabemann> bbl
19:10:22 <tpbsd> cya!
19:19:15 --- join: iyzsong joined #forth
19:32:44 --- join: MrMobius joined #forth
19:58:41 --- quit: jfe (Remote host closed the connection)
19:58:57 --- join: jfe joined #forth
19:59:21 --- quit: MrMobius (Ping timeout: 258 seconds)
20:05:44 <TwoNotes> The GD32 has a pretty sophisticated interrupt system.  Why hide that?
20:06:15 --- join: iyzsong- joined #forth
20:06:59 --- quit: iyzsong (Read error: Connection reset by peer)
20:10:55 <tpbsd> TwoNotes, definitely not hiding it
20:11:08 <tpbsd> this is the existing Mecrisp-Stellaris interrupt
20:11:41 <tpbsd> : tsc-init ( -- )
20:11:42 <tpbsd>    ['] tsc-handler irq-tsc !	       \ tie handler to interrupt
20:11:42 <tpbsd>    TSC-INTERRUPT NVIC_ISER_SETENA bis!  \ enable TSC interrupt
20:11:42 <tpbsd>  ;
20:11:44 <tpbsd> example
20:12:02 <TwoNotes> Yes, a handler per peripheral is cleanest
20:12:46 <TwoNotes> Let the hardware figure out what to handle next
20:13:39 <tpbsd> the cortex-m interrupts have a default priority which I change if needed
20:13:45 <tpbsd> thats easy enough
20:14:03 <TwoNotes> Even the SiFive FE310 has vectored interrupts if you enable it
20:14:12 <tpbsd> I rarely hear accusations of 'hiding' with Forth :)
20:14:52 <TwoNotes> Oh, maybe I misinterpreted what you meant when you said matthias was 'stuck' on a unified interrupt design
20:15:17 <tpbsd> I think matthias is stuck trying to keep the gd32vf103 interrupts consistent with his existing strategy
20:15:50 <tpbsd> he has the same strategy for MSP430, Cortex-M for a few years now
20:15:53 <TwoNotes> Oh I see.   I have noticed that outside the core ISA, RISC-V implementations diverge widely
20:16:23 <TwoNotes> The SiFive designs and the GD32 are not much alike
20:16:33 <tpbsd> the gd32vf103 interrupts looked straightforward to me
20:16:50 <TwoNotes> I think they lifted a lot of it from cortext-m
20:17:09 <TwoNotes> SiFive is straightforward as well - just different
20:17:24 <tpbsd> but Ive only touched lightly on my GD32vf103 test setup, very early days for me
20:17:41 <TwoNotes> I've programmed for both.  They each have pros and cons
20:18:14 <tpbsd> matthias is in love with risc-v I think, and some things in mecrisp-quintus (for risc-v) are a big improvement
20:18:51 <TwoNotes> I actually have not used the other mecrisp flavors - just quintus.  Plus a lot of assembler on the SiFive
20:19:12 <tpbsd> TwoNotes, like anything I guess. No mcu is perfect, but I'm still amazed at the state of the tech, and I stated with the National PACE 16 bit cpu in 1975
20:19:48 <tpbsd> mecrisp flavours are almost identical, hardware permitting
20:19:55 <TwoNotes> I have you beat by 10 years, and a LOT changed even in those years
20:20:22 <tpbsd> wow, not much in IC MCU's around in 1965!
20:20:46 <TwoNotes> IBM 7094.  Filled a room. 32K words of 36 bits.
20:20:47 <tpbsd> they went to the Moon with a mcu made from discretes
20:21:03 <tpbsd> thats more a mainframe than a mcu :)
20:21:13 <TwoNotes> There were no MCUs then!  Thats the point
20:21:26 <tpbsd> there wasnt the room or power for a IBM 7094 on the lunar lander ;-)
20:21:31 <tpbsd> exactly
20:21:49 <TwoNotes> Closest thing to an MCU would be the DEC PDP-* I played with in college.  It was very much like the Apollo computer
20:21:58 <TwoNotes> PDP-8
20:22:25 <TwoNotes> Except the size of a modern microwave oven
20:22:32 <tpbsd> how I lusted after a PDP, but have never seen one in my life, and now of course, I'm no longer interested
20:22:51 <TwoNotes> Just as well.  4K of 12 bit words
20:22:59 <tpbsd> and wirewrap
20:23:03 <TwoNotes> yep
20:23:25 <tpbsd> you and I are now in the 'golden age' of microprocessors
20:23:38 <tpbsd> which is glorious
20:24:19 <tpbsd> I pretty much standardise on the STM32F0 as I have a big box of them in stock and I only do small projects
20:24:49 <tpbsd> I have a couple of Longan-Nano to play around with but I'm in no hurry as it's still a new tech
20:25:55 <TwoNotes> Chasing down doc the the Longan-Nano is frustrating.  All the dodgy translation s from Chinese
20:26:13 <TwoNotes> But thats a perfect environment for FORTH hacking
20:26:29 <tpbsd> yes, thats also one of the reasons my initial enthuisasm slowed right down
20:26:33 <tpbsd> it sure is
20:27:37 <tpbsd> they seemed to copy and paste much from the GD32F103 doc into the GD32VF103 doc and some parts Im familar with need a LOT of editing
20:28:35 <tpbsd> the GD32VF103 for instance claims to have the same 'peripheral wide register reset to defaults' as the GD32F103, but it doesnt
20:28:52 --- join: MrMobius joined #forth
20:29:19 <tpbsd> in fact code samples I have seen show GD resetting the peripheral registers to defaults on a register by register basis
20:30:37 <TwoNotes> I *may* try Rust in the future, but for now sticking with FORTH and Assembly.  The point is to learn the hardware
20:31:02 <TwoNotes> WOrking on a time-driven scheduler to replace PAUSE spinning
20:32:40 <tpbsd> within a multitasking design ?
20:33:10 <TwoNotes> yes
20:33:37 <tpbsd> sounds good
20:33:41 <TwoNotes> It replaced the 'MS' word which now spins doing PAUSE and watching a clock, with a sorted list of wakeup times for each task
20:34:00 <TwoNotes> Idea is to reduce power consumption when all tasks are waiting
20:34:14 <tpbsd> for risc-v ?
20:34:25 <TwoNotes> The single hardware timer interrupt is then set to the earliest time in the list
20:34:38 <tpbsd> aha
20:34:51 <TwoNotes> Actually it should work on anyhting.  The only difference is hooking in the hardware timer interrupt
20:35:07 <tpbsd> I've been thinking of related topics lately myself
20:35:18 <tpbsd> the systick timer ?
20:35:30 <TwoNotes> The GD32 can do rather extreme low-power stuff.  It seems a shame to waste it
20:35:40 <tpbsd> really ?
20:35:50 <tpbsd> like a MSP430 ?
20:35:52 <tpbsd> heheh
20:35:53 <TwoNotes> Each peripheral device has a separate power switch!
20:36:04 <TwoNotes> Oh, in the GD32 I mean
20:36:08 <tpbsd> a clock on/off you mean ?
20:36:55 <tpbsd> the coretex-m always turned any peripheral clock off to reduce power
20:37:24 <TwoNotes> It is in the PMU - power management unit.  You can enable the clock to each interface.
20:37:38 <TwoNotes> Without getting a clock signal, that device is dead
20:37:52 <TwoNotes> You can't even program its control registers
20:37:57 <tpbsd> but getting really low power in the cortex-ml0xx is a frustrating exercise
20:38:04 <TwoNotes> So stuff has to be turned on in proper sequence
20:38:11 <tpbsd> yeah, same as all the cortex-m's ?
20:38:25 <TwoNotes> I am pretty sure the GD32 stole a lot of those ideas
20:38:38 <TwoNotes> Some people are suprised ARM does not sue
20:39:09 <tpbsd> yeah, I think they stole a lot after practising on ther stm32f103 clone
20:39:25 <tpbsd> perhaps GD licensed the ARM cores ?
20:39:47 <tpbsd> but then they's probably be in breach of their contract with coppying
20:39:52 <TwoNotes> If they do not want to get in a Google/Oracle mess, they sure should have
20:40:33 <TwoNotes> But as neither ARM nor the GD32 maker are US companies, maybe they are more sane
20:41:14 <tpbsd> i have followed all this fairly closely, including making a Forth powered 'diagnostics' binary for owners of the 'bluepill' board to find out which counterfeit STM32F103 MCU their board actually contains
20:41:47 <tpbsd> no one really knows, and the Chines attitudes are very different to the West
20:42:35 <tpbsd> to them, I'm told by a Chinese engineer, part numbers belong to everyone, so STM32F103 means 'any STM32F103 like' chip
20:47:45 --- join: [1]MrMobius joined #forth
20:48:19 <tpbsd> but here in the West we call that kind of thing a crime and jail counterfeiters when we can find them
21:07:37 --- quit: TwoNotes (Quit: Leaving)
21:14:48 <tabemann> back
21:14:50 <tabemann> hey guys
21:15:03 <tpbsd> welcome back! 
21:16:57 <tabemann> opinion question
21:17:20 <tabemann> I always have here and , be with regard to RAM
21:17:40 <tabemann> and for flash one has to use flash-here and flash,
21:17:58 <tabemann> or if one wants whatever the current compilation mode is for, current-here and current,
21:18:12 <tabemann> but I'm wondering if I should change those
21:18:32 <tabemann> the only thing then is that they wouldn't be compatible with other operations, naming scheme-wise
21:19:14 <tabemann> e.g. ! always assumes RAM naturally, unless one wants flash, where then one uses flash!, or one wants either, where then one uses current!
21:19:42 <tpbsd> it's a dilemma
21:20:01 <tpbsd> i only know the Mecrisp-Stellaris strategy
21:21:44 <tabemann> my strategy is to allow the user to access both RAM and Flash this way, and to allow optional access either depending on compilation mode
21:27:38 <tpbsd> that does make it a bit more complex I think
21:28:11 <tpbsd> with your strategy can you save uninitialised data in flash ?
21:28:32 <tpbsd> with Mecrisp-Stellaris  uninitialised data has to go into a buffer
21:28:47 <tpbsd> initialised data goes into a array
21:29:23 <tpbsd> if you tru and create an array from within a program, it just wont work
21:32:38 --- join: gravicappa joined #forth
21:40:59 --- quit: [1]MrMobius (Ping timeout: 255 seconds)
21:51:24 --- quit: _whitelogger (Remote host closed the connection)
21:53:29 <tabemann> back
21:54:24 <tabemann> currently I have no way of saving data in flash other than hardcoding a variable into the runtime
21:54:27 --- join: _whitelogger joined #forth
21:55:24 <tabemann> but what I'm planning on doing is having a variable array that gets initialized on bootup
22:00:22 <tpbsd> a user tried the following
22:00:25 <tpbsd> : create_buffer
22:00:25 <tpbsd>    s" 200 buffer: RAM_BUF" evaluate
22:00:25 <tpbsd> ;
22:00:25 <tpbsd> compiletoram
22:00:25 <tpbsd>  
22:00:26 <tpbsd> And now runnig 'create_buffer' RAM_BUF will be added to dictionary at the beginning of RAM.
22:00:28 <tpbsd>  
22:00:30 <tpbsd> The only thing I still need to solve is how to make 'a_word_on_flash' see a new RAM_BUF.
22:00:32 <tpbsd>  
22:01:10 <tpbsd> but then RAM_BUF cant bee seen in the dictionary
22:01:17 <tabemann> I'm doing something different from it
22:01:24 <tpbsd> it's no good anyway
22:01:36 <tabemann> I'm creating words RAM-VARIABLE and RAM-BUFFER
22:02:07 <tabemann> and when these words are executed, they create words *LAST-RAM*
22:02:23 <tabemann> and execute the previous instance of *LAST-RAM*
22:02:50 <tpbsd> with Forth of course we can make whatever we want, so matthias tells me if he needs a area of flash for a special purpose he just excludes it from the dictionary and Mecrisp-Stellaris and then does special stuff to it
22:02:50 <tabemann> on bootup it looks for the last instance of *LAST-RAM*
22:06:11 <tpbsd> and you have to save them in flash ?
22:09:31 <tpbsd> I tried saving some data to flash so after a reboot I could tell if the word failed, but I think when the word failed a exception was raised and the flash didnt happen
22:09:35 <tabemann> with what I'm doing they don't need to be saved in flash
22:10:44 <tpbsd> but 'on bootup' ram is lost ?
22:15:48 <tabemann> yes
22:22:32 --- quit: gravicappa (Ping timeout: 256 seconds)
22:27:24 --- quit: _whitelogger (Remote host closed the connection)
22:30:28 --- join: _whitelogger joined #forth
22:35:33 <tabemann> there's one big disadvantage to the way I've implemented RAM variables
22:35:40 <tabemann> you have to reboot before you can use them
22:36:08 <tabemann> because they're allocated as an array/buffer from the bottom of RAM memory (well, after kernel variables)
22:42:16 --- quit: MrMobius (Ping timeout: 258 seconds)
22:58:23 <tabemann> okay, I'm gonna head to bed
22:58:26 <tabemann> g'night guys
23:01:56 --- join: dave0 joined #forth
23:54:24 --- quit: _whitelogger (Remote host closed the connection)
23:57:28 --- join: _whitelogger joined #forth
23:59:59 --- log: ended forth/20.03.07