00:00:00 --- log: started forth/20.03.01 00:47:16 kori: The keyboard for ZX Spectrum is not that bad IMO, but the token typing (instead of character typing) for BASIC is annoying 00:48:25 Kumool: awesomerc.lua is an attempt to use Lua as a config file format, and it's really bad. I don't know what the personal goals of awesomerc.lua were but either they failed or totally missed the point. 00:49:31 That message on the mailing list is not "how you build a DSL in Lua", that is someone asking for a specific syntax that does not work well with Lua's built in sugars, customisation, but it was still relatively easy to parse with the built-in matching features 00:54:46 --- quit: iyzsong- (Read error: Connection reset by peer) 00:55:08 --- join: iyzsong joined #forth 01:04:27 --- quit: iyzsong (Read error: Connection reset by peer) 01:04:33 tpbsd: The way I would do NOR Flash for Forth is to keep an area for just writing an index of where the latest versions of each block index is, and then for the rest of the erasable area write out copies of each block each time it is written back to storage 01:05:12 So you are only erasing when the area runs out of space for these copies, the simulated 'max' size of the area is about half of the Flash size 01:05:37 And you get some wear levelling because it's writing over the whole thing before each erase 01:05:46 --- join: iyzsong joined #forth 01:06:09 veltas, the way I do it is use the hflash! command :) 01:06:31 I'm just a Forth user, I dont write forths 01:07:05 Don't search for "hflash!" 01:07:13 I just found out that was a bad idea 01:07:24 I used that command recently when I released a diagnostics program for 'blue pill' board owners 01:07:56 among other things it tests a 64kB block of flash by writing to every location 01:08:02 Why is it called 'blue pill'? 01:08:06 --- quit: proteus-guy (Ping timeout: 260 seconds) 01:08:33 it's a small pcb that's coloured blue 01:08:56 probably a oblique reference to 'the matrix' film as well ? 01:09:02 There is a Matrix reference in there somewhere I think yes 01:09:10 I dont know, I dont even own one 01:09:20 but they are really cheap 01:09:25 usually $2 01:10:10 but they have some serious problems one of which is they tend to come with fake STM32F103 MCU's 01:10:59 my program designed to interrogate the mcu and help find out what it was 01:11:44 Interesting 01:11:48 to date I've had about 150 downloads of my binary presumably by blue pill owners 01:12:29 Nice 01:12:49 it's become a bit boring now as Ive learnt a lot about whats happening with that product, which was a mystery to me initially 01:13:20 I made the self booting binary with Forth, which was the perfect OS to do it in 01:14:00 Nice 01:14:26 we have a Forth USB driver for that board so all the owners needed to do was plug in in and connect a serial terminal to the virtual com port 01:15:54 checkout the USB ID string "Mecrisp STM32F10x Forth Serial Port" 01:19:13 Interesting 01:40:29 crc: If I am understanding repl.c correctly your dictionary has 4 fixed position fields "link", "xt", "class", "name". What is "class"? Is that whether it's immediate or not? 01:40:41 Also what is the "xt" literally in your forth? 01:45:33 Word classes are one of the two elements at the heart of 01:45:34 RETROâs interpreter. 01:45:34 There are different types of words in a Forth system. At a 01:45:34 minimum there are data words, regular words, and immediate 01:45:34 words. 01:45:52 http://forth.works/book.html#stack-diagrams 01:47:07 I like the colon for namespace separation 01:47:35 http://forth.works/book.html#header-structure 01:48:16 I'm still not used to different namespaces, I still find them too wordy 01:48:43 and Mecrisp-Stellaris doesnt have them as it's for small mcu's 01:49:17 wheras retro is generally used on a PC where there are tons of every resource 01:50:50 veltas, my diagnostics program has to be under 64kB with everything, and there are no alternatives except perhaps Basic which few use now 01:51:25 eLua needs at least 256kB just to run, so it's no good for that kind of application 01:51:35 same with micropython etc 01:51:37 I am working on 8-bit stuff at the moment 01:51:43 yeah, Z80 01:52:16 I have made product with the Z80 in the past, written the code in C 01:52:25 oops assembler I mean 01:53:03 that was around 1982 I think 01:53:40 i made thousands of Z80 boards for one product once 01:54:02 --- join: rdrop-exit joined #forth 01:54:41 lol, and a decade later I saw a box of the same boards at a auction, and didnt recognise them at first 01:54:53 What did they do? 01:55:40 they did a couple of things. They were used in commercial video games, the kind of machines you see in video game parlours 01:56:11 1) reset the game if a static charge was detected on the metal coin box 01:56:44 2) if 2 coins were entered before the start game button was pressed, add a free credit 01:56:58 something like that 01:57:27 may have been a free credit for every 2 coins and two free credits for 10 coins etc 01:58:22 in those days the kids playing the games would use a piezo electric gas lighter to spark into the metal coin box to glitch the game and try to get free credits 01:58:24 Okay 01:58:30 'ok' 01:58:55 it worked pretty well, and they could glitch thousands of extra credits 01:59:12 So not that well then 01:59:24 there was a lot of TTL still in the games at that time 01:59:42 TTL? 01:59:47 and TTL was a real problem with spikes 01:59:59 Transistor Transistor Logic 02:00:08 Oh right 02:00:21 it was replaced with CMOS eventually (thank God) 02:00:55 so my Z80 board would also detect the spike and reset the game, goodby all credits 02:01:11 it was a nice project, simple, reliable 02:01:25 and the board was retrofitted into thousands of games 02:01:45 good old Z80 02:01:59 I wrote the code on a TRS80 02:02:16 i still recall it's brand new smell as I unpacked it at work 02:02:23 plus the manuals etc 02:03:05 the Z80 was a Godsend at the time, but I'm not nostalgic about it 02:03:14 I always loved the 6800 myself 02:03:27 Z80 is really dirty 02:03:30 and now it's all cortex-m or msp430 for me 02:03:33 6502 is pure but really verbose 02:03:52 although I have a couple of hundred PIC18 and PIC24 series chips 02:04:29 yeah, 6502 is much like the 6800, in fact designed by some guys who worked on the 6800 02:04:45 I know what you mean 02:04:59 there is still a lot of 6502 love about I see 02:05:32 Ive never used it myself, tho Ive repaired plenty of Atari games boards that use the 6502 02:05:35 Well it is credited as being the RISC genesis 02:06:02 yet it's not risc itself ? 02:06:21 it has plenty of instructions 02:06:36 It doesn't match the description of RISC 02:06:42 It doesn't have that many instructions 02:07:16 But it does a lot of memory operations, the typical RISC will do everything in registers and explictly separate out loads and stores 02:07:31 6502 has 1 GPR so that is not really an option 02:09:48 Zero page instructions treat the first 128 words like psuedo-registers, so that is the link I think 02:10:27 Coding in 6502 feels like coding for a RISC processor with 128 16-bit registers 02:13:08 aha 02:59:48 --- quit: rdrop-exit (Quit: Lost terminal) 03:31:22 --- quit: dddddd (Ping timeout: 260 seconds) 03:49:49 --- quit: APic (Ping timeout: 268 seconds) 04:06:52 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 05:20:31 --- join: APic joined #forth 06:10:31 --- join: john_cephalopoda joined #forth 06:10:34 Hey 06:23:48 Hello 07:08:18 --- quit: john_cephalopoda (Ping timeout: 256 seconds) 07:08:58 --- join: john_cephalopoda joined #forth 07:33:34 --- quit: jsoft (Ping timeout: 260 seconds) 08:25:01 --- join: dddddd joined #forth 09:38:21 --- quit: MrMobius (Quit: Want to be different? Try HydraIRC -> http://www.hydrairc.com <-) 10:50:07 CUISINART 10:57:12 --- join: proteus-guy joined #forth 11:26:43 Are there forths where R> DROP EXIT does something meaningful? 11:26:55 Like where e.g. you put a previous return value in there 11:27:17 and you get to go back to where it was interpreting before? 11:38:48 --- quit: john_cephalopoda (Read error: Connection reset by peer) 11:38:57 --- join: john_cephalopoda joined #forth 12:27:56 --- quit: gravicappa (Ping timeout: 255 seconds) 12:42:43 veltas: in many Forths that's an ugly way of doing a branch 12:43:00 well wait 12:43:10 that's R> DROP >R EXIT 12:43:56 R> DROP EXIT isn't very useful because it only exits to the thing that called the caller if the caller put nothing on the stack aside from its return address 12:47:01 How common is it that this can do a branch? 12:53:28 it typically can from what I gather, but I'm not sure if it's something you want to do 12:54:47 hmmm 12:55:17 Well just relevent to me now deciphering how I will implement my forth 12:56:22 I have a better(?) question, reading Starting FORTH, it refers to a "code pointer" in each dictionary entry, preceding the parameter field 12:56:47 Is that a pointer to machine code or a pointer to a colon definition's parameter field? 13:12:37 I wouldn't even think about that 13:12:50 like the Forth I'm developing right now lacks that 13:13:09 it's an SRT/NCI Forth 13:14:32 veltas perhaps read https://www.bradrodriguez.com/papers/moving1.htm instead ? 13:14:44 it's much more modern 13:14:57 a code pointer is basically a thing in indirect threaded Forths 13:16:03 hey tabemann when you have the basics of your Forth running, I'll make you a svd2forth for your stm32l476 13:16:19 but yeah, in zeptoforth words are described one of two way - as a pointer to their header, or as a pointer to the code itself (the 'xt') 13:16:25 tpbsd: thanks! 13:16:49 tabemann, be my pleasure 13:19:12 I'm annoyed that I can't get writing to Flash to work for some reason 13:19:52 thats one of the harder parts of some STM32's 13:19:57 even though my Flash writing code is basically identical to Matthias's in its basics (because I essentialy copied it from him verbatim, complete with copyright attribution) 13:20:43 just be glad you didn't pick a Atmel SAM Cortex-M 13:21:09 perhaps run up matthias code and look at what it's doing via GDB ? 13:21:27 and I know that flash writing works under Mecrisp-Stellaris for STM32L476 because I tried it before successfully 13:21:36 then check against your own code 13:21:56 sure, but he also battles with flash on new chips 13:22:35 tpbsd: That looks very relevant to me, thanks 13:22:52 most C users never have to bother, they flash their binary via openocd and thats it 13:23:18 veltas, Brads page is a kinda defacto for people writing their forths 13:23:32 tabemann: Refer to the flash spec maybe? 13:23:38 spec/datasheet 13:26:30 "refer to the spec" isn't very useful in all cases when you consider just how much spec there is to deal with 13:26:42 veltas, so also is "jonesforth" which you can find on http://git.annexia.org/?p=jonesforth.git;a=tree 13:27:20 tpbsd: I have been checking my code against Mecrisp-Stellaris to see if I made any mistakes 13:27:23 tabemann: Yes and if I remember rightly there is something in the spec about how errors are reported by flash 13:27:44 That's why I said it, didn't mean to come across as "rtfm" but realise that's how it sounded 13:28:15 Mecrisp-Stellaris doesn't seem to check the Flash for error conditions 13:28:34 tabemann, it does 13:28:48 i found that when I was making my binary 13:29:18 at least if you try and write a location that you previously wrote to it throws a error message 13:30:01 that's not a flash error 13:30:05 my code has that too 13:30:15 that's managed completely in software 13:30:24 it's a mecrisp flash error to me tho :) 13:30:30 all it does is check if the flash block is all $FF 13:30:36 and if it is not, it indicates an error 13:30:37 ahh 13:33:44 this is what I get " Wrong address or data for writing flash !" 13:47:55 --- quit: Kumool (Remote host closed the connection) 13:48:44 --- join: Kumool joined #forth 13:54:22 --- quit: Kumool (Quit: FreeZNC - Visit us! Server: chat.freenode.net Channel: ##bnc4you) 13:54:24 tabemann, that error is generated by Mecrisp-Stellaris for the following reasons 13:54:28 Is the desired position in the flash dictionary? Outside the Forth core 13:54:49 Check the address: it must be even on 2 13:55:28 Is -1 at the desired location in the memory ? <-- thats your $F check 14:07:01 --- join: Kumool joined #forth 14:17:46 -1 indicates unwritten memory 14:17:58 yes, erased state 14:18:03 or at least four words containing -1 in a row 14:18:06 $FFFFFFFF 14:18:13 yeah half word 14:18:55 I was suspecting it might have been my boot-up code not properly initing the flash, but my boot-up code looks kosher too 14:19:24 must be hard to debug at that stage ? 14:19:40 youre only working is assembly atm ? 14:19:46 is = in 14:19:48 this is all asm 14:20:02 I do have gdb though 14:20:06 yeah, fully non interactive asm 14:20:25 you know what you can do ? 14:20:29 well it has to bring up the driver code 14:20:43 zeptoforth is now interactive though 14:20:54 lol, install free rtos and then run Mecrisp-Stellaris as a task 14:21:23 develop zapyou Forth in another task 14:21:31 I tried running mecrisp-stellaris today, and the same test that I ran on zeptoforth which failed on it passed on mecrisp-stellaris 14:22:11 I'm not surprised even tho matthias code is beautifuly written imho 14:22:33 something may well be tucked away somewhere not obvious 14:22:41 I basically took his code directly, that's the thing 14:22:54 well obviously you missed something 14:23:05 his works, yours doesnt 14:23:10 (most of zeptoforth is written completely independent of mecrisp-stellaris; it's only the "driver" code that's copied 14:23:12 ) 14:23:27 sure, not that matthias would care 14:24:38 matthias actually told me it was fine if I used parts of stellaris-mecrisp 14:24:52 I've spent weeks analysing his code just to understand how some things work 14:24:58 (after all, he did license it under the GPL, as have I for zeptoforth) 14:25:07 of course, he's not precious about it 14:25:30 --- join: dave0 joined #forth 14:25:35 he would love to hear someone using some of his code in their own Forth 14:25:59 my only thing is that I wish he had licensed his code as BSD, so I could also license my code as BSD 14:26:03 it's not like hes swamped with emails asking if it's ok 14:26:12 so do I actually 14:26:27 but then we have what we have 14:26:35 GPL is better than no code 14:27:10 and once you fully understand what youre doing, you can rewrite the bits you copied 14:27:16 and relicense 14:27:43 the problem is that his code appears to be The way to do things 14:27:48 so it'd be hard to rewrite 14:27:58 for instance, I can use any license I like with the output from his "mecrisp-Across" 14:28:22 yeah, there is that also, his insights are like a laserbeam 14:29:05 matthias isnt just good at this stuff, he is devastatingly good, hes the God of Assembly thinking 14:31:03 my problem here is I have eliminated all the places where the flash-write code differs from matthias's, and it still doesn't work 14:31:46 no you havent 14:31:56 if you had, then yours would work 14:32:38 you may have 'exhausted' all the differences you can find, and I do appreciate how frustrating that is 14:33:12 I have had MASSIVE "aha" moments after spending days/weeks tracking down what Matthias has done 14:34:15 perhaps some command youre using isnt writing a register as you assume ? 14:34:51 perhaps a sequence order is critical ? 14:36:10 I write the very same registers as he does, in the same order, the only thing I can think of is that I wrote a constant wrong or something, but that I haven't been able to find 14:38:25 as a direct result of our convo here today I looked thru matthias flash code for my stm32f051 and found it quite straightforward 14:38:48 and it inspired me to include the reasons for his error in my online doc 14:42:47 hmm the flash assy for your mcu doesnt look much different to the code for my M0 14:59:04 back 15:08:34 YES 15:08:38 I figured out the problem 15:08:43 awesome! 15:08:48 it was totally nonobvious 15:08:57 as expected! 15:09:05 it worked after I turned off gdb and openocd and attached ran it without them 15:09:12 ah crap! 15:09:23 thats a real gotcha! 15:09:25 I know! 15:10:23 so looks like gdb doesnt solve *all* problems 15:10:55 I had the opposite problem recently 15:11:28 due to a STM32F1xx problem, reading the DBG registers only works when the debugger is ATTACHED 15:12:18 you can then remove it and still read the DBG registers, but after a POWER reset, those registers are unreadable 15:12:53 ironically, tho this was never fixed by STM with a respin, the clone makers fixed it 15:14:18 back 15:14:30 yeah you told me about that 15:15:10 all in all, I VASTLY prefer to do my debugging in Forth 15:18:03 hey could you use a .equ file with every register in your MCU ready for gasm ? 15:18:34 it's this format ( this is for a GD32VF103 risc-v chip) 15:18:37 .equ ADC0_BASE, 0x40012400 @ (Analog to digital converter) 15:18:38 .equ ADC0_STAT, ADC0_BASE + 0x0 @ (status register) 15:18:38 .equ ADC0_STRC_Shift, 4 @ bitWidth 1 (Start flag of regular channel group) 15:18:38 .equ ADC0_STIC_Shift, 3 @ bitWidth 1 (Start flag of inserted channel group) 15:18:38 .equ ADC0_EOIC_Shift, 2 @ bitWidth 1 (End of inserted group conversion flag) 15:18:38 .equ ADC0_EOC_Shift, 1 @ bitWidth 1 (End of group conversion flag) 15:18:43 .equ ADC0_WDE_Shift, 0 @ bitWidth 1 (Analog watchdog event flag) 15:19:39 I could use something like that 15:19:43 and being CMSIS-SVD derived all names are CMSIS compliant 15:20:06 ill make it up and put it on my web site shortly 15:25:05 thanks 15:26:13 I'm frustrated by this, because there seems to be bugs in my dictionary code w.r.t. code compiled to flash 15:26:19 but I can't debug them 15:26:31 because right now it's just freezing 15:26:35 and I cannot attach gdb 15:28:10 do you have enough Forth to start simple debugging ? 15:28:44 I had to hack in a change so that you could still see RAM words while in compile-to-flash mode if not actually compiling 15:29:03 because it was breaking my flash dictionary but not my RAM dictionary 15:29:33 I'd get my memory reading words finished then use Forth to debug 15:29:49 but now it's just hanging 15:30:05 waiting for something ? 15:30:22 again, Forth can deal with stuff like that 15:30:36 it can print out right up until it hangs 15:33:20 back 15:33:25 I think it's just segfaulting 15:33:43 I think I'm making progress though 15:34:59 i think it will be like this for a long time yet 15:35:22 assembly is the hardest by far, youre going to learn heaps! 15:36:47 tabemann, https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/svd2forth-STM32L4x6.tar.gz 15:36:53 thats got everything 15:37:47 "make everything" rebuilds from scratch 15:38:30 thanks! 15:38:43 if you want selected registers in the *.fs files just edit out what you dont want in template.xml and run 'make everything' 15:39:30 the equ file isnt affected by that and the full file is produced each time because who cares, it's only a .equ ? 15:40:02 but the memmap.fs is usually loaded into the flash, and in the case of this cpu, thats a LOT of words 15:40:44 not to mention that there is never a reason to load support for *every* peripheral as they cant all be used at once anyway 15:41:10 the readme explains it all I hope 15:42:09 gotcha 15:42:43 yours probably has room, and hey if youre not using it for anything else, who cares ? 15:43:32 but my 64kB STM32F051's only fit about 1/3 of all the registers for development 15:44:02 plus I include register pretty print words which take up a lot of flash 15:44:41 --- quit: john_cephalopoda (Remote host closed the connection) 15:44:54 --- join: john_cephalopoda joined #forth 15:45:13 okay, I figured out something, repeatedly rebooting and writing flash is corrupting something 15:45:28 stuff like this 15:45:31 Flash_CR $00000080 15:45:31 3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1| 15:45:31 1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0 15:45:31 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 15:45:37 because I reflashed and then wrote, the flash looks okay, even though it's still not working 15:46:06 eww 15:47:52 --- quit: john_cephalopoda (Client Quit) 15:55:26 okay, I've figured out that I use a freshly flashed board, it doesn't crash unless I execute the compiled word itself 15:55:48 to be expected 15:56:37 do you have a exception handler in your assy code yet ? 15:57:20 maybe loop led flashes depending on exception number ? 15:57:57 youll need all the diagnostic help you can get developing your Forth 15:58:24 oh I have an exception handler 15:58:45 but it cant tell you what exception has been triggered ? 15:59:06 I've only had support for a few exceptions, such as just "fault" 15:59:13 yeah 15:59:17 I wrote it so that I can set a hook for "fault", but it doesn't say which 15:59:36 theyre usually #3 anyway 16:00:15 or they are for me 16:11:47 --- join: X-Scale` joined #forth 16:13:28 --- quit: X-Scale (Ping timeout: 240 seconds) 16:13:30 --- nick: X-Scale` -> X-Scale 16:39:24 back 16:39:38 I'm pretty sure they're #3 for me as well 16:39:43 most faults are that way 16:39:54 well wait in this case these might be illegal instructions 16:41:06 it's best to know for sure, you could blink a led to tell them apart until your Forth is more complete ? 16:44:57 know what I'm gonna do 16:45:09 I'm gonna instrument each of my flash , words 16:45:22 good idea! 16:45:29 there should be more of it :) 16:45:34 so when compiling to flash it'll dump what it's doing 16:45:51 out the terminal ? 16:53:11 yep 16:53:29 perfect 16:54:19 I don't have a working disassembler, but it seems like what it's trying to do is correct, which means that my flash write layer is buggy (not the code that handles the immediate write, which seems correct, but rather the instructure that uses it) 16:55:01 --- quit: dave0 (Quit: dave's not here) 16:56:22 layer ? 16:56:30 you have layers in assembly ? 17:00:38 well yes 17:01:03 I have a layer which interacts with the physical hardware that does the flash writes and erases 17:01:46 then I have another layer which abstracts that away, so one can do "stores" to individual bytes, halfwords, and words in flash, and it will actually tell the other layer to do the write once a block is complete 17:01:55 aha 17:02:02 or the user just tells it to flush all the changes that have been made 17:02:22 the second layer is where I think the problem lies 17:04:26 because when I test with the first layer, it works correctly 17:05:18 I'm gonna head off to the coffee shop, so I'll bbiab 17:05:25 no problemo 17:10:06 --- quit: tabemann (Ping timeout: 256 seconds) 17:31:14 --- join: jedb_ joined #forth 17:33:45 --- quit: jedb (Ping timeout: 258 seconds) 17:37:06 --- join: tabemann joined #forth 17:42:09 --- join: jedb__ joined #forth 17:44:35 --- nick: jedb__ -> jedb 17:45:11 --- quit: jedb_ (Ping timeout: 265 seconds) 17:55:26 --- quit: jedb (Ping timeout: 256 seconds) 17:56:54 --- join: jedb joined #forth 18:12:09 YES 18:12:14 compiling to flash now works 18:12:28 including after rebooting and running the code again 18:21:21 --- join: boru` joined #forth 18:21:24 --- quit: boru (Disconnected by services) 18:21:27 --- nick: boru` -> boru 18:28:37 I'm really happy about the progress I have made 19:01:04 --- quit: tabemann (Ping timeout: 265 seconds) 19:01:56 me too 19:23:34 --- quit: dddddd (Read error: Connection reset by peer) 19:35:43 --- join: jsoft joined #forth 19:40:32 --- join: tabemann joined #forth 19:40:42 --- part: tabemann left #forth 19:41:11 --- join: tabemann joined #forth 20:04:15 --- join: gravicappa joined #forth 20:17:22 --- join: rdrop-exit joined #forth 20:31:31 hey 20:31:43 hi tabemann! 20:31:55 I got compiling to flash working! 20:32:05 woohoo :) 20:32:23 now the big one is getting CREATE and which'll be a terrible pain in the ass 20:32:54 --- quit: proteus-guy (Ping timeout: 260 seconds) 20:32:59 especially since with CREATE and compiling to flash 20:33:27 I'm almost considering disabling CREATE with flash compilation, and requiring the user to use for it 20:34:38 I never use DOES> or I find them unecessary and they result in bad factoring IMO 20:41:06 okay, I'm gonna hit the sack 20:41:09 g'night 20:41:21 sweet dreams 20:41:30 nighto tabemann 20:41:46 hey rdrop-exit, the Zen Guru of Forth! 20:42:02 hi Forth Master Technician (tm)! :) 20:42:52 rdrop-exit, I thought more about your comments and made a change to my svd2forth, that while produces the same binary code, reads better i think 20:43:05 cool 20:43:31 here is a example 20:43:34 6 bit I2C1_CR1 \ I2C1_CR1_TCIE, Transfer Complete interrupt enable 20:43:34 7 bit I2C1_CR1 \ I2C1_CR1_ERRIE, Error interrupts enable 20:43:34 : I2C1_CR1_DNF ( %XXXX -- ) 8 lshift I2C1_CR1 ; \ I2C1_CR1_DNF, Digital noise filter 20:43:34 12 bit I2C1_CR1 \ I2C1_CR1_ANFOFF, Analog noise filter OFF 20:43:34 13 bit I2C1_CR1 \ I2C1_CR1_SWRST, Software reset 20:43:54 a autonamed Word in a field of one bit configs 20:44:29 the autonaming is cmsis-svd 20:44:50 and the Word "bit" 20:44:56 how come I2C1_CR1_TCIE is a comment? 20:45:14 : bit ( u -- u ) 1 swap lshift 1-foldable ; 20:45:27 6 bit I2C1_CR1 constant I2C1_CR1_TCIE 20:46:23 the comments are all taken from the cmsis-svd 'description' field 20:47:11 these are templates anyway, one modifies them as required in practice 20:47:34 is I2C1_CR1 an address? 20:47:56 yes, they all are 20:48:44 one of my versions used the hex address instead of the constants above but sadly it's buggy and I havent fixed it yet 20:49:11 but the constants have their own appeal when it comes to readability 20:49:33 one can just search the STM technical ref on the name and find the bitfield etc 20:49:50 but that cant be done with the hex address method 20:49:55 their naming convention is ugly 20:52:07 my definition is the same for bit, except the 1-foldable which I guess is specific to your forth's optimizer 20:52:48 : bit ( bit# -- bit ) 2** ;inline 20:54:09 : bits ( hibit# lobit# -- mask ) 20:54:09 tuck - bit 2* mask swap lshift ; 20:55:15 yeah perhaps, the bit word isnt mine 20:55:49 I have a few other utility words like that 20:55:52 their naming convention is a massive task, with some M7 cpus having 17,000 bitfields plus 20:56:21 But I assume you're not using all of them 20:56:22 they also have some naming clashes in the SVD 20:56:30 no way ;) 20:56:41 but I stull autogenerate all the above for them 20:57:03 : mask ( bit -- mask ) 1- ;inline 20:57:12 : ~mask ( bit -- ~mask ) negate ;inline 20:57:20 my svd2forth works on all the STM cortex mcus and a lot of other makes with some small changes 20:57:30 nice! 20:57:45 3 bit mask %. 20:57:51 give you "111" 20:58:03 3 bit ~mask %. 20:58:03 it's a massive logistics job designing these complex cortex-m's and all the naming and documentation 20:58:24 gives you "11..11000" 20:58:26 I love Forth tool making also 20:58:33 bbs, lunch is up! 20:58:41 bon appetit! 21:16:38 vestas, "R> DROP EXIT" aka "RDROP EXIT" aka "BAIL;" and variations thereof have quite a few uses, most of them rely on the internals of the specific Forth 21:17:29 2000 calories later .... 21:17:42 that was fast 21:17:56 I'm a slow eater too 21:18:07 was just some fish and vegies 21:20:30 vestas, one example is when your Forth uses the top of the return stack for backward branches 21:23:27 breaking out of the loop and exiting the definition could be implemented by dropping the TOR and exiting 21:31:51 vestas, most techniques having to do with the return stack are fairly subtle and specific to the implementation 21:32:39 when buying any Chinese electronics, consider this comment by a Chinese engineer I have been debating with: 21:32:53 Part numbers are not generally considered trademarks here. If I produce a transistor that adheres to all 2n3904 specifications, I can sell it as a 2n3904, even if some characteristics not on the datasheet are a bit different. Similarly if I make a chip that functions just like a STM32 and runs most code unmodified (except maybe for very few corner cases), it's generally considered a-ok to sell it as a STM32. The generics mindset here is strong, and it's 21:32:53 not considered ok for one manufacturer to monopolize a part number, especially when compatible substitutes are produced. "STM32" is a generic name for a MCU with these peripherals in this layout, just like U.FL is a generic name for a connector with these dimensions. If that's a problem for you just buy from the big distributors. 21:34:59 As with anything, whether from China or elsewhere, caveat emptor always applies. 21:35:08 of course 21:35:28 but when buying from a reputable vendor there is less risk 21:35:45 when buying from China, the above attitude applies 21:36:17