<rdrop-exit>
I actually dreamt about a Color Forth variant last night. I guess its a side effect of this prolonged quarantine.
<tp>
Ive had a Forth dream recently also
<rdrop-exit>
cool
<tp>
it was quite a silly dream
<tp>
I dreampt I was writing Forth code and became aware I was dreaming and remembered that i actually had to write some urgent code in real life, so I woke up to do it
<tp>
but when I woke up I realised that I didnt have any urgent Forth code to write
<rdrop-exit>
:))
<tp>
ripped off!
proteus-guy has quit [Remote host closed the connection]
<tabemann>
hey guys
<tp>
hey tabemann !
<tabemann>
I implemented SEE - now I'm going to test it
<tp>
awesome!
<tp>
it's one of my most used dev words
<tabemann>
and for my preliminary test, SEE ASSEMBLE-MAIN, it works
<tabemann>
I just pushed my code
<tabemann>
try it!
<tabemann>
note that I made significant changes to the kernel, so you'll need to recompile and upload it
<tp>
I always do
<tp>
just doing some testing on a project right now, will test yours asap
<tp>
I ran into a nasty bug with my blue pill diags, it fails to work properly flashing sections of flash with the latest release for some utterly unknown reason to me
<tp>
so I had to go back to the old kernel
<tabemann>
I discovered accidentally that flashing the wrong forth code onto the L4 board bricks it, at least to the point that ST-Flash is needed to recover
<rdrop-exit>
hi tabemann!
<tabemann>
hey
<tabemann>
whoops there's a bug in the disassembler - as I expected
<rdrop-exit>
step on it
<tp>
tabemann, it rendered the L4 board unbootable, it's impossible to brick them
<tabemann>
I know
<tp>
I remembered when I once disabled the SWD pins and it wouldnt flash .. I pressed reset as it was trying to flash and bingo, flashed :)
WilhelmVonWeiner has quit [Ping timeout: 272 seconds]
WickedShell has quit [Remote host closed the connection]
rdrop-exit has quit [Ping timeout: 256 seconds]
rdrop-exit has joined #forth
proteus-dude has quit [Ping timeout: 256 seconds]
jsoft has quit [Ping timeout: 258 seconds]
proteus-dude has joined #forth
deesix has joined #forth
dddddd_ has joined #forth
dddddd has quit [Ping timeout: 246 seconds]
dddddd__ has joined #forth
deesix_ has quit [Ping timeout: 246 seconds]
dddddd_ has quit [Ping timeout: 264 seconds]
deesix has quit [Ping timeout: 264 seconds]
proteus-guy has quit [Read error: Connection reset by peer]
proteus-dude has quit [Remote host closed the connection]
dddddd__ has quit [Ping timeout: 240 seconds]
deesix has joined #forth
dddddd__ has joined #forth
dddddd__ is now known as dddddd
iyzsong has joined #forth
mtsd has quit [Quit: Leaving]
rdrop-exit has quit [Quit: Lost terminal]
iyzsong- has joined #forth
iyzsong has quit [Ping timeout: 260 seconds]
iyzsong- has quit [Ping timeout: 240 seconds]
iyzsong has joined #forth
X-Scale` has joined #forth
X-Scale has quit [Ping timeout: 246 seconds]
X-Scale` is now known as X-Scale
<crest>
tp: i tried to enable RTS and CTS on the blue pill but it didn't work on usart1
<crest>
even after remapping can1 to other pins
<crest>
btw do your bitmap words using bis! really assume that all bitfields default to all zeroes?
<tp>
crest, the blue pill can be very frustrating to work with and although I think the need to simplify the GPIO config is overly complicated, I see the need for it
<crest>
it's really annoying it looks like the macos ftdi232 driver lacks hw flow control support
<tp>
crest, the 'reset:xxxxxxxx' is derived from the cmsis-svd
<crest>
on a freebsd system picocom displays the flow control as RTS/CTS
<tp>
so whatever it says in the bitfields is what you will get on a hardware reset
<crest>
on mac os it displays RTS/CTS (none)
<crest>
but there is no way to clear bits set by default
<tp>
?
<crest>
e.g. most gpio pins default to $4 in their CRL/CRH bitfield
<crest>
just setting more bits isn't the right thing to do
<crest>
you have to load the old register value, mask the bitfield, insert the new value and write it back
<tp>
GPIOB_CRL (read-write) Reset:0x44444444 ?
<tp>
like that ?
<crest>
yes
<tp>
thats controlled by the micro reset microcode etc
<tp>
no way you can change that
<tp>
except after reboot, then you can do what you like
<crest>
that's fine because it you want the reset logic to put the pins into a "harmless" state
<tp>
exactly, and all the MCU's do it
<tp>
looks like you have a explosion of problems ?
<crest>
but just setting more bits in the register to "1" isn't enough to configure the hardware
<tp>
(to misquote rdrop-exit)
<tp>
no, and I'm actually working on a way to fix this for the damn F103 for once and for all
<tp>
it's as codeless as it can get
<crest>
i just looked at your code and noticed that the code didn't insert bitfields
<tp>
afterall the best and most reliable code is code thats not there
<crest>
instead it just ORs the new bits into the memory mapped register
<tp>
please pastebin code snippets etc as Im always working on other stuff and cant immediately grok what you mean
<tp>
I'm about 100 IQ points short for that kind of caper I suspect
<tp>
crest, yes, usb terminal on the F103 is substantially faster than anything I can do in serial
<crest>
would it be possible to keep enough of the usb state to keep the device connected during a mcu reset?
<tp>
I've no idea, but you can do a mecrisp-stellaris "clear ram" instead of a mcu reset ?
<tp>
i use that method with my ihex binary generator
<crest>
at least it should be possible to write usbcomm tool that reconnects automatically
<crest>
*a usbcomm
<tp>
so that c file is your 'uploader' which is called by picocom ?
<crest>
yes
<crest>
i added ascii ack to quit
<tp>
thats a interesting take on the problem
<crest>
and ascii nak to Fehler_Quit(_n)
<tp>
as 'quit' is the outer interpreter ?
<crest>
yes
<crest>
i just added it after "ok."
<crest>
unless you transmit raw binary data there shouldn't be any data transparency problems with this
<tp>
thats one of the awesome features about forth, everyone has their own solution and thats real diversity!
<crest>
because those control sequences were put into ascii exactly for control purposes
<tp>
yes
<tp>
I transmit the dictionary contents as ihex to get around the binary transmission issue
<tp>
it works fine and the built in crc means I never get any errors
<crest>
would it be possible to use a pair of ring buffer accessed via swd as console?
<tp>
woo! thats a 'out there' question!
<crest>
the debugger would poll the write index of one ring buffer and consume from it
<crest>
and append to the other one
<crest>
it would keep as many pins free as possible
<tp>
and be super fast ?
<crest>
and you could use a stlink v2 clone around
<tp>
everyone has one except blue pill users ;-)
<crest>
even many blue pill users have stlink v2
<tp>
I mean every stm32 disco and nucleo board comes with one
<crest>
i just got mine today
<crest>
but haven't used it
<crest>
(yet)
<crest>
there would be a lot of overhead on the wire and the host cpu
<crest>
but who cares?
<tp>
yes, the cheap $2 blue pill is often sold with a cheap $2 stlink v2 clone taking the price to $4 ish
<crest>
the mcu is the bottleneck after all
<tp>
not me, pcs have plenty of grunt to spare
<crest>
what is so crazy about of this idea?
<tp>
those stlink v2 clones often come with clone stm32f103's
<crest>
its just a shared memory buffer with two single producer, single consumer ringbuffers
<tp>
I'm not qualified to judge, I have no experience there
<crest>
if the debugger could raise an interrupt it the mcu wouldn't even have to poll
<tp>
it sounds like a great idea tho
<tp>
but then youd have to build a terminal for it ?
<crest>
yes
<tp>
it would be revolutionary I think
<crest>
or use something like cuse4bsd to expose it as char dev
<tp>
as you say, simple to use, wastes no pins
<tp>
youll get about 4 users tho
<tp>
not that Id care, as I may be one of them
<crest>
you could even stop the cpu and traverse the dictionary to check if a word is already defined to implement #require
<tp>
but Mecrisp-Stellaris is used my many windows and Linux users
<crest>
expose the serial as telnet server on ::1/127.0.0.1
<tp>
(let them use cutecom and e4thcom ;-)
<crest>
cutecom?
<tp>
I have a telnet facility on the Tiva but was never able to use it the way I use screen
<tp>
cutecom is a serial terminal common among windows users
<tp>
I think
<tp>
theyre all pretty horrible
<crest>
oh shit the screenshot looks horrible
<tp>
yeh
<tp>
dont bother even looking at those things
<crest>
it wastes 1/4 of the screen with bloated ui elements
<tp>
theyre just horrible
<tp>
agreed
<tp>
I couldnt use Forth if I had to use it with that stuff
<crest>
running this swdcom as daemon would be nice
<crest>
it could bind a unix domain socket
<crest>
and a suitable client could just pass file descriptors to upload
<tp>
youre light years ahead of me in that area
<crest>
have you used urxvt(cd)
<tp>
it rings a bell
<tp>
a udp terminal ?
<crest>
urxvt is a pretty heavy x11 terminal with unicode support
<crest>
e.g. it can mix different fonts to display almost all unicode ranges with a good looking font
<crest>
because most good fonts for chinese or japanese look crap for other code points
<crest>
if you want to display japanese and code at the same time
<crest>
but it starts a bit slow because all this stuff
<crest>
because of this you can run it as daemon
<crest>
on first use (or in .xsession) it starts as daemon
<crest>
and all new windows just connect to this daemon reducing startup time
<crest>
you could do something similar with the swdcomm
<crest>
on first use it would scan all devices and start a daemon per detected device
<crest>
or at least per serial number
<crest>
you than connect to this daemon to upload files or attach to the console
<crest>
that should be possible if ARMs claims about the m3 debugging support hold water
<veltas>
I got around to writing my keyboard interrupt handler in forth on the ZX Spectrum, which profiling has indicated runs in around 10ms
<veltas>
Was quite cool watching it run and it does complete faster than the frame, with multiple loops and if statements running within its logic
<veltas>
Nice performance test
<veltas>
Totally inappropriate though, I'm going to rewrite this handler in assembly lol
<crest>
how much rum do you need for your zx forth?
<crest>
would it run on a zx81 with 16kb ram extension?
<veltas>
It's currently under 4KB, but not sure where it will land
<veltas>
3485 right now
<veltas>
I have an option to build it as a tokenized forth, which in the long run should allow it to remain very small so should be able to squeeze some form onto a 16K spectrum, not sure about ZX81 but probably similar enough so yes
<veltas>
I'm at the point where the tokenized version is about 30 bytes larger or something, I should break even soon. 128 tokens might be too much of a table overhead, might try with 64.
<veltas>
I know tp's eyes are glazing over
<veltas>
Currently it has separate headers, so programs produced using this forth environment should actually be able to shave off a big portion of the ram usage / image size if interpreting and word lookup is no longer needed in deployment
<crest>
tp: i just attached my stlink v2 (clone) and it detected the stm32f103
<crest>
but it stops the forth console (probably the whole m3 core)
<veltas>
1243 bytes form the headers for the current output, so 'decapitated' image as rdrop puts it would be 2242 bytes.
<veltas>
Anyway that's enough fun for today
<crest>
the freebsd stlink package includes a shared lib and c headers for it that is used to implement the st-util gdb server
<crest>
and it includes a write_mem8 and write_mem32 etc.
<crest>
if the 32bit writes are atomic it should be enough to implement a single writer, single reader ring buffer
<tp>
crest, I rarely use the terminal anyway, 95% of my interaction with the mcu is done from my editor
<crest>
which explains why upload speed is so important to you
<tp>
crest, your swd interface does sound very exciting, it would be a *new thing* for Mecrisp-Stellaris
<tp>
crest, yes, upload speed is everything
<crest>
my ack based flow control isn't?
<crest>
and an other advantage is that the receive buffer would be in the sram
<crest>
the debugger could write to the buffer while the compiler is busy
<crest>
making good use of the available write bandwidth
<tp>
your ack based flow control is very interesting, I'll definitely be thinking about that
<crest>
just a handful 1 byte changes
<crest>
i followed the color support code to guide me to all places that needed changing
<tp>
tabemann, also uses ack based flow control but I didnt really follow how it was implemented, you have filled in a lot of my ignorance there today
<crest>
even more important to me than the speed is reliable error reporting
<crest>
it aborts on the first compile error
<tp>
crest, the Mecrisp-Stellaris assembly is actually quite easy to follow, even the special german linguistics can be decoded ;-)
<tp>
yes, agree 100%
<tp>
when I first used Mecrisp-Stellaris it was slow and locked up with no errors
<crest>
even as a native speaker i'm confused my the german/english mixture
<tp>
and I wondered how anyone new to Forth would consider using it for more than 5 minutes
<crest>
good question
<crest>
and an important one if we want to grow the userbase
<tp>
i think that it's a easy question and the answer is ... "they would ditch it immediately"
<crest>
i suspect a module system would help
<tp>
it's usless as is, when compared to Gcc, openCM3 and gdb
<crest>
e.g. this is how you use gpio port, timer, usart etc.
<tp>
that C system wipes the floor with the basic Mecrisp-Stellaris and many forths
<crest>
what changes things for you?
<crest>
just your screen setup?
<tp>
basically yes
<tp>
I write code and click make
<tp>
same as using Gcc
<crest>
okay the st-* tools link against libusb to talk to the debugger
<tp>
the source is uploaded and runs on the target
<crest>
i like to play with the system on the console
<tp>
errors are easy to see and hear
<tp>
mine is a very fast and easy to use system
<crest>
but the danger is that your microcontroller grows true state
<crest>
e.g. each chip holds its unique state
djinni has quit [Quit: Leaving]
<crest>
that exists nowhere else
* tp
examines the mcu ... nope nothing growing on it
<crest>
:-)
<tp>
where does that danger lay ?
<tp>
is is contagious, will my other chips be infected ?
<crest>
you grow your forth system on the console without keeping the source code somewhere
<tp>
do they need to observee a 'chip distancing rule' ?
<crest>
in the end it kinda works but nobody know why or how
<crest>
and taking a hexdump isn't the same thing
<tp>
no, the source is saved in the editor and versioned as I go
<crest>
in your setup it is
<crest>
but if you just type at the console until it works
<tp>
the source is treated exactly the same here as it would be with a C system
<crest>
and version controlled?
<tp>
in fact I think many C users would feel a bit uneasy if they saw it
<tp>
yes, with fossil SCM
<crest>
good choice for personal projects
<crest>
everything in one sqlite db
<crest>
even tickets and a wiki
<crest>
and you can even keep unversioned blobs like releases or build artifacts in it and sync them between systems
<tp>
yeah, it is fabulous for me, even CRC uses fossil for RETRO, and if you ever look at that project, youll see it's so well organised it should be german!
<crest>
what annoys me is the lack of something like git add -p
<tp>
crest, for personal projects ??? fossil does everything GIT does and does it properly
<crest>
i often work on several parts of a file and want to add them one clean commit at a time
<crest>
instead of having to add all changes to a file in a single commit or undo them manually and add them manually in multiple stecks
<crest>
*steps
<tp>
hmm, I should append my above comment ... fossil does everything GIT does and does it properly for me :)
<crest>
its a small feature but it's important for my personal workflow
<crest>
the other problem is that few people know about fossil
<tp>
and thats all that matters
<tp>
and are you *sure* that fossil doesnt have that capability ?
<tp>
crest, I know that GIT is a million times more common than Fossil, but that metric doesnt mean much in this day and age
<crest>
it does for larger projects
<crest>
git lowers the barrier to entry
<crest>
and there is a lot of useful tooling around git
<tp>
crest, windows is also a million times more common than Linux on the desktop, but does that make it superior in any way otehr than marketing and retail channel ownership ?
<crest>
this more like comparing freebsd and linux as webserver
<crest>
sure i prefer freebsd
<tp>
crest, I bet 99% of git users use it for small projects as a downloader
<crest>
but those aren't important
<tp>
I bet most of them have no idea what a rebase is
<crest>
they just want a tarball or even worse something to pipe into sudo bash
<crest>
but the project cares about attracting talent
<tp>
actually I dont rebase as fossil doesnt have it, and doesnt need it
<tp>
hahaha
<crest>
e.g. fossil is good enough for most projects
<crest>
but it wouldn't be able to handle the freebsd base or ports repos
<crest>
the history is too large
<crest>
even git struggles with the freebsd repos (base, ports)
<tp>
sure
<crest>
it used to break github
<crest>
but git was improved to handle huge repos better because freebsd (and a few others) demonstrated that this is a real world usecase
<tp>
are you telling me that if I want to go fishing I should buy a aircraft carrier to cast my bait from ?
<crest>
there are bigger and older repos than the linux kernel
<tp>
shouldnt I use something suited for my needs ?
<crest>
for your personal project you should use whatever works for you
<crest>
but if you want to grow the project into a larger team effort
<tp>
well, Mecrisp-Stellaris isnt one of them and nor are 99% of all projects on github
<tp>
in fact Mecrisp-Stellaris uses no scm
<crest>
*sigh*
<tp>
matthias doesnt need one
<tp>
is the Linux kernel on github ?
<crest>
yes (official mirror)
<crest>
and for a while the official copy was on github because kernel.org had slight security problems
<tp>
well then, everyone writing a Forth blinky should immediately change to git on github for the 40 lines of source ?
<tp>
and I have a copy of the Linux kernel here
<tp>
it's no big deal
xek has joined #forth
<tp>
linus said 'why should I backup the kernel, there are thousands of copies on the net'
<crest>
sure but which ones can you trust?
<tp>
id trust your copy :)
xek__ has quit [Ping timeout: 260 seconds]
<crest>
i don't think i have a recent copy of the linux kernel repo