00:00:00 --- log: started forth/20.03.16 00:32:39 --- join: mtsd joined #forth 00:58:19 --- quit: mtsd (Quit: Leaving) 01:59:53 --- quit: actuallybatman (Ping timeout: 255 seconds) 03:00:25 --- quit: gravicappa (Ping timeout: 240 seconds) 05:06:15 --- quit: iyzsong (Remote host closed the connection) 05:06:32 --- join: iyzsong joined #forth 05:18:52 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 05:29:45 --- quit: Lord_Nightmare (Quit: ZNC - http://znc.in) 05:35:10 --- join: Lord_Nightmare joined #forth 05:49:34 --- join: X-Scale` joined #forth 05:50:14 --- quit: X-Scale (Ping timeout: 256 seconds) 05:50:24 --- nick: X-Scale` -> X-Scale 06:07:17 --- join: gravicappa joined #forth 06:51:09 --- quit: X-Scale (Ping timeout: 258 seconds) 06:51:16 --- join: X-Scale` joined #forth 06:52:02 --- nick: X-Scale` -> X-Scale 06:55:34 back 06:55:45 welcome back! 06:55:51 tpbsd: yes, it's a two-color multitasking blinky 06:55:54 you have a blinky! 06:55:58 awesome! 06:56:33 thats pretty good progress in such a short time, you taking lessons on RAD from Elon Musk ? 06:56:52 no I haven't been 06:57:04 judging from your code blow-ups I think you must be ... 06:57:33 the blinker itself is pretty simple (and mind you I took part of the code from Mecrisp-Stellaris's demo program) 06:57:55 thats cool, we all stand on the shoulders of others 06:58:34 I've been going thru a major cockup i made of the stm32f103 systick constants way back 06:58:58 this isn't using systick, but rather is just using a PAUSE counter 06:59:11 in those days I didnt realise that ARM system registers are all the same (mostly) between cortex-m models 06:59:13 so each time it PAUSEs it increments a counter 06:59:46 mine does tho, I rely on my ticktime for most things now 07:00:21 it's just too useful, and designed for this kind of stuff 07:01:07 but as I jump between cortex-m0 and m3 I have to keep updating the improvements I made last time 07:01:56 do you have a compiler controled beep on your terminal ? 07:02:08 frankly I'd be lost without mine 07:02:14 no I don't 07:02:34 does your compiler emit error messages ? 07:02:41 yes 07:03:03 tip: make them consistent and easy to parse 07:03:32 it has an exception mechanism, and any uncaught exception results in the exception xt being executed, which typically results in a string being printed 07:03:48 at first I modified the Mecrisp-Stellaris assembly to raise a gpio pin on a compiler error, but thats too much work to maintain 07:03:58 cool 07:04:17 yeah, it's an idea I got a while back from rdrop--exit 07:04:33 it's much nicer than the typical ANS Forth way of handling exceptions 07:04:34 now I just examine the error string and look for key words, and if found they color the text red and beep the terminal bell 07:05:09 it's SO easy to screw up Forth code, like any source I guess 07:06:26 tabemann, what terminal do you use now, e4thcom ? 07:06:32 yes 07:06:42 --- join: reepca joined #forth 07:06:46 that has a configurable error detector iirc 07:07:11 the mode I'm using it with "noforth", watches for a NAK character to indicate error 07:07:26 which I'm printing upon uncaught exceptions 07:07:33 oh! 07:07:40 not using the mecrisp mode ? 07:08:08 so any error is a NAK ? 07:08:13 nah, because mecrisp mode is based on detecting "ok." and assumes LN for a newline 07:08:19 you dont have finer grained errors ? 07:08:30 oh I have a number of kinds of errors 07:08:47 NAK just tells e4thcom to stop inputting data 07:08:51 yeah, that Linefeed is a pain, but matthias wont be swayed! 07:09:09 *LF 07:09:29 i recommend a numbered error code rather than a textual one 07:09:49 why? 07:09:49 that way you can publish a table of whatthey mean 07:09:59 easier to parse 07:10:09 more consistant 07:10:48 Ive had a a fair few errors parsing mattias error codes 07:10:55 error messages I mean 07:11:08 sometimes there may be a "." sometimes not 07:11:25 it's not the most consistent method 07:11:45 but if one emits a 4 digit error code thats easy to parse 07:12:07 I'm not relying on automatic parsing of error messages, and I hate looking up error codes 07:12:23 perhaps each type of error is given a range of 10, then they could even be finer grained later ? 07:12:48 ah, old school Forth huh ? 07:13:17 9600 baud and read every line as it slowly scrolls up the screen ? 07:13:24 NAK to me is sufficient to stop e4thcom at the point of an error so I can see what's up 07:13:55 some of my apps have 1000 lines of code now, and reading them is impossible at 460800 baud anyway 07:14:14 I should get ready for work though (I'm wondering when they'll tell us to work from home) 07:14:24 probably soon 07:14:29 yeah 07:14:44 as the corona virus fear ramps up 07:15:15 Australia has banned meetings of 200 people or more I think 07:15:33 I'll bbl 07:15:55 np, thanks for the chat 07:21:01 --- join: dddddd joined #forth 08:58:06 --- quit: jsoft (Ping timeout: 246 seconds) 10:26:48 --- join: actuallybatman joined #forth 11:18:59 --- quit: cartwright (Remote host closed the connection) 11:27:30 --- quit: Keshl (*.net *.split) 11:28:03 --- join: Keshl joined #forth 12:06:09 --- join: mtsd joined #forth 12:09:04 --- join: WickedShell joined #forth 12:28:22 --- part: mtsd left #forth 12:45:45 --- join: mtsd joined #forth 12:49:59 --- quit: mtsd (Quit: Leaving) 14:12:03 --- quit: gravicappa (Ping timeout: 246 seconds) 14:26:45 --- quit: xek (Ping timeout: 246 seconds) 16:23:03 --- join: dave0 joined #forth 17:01:42 --- join: crab1 joined #forth 17:01:54 Evening 17:17:33 hey guys 17:18:06 how we doin 17:29:19 got my blinky working 17:29:25 it's a multitasking blinky 17:29:35 so you can still enter and compile forth code while it runs 17:48:28 blinky? 17:48:53 also it appears that you are sending your messages doubly 18:10:27 --- quit: crab1 (Ping timeout: 250 seconds) 18:42:47 back 19:18:21 tp: 19:18:29 tabemann, congrats on your blinky, another milestone ! 19:18:44 now I'm implementing DO LOOPs, which is a real fucking pain 19:18:58 there's a reason I rarely use DO LOOPs in my code 19:19:11 the logic for LOOP and especially for +LOOP is too fucking slow 19:19:18 just trying to comprehend how DO LOOPs are done makes my techs brain hurt 19:19:36 tabemann, thats a typical programmers atitude tho :) 19:19:40 on a different Forth of mine I compared BEGIN UNTIL and BEGIN WHILE REPEAT loops with DO LOOP looops 19:19:54 the first two were so, so much faster when I made them all do the same thing 19:20:19 when it comes to Forth in embedded gear a DO LOOP is easy code and TONS too fast for most things 19:20:45 why? 19:21:05 tabemann, I have to use about a million do loops to slow down a MCU running at 48 MHz just to do things in real time 19:21:33 begin until loops are even faster :D 19:21:34 take a 100 millisecond delay, enough time to debounce a switch ? 19:21:58 thats probably 100,000 or more do loops at 48 mhz 19:22:18 I get a slow enough delay with my PAUSE count loops 19:22:22 with embedded almost everything a mcu does is way too fast 19:22:34 where I increment a pause count each time PAUSE is called 19:22:43 it's only in the purely software world that a do loop is 'slow' 19:23:19 I use do loops all the time in testing, their speed is always irrelevant to me 19:24:44 tabemann, it's natural for a Forth programmer to be very interested in the efficiency of his code, it's a itch that grows and grows, even I have it now 19:26:16 like here, here's my code for compiling a LOOP 19:26:17 tabemann, but it also pays to remember that although far, far fewer Forth USERS (like me) exist than Forth programmers, a do loop is a very handy construct to a Forth user in the real world 19:26:53 \ End a do loop 19:26:53 : loop ( R: leave current end -- leave current end | ) 19:26:53 [immediate] 19:26:53 [compile-only] 19:26:53 postpone r> 19:26:54 postpone r> 19:26:55 6 push, 1 literal, postpone + 19:26:57 postpone 2dup 19:26:59 postpone = 19:27:02 postpone swap 19:27:03 postpone >r 19:27:05 postpone swap 19:27:08 postpone >r 19:27:09 0 6 0 lsl-imm, 19:27:12 6 pull, 19:27:15 0 0 cmp-imm, 19:27:17 0branch, 19:27:20 rdrop 19:27:21 rdrop 19:27:23 current-here 6 rot literal! 19:27:25 ; 19:27:33 yeeah 19:27:35 ouchm I see what you mean 19:28:31 for comparison, this is UNTIL: 19:28:32 @@ End a BEGIN-UNTIL block 19:28:33 define_word "until", visible_flag | immediate_flag | compiled_flag 19:28:33 _until: push {lr} 19:28:33 push_tos 19:28:33 movs tos, #0 19:28:33 push_tos 19:28:36 movs tos, #6 19:28:37 push_tos 19:28:39 movs tos, #0 19:28:42 bl _asm_lsl_imm 19:28:45 push_tos 19:28:48 movs tos, #6 19:28:49 bl _asm_pull 19:28:51 push_tos 19:28:53 movs tos, #0 19:28:55 push_tos 19:28:57 movs tos, #0 19:29:00 bl _asm_cmp_imm 19:29:01 bl _asm_branch_zero 19:29:04 pop {pc} 19:29:06 this may seem just as complex 19:29:23 but in forth it is equivalent to : until [immediate] [compile-only] 0 6 0 lsl-imm, 6 pull, 0 0 cmp-imm, 0branch, ; 19:30:25 so so much simpler 19:31:04 as a Forth user it doesnt bother me 19:31:28 I hate such a waste of cycles as LOOP is 19:32:28 I see how that's good when you're deliberately trying to waste cycles 19:33:06 but for something like that I'd see making a timing mechanism based on systick as being beter 19:33:10 this is loop on a M3 19:33:13 see loop 19:33:14 00003CDC: 2E03 cmp r6 #3 19:33:14 00003CDE: D000 beq 00003CE2 19:33:14 00003CE0: E71A b 00003B18 19:33:14 00003CE2: CF40 ldmia r7 { r6 } 19:33:14 00003CE4: B500 push { lr } 19:33:16 00003CE6: F847 19:33:18 00003CE8: 6D04 ldr r4 [ r0 #50 ] 19:33:20 00003CEA: 4E52 ldr r6 [ pc #148 ] Literal 00003E34: 00003D0C 19:33:22 00003CEC: F7FF bl 00002D74 --> inline, 19:33:24 00003CEE: F842 19:33:26 00003CF0: F7FF bl 00003928 19:33:28 00003CF2: FE1A 19:33:30 00003CF4: F000 bl 00003F9C 19:33:33 00003CF6: F952 19:33:37 00003CF8: 484C ldr r0 [ pc #130 ] Literal 00003E2C: 2000000C 19:33:39 00003CFA: 0031 lsls r1 r6 #0 19:33:41 00003CFC: CF40 ldmia r7 { r6 } 19:33:43 00003CFE: 6001 str r1 [ r0 #0 ] 19:33:44 00003D00: F847 19:33:46 00003D02: 6D04 ldr r4 [ r0 #50 ] 19:33:48 00003D04: 4E4C ldr r6 [ pc #130 ] Literal 00003E38: 00003C94 19:33:50 00003D06: F7FF bl 00002D74 --> inline, 19:33:52 00003D08: F835 19:33:54 00003D0A: BD00 pop { pc } 19:34:00 and until 19:34:04 see until 19:34:04 00003B46: 2E01 cmp r6 #1 19:34:04 00003B48: D1E6 bne 00003B18 19:34:06 00003B4A: CF40 ldmia r7 { r6 } 19:34:08 00003B4C: E706 b 0000395C 19:34:10 00003B4E: 4770 bx lr 19:34:13 Bytes: 10 ok. 19:34:26 first time I've ever looked 19:34:34 exactly 19:34:46 UNTIL is so much simpler than LOOP 19:35:05 loop is 4.8 x longer than until 19:35:30 but from my perspective, each instruction is happening at 75 MHz 19:36:29 but the thing is when you're dealing with a lot of data, all that adds up 19:36:30 slow to someone used to a 3GHz Intel, but very fast to someone used to a 1MHz 6800 19:36:46 --- join: cartwright joined #forth 19:36:52 except embedded does NOT deal with a lot of data, thats the PC world 19:37:08 embedded deals with a lot of I/O thru GPIO ports 19:37:46 thats what software only people dont get, and understandably so 19:39:15 but NOW I know if I ever have a speed problem with a do loop, that a do until loop is 4.8x faster :) 19:39:40 BEGIN UNTIL 19:39:44 oops 19:40:05 tabemann, imagine youre making a washing machine controller in Forth ? 19:40:08 I've made the mistake of writing BEGIN WHILE UNTIL 19:40:25 your confronted with switch debounce, and motor on off control 19:40:35 solenoid valves to control water flow 19:41:12 I guess you can see how often I use begin until ? 19:41:23 but I do use DO LOOP a lot 19:41:57 and all those devices are glacially slow compared to even a 1MHZ mcu 19:42:22 now I have to implement +LOOP 19:42:29 that one is a fucking pain in the ass 19:42:39 thats why I shake my head in wonder when C users on embedded forums rave about a new embedded MCU that can be clocked at 600 MHZ 19:43:08 to me 60 MHz is way faster than I'll ever need 19:43:36 I've almost thought of rewriting hashforth as SRT/NCI because it's too damn slow as being token-threaded 19:43:38 in fact when running on a coincell, many MCU's run at 32 KHz ! 19:43:47 too damn slow meaning it does not start instantaneously 19:44:01 nothing starts instantaneously 19:44:32 well the thing is that there's a bunch of raw source code which is loaded into the image 19:44:52 and at startup time it has to compile it all 19:44:58 even a micro takes time to start after the reset button is pressed due to the deliberate RC delay 19:45:07 and it takes like a noticeable second before it is running 19:45:51 I have never measured the delay it takes for a stm32 to start, but it would be in the milliseconds for sure 19:46:10 zeptoforth seems to boot instantaneously 19:46:25 but then it does far less on bootup than hashforth 19:46:50 well the MCU has a R and a C in it's startup circuit so everything can be syncd 19:47:25 RC? 19:47:35 but PC's and embedded have almost nothing in common in my world 19:47:40 a resistor and a capacitor 19:48:16 this PC is water cooled, my STM32F103 has no cooling and doesnt even get warm 19:49:13 this PC has 32GB dynamic ram, a STM32F103 has 20kB static ram 19:49:57 this PC is clocked at 3500 MHz, the STM32F103 at 75 MHz 19:50:03 and so on 19:53:06 * tabemann likes that you can actually reasonably write code to run on bare metal in the MCU world, whereas for PCs there's too much proprietary firmware drivers and shit that make that nearly impossible 19:54:19 Ive only written GTK, Perl and SH code for the PC in the last 20 years 19:54:34 they were dead easy, but all user stuff 19:54:57 --- join: boru` joined #forth 19:55:00 --- quit: boru (Disconnected by services) 19:55:03 --- nick: boru` -> boru 19:55:32 but I write code for embedded all the time and can do anything the MCU resources allow, I make my own 'drivers' 19:57:05 this is my 'driver' code for my recent touch sensor demo binary: https://mecrisp-stellaris-folkdoc.sourceforge.io/touch-sensor.html#forth-code 19:57:33 what programmers call a driver or a library I call 'configuration' 19:58:53 I'd call that an API 19:59:18 a "driver" implies a discrete piece of code 19:59:20 lol, another programmers term! 19:59:23 to me at least 19:59:35 it's all a bit overlapping I guess 20:00:01 well that code is from a discrete piece of code 20:00:22 like for zeptoforth I have a serial driver - well, two serial drivers - but I find it hard to call them "drivers" 20:00:27 it's just there to show readers the important parts 20:01:08 exactly, same with mecrisp, the USART code is what I call a configuration 20:01:24 (the first serial driver is a simpler one to be used before the multitasker is added, and the second includes more advanced buffering support and plays nice with the multitasker) 20:01:42 but from a programmers perspective Im sure that there is a 'driver' concept there somewhere 20:02:16 "driver" implies it is separate from the rest of your OS or your application 20:02:40 oh ok 20:02:49 like at some point it exists as its own shared object or that it is dynamically loadable or like 20:03:05 thats well above my pay grade! 20:03:28 I'm all solenoid valves and motors 20:03:45 soldering and wiring etc 20:03:48 conversely, I don't understand IO registers and stuff 20:04:07 like with zeptoforth, everything I've used I've copied from mecrisp-stellaris 20:04:16 which are *critical* to embedded, but youre far from alone there 20:04:34 whereas I'm perfectly comfortable doing things like writing my own multitaskers and like 20:04:40 I think the example code people at STM have never seen a MCU myself 20:05:07 tabemann, yes, it's easy for a user to see where your expertise lays 20:06:11 i see the same things on all the embedded forums, programmers operate in the software world and that forms their world view 20:07:57 to a user like me, every peripheral register is like a door into a room containing boxes of different tools, every one is specialised and exciting to learn 20:08:22 to me a peripheral register is where the fun parts of a MCU live 20:08:46 whereas I see it like a space that I get to control completely, all by myself, to essentially create my own OS of sorts for 20:09:06 whereas on a PC I never get to have complete control, ever 20:09:09 theyre like the components of a car, the brake slows the car and stops it, the clutch disables or enables the power from the transmission etc 20:09:56 and as one experiments with every car component, I do the same with every mcu peripheral register 20:10:14 even if there weren't those binary blobs, there's still the fact that there's a hidden secret ARM core buried inside every Intel processor, probably doing the NSA's bidding 20:10:33 tabemann, thats true, tho youre at the stage of controlling the MCU ARM registers only 20:11:29 tabemann, there is 'hidden' stuff inside all MCU's 20:11:52 I know that with the DISCOVERY board there's really two MCUs on the board 20:12:16 one that I control directly, one that I don't that interfaces with the USB and ST-Link and stuff 20:12:28 lookat the RPI, it has a hidden controller that sets everything, if you run Linux on a RPI, it sees only what the hidden controller tells it 20:13:04 tabemann, yes, on a DISCO board there is the 'programmer' and the 'target' MCU 20:13:43 the programmer part can be removed, or better put, I can run a target standalone from the Disco board 20:14:12 tabemann, in fact all the stm32's will run standalone with NO external components at all 20:14:51 which may seem off to a programmer, but that standalone capability is essential for a microcontroller 20:16:09 well yes 20:16:19 when you're actually putting an MCU in a product 20:16:31 but lookat all the guff a pentium needs ? 20:16:42 you don't want to have to rely on a separate MCU just to, say, field upgrade the device 20:16:44 theyre just so different 20:16:59 --- join: rdrop-exit joined #forth 20:17:01 sure, and you dont need one either 20:17:05 hey rdrop-exit 20:17:20 hi tabemann and tp! 20:17:39 the DISCO board just has a USB interface for convenience 20:17:44 well yes 20:17:51 hey Zen Forth Guru! 20:18:15 home quarantine for everybody here 20:18:26 fun 20:18:34 I'm surprised they haven't done it here 20:18:41 I'm seriously going to work tomorrow 20:18:44 tabemann, take Microchip MCU's, they all need a separate PICKIT programmer and so on 20:18:55 rdrop-exit, wow 20:18:55 : loop { a*# # -- }()( r: a lim x -- {a lim x+1}| ) 20:18:55 & (loop) converge ; directive 20:19:31 rdrop-exit, what does that look like in Forth ? ;-) 20:19:38 lol 20:20:11 & is just POSTPONE, I prefer to use a shorter name 20:20:24 (loop) is the runtime of LOOP 20:21:06 CONVERGE resolves a series of pending relative forward references 20:21:15 thats the awesome thing about Forth to me, theyre all difefrent! 20:21:58 rdrop-exit, I had a long chat to my friend in Wuhan about the state of things there 20:22:26 he said it's almost over, hes been confined to his apartment for 2 months 20:22:53 they're talking about 1 month for now here 20:23:09 everything is so organised there, food is ordered online and delivered, the govt provides free vegies 20:24:05 after hearing from him how organised they are in wuhan I saw Australia's response as 'she will be right mate' 20:24:32 the population of Metro Manila is 13M 20:24:58 I'm sure Wuhan's pop would also be a lot ? 20:26:08 yes, urban area is 9M 20:27:27 the town of Wuhan has been in quarantine for those last 2 months, no one leaves or enters, delivery drivers from outside drop off all the ordered online stuff at a special area outside the town where only specialised people hand it on to specialised people inside the town who deliver it to the appartments 20:27:44 and so on 20:28:39 Same here, Metro Manila is cut off from the rest of the island of Luzon, and Luzon is cut off from the rest of the world 20:28:58 he once showed me the Chinese internal shipping system and it makes ours in Auatralia look stoneage 20:28:58 the last international flights will be leaving in about 48 hours 20:29:18 it's like a sci-fi movie 20:29:46 just be ready for the hordes of flesh eating Coronavirus zombies ? 20:30:03 he 20:30:43 if youre not sure what to do just watch 'zombieland' one and two ;-) 20:30:44 I'll be ok until I run out of Espresso beans and cigs 20:31:52 time to quit smoking as long as you have no choice 20:31:52 you and 10 million others 20:32:21 I'm going to walk the dogs on the roof, catch you later 20:32:27 --- quit: rdrop-exit (Quit: Lost terminal) 20:32:27 I wonder which is worse, nicotine withdrawl or the coronavirus ? 20:32:49 at least you won't die from nicotine withdrawal, even if you may want to 20:33:17 tabemann, I only smoked for 3 years, between the age of 30 and 33 20:33:40 and even then it was only 3 cigs a day max as more would give me asthma 20:33:54 good reason to stop 20:33:57 but it was damn hard to give it up 20:34:13 yeah, I put it down to a temporary insanity 20:34:55 id been hunting a lot at night in those days and other hunters smoked and somehow it began 20:35:17 which was wierd as my mum was a chain smoker and I grew up hating everything about it 20:35:46 she dies of primary lung cancer at 74 20:35:54 -s+d 20:36:14 even tho she had stopped at age 50 20:36:23 but back to forth! 20:37:36 I coded right thru the night lastnight, all of a sudden I realised I could see outside because it was light! 20:37:54 I had lost all track of time 20:37:55 what were you working on? 20:38:41 a bunch of stuff, mainly updating my STm32F103 project manager to the same level as the STM32F051 20:39:01 with the aim of releasing a new STM32F103 diagnostic binary 20:39:57 when I went to bed I realised I could just revert everything and keep the STM32F103 projects at the same state because I don't use it in my internal projects 20:40:47 and Im not going to either, it's too old, too limited and even tho I have 30 units, I bough them in 2014 before I knew better 20:41:14 at least my new library strategy is paying off now 20:41:55 to me the main question is why not just use whatever balance of A) processing power and B) low power usage fits one's needs 20:42:20 like with me, I don't need low power, so why not just use something specced out to the max? 20:42:41 and thats a common question I have seen for the last 30 years in embedded 20:42:47 and anyways, the only reason to not use something specced out to the max is if power consumption is a consideration 20:43:35 my personal feeling is that embedded development is ALL about the TOOLS, with the MCU choice coming second 20:43:42 or if there's concerns about issues like binary blobs 20:44:33 for me at least, I've found gas, gdb, openocd, and st-flash together have been fully sufficient 20:44:49 there are other important factors 20:45:17 I don't even use gdb or openocd anymore now that I can develop primarily in forth 20:45:25 well yes 20:45:37 how well the MCU and the board are documented is important 20:45:52 if there's secret proprietary crap going on is another 20:46:01 tabemann, gas, gdb, openocd, and st-flash are recent developments, chronologically speaking 20:46:40 tabemann, and the STM tools are fantastic, they do have pretty much everything one needs 20:47:16 look at Arduino, they have no GDB, theyre still using print statements to debug 20:47:51 TBH with Forth I've heavily relied on print debugging - lol 20:48:22 lol, so do I, withing Forth programs 20:48:32 particularly since it is very difficult to debug Forth code with gdb on here, whereas gdb excels with debugging assembly 20:48:53 I have a "_P" command that prints the stack with a line number label 20:49:17 I use it when the going gets complex 20:49:48 I added .s but I haven't added line numbers to zeptoforth 20:50:05 the line number is automatically inserted so I can correlate the source with the stack prints 20:50:19 the line numbers are a VIM thing 20:50:39 the command is a VIM command, Forth doesnt know whats going on 20:51:05 this is a fine example of what I mean by 'tools' 20:51:48 my specialist tools consist of my project manager which only works for STM32 chips 20:52:16 if a micro was 100x cheaper and I had no tools, I wouldnt use it 20:53:53 look at the Paduk mcus ? theyre available for $0.03 for their OTP version and they have a hardware emulator for each type of Paduk mcu and so on, but I'd never use it because I have my own tool requirements, I wont be forced to use anyones tools 20:54:36 especially as everyone elses tools are all about C 20:55:23 with STM you can work fully in assembly, using very friendly tools, whereas not everything is about that 20:55:36 e.g. if they require proprietary tooling and shit 20:55:57 like require you to use their IDE and like 20:56:11 exactly, which is what Paduk do 20:56:15 and many others 20:57:06 I'm glad I chose STM for the basis of my MCU Forth 20:57:23 my system is so finely tuned to what I want that Arduino programmers and even Forth beginners just stand there looking like zombies when I show them 20:57:38 aside from the fact that I can't use gdb to debug Forth code, it's been painless 20:57:40 it's very hard to beat STM imho 20:58:14 I imagine how it'd've turned out had I chosen a Microchip product for a Forth 20:58:22 particularly a PIC chip lol 20:58:28 I started with embedded in 1974, so Ive seen and used a lot of different mcu's 20:58:42 except for PIC32... I've heard that one is sorta better due to really being MIPS 20:59:14 well, Flashforth is pretty good and it's been around for at least 7 years for PIC 20:59:32 but even flashforth cant run from ram 21:00:31 I have 200x PIC's in stock and just never use them. I like PICs, always have and have made decent money with PIC products Ive dsigned and sold in the past 21:00:32 can it at least flash itself on the fly? 21:00:58 sure, it adds words to it's own flash 21:01:05 same as Mecrisp-Stellaris 21:01:25 except, being PIC, it can't run from RAM 21:01:43 to make a PIC forth which runs from ram you need token or indirect threading 21:01:58 flashforth is very polished, but needs the damn java based microchip IDE to compile the flashforth source 21:02:14 ugh 21:02:28 sadly microchip didnt give a damn about non windows for a long time 21:02:48 and even now it's a token effort for Linux etc 21:03:32 I dont know why Nordstrom doesnt distribute binaries with his flashforth like Mecrisp-Stellaris does 21:03:32 whereas with STM working on Linux has been without any hitches 21:03:39 exactly 21:04:19 in 2014 when I 'came back to embedded' after a decade not doing it, I bought several different MCU's to try out 21:04:55 only one was dead easy to use with Linux .... STM32 21:05:07 all the others were a pain in one way or another 21:05:49 I have a box full of MCUs I couldnt use under Linux ranging from Silabs, Atmel, NXP etc 21:06:22