00:00:00 --- log: started forth/20.05.24 00:01:30 There are really only two advanced topics in Forth, metacompilation and cross-compilation. 00:06:47 The book I mentioned earlier is Interpretation and Instruction *Path* Coprocessing 00:25:29 bbl 00:41:02 --- quit: rdrop-exit (Ping timeout: 256 seconds) 00:46:16 MrMobius: I don't know why people think this, I think it's because the C64 etc had better video modes so you got much faster graphics, even though the CPU was slower. But the CPU is definitely slower, in all profiling I've done where I've just implemented the 'same' stuff on each. 00:46:43 C64 had 1MHz 6502 if I remember rightly 00:47:03 I'm unsure because I was comparing with the Oric Atmos at the time, which does have a 1MHz 6502 00:47:36 BBC Micro had 2MHz 6502 which is more comparable, it's faster at some things and slower at others 00:48:41 So for raw CPU performance the 6502 acts a bit closer to 2* as fast for the same clock speed 00:49:49 --- join: xyh joined #forth 00:50:16 --- quit: xyh (Remote host closed the connection) 00:52:54 And don't get me started on the machine code's verbosity, a 64K 6502 machine is a bit like having a 32K Z80 machine, if you write it all in machine code. 01:02:45 --- join: rdrop-exit joined #forth 01:43:55 --- join: gravicappa joined #forth 01:44:55 rdrop-exit: Do you consider abstract computer science data structures to be a non-forth bias? 01:50:34 --- quit: iyzsong (Ping timeout: 260 seconds) 01:55:20 --- quit: reepca (Remote host closed the connection) 01:55:33 --- join: reepca joined #forth 01:57:27 --- join: iyzsong joined #forth 01:58:27 --- quit: reepca (Remote host closed the connection) 01:58:37 --- join: reepca joined #forth 02:03:42 I don't understand the question, algorithms and data structures in and of themselves aren't biases, they're mathematical+engineering tools. I guess one may have biases that affect which one is selected or how it is implemented. 02:04:17 --- quit: reepca (Ping timeout: 246 seconds) 02:05:20 rdrop-exit, I took your advice a little while ago "rdrop-exit> For any word that confuses you, look at its source, then look at its object code (or intermedate code)" and immediately understood what the words were supposed to do :) 02:05:41 Cool tp! :) 02:06:21 after disassembling the words ( bit@ cbit@ and hbit@ ) I realised their differences 02:06:37 Id been trying all kinds of tests and was very confused 02:07:28 of course after looking at the assembley code it's all too obvious 02:07:46 Forth is very concrete :) 02:08:43 I had never used cbit@ or hbit@ before, as bit@ was all I needed to test a bit 02:09:32 I'm writing a doc page on them, so had to find out what they actually are supposed to do 02:10:30 basically they all test a single bit, but they either fetch a cell, halfword or byte to do it 02:10:55 I figured as much 02:12:30 oddly Ive never looked at the assembly before in cases like this 02:12:43 id just try a number of tests or email the author 02:13:04 I normally would just use 8@ 16@ 32@ or @ and then isolate the bit(s) I need, although if your CPU has some amount of bit addressable memory it makes sense to combine the fetch and isolation in single primitive 02:13:42 I remember reading somewhere that ARM's had "bit banding" which amounts to the same thing 02:14:09 the cortex-m0 which I use doesnt have bit banding 02:14:10 (sorry I meant b@ not 8@) 02:14:48 LDR, LDRB and LDRH instructions load the register specified by Rt with either a word, byte 02:14:48 or halfword data value from memory. Sizes less than word are zero extended to 32-bits 02:14:48 before being written to the register specified by Rt. 02:15:13 so thats the difference with those thre bit test words 02:16:26 masked memory write primitives are more common than masked memory read primitives 02:17:31 perhaps not in my embedded work 02:18:03 e.g. I have %16! ( x mask a -- ) which would end up being a RMW on most CPUs 02:18:25 because the MCU has special registers that set or clear bits without requiring a mask 02:18:36 the register has no read ability 02:18:37 also %b! %32! %! 02:19:27 time has moved on since you last programmed eniac 02:19:28 right, in such cases you can use the regular store primitives, no need to pull out the masked ones 02:19:30 ;-) 02:19:37 exactly 02:19:48 --- quit: crest (Ping timeout: 265 seconds) 02:21:25 here is a masked write using the "bis!" Word 02:21:27 : GPIOB_BSRR_BS0-bis! 0 bit GPIOB_BSRR bis! ; ok. 02:21:28 see GPIOB_BSRR_BS0-bis! 02:21:28 200003A6: F640 movw r0 #0C00 02:21:28 200003A8: 4000 02:21:28 200003AA: F2C4 movt r0 #4001 02:21:29 200003AC: 0001 02:21:30 200003AE: 6903 ldr r3 [ r0 #10 ] 02:21:32 200003B0: F053 orrs r3 r3 #1 02:21:34 200003B2: 0301 02:21:36 200003B4: 6103 str r3 [ r0 #10 ] 02:21:38 200003B6: 4770 bx lr 02:21:40 Bytes: 18 ok. 02:22:15 ironically I used this for ages to write to the "BSRR" register not realising it needs no mask 02:22:35 when I did wake up and use a write, I saved 4 bytes 02:23:34 : GPIOB_BSRR_BS0! 0 bit GPIOB_BSRR ! ; ok. 02:23:35 see GPIOB_BSRR_BS0! 02:23:35 200003E2: F640 movw r0 #0C00 02:23:35 200003E4: 4000 02:23:35 200003E6: F2C4 movt r0 #4001 02:23:35 200003E8: 0001 02:23:37 200003EA: 2301 movs r3 #1 02:23:39 200003EC: 6103 str r3 [ r0 #10 ] 02:23:41 200003EE: 4770 bx lr 02:23:43 Bytes: 14 ok. 02:23:54 yes, if the CPU has special RMW capabilities, one should take advantage of them when applicable 02:24:33 yeah, even if one just uses the mask word without thinking 02:24:38 02:25:02 Forth is all about "thoughtful" programming ;) 02:25:54 I dont believe the MCU reads and masks in the case of the BSRR register, it just ignores all zeroes written to the register perhaps ? 02:26:29 the only registers with this facility control the GPIO port bits 02:27:47 I assume so, it basically gives you a way to avoid RMW in your code in certain specific circumstances 02:28:08 for any other register one has to mask first, even if Mecrisp-Stellaris does that with the "bis!" or "bic!" Words 02:28:19 yeah, and it makes good sense 02:28:32 which is always a good thing, and should be leveraged when and where available 02:29:02 Im not sure why we have bit@ cbit@ and hbit@, perhaps a byte read is faster than a halfword or cell ? 02:30:39 i wonder if alingment has anything to do with it ? 02:30:42 Address alignment 02:30:42 An aligned access is an operation where a word-aligned address is used for a word, or 02:30:42 multiple word access, or where a halfword-aligned address is used for a halfword access. 02:30:42 Byte accesses are always aligned. 02:30:42 There is no support for unaligned accesses on the Cortex-M0 processor. Any attempt to 02:30:43 perform an unaligned memory access operation results in a HardFault exception. 02:33:00 I guess, although since those operators deal only with a single bit, the single-byte version would seem sufficient for all needs. 02:33:59 not if the bit in question is say bit 32 and well outside the range of a byte ? 02:34:50 the byte only deals with bits 1 -8 02:35:13 sure but then you fetch the byte that has the bit in question 02:35:43 hmm, I dont know how to do that with cortex-m0 02:36:33 I know how to save 4 bytes into a cell using a offset 02:36:51 I guess the reverse applie 02:36:53 s 02:36:58 unless you're determining which byte at runtime, the single byte one would seem sufficient, but on some architectures it would be slower 02:37:34 I'm sure he has a perfectly valid reason for having the different variations, I'm just not familiar with ARM 02:38:17 I'm guessing one may read an array of bytes and then test the bit in a byte, but the bit@ requires as parameters, a bit position and an address 02:39:06 Im sure the author does, hopefullI may discern the reason within a decade after he designs it ;-) 02:39:11 probably has to do with alignment making the other versions faster when applicable like you said 02:39:49 I have read that alignment operations can be very expensive on cpus that offer it 02:40:09 which the cortex-m0 does not (auto alignment) 02:40:26 These might also be words he's used to having in his Forths regardless of CPU 02:40:30 only the more complex mcus have it such as the cortex-m4 etc 02:40:56 another good theory! 02:41:20 he loves the MSP430 by Ti and wrote that first. ARM was a later 'port' 02:41:25 This is why my VARIABLE takes a size/alignment parameter in my Forths 02:41:37 byte variable thingy 02:41:51 and then you add whatever mcu black magic is needed later ? 02:42:00 32-bit variable doodad 02:42:02 depending on whats being used ? 02:42:09 cell variable a-nice-cell 02:42:44 well I have a better idea of why the extra bit@ words may exist now 02:43:16 my variable pads the start address so that the variable ends up size aligned on a natural power-of-2 boundary 02:43:30 rdrop-exit, are you aware that the RISC-V mcus have a inbuilt cycle counter ? 02:43:38 yes 02:44:17 rdrop-exit, yes, thats required with cortex-mo unless one likes 'hard faults' 02:45:04 some people recently used that cycle timer to try and determine the start up of the MSU 02:45:17 the RISC-V Debug Module spec has a veritable smorgasbord of capabilities (if the particular implementation implements all the options) 02:45:56 the longan-nano board uses the GD32VF103 mcu, and like most Chinese chips is short on specifics 02:46:40 one of those specifics is the fact that the chip has 128KB flash chip glued on the die of the MCU 02:47:15 and that the flash chip downloads it's data into 128KB of RAM on the chip at power up 02:48:10 this makes the chip faster than a alternate using flash at bootup, but also makes it slower to boot as it downloads the dat from flash into r`am 02:48:47 so some people used the RISC-V timer to try and find out whats happening 02:49:47 the RISC-V specs leave so much up to the implementation, complete documentation from the vendor is critical to figure out which options are actually implemented 02:50:40 true 02:50:51 In some cases I think the spec leaves too much up to the discretion of the chip vendor 02:51:09 perhaps Chinese users get the full doc in Mandarin ? 02:51:27 Kinda like the ANS Forth spec 02:51:29 but the english doc is woeful 02:51:57 could be 02:52:30 I like things to be pinned down more 02:52:39 it looks like the doc for their STM32F103 clone was used as a template and they havent rewritten important parts yet 02:52:54 perhaps it will evenyually 02:52:59 bah humbug 02:53:05 no ? 02:53:46 I'm sure you're right, I'm just expressing my disgust 02:53:52 currently the doc claims the same peripheral reset method as the STM32VF103, except it's not as shown by GD's own demo software 02:54:47 I have been spoilt by the STMicro doc that eveyone hated until they started trying to read the Chinese doc 02:55:16 the STMicro doc is a work of high class literature in comparison 02:55:39 :) 03:28:18 --- join: dddddd joined #forth 03:46:30 --- quit: jedb (Remote host closed the connection) 03:46:44 --- join: jedb joined #forth 03:49:36 --- join: proteus-guy joined #forth 03:52:30 --- quit: jedb (Ping timeout: 256 seconds) 03:54:28 --- join: jedb joined #forth 04:27:08 --- quit: dave0 (Quit: dave's not here) 05:04:47 --- quit: jsoft (Ping timeout: 264 seconds) 05:55:42 --- quit: rdrop-exit (Quit: Lost terminal) 06:17:57 --- quit: rann (Ping timeout: 272 seconds) 06:19:16 --- quit: ovf (Ping timeout: 240 seconds) 06:20:36 --- join: dys joined #forth 06:24:46 --- join: ovf joined #forth 06:31:04 --- quit: ovf (Max SendQ exceeded) 06:31:20 --- join: rann joined #forth 06:34:16 --- join: ovf joined #forth 06:45:14 --- join: X-Scale` joined #forth 06:46:10 --- quit: X-Scale (Ping timeout: 272 seconds) 06:46:10 --- nick: X-Scale` -> X-Scale 07:08:20 --- quit: gravicappa (Ping timeout: 272 seconds) 07:08:49 --- join: gravicappa joined #forth 07:14:34 --- quit: iyzsong (Ping timeout: 260 seconds) 08:20:56 --- quit: dddddd (Ping timeout: 240 seconds) 08:34:22 --- join: TCZ joined #forth 08:54:37 --- quit: TCZ (Quit: Leaving) 09:52:47 --- quit: X-Scale (Ping timeout: 264 seconds) 09:54:09 --- join: X-Scale` joined #forth 09:54:50 --- nick: X-Scale` -> X-Scale 10:33:16 --- join: xek joined #forth 10:41:44 --- quit: xek (Quit: Leaving) 10:48:56 --- join: antaoiseach joined #forth 10:54:27 --- join: xek joined #forth 10:55:59 --- part: antaoiseach left #forth 11:12:41 --- quit: gravicappa (Ping timeout: 260 seconds) 12:11:09 --- quit: lonjil (Quit: Quit.) 12:34:32 --- join: dddddd joined #forth 12:35:37 --- join: lonjil joined #forth 12:38:02 --- quit: lonjil (Client Quit) 12:46:02 --- join: lonjil joined #forth 12:46:31 --- quit: lonjil (Client Quit) 12:46:44 --- join: lonjil joined #forth 12:54:16 --- quit: lonjil (Quit: Quit.) 12:54:26 --- join: lonjil joined #forth 12:57:18 --- quit: dys (Ping timeout: 272 seconds) 13:37:02 --- join: TCZ joined #forth 13:47:45 --- join: reepca joined #forth 14:00:28 --- quit: C-Keen (Quit: WeeChat 2.6) 14:07:11 --- quit: xek (Ping timeout: 264 seconds) 15:13:08 --- quit: Zarutian_HTC| (Read error: Connection reset by peer) 15:13:34 --- join: Zarutian_HTC joined #forth 15:24:09 --- quit: andrei-n (Quit: Leaving) 15:24:16 --- join: C-Keen joined #forth 15:27:29 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 15:34:44 --- quit: TCZ (Quit: Leaving) 15:45:53 --- join: Zarutian_HTC joined #forth 16:32:02 --- quit: reepca (Read error: Connection reset by peer) 16:32:31 --- join: reepca joined #forth 16:40:25 --- quit: cantstanya (Ping timeout: 240 seconds) 16:46:06 --- join: cantstanya joined #forth 16:51:14 --- join: TCZ joined #forth 16:54:12 --- quit: TCZ (Client Quit) 18:18:07 --- join: boru` joined #forth 18:18:10 --- quit: boru (Disconnected by services) 18:18:13 --- nick: boru` -> boru 18:31:51 --- join: rdrop-exit joined #forth 18:46:46 hey guys 18:48:09 I got the second part of the test framework for zeptoforth implemented 18:49:17 tabemann, great, I've almost finished by bit@ test doc page 18:51:25 cool 18:51:44 check out this lovely embedded c code 18:51:47 #include "SmartcontrolOS.h" 18:51:47 #include "Apps.h" 18:51:48 #include "CMSIS.h" 18:51:56 DO__write_open_drain(_,PA4,1); 18:51:56 DO__write_open_drain(_,PA4,0); 18:51:56 Scheduler__wait(_,10*ms); 18:51:56 DO__write_open_drain(_,PA4,1); 18:51:56 Scheduler__wait(_,40*us); 18:51:57 DI__read(_,PA4); 18:52:14 oh my 18:53:00 wait, where's the function definition? 18:53:13 and people think embedded C is straightforward, easy to read ? 18:53:14 I just see #include and then code, no foo (void) { 18:53:32 there is more, this is just the first bit 18:53:52 but it's all the includes ... and is a first time C user 18:54:30 using CodeBlocks ... opps NOT a first time C user 18:55:54 I see this stuff everywhere I look, the state of C embedded is a mess in the hobby community 18:56:26 well coding zeptoforth to do the same thing is non-trivial either; you have to essentially have the CMSIS or equivalent available, and need to have access to the proper datasheet to know how to use said registers 18:56:54 tabemann, that may change after I add RTS handshaking :) 18:57:05 :D 18:57:11 which I start soon as the bit@ page is nearly done 18:57:47 --- join: crest joined #forth 18:57:52 onve I have RTS I can make a binary which includes all the memory maps, and also include a bitfield template in the release tarball 18:58:18 tabemann, after that, it's quite easy to do hardware config 18:58:55 tabemann, youre a Emacs user iirc, I'm assuming you can easily paste lines from open buffers into a source file ? 18:59:06 yes 18:59:36 because I imagine that the full CMSIS will be quite large 18:59:39 tabemann, for instance, my project manager opens a number of files, including the memmap.fs and the bitfield.fs for the MCU I'm using in the project 19:00:31 this means it's dead easy to then add hardware config as bitfields.fs contains a hardware summary of every bitfield 19:01:26 tabemann, the full CMSIS-SVD for the F4 is large, but I transform it into the memmap.fs and bitfields.fs files 19:01:54 theyre transformed into Forth words etc 19:02:25 in the same way that the C compiler makers use CMSIS-SVD to make their header and include files 19:02:39 as do the RUST people 19:02:50 I figured as much 19:03:00 it makes sense, and makes it easy 19:03:41 some people dont like CMSIS-SVD but I think it's fantastic. I wouldnt be using Forth in embedded without it 19:04:22 the tyrany of bitfields makes forth simply utterly impossible to use otherwise 19:07:08 well in the code I've copied from Mecrisp-Stellaris, in many places they just use hardcoded values to represent multiple bits that are set or unset 19:07:57 Forth is fine for say a 6502 with 10 registers or so, but for a cortex-m4 with 722 registers ... forget it 19:08:17 oops, thats for a M3 ! 19:08:25 lol, the old stm32f103 19:09:18 tabemann, yeah, the assembly in Mecrisp-Stellaris is particulary hard to grok because matthias uses his own syntax as he makes it up on the fly 19:09:46 it's always *partially* correct, but almost never fully correct 19:11:32 for instance, a complete, non ambiguous CMSIS-SVD name is very long and programmers just have an adversion to them 19:11:38 I highly suspect my code is the same 19:12:16 everyone is the same, except me 19:13:01 I noticed early on that there are name clashes in the STM32 CMSIS-SVD xml files 19:13:22 and? 19:13:37 except where the complete 'peripheral_register_bitfield" nomenclature is used 19:14:09 well, name clashes mean probable bugs later on 19:15:06 it's probably not fair to be too hard hon STMicro as some of their micros have over 17,000 bitfields 19:15:19 thats a lot of names to invent and maintain 19:20:37 "I reminded myself a little bit of how people write C code [...] 19:20:38 There were a lot of programmable options that they had to test for. There were a lot of bits you might want to set or not set in a control word. And they had long names for those bits and they would smush them together and put them in a control word. I don't do things that way. To me it's an oxymoron. Those long names don't mean anything to me. I had to find a place in the documentation to find out what 19:20:43 that long name meant, what the consequences of setting it or not setting it in order to understand what was going on. 19:20:46 Now having gone to all that work I can just set that bit in a hex word. I don't need the names and the conditions. I only have to do it once in one context." -- Chuck Moore 19:21:38 good morning Forthies c[] :) 19:21:45 hey rdrop-exit 19:22:17 g'day rdrop-exit 19:23:20 to me it's easier to remember what you were doing after the fact with a name rather than just remember what some random hex meant later on 19:23:51 like in the code I borrowed from Mecrisp-Stellaris that just specifies random hex - wtf does that all mean? 19:24:21 tabemann, exactly 19:24:23 whereas if it were with CMSIS labels, I could always look them up in the data sheet 19:24:29 sure, I'm sure chuck names and documents the word were he specifies that hex value 19:25:14 tabemann, same here. Embedded code written by programmers is usually impossible to understand 19:25:27 he's just not making a name for each possible hex value 19:26:15 sure the Forth code is easy to understand as youd expect, but there is no way to understand what it does without spending a lot of time reading the data sheets 19:26:51 he's setting the hex value to suit his requirements within a particular context 19:26:51 and doing that on a bitfield by bitfield basis is massively time consuning 19:28:38 and lets remember, chicks code was in the early days when MCU's had no peripherals on board 19:28:41 Chuck 19:29:34 for that he finds the "smushed names" that C programmers use next to useless, since he has to go back to the docs anyway to figure what it all means and what the subtle implications are, that seems especially applicable with todays chips 19:29:56 that's why we should be using full names 19:29:57 oh yeah, C progrmmers are terrible in that regard 19:31:05 I hate C code examples for embedded code 19:31:23 like I remember trying to look up how to enable some interrupt 19:31:49 tabemann, I agree, of course thats in the early config stage when the full and correct hardware naming is critical. Later all that stuff becomes 'on fill wash drain spin off" etc and who cares 19:32:04 yes, Chuck is certainly allergic to such C programmer ways and doesn't use them with Forth 19:32:14 tabemann, yeah, it's incredibly frustrating 19:32:21 and all the examples I found just pointed you at some random library 19:32:27 hence my C rants 19:32:31 and I wanted to know which exact registers to set 19:32:39 not to use library foo.c 19:32:57 tp: have you ever implemented auto baudrate detection for stm32? 19:33:26 sadly there are very few Forth examples for cortex-m except in the Mecrisp-Stellaris user contributions and prior to svd2forth they all had to make up their own naming 19:33:32 crest, yes 19:34:19 tabemann, I was *gobsmacked* recently when I looked at a new user contribution, he used the full cmsis-svd naming as provided by svd2forth! 19:34:25 even for chips without hardware support for it? 19:34:33 to get anything done with Cortex-M peripherals I found myself having to constantly go back to the datasheet 19:34:38 tabemann, so it is happening slowly 19:35:12 cool 19:35:13 tabemann, thats right, it's either svd2forth or the datasheet, and when learning the datasheet is inevitable anyway 19:35:16 .oO( tab completion in mecrisp would be really nice to have ) 19:35:41 crest, no, I only use the stmn32f051 so the autobaud rate was with that 19:36:23 an other reason to pick the "right" chip 19:36:28 crest, of course, the bluepill board using the ancient stm32f103 has no autobaud. This comes from being a 14 year old design 19:36:34 I've implemented tab completion in other Forths of mine, but I have deliberately left it out of zeptoforth because I expect someone will be using something like e4thcom which won't permit it anyways 19:37:00 i find autobaud a waste of time for development 19:37:20 I haven't bothered with autobaud with zeptoforth 19:38:09 i wanted to write a word to change the clock rate without locking myself out and usb<->serial adapter are often limited to a few baud rates 19:38:31 crest, tab completion in Mecrisp-Stellaris would take up too much rom, matthias wouldnt allow it 19:39:23 shouldn't be too bad unless you want to convert the dictionary to a prefix tree 19:40:36 but it would require some sort of line double buffering 19:41:30 crest, I think all that could be done in a IDE outside the mcu anyway 19:41:55 i want it for interactive use as well 19:42:10 but a proper ide should do more than just tab completion 19:42:14 to me at least I wouldn't implement autocomplete except with a full line editor.... but a full line editor would be way too big and complex to implement 19:42:19 frankly I know all the Forth words so well I dont need completion, which I have in my editor and dont use 19:42:31 I've never cared for auto-complete 19:43:09 I use open buffer full line paste all the time tho 19:43:29 i really have to look into vim completion support 19:43:45 tp: i have an other idea i want to run past you 19:44:14 the reason is that lines like this are too big to type or remember ": USART1_ISR_BUSY? ( -- 1|0 ) 16 bit USART1_ISR bit@ ; \ USART1_ISR_BUSY, Busy flag" 19:44:18 now that I think of it, what I could implement is a lookup word, that essentially does completion to look up words, but without involving a line editor 19:44:25 how do you think about some words to implement word sized bit fields as pair of value and mask? 19:46:10 that's how it's typically done 19:46:59 especially with a peephole optimizing Forth that can eliminate needles shifts 19:47:03 crest, sounds ok to me 19:47:53 bitfield ( x mask -- bits ) 19:48:27 bitfield Extract a bitfield. 19:48:28 When is a literal |bitfield| optimizes down to 19:48:28 an |and| followed by a right shift (if needed). 19:51:33 crest, can I use your recent C "ok-waiter" file uploader app as a example for picocom in my online doc ? 19:52:00 I have another to add to it written in python 19:52:09 sure but it requires a small change to mecrisp that i haven't documented yet 19:52:26 i piggy backed on the color support 19:52:26 oh ? I havent had a chance to try it yet 19:52:52 crest, and why not ? :) 19:53:17 because i wrote it between 1am to 3am local time? 19:53:29 crest, if you do finish it, can you paste it somewhere with your license etc ? 19:53:50 i want to clean it up and use less system calls 19:54:05 ok, I'll wait until you let me know 19:54:06 right now it uses single byte write()/read() 19:54:13 the more features you add to your PC client the more it makes sense to just use a PC Forth as your client 19:54:27 the code is already on github: https://github.com/Crest/upload 19:54:34 rdrop-exit, what are you smoking today ? 19:54:42 Winston Lights 19:54:44 rdrop-exit, can I have some please ? 19:54:48 eww 19:54:57 no I mean mind altering drugs 19:55:48 aka i don't provide any warrenty, please keep the license header but otherwise do what you want 19:56:41 crest, I'll just provide your the url 19:56:47 -your 19:57:07 people can go there to check it out 19:57:18 the code is just ugly at the moment but works because of the struct FILE buffering 19:57:24 I think it's a natural evolution, at some point if you keep adding features to the PC side of your development environment, you might as well use a PC Forth as your client 19:58:03 rdrop-exit, thats fine 1) if you make your own forth, 2) if you want to depend on a PC 19:58:30 back 19:58:30 rdrop-exit: a tethered forth has different tradeoffs 19:58:58 sure your host has plenty of cpu cycles and memory for fancy tricks 19:59:14 rdrop-exit, I have to disagree with you that a tethered Forth is the answer to all problems 19:59:28 but how do you keep the compiler extensible? 19:59:34 personally I love tethered forths, but they all have their pros and cons 20:00:56 * crest should finally receive 10 buck converters today 20:01:19 to me at least, tethered forths tie you to a particular PC Forth, whereas hosted forths allow you to use any terminal sofware you like 20:01:30 usb isn't designed to power stepper motors etc. 20:01:46 tp, I didn't say it was 20:01:47 I assume you've seen fans powered by USB 20:03:04 sure 20:03:19 but i have received serveral over power warnings from my host 20:03:31 and macos just disables the usb port for a few seconds if that happens 20:03:35 tabemann, sure if your PC development environment is simply a generic terminal, then you are truly thin client, but once it ends up relying on a bunch of scripts and other tools, then it's not so thin anyhow, might as well consolidate 20:07:15 my PC development environment is either e4thcom or codeload3.py (thanks to Thomas, the STM8EF guy) combined with st-flash, a build script or two, and so on, but as a whole the functionality is not tied to the PC - e.g. zeptoforth is perfectly happy communicating with screen, even though e4thcom is more user-friendly IMHO 20:08:29 (codeload3.ppy being a port of codeload.py to Python 3, combined with changes to make it tolerant of the MCU rebooting mid-load) 20:08:38 *py 20:11:31 Sure, the same thing can apply with Forth instead of Python and your various other scripts, you can still have a target Forth that can be perfectly happy just communicating with screen when you don't need the rest of your client tools 20:12:38 one does not preclude the other 20:12:46 in my case I use Forth hosted on the mcu to do real time development on various hardware that isnt anywhere near my mc 20:12:59 there is no alternative for that 20:13:15 As I said, one does not preclude the other 20:14:56 crest, you may have to get a PSU at some point ? 20:17:00 tp: i have bench power supplies at the local hackerspace :-( 20:17:51 crest, that doesnt help you working at home unless you have some really long wires ? 20:18:07 your normal units with 0-30V, 0-3A adjustable voltage and current limit 20:18:15 tp: exactly 20:18:35 0-30 is a bit high for working with bluepills 20:18:49 it's a great way to burn them out 20:18:50 they have different knobs for fine and coarse adjustment 20:19:07 and display the target limits without load 20:20:23 so i can adjust them to 3,4 or 5,1v and a sane current limit that should prevent damages from user error 20:22:59 thats pretty common for most cheap Chinese gear 20:23:28 the expensive stuff has a keypad for voltage and current settings 20:23:43 mine are all analog 20:34:56 --- quit: dddddd (Ping timeout: 258 seconds) 20:36:59 tp: i added the patch to https://github.com/Crest/upload 20:37:08 https://github.com/Crest/upload/blob/master/mecrisp-upload.patch 20:39:08 so far i only tested the color version of this on a stm32f103-ra where it required me to bump the flash size by one 2048 byte page 20:45:09 crest, cool, I'll try it out later today after I finish my bit@ doc 20:46:03 the idea behind my uploader and the patch is to ack each line processed by including a ascii ack byte in the "ok. " string literal 20:46:19 and a negative ack byte in all error messages 20:46:39 oh, you need a kernel patch ? 20:46:45 yes 20:46:58 ok, I'll add that in the notes 20:47:30 the patch changes a few string literals and the Fehler_Quit and Fehler_Quit_n macros 20:47:41 understand 20:47:53 I always patch them myself 20:48:24 i also added a simple change to to Redfine warnings to use yet an other control char 20:49:03 that allows the uploader to tell the user that a warning has been emitted 20:49:27 cool 20:49:36 back 20:49:59 picocom (and other terminal programs) just ignore those control chars 20:50:11 I was suprised that matthias added my colors and warnings to the kernel, it's like trying to inject blood into a stone ;-) 20:50:21 welcome back! tabemann 20:50:29 hey - I created a "lookup" word which shows all the words with the longest common prefix of the word specified 20:50:33 crest, yes, picocom is ancient 20:50:58 tabemann, that sounds interesting, I cant wait to try it 20:51:07 the patch is small, easy to maintain and doesn't increase the defaul code size at all 20:51:18 it's like "words", except it allows you to control which words you want to look for 20:51:27 it even has the four-column formatting 20:51:45 tabemann: i wrote a match word that shows all words containing a substring 20:51:58 limiting it to a prefix would be trivial 20:52:47 this searches for a prefix, but if no words perfectly have said prefix, it shows all the words with the longest common prefix any one of them matches 20:52:50 like: 20:53:16 crest, i trued that and it worked, then I tried it later and it didnt, I havent gone back to it yet 20:53:22 lookup tok 20:53:22 token-expected token token-end token-start 20:53:22 token-word 20:53:22 ok 20:53:24 but 20:53:28 crest, it was pretty cool 20:53:40 lookup foobar 20:53:40 for-gas force-disable-action force-enable-action 20:53:41 force-disable-task force-enable-task for-task 20:53:41 format-double-unsigned format-double format-integer-inner 20:53:41 format-integer format-unsigned 20:53:41 ok 20:54:04 https://gist.github.com/Crest/24a6323af108e854ba4acd36c6c5b98c 20:54:05 tabemann, have you considered renaming Zeptoforth to gforth ? ;-) 20:54:14 lolol 20:54:14 :)) 20:54:31 zforth 20:54:37 tforth 20:54:44 omega forth the last one to rule them all :-P 20:54:47 I wanted to name it zforth, but the name was already taken 20:54:49 tforth exists 20:55:01 almost every possible forth name is taken 20:55:02 scnr 20:55:07 yeah, all the names are taken in the world thesedays 20:55:10 that's just how many forths there are 20:55:21 it's the same for URL's 20:55:47 I chose zeptoforth because it's like only small SI multipler not taken as the name of a forth 20:56:09 tabemann, naming is hard anyway 20:56:16 but fun 20:56:35 it's a science I think 20:56:51 I wanted to name it with a small SI multiplier because this is meant for microcontrollers 20:57:01 it wouldn't be appropriate to name it something like megaforth 20:57:17 for programs it's important to be unique and not ambiguous, for product branding it's critical 20:57:28 zettaforth :-P 20:58:22 and all numbers have to be written as zero padded 64bit hex 20:58:46 you could do the GNU thing, e.g. FINF Is Not Forth 20:59:20 or FINC, FINC is not C 20:59:58 thats a good one! 21:00:33 I call my latest No Frills Forth 21:02:07 I'm sticking with zeptoforth because Google already associates zeptoforth with the name (i.e. first entry you see when you google it is its github) 21:02:24 cool 21:25:05 --- join: tolja joined #forth 21:25:25 --- join: jsoft joined #forth 21:50:42 tp: i just looked at the stlink lib and within a few minutes i'm able to read a 32bit word from sram without resetting the system 21:51:50 the lib is pretty easy to use: open a handle, issue a command, check the return value, get the word from a buffer stored inside the handle 22:00:01 tp: writing works the same way 22:00:48 put what you want to write in the buffer and use stm32_mem_write32 to write a multiple 4 bytes from the buffer to the memory address 22:01:39 i can change a forth variable this way (if the host knows the address) 22:12:17 --- join: antaoiseach joined #forth 22:32:37 does anyone know of a better way to use a the debugger as console than just polling a single word? 22:44:40 that would require an intimate knowledge of stlink 22:44:52 I bet there's a way though 22:45:21 because if writing to flash had to be 32 bits at a time, god it'd have to be slow, which it isn't 23:02:03 --- join: dave0 joined #forth 23:06:12 --- join: gravicappa joined #forth 23:16:01 --- join: andrei-n joined #forth 23:31:45 --- join: mtsd joined #forth 23:39:00 tabemann: i don't want to write to flash 23:39:23 i want to use a single 32bit word as serial port replacement for the forth system 23:39:43 with one byte each for rx, tx, rx_ready, tx_ready 23:39:44 --- join: va joined #forth 23:40:08 --- join: dys joined #forth 23:40:29 i guess an adeptive poll rate would be good enough 23:40:50 *adaptive 23:51:31 --- quit: antaoiseach (Quit: leaving) 23:59:59 --- log: ended forth/20.05.24