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
<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