jfe has quit [Ping timeout: 255 seconds]
<tpbsd> hey tabemann
MrMobius has quit [Quit: HydraIRC -> http://www.hydrairc.com <- It'll be on slashdot one day...]
MrMobius has joined #forth
jedb has quit [Read error: Connection reset by peer]
X-Scale has quit [Ping timeout: 240 seconds]
jedb has joined #forth
X-Scale` has joined #forth
X-Scale` is now known as X-Scale
MrMobius has quit [Read error: Connection reset by peer]
iyzsong has joined #forth
MrMobius has joined #forth
<tabemann> hey tp
MrMobius has quit [Ping timeout: 255 seconds]
<tpbsd> hey tabemann
<tpbsd> whats new ?
MrMobius has joined #forth
<tabemann> working on CORNERSTONE
<tabemann> had a stupid bug where I was changing compilation to RAM compilation before executing DOES> in CORNERSTONE
<tpbsd> oops
<tpbsd> bugs-r-us
<tpbsd> I'm working on a bug atm also
<tpbsd> once thats fixed I can publish my new binary and article on using the STM32 'TSC' Touch Sense Controller
<tabemann> okay, CORNERSTONE now works
<tabemann> for some reason, for the sake of redundance, I have both MARKER and CORNERSTONE
<tpbsd> does marker name and set the cornerstone ?
<tpbsd> Mecrisp-Stellaris cornerstone takes a name as the marker
<tpbsd> regarding RTS
<tabemann> they're two different words doing two different things
<tpbsd> you can set it from a Forth Word if you don't want to do the assembly
<tpbsd> ah
<tabemann> a marker deletes itself when executed, a cornerstone does not
<tpbsd> nice
<tpbsd> my cornerstone deletes everything back to it when executed
<tpbsd> i just remembered you use the USB connection on the stm32l476
<tabemann> yes, I do
<tpbsd> so forget about hardware handshaking
MrMobius has quit [Ping timeout: 255 seconds]
<tpbsd> my Forth driver mentions 'backflow' which is supposed to provide some form of flow control
<tpbsd> it does need a millisecond or so line delay to have time to work
<tabemann> back
<tabemann> I just realized that I had to put creating a CORNERSTONE at the very end of a source file
<tabemann> because the way I had flash writes written, CORNERSTONE is slow
<tabemann> slow enough that the next character is sent before it's done
<tabemann> and because I'm using screen and not e4thcom...
<tpbsd> or RTS
<tabemann> yeah
<tabemann> I'm wonder if XON/XOFF would help
<tpbsd> thats even harder to implement, I tried it once
<tpbsd> but I have a note from Matthias on that
<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
<tpbsd> spread interface that currently offers this scheme.
<tpbsd> XON and XOFF should be inserted into quit, I think (untested):
<tpbsd> : handshake-quit ( -- )
<tpbsd> begin
<tpbsd> xon
<tpbsd> query
<tpbsd> xoff
<tpbsd> interpret
<tpbsd> ." ok." cr
<tpbsd> again
<tpbsd> ;
<tpbsd> ' handshake-quit hook-quit ! quit
jfe has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<tabemann> well I got e4thcom's ACK/NAK mode (with the noforth plugin) working
<tabemann> and it loaded much, much faster
<tpbsd> yeah, it's the easiest choice to impliment
<tpbsd> people who start with e4thcom have a smooth Forth ride
dave0 has quit [Quit: dave's not here]
iyzsong has quit [Ping timeout: 240 seconds]
<tpbsd> remember 'jsoft' ? he built a Cortex-M0 clock in record time as a first time Forther
<tpbsd> he used e4thcom from the start
<tabemann> I've seen that name around here
<tpbsd> he built a blingy clock that looks like a car tachometer and uses neopixels
<tpbsd> he did the whole thing including the pcb etc
<tabemann> wow
<tpbsd> in only a few weeks!
<tpbsd> simply amazing
<tabemann> even zeptoforth took like four or so months
<tpbsd> a few weeks of spare time
<tpbsd> afterwork for him
<tabemann> mind you zeptoforth was also written in spare time
<tpbsd> matthias took 2 years for Mecrisp (MSP430)
<tabemann> mecrisp seems more complete than zeptoforth
<tpbsd> definitely
<tabemann> e.g. I have yet to write a multitasker for zeptoforth
<tpbsd> tons of words, fixed-point, multitask, assembler, dissasembler, interrupts etc
<tpbsd> heaps of example code
<tabemann> yeah, I have yet to write fixed-point, an assembler, or a disassembler, and my interrupt handling is rudimentary
<tpbsd> matthias is still stuck on a unified interrupt design for the GD32VF103 risc-v
<tabemann> note that many of these things for me will be optional modules the user can load
<tpbsd> he managed it with msp430, cortex-m and ICE, but risc-v is a problem
<tabemann> okay, time to put my daughter to bed
<tabemann> bbl
<tpbsd> cya!
iyzsong has joined #forth
MrMobius has joined #forth
jfe has quit [Remote host closed the connection]
jfe has joined #forth
MrMobius has quit [Ping timeout: 258 seconds]
<TwoNotes> The GD32 has a pretty sophisticated interrupt system. Why hide that?
iyzsong- has joined #forth
iyzsong has quit [Read error: Connection reset by peer]
<tpbsd> TwoNotes, definitely not hiding it
<tpbsd> this is the existing Mecrisp-Stellaris interrupt
<tpbsd> : tsc-init ( -- )
<tpbsd> ['] tsc-handler irq-tsc ! \ tie handler to interrupt
<tpbsd> TSC-INTERRUPT NVIC_ISER_SETENA bis! \ enable TSC interrupt
<tpbsd> ;
<tpbsd> example
<TwoNotes> Yes, a handler per peripheral is cleanest
<TwoNotes> Let the hardware figure out what to handle next
<tpbsd> the cortex-m interrupts have a default priority which I change if needed
<tpbsd> thats easy enough
<TwoNotes> Even the SiFive FE310 has vectored interrupts if you enable it
<tpbsd> I rarely hear accusations of 'hiding' with Forth :)
<TwoNotes> Oh, maybe I misinterpreted what you meant when you said matthias was 'stuck' on a unified interrupt design
<tpbsd> I think matthias is stuck trying to keep the gd32vf103 interrupts consistent with his existing strategy
<tpbsd> he has the same strategy for MSP430, Cortex-M for a few years now
<TwoNotes> Oh I see. I have noticed that outside the core ISA, RISC-V implementations diverge widely
<TwoNotes> The SiFive designs and the GD32 are not much alike
<tpbsd> the gd32vf103 interrupts looked straightforward to me
<TwoNotes> I think they lifted a lot of it from cortext-m
<TwoNotes> SiFive is straightforward as well - just different
<tpbsd> but Ive only touched lightly on my GD32vf103 test setup, very early days for me
<TwoNotes> I've programmed for both. They each have pros and cons
<tpbsd> matthias is in love with risc-v I think, and some things in mecrisp-quintus (for risc-v) are a big improvement
<TwoNotes> I actually have not used the other mecrisp flavors - just quintus. Plus a lot of assembler on the SiFive
<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
<tpbsd> mecrisp flavours are almost identical, hardware permitting
<TwoNotes> I have you beat by 10 years, and a LOT changed even in those years
<tpbsd> wow, not much in IC MCU's around in 1965!
<TwoNotes> IBM 7094. Filled a room. 32K words of 36 bits.
<tpbsd> they went to the Moon with a mcu made from discretes
<tpbsd> thats more a mainframe than a mcu :)
<TwoNotes> There were no MCUs then! Thats the point
<tpbsd> there wasnt the room or power for a IBM 7094 on the lunar lander ;-)
<tpbsd> exactly
<TwoNotes> Closest thing to an MCU would be the DEC PDP-* I played with in college. It was very much like the Apollo computer
<TwoNotes> PDP-8
<TwoNotes> Except the size of a modern microwave oven
<tpbsd> how I lusted after a PDP, but have never seen one in my life, and now of course, I'm no longer interested
<TwoNotes> Just as well. 4K of 12 bit words
<tpbsd> and wirewrap
<TwoNotes> yep
<tpbsd> you and I are now in the 'golden age' of microprocessors
<tpbsd> which is glorious
<tpbsd> I pretty much standardise on the STM32F0 as I have a big box of them in stock and I only do small projects
<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
<TwoNotes> Chasing down doc the the Longan-Nano is frustrating. All the dodgy translation s from Chinese
<TwoNotes> But thats a perfect environment for FORTH hacking
<tpbsd> yes, thats also one of the reasons my initial enthuisasm slowed right down
<tpbsd> it sure is
<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
<tpbsd> the GD32VF103 for instance claims to have the same 'peripheral wide register reset to defaults' as the GD32F103, but it doesnt
MrMobius has joined #forth
<tpbsd> in fact code samples I have seen show GD resetting the peripheral registers to defaults on a register by register basis
<TwoNotes> I *may* try Rust in the future, but for now sticking with FORTH and Assembly. The point is to learn the hardware
<TwoNotes> WOrking on a time-driven scheduler to replace PAUSE spinning
<tpbsd> within a multitasking design ?
<TwoNotes> yes
<tpbsd> sounds good
<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
<TwoNotes> Idea is to reduce power consumption when all tasks are waiting
<tpbsd> for risc-v ?
<TwoNotes> The single hardware timer interrupt is then set to the earliest time in the list
<tpbsd> aha
<TwoNotes> Actually it should work on anyhting. The only difference is hooking in the hardware timer interrupt
<tpbsd> I've been thinking of related topics lately myself
<tpbsd> the systick timer ?
<TwoNotes> The GD32 can do rather extreme low-power stuff. It seems a shame to waste it
<tpbsd> really ?
<tpbsd> like a MSP430 ?
<tpbsd> heheh
<TwoNotes> Each peripheral device has a separate power switch!
<TwoNotes> Oh, in the GD32 I mean
<tpbsd> a clock on/off you mean ?
<tpbsd> the coretex-m always turned any peripheral clock off to reduce power
<TwoNotes> It is in the PMU - power management unit. You can enable the clock to each interface.
<TwoNotes> Without getting a clock signal, that device is dead
<TwoNotes> You can't even program its control registers
<tpbsd> but getting really low power in the cortex-ml0xx is a frustrating exercise
<TwoNotes> So stuff has to be turned on in proper sequence
<tpbsd> yeah, same as all the cortex-m's ?
<TwoNotes> I am pretty sure the GD32 stole a lot of those ideas
<TwoNotes> Some people are suprised ARM does not sue
<tpbsd> yeah, I think they stole a lot after practising on ther stm32f103 clone
<tpbsd> perhaps GD licensed the ARM cores ?
<tpbsd> but then they's probably be in breach of their contract with coppying
<TwoNotes> If they do not want to get in a Google/Oracle mess, they sure should have
<TwoNotes> But as neither ARM nor the GD32 maker are US companies, maybe they are more sane
<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
<tpbsd> no one really knows, and the Chines attitudes are very different to the West
<tpbsd> to them, I'm told by a Chinese engineer, part numbers belong to everyone, so STM32F103 means 'any STM32F103 like' chip
[1]MrMobius has joined #forth
<tpbsd> but here in the West we call that kind of thing a crime and jail counterfeiters when we can find them
TwoNotes has quit [Quit: Leaving]
<tabemann> back
<tabemann> hey guys
<tpbsd> welcome back!
<tabemann> opinion question
<tabemann> I always have here and , be with regard to RAM
<tabemann> and for flash one has to use flash-here and flash,
<tabemann> or if one wants whatever the current compilation mode is for, current-here and current,
<tabemann> but I'm wondering if I should change those
<tabemann> the only thing then is that they wouldn't be compatible with other operations, naming scheme-wise
<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!
<tpbsd> it's a dilemma
<tpbsd> i only know the Mecrisp-Stellaris strategy
<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
<tpbsd> that does make it a bit more complex I think
<tpbsd> with your strategy can you save uninitialised data in flash ?
<tpbsd> with Mecrisp-Stellaris uninitialised data has to go into a buffer
<tpbsd> initialised data goes into a array
<tpbsd> if you tru and create an array from within a program, it just wont work
gravicappa has joined #forth
[1]MrMobius has quit [Ping timeout: 255 seconds]
_whitelogger has joined #forth
<tabemann> but what I'm planning on doing is having a variable array that gets initialized on bootup
<tpbsd> a user tried the following
<tpbsd> : create_buffer
<tpbsd> s" 200 buffer: RAM_BUF" evaluate
<tpbsd> ;
<tpbsd> compiletoram
<tpbsd>
<tpbsd> And now runnig 'create_buffer' RAM_BUF will be added to dictionary at the beginning of RAM.
<tpbsd>
<tpbsd> The only thing I still need to solve is how to make 'a_word_on_flash' see a new RAM_BUF.
<tpbsd>
<tpbsd> but then RAM_BUF cant bee seen in the dictionary
<tabemann> I'm doing something different from it
<tpbsd> it's no good anyway
<tabemann> I'm creating words RAM-VARIABLE and RAM-BUFFER
<tabemann> and when these words are executed, they create words *LAST-RAM*
<tabemann> and execute the previous instance of *LAST-RAM*
<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
<tabemann> on bootup it looks for the last instance of *LAST-RAM*
<tpbsd> and you have to save them in flash ?
<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
<tabemann> with what I'm doing they don't need to be saved in flash
<tpbsd> but 'on bootup' ram is lost ?
<tabemann> yes
gravicappa has quit [Ping timeout: 256 seconds]
_whitelogger has joined #forth
<tabemann> there's one big disadvantage to the way I've implemented RAM variables
<tabemann> you have to reboot before you can use them
<tabemann> because they're allocated as an array/buffer from the bottom of RAM memory (well, after kernel variables)
MrMobius has quit [Ping timeout: 258 seconds]
<tabemann> okay, I'm gonna head to bed
<tabemann> g'night guys
dave0 has joined #forth
_whitelogger has joined #forth
_whitelogger has joined #forth
xek_ has joined #forth
_whitelogger has joined #forth
dys has joined #forth
<tpbsd> whohoo I just answered a 1 yer old stackexchange tech question after becoming familiar with the subject in my latest Forth project, this could be my second right answer so far :P
<tpbsd> year
iyzsong- has quit [Quit: ZNC 1.7.1 - https://znc.in]
iyzsong has joined #forth
MrMobius has joined #forth
iyzsong has quit [Quit: ZNC 1.7.1 - https://znc.in]
jsoft has quit [Ping timeout: 256 seconds]
[1]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 256 seconds]
[1]MrMobius is now known as MrMobius
MrMobius has quit [Ping timeout: 265 seconds]
xek_ has quit [Ping timeout: 256 seconds]
MrMobius has joined #forth
dys has quit [Ping timeout: 255 seconds]
_whitelogger has joined #forth
gravicappa has joined #forth
dave0 has quit [Quit: dave's not here]
dddddd has joined #forth
[1]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 256 seconds]
[1]MrMobius is now known as MrMobius
[1]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 258 seconds]
[1]MrMobius is now known as MrMobius
jfe has quit [Ping timeout: 258 seconds]
tabemann has quit [Ping timeout: 240 seconds]
[1]MrMobius has joined #forth
jfe has joined #forth
xek_ has joined #forth
[2]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 256 seconds]
MrMobius has joined #forth
[2]MrMobius has quit [Ping timeout: 258 seconds]
MrMobius has quit [Ping timeout: 240 seconds]
[2]MrMobius has joined #forth
[2]MrMobius has quit [Quit: HydraIRC -> http://www.hydrairc.com <- In tests, 0x09 out of 0x0A l33t h4x0rz prefer it :)]
MrMobius has joined #forth
tabemann has joined #forth
<tabemann> I'm fucking pissed off
<tabemann> AT&T seems to be blocking port 6667
<tabemann> so I can't use my home-made IRC client, Amphibian, here
<MrMobius> are they blocking it for religious reasons?
<tabemann> nah, probably for "security reasons"
<tabemann> as IRC over port 6667 is typically not encrypted
jfe has quit [Ping timeout: 265 seconds]
<Kumool> ha!
<Kumool> cant you do tunneling or w\e
jfe has joined #forth
jfe has quit [Ping timeout: 255 seconds]
jfe has joined #forth
[1]MrMobius has quit [Quit: HydraIRC -> http://www.hydrairc.com <- s0 d4Mn l33t |t'z 5c4rY!]
Lord_Nightmare has quit [Quit: ZNC - http://znc.in]
Lord_Nightmare has joined #forth
[1]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 240 seconds]
[1]MrMobius is now known as MrMobius
tabemann has quit [Ping timeout: 258 seconds]
jfe has quit [Ping timeout: 268 seconds]
xek_ has quit [Ping timeout: 255 seconds]
gravicappa has quit [Ping timeout: 258 seconds]
jackdangers has joined #forth
jackdangers has left #forth [#forth]
tp___ has joined #forth
tp___ has quit [Changing host]
tp___ has joined #forth
tpbsd has quit [Read error: Connection reset by peer]
MrMobius has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Like it? Visit #hydrairc on Freenode]
MrMobius has joined #forth
tabemann has joined #forth
MrMobius has quit [Ping timeout: 265 seconds]
MrMobius has joined #forth
tp___ is now known as tp
[1]MrMobius has joined #forth
[2]MrMobius has joined #forth
MrMobius has quit [Ping timeout: 265 seconds]