00:00:00 --- log: started forth/20.06.08 00:08:08 --- quit: dddddd (Ping timeout: 260 seconds) 00:37:55 --- join: xek_ joined #forth 00:44:40 --- quit: xek_ (Read error: Connection reset by peer) 00:44:52 --- join: xek joined #forth 00:53:33 --- quit: jedb (Remote host closed the connection) 00:53:49 --- join: jedb joined #forth 00:59:03 --- join: xek_ joined #forth 01:01:11 --- quit: xek (Ping timeout: 246 seconds) 01:08:02 crest, ping 01:50:53 --- quit: xek_ (Ping timeout: 246 seconds) 01:54:03 --- join: xek_ joined #forth 02:13:21 pong 02:13:52 crest, you dont have a STM32 discovery or nucleo board do you ? 02:14:23 crest, you only have bluepills ? 02:14:27 yes 02:14:30 why? 02:15:01 I have sedcom running on a stm32F0 discovery and it's very nice :) 02:15:07 swdcom 02:15:28 the disco board has the swd interface on the board 02:16:09 so swdcom makes a very easy terminal for a disco or nucleo board 02:17:31 --- quit: xek_ (Ping timeout: 258 seconds) 02:17:32 Mecrisp-Stellaris RA 2.5.3 with M0 core for STM32F051 by Matthias Koch 02:17:33 The swd buffer address is: 20001D58 02:20:09 crest, also tabemann tried it but his Linux bombed on stm32.h which my system doesnt even have anyway 02:20:53 did he have stlink 1.5 installed? 02:21:38 did he try it on a debian based distro? those stupid fuckers split most packages into a few tiny headers and the rest "to safe space" 02:21:51 it's debian and looks broken 02:22:10 hahah a 'safe space' LOL 02:22:46 i dont know what stlink he has 02:23:10 its about a stupid has handing kids dull knives for carving because the sharp ones are too dangerous 02:23:17 yeah 02:23:17 *it's 02:23:33 yet it's the 'dull knife' that actually cuts ;-) 02:23:45 exactly because you have to use force 02:23:49 yes 02:24:57 ah well use debian and pay the price 02:26:26 tp: the realtime clock code? that works on linux as well 02:26:44 crest, I've just written a word that takes the output from swd and binks the green led the digit number of times 02:26:49 or did you mean the stm32f103 clock setup 02:27:25 crest, tabemann couldnt compile the C code 02:27:55 it complained about not finding stm32.h 02:28:26 crest, we ignore the mcu clock stuff 02:30:26 crest, damn swdcom is fast, at 72MHz on my F0 I think it's faster than my 460800 baud serial 02:30:43 hard to say, definitely not slow 02:31:11 i did spend some time thinking about how to minimize latency and maximize throughput 02:31:34 under the assumption that stlink v2 commands have an annoying latency 02:32:03 and larger transfers are faster (per byte) than more smaller transfers 02:32:20 crest, so my idea is to use the discovery board user push button to read the swd buffer address via the green user led, therby negating the need for a serial terminal 02:33:11 you could also put the buffer definition in the assembler code 02:33:12 crest, Ive also built a bootable binary with your swdcom included 02:33:39 and extract the address from the symbol file 02:34:00 actually .. you could put the buffer address in a USB parameter 02:34:16 um no, forget that 02:34:39 or maybe there is some "spare" configuration register in the debug unit? 02:34:42 there is no usb driver on the disco boards 02:34:59 that's mcu dependent 02:35:00 some well known place in memory to put the pointer 02:35:18 hmm 02:35:34 blinking the led like a automotive fault code is easy enuf 02:35:45 i can read it no problems 02:36:01 i could fill the ring buffers with pseudorandom data 02:36:13 dump the sram and at connection time 02:36:22 and search for the pattern 02:37:04 crest, I think you have winner if you can also make a uploader and any other bells would be a bonus 02:37:07 how likely is it that some other 512 byte buffer satisfies the function? 02:37:30 i dont understand your statement 02:38:24 the startup code could fill the rx and tx ringbuffer with some pattern start with 0x12345678 and each word is the crc32 of its predecessor 02:39:17 than i could just scan the sram until i find 0x12345678 followed by $n times the crc32 of itself 02:40:24 ahh 02:40:48 i could even keep a cache of the last buffer address per stlink serial number 02:41:02 and start the search at that address the next time 03:10:36 --- quit: jedb (Ping timeout: 260 seconds) 03:18:27 --- join: deesix_ joined #forth 03:20:48 --- quit: deesix (Ping timeout: 272 seconds) 03:23:26 --- join: deesix joined #forth 03:23:52 --- quit: deesix_ (Ping timeout: 256 seconds) 03:28:11 --- quit: deesix (Ping timeout: 246 seconds) 03:30:35 --- quit: jsoft (Ping timeout: 272 seconds) 03:33:38 --- join: deesix joined #forth 03:38:41 --- join: deesix_ joined #forth 03:39:10 --- quit: deesix (Ping timeout: 258 seconds) 03:43:04 --- quit: deesix_ (Ping timeout: 260 seconds) 03:43:40 --- join: deesix joined #forth 04:04:53 --- join: iyzsong joined #forth 04:37:26 --- join: kori joined #forth 04:37:26 --- quit: kori (Changing host) 04:37:26 --- join: kori joined #forth 05:03:04 --- join: TCZ joined #forth 05:17:05 --- join: jedb joined #forth 05:35:59 --- quit: a3f (Ping timeout: 260 seconds) 05:38:42 --- join: a3f joined #forth 06:13:23 --- join: dddddd joined #forth 06:20:55 --- quit: mtsd (Quit: Leaving) 06:25:05 --- join: Blue_flame joined #forth 06:25:26 --- nick: Blue_flame -> Guest68669 06:33:17 --- quit: TCZ (Quit: Leaving) 06:33:58 --- quit: a3f (Ping timeout: 256 seconds) 06:35:34 --- join: a3f joined #forth 06:46:01 --- quit: cantstanya (Remote host closed the connection) 06:48:31 --- join: cantstanya joined #forth 07:01:40 --- quit: iyzsong (Quit: ZNC 1.8.0 - https://znc.in) 07:06:01 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 07:06:23 --- join: Zarutian_HTC joined #forth 07:07:39 crest 07:07:46 pong? 07:07:50 even when I solved the stm32.h problem 07:07:55 by commenting that line out 07:08:03 and I fixed some other header problems 07:08:07 thanks to debian 07:08:28 it still just wouldn't compile, with lots of missing identifiers 07:08:37 also I had to move sys/endian.h to endian.h 07:08:45 in that case thank debian for their great packaging work 07:08:57 sure sys/endian.h is bsd specific 07:09:14 a short ifdef block around the include would fix that 07:09:32 I think most of the other issues I saw were probably Linux versus BSD issues 07:09:53 what else? 07:10:10 the endian.h is trivial to fix (for a c programmer) 07:10:43 it is just used once for le32toh() which is a no-op on all my x86 systems anyway 07:11:07 actually, it seems to complain a lot about struct timespec not existing 07:11:27 isn't it enough to include time.h? 07:12:22 it seems it should... 07:13:31 it also says it can't find clock_gettime 07:14:13 I do need to get ready for work though, so I'll be back on later 07:14:19 https://linux.die.net/man/3/clock_gettime 07:14:50 according to this clock_gettime is declared in time.h and should be part of glibc 07:14:56 I know, time.h should include it 07:15:19 but maybe not the uptime clock 07:15:27 in that case CLOCK_MONOTONIC could be used 07:17:11 okay 07:17:15 well, I do need to go 07:17:21 see ya later 07:17:27 an other ifdef could hide that 07:25:45 --- join: crc_ joined #forth 07:40:47 --- quit: Zarutian_HTC (Ping timeout: 264 seconds) 08:01:14 --- join: antaoiseach joined #forth 08:01:17 --- quit: antaoiseach (Client Quit) 08:07:47 --- join: Zarutian_HTC joined #forth 08:16:09 --- quit: kori (Quit: WeeChat 2.8) 08:37:06 --- nick: Guest68669 -> Blue_flame 08:43:29 --- quit: jedb (Ping timeout: 260 seconds) 08:53:40 --- quit: Chobbes (Changing host) 08:53:41 --- join: Chobbes joined #forth 08:56:22 --- join: X-Scale` joined #forth 08:58:04 --- quit: X-Scale (Ping timeout: 265 seconds) 08:58:04 --- nick: X-Scale` -> X-Scale 09:16:47 --- join: WickedShell joined #forth 09:25:37 --- join: andrei-n joined #forth 09:32:18 --- join: TCZ joined #forth 09:44:09 --- quit: dys (Ping timeout: 260 seconds) 10:33:10 --- quit: Zarutian_HTC (Ping timeout: 258 seconds) 10:37:00 --- join: remexre joined #forth 12:19:35 --- join: xek joined #forth 12:25:47 --- quit: xek (Ping timeout: 264 seconds) 12:32:17 --- quit: TCZ (Quit: Leaving) 12:36:05 --- join: dys joined #forth 12:56:35 tabemann: did you get it working? 13:01:13 --- join: TCZ joined #forth 13:52:36 --- join: Zarutian_HTC joined #forth 13:56:59 --- join: Zarutian_HTC| joined #forth 13:57:15 --- quit: Zarutian_HTC (Ping timeout: 265 seconds) 13:59:50 --- join: Zarutian_HTC joined #forth 14:00:03 --- quit: Zarutian_HTC| (Read error: Connection reset by peer) 14:02:36 --- quit: reepca (Read error: Connection reset by peer) 14:03:12 --- join: reepca joined #forth 14:06:41 --- join: Zarutian_HTC| joined #forth 14:08:20 --- quit: Zarutian_HTC (Ping timeout: 246 seconds) 14:12:35 --- join: Zarutian_HTC joined #forth 14:12:47 --- quit: Zarutian_HTC| (Read error: No route to host) 14:12:53 --- join: Zarutian_HTC| joined #forth 14:12:53 --- quit: Zarutian_HTC| (Client Quit) 14:16:44 --- quit: Zarutian_HTC (Ping timeout: 246 seconds) 14:46:52 --- quit: gravicappa (Ping timeout: 260 seconds) 15:09:07 --- join: Zarutian_HTC joined #forth 15:28:12 --- quit: crest (Read error: Connection reset by peer) 15:28:31 --- join: crest joined #forth 15:47:50 tp, tabemann: i encountered data corruption on fast tranmissions from the host to the microcontroller 16:05:34 --- quit: andrei-n (Quit: Leaving) 16:07:08 --- quit: TCZ (Ping timeout: 260 seconds) 16:07:27 --- join: dave0 joined #forth 16:26:15 --- join: X-Scale` joined #forth 16:26:36 --- quit: X-Scale (Ping timeout: 258 seconds) 16:26:58 --- nick: X-Scale` -> X-Scale 16:36:47 the swd2.c code you tried has nasty bug causing data corruption 16:37:10 my tired mind calculated padding for the end twice instead of for the front and end once each 16:37:18 resulting in aligned writes 16:43:01 ok i fixed it 16:43:36 the latest code adds support for pipes and files as input to swdcom 16:43:48 instead of just ttys 16:44:59 --- quit: reepca (Read error: Connection reset by peer) 16:45:19 --- join: reepca joined #forth 16:45:56 oh and it shuts down cleanly on end of file, pipe close and ctrl+d 16:52:17 --- quit: Blue_flame (Quit: authenticating) 16:52:25 --- join: Blue_flame joined #forth 17:05:40 tp: compiling the m3 disassembler from a file into sram takes about 1.424 seconds on my laptop with swdcom 17:07:36 uploading an empty file takes 0.011 seconds 17:07:36 --- quit: reepca (Read error: Connection reset by peer) 17:07:54 --- join: reepca joined #forth 17:07:55 this is without comment stripping 17:09:55 tp: would you be willing to run a comparison on your setup with a 400k baud serial and hardware flow control? 17:10:08 bak 17:10:14 crest sure 17:11:48 oh that's with my slower fallback swd-key 17:12:52 crest, the m3 dissasembler upload seemed a bit slow 17:13:02 why? 17:13:14 crest, I'll set up here to properly time things 17:13:34 i timed with the zsh time builtin 17:13:43 1.4 seconds seems slow but I dont have any hard timings yet 17:14:09 i don't expect much difference 17:14:43 I trued timing with screen but it didnt work for some reason 17:15:33 crest, have you updated your repo ? 17:16:00 that's what i was doing before you replied 17:17:20 cool, ill try it shortly 17:19:40 committed and pushed 17:20:34 for now you have to use i/o redirection to use regular files and pipes 17:20:56 e.g. swd2 $add < foo.fs 17:21:21 thats no problem 17:21:44 i want to add a better interface 17:24:19 but before that i have to cleanup the code a little more 17:24:46 adding support for pipes and regular files made a mess out of produce() 17:24:48 there isnt a lot of code there 17:25:29 ? 17:25:51 did you execute "git pull" 17:26:19 i havent got to it yet 17:26:53 how do you access swd from your code, it's a mystery to me 17:27:08 I dont see any swd memory maps 17:27:23 i mean the SWD interface 17:28:18 ? 17:28:44 youre talking to the chip via the SWD interface ? 17:28:50 yes 17:29:21 yet swdcom seems not to know anything about the swd peripheral ? 17:29:46 i reuse the existing code in libstlink-shared.so from the stlink package 17:30:28 all my code does to talk to the stm32 through the stlinkv2 is call a few library functions 17:30:51 stlink_open_usb() to get a handle to the stlinkv2 17:31:02 ahh and the target micro just responds to the swd programmer ? 17:31:36 because it's hardwired to do that 17:31:37 the debugging hardware inside the blue pill (or other target) responds to the stlinkv2 17:31:59 there is no setup needed because the defaults are to allow debug access 17:32:12 I'm using a STMicro F0 Discovery here, I'm not using a blue pill 17:32:42 and it works perfectly 17:32:58 as long as you have 2 * 256 + 4 bytes of sram for the buffer it should work 17:33:15 https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32-boards.html?highlight=discovery#stm32f0-discovery-board 17:33:37 the F0 has 8KB of ram 17:34:17 I'll measure the free ram before after swdcom is installed nextime 17:34:35 in that case dedicating 516 byte to i/o buffers hurts a lot more 17:34:37 cortex-m units have plenty of ram 17:35:11 nah, it's not a problem for me 17:35:37 i never run short of ram 17:36:02 techs and their puny code bases :-P 17:36:05 Mecrisp-Stellaris takes abut 1.5KB of the ram 17:36:41 yeah, I just make real world things work, I'm not generating bitcoins on my micro 17:38:02 I designed and sold a bunch of solid particulate level detectors about 20 years ago that used a PIC micro with 1K flash and 78 bytes of ram. I had plenty of each left over 17:38:27 those units were still in use a decade later 17:39:08 why change a working system? 17:45:20 you can think of the ring buffers of the two arrays they are 17:45:32 and my swdcom as a special purpose debugger 17:46:06 crest, almost 3am again! 17:46:08 it just polls one of the array and writes to the other 17:46:27 crest I've githubbed and I'm setting the test up with your new code 17:49:55 this version shouldn't transpose your source code in garbage 17:50:01 (during fast uploads) 17:53:07 nerly ready to test 17:56:16 it takes me a while because I have to reflash a new Mecrisp-Stellaris, edit your code, load it, make a binary then test 17:56:59 Ram Total:8192 Used:2080 Free:6112 17:57:22 Mecrisp-Stellaris RA 2.5.3 with M0 core for STM32F051 by Matthias Koch 17:57:22 The swd buffer address is: 20001D58 17:58:46 ok. 17:58:46 words4 17:58:47 --- Mecrisp-Stellaris RA 2.5.3 --- 17:58:47 2dup 2drop 2swap 2nip 17:58:47 2over 2tuck 2rot 2-rot 17:58:47 2>r 2r> 2r@ 2rdrop 17:58:54 looks as fast as beore 17:59:04 :) 18:00:55 i did nothing that should make it slower to fix the bug 18:01:14 Ill try a file upload 18:01:31 will I need to exit the terminal first ? 18:03:46 yes 18:03:59 you have to press ctrl + d to get out of swd2 correctly 18:04:15 oh 18:04:32 ctrl+c isn't caught and kills swd2 without a clean shutdown 18:04:43 this can cause problems the next time 18:05:11 it's probably a cooincidence but I note that stlink no longer works on this machine, Ive had to flash via serial bootloader 18:06:35 it could be stuck because you killed swd2 the "wrong" way 18:06:52 if it writes a core file the stlink hasn't been properly released 18:07:13 but in the last version killing it the wrong way was the only way 18:07:23 because the correct ways hadn't been implemented yet 18:08:32 aha 18:09:06 serial is at least a easy way and works with openindiana 18:09:23 i don't know if there is a good way to recover from this without unplugging the stlink 18:09:27 but youre right, open solaris is dead 18:10:00 looks like I'll stay with freebsd, I think it's the only choice now 18:10:14 (if one must have ZFS) 18:10:31 unplugging is no problem 18:10:37 zfs on linux is a thing 18:10:46 not bootable zfs 18:10:58 it's possible 18:11:09 openzfs is incompatible with the gpl 18:11:18 not a problem 18:11:26 yeah, it's possible to mate a horse and a donkey but not easy 18:11:29 you're just not allowed to distribute the result 18:12:09 have you converted a Linux distro to bootable openzfs ? 18:12:19 it's not trivial 18:12:35 no but i know several people booting arch from zfs for years 18:12:38 --- join: jedb joined #forth 18:13:35 yeah but arch users are used to that kind of stuff 18:13:53 your average debian user would find it daunting 18:14:22 my opinion of the average debian and ubuntu user isn't printable 18:14:28 sure having ZFS filesystems in Linux is trivial, they have packages for it 18:14:32 hahah 18:15:29 Closing ST-LINK/V2 handle. 18:15:38 that sounds good 18:17:40 swd2 $add < gcd.fs 18:17:40 add: Undefined variable. 18:17:53 hmm why is $add there ? 18:18:07 it should read $addr 18:18:24 its the base address of the buffer printed to the serial console before the switch 18:19:11 oh! 18:21:10 wow that uploaded fast 18:21:30 i had a lot of comments in that file 18:21:40 what did you try? 18:21:53 just a small gcd function? 18:23:07 http://dpaste.com/1B26V91 18:24:20 I had errors because of a missing ms.counter.reset which I didnt see of course 18:24:46 but when I opened swdcom terminal I saw them 18:25:22 compiling to flash raises the upload time from 1.3 seconds to 1.8 seconds for the m3 disassembler 18:25:35 i only uploaded into ram 18:25:43 compiled to ram rather 18:25:57 writing to flash slows down the compiler a little 18:25:58 i always do that first and during dev 18:26:02 yes 18:26:12 but thats not swdcoms fault 18:26:20 of course not 18:26:47 it is fast enough to expose the flash as bottleneck 18:26:48 and the m3dissasembler has a lot of stuff to compile 18:27:05 yes, flash is always the slow part 18:27:27 it's better to use ram in measurements as flash varies between mcu's also 18:27:29 it is one of the largest forth files in the mecrisp stellaris release 18:27:34 it is 18:27:47 i wanted to know by how much it slows down uploads 18:28:07 I rarely load the m0dissasembler as it takes up so much space in my tiny stm32f051 18:28:31 about 10k for the m3 disassembler 18:28:39 yeah 18:28:48 proving how complex the damn thumb2 isa is 18:28:49 but I only load what I need 18:29:05 well anything with a lot of text takes up space 18:29:12 it's a good that thing that risc-v is so boring compared to that 18:29:23 just about 50 instructions for the base isa 18:29:35 with a lot fewer special cases 18:29:40 my next version of svd2forth will separate the text legends from the memory maps to save space 18:30:04 it is really boring, just reading source put me to sleep 18:30:20 but for now swdcom is useable 18:30:28 it sure is! 18:30:49 even if there are a lot of possible improvements on my mental roadmap 18:30:53 i may send your name to the Nobel Committee for this! 18:31:31 be really nice to get the errors back when uploading 18:32:09 that's close to the top 18:32:26 Ive made a bootable binary with your latest swdcom for the F0 18:34:03 as much as I dont care I should ask do you want to do anything about the Linux issue with compiling swd2.c ? 18:34:34 yes 18:34:51 maybe make and distribute a Linux binary swd2 ? 18:35:11 the patch to fix everything tabemann mentioned should be between 10 and 20 lines 18:35:25 if you do then I can put swdcom on my website for people to try *if you want* ? 18:35:43 and then you can get feedback *if you want( 18:35:57 i just need a linux tester 18:36:07 only one ? 18:36:17 yes 18:36:26 you may get a few if it's on my website 18:36:48 I have 47 readers ;-) 18:36:53 oops 42 18:37:06 and it looks like tabemann volunteered 18:38:04 he had a good try and discovered what crap debian is nowadays 18:38:58 your uploader is pretty spectacular 18:39:15 the package maintainer probably never tried to use the shared library to compile anything from outside the package 18:39:26 it gets the job done 18:39:42 probably a non coder like me with zero clue 18:39:52 but relies on a tiny patch of the forth kernel 18:40:31 to inject a ACK to "ok. " in quit 18:40:36 I can put that up with a article about swdcom also if you like 18:40:43 and a NAK to all compiler errors 18:41:12 as long as you warn your readers how sharp the edges are 18:41:19 that will make tabemann happy he loves ack/naks 18:41:33 it's your choice, this is your development 18:41:50 warn Forth users aboyt sharp edges ... really ? 18:41:51 not really. i put it on public github repo 18:42:11 if anyone is impervious to sharp edges it's Forth users 18:42:27 sure but this one just a proof of concept so far 18:42:37 like most forths :) 18:42:51 there is no way to upload files without disconnecting the interactive console yet 18:42:59 i must say swdcom is looking pretty robust so far 18:43:21 and thats still ok as long as errors can be seen during upload 18:43:25 hey guys 18:44:00 hey tabemann, I just tested the latest swdcom doing a Forth source upload .... fast! 18:44:19 tp: that's what happens handle all errors returned by library functions 18:44:27 *when you handle 18:44:30 tp: cool! 18:44:42 tabemann, but beware, swdcom may set your pc on fire, curdle your milk and make your curtains turn yellow! 18:44:50 lol 18:45:26 tp: i just don't want to disappoint potential users 18:45:52 tabemann, I also have swdcom running on a F0 Disco, piece of cake! 18:46:22 tabemann, all it needs is a usb connection to the SWD programmer section of the board for a fast terminal 18:47:16 tabemann, kind of like a USB virtual terminal, except it's connected to the SWD programmer and the FO Disco MCU has no USB 18:47:46 crest, lets call then 'beta testers' 18:47:59 I'm a SWDCOM 'beta tester' 18:48:20 there is no beta (yet) 18:48:37 it's very refreshing not to have to worry about EOL delays 18:48:49 Im a ceta tester 18:49:26 https://next.rlwinm.de/s/kMmcPeqj5pk5egs 18:49:32 this is my dev system 18:50:13 a stlink clone hooked up to the swd connector of a blue pill board 18:51:20 how well do you know the stm32 usarts? 18:51:38 are all the registers writable? 18:51:47 or are there a read only registers? 18:52:07 let me show you ? 18:52:14 i'm asking because i'm wondering if would it be possible to bootstrap by writing to the usart registers 18:53:02 use the stlink to write to the usart registers 18:53:30 and let serial-key? and serial-key read them into the compiler 18:53:45 MUHAHAHA 18:54:02 * crest evil laughter 18:54:17 http://dpaste.com/2J2NF5X 18:54:40 wow, thats a evil thought! 18:54:49 hey! 18:55:22 I got it to build with: gcc -O0 -g -I/usr/local/include -L/usr/local/lib -o swd2 swd2.c -lstlink 18:55:36 crest your home setup is pretty horrible 18:55:44 with CLOCK_UPTIME_FAST replaced with CLOCK_MONOTONIC_COARSE 18:55:51 tabemann, awesome! 18:55:58 and #include replaced with #include 18:56:17 did you pick the latest version form half an hour ago? 18:56:23 tabemann never gives up! 18:56:31 because the version from last night had data corruption bug 18:56:34 crest: yes 18:56:56 tabemann, and quit the terminal with ctrl-d or your pc will explode 18:57:24 tabemann, ctrl-c will make the pc explode 18:57:28 it won't explode 18:57:36 ok .. catch fire 18:57:46 at worst you have to unplug the stlink 18:57:52 and reconnect it to get it working 18:58:07 and only because i don't know how to reset the debugger without resetting the target 18:58:20 crest, which I had to do the first time I ctrl-c the terminal 18:58:22 i hope that it's possible 18:59:13 crest I also remove your 'reset' as the last command as init will take effect after the board is reset 18:59:31 --- join: boru` joined #forth 18:59:34 --- quit: boru (Disconnected by services) 18:59:36 crest, that way I can build a binary before I reset the board 18:59:36 --- nick: boru` -> boru 19:00:48 crest, pLus all your clock stuff is extranious and mcu dependent, I remove all that as my mcu has all that set up anyway 19:01:32 crest, for instance tabemann's mcu will be set up to do 120mhz 19:01:45 i wanted everything to bootstrap from a mecrisp stellaris 2.5.3 stm32f103-ra image to swdcom in a single file 19:02:03 back 19:02:15 and sure it works with the default 8mhz 19:02:16 crest, sure, but why limit swdcom to a old obsolete F103 ? 19:02:25 because its all i have available for testing 19:02:45 *it's 19:02:58 you can always get more DISCOVERY boards 19:03:08 the two DISCOVERY boards I own costed like $25 each 19:03:14 crest, so just use the default 8mhz ? 19:03:33 crest, only windows users have blue pills 19:03:35 ;-) 19:03:45 tp: i'm not falling for that 19:04:14 crest and Do you know wether you *actually* have bonafide F103's in that board ? 19:04:24 no 19:04:54 crest, it's true, 60% of my blue pill diags binary are windows users 19:05:08 i have stats to prove it 19:05:14 i have some mystery chip on a board that cost less with shipping in packs of 5 than 5 chips should cost 19:05:29 yeah, Chinese clones 19:05:42 Chinese clones that arent 100% compatible 19:08:42 according to the datasheet the RXNE bit can only be cleared 19:09:47 that puts an end to my evil plat to bootstrap that way 19:09:51 back 19:10:51 my question is that, unless one is manufacturing products in volume, why care about whether they are cheaper than dirt 19:11:44 * tabemann does not miss the money he spent on his two DISCOVERY boards 19:12:10 because i didn't know what i wanted do with them before i ordered them 19:12:20 whereas I'd be so pissed if something broke, and after spending hours debugging it, it turned out to be due to some cheapass chinese clone 19:12:32 i just had the general idea that i wanted to play with arm boards 19:12:48 and they're small throwaway computing units 19:12:51 whereas I had the specific aim of creating a Forth implementation targeting these chips 19:13:03 crest if you dl and run my binary you can determine what chip you have: https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f1xx-diagnostics.html#stm32f103xx-diagnostics 19:13:56 crest, the F103 is 16 years old, it's a obsolete cortex-m 19:14:07 thx for telling me ... 19:14:09 ... again 19:14:24 what would you recommend as replacement? 19:14:44 get an L476 or an F407 19:14:50 hahahah 19:14:55 total overkill 19:15:34 what's the difference between the two? 19:15:52 crest, there are hundreds of cortex-m from the smallest and slowest to monsters, how can anyone advise you, it depends what your requirements are 19:16:13 L476 is lower power, with a whole power control system, whereas F407 is fast 19:16:35 for a start, the latest stuff is the "G" series, tabemanns gear is obsolete already 19:16:55 the G embodies the best of the F and L range 19:17:21 $3 gets you a 200+ pin MONSTER G mcu 19:17:28 208 MHz 19:17:33 2MB flash 19:17:47 you can't argue with that for 3 bucks 19:17:58 something small and cheap enough to leave in projects, supported by mecrisp stellaris 19:18:19 or in my case I paid $0.65 each for 480 STM32F051's in 2014 19:18:35 and i don't want to run out of resource too quickly while learning 19:18:59 lets say at least 32kB ram and 128kB flash 19:19:03 me doesn't regret buying getting MCUs with 1 meg flash 19:19:18 whoops 19:19:22 lol, Ive been learning the peripherals of my STM32F051 since 2016 and Im only about 60% proficient 19:19:36 * tabemann doesn't regret getting MCUs with 1 meg flash 19:19:45 tabemann, is right, the extra flash is a bonus when learning 19:20:11 crest, https://mecrisp-stellaris-folkdoc.sourceforge.io/supported-hardware.html#supported-hardware 19:20:59 crest, any cortex-m is supported really, but if it's not on that list then you may have to set up the flash and the serial port 19:21:09 unless you use swdcom!!! 19:21:39 then you may still need to code the flash support in assembly 19:23:09 crest, how about a STM32G071RB 19:23:24 it's a cortex-m0 19:24:23 https://www.st.com/en/evaluation-tools/nucleo-g071rb.html 19:25:00 the NUCLEO-F446RE is available for 17€ 19:25:28 with 512kB flash and 128kB sram 19:26:10 and it will *utterly* blow the blue pill away in every area 19:26:18 but it's not on the list 19:27:27 then there is no ready made Mecrisp-Stellaris for it 19:28:04 really, coding up support for a new arch in mecrisp-stellaris is pretty simple 19:28:08 tp: https://www.amazon.de/NUCLEO-F103RB-Entwicklungskit-STM32F103RB-STMicroelectronics-integriert/dp/B0121QTVV4/ref=sr_1_6?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&dchild=1&keywords=STM+F4+Discovery&qid=1591669644&quartzVehicle=1820-1194&replacementKeywords=stm+f4&sr=8-6 19:28:10 scnr 19:28:42 * tabemann versteht nur ein bisschen Deutsch 19:29:07 haahh a f103 nucleo, youd have to be mad 19:29:23 I have no problems with long urls 19:30:10 crest, the F4 seris are the heavy duty MCU's they are faster, bigger, much higher end 19:30:43 I dont need them for any of my real world projects 19:30:50 but how much harder are they to configure? 19:30:58 no harder 19:31:08 the only real disadvantages to the F4 are if you want lower power or you want nicer flash erasure characteristics 19:31:10 just more of everything 19:31:17 are there breakout boards to allow people to play with them 19:31:23 * tabemann finds the L4s and the F4s to be equally easy to configure 19:31:23 and tabemann is the F4 expert here 19:31:42 * tabemann hates the F4's huge flash sectors 19:31:46 crest, any discovery or nucleo board is a breakout board 19:32:10 both of my DISCOVERY boards come with loads of pins to attach things to 19:32:16 crest, they are all easy once one gets used to cortex-m 19:33:00 the f0 series are for small projects that only need 33 onboard peripherals bwah! 19:33:19 fundamentally the main things that differ between Cortex-M chips are A) the flash controller B) the U(S)ARTs C) whether they support thumb-2 and D) how much flash and RAM they have 19:33:28 a F7 has 97 thats *NINETY SEVEN* onboard peripherals ! 19:33:59 tabemann, has summarised it very succinctly 19:34:04 and yes, whether they have fuckloads or fuckloads upon fuckloads of peripherals 19:34:11 hahah 19:34:43 STM32F7x7 93 peripherals 2093 registers 17051 bitfields 19:35:11 one cant even visualise ho many bitfields 17051 are 19:35:13 this is what svd2forth exists for 19:35:19 exactly 19:36:22 tabemann, my next version separates the pretty printing parts from the memaps so a user can choose what they want to save space 19:39:02 HAHA 19:39:06 it's alive! 19:39:18 crest 19:39:26 I got swdcom working with zeptoforth! 19:40:23 how awesome!! 19:40:24 tp: is there anything wrong with a NUCLEO-F401RE? 19:41:41 crest I'm getting the datasheet now 19:48:24 ARM® Cortex®-M4 32b MCU+FPU, 105 DMIPS, 19:48:25 512KB Flash/96KB RAM, 11 TIMs, 1 ADC, 11 comm. interfaces 19:49:10 looks fairly standard, older model (like tabemanns gear ;-) 19:49:19 $13 tho :) 19:49:31 it's a massive bargain compared to a blue pil 19:49:50 i can get a NUCLEO F411RE for the same price 19:49:54 also has a SWD programmer at one end like all disco/nucleos 19:50:05 blue pills're cheaper, but with cheaper you get fewer features and worse quality 19:50:16 and no swd programmer 19:50:20 yeeah 19:50:23 fewer pins 19:50:31 you want the integrated swd programmer 19:50:41 so you can just hook up your board with USB 19:50:44 and program right away 19:50:45 they only exist for windows users like crest ;-) 19:51:02 without fussing with an external SWD programmer 19:51:30 yeah, but how will crest survive without arduino for the bluepill ??? 19:51:48 tp: well, for a windows user I am impressed by swdcom - lol ;) 19:51:53 for many hobbysists arduino is a lifeline 19:51:57 i haven't installed the arduino in over a decade 19:52:03 and hated it back than 19:52:14 we're not being serious, crest 19:52:20 sorry crest, I'm joking, youre a l33t hacker to me 19:52:43 but seriously, swdcom is niice 19:53:04 i just want something that will run mecrisp without porting 19:53:08 tp programming level - 1 ; crest programming level - 1000+ 19:53:21 because i don't want to spend time on that 19:53:31 crest that NUCLEO-F401RE? will absolutely rin Mecrisp-Stellaris withut porting 19:53:31 crest: there's tons of chips and boards mecrisp supports 19:53:45 supporting the register allocator would be nice as well 19:53:57 tabemann, crest has the supported hardware list 19:53:58 is there a reason why so few targets have a -ra suffix 19:54:10 or you could always invest in an L476 or F407 and install zeptoforth ;) ;) ;) 19:54:30 only that the binary hasnt been made for that chip, it's a compile time option 19:54:41 ok 19:55:07 as Mecrisp-Stellaris comes with premade and ready to run binaries 19:55:07 and getting the toolchain for arm-none-eabi is easy if you run linux or freebsd 19:55:22 yeah it all works with FreeBSD 19:55:43 including making a binary for Mecrisp-Stellaris 19:56:30 (unlike getting the toolchain for risc-v, which is an absolutely massive pain in the ass) 19:56:51 tabemann, tried uploading a Forth sourcefile cia swdom yet ? 19:56:59 swdcom 19:57:15 tp: do I use #include like e4thcom? 19:57:27 tabemann, like this: ./swd2 20001D58 < gcd.fs 19:57:42 tabemann, kill the terminal first 19:57:55 tab, no it's still a ceta release 19:58:04 ceta? 19:58:10 before beta ;-) 19:58:15 that's alpha 19:58:23 oh... 19:58:34 Im a technician, no one told me bwahahahah 19:58:39 lol 19:59:04 I'm the hardware guy 19:59:49 tp: looks like i'm gettin two NUCLEO F411RE boards in case i break one 20:00:18 crest, re the F411RE, as it's a older unit it has older flash 20:00:27 than the 401? 20:00:44 and the older flash is SLOW to flash compared to the L476 20:01:05 but the board is solid and proven 20:01:20 the MCU is solid and proven, just older 20:01:24 with 128kB sram i can keep enough code in sram to keep me busy for a while 20:01:27 now I've got my board displaying blinkenlichten, all thanks to swdcom 20:01:35 tabemann :) 20:01:48 tabemann: good to hear that the code works for you 20:01:57 feel free to send a pull request 20:02:00 tabemann, your impression re speed of upload, terminal response etc ? 20:02:11 tp: very, very fast 20:02:24 crest, is a legend! 20:02:37 despite the fact that no comments or whitespace were being taken out of the code 20:02:44 yes! 20:03:34 crest, some of the boards have a lot more ram 20:03:49 tabemann whats in the L476 ? 20:04:46 oh same 1 Mbyte of Flash memory, 128 Kbytes of RAM 20:04:47 in LQFP100 package 20:05:37 crest, the older flash also has much larger blocks compared to the L476 20:06:17 so you would recomend to spend 1€ more on a NUCLEO L476RG 20:06:18 hmm my code seems to indicate it has 96K of RAM, even though I thought it had more 20:06:29 tabemann, crests code would run on Zeptoforth methinks ? 20:07:16 tabemann, with a bit of tabemann massaging 20:08:11 eyes 20:08:20 whoops 20:08:22 yes 20:08:39 it is runningo on zeptoforth, with some massaging 20:08:54 oh1 20:09:17 you ran it on zeptoforth instead of Mecrisp-Stellaris ? 20:09:33 yes 20:09:49 hahah, you could have mentioned that! 20:10:14 i think he did 20:10:20 we assumed you meant you had it running on Mecrisp-Stellaris 20:10:56 oh, I must have missed that, apologies 20:11:35 there's a single disadvantage to using swdcom - it feed literally every character entered into zeptoforth 20:11:48 and zeptoforth, well, can we say it doesn't really filter its input 20:12:10 it'll echo every character entered aside from DELETE and CR 20:12:21 and it will put the character in its input buffer 20:12:28 verbatim 20:12:34 feeds* 20:12:40 tabemann, but you dont see any of that with swdcom atm 20:13:01 tp: mecrisp-stellaris probably more strictly filters the characters entered 20:13:24 I should program that into zeptoforth 20:13:26 tabemann, Mecrisp-Stellaris does filter comments 20:13:38 no, I mean like characters < $20 20:13:44 control characters 20:14:01 but filtering comments takes time which is why I strip them automatically before upload 20:14:17 no I mean when the user is interactively using the terminal 20:14:21 and say, they hit up 20:14:33 with zeptoforth, the cursor will literally go up one line 20:14:44 and the control characters will be entered in the input buffer verbatime 20:17:11 i went with the STM32L476RG 20:17:37 1MB flash and 128kB ram for my crazy ideas 20:17:37 tabemann, ahh thats why my terminal is almost unusable with Zeptoforth @ 20:18:11 crest, a very excellent choice! 20:18:28 tp: my debugger attack on the serial-key? and serial-key should be possible 20:18:41 i just have to put hardware breakpoints at their addresses 20:18:50 crest, the STM32L476RG is not too old, has all the cool low power stuff and a zillion resources 20:19:34 load the data into the registers and skip the program coutner over the status register reads 20:20:17 but that would be a lot harder to implement than just putting data into writable memory mapped i/o registers 20:21:57 crest, aNd faster ? 20:22:06 than what? 20:22:52 --- quit: WickedShell (Remote host closed the connection) 20:22:54 your existing swdcom technique ? 20:22:59 no 20:23:11 probably orders of magnitude slower 20:23:39 but it would be possible to inject the bootstrap code into an unmodified image that way 20:23:41 oh 20:24:11 its not useful 20:24:13 so you can load swdcom remotely ? 20:24:35 you could load the target code into the target through the stlink 20:24:42 aha 20:25:16 it's just my curious hacker mindset that send me down that path 20:25:29 tho Ive worked around the issue of needing a serial terminal to load swdcom by making a bootable binary and the address by blinking the disco board leds 20:26:27 writing the four functions in assembler would also solve the problem 20:26:35 back 20:26:35 but i wanted to do it in forth 20:27:08 crest, so a future swdcom may install itself ? 20:27:18 maybe 20:29:35 hackers are definitely a breed apart from us mortal electronics techs :) 20:30:23 i know next to nothing about the analog world just next to the mcu 20:31:10 one cant be a expert in both fields, just one is more than enough 20:32:25 can someone tell me what happens in a stm32 on reset? 20:32:38 what does the chip do on reset? 20:32:57 is there some code in mask rom to bring the hardware into a sane state? 20:33:09 sure, a lot happens 20:33:17 is it a hardwired state machine? 20:33:37 in that url I pasted earlier of USART1 it showed the reset state of every register 20:33:49 but how does it get into reset state? 20:33:57 it resets all the registers to the reset state 20:34:02 but how? 20:34:25 there are a number of ways, the technical manual for the mcu explains everything 20:34:25 are those all set-reset registers hooked to a single reset line? 20:34:40 no one knows *how* it's done 20:34:55 someone at ST should know 20:35:01 all the interrupt vectos are set 20:35:04 back again 20:35:07 vectors 20:35:21 but it sounds like i shouldn't hope to be able to protect the usb controller from resets 20:35:42 and revive the usb modem idea 20:36:01 and in your new STM32L476RG there are probably 100+ interrupt vectors 20:37:14 what I do is load all the setup code initially via serial, and either export it via ihex to a binary or just use it as is, and then load the swdcom code when it's all done 20:37:15 crest, resets happen under controled circumstances such as pressing the reset button, low power voltage, hard exception 20:37:37 crest, but otherwise wont happen 20:37:46 as long as one avoids those situations, one should be fine 20:38:00 and also, at least in zeptoforth, the location of the buffer won't change across reboots 20:38:03 is there any electrical connection between the two parts of a nucleo board? 20:38:10 tabemann, I've already made a bootable Mecrisp-Stellaris binary with swdcom using my ihex method 20:38:37 crest, sure, the power, swd etc 20:38:59 tp: then you just need to record down that magic address somewhere 20:39:42 tabemann, I've written a alpha level word that blinks the board led to convey the swdcom address 20:40:02 in binary? lol 20:40:33 no, in decimal, like a car fault code led 20:40:37 it's easy to do' 20:41:08 short flashes for 1 - 9 and a long flash for 0 20:42:03 you could do morse code 20:42:40 then youd have to know morse, I already know decimal 20:43:19 it blinks, you count them, you write them down, it's easy 20:43:23 with morse code one could do hexadecimal 20:43:26 sure he could also use a DAC to output each digit as $x * 100mV for one second 20:43:28 and you only have to do it once 20:43:45 crest, thats also a idea :) 20:44:32 but watching the led requires no aditional gear 20:45:01 with zeptoforth and swdcom, you just attach a serial terminal first then boot 20:45:12 and the address is right there on the serial terminal 20:45:18 no counting involved 20:45:44 if you rewrite the code in assembler you can make it part of the image and extract the location from the symbols file 20:46:00 it's already a bootable binary 20:46:05 --- quit: dave0 (Quit: dave's not here) 20:46:08 unless zeptoforth is fastly different 20:46:42 tabemann, I'm trying to use a method that requires no serial terminal 20:47:17 tabemann not everyone has a serial dongle 20:48:49 that is true - the age in which every machine came with a serial port is long past 20:49:12 often the chipset still includes the serial port 20:49:19 but it isn't exposed to the user 20:49:28 yeah 20:51:02 fortunately usb-3.3v dongles are a $0.90 commodity 20:51:10 so it's not an issue 20:52:24 cheap FTDI clones straight from china 20:52:47 cheap enough that if the FTDI firmware updates brick the cloned chipset, oh well 20:53:09 the problem is when real live products include those cheap FTDI clones, and they get bricked 20:53:53 and then people wonder why, inexplicably, the serial ports on their expensive equipment no longer work 20:53:54 --- quit: dddddd (Ping timeout: 256 seconds) 20:54:17 updates ??? 20:54:21 yeah 20:54:43 who updates a usb-3.3v dongle ???? 20:55:01 there was an FTDI driver update that was designed to brick any of the chinese FTDI clones 20:55:59 don't install the official driver and use a the one included in linux and *bsd? 20:56:19 https://hackaday.com/2016/02/01/ftdi-drivers-break-fake-chips-again/ 20:56:22 yeah 20:57:33 the solution is to use linux or xbsd or to never windows update your machine ever 20:58:04 just use the device, forget about ever updating it 20:58:23 nah, it's the driver installed on your windows machine 20:58:36 tabemann: tp got the never update your machine part covered 20:58:39 not updating the device 20:58:52 anyway the dongles I use are these: https://mecrisp-stellaris-folkdoc.sourceforge.io/terminal-connections.html?highlight=serial#usb-3-3v-dongle-or-cables 20:59:07 CP2102 chipset 20:59:12 who needs fttdi ? 21:01:30 crest, hahah, FreeBSD makes updating easy providing you run a current release 21:04:59 just be careful going from 11.x to 12.x and follow the official steps 21:05:24 no just make installkernel installworld ; etcupdate ; etcupdate resolve 21:06:23 i managed to mess up (an recover) one system by skipping the correct steps and reboots 21:06:48 crest, I never update I always do a new install 21:07:09 then I just import my zfs array 21:07:10 my desktop/workstation still runs my second ever freebsd installation 21:07:13 I'm a debian user and I've gone years upon years without doing a fresh install 21:07:37 tabemann, we are sorry to hear that ;-) 21:07:46 lol 21:08:09 tabemann, will now be known as 'cruft-boi' 21:08:28 i moved this system from 32bit to 64bit, from ufs to zfs etc. 21:08:36 why install from fresh when one can do sudo apt update ; sudo apt upgrade 21:08:55 tabemann: because you want to end up in a well defined state 21:09:11 my desktop is the only system i refuse to wipe 21:09:30 I don't want to have to reinstall everything I've installed on here 21:09:48 tabemann: ansible? 21:10:09 tabemann, Linux users are born to suffer I guess 21:10:32 nah, there are linux users who will install everything from scratch too 21:10:43 I just don't like doing things this way 21:11:45 tabemann, who install from scratch ? 21:11:48 I dont 21:11:55 oh, and by the way, doing clone (from ihex.fs) to dump everything in the ram of my F407 board (which includes lots of empty filler space due to the limitations of flash erasure on it) is almost instantaneous 21:12:02 new install doesnt = from scratch 21:12:36 tabemann, with swdcom ? 21:12:41 yes 21:12:51 wow, I havent tried that yet 21:13:01 shame you cant capture it yet 21:13:05 whereas dumping it all with serial at 115200 baud takes about half a minute 21:13:13 yeah, it's slow 21:13:40 you can capture swdcom 21:13:45 hmm 21:14:00 echo dump | ./swd2 $addr | tee log.txt 21:14:28 swd2 address log.txt ? 21:14:34 okay make that (echo dump ; sleep 1) | 21:15:01 crest, you have to start the ihex dump first 21:15:10 ahh thats 'dump' ? 21:15:40 tis I have to try! 21:15:43 the problem is that there is no nice way to wait 21:16:04 swd2 quits on end of file 21:16:08 why wait ? 21:16:21 because it stops reading the output as well 21:16:29 and you want to capture the output 21:16:40 oh 21:17:00 so just tee ? 21:17:21 also possible 21:17:46 swd2 address | tee log.txt 21:17:47 just tee and remove the execess around the ihex 21:18:05 i have to do that anyway, i have a script that does it all 21:18:09 also you could restore the serial console first 21:18:22 my dump has a start and end keyword 21:18:22 and patch your dump code to call swd-emit instead of emit 21:18:57 nothing (of value) is lost be deconnecting and reconnecting 21:19:11 swdcom stores the buffer in the target ram 21:19:26 that allows swd2 to terminate without losing that buffer 21:19:34 back 21:19:44 swdcom is vry cool, a magnificient concept 21:20:01 okay, it isn't instantaneous 21:20:06 hahah 21:20:09 it needs more than one second to read all the data 21:20:13 but it still is really fast 21:20:16 10 hours ? 21:20:16 compared to serial 21:20:31 lol 21:20:47 al we need is error feedback from uploads 21:20:56 and we are there 21:21:07 at least as far as using screen goes 21:22:04 i my current state i would do more harm than good to the code 21:23:52 --- join: jsoft joined #forth 21:23:55 no sleep ? 21:23:59 tp: exactly 21:24:12 it being 0630! 21:24:19 i just stumbled over : https://sourceforge.net/p/mecrisp/discussion/general/thread/0aa9ed5212/ 21:24:35 why don't you use sed -e 21:24:57 I'm a technician ? 21:24:59 ok 21:25:15 Im just a rough hack 21:25:32 but it does safe bandwidth 21:25:45 thats not a problem on this boz 21:25:49 box 21:25:56 on the uart 21:26:12 ? 21:26:26 not sending the comments saves time 21:26:56 i dont send comments 21:27:38 thats used on my pc where all my Forth source is written 21:28:05 zero comments leave the pc to the Forth target 21:29:16 okay, I should get to bed 21:29:19 g'night guys 21:29:27 and crest, thank you for swdcom 21:29:36 night tabemann 21:30:03 yes crest, thank you for swdcom 21:30:14 :-) 21:31:41 oh, and btw tp 21:31:54 I committed code for zeptoforth which fixes the control characters problem 21:32:09 tabemann, cool! 21:32:31 so if you hit up you'll just get garbage like [A 21:32:38 tabemann: how does zeptoforth compare to mecrisp? what made you start your own forth? 21:32:50 rather than having the cursor actually move up a line while corrupting the input buffer 21:32:52 did you write down a comparison somewhere? 21:33:41 crest: I've never really compared zeptoforth to mecrisp; I just wanted to write my own forth for an embedded platform, and Cortex-M4 MCUs seemed like a good target 21:33:49 ok 21:33:49 crest, tabemann is a Forth implementer, thats what they do 21:33:57 :-P 21:34:19 note that parts of zeptoforth, particularly the serial console and the flash controller code are heavily based off of mecrisp-stellaris 21:34:45 while the vast majority of zeptoforth is a completely new implementation, independent of mecrisp-stellaris 21:35:55 note that in ways mecrisp-stellaris is more mature than zeptoforth, particularly because it has RA which zeptoforth lacks 21:36:40 Zeptoforth does have a ton of extra facilities; kitchesink.fs, theanswertoeverything.fs 21:37:03 in other ways zeptoforth has advantages, like as long as one uses a "full" binary one gets interrupt-driven serial IO out of the box along with power management 21:38:38 it also has wordlists, as of version 0.6.0, integrated into the core of zeptoforth, whereas VOCs in mecrisp-stellaris are an experimental extra 21:39:19 adding powermangement wouldn't hard 21:39:31 but having it built in is nice 21:39:41 crest, wanna bet ? 21:39:55 crest: the key thing is that power management is integrated with multitasking 21:39:58 tp: not optimal powermanagement 21:40:13 but sleeping instead of polling 21:40:25 with wakeups by the usart interrupts 21:40:42 crest, dont coment on stm32 power management until you try and implement it 21:40:43 yep, zeptoforth has that 21:40:50 tp: i played with it 21:40:57 and it looked like it worked 21:41:17 note that zeptoforth only uses "sleep" mode, not "stop" mode or any of the other modes 21:41:19 crest, which level of power management did you use ? 21:41:29 there are three modes 21:41:34 just the idle until interrupt instruction 21:41:42 nothing deeper 21:41:49 sleep ? 21:41:55 there is no idle mode 21:42:03 WFI? WFE? something like that 21:42:06 you mean WFI with the default power management option 21:42:17 I've done a comprehensive study with power measurements 21:42:18 that's what I use as well 21:42:38 WFI is required to enter any of the THREE modes 21:42:46 or WFE 21:43:08 one step better than just polling the usart status register all the time 21:43:11 what happens after the WFI depends on the setup before WFI is called 21:43:25 crest, maybe, maybe not 21:43:32 exactly 21:43:43 that was before i had a stlink to even samlpe the program counter 21:43:57 crest at least the board you have ordered has all the latest power resources 21:44:10 the thing about sleep mode is that it doesn't save as much power, but it is quickest to get out of that state 21:44:15 the STm32F103 in the blue pill has only coarse power control 21:44:22 and i have no idea how the debugger interferes with sleeping 21:44:24 tabemann, is right 21:44:59 in the case of zeptoforth, the systick is constantly waking up the processor, so it is necessary to exist the power management mode - and return to it - as fast as possible 21:45:08 various sleep modes will result in a long wake up of the usart with missing characters unless allowed for 21:45:39 low power is a MASSIVE study on it's own 21:45:45 and also because if input is being continuously fed in, as tp says, it'll lose characters if it's not as fast as possible 21:46:13 tabemann: only without reliable flow control 21:46:30 I know a very smast and capable embedded programmer who spent 3 months getting the lowest power on a commercial product, he said it nearly drove him crazy 21:46:31 you could use a timer to poll the swd ring buffers 21:46:54 you could even increase sleep time after a period of inactivity 21:47:11 to keep uploads fast but otherwise poll at a human friendly rate 21:47:18 in the end his product used about 8 nA in sleep ! 21:47:37 after a few minutes without transfers you could go into even deeper sleep 21:48:27 actually, with how I have it working right now, it's going to sleep and not being woken up, until a systick wakes up the processor 21:49:11 mind you systick is occurring at 1/10 ms intervals 21:49:16 whereas it needs input data to wake it 21:50:16 so it can transfer data in either direction as up to 255 bytes per 1/10th of a millisecond 21:50:35 with swdcom? 21:50:41 yes 21:51:01 it's a limitation imposed by the fact that I'm not having it busywait 21:51:18 but rather having it be woken up by systick 21:51:24 do stuff 21:51:27 then go back to sleep 21:51:44 that's 2.55MB/s 21:51:50 nevertheless Zeptoforth doesnt use much power, a great job by tabemann 21:52:00 (in theory) 21:53:50 okay, I should actually go to bed now 21:53:56 hehe 21:54:00 g'night guys for reals now 21:54:01 and crest1 21:54:06 and crest! 21:54:12 gn8 guys 21:54:15 yeah, you go to bed too, it's even later for you 21:54:29 night tabemann and crest 21:54:35 n8 21:54:38 it's 3pm here 22:28:49 --- join: gravicappa joined #forth 22:35:11 see swd 22:35:12 0000A00A: 3F04 subs r7 #4 22:35:12 0000A00C: 603E str r6 [ r7 #0 ] 22:35:12 0000A00E: 2680 movs r6 #80 22:35:12 0000A010: 0476 lsls r6 r6 #11 22:35:12 0000A012: 36EA adds r6 #EA 22:35:14 0000A014: 0176 lsls r6 r6 #5 22:35:16 0000A016: 3618 adds r6 #18 22:35:18 0000A018: 4770 bx lr 22:35:20 Bytes: 16 ok. 22:35:22 lol, not much 22:37:11 --- quit: proteus-guy (Ping timeout: 256 seconds) 23:04:40 --- quit: reepca (Read error: Connection reset by peer) 23:05:02 --- join: reepca joined #forth 23:07:34 --- quit: dys (Ping timeout: 256 seconds) 23:17:18 --- join: dys joined #forth 23:49:46 --- join: andrei-n joined #forth 23:54:00 --- join: guessgood joined #forth 23:59:59 --- log: ended forth/20.06.08