2026-02-27 11:36:04 Okay, slow go here. As far as I can tell from the technical reference, the ESP32-C6 "boots" with more or less none of the protection mechanisms engaged. But it looks like the Linux tool chain is thoroughly deploying them before it hands control off to your flashed code. I'm slowly picking away at how to poke at the registers to take down all of the barriers it's erected between me and running 2026-02-27 11:36:06 code from data RAM, writing to code space, etc. I have no sense at this point of how far I still have to go, but so far it has not refused to let me write to any of the registers controlling all this stuff, so I assume I will eventually get there. 2026-02-27 11:38:24 The way the address space is documented is somewhat obtuse. The information is all there, but it's spread out in a bunch of places that makes for slow going. Each distince set of registers comes with a table that gives you the register addresses within a region - the base addresses of those regions are documented in other places. So you have to scramble around and put it all together to figure 2026-02-27 11:38:25 out where your registers "really are." 2026-02-27 11:38:41 And there are a LOT of registers. 2026-02-27 11:39:23 I spent hours and hours on it yesterday - probably will need a break for other things today. 2026-02-27 11:39:46 KipIngram, your'e into it now! 2026-02-27 11:39:58 Yeah, right down in the mud. 2026-02-27 11:41:04 KipIngram, I encountered the same issue when I started with ARM Cortex-M0, 413 registers and it's the simplest of the lot 2026-02-27 11:41:28 within the 413 registers are 3300 bitfields 2026-02-27 11:41:39 Yeah - crazy. It's just the pathology the world has these days, though - this obsession with being able to "lock everything down." 2026-02-27 11:41:49 and these all control the 37 on board peripherals 2026-02-27 11:41:57 I'm very much just a "give me control" sort of guy in situations like this. 2026-02-27 11:42:07 Let me do what I want - if I shoot myself, that's my problem. 2026-02-27 11:42:25 once you fit it all in your head, I'm sure youll appreciate it 2026-02-27 11:43:03 I now know all the above intimately, Ive had 11 years to learn it 2026-02-27 11:43:05 Oh, I don't mind all this stuff being there. But in a development environment I think it should be more "opt in" rather than set up to box you in right from the outset. 2026-02-27 11:43:53 I figure, though, that what led to it was the tool chain guys thinking, "Well, let's make it as much like the situation one would encounter in a Linux environment as possible." 2026-02-27 11:44:29 well, the Cortex-m0 runs at boot with factory defaults, one really doesnt have to do anything, but it takes a while to understand that 2026-02-27 11:44:42 eww 2026-02-27 11:45:13 But, it WILL let me poke these registers, and I've poked some that do things you wouldn't be letting a Linux user do. For instance, I can change the base and limit addresses of the protection regions. 2026-02-27 11:45:38 If I change them the wrong way, the chip crashes because suddenly the code can't get to resources it needs anymore. 2026-02-27 11:45:44 I ran the Cortex-M0 from asm, with a home made linker and a simple blinky, nothing but the flash over SWD program 2026-02-27 11:46:39 thats how I started. I did take a look at the standard STM OSS development and reeled in horror at it's complexity and have never used it 2026-02-27 11:47:27 I think that the default factory software is poison for people like you and I 2026-02-27 11:48:12 in fact the default factory STM blinky demo (written in C) wouldnt even work for me back in 2014 2026-02-27 11:48:19 and I had no idea why 2026-02-27 11:48:38 I was hoping just changing those ranges would be all I needed to do, and that may actually still turn out to be true, if I change them the RIGHT way. The tech ref is pretty good - it's got all of those details like addresses and stuff. But it doesn't really quite do the whole job in explaining the "philosophy" behind it all, so I'm kind of just wandering in the dark to some extent here. 2026-02-27 11:49:05 KipIngram, can you locate articles that talk about assembly blinkies on that chip ? 2026-02-27 11:49:22 Right - everything is just SO wildly complicated. It's like they live to make things more complex instead of simpler. 2026-02-27 11:49:58 but I've felt that way for a long time about a lot of things. There was a time in the past when I could actually engage with how Linux tools were built (make, Makefile, etc. - all that made perfect sense). 2026-02-27 11:50:22 But they just could not stop piling more layers on, and these days it's Greek to me. If something won't just build out of the box, I rarely know how to fix it anymore. 2026-02-27 11:50:40 I think what they've done is to build all this for DEVELOPER convenience instead of USER convenience. 2026-02-27 11:51:13 It seems counterproductive to me if you want your OS to be really accepted on a broad front. 2026-02-27 11:51:32 You want as many people as possible to say "Oh, that makes perfect sense - I can deal with this." 2026-02-27 11:51:52 But for a lot of it today you really do have to be an expert to cope with it all. 2026-02-27 11:52:52 I had made commercial projects on the PIC16C74 (but in 1999) before I moved to STM32F051 back in 2014 2026-02-27 11:53:46 and the PIC16C74 has only one timer and 1KB of on board flash iirc, so it was a massive jump for me 2026-02-27 11:54:06 I did just a tiny bit of work with PICs back in the day. So little that I really don't remember it. I remember back in 2007 or so I wrote a Forth assembler for a chunk of the PIC instruction set, though. Mostly just for fun. 2026-02-27 11:54:27 as the STM32F051 has 64KB flash and 8KB ram and those 37 peripherals 2026-02-27 11:54:51 My interests have usually been a bit higher up the capability curve than those very cheapest PICs. 2026-02-27 11:55:00 I only ever used a small C compiler on it for my devices, was easy and reliable 2026-02-27 11:55:21 Usually defined by "enough resources to actually host a Forth." 2026-02-27 11:55:23 yeah, I get that. Mine are always at the simple end of devices 2026-02-27 11:56:23 as soon as I started to get a clue about the STM32F051 (now obsolete) I discovered Mecrisp-Stellaris Forth and have been using that ever since 2026-02-27 11:57:19 but wether it's assembly or Forth on modern embedded, youre going to need a way to translate all those peripheral bit fields to addresses 2026-02-27 11:58:25 I had nothing and spent a decade designing FURS, which has been finished for about a month (at last). I'm still the only person I know of that uses it tho 2026-02-27 11:58:53 but thats typical for Forthers, we each do it our own way 2026-02-27 11:59:31 C users get a header file with that information from the maker of their particular C 2026-02-27 12:00:07 every other language has to make their own system, that goes for python, Rust, Lisp 2026-02-27 12:00:38 they all need the addresses for the registers ready made and usable 2026-02-27 12:00:59 preferably shareable with others for code reuse 2026-02-27 12:01:22 ARM has it, and it's name is CMSIS-SVD 2026-02-27 12:01:59 but lots of mcu brands don't, mainly Chinese clones and RISC-V chips 2026-02-27 12:02:54 without that register syntax to addresses table, you can't use the onboard peripherals, even make a simple blinky 2026-02-27 12:04:31 Yeah, it's "must have" information. 2026-02-27 12:04:52 exactly 2026-02-27 12:05:48 I'm really glad I can actually write those registers - they very easily could have set those address regions so that I truly was locked into the one use model they offered. All they needed to do was leave those registers outside the accessible address ranges. 2026-02-27 12:06:54 Anyway, I continue to think I will get there in time. Just have to slug through it. 2026-02-27 12:06:59 when you mentioned you were using the ESP32-C6 I did find a online SVD, and ran it thru one of my earlier "svd2asm" apps, but the SVD had some variations in the the format and the output was useless 2026-02-27 12:07:55 so I did try to make you a table with ll that register - address info but couldnt 2026-02-27 12:08:55 it uses XSLT , Shell, sQlite etc, so it's not exactly trivial 2026-02-27 12:10:16 KipIngram, with Cortex-M, if you try and access any memory outside the existing blocks, the mcu throws a fault instantly, I expect that RISC-V will be the same ? 2026-02-27 12:11:04 I probably spent a few months aquainting myself with all those fault errors 2026-02-27 12:12:18 Yes, immediately. 2026-02-27 12:13:12 I expect that if youre getting memory fault errors, youre not accessing the right blocks 2026-02-27 12:13:24 On the other hand, if you put the serial port outside reach, you can perceive the slightest delay before the crash. 2026-02-27 12:14:02 in CMSIS-SVD, the addreses are broken down to 'base' and 'register' and they have to be added before use 2026-02-27 12:14:06 Just enough difference to notice. 2026-02-27 12:14:58 I didnt like that and so I create absolute addresses in a modified SVD I create, that way my mcu doesnt have to add them 2026-02-27 12:15:36 Yeah, that's how these are too. Base and offset (documented in different places). 2026-02-27 12:15:57 ahh, so that seems to be a standard then 2026-02-27 12:16:16 I suppose when each peripheral team is doing it's work they don't know yet where they'll be put. 2026-02-27 12:16:33 And it just never gets consolidated. 2026-02-27 12:16:44 Or maybe it varies from product to product. 2026-02-27 12:17:00 And they don't want to have to update all the details for every variation. 2026-02-27 12:17:12 it sure does, even amongs the same part but a later version 2026-02-27 12:17:41 but they do update every model with it's own Header file 2026-02-27 12:18:22 Ive observed massive differences even between different versions of the same model 2026-02-27 12:18:24 I can already see Forth code for it one of these days, using create/does>. 2026-02-27 12:19:41 some do, but most use constants, either way neither are a good fit given small memory and massive numbers of registers 2026-02-27 12:20:10 thats why I moved all that stuff outside the mcu with FURS 2026-02-27 12:20:31 A little like when I wrote my x64 assembly words. If you stare at the instruction encoding enough you can see a lot of patterns. I had a defining word for binary operation instructions (like add, etc.) that went something like "binary_op add ". 2026-02-27 12:20:48 And it would make add be a word that plugged the right special bits into the right pattern. 2026-02-27 12:20:55 that way I can have easy access to every bitfield by name with no memory overhead 2026-02-27 12:22:01 I think Moore did that with the Motorola 6800 as he found a 1:1 correspondence between the opcodes and his Forth 2026-02-27 12:22:30 but the 6800 is simple and restricted compared to ARM 2026-02-27 12:36:54 It only worked for a subset of the instructions, but it was enough of a subset to support writing a Forth, which was what I mostly cared about. I really wouldn't even contemplate trying to tackle the whole thing, as bloated as it's gotten. 2026-02-27 12:37:20 You can see that once upon a time there WAS some sense behind it. 2026-02-27 12:37:41 yes 2026-02-27 12:38:20 One thing you notice right away is that rsp and rbp are "oddball" registers - when they're used in an instruction it doesn't encode per quite the same pattern. Same instruction, same addressing mode - just a different registers, and it makes a bigger change than it really should. 2026-02-27 12:38:33 I'm sure there's a reason, but I couldn't discern it. 2026-02-27 12:39:13 Actually maybe it's not rsp. It's rbp, and then whichever one of the new eight registers - r13 I think - that corresponds to rbp in the sequence. 2026-02-27 12:39:54 I generally don't use rsp for anything in my x86 Forths. I just leave it the way the OS gives it to me, and it only gets used when I make syscalls. 2026-02-27 12:42:02 maybe theyre registers for the CPU ? 2026-02-27 12:42:33 I only access peripheral registers myself, but then youre a Forth implimentor, I'm a Forth user 2026-02-27 12:44:40 KipIngram, here is a screenpic I just took of my local STM32F051 forth thermometer 2026-02-27 12:44:44 https://bpa.st/MZWA 2026-02-27 12:45:58 it shows the state of a number of onboard peripherals, most notably 'tim2en' is = 1 as it's enabled 2026-02-27 12:46:17 this is the right most vertical item 2026-02-27 12:47:30 I hade a number of these facilities to help me with the 'wider view' of registers when I first started with the chip 2026-02-27 12:48:18 i.e. id change a bitfield and then want to see if it had actually been changed 2026-02-27 12:49:09 these 'register views' helped me resolve problem bitfields that I couldnt seem to change 2026-02-27 12:53:17 I'm not far enough into this yet to start to see the "big picture" well enough to know what that will all look like except in the most vague way. 2026-02-27 12:53:51 The tech ref (TRM) lays it all out by subsections, so I expect its Forth support will line up that way too. 2026-02-27 12:55:23 then boredom won't be an issue ;-) 2026-02-27 12:56:36 Once I have all the "gettint it to work" bits done, I expect the uart to be the only tricky part, since I'm actually already using it under the stock infrastructure for the monitor itself. So whether or not I'll be able to switch back and forth between the monitor and the Forth and have both of them use it remains to be seen. At some point I may just have to kiss the monitor goodbye, but I'm 2026-02-27 12:56:38 trying to arrange things so it can stay engaged as long as possible. 2026-02-27 12:59:08 KipIngram, does your mcu feature JTAG or SWD ? you can monitior thu those without affecting the Forth terminal with Cortex-m 2026-02-27 12:59:48 tho thanks to crest, I use SWD for my Forth terminal now instead of a UART 2026-02-27 13:21:43 It may. I don't know all of it yet - I've sort of zeroed in on specific parts of it so far. It's got a lot, so I'm guessing it probably does. 2026-02-27 13:22:26 Right now my obsession is this whole permissions thing. 2026-02-27 13:23:42 I've got a block of C code in the monitor that does whatever register pokes I want, and I implemented @ and ! in the monitor, so I can read those back in the monitor to confirm they took. 2026-02-27 13:25:05 The flash code starts a second thread that actually is "the monitor" - the pokes are in "app_main" just before it starts the monitor thread. 2026-02-27 13:25:26 Actually I should look at that thread call - there may be some parameters there that affect it's capabilities. Maybe there's something there I can adjust. 2026-02-27 13:25:38 I didn't write all of it - I hijacked one of the provided examples. 2026-02-27 13:26:17 I do make calls from app_main that initialize the GPIO subsystem, so I can turn the LED on and off with ! too. 2026-02-27 13:27:02 I can either wiggle the output, or wiggle the registers of output enables - either one affects the LED state. 2026-02-27 13:30:30 Base/offset is also because you'll have more than one controller of the same type, so they can just instance them at different bases 2026-02-27 13:31:17 According to ChatGPT the USB interface to the ESP32-C6 exposes different interfaces, so that simultaneous "normal uart" and JTAG interactions are possible at the same time. 2026-02-27 13:31:26 So that's something interesting to look into at some point. 2026-02-27 13:31:43 veltas: Very good point. 2026-02-27 13:31:47 Hey eveyone, I'm new to Forth. Finished the Starting Forth book and now figuring out the code writing workflow. As I understand it just playing around in the interpreter loop is not a proper workflow because definitions are compiled. So I need to have a separate file in a separate terminal opened, use MARKER dev in my Forth (I'm using VFX on Linux) include the file, and play with it, then go back to my 2026-02-27 13:31:53 text editor, change the definition, go back to Forth, use dev to rollback the state, include the file again and play with the new version. Is this the loop I'm supposed to be doing? Feels not Forth'y, more like regular development, so I'm confused. 2026-02-27 13:33:24 tulushev: That sounds more or less right. Your Forth may have a LOAD word that can directly load your source file, but it sounds like you have the right notion of hopping back and forth between compilation and interaction. 2026-02-27 13:33:55 thanks! 2026-02-27 13:34:06 Forth app development is a little different from o ther languages, in that ideally your application's interface will BE the interpreter, and what you mostly do is craft an application-specific "lexicon" that makes it easy to accomplish whatever you're interested in. 2026-02-27 13:34:23 Of course if you want a GUI and so on, that's sort of a different case. 2026-02-27 13:34:56 But the presence of the interpreter means you can do a lot without actually having to "build an interface." You just use the one that's provided. 2026-02-27 13:35:33 So it all has a very different feel from the C-like "edit, compile, run" cycle. 2026-02-27 13:35:48 yeah, playing around with the code interactively and coming up with tests is nice, even if I need to context switch once in a while 2026-02-27 13:36:30 And all that said, of course you CAN just make some arrangement to paste your source file directly into your typing interface - that works too. 2026-02-27 13:36:47 I thought that if my Forth has a LOCATE that can jump to edior than maybe there's a way to just SAVE not an image but a definition. but it's compiled so that's not the way 2026-02-27 13:36:50 Really all LOAD does is re-direct that stream from the keyboard to a file temporarily. 2026-02-27 13:37:18 Traditionally you LOADed "blocks" - actually raw sections of your disk, no file system involved. 2026-02-27 13:37:49 yeah, I tried that and it's a nice mental model. doesn't matter if you type in the interpreter or just load from a file, it's all the same 2026-02-27 13:37:58 And the code being loaded can also interpret or compile, so it's free to recursively LOAD other blocks as it LOADs. You can nest that as much as you want, up to whatever your stacks can handle. 2026-02-27 13:38:54 Those blocks all had consecutive numbers, and in most cases as far as the interpreter was concerned "block 0" meant "keyboard." 2026-02-27 13:39:09 I made an app.bld that has includes for all my files and I use that to include everything at once. is this the way? 2026-02-27 13:39:42 It's fine. You could nest them if it made sense to do so, but loading them consecutively at one level works perfectly well. 2026-02-27 13:40:14 The main difference between blocks and files is that blocks are fixed size, so only so much source can fit in one. 2026-02-27 13:40:38 What file extension do people use? I see .forth .fth .fs .f being used, even .4th 2026-02-27 13:40:40 A lot of old Forths had a word --> that meant "move on to the next block in numerical order." 2026-02-27 13:41:08 gforth use .fs and Forth Inc use .4th I think 2026-02-27 13:41:14 Up to you 2026-02-27 13:41:15 are block still relevant if you use Forth from inside an OS? 2026-02-27 13:41:45 Not really, though many systems implement a "block file" - a particular file that you access as though it's a bunch of blocks. 2026-02-27 13:41:48 In some way blocks are a portable interface, it can be nice to write code that will run on an OS and also an embedded device 2026-02-27 13:41:57 Just to be able to support the traditional block notion. 2026-02-27 13:42:08 Really depends what you want to do 2026-02-27 13:43:17 I mean almost any computer can support something like blocks, so if your database can use blocks then it can pretty much run anywhere 2026-02-27 13:43:34 I wish I knew about Forth 15 years ago when I was programming microcontrollers. I was doing everything in just assembly and C devs were running circles around me. Only learned about it now and it's like a life changing event 2026-02-27 13:43:38 But why do that to yourself ... most of us using blocks do so because it's retro / fun 2026-02-27 13:44:23 Unfortunately computers are rarely designed for assembly programmers now 2026-02-27 13:44:30 Yes, or in my case because I dream about being bare metal at some point. 2026-02-27 13:45:03 There are some good Forths like mecrisp for embedded programming 2026-02-27 13:49:19 I've seen it, looks great. Don't do micrococontroller dev anymore. My work is cross platform SDKs in Rust. Personally I play around in Zig doing GUI apps from scratc, no libc, just blitting buffers to compositor on a socket. Will do that in Forth now. Feels like a perfect language, close to the metal but still high level 2026-02-27 13:50:05 By the way, I don't see much Forth code on GitHub. Are people not keen to share because everyone's stuff is too custom made or do people share code elsewhere? 2026-02-27 13:50:48 Forth is just very niche. Not quite "dead" - the folks who are fans are pretty intense ones. But there just aren't a huge number of us. 2026-02-27 13:51:06 that's the feeling I got 2026-02-27 13:51:36 It's infectious - if you do enough of it it has a way of getting under your skin. 2026-02-27 13:51:49 : D 2026-02-27 13:52:40 In my case the very first programming I ever did was on an HP-41C calculator, in college. It's an RPN calculator, so I got "stack think" kind of burned into my head when it was all still virgin snow in there. So Forth immediately appealed. 2026-02-27 13:53:23 omg I envy you, nice introduction 2026-02-27 14:27:58 From my lsusb output: 2026-02-27 14:28:00 Bus 003 Device 010: ID 303a:1001 Espressif USB JTAG/serial debug unit 2026-02-27 14:28:08 So yes - JTAG is there. 2026-02-27 14:30:25 tulushev: I just inhaled it. Wrote "labor saving" programs for all my classes, etc.The 41C didn't support complex arithmetic natively, but I implmented a software environment for it, with a complex stack in the register space, and on top of that built a program that would use phasor methods to solve for all the steady state voltges and currents in a circuit with R, L, C, variable voltage and 2026-02-27 14:30:27 current sources, and so on. 2026-02-27 14:31:17 Also did one that basically emulated Smith Chart operations, for solving transmission lines. 2026-02-27 14:31:53 And in the university library I found a book called Algorithms for RPN Calculators by Ball and inhaled that too. Lots of astronomy algorithms in there. 2026-02-27 14:36:46 wow, I was wondering what kind of programs were possible there. I used Mathcad at home for those kind of tasks in uni, using a programmable calc in immediate environment would be much cooler 2026-02-27 14:39:31 tulushev: The main forths I've seen aren't on github, although I'm sure there's some on there 2026-02-27 14:39:36 I'm now reading Forth Programmer's Handbook and section 1.5 is talking about exactly what we discussed above and example workflow from start to finish. Great book after Starting Forth + Thinking Forth 2026-02-27 14:39:44 Github isn't the only place things happen, especially these days 2026-02-27 14:39:51 People are getting a bit tired of github 2026-02-27 14:40:00 My ZX Spectrum Forth is on there 2026-02-27 14:41:07 found it (https://github.com/Veltas/zenv) thanks 2026-02-27 14:42:45 I was using this way to search top repo's written in Forth and it's not much https://github.com/search?q=language%3AForth&type=Repositories&ref=advsearch&l=Forth&l=&s=stars&o=desc 2026-02-27 14:46:49 ok, this misses projects like yours, written in ASM but actually implementing Forth 2026-02-27 14:51:09 Ok, so hopefully I have learned something important. I was proceeding on the assumption that all of the relevant registers were memory mapped, but apparently that is untrue - some of them are internal to the RISCV core and are accessed using special instructions, which I will have to use inline assembly to issue. csrr and csrw instructions. 2026-02-27 14:51:41 The pertinent ones for RAM permission are at 0x3A0 through 0x3BF (not addresses - register numbers). 2026-02-27 14:52:28 Also, I do see now that my C code is NOT running from RAM. It's running from external flash. So it's getting cached, but not brought into RAM. 2026-02-27 14:53:32 It looks like what I need to do is make the appropriate modifications to the registers noted above and then issue the "fence.i" command to post all that to the instruction execution unit. And then hopefully I will be able to run code from RAM. I was also trying to write to code space, but that was really just for testing and isn't something that actually matters. 2026-02-27 15:10:21 Is the special register an immediate or can it be indexed by a register? 2026-02-27 16:46:01 It appears to be immediate, and furthermore cannot be done in inline assembly with a contructed on the fly string - it has to be a compile time constant. 2026-02-27 16:46:17 anyway, I dumped the registers all out, and an issue has arisen. 2026-02-27 16:46:44 The registers that contain the permission bits also contain a "lock" bit that will trap any attempt to modify the register, and once it's set it can only be cleared by a reset. 2026-02-27 16:47:04 So - I'm stuck as far as the immediate path goes - I'm locked in. 2026-02-27 16:47:07 However... 2026-02-27 16:48:09 These lock bits reset clear - they have to get set at some point. In my project build directory, there is a subdirectory bootloader (secondary bootloader that gets built into my project), and in there is bootloader.bin and bootloader.elf. 2026-02-27 16:48:29 It sounds like you're learning a lot from this work 2026-02-27 16:48:33 Apparently bootloader.bin is the "business item." I've disassembled bootloader.elf and I have found the code where all t his is done. 2026-02-27 16:48:50 I intend to patch bootloader.bin to a) clear all lock bits and b) set all X bits. 2026-02-27 16:48:52 Is .bin just objcopy of .elf? 2026-02-27 16:49:44 I don't know, but it's worth checking. I suppose I could consider changing the assembly and re-building it, but I've never done anything that extensive before and the idea of just changing a few bits in .bin seems more sure to me. 2026-02-27 16:51:12 It's probably easier to change the source if you've got that, and rebuild 2026-02-27 16:51:33 The source may also help you understand caveats of "just changing the value", if there are any 2026-02-27 16:57:05 I'll keep it in mind. 2026-02-27 16:57:35 This is frustrating to me. I'm 100% fine with the device having this "ultimate lockdown" capability - I see it as having value in many field applications. 2026-02-27 16:57:58 But for them to put you into this locked down environment when they're giving you DEVELOPMENT tools is just sinful. 2026-02-27 16:58:04 Completely ridiculous. 2026-02-27 16:58:48 I object to having permissions thrust onto me at all, but to make them IRREVOCABLE is almost unforgivable. 2026-02-27 16:59:22 Unless I make this work, this entire toolchain becomes useless to me. 2026-02-27 17:03:17 Is this lockdown non-volatile? 2026-02-27 17:27:09 I just found out about conflictStyle diff3 2026-02-27 17:27:14 Where has this been all my life 2026-02-27 17:27:38 If you don't know what I'm talking about and you use git you need to go look it up right now 2026-02-27 17:39:58 Holy cow. After all that wrangling around, the problem is now solved. And, veltas - you were very wise there. I was actually in the process of perusing the source tree anyway, before proceeding. With some judicious grepping I ound my way to a function void esp_cpu_configure_region_protection(void). There was a comment there that referred to a project configuration option. There was a remote 2026-02-27 17:40:00 place in the config files where one could turn memory protection on and off. I turned it off, and now I can call my RAM buffer and it works fine. I just have a return instruction there, so the command behaves as a noop. But... it silently returns instead of crashing. Once I had that option off, idf.py fullclean ; idf.py build ; idf.py flash did the whole job. 2026-02-27 17:43:55 Nice 2026-02-27 17:44:09 But what about diff3? :P 2026-02-27 18:01:17 Ok, I added code to toggle the LED before returning - that works. I regard that as a full proof of principle. 2026-02-27 18:02:10 I guess I have to take back the worst of the comments I made about the tool developers, since all they were really doing was defaulting to me "asking for" protection. It was the idea of being entirely locked in that was most upsetting. 2026-02-27 18:02:26 I stand by the "too much complexity" remarks, though. 2026-02-27 18:14:50 It's crazy to me that's the default for an embedded chip 2026-02-27 18:18:08 Well, it's more the default of the tool chain than the chip. It says pretty clearly in the technical reference that the chip itself boots up with all of RAM readable, writable, and executable. 2026-02-27 18:18:23 This was all imposed by the open-source toolchain. 2026-02-27 18:19:07 And not mentioned plainly and clearly in an "overview" or any easy to find place - I had to find it by scratching around. And it was buried way way down in the configuration tree. 2026-02-27 18:20:02 They have a tool, idf.py menuconfig, that runs one of those "text/graphical" curses style GUIs. A big tree of config options. It was way down in there somewhere, and even knowing it was there somewhere I had to search around for it for a while. 2026-02-27 18:20:41 I'm taking a break to do other things for a while - it's been about two solid days of nothing but this, but now I can relax and feel at ease - it works. 2026-02-27 18:35:19 Does anyone use double cell operations on 64 bit systems? 2026-02-27 18:59:10 I don't - I let . designate a float instead. 2026-02-27 18:59:23 I've just never been able to imagine needing 128-bit integers. 2026-02-27 18:59:58 2^128 > 2^64 in a grander sense than 2^64 > 2^32. 2026-02-27 19:00:48 If you have 32 bits, you can at least imagine "running out" even in counting applications. Just count the people on Earth. But I haven't thought of any easy way to run out of 2^64 values. I guess you could say "count the particles in the universe," and that would do it, but... really? 2026-02-27 19:21:54 One argument that I've found is that it improves portability. But IMO if you are not using a known integer type in the first place - there's no portability anyway. Another argument - running old Forth code that was written in 16 bit, here I agree. But writing new code doesn't seem right 2026-02-27 19:26:19 I've never sweated much over portability. My career was mostly in embedded work, and the goal there is the one system in front of you. You've got full control over the hardware and the software, and that's the only thing that needs to work. 2026-02-27 19:26:43 You certainly don't want to compromise its performance in the name of supporting non-existent platforms. 2026-02-27 19:26:59 Non-existent within your product line, at least. 2026-02-27 19:27:43 Yep, those kinds of constraints are liberating 2026-02-27 19:28:26 For sure, and I concede that the environment may have produced a degree of bias in me. I'm sure portability is a real headache for a lot of software engineers. 2026-02-27 19:35:27 Yeah. My current work is cross-platform binary for mobile phones, needs to work on all possible Android's and iOS devices with any combination of CPU's and OSes. It's a pain to set up and test, knowing ASM and OS internals is a must. Having no dependencies helps. Thinking of writing Forth'y Raylib with ability to output CPU rendered graphics on Linux, macOS, Windows, Web would be very nice 2026-02-27 19:47:27 I'm planning for this next Forth I'm just getting started on to be multi-platform, but it's going to involve a byte-coded vm, which I can make identical on all platforms. So the actual "Forth system" should be easy to make portable. The vm layer will of course have to be targeted for each platform, and then there will also be some Forth code that handles platform specific hardware. But I expect 2026-02-27 19:47:29 those non-portable parts to be only a small portion of the ultimate code body. 2026-02-27 19:48:02 On the notebook/desktop targeted version (x86 Linux) I plan to link in SDL2/OpenGL and have graphics support. 2026-02-27 19:48:22 In fact, my "console windows" there will be SDL2 windows. 2026-02-27 19:49:21 And I do want to be able to ssh from them to other places, like here (my irc client runs on a remote server and I ssh into it), so I will have to implement all my own support for ANSI control codes and so on. 2026-02-27 19:52:38 tpbsd: Now that I've learned that when the typical user builds a project for the ESP32-C6 their code runs from flash, with a cache intervening to give the CPU a standard memory interface, it's easy to see how some jitter could come into square waves and things like that. It could get injected by cache misses and so on, which then have to be serviced by access to a serial flash load. 2026-02-27 19:52:56 I at first thought the code got copied out of flash to RAM, but that turns out not to be the case. 2026-02-27 19:53:34 It will be the case in my Forth, though - when it's all said and done it will get moved from flash to RAM at boot and will run from there. There is no cache between the CPU and the internal RAM, so that issue just goes away. 2026-02-27 19:54:42 I'm sure there will be other possible sources, but I will look into mitigating those as the system comes together. I haven't really set out to "write a strict realtime system," but nonetheless it seems reasonable to at least think about trying to make timing activities and so on as precise as possible. So maybe it will wind up being "near-realtime." 2026-02-27 19:55:47 I haven't studied the interrupt controller yet, but if it has a priority system then it ought to be possible to prevent less important interrupts from intruding on higher priority threads. 2026-02-27 19:56:28 And it would just be on me to avoid writing those high priority threads to be so greedy they caused problems. 2026-02-27 19:57:07 A lot of thinking still to do on that front. 2026-02-27 19:57:55 veltas: So, yes - if the default for these projects had been to NOT have memory protection, this would have just worked on the first go two days ago. 2026-02-27 19:58:31 In the end all the putzing around with the configuration control registers was interesting and I'm sure is good knowledge to have, but none of it contributed to the final resolution at all. 2026-02-27 19:59:48 Once it's all working I may put some protection back - I could easily see locking down the vm machine code and the main system vocabulary. 2026-02-27 20:00:30 You can have up to sixteen different protection regions, so that might prove useful later on. 2026-02-27 20:01:59 I find SDL/Raylib to not be so portable. It's easy to pipe raw buffers to compositors directly and the setup doesn't even require linking to .so or .dlls in runtime. The setup is ugly but needs to be done once, and it's just a buffer of RGB pixels in platform dependent arrangements, very simple as an interface, simpler than trying to fit into external lib ABI's IMO 2026-02-27 20:02:51 KipIngram, great progress! 2026-02-27 20:04:07 KipIngram, turning off the cache should just be a config away ? 2026-02-27 20:04:49 I don't think you can turn it off - it's there to allow the CPU to treat the external SPI flash like it's a normal RAM addressible memory. 2026-02-27 20:05:02 Once I've copied my code into actual RAM it'll be irrelevant. 2026-02-27 20:05:07 KipIngram, it is on my STM32F051, in fact it's disabled by default after boot. I wonder if your cache is turned on my your dev system ? 2026-02-27 20:05:15 Well, except when I access flash explicitly. 2026-02-27 20:05:24 Which is what BLOCK will sometimes do. 2026-02-27 20:06:01 Though I also want BLOCK to be able to fetch data over networks. 2026-02-27 20:06:10 KipIngram, maybe it is, I admit I dont use MCU's with external flash 2026-02-27 20:06:59 KipIngram, so I'm clueless regarding how they work. I only use MCU's with internal parallel flash (not on die SPI) 2026-02-27 20:07:15 I like it - it means once you've written the SPI flash config registers to define how your particular flash chip works, then the whole thing is just transparent - you don't have to fret over the SPI details anymore. 2026-02-27 20:07:54 It's just a particular serial protocol. You stream out your address and stream your data in or out. 2026-02-27 20:08:03 as long as youre not making product and have to source SPI chips, the good ones not ones with 100 life cycles 2026-02-27 20:08:10 I don't know the details either, really. 2026-02-27 20:08:57 I know how it works, I just dont use SPI flash main memory as it complicates my designs 2026-02-27 20:08:59 I haven't seen the life cycle count on this chip, but the biggest reason I wanted to immediately set up this ability to run code out of RAM was to stop having to write the flash every iteration. 2026-02-27 20:09:32 Because I'm sure there will be a LOT of iterations. 2026-02-27 20:09:37 absolutely! I do the same during development as Mecrisp-Stellaris can compile to flash or ram 2026-02-27 20:10:11 I've never used mecrisp, but I've read lightly about it and find it so impressive. It just "feels right." 2026-02-27 20:10:18 so all my development Words are in ram, once tested, I move them to flash as I only have 8KB ram 2026-02-27 20:10:39 it's very optimised, fast and easy to use 2026-02-27 20:10:48 I have 512kB of RAM, so I expect to only have to do that once, for the most part. 2026-02-27 20:11:09 Im a Forth user and I only make projects, Im not a Forth implimenter like you 2026-02-27 20:11:19 I'm sure from time to time after that I'll re-flash as I add more capability (after I can metacompile), but it should be very infrequent. 2026-02-27 20:11:43 it's all a trade off, massive ram usually means huge page sizes and slower ram access 2026-02-27 20:11:54 the same with flash 2026-02-27 20:11:54 That's another reason to be able to have BLOCK handle distributed blocks - I'll be able to BLOCK stuff in from my notebook. 2026-02-27 20:12:22 And FLUSHing those blocks won't write the flash. 2026-02-27 20:12:51 that's way off down the road, though - first I have to get some kind of networking up. 2026-02-27 20:13:06 my dev system is all PC based, ZFS on freeBSD with 15 minute snapshots so it's very fast 2026-02-27 20:13:56 But I have this ability now to transfer files from my notebook into the RAM buffer, so I can get a long way like that. Instead of typing LOAD into the ESP itnerpreter, I'll just run a script on my notebook - it will just squirt over the source I tell it to send, through the usb serial. 2026-02-27 20:14:02 I can flash my thermometer project to ram in 0.2 seconds after chip reboot, and I do that at every change 2026-02-27 20:14:48 Ive learnt that I can spend days confused about non reboot states if I don't do that 2026-02-27 20:15:38 it only takes one errant bit somewhere to ruin my day, so I always start every code change from a guaranteed mcu reboot state 2026-02-27 20:16:56 Ive experimented with 'warm' reboots and found that method is unreliable the way I work 2026-02-27 21:27:21 Yes, warm restarts in Forth are hard unless limit them. The return stack is usually cleared every iteration of the main interpreter loop anyway (just before fetching a new input line), and it's easy enough to have WARM clear the data stack in addition to that. Doing more is difficult. There's a lot to unwind in a modern Forth system - it was a lot easier back in the old days when it was just one 2026-02-27 21:27:23 RAM region growing nicely upward. Later developments added a lot of complexity. I content myself with WARM clearing the data stack and restarting the interpreter (which clears the return stack). I also have COLD, which goes all the way back to copying the entire initial image from its original location into the runtime RAM region, so it truly is equivalent to shutting the system down and 2026-02-27 21:27:25 re-starting it. Even there, though, any mallocs you've done outside of that original region have to be unwound. Any threads you used the operating system to start, etc. 2026-02-27 21:28:01 Files you have open and so on. 2026-02-27 21:28:39 I don't run my code from where Linux puts it - I allocate a large RAM region for my system and copy the code there and run that. 2026-02-27 21:29:17 And the initial data section too - the Linux-loaded stuff is left in its virgin state. 2026-02-27 21:29:49 COLD actually returns control flow to that original load image (which is a bit tricky, actually). 2026-02-27 21:30:25 As is getting actual CPU execution from the load image to the copy in the first place. 2026-02-27 21:31:12 So the idea of copying the esp32-c6 code from flash to RAM fits into that model pretty well - I've already been around that block.