00:00:00 --- log: started forth/20.06.10 00:25:03 --- quit: Zarutian_HTC (Remote host closed the connection) 01:04:47 --- join: dys joined #forth 01:16:03 --- join: xek joined #forth 02:29:32 --- join: jedb_ joined #forth 02:31:59 --- quit: jedb (Ping timeout: 246 seconds) 03:06:29 --- quit: dave0 (Quit: dave's not here) 03:38:14 --- join: iyzsong joined #forth 03:45:08 --- quit: xek (Ping timeout: 256 seconds) 04:14:03 --- quit: dys (Ping timeout: 272 seconds) 04:18:36 --- join: dddddd joined #forth 04:24:23 --- nick: jackdani1l -> jackdaniel 04:33:26 --- quit: jsoft (Ping timeout: 246 seconds) 04:37:39 --- join: jamzattack joined #forth 04:39:24 --- join: TCZ joined #forth 05:12:07 just bought 2 riscv board with hdmi and usb port, also 64MB ram inside. this remind me the j1forth board 05:30:38 --- quit: TCZ (Quit: Leaving) 05:46:21 --- quit: iyzsong (Quit: ZNC 1.8.0 - https://znc.in) 05:48:55 --- join: iyzsong joined #forth 05:53:20 --- join: tp_ joined #forth 05:58:29 --- quit: tp (Read error: Connection reset by peer) 06:01:58 --- quit: crest (*.net *.split) 06:03:33 --- join: crest joined #forth 06:54:56 damn it. looks like the virtual com port is routed to different pins than the ones used by image 06:55:09 one more reason to get swdcom finished quickly 07:18:48 --- join: TCZ joined #forth 07:37:00 --- quit: iyzsong (Quit: ZNC 1.8.0 - https://znc.in) 08:13:37 --- nick: TCZ -> DOMSlayer2020 08:33:55 --- nick: DOMSlayer2020 -> TCZ 08:42:59 tp: : swd-init ( -- ) 0 swd [ $46b3 h, ] ! ; \ $46b3 = mov r11, rTOS 09:08:32 i added to little helpers 09:08:35 : >r11 ( x -- ) [ $46b3 h, ] drop ; \ $46b3 = mov r11, rTOS (aka r6) 09:08:36 : r11@ ( -- x ) dup [ $465e h, ] ; \ $465e = mov rTOS, r11 09:08:49 it looks like they're working correctly 09:09:33 but the debugger stlink_read_reg and stlink_read_all_reg return garbage 09:10:23 because i don't believe that all 16 registers are equal to $f3de9b08 09:13:28 --- quit: TCZ (Quit: Leaving) 09:17:04 okay the core has to be halted for the debugger to inspect the register file 09:19:56 --- part: jamzattack left #forth 09:32:11 --- join: WickedShell joined #forth 10:13:33 tp_: christmas came early 10:14:11 i figured out how to read from the register file and reset the target system 10:14:21 now ctrl+c resets the system 10:14:50 but it isn't the same as pressing the reset button because it look like it doesn't reset the hardware and "just" jumps to the reset interrupt 10:14:54 (i assume) 10:15:25 because the serial output on reset is garbled 10:16:25 for now i keep the address in R11 10:17:07 but preserved the option override it from the command line 10:17:12 e.g. to use R11 for something else 10:17:41 or to avoid halting the cpu to access the register file 10:20:34 for some as yet unknown reason you now have to hit ctrl+c to continue after a reset 10:34:45 pointfree: have you considered banning wengchunkn from r/Forth 10:34:55 everything he posts is unrelated garbage 11:01:45 Sir, this is an Arby's 11:18:02 --- join: Zarutian_HTC joined #forth 11:25:33 a what 12:09:32 --- quit: jedb_ (Ping timeout: 256 seconds) 13:01:01 Just reading the reddit and wengchunkn posted a link to that hilariously bad tweet about that forth code that was formatting people's hard driver, I think that's relevant 13:01:47 --- join: TCZ joined #forth 14:07:25 --- quit: TCZ (Quit: Leaving) 14:36:29 --- quit: gravicappa (Ping timeout: 246 seconds) 15:28:12 --- join: dave0 joined #forth 16:36:35 --- join: X-Scale` joined #forth 16:37:35 --- quit: X-Scale (Ping timeout: 246 seconds) 16:37:36 --- nick: X-Scale` -> X-Scale 16:42:26 --- join: rdrop-exit joined #forth 17:38:47 hey guys 17:39:16 crest wow! 17:39:33 --- nick: tp_ -> tp 17:39:45 hi tabemann 17:40:46 tp: turns out the stm32l476-ra config doesn't match the nucleo board 17:41:08 the serial console doesn't work 17:41:09 the stm32l476 configuration is for the discovery board 17:41:20 tabemann: exactly 17:41:32 and it's unfortunate that you bought the nucleo board 17:41:37 --- join: jedb joined #forth 17:41:44 i suspected as much from some of the comments 17:41:46 as for that same reason you won't be able to use zeptoforth without doing some porting work 17:42:19 it should be as simple as fixing the serial port setup or are there any other problems lurking after that? 17:42:40 because it's the same MCU, the flash controller should be the same 17:43:05 guess i have to study the datasheets first and figure out how to get USART2 mapped to PA2 and PA3 17:43:17 instead of PD5 and PD6 17:43:40 if you could just use a serial dongle and jumper cables 17:43:59 looks like those pins aren't exposed on the headers 17:44:06 crest that why the support hardware says "STM L476 Discovery" 17:44:41 crest it will only be a few changes to the assembly for a different usart 17:44:45 or i could port the swdcom bootstrap code to assembler on the blue pill 17:44:58 tp: just ther alternate function setup 17:45:10 to route usart2 to the right expected pins 17:45:18 but i'm not yet familar with the chip 17:45:21 crest, maybe it's just on different pins ? 17:45:30 maybe 17:45:33 i don't know 17:45:46 crest I'll grab the schematic and have a look 17:46:04 it's only a very minor issue 17:46:09 and because of that i'm thinking about porting the swdcom forth code to assembler 17:46:12 definitely no showstopper 17:46:22 wow, thats even better 17:46:58 but so far i have just written two instructions of thumb2 assembler and assembled those manually 17:47:11 to write >r11 and r11@ 17:47:35 USART2 PD5 PD6 and the USB had a virtual com port 17:48:00 I'd prefer that approach, so that I don't have to change the zeptoforth kernel to support swdcom 17:48:01 that much i discovered in the getting started guide 17:48:15 tabemann: but a working serial port is still useful 17:48:21 so looks like PD5 PD6 to your 3.3v dongle and youre in business 17:48:37 crest: yes, you want a working serial port 17:48:51 but i didn't find a proper schematic for the board 17:48:55 oops thats on the discovery! 17:49:01 tp: crest is saying those pins aren't exposed on the Nucleo 17:49:14 yeah the bloody nucleo schematics are a damn disgrace 17:49:30 tabemann: no. i said i haven't found if they're routed to any pin 17:49:37 ah 17:49:42 tabemann, aha, I'm still looking for the schematic 17:55:41 the nucleo schematics are likely the worst schematics Ive ever seen in my life 17:55:50 thats how bad they are 17:55:58 this is what i've found so far: https://os.mbed.com/platforms/ST-Nucleo-L476RG/ 17:56:11 tp: what makes them so much worse than the discovery boards? 17:56:20 --- join: TCZ joined #forth 17:56:41 the discovery boards arent much better 17:57:01 they are both utterly usless 17:57:27 someone who knows nothing aboyt electronics did them 18:09:33 ? 18:09:56 that's not very precise 18:17:21 holy shit the reference manual has >1800 pages and 30MB 18:19:11 --- quit: jedb (Ping timeout: 264 seconds) 18:36:29 and is written in the same style as the old stm32f103 documention 18:37:15 tp: what were the signs for that? just curious 18:37:17 looking for the instruction sequence required to configure some piece of the chip feels like a game of whack a mole 18:38:59 --- join: jedb_ joined #forth 18:39:26 it almost feels like a DDoS attack on newbies 18:41:07 or some overzealus IP defender got into the documentation making 18:41:48 --- quit: TCZ (Quit: Leaving) 18:50:17 back, phonecall 18:50:26 Zarutian_HTC, signs for what ? 18:50:57 crest, Ive learnt to LOVE the stm manuals, theyre a class above anything else Ive seen 18:51:11 tp: that the board was done by someone clueless about electronics 18:51:42 Zarutian_HTC, ah. the fact that they dont atually draw a schematic is the clue 18:52:06 the discovery and nucleo schematics arent actually schematics 18:52:24 tp: then you havent come across panasonic troubleshooting and service manuals. Those are quite goodþ 18:52:36 theyre a ah hoc list of signals placed on the page 18:54:11 just, "pin 4 has these as possible signals" kind of list? 18:56:11 back 18:57:15 would it kill them to export the eagle/kicad/whatever files into pngs and pdfs? 18:57:51 --- join: boru` joined #forth 18:57:54 --- quit: boru (Disconnected by services) 18:57:57 --- nick: boru` -> boru 18:58:15 crest: probably 19:00:06 there is one manifacturer that uses the internal hyperlink feature of pdf extensively and does it well 19:01:07 click on a signal name on the schematic and you get the section on how to make it accessible 19:01:31 that is show up on the pin 19:03:34 Zarutian_HTC, this is a schematic and pcb I did over 20 years ago https://mecrisp-stellaris-folkdoc.sourceforge.io/pcb.html#old-riaa-amp 19:03:45 thats what I know as a schematic 19:04:31 crest, youre right, theyre terrible, I will probably draw up a nucleo schematic soon 19:05:14 if each pin doesnt have a wire joining it to another pin(s) it's not a schematic, it's a list of signals 19:06:40 the schematic and pcb are all made by OSS apps btw 19:06:53 the original gEDA 19:08:21 tp: the internal layout wasnt down to resistor, caps and transistors at that level. Think very detailed block diagram. The outlines of the blocks were hyperlinks to those kind of schematics in the document 19:09:34 Zarutian_HTC, gEDA has sub pages 19:09:42 thats nothing new 19:10:16 otherwise you would get an A0 sized page were all the text is 6p and schematic symbols of equiv size 19:10:51 of course, but that was solved at least 20+ years ago, probably 40 19:11:03 depending on what package one used 19:11:22 sure, but I hadnt seen the link usage and such in a pdf datasheet 19:12:04 ahh , good point :) 19:12:36 schematic files sure but not this well done in a datasheet pdf 19:12:48 crest: TX is on PA2, RX on PA3 19:13:09 i know 19:13:41 that much is documented in the getting started guide in the section for the virtual com port 19:14:17 the problem is that mecrisp uses a different pin that isn't exposed on any of the headers 19:14:57 and the component BOM list highlighting in board layout diagrams made troubleshooting breazy 19:15:26 table 16 of the datasheet tells me that PA2 / PA3 are an option as well 19:15:26 crest, ok, looking into it 19:16:23 it don't know enough about the i/o subsystem to fix this (yet) 19:18:40 i have to learn about the multiplexer connecting alternate functions to gpio pins 19:18:55 crest, looks like there is no PDx 19:19:18 there is in the reference manual 19:19:49 yeah of course, the ref manual covers all types of package 19:19:53 the nucleo board is confusing because it looks like they're reusing the arduino pin names for the arduino connectors 19:20:07 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 19:20:17 --- join: Zarutian_HTC joined #forth 19:20:22 but if the mcu in the nucleo is a small pinout package, it may not have enough pins to bring out port 19:20:24 D 19:20:45 crest, the nucleo is STMicros effort to support arduino 19:21:17 so it has arduino daughter board headers' and the old stm32 headers 19:22:03 it's also the the cheapest possible pcb as evidenced by the criminal lack of silk screening for pins 19:22:13 I have one myself 19:22:36 i'm just a programmer with no idea about PCB design 19:22:45 why is the silk screening so important? 19:23:07 so you can see the number of the pin you want to plug a wire onto 19:23:16 unless you like counting pins 19:23:38 all the discovery board pins are labelled 19:23:56 in comparison 19:24:18 I understand why they cut corners, afterall the nucleo is very cheap for what it offers 19:24:46 it just means more care and attention is needed 19:25:37 crest, if you port a standard Mecrisp-Stellaris to the nucleo and sent the files to matthias youll be imortalised in the contributors page! 19:25:38 ok the PD5/6 ping exist only in the parts >=100 pins and not on 64pin verions like the one on my board 19:25:49 yeah 19:25:58 that's how it works 19:26:37 a 205 pin package may have ports up to "G" 19:26:50 or even "H" 19:28:08 my 32 pin package has only ports A and B 19:29:22 crest, basically you edit terminal.s in the MCU directory in source 19:29:56 i did fiddle with that already 19:30:02 to test your terminal.s 19:30:02 that will involve checking if you can use the default AF1 as is or changing it if noy 19:30:10 back 19:30:44 does everyone have my latest L476 svd2forth files ? 19:37:45 I just realized a misfeature of my SET-ORDER functionality 19:37:54 it makes it really easy to not include forth-wordlist 19:38:01 and then you're fucked until you reboot 19:38:35 because without FORTH-WORDLIST one cannot call SET-ORDER again to reverse the change you made 19:41:05 I'm almost considering changing SET-ORDER that it forces the inclusion of FORTH-WORDLIST no matter what 19:42:53 damn it 19:43:20 the AF0-7 mappings are in the datasheet but *not* in the 2000 page reference manual 19:43:31 that explains why i didn't find them 19:44:01 no, theyre in the 'electrial' manual usually 19:44:21 i found them in: https://www.st.com/resource/en/datasheet/stm32l476rg.pdf 19:44:44 i need AF7 for PA2 and PA3 19:45:08 it takes a little while to become familiar with what is where, but these are *very* complex devices, they cant be conddensed into a 100 page manual 19:45:40 of course not 19:45:54 but you could index them in useful ways 19:46:17 have an application note for normal USART use 19:46:21 crest, I've made an posted a tarball with a .s file for you, I'm waiting for sourceforge to make it live 19:46:22 an other one for USART with DMA 19:46:38 it has all the equate stuff you need 19:46:59 but most of it is "hidden" from C programmers in the support library 19:47:02 https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/stm32L476-svd2forth.tar.gz/download 19:47:20 I hate the damn support libraries 19:47:27 if you write C against their library you call an API 19:47:31 they make searching for information on MCUs online impossible 19:47:38 the equate file has all the stuff you need to set up the alternate usart etc 19:48:01 the rest is just an implementation detail you don't have to know 19:48:02 in the terminal.s file 19:48:48 matthias wrote it so only the base file of the usart needs to be changed 19:49:13 all the usart registers are fine as is 19:49:56 tabemann, https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/stm32L476-svd2forth.tar.gz/download has my latest stack picture in the bitfields 19:52:16 cool 19:54:12 * tabemann just changed the search order in zeptoforth so it searches for words wordlist first, then by ram versus flash, rather than the other way around 19:58:33 --- join: reepca joined #forth 20:14:38 ah 20:15:06 tabemann I like your word search feature 20:18:17 I think SET-ORDER is better than the traditional Forth-79 approach for a system with flash 20:19:01 as there is no need to maintain a branching tree of linked lists 20:19:21 rather there are two single linked lists, one for flash and one for RAM, in which each word is tagged with a wordlist 20:20:27 and for the wordlists, you just list he wordlists and the count and call SET-ORDER and presto! you now search those wordlist in that order 20:24:21 with the Forth-79 way of doing things... well... you set a single searched wordlist that links to a parent wordlist, and can't really change things around without chaining that wordlist to a different wordlist (something that is all but impossible with flash) 20:32:49 okay, I am getting tired, so I should go to bed 20:33:42 g'night 20:46:42 Except for a few holdouts, Forth-79 fell out of favor when Forth-83 was published 21:03:22 --- quit: dave0 (Quit: dave's not here) 21:30:09 --- join: jsoft joined #forth 22:10:03 --- quit: Zarutian_HTC (Ping timeout: 258 seconds) 22:11:19 --- quit: dddddd (Ping timeout: 260 seconds) 22:16:06 --- join: dys joined #forth 22:36:50 --- quit: APic (Ping timeout: 256 seconds) 22:37:01 --- quit: jedb_ (Ping timeout: 265 seconds) 22:39:16 --- join: APic joined #forth 22:58:30 --- join: gravicappa joined #forth 23:00:00 --- join: jedb joined #forth 23:09:24 --- quit: _whitelogger (Remote host closed the connection) 23:12:25 --- join: _whitelogger joined #forth 23:18:03 --- join: Zarutian_HTC joined #forth 23:32:44 --- join: mtsd joined #forth 23:43:57 --- quit: rdrop-exit (Quit: Lost terminal) 23:45:35 --- quit: mtsd (Quit: Leaving) 23:59:59 --- log: ended forth/20.06.10