00:00:00 --- log: started forth/20.06.01 00:07:59 --- quit: dys (Ping timeout: 246 seconds) 01:10:17 --- quit: reepca (Remote host closed the connection) 01:10:29 --- join: reepca joined #forth 01:44:43 --- quit: va (Remote host closed the connection) 01:47:22 --- join: va joined #forth 03:25:33 --- join: xek joined #forth 03:33:43 --- join: dys joined #forth 03:47:29 --- join: iyzsong joined #forth 03:52:40 --- quit: xek (Ping timeout: 265 seconds) 03:55:12 --- join: xek joined #forth 04:10:01 --- join: TCZ joined #forth 04:31:09 --- join: Zarutian_HTC joined #forth 04:42:35 --- join: dddddd joined #forth 05:05:10 --- nick: TCZ -> DoomSlayer2020 05:40:51 --- quit: DoomSlayer2020 (Quit: Leaving) 07:01:17 --- quit: iyzsong (Ping timeout: 260 seconds) 07:47:09 --- join: MrMobius joined #forth 08:24:05 --- join: TCZ joined #forth 08:30:45 --- join: xek_ joined #forth 08:34:12 --- quit: xek (Ping timeout: 258 seconds) 08:46:35 --- join: X-Scale` joined #forth 08:48:26 --- quit: X-Scale (Ping timeout: 246 seconds) 08:48:27 --- nick: X-Scale` -> X-Scale 09:11:56 --- quit: Zarutian_HTC (Ping timeout: 256 seconds) 09:14:44 --- join: Zarutian_HTC joined #forth 09:26:44 --- quit: Zarutian_HTC (Ping timeout: 272 seconds) 09:28:42 --- quit: xek_ (Read error: Connection reset by peer) 09:29:06 --- join: xek_ joined #forth 10:25:29 --- join: Zarutian_HTC joined #forth 10:29:12 --- quit: TCZ (Quit: Leaving) 10:46:44 --- quit: yunfan (Ping timeout: 246 seconds) 11:05:16 --- join: WickedShell joined #forth 11:42:18 --- quit: siraben (Ping timeout: 246 seconds) 11:42:20 --- quit: jimt[m] (Ping timeout: 252 seconds) 11:53:36 --- quit: gravicappa (Ping timeout: 240 seconds) 11:56:46 --- join: gravicappa joined #forth 12:17:44 --- join: siraben joined #forth 12:28:19 --- join: jimt[m] joined #forth 12:33:16 --- join: pierpal joined #forth 13:05:36 --- quit: pierpal (Ping timeout: 246 seconds) 13:20:39 --- join: pierpal joined #forth 13:36:16 --- quit: pierpal (Ping timeout: 272 seconds) 14:16:10 --- quit: dys (Ping timeout: 265 seconds) 14:16:11 --- quit: MrMobius (Ping timeout: 264 seconds) 14:23:11 --- join: dave0 joined #forth 14:26:57 --- quit: xek_ (Ping timeout: 260 seconds) 14:30:24 Today I learned if you effectively do COUNT SWAP TYPE accidentally, instead of COUNT TYPE, it will also print the string! (after first emitting almost all of the preceding memory) 14:31:02 Because either way you stop when you get to the address u+addr 14:31:54 This reminds me of the C thing where arr[i] is also i[arr] 14:50:36 --- quit: gravicappa (Ping timeout: 246 seconds) 15:04:21 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 15:04:51 --- join: Zarutian_HTC joined #forth 15:24:25 --- join: yunfan joined #forth 15:38:39 --- quit: kori (Ping timeout: 256 seconds) 15:41:22 --- join: rdrop-exit joined #forth 15:48:26 --- join: pierpal joined #forth 15:53:08 --- quit: pierpal (Ping timeout: 260 seconds) 16:01:31 --- join: ryke joined #forth 16:07:00 --- join: pierpal joined #forth 16:16:55 --- quit: pierpal (Read error: Connection reset by peer) 16:28:55 --- join: MrMobius joined #forth 17:15:14 --- quit: Zarutian_HTC (Remote host closed the connection) 17:16:25 --- join: Zarutian_HTC joined #forth 17:24:51 --- join: pierpal joined #forth 17:26:39 --- quit: pierpal (Read error: Connection reset by peer) 17:35:43 --- join: Zarutian_HTC| joined #forth 17:35:43 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 17:55:48 --- join: pierpal joined #forth 18:09:12 --- quit: pierpal (Ping timeout: 258 seconds) 18:09:20 --- join: boru` joined #forth 18:09:23 --- quit: boru (Disconnected by services) 18:09:25 --- nick: boru` -> boru 18:34:13 --- join: pierpal joined #forth 18:41:08 --- quit: pierpal (Ping timeout: 260 seconds) 19:00:15 --- join: pierpal joined #forth 19:04:16 --- quit: pierpal (Ping timeout: 240 seconds) 19:17:27 --- join: pierpal joined #forth 19:23:56 --- quit: dave0 (Quit: dave's not here) 19:31:18 --- quit: pierpal (Ping timeout: 256 seconds) 19:33:13 hey guys 19:33:30 hey tabemann 19:36:54 --- join: pierpal joined #forth 19:38:19 been working on converting the mecrisp-stellaris numworks code to work with zeptoforth 19:38:44 that sounds interesting 19:39:33 are you able to flash the calculator yet ? 19:39:54 or still waiting for a different connector ? 19:40:37 still waiting for the connector 19:40:52 the issue is that I cannot flash it but rather that I cannot hook up serial 19:41:13 and because I can't hook up serial I cannot download code into it for zeptoforth to compile 19:42:05 so you can flash but dont have a terminal ? 19:43:37 yeah 19:43:40 --- quit: pierpal (Ping timeout: 260 seconds) 19:44:12 did you see Crests work with a terminal on SWD ? 19:44:18 yeah 19:44:36 but I don't think I have access to SWD, just DFU over a USB connection 19:44:42 aha 19:45:18 aha, all thru the same usb connector 19:45:43 DFU works fine, I use it with RISC-V 19:46:16 the serial isn't through USB 19:46:30 it's thru the usb connector tho 19:46:40 it's that mecrisp-stellaris and zeptoforth can take over two different USB pins and turn them into a serial line 19:46:49 very handy, serial or usb bepending on whats running 19:46:56 -b+d 19:47:10 but they need to be fed into a serial-to-USB dongle 19:47:25 sure, it's all up to the config 19:47:35 which is why I need my female USB A 2.0 breakout board 19:47:42 so I can extract -D and +D 19:47:53 and feed them into the USB dongle 19:48:07 hmm, i wonder if that's also possible with the stm32f103 for the blue pill boards 19:48:08 one of them is RX the other is TX, I always forget which 19:48:48 i guess it's easier to leave the blue pill as is 19:49:12 it's a very versatile microprocessor world we now live in 19:50:53 well the numworks have a Cortex-M7 whereas the blue pill as an M3... 19:51:10 sure 19:54:56 the thing is that the STM32F7 used by the numworks seemed awfully similar to the STM32F4 used by the board I have 19:56:03 theyre all similar 19:56:28 in some way or another 19:58:15 porting zeptoforth itself required almost no changes 19:58:35 probably the only things that changed were the USART interface 19:58:54 particularly because I'd be using USART6 rather than USART2 20:02:36 thats common 20:03:17 sadly STM put the usb D- and D- signals with a usart control signals 20:03:37 and fixed that later in the F7 20:03:45 (and maybe others) 20:04:01 another reason to avoid the old F103 20:04:27 even if it is 3 - 5 times faster than my F051 at the same clock speed 20:07:19 i can help with your moving USART2 to USART6 if you need it 20:08:21 nah, already did it 20:08:44 cool 20:08:56 actually, there is a problem I just realized that will need solving 20:09:16 dfu-util only flashes space that it needs to load an image 20:09:28 yeah 20:09:39 but zeptoforth assumes that everything above its code is flashed 20:09:51 but it also can erase a larger space 20:09:52 i.e. it relies on a full erase cycle 20:11:12 dfu-util -a 0 -d 0483:df11 -s 0x8000000:mass-erase:force -D mecrisp-stellaris-stm32l433.bin -t 1024 20:11:38 https://forum.mystorm.uk/t/how-to-clear-all-flash/373 20:12:58 cool 20:15:33 wait a second - does the numworks board rely on an eraseable bootloader that could result in bricking if erased? 20:17:09 no, the stm32 bootloader cant be erased 20:17:20 it's in rom somewhere 20:22:31 I always wonder how those bootloaders can function without having to specifically allocate room for them 20:22:56 is there hidden ROM and RAM that is not in the standard memory space used by applications? 20:22:58 theyre in a read only part of the memory 20:23:01 sure 20:23:22 and not declared in the tech data afaik 20:25:12 but one can get the ST 'rom' dumps apparently 20:25:21 I always love undocumented stuff 20:26:08 they must have a bit of code as there is the DFU, the Serial bootloader that works not only with Usarts but I2c etc 20:26:49 well the actual functionality is well documented 20:27:17 the dfu and serial bootloaders are well documented as regards how to use them 20:28:18 yeah 20:28:49 theyre not all that trivial either 20:28:52 my biggest question is how do interrupt vectors work 20:29:08 there simple from mpov 20:29:24 because code installed at $00000000 have their interrupt vectors at the bottom of memory 20:29:36 ?? 20:29:49 so for some hidden firmware to work, they'd have to have their own vectors somewhere lse 20:29:52 *else 20:30:05 and then only pass on control to the normal vectors at the bottom of memory 20:30:07 ahh i see 20:30:33 you know how the user interrupts are configured ? 20:30:41 so let's say the real reset vector isn't at $00000004 but rather at, say, $F0000004 20:30:41 thats all very straightforward 20:31:06 I know the normal way user interrupts are configured, I'm not familiar with moving the vectors around 20:31:18 why are you concerned with the factory rom firmware ? 20:31:29 moving them is easy 20:31:30 I'm just curious 20:32:25 I guess youd have to get a copy of the STM ROM dump 20:32:58 does Zeptoforth support interrupts yet ? 20:33:03 yep 20:33:07 ah cool 20:33:16 I havent got that far 20:33:18 you have to code everything for them 20:33:32 but it does use interrupts for serial IO 20:33:41 not in the kernel out of the box 20:33:44 ah yes, I remember now 20:33:47 but rather in the "full" binaries 20:33:58 i saw this earlier today 20:34:15 it also uses the systick (again, not out of the box but in the "full" binaries) 20:34:38 re STM baud rate detection 20:34:40 baud rate detection algo: 20:34:41 activate IWDG watchdog 20:34:41 wait until RxD=1 - this is idle state 20:34:41 wait until RxD=0 - this is leading edge of start bit 20:34:41 wait until RxD=1 - this is leading edge of bit 0 of 0x7F sync byte 20:34:41 start timer 20:34:43 wait until RxD=0 - this is trailing edge of bit 6 of 0x7F 20:34:45 get elapsed time - this is duration of 7 '1' bits of 0x7F 20:34:47 set UART bit period = time / 7 20:34:49 So: 20:34:51 baudrate detection itself can’t hang (IWDG will reset the CPU) 20:34:53 the sync byte is not checked to be 0x7F, any trash containing 1010 sequence will be accepted 20:34:55 after detection the algo proceeds to RxByte functions kicking the IWDG endlessly until something is received 20:35:27 but I dont use autobaud because it has to be set up after every mcu reset 20:35:42 and I do a zillion resets during dev 20:39:03 I personally don't see why I would bother 20:39:07 --- quit: reepca (Remote host closed the connection) 20:39:25 it's better just to note that one needs to select a certain baud and live with that 20:42:12 yeah, agree 20:45:55 --- join: reepca joined #forth 20:46:29 one thing that annoys me about converting code from mecrisp-stellaris to zeptoforth is VARIABLE 20:46:47 mecrisp-stellaris's VARIABLE takes an initialization value 20:46:59 zeptoforth leaves VARIABLEs uninitialized 20:47:41 in part because they can be allocated while compiling code for flash despite the fact that they are really being allocated in RAM 20:48:05 so I'd need to figure out someplace to put them to store the initialization values 20:48:23 or just change yours ? 20:48:26 and I figured that it is easier to just require the user to initialize them from the init word 20:49:43 tp: all the ways I can imagine doing it seem overly complicated 20:50:20 like compiling an init word that calls the previous init word for each VARIABLE - which'd be inefficient space-wise 20:52:07 but Mecrisp-Stellaris VARIABLE just takes a parameter in addition to yours ? 20:53:40 it's done with or similar if I understand that correctly 20:53:54 Mecrisp-Stellaris must be doing some magic I am not aware of 20:54:12 Mecrisp-Stellaris's and zeptoforth's are equivaelnt 20:55:34 zeptoforth also has a CREATE which is equivalent to except it is more efficient space-wise 20:55:42 I recall reading how some VARIABLE are uninitialised in forths like yours and initialised in others 20:55:46 whereas Mecrisp-Stellaris has deprecated CREATE 20:56:15 implementing an initialized VARIABLE when compiling to RAM is trivial 20:56:32 ahh 20:56:40 where it gets tricky is when defining VARIABLEs while compiling to flash 20:57:05 I had to do some magic to get VARIABLEs to work while compiling to flash in the first place 20:58:01 thats Forth implementer black magic 20:58:10 technicians dont go there 20:59:51 hint - if you forget to call init from within an outer init word, it all breaks 21:03:41 it's the same with Mecrisp-Stellaris 21:07:06 I bet Mecrisp-Stellaris just generates hidden init words to do all this 21:07:31 I'm speaking about the user 'init' word 21:07:39 yeah 21:07:41 the turnkey user word 21:07:50 thats the only one I know about 21:10:32 okay, I should get to bed - kinda falling asleep here 21:10:46 night! 21:12:02 g'night 21:25:05 --- quit: dddddd (Ping timeout: 258 seconds) 21:40:15 --- join: X-Scale` joined #forth 21:40:50 --- quit: X-Scale (Ping timeout: 265 seconds) 21:41:01 --- nick: X-Scale` -> X-Scale 21:41:30 --- quit: jsoft (Remote host closed the connection) 21:50:41 --- quit: rdrop-exit (Quit: Lost terminal) 22:09:40 --- join: dys joined #forth 22:17:02 --- quit: ryke (Remote host closed the connection) 22:17:32 --- join: ryke joined #forth 22:30:20 --- join: pierpal joined #forth 22:51:31 --- join: gravicappa joined #forth 23:04:29 --- quit: ryke (Ping timeout: 260 seconds) 23:37:13 --- join: xek_ joined #forth 23:38:31 --- join: mtsd joined #forth 23:57:10 --- nick: xek_ -> xek 23:59:59 --- log: ended forth/20.06.01