14:53:59
##forth
<veltas>
crc: Any other plans for the UEFI port?
15:28:55
##forth
<cleobuline>
NEWS ! I installed photovoltaic panels on my roof
15:32:03
##forth
<ajhidd2>
\3
15:43:43
##forth
<cleobuline>
4,5 kw
15:44:23
##forth
<cleobuline>
actually producing 2,5 kw
15:44:28
##forth
<cleobuline>
cloudly
15:56:25
##forth
<crc>
veltas: yes, in the short term: adding in stack over/underflow & memory access bounds checks, additional ilo i/o devices for direct reads/writes to physical RAM & system i/o ports, improvements to the graphics support (adding color, faster drawing primitives)
16:03:29
##forth
<crc>
a bit longer term: support for aarch64 systems, saving/loading the konilo image from a disk partition, mouse support, possibly network support
16:03:53
##forth
<crc>
I'm going to have a dedicated machine running this soon
16:12:39
##forth
<KipIngram>
cleobuline: Where are you geographically?
16:50:19
##forth
<cleobuline>
installed yesterday
16:50:36
##forth
<cleobuline>
i'm happy of that
17:07:06
##forth
<KipIngram>
Cool. Not exactly the best solar spot in the world, but I do hope it goes well for you! I live around latitude 30 degrees, so it's a pretty favorable solar zone, but I have no panels on my home. A few of my neighbors do.
17:26:50
##forth
<veltas>
crc: awesome, I'm interested in anything that comes out of that
17:29:32
##forth
<veltas>
cleobuline: You're only a 10 hour drive from me
17:32:56
##forth
<veltas>
KipIngram: We can't all live in Cape Verde
17:47:43
##forth
<crc>
veltas: I'll provide updates as the work continues
18:06:19
##forth
<KipIngram>
veltas: True true - we all do the best we can.
18:06:44
##forth
<KipIngram>
Trust me, around August or so I often wish I lived 10-15 degrees further north. :-|
18:06:58
##forth
<KipIngram>
It gets god awful miserable around here that time of year.
18:07:14
##forth
<KipIngram>
You can almost look out the window and start sweating.
18:08:33
##forth
<KipIngram>
I used to watch that TV show, "Sex and the City." On an episode or two it would be summer there in New York City, and they all sat around acting like they were about to faint from heat stroke and envy the people who were able to "go up to the Hudson" for the hot weather. I'd just shake my head and think "You have no idea what you're even talking about."
18:10:52
##forth
<KipIngram>
Although part of it could be that some folks living up around New York have no air conditioning - you can think of it as optional in that part of the country. So then when the "hot" weather comes, you can't hide from it, and that could make it psychologically worse, I guess. Around here AC is simply not optional.
18:11:29
##forth
<KipIngram>
Especially since they don't build homes to take advantage of natural circulation anymore. They just build a box, often with many windows that won't open, and slap a machine on the ground next to it.
18:12:37
##forth
<KipIngram>
Back between my marriages I lived in Austin and had bought a homesite I intended to build my own place on, and I meant to try to honor those old ways of doing things. But then I met my current wife and she sort of turned my whole world upside down, and that path never materialized.
18:13:02
##forth
<tp_>
KipIngram, it's the same here in nsw, australia, it's 3am and the lowest the temperature has been since 9am yesterday is 25,2 C 77,4 F
18:13:05
##forth
<KipIngram>
Sold that lot and moved her to Houston.
18:13:44
##forth
<tp_>
our peak was aroung 36C yesterday
18:16:41
##forth
<veltas>
Yeah I don't envy people near equator, I am not built for it
18:16:48
##forth
<veltas>
I need cold weather to function
18:21:05
##forth
<tp_>
me too
18:21:39
##forth
<tp_>
especially as I get older
18:23:28
##forth
<tp_>
well, I've mostly finished my years long project that provides the same kind of hardware knowledge to Forth for embedded that C gets from header files
18:24:36
##forth
<tp_>
Im just rewriting the example project for it (digital thermometer) but everything else is finished now ince the doc, with flowcharts
18:25:49
##forth
<veltas>
Interested to read your doc when it's published
18:26:02
##forth
<tp_>
here is a sample of the syntax "COMP_CSR_COMP1EN enable! \ Comparator 1 enable"
18:26:29
##forth
<tp_>
veltas that should be in a couple of days
18:27:14
##forth
<tp_>
it doesnt modify the base Forth in any way (mecrisp-stellaris) or alter the project source in any way
18:28:03
##forth
<tp_>
and it uses 100% compliant CMSIS-SVD syntax
18:29:06
##forth
<veltas>
Is it pre-processing the Forth before it's transmitted?
18:29:24
##forth
<tp_>
veltas, exactly right!
18:30:52
##forth
<veltas>
The purist in me isn't too keen on all the tools used and the fact it sort of messes with the core interpreter/compiler concept; but also I can't really suggest a better alternative, this solves a real problem effectively
18:31:30
##forth
<veltas>
I'll read about it when it's published, it's definitely an important tool for the Mecrisp ecosystem
18:32:03
##forth
<tp_>
"COMP_CSR_COMP2EN enable! \ Select COMP2" becomes "$4001001C 16 enable!" before upload to the mcu
18:34:03
##forth
<tp_>
yeah, Mecrisp-Stellaris or any Forth with no knowledge of the hardware is usless with any cortex-m cpu
18:34:47
##forth
<veltas>
How easy is it to hook into the 'unrecognised symbol' routine in Mecrisp?
18:35:24
##forth
<tp_>
Im only a electronics tech and dont understand your question
18:35:34
##forth
<tp_>
Im not a real programmer
18:36:16
##forth
<tp_>
I understand Mecrisp-Stellaris well enough but Im not a Forth implimenter
18:36:29
##forth
<veltas>
What I mean is in Mecrisp's interpreter if it doesn't find a word in the dictionary, it will attempt to read it as a number, and then otherwise give up and print an error, riht?
18:36:38
##forth
<tp_>
yes
18:37:25
##forth
<tp_>
it would be impossible to add to Mecrisp-Stellaris itself as the image as is is 20KB in size and the mcu only has 64KB storage
18:37:41
##forth
<veltas>
I'm wondering if you can add your own code after failing to find it in the dictionary, that talks to the host (if connected) to search the CMSIS
18:37:58
##forth
<tp_>
hmm, good question
18:38:35
##forth
<tp_>
that would need modification of the terminal and some special control characters I guess ?
18:38:44
##forth
<veltas>
This would run slower because of the back-and-forth, but could prevent issues caused by pre-processing
18:39:00
##forth
<veltas>
If it is assumed the terminal is the only two-way connection then yeah
18:39:11
##forth
<veltas>
Which I'm guessing is the normal situation?
18:39:43
##forth
<tp_>
yes, and it's not a 'normal terminal' eother
18:40:15
##forth
<tp_>
this terminal talks to the mcu via SWD over the debug interface
18:40:45
##forth
<tp_>
and that provides a 512 chr ring buffer in sync with the PC
18:41:52
##forth
<tp_>
the bottom line being I can do 512 char prints and not affect running programs at all, unlike what happens with a usart 'terminal'
18:42:18
##forth
<veltas>
Very nice
18:42:30
##forth
<tp_>
the SWD terminal runs at 1 - 20 MHz
18:43:35
##forth
<tp_>
so it provides problem free debugging with up to 512 chr 'printfs'
18:44:59
##forth
<tp_>
lol, Im still trying to measure how long it actually takes to do a full 512 char print, but the 1ms Systick is no good as it always measures '0' so I have to write a accurate microsecond timer
18:45:23
##forth
<veltas>
Could you do 1000 512 char prints and measure that?
18:46:11
##forth
<tp_>
good idea! I hadnt considered that
18:47:11
##forth
<tp_>
I focussed only on the 512 char elapsed time
18:47:53
##forth
<tp_>
thanks! now I can try both and compare them to confirm the timer accuracy
18:48:27
##forth
<veltas>
I use something like that to check timers, clocks etc at work with low precision stopwatches etc
18:49:14
##forth
<tp_>
it's embarrasingly obvious now that you have suggested it
18:49:27
##forth
<veltas>
:P
18:49:33
##forth
<tp_>
I have a singular one-track mind
18:49:36
##forth
<KipIngram>
tp_: If you're on Linux there is a system call that gives microseconds as a pair of 64-bit results. I forget it it's actually a 128-bit microseconds quantity or seconds / microseconds. I think the latter.
18:49:55
##forth
<tp_>
KipIngram, yeah I'm on nixos
18:50:08
##forth
<KipIngram>
I've got code for it (nasm) if you're interested.
18:51:03
##forth
<tp_>
as the mcu has a xtal controlled clock I'd normally get it to do the time measurements
18:52:09
##forth
<tp_>
KipIngram, so thanks but I'll use the mcu for that part
18:53:40
##forth
<tp_>
the only think that has prevented me from doing that with a microsecond timer is finishing my 'furs' project as I've been putting 100% of my time into it
18:54:01
##forth
<tp_>
(furs = Forth Upload Replacement System)
18:55:06
##forth
<tp_>
oh and the awesome SWD terminal was designed by "crest_" who I see is on this channel atm
18:55:20
##forth
<crest_>
tp_: ?
18:55:29
##forth
<crest_>
(haven't read the backlog in a while)
18:55:36
##forth
<tp_>
hi crest!
18:56:35
##forth
<tp_>
swd2 is still working great, I use it with the python readline wrapper designed by 'wolfmanjm' thesedays
18:57:00
##forth
<tp_>
so now I have Mecrisp-Stellaris with command history etc
18:57:29
##forth
<crest_>
yeah i've nevver gotten around to implement my smart console for forth fully
18:57:44
##forth
<crest_>
i wanted to have a client that autostarts it server similar to tmux
18:58:00
##forth
<crest_>
(or screen for the gnu users)
18:58:26
##forth
<tp_>
crest_, well the python wrapper works fine, so I have all I need
18:58:29
##forth
<crest_>
that opens a single 8bit clean connection to the forth system via whatever method is specified
18:59:01
##forth
<crest_>
with the idea that the server also provides semi-hosting like access to the host pc
18:59:25
##forth
<crest_>
so that things like including files would work by having the forth system download the file from the host computer
18:59:49
##forth
<tp_>
crest_, my next project is a SWD connected mcu info screen, (after FURS is finished and released in the next few days)
19:00:39
##forth
<crest_>
as in an info screen for your host computer e.g. an e-ink or oled display for cpu temp, ram usage, network traffic?
19:00:40
##forth
<tp_>
crest_, oddly uploading files has never been a issue since you wrote swdcom
19:01:09
##forth
<crest_>
but i want(ed) smarted file uploading, stopping precisely on errors etc.
19:01:34
##forth
<crest_>
also i wanted to support other connection types e.g. can bus, spi, nrf24l01+, etc.
19:01:36
##forth
<tp_>
no, more for design, dynamic register and bitfield values displayed
19:02:17
##forth
<crest_>
yeah the other thing i wanted was a swdcom / segger rtt server that works while gdb is attached
19:02:32
##forth
<tp_>
Mecrisp-Stellaris does stop on errors tho :) it's not exact but that has never mattered to me as it's always obvious
19:02:49
##forth
<crest_>
but the openocd segger rtt implementation sucks (slow, incomplete, buggy)
19:03:11
##forth
<tp_>
is that your implementation ?
19:03:18
##forth
<crest_>
no
19:03:29
##forth
<crest_>
i never implemented the full rtt protocol
19:03:35
##forth
<crest_>
swdcom does its own thing
19:03:46
##forth
<tp_>
Im not supised as your designs work perfectly!
19:04:17
##forth
<tp_>
I'm suprised that the openocd implementation is so bad
19:04:19
##forth
<crest_>
e.g. i use reserved register that mecrisp stellaris doesn't use to auto-detect the buffer address instead of scanning the whole memory map (that you have to know^^) to guestimate where buffers are
19:04:34
##forth
<tp_>
yeah R11 or 12 ?
19:04:39
##forth
<crest_>
segger rtt is both a lot more complex (it supports multiple terminals)
19:04:44
##forth
<crest_>
iirc R11
19:05:05
##forth
<crest_>
because R12 has special meaning in the C ABI for far calls etc.
19:05:05
##forth
<tp_>
ahh, thats what i'd need to implement my mcu info screen
19:05:19
##forth
<crest_>
multiple streams?
19:05:26
##forth
<tp_>
I think so
19:05:37
##forth
<crest_>
how many and do they need to be interactive?
19:05:38
##forth
<tp_>
one for swdcom, one for the mcu info
19:05:51
##forth
<tp_>
no, they would be seperate
19:06:01
##forth
<crest_>
that's not really what i asked
19:06:39
##forth
<crest_>
what i meant is could you interleave the streams
19:06:52
##forth
<tp_>
my concept was that Id have a config for the bitfields I wanted to see, and that would update on a 1 second interval on a second screen as I worked on the code
19:06:59
##forth
<tp_>
ahh
19:07:23
##forth
<crest_>
you could implement new mecrisp forth console hooks on top of the swd2 terminal.s hooks
19:07:25
##forth
<tp_>
you shouldnt confuse me with a proper programmer :)
19:07:50
##forth
<crest_>
e.g. using ascii control chars like shift in/shift out to multiplex between two streams
19:08:21
##forth
<tp_>
thats handy to know
19:08:39
##forth
<tp_>
and would probably be fine]
19:09:20
##forth
<tp_>
I never need instant terminal access and as long as uploading still works properly ...
19:11:37
##forth
<crest_>
have you already decided on a chip to use?
19:11:52
##forth
<crest_>
will it be a cortex m3 or m4?
19:12:04
##forth
<tp_>
I always use M0
19:12:12
##forth
<crest_>
not even m0+?
19:12:19
##forth
<tp_>
I have a huge stock of stm32f051
19:12:49
##forth
<crest_>
still "stuck" on your old stock i see
19:13:18
##forth
<crest_>
does it implement the pendsv and syscall exceptions?
19:13:19
##forth
<tp_>
no, Id love to use the m0+ namely the STM32G030 and I do have 10 of those in 64KB flash
19:13:41
##forth
<tp_>
no, the F051 is pretty retarded in that area
19:13:54
##forth
<tp_>
it's even obsolete now
19:14:13
##forth
<tp_>
but it's still insanely useful
19:14:42
##forth
<crest_>
so you want a console and send draw commands without disrupting the console
19:14:46
##forth
<crest_>
correct?
19:15:27
##forth
<tp_>
the only thing I need is not to intefere with uploads (oncve started)
19:15:44
##forth
<crest_>
okay here is an idea
19:15:50
##forth
<crc>
updates done today: better hardware detection & reporting; bugs in input handling were fixed; auto select of default blocks partition based on label; support more than 10 disks/partitions (up to 36); clean restart of the Konilo image on stack overflow, underflow, memory boundary issues, and division by zero; added NOP instruction skipping in the ilo vm to aid in performance
19:15:53
##forth
<tp_>
the console access doesnt have to be instant as I rarely use it
19:16:07
##forth
<crest_>
implement the draw commands in your key hook.
19:16:45
##forth
<crest_>
if you read an ASCII shift-in byte you dispatch the bytes to your draw command buffer
19:17:26
##forth
<crest_>
if you see an ASCII shift-out byte you execute the draw command buffer
19:18:07
##forth
<crest_>
or the other way around^^
19:18:21
##forth
<tp_>
crest_, I assumed i'd need jtag/swd to access the bitfields via debug interface, same as gdb ?
19:18:39
##forth
<crest_>
you could to the same kind of trick with the output
19:19:13
##forth
<crest_>
and modify the console wrapping pyhton script to do what you want
19:19:34
##forth
<crest_>
beware if your update rate is too high swd2 will eat a lot of host cpu cycles
19:19:52
##forth
<tp_>
ahh yes, I recall
19:20:00
##forth
<crest_>
because i aggressively poll the swd ring buffers via the debug probe for a few ms after something changed
19:20:08
##forth
<tp_>
I do have plenty of host cpu to spare tho
19:20:53
##forth
<crest_>
swd2 is just (barely) good enough to be a really fast interactive console to the forth system
19:21:17
##forth
<tp_>
as in 20MHz ?
19:21:42
##forth
<crest_>
with an st-link v3 it tries 24MHz swd clock
19:22:00
##forth
<crest_>
and falls back to the max. an stlink v2 can do
19:22:02
##forth
<tp_>
oops I meant V3 for 20Mhz
19:22:24
##forth
<crest_>
iirc the v3 can clock the swd interface with 24MHz (not "just" 20MHz)
19:22:24
##forth
<tp_>
I see
19:22:33
##forth
<tp_>
ha
19:22:43
##forth
<crest_>
the older stlink v2 (and their plentyful clones) can do up to 4MHz
19:23:00
##forth
<crest_>
but they'll stretch the clock when they have to do any protocol processing
19:23:13
##forth
<crest_>
because they're mostly stm32f103 (clones)
19:23:18
##forth
<tp_>
thats been plenty fast enough for me so far. I havent even used the V3 units yet
19:23:35
##forth
<crest_>
i did because one of my disco boards has a builtin v3
19:23:57
##forth
<tp_>
the H7xx ?
19:23:57
##forth
<crest_>
it's crazy how fast an stm32h7xx runs with a 24MHz console
19:24:09
##forth
<tp_>
yeah, it would be
19:24:31
##forth
<crest_>
you don't even see any flickering text when running words with plenty of your svd2forth words loaded
19:24:44
##forth
<crest_>
it just jumps to the last screen page
19:25:09
##forth
<tp_>
it's even mind bending how fast swd2 is printing a 512 char 'printf' to the terminal
19:25:24
##forth
<crest_>
that's just ~1Mb/s
19:25:56
##forth
<crest_>
i wanted to implement other console hooks e.g. i2c, can bus, spi, etc.
19:26:04
##forth
<tp_>
yeah, but the screen upload is over before the screen finishes displaying I think
19:26:06
##forth
<crest_>
but so far i've mostly used swdcom and serial
19:26:45
##forth
<tp_>
yes, but serial over the swd debug
19:26:59
##forth
<crest_>
for compilation speed it helps that swdcom has a ring buffer between the debug probe and the console input hooks (key?, key)
19:27:20
##forth
<crest_>
so swd2 can upload bytes into the ring buffer while the forth system compiles
19:27:23
##forth
<tp_>
the second you start using a std peripheral wont that slow everything down ?
19:27:39
##forth
<crest_>
depending on the peripheral it can be even faster
19:27:57
##forth
<crest_>
i've pushed the stm32f103 high speed uart all the way to 4.5Mbaud
19:28:11
##forth
<tp_>
oh yeah, Ive just recalled how fast USB is on the 103!
19:28:30
##forth
<crest_>
i didn't write the f103 usb driver
19:28:43
##forth
<tp_>
it's actually seems as fast as swd2
19:28:58
##forth
<crest_>
with the right serial driver (double buffered DMA, line idle interrupt, etc.) the serial port can be as fast or faster than usb full speed in real life
19:29:09
##forth
<tp_>
I know. that driver has been worked on by a few people
19:29:41
##forth
<crest_>
i hacked together a fancy stm32f1xx serial driver that uses the DMA engine to keep the UART fed
19:29:50
##forth
<tp_>
that driver was initally written by mitch bradley for the OLPC project iirc
19:29:54
##forth
<crest_>
because STM32 UARTs aren't meant to be used interrupt driven
19:30:19
##forth
<crest_>
all but the low-speed ones that can wake up the chips from sleep lack FIFOs
19:30:46
##forth
<crest_>
you only have a single frame (aka byte) uart receive/transmit buffer
19:31:04
##forth
<tp_>
I wouldnet be constrained by the F103, that thing while still fast is pretty old
19:31:11
##forth
<crest_>
so either you have to poll them like crazy or accept stupid interrupt rates to use them without DMA at higher baud rates
19:31:28
##forth
<tp_>
why develop for the F103 ?
19:31:37
##forth
<crest_>
because at the time i didn't know better
19:31:49
##forth
<crest_>
i wanted a cheap chip i kinda knew that has can bus
19:32:11
##forth
<crest_>
but the can bus and usb share the same dual ported sram bank as buffer on the f103
19:32:20
##forth
<crest_>
so you can't use them at the same time
19:32:42
##forth
<tp_>
oh, or is it allSTM32 uarts ?
19:32:43
##forth
<crest_>
also i wanted to protect the host system from voltage spikes on the can bus
19:32:43
##forth
<tp_>
the only advantage I can see to the F103 is all the clones coming out of china, such as the APM32F103, available and cheap
19:33:01
##forth
<crest_>
so the idea was to get a good enough opto coupler for the uart rx/tx lines
19:33:14
##forth
<tp_>
but the STM32G030 is in 40nm node and pretty cheap now
19:33:32
##forth
<tp_>
ahh, I see
19:33:38
##forth
<crest_>
because that's a lot easier to isolate than usb or swd which happen to be half duplex (data goes both directions on the same pin)
19:34:04
##forth
<crest_>
sure you can buy fancy usb protection devices
19:34:06
##forth
<tp_>
and 40nm nodes arent as 'analog friendly' as 90nm
19:34:22
##forth
<crest_>
and there are debuggers that claim to have protected pins
19:34:47
##forth
<crest_>
but a random ~10MHz opto coupler from the parts bin is so much cheaper and easier
19:34:48
##forth
<tp_>
yeah a real issue on CAN bus I guess
19:35:13
##forth
<crest_>
especially when you it as a bus for a hackerspace
19:35:29
##forth
<crest_>
and let other idiots build their own devices to hook to the bus
19:35:30
##forth
<tp_>
you used CAN for controil inside a building, right, not automotive ?
19:35:53
##forth
<tp_>
hackerspace, yes I recall now
19:36:00
##forth
<crest_>
frigde door status, lights, etc.
19:36:06
##forth
<tp_>
no wonder you needed all that protection
19:36:20
##forth
<crest_>
and the host pc was the primary file server
19:36:31
##forth
<tp_>
it's only a matter of time before someone put mains onto that bus
19:37:05
##forth
<tp_>
Ive blown up 8 seperate PC's with mains on the ethernet, wasnt a good look
19:37:09
##forth
<crest_>
i didn't want some idiot frying the file server just because they couldn't be assed to unplug something before they short things with multimeter probes
19:37:21
##forth
<tp_>
it's even easier than that
19:37:38
##forth
<crest_>
you should've learned better the 7th time :-P
19:38:01
##forth
<tp_>
all it takes is making a mains extension lead and accidentally reversing the active and earth
19:38:17
##forth
<tp_>
I did them all at once
19:38:26
##forth
<crest_>
i assumed as much :-P
19:38:27
##forth
<tp_>
every pc in the building
19:39:02
##forth
<crest_>
just wanted to mess with you
19:39:03
##forth
<tp_>
it was a coax network at the time, (1994 ish)
19:39:51
##forth
<tp_>
dont torment us old people, we have had enough already ;)
19:40:29
##forth
<tp_>
the screams from the users was kinda interesting tho
19:40:53
##forth
<crest_>
i may be younger, but i still grew up with thin net and apple talk over phone lines before that
19:41:17
##forth
<tp_>
many said that it was like a 'angle grinder' at the back of their pc's as the coax connectors all melted
19:41:18
##forth
<crest_>
i've never used thick net in anger
19:41:50
##forth
<tp_>
was just RG502 or something like that
19:42:28
##forth
<tp_>
Ive installed university backbones on coax that was so large I had to drill a hole in it for the 'vampire connector'
19:42:55
##forth
<tp_>
ethernet has indeed come a very long way
20:24:06
##forth
<cleobuline>
forthBot: LOAD ini.fth
20:24:06
##forth
<forthBot>
File ini.fth with MOON loaded
20:24:15
##forth
<cleobuline>
forthBot: MOON
20:24:15
##forth
<forthBot>
Phase de la lune pour Wed October 22 2025
20:24:15
##forth
<forthBot>
🌒 Croissant montant Une jeune lune, un nouveau depart a Paris ! Illumination 1%
20:32:00
##forth
<lmt>
🥐
21:04:45
##forth
<tp_>
veltas, I asked a AI to compare my FURS efficiency to using the default 'base address + offset" method and it agreed that FURS is better for small embedded mcu's "Bottom line:
21:04:46
##forth
<tp_>
For the STM32F051 (64 kB flash) FURS **always** saves flash unless your application literally configures **every** register and bit-field in the entire peripheral set. Even then the break-even is ~14800 accesses, which is far beyond typical usage. Therefore FURS absolute-address mode is strongly recommended for this part."'s
22:24:15
##forth
<forthBot>
Environment for cleobuline inactive, freeing...
22:44:37
##forth
<cleobuline>
brave forthBot ...