00:00:00 --- log: started forth/20.05.25 00:39:09 --- join: xek joined #forth 00:42:50 crest, very interesting, it sounds as tho your idea may work 00:42:59 it should 00:45:29 crest, and openocd knows how to use a usb3.3v dongle as SWD programmer and debugger 00:45:59 so no one really needs a dedicated Chinese swd programmer 00:46:44 libstlink-shared from https://github.com/texane/stlink 00:47:18 because my code just calls the open_usb variant it only works with stlink v2 right now 00:47:35 but a small change to the open code should be enough to support stlink v1 as well 00:48:50 eww, forget V1, nobody uses that 00:49:08 what we all did was flash V1 to V2 00:57:03 tp: so far i'm only implementing a simplified version of my idea 00:57:28 with a one byte buffer and flag for each direction 00:59:39 crest, start small and get bigger later 01:00:12 crest, yours is a new idea for Mecrisp-Stellaris, you're bringing new talent to it! 01:01:23 and maybe the simplified verstion is good enough 01:04:57 crest, what's the whole idea? upload source via SWD into the TIB where it is compiled ? 01:05:36 no 01:05:51 provide hooks for key?, key, emit and emit? 01:06:22 writing directly into the TIB would be hideous 01:06:54 wait a minute, providing hooks for key?, key, emit and emit? is far to easy! 01:07:21 why would it be too easy? 01:07:52 then use an 'uploader' program on the pc without a terminal ? 01:08:05 well compared to writing to the TIB I mean 01:08:15 the whole state (rx, /rts, tx, cts) fits into 32 bit 01:08:46 allowing the stlink v2 to read it with a single read_mem32 command 01:09:16 i used a different byte for each field because it allows me to use write_mem8 to change fields in the right order 01:09:33 or c@/c! on forth system 01:11:39 Good morning forth-users 01:14:18 g'day veltas 01:18:02 I wrote my division and it doesn't work, so debugging that today 01:18:19 Hi tp how is the metal life 01:20:38 tp: it works 01:20:40 veltas, good, a lot to do atm, tabemanns Zeptoforth dissasembler is ready to try to use to build RTS handshaking 01:21:03 crest, awesome, so what can it do now ? 01:21:23 replace the usart as console 01:21:51 veltas, my new bit testing page is nearly ready, stm32f103-diags-v1.5 is finished 01:22:18 crest and what replaces the terminal at the pc end ? 01:22:38 Cool, well you know I will read that if you want, although I don't see the point because I don't think you really listen to anything I say about C unless it's negative :P 01:22:39 my little tool 01:23:09 it puts the tty in raw mode and sends everything to the forth system 01:23:27 and outputs everything in the other direction as well 01:23:52 veltas, I have at least 42 readers already ;P 01:25:11 veltas, actually my doc page is just my Forth notes, and some personal rants, it's not there for readership or money, it's all OSS on sourceforge 01:25:30 now i have to implement something better than 1kHz polling 01:25:58 veltas, it's only there to provide something modern for the few Forth addicts to read as everything else everywhere is about C 01:26:37 and handle things other than ttys as input 01:26:41 crest, is raising the speed a issue ? 01:26:49 shouldn't be 01:27:28 --- quit: Vedran (Ping timeout: 260 seconds) 01:31:49 next i have to implement file uploads 01:32:11 ... again 01:32:43 the price of innovation! 01:40:12 polling the stlink v2 as fast as possible takes about 17% of one core at 900mhz on my thinkpad t470s 01:40:48 the stlink lib uses libusb in turn to acess the stlink v2 from userspace 01:41:27 because there is no file upload i can't tell you (yet) how fast this console can be without further optimizations 01:41:50 wow 01:41:59 ? 01:42:08 polling the stlink v2 as fast as possible takes about 17% of one core at 900mhz 01:42:34 the library fires ioctl()s like crazy 01:42:55 to be expected I guess 01:42:58 its a true busy poll loop only limited by how fast the syscalls return 01:43:45 --- quit: dave0 (Quit: dave's not here) 01:43:51 with a smarter polling algorithm it shouldn't cause more than a few dozen syscalls per second at idle 01:45:45 maybe start with a 100ms poll interval and on each transfer divde it by 3, increase by 2 on timeout 01:45:58 or something like that 01:46:17 with some upper and lower bounds 01:48:17 the polling is part of st-link I guess ? 01:50:27 its part of the logic because i don't know how to set data watchpoints 01:50:40 it would be really nice to just have a data watchpoint on tx 01:52:03 but because i haven't found a mcu -> host command in the stlink headers i assume that the host still has to poll 01:52:09 just on some debug control register 01:58:51 running words takes about 20 seconds with my swd console 01:59:14 --- quit: dys (Ping timeout: 260 seconds) 02:00:46 which is several times slower than an usart at 115200 baud 02:00:46 uploading and then running some words takes 20 seconds ? 02:00:59 no just running "words" 02:01:03 oh 02:01:28 but this could be due to lots of ping-pong between the mcu and host 02:01:36 because of the low 1kHz polling ? 02:01:45 no this is without any sleep 02:01:56 but there is still a lot of roundtrips per byte 02:02:01 *there are 02:03:01 it could be a lot faster with proper buffering per direction 02:03:29 right now emit waits for the host to poll the "shared memory" 02:03:52 notice the change and clear the flag 02:04:30 so for each byte transmitted from the mcu to the host two commands have to be executed on the stlink 02:04:53 one to read the whole 32 bit word 02:05:21 and an other to clear the flag byte inside the 32 bit word 02:07:52 http://dpaste.com/03YE95Y takes 0.5 second to list on a stm32f051 cortex-m0 running at 75Mhz and 460800 baud 02:09:12 --- join: Vedran joined #forth 02:09:31 thats what Im used to, a STM32F103 at 75MHz is a bit faster, definitely noticable 02:10:13 lol, especially when using USB to display the wordlist 02:11:20 its not like the debugger was designed as a high speed interface 02:11:27 and i have to check the swd clock rate 02:13:31 i think Ive seen st-link stating 900 Mhz speeds 02:13:55 it usually wants 1GHz but has never achieved that here 02:14:32 I have noticed that SWD is faster than JTAG when uploading to flash 02:15:45 GHz?!? 02:18:22 yeah 02:18:39 thats what I see with openocd 02:19:35 OOPS! 02:19:38 adapter speed: 1000 kHz 02:19:43 sorry 02:19:56 1Mhz 02:20:26 --- quit: Vedran (Ping timeout: 265 seconds) 02:20:50 adapter_nsrst_delay: 100 02:20:50 jtag_ntrst_delay: 100 02:20:50 none separate 02:20:50 cortex_m reset_config sysresetreq 02:20:50 Info : clock speed 1000 kHz 02:21:35 --- join: dys joined #forth 02:22:29 the default with stlink is 1.8MHz lets try again with the full 4MHz 02:25:57 that reduced the runtime of "words" by 5 seconds 02:27:20 looks like i should implement a buffered version of this 02:27:49 but it's still a useful alternative to the usart if you're running out of pins 02:28:11 and it requires no baudrate matching 02:29:22 --- join: Vedran joined #forth 02:31:55 tp: this is the whole code form the forth side: https://gist.github.com/Crest/4661650057935952013dc092573c7f46 02:34:51 i inverted one of flags to get a all zeroes start value for the shared variable 02:35:22 the terminal programs needs to know which stlink and memory address to use 02:41:14 crest, your Forth code looks simple but it's well above my Forth level 02:41:58 swd is the 32bit variable polled by the stlink 02:42:23 swd. just dumps the variable with hex. (little debug helper) 02:42:51 the protocols works like this 02:43:36 to send a byte from the mcu to the host the mcu checks if the one byte tx buffer is available 02:44:00 if so it writes to a byte to the tx buffer and sets the flag to $ff 02:44:18 now it's the hosts job to poll the whole variable 02:44:22 notice the flag 02:44:35 show the byte to the user and clear the flag 02:45:10 to get a byte from the host to the mcu the host has to check if the mcu rx buffer is free 02:45:36 if the buffer is free it writes to the buffer and sets corresponding flag to $ff 02:46:12 now the mcu has to poll the rx flag byte 02:46:28 read the data byte and clear the flag 02:47:25 so there are two or three stlink commands (mem_read32 or mem_write8) per single byte transfer depending on the direction 02:47:37 this is a lot of fucking overhead 02:47:50 as you said earlier, perhaps a buffer on the mcu to speed it up ? 02:47:56 and each side has to wait for the other 02:48:14 i want to write a little benchmark how fast i can read 1024^2 times 02:48:33 yeah, must be as it's so slow, Im surprised 02:48:44 that should be the upper bound 02:53:47 --- quit: jsoft (Ping timeout: 265 seconds) 02:56:10 65.738424 seconds / MiB 02:57:03 or 124.61 kib/s 02:58:16 so my upper bound is around the speed of a 115200 baud usart 02:58:58 but there is a disconnect as reading the wordlist at that speed is much less than 60 seconds ? 02:59:18 maybe 1 or 2 seconds ? 02:59:59 that's just reading from the same 32 bit memory location in a loop 03:00:12 with no waiting at all 03:00:45 it's much too slow imho 03:00:51 ... sadly 03:00:57 for ( size_t i = 0; i < (1024*1024)/4; i++ ) { 03:00:57 uint32_t value = read32(addr); 03:00:57 } 03:01:25 i don't know if one could write debugger 03:01:41 can you correlate that with a sw-link write to flash if 1024 bytes ? 03:01:47 if = of 03:02:28 or even if the debugger i have could be faster with a different library 03:02:38 I'm thinking suck a write to flash is about 7 seconds ? 03:02:43 i haven't tried that 03:02:50 such 03:03:11 let me check how long it takes to read the whole flash 03:03:21 ah yes, great idea 03:05:13 reading the whole 128KiB flash took just 1.31 seconds 03:06:46 = 6.2 times faster than my benchmark 03:07:07 still slow :( 03:08:01 come to think of it, when Ive used the serial bootloader on occasion Ive always been surprised how fast it is 03:08:14 faster than your serial baurate 03:08:34 but not by much 03:09:09 I'm limited to 460800 baud with Screen on FreeBSD but the real slowdown when uploading source is the on chip compiler 03:09:28 so uploading is different to reading from the chip 03:09:59 how fast is your effective datarate while uploading code? 03:13:23 I've not measured it 03:13:28 let me time it 03:18:47 maybe it's more efficient to transfer multiple words per api call? 03:21:27 reading in 1024 byte blocks is about 10 times faster 03:22:28 11 seconds to upload (and compile) 42606 bytes of source with no comments 03:22:45 on a cortex-m0 03:22:46 my latest benchmark reading 1024 times the same 1024 bytes from sram runs in 6.429456 seconds 03:23:17 thats as fast as st-link ? 03:23:55 that's faster than st-flash read 03:25:05 so your upload speed is just 3873 byte/sec 03:26:48 less than the peak throughput of a 38.4k baud link 03:27:08 yeah, the culprit is the on-chip compiler 03:27:28 sure but relative to this my idea could still be fast enough 03:27:42 ah yes, regarding upload speeds :) 03:28:01 youll just have to send wordlists by telegram instead ;-) 03:28:10 no?!? 03:28:36 60 seconds for a wordlist is about 120 times too slow 03:29:17 with a large enough buffer the transfer speed should go up by several factors 03:30:11 I think thats still way too slow, certainly for me 03:30:35 of course searching wor a word would cure that 03:30:37 for 03:30:49 so there would be workarounds 03:30:59 searching instead of listing 03:31:06 I list as I have no search 03:31:35 --- join: iyzsong joined #forth 03:35:29 my read benchmark reaches about 1276 kbaud 03:36:23 about 3 times that of your serial console 03:36:53 only when uploading source 03:37:18 I also use it to download hexfiles and source 03:37:45 automatically, when Im making a release tarball 03:38:02 and hex is quite verbose ;-) 03:38:15 Intelhex I mean 03:38:31 but thats just me 03:38:38 3 times the peak data rate of your serial connection's baud rate 03:38:51 tho tabemann also uses that method to make his 'full' releases 03:39:41 another factor is this is a cortex-m, your cortex-m3 is 3 -5x faster than that 03:39:50 another factor is this is a cortex-m0, your cortex-m3 is 3 -5x faster than that 03:45:10 why is the m0 so much slower per clock? 03:45:18 is it just the thumb1? 03:47:03 it's the m0 03:47:20 it's the simplest stm32 off all 03:48:14 it has a tiny dies size and very few transistors in comparison to the F1xx and above 03:58:14 but why did they use the old arm v6 with thumb1? isn't the m3 the oldest cortex m? 03:59:58 yes, the stm32f103 was released in 2004, the stmn32f0 in 2011 04:01:08 the f0 is the cheapest in stm32, and is capable of many embedded tasks, perhaps thats why ? 04:01:46 but how can a core that implements arm and thumb1 mode be smaller than one that just implements thumb2? 04:03:40 the m0 *only* implements thumb1 04:05:01 maybe instead of a pair of ring buffers with a read and write index each it would be better just have a bitmap in every 8th byte of the buffer 04:07:59 How old is # for pictured numeric output processing? 04:08:48 Because the method seems really inefficient for printing a number, although I'm not sure how much it matters 04:08:54 i have no idea 04:09:09 it isn't designed to just print numbers 04:09:27 but to format them 04:10:00 The way it's defined makes sense if you have division built-in, and division is fast. But if division is software or software-support it makes zero sense because the *steps* of division actually produce digits in the right order 04:10:38 So it's like you end up doing the work many times over 04:11:03 division is always faster than humans 04:12:17 --- quit: rdrop-exit (Ping timeout: 246 seconds) 04:12:52 I don't understand what you mean, why does it matter how fast humans do it? 04:32:35 --- join: rdrop-exit joined #forth 04:37:48 My least favourite thing in standard forth so far is the sized arithmetic combinations available and the ambiguous conditions for using them 04:40:44 --- join: dddddd joined #forth 04:40:52 i guess on hardware without a hardware divider you could implement special cases for base 10 and 16 04:57:38 Yes, that is the approach I am using 04:58:10 --- quit: rdrop-exit (Quit: Lost terminal) 04:58:22 Well the plan is to have a special case in # for any power of 2 base, and probably a hardcoded case for 10. 05:08:34 --- quit: pointfree (Ping timeout: 260 seconds) 05:08:41 --- join: mtsd_ joined #forth 05:11:09 --- join: pointfree joined #forth 05:11:22 --- quit: mtsd (Ping timeout: 272 seconds) 05:13:42 --- join: TCZ joined #forth 05:22:34 the numworks calculator looks like a nice little mobile forth system 05:26:08 and has a Mecrisp-Stellaris binary just for it 05:35:26 --- quit: Lord_Nightmare (Ping timeout: 258 seconds) 05:37:16 --- join: Lord_Nightmare joined #forth 05:48:24 --- quit: mtsd_ (Quit: Leaving) 05:55:57 that's how i found out about it 05:56:40 :) 05:57:55 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 05:58:42 --- join: antaoiseach joined #forth 05:58:51 --- quit: antaoiseach (Client Quit) 05:59:02 --- join: antaoiseach joined #forth 06:01:20 --- join: iyzsong joined #forth 06:04:36 --- quit: proteusguy (Ping timeout: 240 seconds) 06:05:12 --- quit: proteus-guy (Ping timeout: 265 seconds) 06:10:25 --- quit: reepca (Remote host closed the connection) 06:10:38 --- join: reepca joined #forth 06:14:19 --- quit: TCZ (Quit: Leaving) 06:18:20 --- join: proteusguy joined #forth 06:18:20 --- mode: ChanServ set +v proteusguy 06:18:33 --- join: proteus-guy joined #forth 06:37:40 --- part: antaoiseach left #forth 07:28:31 --- join: WickedShell joined #forth 07:44:35 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 08:01:58 --- join: karswell joined #forth 08:50:10 --- quit: reepca (Ping timeout: 258 seconds) 08:57:20 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 09:13:01 --- quit: dys (Ping timeout: 244 seconds) 09:14:54 --- quit: karswell (Remote host closed the connection) 09:15:48 --- join: karswell joined #forth 09:24:08 --- join: Zarutian_HTC joined #forth 09:42:07 back 09:42:11 hey guys 09:52:00 --- join: X-Scale` joined #forth 09:52:48 --- quit: X-Scale (Ping timeout: 256 seconds) 09:52:53 --- nick: X-Scale` -> X-Scale 10:14:33 --- quit: karswell (Remote host closed the connection) 10:15:33 --- join: karswell joined #forth 10:57:29 dealing with padding for both parts of a ring buffer gets annoying 10:58:27 hey 10:59:37 * tabemann is going to take a stab at programming this nRF52840-DONGLE board 11:11:59 Hello. This time I have a more concrete problem. How should I represent a doubly linked list in Forth? Should I use structures or there is a better solution? 11:13:27 andrei-n, do you know how to use CREATE and ALLOT? 11:14:08 Yes. It's for creating arrays or strings, that is contiguous sections of data in memory. 11:15:20 right 11:15:46 you can store anything you want there though. you can also think of it like a struct in C where the bytes could be different types 11:17:16 like if you have a 1 byte variable, a 2 byte variable and a 4 byte variable, just do 7 ALLOT and you can store those three things there however you like 11:17:17 So the way Forth does while defining words? So you just specify (like in a binary file) the organization of data and that's all? 11:18:29 you dont really specify the organization of data, you just write it at a particular address and as long as youre careful you wont overwrite anything 11:19:02 And is there a way to "free" the allots? For example I have a string that might become bigger, so I need to make more space. But the old one still takes some space. 11:19:55 not really. what youre describing is dymanic memory allocation 11:20:09 " allot" is yet another Stack: " neg allot". 11:20:19 so you could a few bytes in your structure to hold an address then devise some way to do dynamic allocation and store the address in the struct 11:20:36 That means that if I for example want to make a text editor I need to write my own memory allocator? 11:21:07 andrei-n, yes or find a forth that has one builtin or bite the bullet and make every line in the editor the max line size 11:23:16 the memory allocator becomes much easier if every block allocated is the same size. on the other hand you might be wasting a lot of memory. depends on what system youre on the resources you have to spare 11:23:26 Is it a common thing for a Forth programmer to write a memory allocator? Or is it some kind of antipattern? 11:24:29 Why would it be ""anti-pattern""? 11:25:19 andrei-n, what system are you working on? some of the PC-based forths probably have it built in already 11:25:28 CORDIC, Because it might be like forcing a mentality from other programming paradigms... 11:25:42 MrMobius, gforth 11:26:14 andrei-n: Are you aware gforth is not even v1.0? 11:27:35 CORDIC, yes... Is it a problem? Are there other free implementations that are still alive? 11:27:43 back 11:28:02 andrei-n, this looks like what you need https://www.complang.tuwien.ac.at/forth/gforth/Docs-html-history/0.6.2/Heap-Allocation.html#Heap%20Allocation 11:28:25 andrei-n: I've not needed to use or write a memory allocator in my forths 11:29:37 * tabemann wrote a memory allocator for hashforth from scratch, while on the other hand, zeptoforth lacks such a thing 11:29:44 Create and allot have sufficed 11:31:05 crc, If you have enough memory you don't have to free. You can allocate more and more. 11:31:40 MrMobius, Thanks. It seems to be a non-standard extension. 11:32:27 andrei-n, I wouldnt worry about that. everyone just does what they want when it comes to Forth. its not like C where you can compile the same source with different compilers 11:33:09 I generally use a build with 512k memory locations 11:33:34 This can be tight with large files 11:34:32 crc, I made a hashtable in PL/M on CP/M for Nand To Tetris, it had something like 30K, so it's entirely possible. 11:57:35 --- quit: Zarutian_HTC (Ping timeout: 264 seconds) 12:06:58 --- quit: karswell (Remote host closed the connection) 12:08:50 back 12:17:24 --- join: jsoft joined #forth 12:26:22 --- quit: jsoft (Ping timeout: 256 seconds) 12:31:30 --- join: karswell joined #forth 12:57:49 --- quit: gravicappa (Ping timeout: 260 seconds) 13:04:47 --- join: reepca joined #forth 13:28:31 tp: i improved my througput to 19 seconds per megabyte 13:30:18 or about 430 kilobit/second 13:34:53 --- quit: karswell (Read error: Connection reset by peer) 13:36:12 running words takes less than a second with the m3 disassembler loaded 13:41:49 but i have only implemented the stm32 -> host direction so far 13:49:53 --- quit: reepca (Read error: Connection reset by peer) 13:50:02 --- join: reepca` joined #forth 13:58:31 --- quit: reepca` (Read error: Connection reset by peer) 13:58:58 --- join: Zarutian_HTC joined #forth 13:58:58 --- quit: Zarutian_HTC (Client Quit) 13:59:05 --- join: reepca` joined #forth 13:59:13 --- join: Zarutian_HTC joined #forth 14:04:24 --- join: dave0 joined #forth 14:19:18 --- join: TCZ joined #forth 14:23:00 --- quit: xek (Ping timeout: 272 seconds) 14:25:00 --- quit: reepca` (Read error: Connection reset by peer) 14:25:15 --- join: reepca` joined #forth 15:00:28 --- quit: andrei-n (Quit: Leaving) 15:17:11 --- join: dys joined #forth 15:24:16 --- quit: cheater (Ping timeout: 240 seconds) 15:26:50 --- join: cheater joined #forth 15:46:26 --- quit: TCZ (Quit: Leaving) 16:01:56 --- quit: cheater (Ping timeout: 240 seconds) 16:04:16 --- join: cheater joined #forth 16:57:52 --- quit: WickedShell (Remote host closed the connection) 17:02:04 --- join: WickedShell joined #forth 17:28:58 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 17:29:17 --- join: Zarutian_HTC joined #forth 17:30:49 crest, wow, thats a big improvement 17:30:58 20x + 17:31:38 crest, stm32 -> host direction is going to be the fastest anyway 17:56:31 --- quit: cp- (Quit: Disappeared in a puff of smoke) 17:57:40 --- join: cp- joined #forth 18:02:06 back 18:02:14 ugh 18:02:31 working with the nRF52840-DONGLE board is such a fucking pain 18:02:46 why ? 18:03:16 they had to make everything so complex, and they seem to omit key points like where in hell is the application vectors 18:03:31 is it just at the start of the application binary? 18:03:36 if not, where? 18:03:39 I have a svd2forth for it 18:03:56 not that it helps there 18:04:03 they also had to make their installation process so complex 18:04:15 flashing you mean ? 18:04:20 yeah 18:05:49 and you have to make sure you don't overwrite the MBR at the start of flash, or else you've effectively bricked the device, unless you manage to solder a connector to the SWD pads on the bottom of the board 18:07:24 but at the same time, nrfutil only flashes the pages where code is being installed, so you have to make sure to flash the space after it (up to the bootloader code) if you want to use it for Forth 18:07:32 eww with other NRF boards you just connect the usual SWDIO, SWCLK and GND pins and use openocd as usual. 18:08:28 I think this has these, but instead of pins they are surface mounts 18:08:56 and I'm not good at soldering, and forget about surface mounts 18:09:11 --- quit: cp- (Quit: Disappeared in a puff of smoke) 18:09:21 yes, I recall the pic, those test pads are just unusable 18:09:51 tabemann, you may find this interesting at some point re NRF https://github.com/juju2013/swd-bb 18:10:21 tabemann, what you have there are 'test points' theyre not made for soldering 18:10:53 yeah 18:10:57 tabemann, theyre designed to touch a the point of a spring loaded test needle in a special jiig 18:11:21 I figured 18:11:34 tabemann, I have the pins and all the machinery to make a jig, but no nrf boards 18:12:07 looks like the $100 board was a better idea and the $10 one is hard to use ? 18:12:31 still ... the NRF chip is very impressive 18:12:41 seems so 18:13:03 tabemann, I think that if the user has no soldering skills, it's always gotta be the more expensive boards 18:13:24 I use the single chips, but one must have the skills and gear 18:13:32 provided the $100 board can be programmed with SWD out of the box 18:13:52 tabemann, agreed, and they usually have all the right connectors 18:14:10 plus didnt that one come with a bunch of cables etc 18:14:42 I didn't look at the details of the $100 board, just saw the price and passed on it 18:15:27 the $100 board is vastly cheaper than my way, Ive probably $30,000 in machinery here so I can use a $0.60 cent cpu 18:17:10 --- join: boru` joined #forth 18:17:13 --- quit: boru (Disconnected by services) 18:17:15 --- nick: boru` -> boru 18:17:18 I like my $25 boards 18:17:53 not so cheap that the quality is reduced or there are limitations like needing soldering and not too expensive either 18:19:58 theyre good value, probably the best out there 18:20:26 but they have short pins which *really* annoys me 18:20:55 I managed to deal with the short pins on the STM32 DISCOVERY boars 18:21:18 *boards 18:21:48 in comparison a Olimex board has full length pins st the top and theyre all gold plated, it also has JTAG, rs/232 and USB 18:22:07 it's a much better board, the schematic is even better 18:22:37 but it cost about 2 -3 x that of the disco board 18:23:16 in the long run, the better board is worth the extra imho 18:23:50 question 18:24:13 what is the relationship between SWD, ST-Link, JTAG, AN J-Link? 18:24:18 *and* 18:24:28 actualy the disco board pins are gold plates as well, just way too short 18:25:08 SWD is the ARM alternative to JTAG, just a protocol for flashing/testing the chip 18:25:49 st-link is the firmware used to provide the SWD protocol within a pc 18:26:00 so for a Nordic board that provides SWD, what would I use to connected that to my PC? 18:26:30 j-link, I dont really know, I think it's a commercial equivalent to st-link thats supposed to be better somehow 18:26:55 tabemann, you can use a disco board 18:27:30 tabemann, your disco board has SWD connectors on it ready to be used to connect to a chip or abother board 18:28:11 then I need to learn how SWD works - lol 18:28:13 tabemann, atm your disco board SWD subsystem is connected to the target chip on the same board with option jumpers 18:28:31 tabemann, yeah but thats easy, it's all user stuff 18:29:11 tabemann, basically you use OPENOCD with a 'mcu' and 'board' configuration 18:29:16 like this 18:31:20 openocd -f /usr/local/share/openocd/scripts/interface/ftdi/olimex-arm-usb-tiny-h.cfg -f /usr/local/share/openocd/scripts/target/stm32f1x.cfg 18:31:37 except here I'm using a olimex jtag adaptor 18:32:33 youd use stlink-v2-1.cfg 18:32:41 or something like that 18:33:34 just list the files in whatever/openocd/scripts/interface/ 18:33:42 to see what your choices are 18:34:15 then look in /usr/local/share/openocd/scripts/target/ to find what chip to use 18:34:39 after that it's just use openocs 18:34:44 openocd I mean 18:36:07 tabemann, I detail the usage here: https://mecrisp-stellaris-folkdoc.sourceforge.io/flashing-mecrisp_stellaris.html?highlight=openocd#swd 18:41:35 I see a group of six pins on my STM32L476 discovery board 18:42:39 labeled SWD V-somethingoranother SWCU GND SWDIO NRST SWO 18:42:55 are these them? 18:43:55 yes 18:44:10 there are option jumpers there ? 18:44:22 should be two of them side by side 18:44:52 they will be opposite those 6 pins (more or less) 18:45:14 that part of the disco is the SWD section 18:45:42 you actually have two systems on that board, 1) SWD system 2) STM32L476 target system 18:47:18 yes there is 18:47:53 there are two sets of settings, "DISCOVERY" and "ST-LINK" 18:49:51 use "DISCOVERY" to flash the STM32L476 and "ST-LINK" to use those 6 pins to flash a external device such as your nRF52840-DONGLE board 18:50:27 you have to switch the SWD substem to one or the other using the two jumpers 18:50:44 why are there two jumpers rather than one? 18:50:45 remove the jumpers to use those 6 pins to flash a external device such as your nRF52840-DONGLE board 18:51:24 why should there only be one ? 18:51:35 donno 18:51:45 that seems to imply that one could be off and one could be on 18:51:52 why do you have 2 legs rather than one ;-) 18:52:28 no, both option jumpers are removed together, or instanned together 18:52:36 installed 18:52:37 I figured that 18:53:03 the fact that a disco/nucleo has a complete SWD interface makes them even better value 18:53:19 se the chip in the SWD section ? 18:53:26 yeah 18:53:37 thats a STM32F103 ... same as in the 'blue pill' 18:54:20 and I remember reading something a while back about people turning blue pills into ST-Link programmers 18:54:28 exactly 18:55:26 there are a number of firmwares that claim to do that but theyre a bit dodgy imho because people want to sell the hardware not give the fw away 18:55:49 i tried it once and couldnt get it working, was a uggly mess 18:56:18 tabemann, oh, you can also use a RPI as a SWD/JTAG programmer 18:56:33 there are much friendlier FW around for thiose 18:56:41 they also include a gdb server etc 18:56:54 whereas blue pills aren't very friendly devices 18:57:09 tabemann, no, theyre pretty junky 18:57:27 but the easiest device is the one on your disco board 18:57:36 it's all set and ready to go 18:57:48 yeah 18:58:29 so you just take each pin of those six on the DISCO board and use a jumper cable to hook it up to the matching pin on the target? 18:58:30 pull the jumpers, wire 4 wires I think, +v,0v, signal and clock, reset and youre good to go 18:58:47 ill check 19:01:49 tabemann, this looks interesting ? 19:01:52 https://devzone.nordicsemi.com/f/nordic-q-a/25393/using-stm32-disco-board-for-flashing-a-custom-nrf52832-chip-with-keil 19:02:55 tabemann, this is the tech wiring for what you need: https://geekilyinteresting.wordpress.com/2014/05/04/using-your-stm32f4-discovery-board-as-a-programmer-and-debugger/ 19:03:11 bbl, gtg shopping 19:37:12 --- quit: dave0 (Quit: dave's not here) 20:08:30 --- join: warriors joined #forth 20:10:44 --- part: warriors left #forth 20:48:28 bak 20:52:04 wb 20:52:17 * tabemann has been reorganizing his documentation for zeptoforth 20:53:26 cool 20:54:07 the only issue I have is that the level-5 headers with code strings appear correctly in github markdown, but in recommonmark markdown the headers just seem too big 20:54:35 I could make them just code strings, but then the user wouldn't be able to link to the strings themselves 20:56:04 that's my only gripe w.r.t. sphinx + recommonmark 20:58:53 with github markdown the headers are just bolded some relative to normal code strings 21:07:13 could it be your browser settings ? 21:08:37 nah - I'm viewing the two on the same browser 21:14:30 well github is probably wrong 21:14:47 I know that most github pages dont render properly for me 21:15:01 most are unreadable 21:15:30 okay, sphinx+recommonmark are converting my level-5 headers to level-2 headers 21:18:00 whereas github is keeping them as level-5 headers 21:21:40 --- quit: WickedShell (Remote host closed the connection) 21:26:47 honestly many github sites are unreadable for me 21:26:59 they have been for a long tim 21:27:20 the fonts are widely spaced or too big or whatever 21:27:40 I hardly ever browse github sites 21:30:02 I haven't had any problems with github sites myself 21:30:32 are you sure this isn't a font problem? 21:31:29 okay, I should hit the sack 21:31:32 g'night 21:31:42 i dont know, but i never have that problem anywhere else 21:31:48 gnight tabemann 21:32:42 --- join: jsoft joined #forth 22:14:09 --- join: cp- joined #forth 22:14:27 --- quit: cp- (Client Quit) 22:16:09 --- join: cp- joined #forth 22:17:11 --- quit: cp- (Client Quit) 22:18:07 --- join: cp- joined #forth 22:32:24 --- quit: dddddd (Ping timeout: 260 seconds) 22:33:54 --- join: dave0 joined #forth 23:05:03 --- join: antaoiseach joined #forth 23:05:38 --- quit: dys (Ping timeout: 256 seconds) 23:18:42 --- nick: reepca` -> reepca 23:21:36 --- join: TCZ joined #forth 23:22:40 --- quit: TCZ (Remote host closed the connection) 23:23:16 --- join: TCZ joined #forth 23:23:21 --- quit: TCZ (Remote host closed the connection) 23:24:35 --- join: TCZ joined #forth 23:25:03 --- join: mtsd joined #forth 23:25:59 --- quit: TCZ (Client Quit) 23:27:06 --- join: TCZ joined #forth 23:31:37 --- join: andrei-n joined #forth 23:33:58 --- quit: proteus-guy (Ping timeout: 256 seconds) 23:35:36 --- quit: reepca (Read error: Connection reset by peer) 23:35:52 --- join: reepca joined #forth 23:55:59 --- join: dys joined #forth 23:59:59 --- log: ended forth/20.05.25