00:00:00 --- log: started forth/20.02.10 00:07:45 --- join: jsoft joined #forth 00:13:25 back c[] 00:14:24 welcome back! 00:15:00 --- quit: dave9 (Ping timeout: 265 seconds) 00:15:37 thanks! 00:17:09 --- join: dave9 joined #forth 00:27:23 rdrop-exit, as you know, as part of my sneaky Forth infiltration into a very large C and Arduino anti-Forth group I released a bootable binary with a simple menu that worked from a single USB conection to the board in question, a cheap $2 Chinese "BluePill" 00:27:53 yup 00:28:22 the bootable binary was my initial foray into this issue, mainly trying to detect which of the 'fake' Chinese STM32F103 clones was in the board 00:29:17 then I waited a couple of months and released 'a gentle introduction to Forth by way of a blinky' that ran on the binary I released 00:30:13 as the binary was a full Forth system with as many memory mapped registers as I could fit onto the binary image and yet still be under 64kB 00:31:02 because the standard binary flashing scheme can only handle 64kB when the chip declares 64kB Flash is all it has 00:31:22 and this system works with Windows and Linux USB 00:31:40 in fact most of the downloaders are Windows users in the USA 00:33:09 so as of right now, Im up to 112 downloads of the binary and 5 downloads of the overt 'a gentle introduction to Forth by way of a blinky' so thats five C users having a closer look at Forth 00:33:35 so sneaky Forth advocacy plan: 00:34:04 1) release a really useful bootable binary for a popular micro for which no C alternative exists 00:34:15 2) Dont mention Forth at all 00:34:41 3) wait until there are over 100 downloads 00:35:11 4) Advertise a overt Forth 'intro' that runs on the binary 00:37:42 kudos 00:39:10 interestingly I haven't received a single bug report 00:40:34 which means it's doing on their systems exactly what I planned. This is good as Ive never owned any of the fake chips myself so was unable to test on anything but a bonafide STM chip 00:41:07 I guess that has to speak to the versatility and robustness of Forth 00:43:29 --- quit: dave9 (Ping timeout: 260 seconds) 00:44:24 nice 00:44:45 it's a funny thing testing fakes 00:44:54 you cant buy a fake directly 00:45:42 no one advertises their bluepill has one in it because if it does it's probably been marked as a STM32F103 00:45:57 and they probably dont know, even if they did, they wouldnt say 00:46:28 so one has to buy 'bluepills' and wait to get a fake! 00:47:25 so at $5 - $10 a board I'm not interested, and knowing my luck, they will all be bonafide, obsolete 16 year old STM32F103's! 00:48:25 so it's a difficult problem to address, relying on Internet users to test my binary as there are so many who ordered the bluepill boards and got the fake chips 00:54:38 right 00:55:49 how is that flu of yours going ? 00:56:03 is there any panic over the Conavirus there as yet ? 00:56:17 everyone wearing paper masks ? 00:57:15 No panic yet, maybe 1 in 10 or more wearing masks. 00:58:17 personally I dont believe in the medias 'panic' agenda. I dont think people panic like that 00:58:51 usually people are orderly in times of emergency in my experience 00:59:00 --- join: dave9 joined #forth 01:00:29 Ive seen people run away in times of unexpected explosions, but that's instinctual. it's not panic 01:00:49 right 01:00:50 before you know it your legs have carried you 100 meters to safety 01:03:04 You typically see more visitors wearing masks here than locals, especially Chinese, Koreans, and Japanese, tend to habitually wear masks 01:03:24 ah yes 01:03:46 i can understand that when the Japanese get packed like sardines on some trains 01:04:04 being out in public is a great way to catch viruses etc 01:04:33 if I'm on public transport and some starts coughing, I immediately move as far away as possible 01:05:38 I don't use any public transport locally 01:06:06 you dont need to, with all the awesome shops opposite your door! 01:09:13 it's a convenient neighborhood, I only tend to leave it to go to the beach or to visit friends or family 01:09:25 sounds like it! 01:10:09 I hate sitting in traffic 01:11:09 that only happens in our major cities, here in rural Australia there is no traffic jams 01:11:35 I can hop on my motorbike and ride for 2/5 hrs and never stop 01:12:05 thats my 'fish run' when I buy fresh fish from a fishermans co-op on the coast 01:12:16 cool 01:12:28 2.5 hrs thru rainforests and mountains, it's just awesome 01:12:38 nice 01:13:01 hey have a look at the C alternative to my Forth binary, I can barely understand it 01:13:04 https://github.com/a-v-s/ucdev/tree/32F103Detect/demos/usbd 01:13:15 ok, checking 01:13:24 it appears he uses USB to dl a hex file ? 01:13:34 no user notes, no nothing 01:14:04 i know it's only a day old, but why release something so unfinished ? 01:14:26 probably just to keep it in version control? 01:16:52 --- quit: cartwright (Remote host closed the connection) 01:17:36 but one doesnt need github for version control 01:18:09 maybe s/he wants to keep it on github as a backup and access the code from multiple places 01:18:27 thats a valid reason 01:19:14 --- join: cartwright joined #forth 01:34:35 He's trying to distinguish STM32, GD32, CS32, and APM32 01:34:54 yes 01:35:06 which are the counterfeits? 01:35:15 CS32, and APM32 01:35:36 GD32 is a clone but advertizes itself as a GD32 01:36:04 the others counterfeit the STM32 chip internal credentials 01:36:57 CS32 and APM32 may be the same fake chip, no one knows yet 01:38:13 so if the id is 59, and the continuation code is 4, he assumes it's either a apm32 or cs32 01:38:33 then he does a further test to differentiate those two from each other 01:39:31 oh 01:39:56 the data doesnt suggest a way to differentiate the apm32 or cs32 01:40:17 // So, we can determine what core we're running on. We still need to find // a way to tell apm32 and cs32 apart. 01:40:41 there isnt one as yet 01:40:45 TM32 : Cortex-M3 r1p1 V:1 CONT: 0 ID: 32 PART: 410 REV: 0 01:40:45 GD32 : Cortex-M3 r2p1 V:1 CONT: 7 ID: 81 PART: 76F REV: 0 01:40:45 CS32 : Cortex-M3 r2p1 V:1 CONT: 4 ID: 59 PART: 4C3 REV: 0 01:40:45 APM32 : Cortex-M3 r2p1 V:1 CONT: 4 ID: 59 PART: 4C3 REV: 0 01:40:50 thats the data hes using 01:41:09 but after that he does a further test 01:42:03 romtable_t *rom = (romtable_id_t*) (ROMTABLE); 01:42:30 if (rom->etm & 1) { prob = "CS32"; 01:42:31 } else { prob = "APM32"; 01:42:31 } 01:42:42 oh 01:43:39 that's from line 175 01:43:50 Embedded Trace MacrocellTM (ETM) 01:45:43 thats the "user ETM pending" bit I think 01:46:00 I'll take your word for it ;-) 01:46:10 it's way to iffy for me 01:46:22 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 01:46:41 --- join: iyzsong joined #forth 01:46:47 perhaps he has a APM32 and diffed the ROM hexoile and found it different to the CS32 01:48:38 thanks for mentioning it, Ive made a note. Thankfully the "APM32" is hardly seen thesedays 01:49:08 there is no doc for it either, same as the "CS32" 01:49:37 have fun with your detective work 01:49:51 Its fun with Forth 01:50:02 :-) 01:50:20 his code looks like a lot came from premade templates 01:50:58 the popular C IDE's for STM32 have template generators using "HAL" or whatever 01:51:16 one gives the desired config and the IDE spits it out (more or less) 01:52:12 I hate such things 01:52:27 the more experienced coders always advise to avoid them and do the config manually, the fans claim that these are the reasons the IDE is desireable 01:52:57 it does produce copious boilerplate thats soul destroying to read 01:56:35 :) 01:56:44 I'm guessing that "sprintf" talks via the USB and a virtual serial port ? 01:57:09 so basically it makes some decisions and reports them ? 01:57:34 I closed the browser tab, hold on 01:58:01 mine is similar but I do two reports, one is a few decisions and the other is a XML file with the virgin data for later analysis and database etc 02:00:07 sprintf() prints to a 128 byte buffer 02:01:03 I wonder how that is then used ? 02:01:34 perhaps the bugger is read by the debugger into a hexfile, seems silly to do it that way tho 02:02:00 he has a USB virtual serialport, perhaps that reads the buffer ? 02:03:19 in demo.c in the project root directory ? 02:04:38 either way, I find that project very basic and confusing without some doc explaining it 02:05:07 I don't see that buffer being picked up by any code 02:05:24 ahh, I reread his announcement 02:05:27 There is no fancy user interface, it puts its result in the USB string of the Interface. 02:05:28 The USB ID is DEAD:BEEF, so to capture the output, you can do something like this 02:05:28 Code: [Select] 02:05:28 [andre@8570w ~]$ lsusb -d dead:beef -v | grep iInterface 02:05:28 can't get device qualifier: Resource temporarily unavailable 02:05:29 can't get debug descriptor: Resource temporarily unavailable 02:05:31 iInterface 4 STM32 Cortex-M3 r1p1 V:1 CONT: 0 ID: 32 PART: 410 REV: 0 02:05:33 The iInterface string will contain 02:05:35 STM32/GD32/CS32/APM32 02:05:37 Cortex M3 rnpn : The ARM Core used: STM32 uses r1p1, clones usually r2p1 02:05:39 Content of the PID in the ROM TABLE (JP106 Identifier) 02:06:46 I guess his buffer and decisions are for later use 02:07:50 probably work-in-progress 02:07:56 definitely 02:08:06 thanks for having a look at it, my C sucks 02:08:18 np 02:08:57 this guy seems very capable, I can only imagine the initial design questions that he must have had 02:09:30 having *zero* on chip resources ready to use, he had to create eveything 02:10:00 Forth had everything I already needed when I started 02:15:23 cool 02:18:09 I guess his idea is pretty simple, but it does require his hexfile be flashed to the chip, then the data is sent back as a USB string 'Interface" 02:18:41 probably the simplest C method ever apart from blinking the data thru the board user LED as morsecode 02:20:18 My first instinct would be to use the debug interface for stuff like this. 02:22:47 As you know I always assume a tethered setup. 02:23:43 yes 02:24:03 do you have actual hardware connected via the debug interface yet ? 02:24:19 the bluepill has no SWD or JTAG connector 02:25:06 Not yet, I haven't bought a target yet. 02:26:07 If the target has no debug interface than I would put a tiny monitor on it, enough to go peeking and poking around under the control of a Forth on the PC side. 02:27:17 the Blue Pill has pims for SWD and Jtag which have to be manually wired 02:27:52 thats what I did, my monitor was 19kB in size, some people call it "mecrisp-stellaris" tho 02:27:57 :) 02:28:08 that works :) 02:28:17 it do 02:28:39 my aim was to get data back from users who actually have the hardware and analyse it 02:29:13 that was the aim of V1, apart from showing C users that something else other than C does this job very well 02:29:42 you are a generous person 02:29:42 (for those that even wondered) 02:29:53 it was a interesting challenge 02:30:24 and I have about 20 STM32F103 chips here myself, just none of the clones 03:08:48 time to walk the dogs, catch you later 03:08:59 cya 03:10:20 --- quit: rdrop-exit (Quit: Lost terminal) 03:57:20 --- join: dddddd joined #forth 04:06:31 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 04:54:22 --- quit: jsoft (Ping timeout: 265 seconds) 04:56:56 --- join: X-Scale` joined #forth 04:57:45 --- quit: X-Scale (Ping timeout: 265 seconds) 04:57:45 --- nick: X-Scale` -> X-Scale 05:02:08 --- quit: deesix (Read error: Connection reset by peer) 05:05:29 --- quit: dddddd (Ping timeout: 268 seconds) 05:12:01 --- join: deesix joined #forth 05:12:19 --- join: dddddd joined #forth 05:17:53 --- join: deesix_ joined #forth 05:18:15 --- join: dddddd_ joined #forth 05:20:28 --- quit: deesix (Ping timeout: 265 seconds) 05:20:49 --- quit: dddddd (Ping timeout: 240 seconds) 05:20:57 --- nick: dddddd_ -> dddddd 05:21:30 --- nick: deesix_ -> deesix 06:51:17 --- join: xek joined #forth 07:19:07 --- join: proteus-guy joined #forth 07:41:29 --- quit: tabemann (Ping timeout: 240 seconds) 08:41:07 --- join: ryke joined #forth 09:41:09 --- quit: X-Scale (Ping timeout: 240 seconds) 09:41:16 --- join: X-Scale` joined #forth 09:42:05 --- nick: X-Scale` -> X-Scale 09:57:25 --- quit: ryke (Ping timeout: 265 seconds) 10:04:02 --- join: ryke joined #forth 10:13:29 --- quit: dys (Ping timeout: 240 seconds) 11:50:14 --- join: WickedShell joined #forth 12:10:02 --- join: pierpal joined #forth 12:38:06 --- quit: gravicappa (Ping timeout: 268 seconds) 13:09:53 --- quit: pierpal (Ping timeout: 272 seconds) 13:15:59 --- join: pierpal joined #forth 13:16:57 --- quit: cartwright (Remote host closed the connection) 13:19:22 --- join: cartwright joined #forth 13:37:20 --- quit: xek (Ping timeout: 265 seconds) 13:38:23 --- quit: pierpal (Read error: Connection reset by peer) 13:46:12 --- join: pierpal joined #forth 13:51:05 --- quit: KipIngram (Quit: WeeChat 1.4) 13:54:24 --- join: KipIngram joined #forth 13:54:24 --- mode: ChanServ set +v KipIngram 14:00:32 --- quit: pierpal (Ping timeout: 265 seconds) 14:13:35 --- join: pierpal joined #forth 14:21:06 --- quit: pierpal (Ping timeout: 268 seconds) 14:26:29 --- join: dave0 joined #forth 14:44:49 --- join: pierpal joined #forth 14:49:21 --- quit: pierpal (Ping timeout: 265 seconds) 14:56:33 --- quit: ryke (Ping timeout: 260 seconds) 16:48:01 --- quit: dave0 (Quit: dave's not here) 17:06:33 --- quit: jedb (Quit: Leaving) 17:07:36 --- join: jedb joined #forth 17:23:54 --- join: tabemann joined #forth 17:35:42 ist jemand hier? 17:36:43 nein 17:37:21 niemand ist hier 17:37:22 hehe :D 17:38:10 ugh why do I so not want to implement . ." .( c" or s" ? 17:38:49 when you were a young boy a ." scared you badly ? 17:39:27 nah, it's just that I don't want to figure out how to compile a string into the words being compiled 17:39:29 st least it will look like human crafted code when you do it 17:40:10 maybe it's just that the ADR instruction scares me 17:40:11 unlike the stale HAL boilerplate I see as part of embedded C code thesedays 17:40:40 because it requires a constant to be at a 4-byte offset from the PC 17:40:42 the good think about Forth is that it doesnt make the MCU red hot when you screw up 17:40:56 just experiment ? 17:40:57 why doesn't it? 17:41:12 it's a benign language 17:41:24 all you get is the MCU locking up 17:41:33 but you can make a tight loop with it if you want to 17:41:35 I reset mine a zillion times every project 17:41:53 sure, only 3x slower than assembly on average 17:42:21 but a tight loop wont hurt the mcu, even when overclocked 6x 17:42:30 in the case of a stm32f051 17:43:38 so why would anything else make the MCU glow? 17:45:10 oops I meant 100% 17:45:36 well nothing will, modern electronics doesnt do that generally 17:49:39 * tabemann remembers the classic HCF instruction :D 17:50:48 early unix had a 'your printer is on fire' error when it wasnt working, they had to remove it because too many secretaries panicked 17:54:03 I love that one! 17:54:20 nah, you can still find that one if you try hard enough 17:55:35 Modern printer drivers and support have improved and hidden low-level error messages from users, so most Unix/Linux users today have never seen the "on fire" message. However, a few people still run into it today with varying levels of amusement or confusion.[6][7] The "on fire" message remains in the Linux source code as of version 5.0-rc3.[8] 17:55:35 The message is also present in other software modules, often to humorous effect. For example, in some kernels' CPU code, a CPU thermal failure could result in the message "CPU#0: Possible thermal failure (CPU on fire ?)"[9] and similar humor can be found in the phrase halt and catch fire. 18:06:15 okay, gotta head home - bbl 18:06:27 cya 18:12:21 --- quit: tabemann (Ping timeout: 265 seconds) 18:20:01 --- quit: proteus-guy (Ping timeout: 260 seconds) 18:41:32 --- join: boru` joined #forth 18:41:35 --- quit: boru (Disconnected by services) 18:41:37 --- nick: boru` -> boru 19:15:25 --- quit: cartwright (Ping timeout: 240 seconds) 19:16:55 --- join: jsoft joined #forth 19:18:27 --- join: ryke joined #forth 19:19:03 --- join: tabemann joined #forth 19:38:25 --- quit: jsoft (Ping timeout: 260 seconds) 20:06:22 --- join: actuallybatman joined #forth 20:39:43 --- join: iyzsong joined #forth 20:40:46 --- quit: phadthai (Ping timeout: 268 seconds) 20:40:55 --- join: phadthai joined #forth 21:06:21 --- quit: iyzsong (Ping timeout: 265 seconds) 21:07:04 --- join: iyzsong joined #forth 21:17:13 --- join: gravicappa joined #forth 21:51:13 --- quit: dddddd (Ping timeout: 240 seconds) 22:48:59 --- join: jsoft joined #forth 22:59:10 --- join: smokeink joined #forth 23:06:25 --- quit: MrMobius (Ping timeout: 240 seconds) 23:08:10 --- join: MrMobius joined #forth 23:16:01 --- quit: jsoft (Ping timeout: 240 seconds) 23:46:20 --- quit: ryke (Ping timeout: 265 seconds) 23:59:59 --- log: ended forth/20.02.10