00:00:00 --- log: started forth/19.06.27 00:42:51 --- quit: Blue_flame (Quit: Blue_flame) 00:44:15 --- join: xek__ (~xek@user-5-173-136-60.play-internet.pl) joined #forth 00:55:14 --- join: gravicappa (~gravicapp@h109-187-231-103.dyn.bashtel.ru) joined #forth 03:34:40 --- join: Blue_flame (~cdadr@2405:204:9510:15c9:191a:9323:9275:a48) joined #forth 03:55:22 --- quit: proteusguy (Ping timeout: 252 seconds) 03:57:57 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 04:07:32 --- join: proteusguy (~proteusgu@mx-ll-180.183.97-198.dynamic.3bb.co.th) joined #forth 04:07:32 --- mode: ChanServ set +v proteusguy 04:29:50 --- join: Green_flame (~cdadr@49.35.88.203) joined #forth 04:30:19 --- quit: Green_flame (Client Quit) 04:30:34 --- quit: Blue_flame (Ping timeout: 252 seconds) 04:30:48 --- join: Blue_flame (~cdadr@49.35.88.203) joined #forth 05:26:50 --- quit: Blue_flame (Quit: Blue_flame) 07:38:40 --- quit: tabemann (Ping timeout: 252 seconds) 07:53:31 --- quit: xek__ (Remote host closed the connection) 07:56:01 --- join: xek (~xek@user-5-173-136-60.play-internet.pl) joined #forth 07:58:53 --- join: xek_ (~xek@37.248.253.231) joined #forth 08:01:57 --- quit: xek (Ping timeout: 258 seconds) 08:37:28 --- quit: dave0 (Quit: dave's not here) 09:19:22 --- join: dys (~dys@tmo-111-173.customers.d1-online.com) joined #forth 09:20:52 --- join: xek__ (~xek@37.248.253.165) joined #forth 09:23:49 --- quit: proteusguy (Remote host closed the connection) 09:23:55 --- quit: xek_ (Ping timeout: 268 seconds) 09:42:53 --- join: proteusguy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 09:42:53 --- mode: ChanServ set +v proteusguy 10:03:16 --- join: xek_ (~xek@user-5-173-136-60.play-internet.pl) joined #forth 10:05:50 --- quit: xek__ (Ping timeout: 246 seconds) 10:43:38 --- quit: xek_ (Ping timeout: 246 seconds) 10:44:59 --- quit: gravicappa (Ping timeout: 245 seconds) 10:45:54 --- join: gravicappa (~gravicapp@h109-187-47-207.dyn.bashtel.ru) joined #forth 12:36:15 --- quit: gravicappa (Ping timeout: 245 seconds) 12:37:36 --- join: alexande1 (~alexander@ec2-52-34-17-143.us-west-2.compute.amazonaws.com) joined #forth 12:38:00 --- nick: alexande1 -> alex4nder 14:47:34 --- quit: deesix (Ping timeout: 272 seconds) 15:23:57 --- join: deesix (~dddddd@unaffiliated/dddddd) joined #forth 16:02:15 --- quit: deesix (Ping timeout: 248 seconds) 16:02:49 --- join: deesix (~dddddd@unaffiliated/dddddd) joined #forth 16:26:42 --- quit: john_cephalopoda (Ping timeout: 252 seconds) 16:40:11 --- join: john_cephalopoda (~john@unaffiliated/john-cephalopoda/x-6407167) joined #forth 17:10:17 --- quit: rprimus (Remote host closed the connection) 17:16:32 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 17:17:22 hi 17:18:13 g'day dave0 17:18:29 hi tp 17:18:43 sunny here, no rain today 17:18:52 20 C 17:19:52 * dave0 looks outside 17:19:58 bright light! bright light! 17:20:28 we had a great convo here day before yesterday, I learnt a few things and enjoyed it greatly. Ttmrichter also gave us his insight into the 'C' programming language and some STM32 low power insights 17:21:27 oh cool 17:25:04 with stm32 we play with saving microamps, not a problem to you X86 Forth builders! 17:25:53 doh i missed it 17:26:01 what does a I7 hexcore use flat out at 3.3v ? 30 Amps ? 17:27:53 it will be logged at http://forthworks.com/forth/irc-logs/19.06.25 I think 17:41:52 --- join: tabemann (~tabemann@2600:1700:c3e0:d390::15) joined #forth 17:52:51 tp: More L0 power insights. I FUCKING HATE LOW POWER APPS! 17:52:57 *ahem* 17:53:35 Low power is almost the poster child for cross-cutting concerns, I tell you. 17:54:02 hahah 17:54:30 ttmrichter, my interest is only academic as I dont make anything thats 'low power' or IoT 17:56:56 ttmrichter, when I fired up my L073, generated a bitfields file and compared it to a F051 my comments were WTF? everything was different and a heap of low power controlls for everything 17:57:02 I'm doing both. (Industrial IoT, not the bullshit being foisted on consumers.) 17:57:19 Oh, the peripherals in the L0 are SWEET. 17:57:20 ttmrichter, as you say, the much lower transistor count makes for manual everything 17:57:27 Far nicer than their F0 counterparts. 17:58:04 absolutely, the F0 doesnt have much for low power other than the LP 'modes' 17:58:04 But yeah, big learning curve when you move from one to the other. Jack up the paint job, insert an entirely new platform, lower the paint job. 17:58:45 what surprised me is the F0 and F0+ registers are totally different, even with the same names! 17:59:11 In the L0 for LP you've got all those modes, plus all those modes with the low power regulator. And you can switch individual components clock-on/clock-off (like with the F0) or clock-off-while-sleeping. Or reduced-clock-while-sleeping in some cases. 17:59:18 my snazzy register pretty print legends are all useless with M0+ 17:59:44 yep, it's enuf to inspire cross cutting hobbies as you say 17:59:59 It's a huge nightmare to get right. 18:00:11 But when you get it right it's really nice to see the low power usage. 18:00:31 but I guess it's about all the power switches a man could ask for, they are all there for the switching 18:00:43 Lowest power usage with decent response time is the "sleep on return" format where you basically write your whole application as a set of responses to interrupts. 18:00:57 wow 18:01:18 thats the other problem, wake up time. 18:02:01 You put the chip in STOP mode, you disable everything you don't immediately need for waking up, you switch to the low power regulator, and you set it to STOP on return. 18:02:04 in a Forth system it's kinda useless if it coes to sleep and takes 200mS to wake up between serial terminal comms 18:02:24 Something wakes you up, you respond to it, you go back to sleep. 18:03:08 If you need more processing, you set yourself up into regular run mode, and the code after the WFI continues. 18:03:29 Then that finishes and you go back into stop on return. 18:03:36 I should port hashforth to a microcontroller so I can play around with this kind of stuff 18:03:37 You can get some amazing power performance that way. 18:04:14 tabemann: Get used to staring at your meter and going FORTY-FIVE MICROAMPS!? WHAT'S SUCKING UP ALL THE POWER!? 18:04:26 (Yes. Micro.) 18:04:56 Only thing worse than doing LP work is doing RF work. 18:05:01 ttmrichter, I was amazed at the claims for the STM32L163 of "11 µA Low-power run mode" 18:05:02 So of course I'm doing LP RF... 18:05:12 ttmrichter, hahahaha 18:05:21 That's doable, but you're not gonna win any speed awards. :D 18:05:40 MSI for system clock, tightened down to (I think) 64KHz clock. 18:05:48 I think it uses a 160KHz clock to do that 18:06:00 oh yes, 64KHz 18:06:02 Might be 160. I can't remember all the MSI modes. 18:06:07 youre right 18:06:10 There's six of 'em and i use one. 18:06:38 But of course you then put a huge divider between the system clock and the HCLK. 18:06:45 still, if it's a optical GPS on a swallows head, battery life is far more important than speed 18:06:59 And then more huge dividers in front of the PCLKs. 18:07:05 --- quit: proteusguy (Ping timeout: 245 seconds) 18:07:18 You shut off EVERYTHING you're not using. (Possibly even Flash!) 18:07:30 --- quit: djinni (Ping timeout: 245 seconds) 18:07:35 Then you'll be at 11uA or so... 18:07:59 We got nailed by the 1uA stop mode claim. 18:08:04 It's ... technically true. 18:08:08 if STM say 11ua, Id expect maybe 50 uA 18:08:25 But realistically it's true that the CHIP is taking only 1uA. 18:08:56 Unfortunately you need to use an external crystal to get that. (HSI and MSI both take double-digit uA power.) 18:09:15 tabemann, going to a MCU will be a intersting experience for your hasforth as you have to deal with a million interrupts, FLASH minimum block sizes and RAM 18:09:17 And the external crystal takes up, at lowest drive, 0.5uA per volt. 18:09:35 plus the xtal needs POWARGH! 18:09:47 --- join: djinni (~djinni@static.38.6.217.95.clients.your-server.de) joined #forth 18:10:00 Yeah. You'll be stress-testing your interrupt architecture for sure with a uC. 18:10:30 tp: I do have an interrupt architecture at the moment, but it's really meant more for error handling and for handling alarm signals 18:10:34 ttmrichter, I get what you mean with your "FORTY-FIVE MICROAMPS!? WHAT'S SUCKING UP ALL THE POWER!?" lol, when it's a digital number on a display, even nS can seem a metre wide 18:11:14 I'd have to rework it to handle processor interrupts on an MCU 18:11:35 --- join: proteusguy (~proteusgu@cm-58-10-208-146.revip7.asianet.co.th) joined #forth 18:11:35 --- mode: ChanServ set +v proteusguy 18:11:50 hey proteusguy 18:11:54 I once had to reduce the response time of a RTC when the chip was accessed by the MCU, basically the RTC was too slow for a Rockwell 65F11 with onboard Forth 18:11:57 Yep. You practically live, breathe, and eat interrupts for any decently flexible uC system. 18:12:25 I managed to get the response time down by loading the RTC databus with resistorsd 18:12:41 I mean technically a polling-driven system is fastest, but ... no. You'll drive yourself batty doing anything of substance in a polling loop. 18:12:57 back then I was like "where is that extra 350 pico seconds comming from!" 18:13:06 Native coroutining could help there, but interrupts still give you better, more consistent, response times. 18:13:09 ttmrichter, yep, agree 18:13:21 the current architecture of hashforth is not realy interrupt driven but select() driven 18:13:33 And ... learn to french kiss your DMA controller. 18:13:36 as it's designed to be a hosted Forth 18:13:37 It will be your best friend. 18:14:07 Had a performance problem with an RF on SPI. 18:14:07 ttmrichter, my last project a multi temperature sensor using the LMT01 uses two interrupts, my first actual use of interrupts ever 18:14:14 Losing information big-time. 18:14:27 I'd probably have to rip out the whole architecture of hashforth as design it all around interrupts 18:14:29 Started using DMA for all the packets. 18:14:50 Power consumption dropped (because I could go into sleep mode while waiting) and never missed a byte. 18:14:51 tabemann, youd learn a LOT doing a small embedded Forth 18:15:12 God I love embedded. 18:15:13 because the cpu could do DMA in sleep ? 18:15:17 the core of hashforth is small; it's the whole "userspace" which is huge 18:15:38 I started in it, moved to PCs and servers, hated it, jumped the industry completely for a decade, came back to embedded, and ... here I still am. 18:15:45 ttmrichter, playing with DMA is next on my list 18:16:15 ttmrichter, and thriving in embedded from what I can see! 18:16:15 tp: One place where the L0 smokes the F0 is DMA and UARTs. 18:16:35 Using DMA for reception in the F0 is an exercise in frustration. 18:16:42 i know it has a low power usart, ill play with that soon 18:16:46 Using it in the L0 is a dream. 18:16:55 oh? nice! 18:16:57 Ugh. The LPUSART is a ... ugh. 18:17:07 I can imagine using DMA and interrupts to drive execution of Forth code from a serial port 18:17:11 The issue for the F0 is that DMA works by pre-determined packet length. 18:17:19 Id love to make a f0+ Mecrisp-Stellaris kernel that sleeps between serial comms 18:17:28 So if you decide to DMA 15 bytes, you receive 14 ... it will stay there forever. 18:17:51 oh, so avoid the lpusart ? 18:17:53 You have to do timeouts and such yourself manually. 18:17:58 eww 18:18:05 more cou overhead ? 18:18:08 cpu 18:18:14 you can't set it to wake up every so many ms and check to see how much is in the buffer if the DMA does not trigger an interrupt? 18:18:24 Well the LPUSART is a nice component, but it has a completely different way of doing everything from the other UARTs. 18:18:34 tabemann: You have to do that manually. 18:19:01 You have to set up a one-shot timer, renew that one-shot timer each time the DMA does its job, etc. 18:19:09 This is error-prone and convoluted. 18:19:16 tabemann, ttmrichter and I are talking stm32 but youd have a wider range such as NXP, Nordic etc 18:19:32 yes it is error-prone and convoluted 18:19:39 I can just imagine the race conditions it'd entail 18:19:48 You also have the option of setting up USART interrupts for framing errors and such which will give you NUL detection. 18:20:01 ttmrichter, Im doing a timer interrupt to time out the wait time for LMT01 pulses in my temperature sensor 18:20:23 If you get the NUL condition, again you can work out how much of the DMA has already been transferred, copy it out of the DMA buffer, turn off the DMA, etc. 18:20:44 sounds tedious ? 18:20:54 But with the L0 USARTs the DMA can be tied into the error signals so the DMA subsystem does it for you. 18:20:57 you're almost better off writing an interface layer on the other end and packetizing your data before you send it over the serial 18:21:20 So you get a DMA event for half-full, full, and error. 18:21:21 ttmrichter, oh ok, Im liking the lpusart again 18:21:25 Instead of just half-full and full. 18:21:33 LPUSART is a different beast. :D 18:21:46 The L071 I have has 4 USARTs and an LPUSART. 18:21:57 Welcome to ST! :D 18:22:27 someone ported Mecrisp-Stellaris to the l073 and i was wondering why they used the standard normal uart instead of the lpusart, now I think I know why 18:22:27 But the whole DMA architecture on the L0 and L4 lines has been completely reworked from the F line. 18:22:42 LPUSART is also limited in baud. 18:22:48 i noted a LOT of diffs 18:22:54 I think it can't go any faster than 19200? Maybe even 9600? 18:23:04 technically the Lx is just a M0+ ? 18:23:16 oh, that sucks 18:23:18 L0 is an M0+ and ST's third-generation peripherals. 18:23:25 I run my system here at 460800 18:23:51 L1 is an M3 and ST's second-generation peripherals. 18:24:09 L4 is an M4 (M4+ maybe?) and ST's third-generation peripherals again. 18:24:19 lol, and arduino users think that the stm32f103 is like alien tech compared to a MEGA328! 18:24:50 plus mow we have the M7 that can run at 400 Mhz 18:25:05 Did you see the MP1? (I think that was the name.) 18:25:13 i must get one soon and see how it goes 18:25:29 I dont think so 18:25:50 https://www.st.com/en/microcontrollers-microprocessors/stm32mp1-series.html 18:26:02 I'm confused. I'm just going to fo first port hashforth to the Raspberry Pi, once the Pi 4B is in stock again at one of the recommended vendors - lololol 18:26:07 A Cortex-A7 paired with a Cortex-M4. 18:26:19 ah yes, I saw that 18:26:48 looks too new and too hard for me, plus I dont need any Cortex A 18:27:07 i dont want to run linux and Mecrisp-Stellaris on the one chip 18:27:18 The intent for that is integrating sensor hubs with the UI component, basically. 18:27:35 tho I imagine ttmrichter's mind is revving with the possibilities ? 18:27:43 yeah, IoT again 18:27:45 Not mine. My boss's. 18:28:15 Right now we make a control hub based on PCs. They're big, power-hungry, and expensive. 18:28:17 ttmrichter, well yoy guys are into the bleeding edge 18:28:28 aha 18:28:44 for a first platform to port a forth to that doesn't run an OS, what'd you guys recommend? 18:28:46 AND we have all the usual issues of cabling and such to hook the PCs to the controller boxes. 18:28:49 so port to the new A7/M4 ? 18:29:08 tabemann: STM32L4. 18:29:25 Get one of the Nucleo or Discovery boards with an L4. 18:29:25 I think that the new A7/M4 is a STM32Gxx 18:29:46 You'll have a reasonably capable MCU with lots of things to toy with. 18:30:00 It's third-generation stuff, so ... more flexible and easier to use. 18:30:06 lol the L4 is a monster! 18:30:14 It *CAN* be a monster. 18:30:15 gotcha 18:30:21 But it's also trivial to get to blinky. 18:30:27 Because it has a whole bunch of sane defaults. 18:30:31 even the L162 is a monster to me 18:30:42 L1 is harder for me than the L4. 18:30:47 I want a minimum amount of time from porting the core to blinkenlichten 18:30:51 ahh, all thoise extra transistors ? 18:30:59 Yep. It's much smarter. 18:31:15 All you really need to get an L4 working is a filled-in ISR table and an entry point. 18:31:32 same as the F0 18:31:57 so just hook up an ST-Link, dump on a binary to flash, and apply power? 18:32:09 i can do a F0 blinky in assembly in 32 bytes inc startup code, no external components apart from a led 18:32:11 Pretty much, yes. 18:32:26 L4 pretty much the same. 18:32:28 tabemann, yep, theyre easy to talk to 18:32:34 Though the clock tree is a bit of a bear. 18:32:44 But again, sane defaults are in place. 18:32:51 ttmrichter, the L4 clock tree is a bear ? 18:33:12 Yep. But you can ignore it mostly. It starts up with the HSI as the clock source, so, 16MHz. 18:33:24 No PLLs. No dividers. 18:33:37 I've learned the f0 has sane defaults, now if only theyd set uart1 to run at 9600,n,1 by default :) 18:33:52 like the HC11 used to 18:33:57 That's a weird thing, yes. The USARTs never have sane defaults. :-/ 18:34:51 everyone used to warn me about the clocks on the F0 but Ive found the sane defaults make the whole thing easy 18:35:21 i can easily change from MCI to MCE and the pll + change serial baud rate 18:35:34 be back in a sec 18:35:37 even overclocking to 108Mhz works 18:35:57 up, 96 Mhz and 102 Mhz ? 18:36:17 I ran a F0 for 12 months at 98Mhz, it's still running fine 18:36:31 doubles the power to 32mA tho 18:42:39 back 18:43:00 welcome back! 18:43:21 tabemann, the mcu world is so different to the pc 18:45:10 tabemann, for instance some Flash implementations such as used by some NXP and by PIC SAMxxx have very large minimum Flash block sizes which makes it difficult for Forth 18:45:32 hence Mecrisp-Stellaris doesnt and wont ever be ported to them 18:47:35 this L4 board I'm looking at doesn't seem to be even in the same class as some of these MCUs - it has a whopping *128 K* of RAM and *1 MEG* of Flash 18:48:05 like fucking A - I can just build my whole application in RAM, and copy it into Flash 18:51:29 bbiab 18:56:29 --- quit: tabemann (Ping timeout: 276 seconds) 19:06:27 --- join: tabemann (~tabemann@2600:1700:7990:24e0:1ce2:9bd6:6ee:b28e) joined #forth 19:38:33 --- quit: dddddd (Remote host closed the connection) 20:02:34 tabemann, that's probably why ttmrichter suggested the L4, it's packed with resources 20:10:10 back 20:10:15 That's exactly why I recommended it. 20:10:16 welcome back! 20:10:24 It's the shallow end of the ocean. 20:10:39 hahah, you sure are a wordsmith ttmrichter 20:10:39 But it has loads of room for that depth when you start exploring the peripheral space. 20:10:59 You won't worry (much) about space, which lets you concentrate on how the damned devices work. 20:11:09 excellent advice 20:11:49 allowing one to focus on more important things, like making that damned LED blink 20:11:56 Then you can start looking at smaller L4s. 20:12:06 Like the Nucleo-32 board with an L4. 20:13:09 https://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-mpu-eval-tools/stm32-mcu-mpu-eval-tools/stm32-nucleo-boards/nucleo-l432kc.html 20:13:15 I've got one of these, for example. 20:14:16 any recommendations on a USB-serial interface to go with the STM32L4 Discovery board? 20:14:27 ttmrichter, I was very unimpressed with my nucleo, what a piece of junk, unfinished, incomplete schematic and only partial test pin labeling on the silk screen 20:15:09 frankly I'll never recommend another STM board again, next time someone asks I'll recommend they buy just the chip and deadbug it 20:15:22 That's based on this chip: https://www.st.com/content/st_com/en/products/microcontrollers-microprocessors/stm32-32-bit-arm-cortex-mcus/stm32-ultra-low-power-mcus/stm32l4-series/stm32l4x2/stm32l432kc.html 20:15:23 cheaper and much more satisfying 20:15:56 * tabemann probably doesn't have the dexterity to solder anything if the future of humanity depended on it 20:15:57 tabemann: Anything that's not based on FTDI. :D 20:16:06 My favourite poison is the CP2102. 20:16:25 Any USB/Serial bridge you find based on the CP2102 is fine. 20:16:33 28 nA Standby mode .... suuuuure! 20:16:54 I've managed to get to 50nA Standby... 20:17:20 I have both ftdi (older genuine) and CP2102 here, both are flawless on FreeBSD 20:17:35 ttmrichter, thats damn close for a STM claiM! 20:18:47 tabemann, and you want to resist the temptation to buy a STM32L4 'purple pill' or whatever the Chinese sell less you get a board with a renamed e-waste NE555 as the mcu! 20:18:58 you mean blue pill 20:19:04 I have heard bad things about those 20:19:08 like they're total crap 20:19:10 it's true 20:19:20 with the USB connectors breaking off due to bad soldering and like 20:20:24 I've made a page about it and even a utube video : https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32-boards.html?highlight=blue%20pill#stm32f103c8t6-blue-pill 20:20:33 * tabemann probably can't solder for shit, so he's glad the Discovery board has big fucking pins on it to attach to stuff with 20:20:47 and anyway, the stm32f103 is ancient 20:21:18 tabemann, actually the Discovery board DOESNT have big fucking pins, it's a disaster pin wise 20:22:06 the pins that stick out the top of the disco boards (where you want them) are really short and the dupont connectors easily fall off 20:22:27 it's very frustrating 20:23:15 okay, I must be mentally comparing them with the blue pill, wihch doesn't have pins at all 20:23:52 or at least very many 20:24:03 I invented the term 'purple pill' to describe not yet invented crap that uses more modern STM32L4's ;-) 20:24:31 thats another thing, the 'blue pill' doent have nearly enuf pins 20:24:46 which is why I think it's better to make your own 20:25:05 tabemann, you in germany ? 20:25:42 I hear the german Forth group will get the hardware guys to design and make boards for the software guys etc 20:25:43 ich kann ein bisschen Deutsch, aber ich komme aus Wisconsin, nicht Deutschland 20:25:52 shame! 20:26:16 well not so bad, youre in the USA, the heart of tech and innovation 20:26:52 if you cant do the soldering etc, a least design it and get a hardware guy to assemble it for you ? 20:27:45 at the worst you can buy a 'header board' and the chip and get someone to solder the chip and the pins to the header board / 20:27:46 I remember soldering together an AM radio for a summer school class in high school, and I kinda globbed on the solder 20:28:05 soldering needs a lot of practice and SMT needs special gear 20:28:19 but you can find a hardware guy to do it I'm sure 20:28:30 just trade some software for hardware work ? 20:28:38 I'm going to try with this Discovery board first 20:28:51 well you could do worse (blue pill) 20:28:58 I started with a disco board 20:29:11 at least theyre tested and working, quality boards 20:29:25 (apart from the too short pins) 20:29:29 yeah 20:29:42 and youll get a SWD programmer with it 20:31:11 but bear in mind that you can program a stm32 chip with nothing but a $0.90 usb/3.3v serial dongle 20:31:30 and that chip will run all by itself with 3.3v applied 20:31:52 which you can get from the same $0.90 usb/3.3v serial dongle 20:32:48 from reading some docs apparently the thing has a special protected part of the flash in which it runs a bootloader so you can reflash the thing no matter what even if you completely scramble the (writable) flash on it 20:33:10 --- quit: dave0 (Quit: dave's not here) 20:33:26 which I'm not sure about - I like the idea of having my code run from the very first cycle the processor executes 20:35:45 they probably figure this board will be used for things like kids controlling robots and like so they want to avoid the occasional bricking 20:36:14 and complaints from parents about how their kid's board has up and died 20:44:11 the bootloader is in ROM and is accessed by booting with BOOT1 pin HIGH 20:44:22 you cant kill the bootloader in any way 20:44:54 stm32 has so many ways to flash your image, it's a fabulous chip 20:45:31 you can completely forget about bricking any STM32 20:46:40 I havent managed to kill or brick any yet, tho a stm32f051 died when I flashed it in a disco board once, not my fault 20:47:23 other than that Ive soldered them mercilessly and fully expected them to die but nope! 20:48:25 you can probably kill it if you directly apply wall current to the board :D 20:49:31 but I'm glad they're hard to kill - I'd be worried that I attached something the wrong way and poof there goes the blue smoke 20:49:52 hahah, maybe! as a hardware guy I'm really impressed with the robustness of STM32 20:50:21 nothing is invunerable of course 20:50:54 * tabemann wonders if anyone has actually tried out the etherkiller on a real network 20:51:23 I bought 480 off stm32f051's back in 2014 (for $0.56 USD each) and Ive only used 3, so I have a lifetime stock, which is why I pretty much do everything with them 20:52:12 theyre 64KB flash and 8KB ram, run up to 98 MHz (overclocked) and 32 bit 20:52:23 plus have 33 peripherals on board! 20:52:48 the thing I don't get it is what is the point of having 32 bit words when you can only access so little space? 20:53:00 aren't those big addresses taking up so much precious space? 20:53:07 but a L4 is like the uss enterprise to my little F051's 20:53:33 the L4 is almost a "big" system 20:53:43 not big as in the way a raspberry pi is "big" 20:54:00 no, a rpi is a "A" class ARM chip 20:54:01 but "big" in that you don't worry too much about RAM or Flash 20:54:06 tabemann: The 32-bit thing actually helps in keeping power costs down. 20:54:29 Multiply two 16-bit values in a typical 8-bit MCU. 20:54:47 It's a sizable subroutine that absorbs loads of clock cycles. 20:54:57 you probably need fewer instructions to do typical math on a 32 bit system, true 20:54:58 Now multiply two 16-bit values in a 32-bit machine. 20:55:03 It's a clock cycle. 20:55:30 Back when I was first doing embedded there was all the noise around these for-purpose DSPs. 20:55:34 ttmrichter, the 32 bit data bus and the address bus of the cortexM dont have that much dependency on each other do they ? 20:55:36 Like the MC56K 20:55:52 tp: Not sure what you mean? 20:56:03 what'd make sense is to have 32 bit data words but 16 bit address words 20:56:30 Well with the Thumb2 stuff you almost get that. :) 20:56:35 on really small systems 20:56:48 One of the big complaints with ARM's original architecture was the code density. 20:56:59 ttmrichter, I mean as the M0 class only addresses it's internal peripherals, it's not that important ? 20:56:59 Precisely because of the huge addresses. 20:57:12 hence THUMB ? 20:57:35 the only problem with thumb is when you want to write a full 32-bit value to a register 20:57:40 tabemann, most of the cortexM-0 thumb are in fact 16 bit addresses 20:57:52 tp: The whole Cortex-M world pretty much only addresses internally. There isn't an external address bus on any of the devices I have that isn't a peripheral device controlled with weird mapping. 20:58:10 tabemann: That's a problem in ARM in general. 20:58:13 ttmrichter, thats what I was trying (poorly) to say 20:58:33 The ability to load a 32-bit value straight to register in ARM is a pseudo-instruction in the assembler. 20:58:39 There's no load-immediate 32-bit. 20:59:04 The Thumb approach isn't any more difficult than the full-ARM one. 20:59:16 I'm getting the picture that my 8/16-mode with 32-bit cell TTC code is gonna be pretty dense compared to native ARM code 20:59:19 thats one of the things I hate, the limited IMM range of addressing 20:59:44 because a normal token is just 8 or 16 bits, but if it encodes an actual value, that value, which would be 32-bit, comes right after the token 20:59:50 ttmrichter, I was wondering about full ARM vs thumb 21:00:12 whereas while thumb is dense instruction-wise, it's far more verbose than that for actually encoding 32-bit literals 21:00:54 actually, better yet, I could make multiple literal tokens, which take up different amounts of space 21:01:26 so for 8-bit values I don't need to take up the full 32-bit (or on 64-bit systems, 64-bit) space 21:24:26 --- join: gravicappa (~gravicapp@h109-187-47-207.dyn.bashtel.ru) joined #forth 22:59:02 --- quit: dys (Ping timeout: 272 seconds) 23:38:33 --- join: dave0 (~dave0@069.d.003.ncl.iprimus.net.au) joined #forth 23:53:06 --- quit: jimt[m] (Remote host closed the connection) 23:53:13 --- quit: bb010g (Write error: Connection reset by peer) 23:53:18 --- quit: siraben (Write error: Connection reset by peer) 23:53:56 --- join: dddddd (~dddddd@unaffiliated/dddddd) joined #forth 23:59:59 --- log: ended forth/19.06.27