00:00:00 --- log: started forth/20.05.13 00:28:52 --- join: xek__ joined #forth 00:31:16 --- quit: xek_ (Ping timeout: 260 seconds) 00:58:47 --- join: Labu joined #forth 02:06:22 --- join: dddddd joined #forth 02:20:49 --- quit: presiden (Ping timeout: 240 seconds) 02:21:19 --- quit: nmz (Ping timeout: 260 seconds) 02:21:46 --- quit: WilhelmVonWeiner (Ping timeout: 272 seconds) 02:27:15 --- quit: WickedShell (Remote host closed the connection) 02:47:52 --- quit: rdrop-exit (Ping timeout: 256 seconds) 02:58:52 --- join: rdrop-exit joined #forth 03:01:32 --- quit: proteus-dude (Ping timeout: 256 seconds) 03:01:49 --- quit: jsoft (Ping timeout: 258 seconds) 03:13:50 --- join: proteus-dude joined #forth 03:20:10 --- join: deesix joined #forth 03:20:38 --- join: dddddd_ joined #forth 03:22:23 --- quit: dddddd (Ping timeout: 246 seconds) 03:22:43 --- join: dddddd__ joined #forth 03:22:44 --- quit: deesix_ (Ping timeout: 246 seconds) 03:25:47 --- quit: dddddd_ (Ping timeout: 264 seconds) 03:25:47 --- quit: deesix (Ping timeout: 264 seconds) 03:25:49 --- quit: proteus-guy (Read error: Connection reset by peer) 03:25:49 --- quit: proteus-dude (Remote host closed the connection) 03:27:56 --- quit: dddddd__ (Ping timeout: 240 seconds) 03:29:38 --- join: deesix joined #forth 03:30:02 --- join: dddddd__ joined #forth 03:30:17 --- nick: dddddd__ -> dddddd 03:38:58 --- join: iyzsong joined #forth 04:01:07 --- quit: mtsd (Quit: Leaving) 04:17:46 --- quit: rdrop-exit (Quit: Lost terminal) 04:19:18 --- join: iyzsong- joined #forth 04:20:19 --- quit: iyzsong (Ping timeout: 260 seconds) 04:28:56 --- quit: iyzsong- (Ping timeout: 240 seconds) 04:31:28 --- join: iyzsong joined #forth 04:41:32 --- join: X-Scale` joined #forth 04:43:56 --- quit: X-Scale (Ping timeout: 246 seconds) 04:43:57 --- nick: X-Scale` -> X-Scale 04:50:42 tp: i tried to enable RTS and CTS on the blue pill but it didn't work on usart1 04:50:54 even after remapping can1 to other pins 04:51:26 btw do your bitmap words using bis! really assume that all bitfields default to all zeroes? 04:52:06 crest, the blue pill can be very frustrating to work with and although I think the need to simplify the GPIO config is overly complicated, I see the need for it 04:52:52 it's really annoying it looks like the macos ftdi232 driver lacks hw flow control support 04:52:59 crest, the 'reset:xxxxxxxx' is derived from the cmsis-svd 04:53:20 on a freebsd system picocom displays the flow control as RTS/CTS 04:53:20 so whatever it says in the bitfields is what you will get on a hardware reset 04:53:27 on mac os it displays RTS/CTS (none) 04:53:47 but there is no way to clear bits set by default 04:54:10 ? 04:54:13 e.g. most gpio pins default to $4 in their CRL/CRH bitfield 04:54:38 just setting more bits isn't the right thing to do 04:55:07 you have to load the old register value, mask the bitfield, insert the new value and write it back 04:55:13 GPIOB_CRL (read-write) Reset:0x44444444 ? 04:55:22 like that ? 04:55:24 yes 04:55:39 thats controlled by the micro reset microcode etc 04:55:47 no way you can change that 04:56:08 except after reboot, then you can do what you like 04:56:08 that's fine because it you want the reset logic to put the pins into a "harmless" state 04:56:19 exactly, and all the MCU's do it 04:56:44 looks like you have a explosion of problems ? 04:56:48 but just setting more bits in the register to "1" isn't enough to configure the hardware 04:56:57 (to misquote rdrop-exit) 04:57:24 no, and I'm actually working on a way to fix this for the damn F103 for once and for all 04:57:41 it's as codeless as it can get 04:57:49 i just looked at your code and noticed that the code didn't insert bitfields 04:57:59 afterall the best and most reliable code is code thats not there 04:58:08 instead it just ORs the new bits into the memory mapped register 04:59:23 please pastebin code snippets etc as Im always working on other stuff and cant immediately grok what you mean 04:59:47 I'm about 100 IQ points short for that kind of caper I suspect 04:59:55 : GPIOA_CRL_MODE0 ( %XX -- ) 0 lshift GPIOA_CRL bis! ; \ GPIOA_CRL_MODE0 Port n.0 mode bits 05:00:07 : GPIOA_CRL_CNF0 ( %XX -- ) 2 lshift GPIOA_CRL bis! ; \ GPIOA_CRL_CNF0 Port n.0 configuration bits 05:00:13 etc. 05:00:25 they just shit the argument by the correct amount of bits 05:00:33 and use bis! 05:00:44 yes 05:00:53 which loads the old value, combines the two with logical or and writes it back 05:00:55 I know that 05:01:38 is that a problem, do you have a better way ? 05:01:44 the problem is the mcu doesn't use an all zeroes 05:01:56 ah yes! 05:01:59 and there is no way to clear "1" bits from registers that way 05:02:02 a very cood point 05:02:05 good 05:02:35 yes the correct solution is something like what i did in my crazy cr! word 05:02:47 which is why it's been changed 05:03:01 no, yours is not tackling the root problem 05:03:03 but if the bit field boundries are fixed you can simplify the code by using constants 05:03:32 if you dl the latest version I made for you : https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/svd2forth-v3-2d786271ca-stm32f103c8t6-bitfields.fs.gz/download 05:03:47 you will see that the BIS! is gone 05:04:00 it's been gone for quite a while here 05:04:13 this is my plan .... 05:04:24 tell me what you think ? 05:04:34 GPIOA_CRL defined somewhere? 05:04:56 sure, in the memmap.fs which you have 05:05:02 thats never changed 05:05:08 that code can't work because you pass to few arguments to it 05:05:26 see the stack comment ? 05:05:38 ( %bb -- x addr ) 05:05:39 but you need the start and end bit of bit field 05:05:48 that code works as designed 05:05:58 but it doesn't solve the problem 05:06:09 it's up to you to add a BIC! or a BIC! 05:06:09 it just passes the buck to the next guy 05:06:14 hahahaha 05:06:27 it should replace the bitfield 05:06:35 the programmer is expected to know what he is doing 05:06:44 a hammer wont build the house for you 05:07:00 no, it must NOT replace the bitfield at that stage 05:07:10 no but i expect my drill to turn if i pull the trigger 05:07:13 or you get what you complained about earlier 05:07:41 instead of reminding me to turn the drill clockwise really quickly 05:10:30 my next idea is to replace the cmsis-svd and join MODE0 and CNF0 into a new bitfield 05:10:31 do you see the appeal of %1010 PINx GPIOx CR! 05:11:02 it works the same for all possible values of mode, cnf, pin and gpio 05:12:05 no, i'll never use that format, but I do see the appeal of output gpioa-mode-10 05:12:15 or something like that 05:12:20 it doesn't matter if the pin falls into the high or low half of the control register 05:13:03 the default mode is input analog floating iirc 05:13:14 on most pins 05:13:27 --- join: proteus-guy joined #forth 05:13:31 and it's easy to change to output pushpull in one operation iorc 05:13:36 at least floating input 05:13:39 on all pins 05:13:48 it's changed by Mecrisp-Stellaris at bootup 05:13:49 what about jtag? 05:13:49 --- join: proteus-dude joined #forth 05:14:07 ok, apart from jtag :) 05:14:21 all pins except jtag 05:14:43 hey I dont actually use the F103, it's my least fav cpu 05:15:35 if you want instant correct answers youll have to ask me about the F051 05:15:54 is it possible enable RTS (and CTS) at runtime? 05:16:06 sure 05:16:10 thats what I do 05:16:20 --- quit: proteus-dude (Client Quit) 05:16:47 i pasted the source I use for the f103 for you a while back 05:16:55 is it enough to put the RTS pin into 2MHz alternate function push-pull mode and set the RTSE bit in the USART CR3 05:17:05 i know and i looked at it 05:17:14 firstly, forget all the 'speed' modes 05:17:28 it doesnt matter, use the default whatever it is 05:17:36 i used it in an attempt to replicate it in forth 05:17:59 it's from Frank Sargeants Forth on the F103 05:18:28 and what I use in any F103 kernels I make 05:18:52 is it enough to put the RTS pin into 2MHz alternate function push-pull mode and set the RTSE bit in the USART CR3 ? 05:19:12 no, you must assign a GPIO pin to RTS signal as well 05:19:22 i wanted to understand the code and not just copy and paste some magic incantation into terminal.s 05:19:22 then youre done 05:19:33 then get out your GAS book ? 05:19:49 and the M3 assembler book 05:20:04 oh, and the technical ref 05:20:10 i did 05:20:21 and my equates.s file :) 05:20:47 I also generate every equate for the chip 05:21:22 i even looked at the errata for the chip 05:21:44 i used it to make the first f103 RTS mod and it failed badly, so I copied franks work and moved on because ... I dont use that chip 05:21:51 which is how i found out about the pin conflict on PA12 between CAN1 and USART1 RTS 05:22:23 which is why I mentioned that to you earlier and always put the terminal on usart2 05:22:41 usart1 competes with can and usb 05:22:44 the problem according to the errata is that can1 blocks any other alternate function on PA1 even if CAN is disabled unless CAN is remapped 05:23:00 welcome to the nasty f103 05:23:15 but changing CAN_REMAP from %00 to %10 should fix that 05:23:21 please dont assume that I care what the f103 does 05:23:25 ok 05:23:49 it's ancient and nasty junk, only a lot less nasty than avr 05:24:15 do you care about anything other than f051? 05:24:24 hell yeah 05:24:30 f407? 05:24:45 not really, it's too advanced for what I need 05:24:49 I have one 05:25:11 I take the pushbike to the shops not the F16A in the hangar 05:25:31 and who needs 1MB of flash ?? 05:25:34 not me 05:25:38 your bitfields :-P 05:25:45 I love the MSP430 05:26:05 the 6800, 68hc11, 6805 05:26:05 but i'm sure it won't be able to old bitfields for its hardware :-P 05:26:20 i never msp430, but the instruction set looks nice 05:26:37 i have a esp2866 that I just cant be bothered with 05:26:42 cleaned up pdp11 with more registers at the cost of few addressing modes 05:26:51 the msp430 isa is so sweet! 05:27:18 it should be easy to write assembler msp430 05:27:24 I like various PICS, theyre fast and reliable 05:27:29 yeah it is 05:27:38 but the pic isa is nasty 05:27:47 I plan to get back to the msp430 soon for a while 05:27:58 yeah but I run Forth on them so I dont care 05:28:10 PIC + Forth is ok 05:28:36 nothing special but fast and reliable, some good peripherals, all in dip SMT 05:28:52 i have about 100 in stock 05:29:09 which forth do you run on pic? 05:29:16 id never do pic assy, it's hateful 05:29:20 flashforth 05:29:26 but there are a few 05:29:30 amforth 05:29:52 pics have been popular among Forth writers 05:30:06 lots of useful peripherals? 05:30:37 but the botton line is that I have 480 off STM43F051 and they do everything all the others do, so why stray from the f051 ? 05:30:40 yep 05:30:59 plus I love the QFN32 package, it's my ideal 05:31:17 it's tiny and thin, 5x5x1.2mm 05:31:29 yet the pins are 0.5mm apart and wide 05:31:39 and I have no problems soldering them 05:32:06 I'm a Forth user, I just make things 05:33:08 ill be starting my execise box soon, and that should showcase my current IDE and bitields 05:33:48 it's a fair project, touch sensor, timers, low power, interrupts, rtc, lcd 05:34:42 hmm, maybe I should release my ultra simple, low power nightlight first ? 06:06:22 --- quit: crest (Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) 06:06:45 --- join: WilhelmVonWeiner joined #forth 06:07:07 --- nick: WilhelmVonWeiner -> Guest38566 06:08:21 --- join: nmz joined #forth 06:08:22 --- join: presiden joined #forth 06:08:52 --- join: crest joined #forth 06:29:16 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 07:04:24 --- join: jsoft joined #forth 07:46:47 --- quit: jsoft (Ping timeout: 264 seconds) 08:12:42 --- quit: Zarutian_HTC (Ping timeout: 258 seconds) 08:17:29 --- join: TCZ joined #forth 08:31:26 --- join: Zarutian_HTC joined #forth 08:34:16 --- join: karswell joined #forth 09:16:39 --- quit: dys (Ping timeout: 260 seconds) 09:20:58 --- quit: cantstanya (Write error: Connection reset by peer) 09:23:04 --- quit: ornxka (Quit: No Ping reply in 180 seconds.) 09:23:41 --- join: cantstanya joined #forth 09:24:12 --- join: ornxka joined #forth 09:58:54 --- join: jsoft joined #forth 10:07:55 --- quit: TCZ (Quit: Leaving) 10:20:37 --- quit: jedb (Remote host closed the connection) 10:26:06 --- join: WickedShell joined #forth 10:29:47 --- join: jedb joined #forth 12:13:43 --- quit: karswell (Remote host closed the connection) 12:15:12 --- join: karswell joined #forth 12:15:24 --- quit: cantstanya (Remote host closed the connection) 12:17:43 --- join: cantstanya joined #forth 12:24:20 --- quit: jsoft (Ping timeout: 260 seconds) 12:58:08 --- quit: cheater (Ping timeout: 246 seconds) 12:58:39 --- join: cheater joined #forth 13:13:03 --- quit: C-Keen (Quit: WeeChat 2.6) 14:51:29 --- quit: gravicappa (Ping timeout: 260 seconds) 14:51:29 --- quit: reepca (Read error: Connection reset by peer) 14:52:01 --- join: reepca joined #forth 15:03:37 --- quit: jedb (Remote host closed the connection) 15:03:51 --- join: jedb joined #forth 15:16:28 tp: i patched mecrisp st with ascii control chars in Fehler_Quit(_n) and quit 15:16:52 the this allows me to upload code without line delay or (working) hardware flow control 15:17:32 and uploads stop at the first error with a file name and line number 15:17:52 crest, nice work! 15:18:28 the upload tool works as picocom send-cmd 15:19:08 so far the code is wastes host cpu cycles because it transmits one byte at a time 15:19:16 but it simplifies the code 15:22:00 the only problem is that it locks up on very long lines 15:22:24 that sounds like a flow control problem ? 15:22:28 but it looks like mecrisp itself just hangs if you attempt to send (close to) 200 bytes 15:22:49 the input buffer size is just 200 bytes 15:23:28 ahh yes, if it's really long and waiting for a cr 15:24:00 because I use m0, I have a habit of using short lines to reduce the load 15:24:05 maybe i could fail after 198 bytes and add a \r\n 15:24:43 i want to tool to handle long lines with a graceful error instead of a unresponsive forth system 15:24:54 good idea 15:25:34 because shit happens 15:25:41 maybe generate a coloured warning at X chars ? 15:25:58 i want to upload to stop with an error 15:25:59 everything has a limit 15:26:18 sure but it shouldn't require a forth system reset because that loses the mcu state 15:26:30 except my propensity to write bad Forth code of course 15:26:49 agreed 15:26:50 sure you can crash the system 15:27:21 it even works with a fucking ft232 15:27:35 i use them all the time without issues 15:27:43 this braindead chip takes up to 3 bytes to react to hardware flow control 15:28:03 do you have fake ones tho ? 15:28:20 according to the fdti website you should think of it as a packet oriented chip and not a true serial port 15:28:27 I have no issues with ft232 myself 15:28:39 at that point i gave up on getting flow control for usart1 working 15:28:58 and started writing something cleaner 15:29:33 flow control with usb/serial is always a problem, and why I use hardware handshaking 15:30:01 the usb side is buried in complex flow control methods that few seem to understand 15:30:09 all too hard 15:30:44 I've been watching a online debate over this exact issue and everyone seems confused 15:31:03 --- join: dave0 joined #forth 15:39:20 usb serial itself is pretty nice from the usb end of things 15:39:34 or usb modem class is 15:39:49 it just transmits the payload as usb bulk frames 15:39:59 those are checksummed and acked with backpressure 15:40:27 if the receiver is busy it replies to a message with stall and the sender is required to retransmit it 15:41:18 so usb modem emulation is faster than a any reasonable clocked usart with flow control 15:41:34 tp: https://github.com/Crest/upload/blob/master/upload.c 15:41:40 its just a rough draft 15:41:52 *it's 15:46:59 crest, yes, usb terminal on the F103 is substantially faster than anything I can do in serial 15:48:50 would it be possible to keep enough of the usb state to keep the device connected during a mcu reset? 15:50:30 I've no idea, but you can do a mecrisp-stellaris "clear ram" instead of a mcu reset ? 15:51:01 i use that method with my ihex binary generator 15:51:09 at least it should be possible to write usbcomm tool that reconnects automatically 15:51:27 *a usbcomm 15:51:39 so that c file is your 'uploader' which is called by picocom ? 15:51:45 yes 15:52:04 i added ascii ack to quit 15:52:11 thats a interesting take on the problem 15:52:27 and ascii nak to Fehler_Quit(_n) 15:52:44 as 'quit' is the outer interpreter ? 15:52:51 yes 15:53:02 i just added it after "ok." 15:53:35 unless you transmit raw binary data there shouldn't be any data transparency problems with this 15:53:48 thats one of the awesome features about forth, everyone has their own solution and thats real diversity! 15:54:13 because those control sequences were put into ascii exactly for control purposes 15:54:18 yes 15:54:45 I transmit the dictionary contents as ihex to get around the binary transmission issue 15:55:27 it works fine and the built in crc means I never get any errors 15:56:25 would it be possible to use a pair of ring buffer accessed via swd as console? 15:57:02 the debugger would poll the write index of one ring buffer and consume from it 15:57:02 woo! thats a 'out there' question! 15:57:12 and append to the other one 15:57:22 it would keep as many pins free as possible 15:57:33 and be super fast ? 15:57:37 and you could use a stlink v2 clone around 15:57:51 everyone has one except blue pill users ;-) 15:58:11 even many blue pill users have stlink v2 15:58:16 I mean every stm32 disco and nucleo board comes with one 15:58:19 i just got mine today 15:58:25 but haven't used it 15:58:38 (yet) 15:58:58 there would be a lot of overhead on the wire and the host cpu 15:59:01 but who cares? 15:59:02 yes, the cheap $2 blue pill is often sold with a cheap $2 stlink v2 clone taking the price to $4 ish 15:59:14 the mcu is the bottleneck after all 15:59:27 not me, pcs have plenty of grunt to spare 15:59:48 what is so crazy about of this idea? 15:59:59 those stlink v2 clones often come with clone stm32f103's 16:00:14 its just a shared memory buffer with two single producer, single consumer ringbuffers 16:00:24 I'm not qualified to judge, I have no experience there 16:00:35 if the debugger could raise an interrupt it the mcu wouldn't even have to poll 16:00:38 it sounds like a great idea tho 16:00:54 but then youd have to build a terminal for it ? 16:01:03 yes 16:01:21 it would be revolutionary I think 16:01:25 or use something like cuse4bsd to expose it as char dev 16:01:35 as you say, simple to use, wastes no pins 16:02:02 youll get about 4 users tho 16:02:16 not that Id care, as I may be one of them 16:02:30 you could even stop the cpu and traverse the dictionary to check if a word is already defined to implement #require 16:02:37 but Mecrisp-Stellaris is used my many windows and Linux users 16:02:57 expose the serial as telnet server on ::1/127.0.0.1 16:03:04 (let them use cutecom and e4thcom ;-) 16:03:28 cutecom? 16:03:56 I have a telnet facility on the Tiva but was never able to use it the way I use screen 16:04:18 cutecom is a serial terminal common among windows users 16:04:21 I think 16:04:31 theyre all pretty horrible 16:04:41 oh shit the screenshot looks horrible 16:04:48 yeh 16:04:58 dont bother even looking at those things 16:05:01 it wastes 1/4 of the screen with bloated ui elements 16:05:05 theyre just horrible 16:05:11 agreed 16:05:29 I couldnt use Forth if I had to use it with that stuff 16:06:00 running this swdcom as daemon would be nice 16:06:06 it could bind a unix domain socket 16:06:21 and a suitable client could just pass file descriptors to upload 16:06:24 youre light years ahead of me in that area 16:06:44 have you used urxvt(cd) 16:06:53 it rings a bell 16:07:06 a udp terminal ? 16:07:19 urxvt is a pretty heavy x11 terminal with unicode support 16:07:42 e.g. it can mix different fonts to display almost all unicode ranges with a good looking font 16:08:32 because most good fonts for chinese or japanese look crap for other code points 16:08:57 if you want to display japanese and code at the same time 16:09:12 but it starts a bit slow because all this stuff 16:09:28 because of this you can run it as daemon 16:09:40 on first use (or in .xsession) it starts as daemon 16:09:58 and all new windows just connect to this daemon reducing startup time 16:10:23 you could do something similar with the swdcomm 16:10:53 on first use it would scan all devices and start a daemon per detected device 16:11:04 or at least per serial number 16:11:20 you than connect to this daemon to upload files or attach to the console 16:11:47 that should be possible if ARMs claims about the m3 debugging support hold water 16:13:39 I got around to writing my keyboard interrupt handler in forth on the ZX Spectrum, which profiling has indicated runs in around 10ms 16:14:30 Was quite cool watching it run and it does complete faster than the frame, with multiple loops and if statements running within its logic 16:14:34 Nice performance test 16:14:48 Totally inappropriate though, I'm going to rewrite this handler in assembly lol 16:15:00 how much rum do you need for your zx forth? 16:15:14 would it run on a zx81 with 16kb ram extension? 16:15:43 It's currently under 4KB, but not sure where it will land 16:16:14 3485 right now 16:17:14 I have an option to build it as a tokenized forth, which in the long run should allow it to remain very small so should be able to squeeze some form onto a 16K spectrum, not sure about ZX81 but probably similar enough so yes 16:17:58 I'm at the point where the tokenized version is about 30 bytes larger or something, I should break even soon. 128 tokens might be too much of a table overhead, might try with 64. 16:18:55 I know tp's eyes are glazing over 16:21:30 Currently it has separate headers, so programs produced using this forth environment should actually be able to shave off a big portion of the ram usage / image size if interpreting and word lookup is no longer needed in deployment 16:23:22 tp: i just attached my stlink v2 (clone) and it detected the stm32f103 16:23:44 but it stops the forth console (probably the whole m3 core) 16:25:41 1243 bytes form the headers for the current output, so 'decapitated' image as rdrop puts it would be 2242 bytes. 16:26:12 Anyway that's enough fun for today 16:27:23 the freebsd stlink package includes a shared lib and c headers for it that is used to implement the st-util gdb server 16:27:59 and it includes a write_mem8 and write_mem32 etc. 16:28:30 if the 32bit writes are atomic it should be enough to implement a single writer, single reader ring buffer 16:29:15 crest, I rarely use the terminal anyway, 95% of my interaction with the mcu is done from my editor 16:29:35 which explains why upload speed is so important to you 16:29:43 crest, your swd interface does sound very exciting, it would be a *new thing* for Mecrisp-Stellaris 16:29:56 crest, yes, upload speed is everything 16:30:00 my ack based flow control isn't? 16:30:13 and an other advantage is that the receive buffer would be in the sram 16:30:24 the debugger could write to the buffer while the compiler is busy 16:30:40 making good use of the available write bandwidth 16:30:43 your ack based flow control is very interesting, I'll definitely be thinking about that 16:31:03 just a handful 1 byte changes 16:31:29 i followed the color support code to guide me to all places that needed changing 16:31:46 tabemann, also uses ack based flow control but I didnt really follow how it was implemented, you have filled in a lot of my ignorance there today 16:32:14 even more important to me than the speed is reliable error reporting 16:32:23 it aborts on the first compile error 16:32:33 crest, the Mecrisp-Stellaris assembly is actually quite easy to follow, even the special german linguistics can be decoded ;-) 16:32:47 yes, agree 100% 16:33:09 when I first used Mecrisp-Stellaris it was slow and locked up with no errors 16:33:18 even as a native speaker i'm confused my the german/english mixture 16:33:36 and I wondered how anyone new to Forth would consider using it for more than 5 minutes 16:34:14 good question 16:34:27 and an important one if we want to grow the userbase 16:35:08 i think that it's a easy question and the answer is ... "they would ditch it immediately" 16:35:34 i suspect a module system would help 16:35:42 it's usless as is, when compared to Gcc, openCM3 and gdb 16:35:56 e.g. this is how you use gpio port, timer, usart etc. 16:36:05 that C system wipes the floor with the basic Mecrisp-Stellaris and many forths 16:36:44 what changes things for you? 16:37:14 just your screen setup? 16:37:50 basically yes 16:38:00 I write code and click make 16:38:06 same as using Gcc 16:38:14 okay the st-* tools link against libusb to talk to the debugger 16:38:19 the source is uploaded and runs on the target 16:38:29 i like to play with the system on the console 16:38:32 errors are easy to see and hear 16:38:48 mine is a very fast and easy to use system 16:38:51 but the danger is that your microcontroller grows true state 16:38:59 e.g. each chip holds its unique state 16:39:02 --- quit: djinni (Quit: Leaving) 16:39:09 that exists nowhere else 16:39:17 * tp examines the mcu ... nope nothing growing on it 16:39:23 :-) 16:40:15 where does that danger lay ? 16:40:33 is is contagious, will my other chips be infected ? 16:40:42 you grow your forth system on the console without keeping the source code somewhere 16:40:55 do they need to observee a 'chip distancing rule' ? 16:41:07 in the end it kinda works but nobody know why or how 16:41:16 and taking a hexdump isn't the same thing 16:41:27 no, the source is saved in the editor and versioned as I go 16:41:43 in your setup it is 16:41:53 but if you just type at the console until it works 16:41:59 the source is treated exactly the same here as it would be with a C system 16:42:11 and version controlled? 16:42:17 in fact I think many C users would feel a bit uneasy if they saw it 16:42:24 yes, with fossil SCM 16:42:34 good choice for personal projects 16:42:38 everything in one sqlite db 16:42:44 even tickets and a wiki 16:43:47 and you can even keep unversioned blobs like releases or build artifacts in it and sync them between systems 16:43:54 yeah, it is fabulous for me, even CRC uses fossil for RETRO, and if you ever look at that project, youll see it's so well organised it should be german! 16:44:13 what annoys me is the lack of something like git add -p 16:44:34 crest, for personal projects ??? fossil does everything GIT does and does it properly 16:44:41 i often work on several parts of a file and want to add them one clean commit at a time 16:45:19 instead of having to add all changes to a file in a single commit or undo them manually and add them manually in multiple stecks 16:45:21 *steps 16:45:25 hmm, I should append my above comment ... fossil does everything GIT does and does it properly for me :) 16:45:51 its a small feature but it's important for my personal workflow 16:46:11 the other problem is that few people know about fossil 16:46:15 and thats all that matters 16:46:49 and are you *sure* that fossil doesnt have that capability ? 16:50:56 crest, I know that GIT is a million times more common than Fossil, but that metric doesnt mean much in this day and age 16:51:13 it does for larger projects 16:51:36 git lowers the barrier to entry 16:51:46 and there is a lot of useful tooling around git 16:51:53 crest, windows is also a million times more common than Linux on the desktop, but does that make it superior in any way otehr than marketing and retail channel ownership ? 16:52:30 this more like comparing freebsd and linux as webserver 16:52:41 sure i prefer freebsd 16:52:44 crest, I bet 99% of git users use it for small projects as a downloader 16:52:54 but those aren't important 16:53:01 I bet most of them have no idea what a rebase is 16:53:13 they just want a tarball or even worse something to pipe into sudo bash 16:53:29 but the project cares about attracting talent 16:53:44 actually I dont rebase as fossil doesnt have it, and doesnt need it 16:53:50 hahaha 16:53:59 e.g. fossil is good enough for most projects 16:54:13 but it wouldn't be able to handle the freebsd base or ports repos 16:54:18 the history is too large 16:54:33 even git struggles with the freebsd repos (base, ports) 16:54:42 sure 16:54:42 it used to break github 16:55:17 but git was improved to handle huge repos better because freebsd (and a few others) demonstrated that this is a real world usecase 16:55:24 are you telling me that if I want to go fishing I should buy a aircraft carrier to cast my bait from ? 16:55:27 there are bigger and older repos than the linux kernel 16:55:40 shouldnt I use something suited for my needs ? 16:55:54 for your personal project you should use whatever works for you 16:56:07 but if you want to grow the project into a larger team effort 16:56:12 well, Mecrisp-Stellaris isnt one of them and nor are 99% of all projects on github 16:56:26 in fact Mecrisp-Stellaris uses no scm 16:56:34 *sigh* 16:56:35 matthias doesnt need one 16:56:52 is the Linux kernel on github ? 16:57:02 yes (official mirror) 16:57:27 and for a while the official copy was on github because kernel.org had slight security problems 16:57:55 well then, everyone writing a Forth blinky should immediately change to git on github for the 40 lines of source ? 16:58:07 and I have a copy of the Linux kernel here 16:58:13 it's no big deal 16:58:23 --- join: xek joined #forth 16:58:45 linus said 'why should I backup the kernel, there are thousands of copies on the net' 16:59:29 sure but which ones can you trust? 16:59:40 id trust your copy :) 16:59:40 --- quit: xek__ (Ping timeout: 260 seconds) 16:59:57 i don't think i have a recent copy of the linux kernel repo 17:00:07 actuall same here 17:00:13 I'm a FreeBSD user 17:00:40 i do have lots of freebsd svn checkouts 17:00:46 and a few git clones as well 17:01:03 crest, religious scm debates aside, I think your take on a new Forth terminal is exciting 17:01:32 that's the kind of stuff I find really interesting, I'm just a scm user 17:01:46 i won't file any ridiculous software patents on it. feel free to implement it :-P 17:02:11 crest, feeling free and having the capabality are two different things 17:02:26 my system works perfectly for me and I understand it 17:03:02 it works so well that I never worry about it, projects just get built and the work only involves the project 17:03:51 I have no intention to spend another 4 years developing something else to do the same thing in a better or more modern network centric way 17:04:30 too bad 17:05:13 I read about people using C and eclipse waiting 5 minutes to compile a small project etc, Id give up developing if that applied to me 17:06:04 I wait for almost nothing, the longest is building a binary release from the chip itself, which while being fully automated can take 30 seconds 17:07:15 that release also includes a readme in html, two copies of all (non kernel) source, one with comments and one without, a Word list etc 17:08:05 everything needed to rebuild the project using whatever Forth terminal system you use 17:08:12 --- join: rdrop-exit joined #forth 17:17:28 --- join: djinni joined #forth 17:19:24 --- quit: Zarutian_HTC (Read error: Connection reset by peer) 17:20:02 --- join: Zarutian_HTC joined #forth 17:21:32 hey guys 17:22:12 tabemann: have you ever written directly to the sram with the stm32* running while debugging your forth? 17:22:50 you mean use gdb to do so? 17:23:05 yes while the core is running 17:23:10 no I haven't 17:23:12 hey tabemann 17:23:24 not stop at a breakpoint and debug 17:23:47 e.g. change the delay of a delay loop while it's running 17:24:06 because if you check the backlog you can find my crazy idea 17:24:24 use a pair of ring buffers in sram as console for the forth system 17:24:30 I'm gonna create a release with teh Debugger shortly 17:25:08 what I have done is modified fields from the Forth REPL while things are running via multitasking 17:25:14 good morning Forthwrights c[] 17:25:22 hey rdrop-exit 17:25:30 hi tabemann 17:25:59 i want to use libstlink-shared to access the ring buffers to get a fast reliable console 17:25:59 hey rdrop-exit 17:26:04 hi tp 17:28:10 crest, when I tested micropython on a M4 I was really impressed with their full screen editor, it was awesome to use ... shame about the rest of the micropython tho 17:28:29 crest, but that editor was luxurious 17:29:02 --- quit: dddddd (Ping timeout: 256 seconds) 17:29:07 crest, an editor like that for Mecrisp-Stellaris would be hard to resist 17:29:54 I wonder how much that editor weighs in though 17:31:18 I weighed it at the time and came up with 4.5 grams 17:32:00 i created a variable in mecrisp st 17:32:09 printed its address 17:32:15 attached gdb 17:32:22 it the editor would have been python based on the pc tho 17:32:22 changed it from 23 to 42 17:32:23 a good undo/redo takes a lot of space 17:32:39 and continued the core 17:32:44 to print the new variable content 17:32:46 crest, thats pretty cool 17:32:55 with gdb 17:33:03 but it stopped the core to do so 17:33:10 I've run Mecrisp-Stellaris under gdb 17:33:39 but didnt change anything on the fly from gdb 17:34:17 yeah, I think Ive always had to halt the target to change variables etc 17:34:51 I dont use gdb much, too complex, too hardware dependent 17:35:36 just use Forth 17:36:52 me too 17:37:49 but I have both systems set up and working so I can answer questions from the occasional embedded C user about the diferences 17:38:24 Ive tested most open development systems, I even have Eclipse and massive C dev systems here 17:38:55 some of the systems are so massive they make a blinky hard work 17:44:34 --- quit: Labu (Quit: Leaving.) 17:46:02 back 17:46:54 I've always just changed things on the fly via Forth 17:49:03 that's the Forth way, Total Interactive Control (tm) 17:49:43 :) 17:58:42 * watching a video on Eclipse out of curiosity 18:00:41 --- quit: _whitelogger (Read error: Connection reset by peer) 18:03:28 Eclipse is horrific 18:04:01 even though it's proprietary, my preferred Java IDE, provided someone else is paying for the license, is IntelliJ 18:04:19 (well, there's a free version of IntelliJ as well, which is still proprietary) 18:04:20 sounds like it, tons of folders and files for each project 18:04:38 * tabemann uses IntelliJ at work 18:05:03 Eclipse is a buggy crock of shit btw 18:06:15 my wife's company does a lot of Java. My only exposure to Java was reading the JVM spec years ago. 18:06:27 --- join: _whitelogger joined #forth 18:07:15 I was thinking of doing a Forth on JVM, but the spec madfe my stomach turn. 18:07:24 --- join: boru` joined #forth 18:07:27 --- quit: boru (Disconnected by services) 18:07:30 --- nick: boru` -> boru 18:12:29 tp: turns out even if you run continue & in arm-eabi-none-gdb connected to the stm32f103 you can't change things without interrupting the thread first 18:12:59 i'm not sure if this is a limitation of gdb, the st-util gdb server, st-link v2 or the debugging hardware itself 18:21:33 crest, it's not a problem that paying $50,000 for proprietary JTAG gear would't fix I expect :) 18:22:14 so far i haven't even looked into the opensource stlinkv2 library *headers* 18:22:25 not really at least 18:22:37 it could be as easy as open a context to the stlink 18:22:55 an read/write memory in bytes and words 18:24:09 there is a little bit of documention (short description of each function) in the doc folder of the git repo 18:24:41 but nothing about the pre and postconditions for each function 18:24:50 or even better a state diagram 18:24:56 of how the library is supposed to be used 18:25:04 crest, it's a job for a serious programmer like you, besides you thought of it :) 18:25:19 but the st-util gdb server should include it all 18:25:44 crest, Ive not heard it mentioned before, altho rdrop-exit is using JTAG for his tethered Forth project 18:25:51 my only question is how fast is the swd interface and stlink in the real world 18:26:31 crest, there is something called 'blackmagic' probe that is supposed to include it all even run on a bluepill 18:26:31 back 18:26:40 crest, 5mb/s 18:26:48 welcome back! tabemann 18:26:57 --- join: kori joined #forth 18:26:57 --- quit: kori (Changing host) 18:26:57 --- join: kori joined #forth 18:26:59 crest, swd is super fast 18:27:02 tp: is that the realworld bandwidth or just the baudrate? 18:27:16 using FTDI's MPSSE cable you can go USB to JTAG 18:27:46 you have to deal with their proprietary drivers/library though 18:27:52 crest, thats the bandwidth I think. I first discovered that it's fast when using it with flying leads ... 12" leads FAIL, 3" leads work 18:28:27 no need for gdb 18:28:49 --- quit: dave0 (Quit: dave's not here) 18:29:03 "Instead, a debug interface module is decoupled from the core, and a bus interface called the 18:29:03 Debug Access Port (DAP) is provided at the core level. Through this bus interface, external debuggers 18:29:03 can access control registers to debug hardware as well as system memory, even when the processor is 18:29:03 running." 18:29:13 crest have a look at 'blackmagic probe' and get the blue pill binary, it's bound to be interesting 18:29:20 from the defintive guide to the cortex m3 18:29:24 so it should be possible 18:29:25 PC Forth <-- USB<->JTAG --> Target Forth 18:30:12 or just PC Forth <-- USB<->JTAG --> bare Target 18:30:23 i wonder how complex the swd protocol truly is 18:30:27 --- quit: karswell (Read error: Connection reset by peer) 18:30:59 or at least the subset needed for 8 bit sram access 18:31:35 crest, there are OSS projects to use a RPI as a SWD programmer, or a blue pill 18:32:01 that could be useful to get a feel for the protocol 18:32:25 crest, matthias uses JTAG to talk to the MPS430 from a cortex-M4 so it's definitely dooable 18:32:43 crest, he does that on the M4 with Mecrisp-Stellaris 18:34:17 tp: I've officially made a release 0.5.0 18:34:30 so my crazy idea is should be possible 18:35:18 IF you want total interactive control of a target JTAG is the way to go 18:36:55 no need for gdb, or a terminal program 18:37:35 rdrop-exit, SWD is what we use for STM32, it's similar but doesnt have all the extra uneeded stuff that JTAG has 18:38:02 tabemann, cool, I'll get that and run it up soon 18:39:36 tp, if it's simpler and can give you the needed level of control, then cool 18:39:49 JTAG is definitely not simple 18:43:18 rdrop-exit, true, JTAG is designed to connect to everything JTAG enabled on a PCB, SWD is just designed to connect to to STM32 MCU's 18:43:36 but both are supported by programmers and GDB 18:43:43 I went with JTAG because RISC-V has a fairly complete spec for how their on-chip debug infrastructure works with JTAG 18:44:10 rdrop-exit, I think for you JTAG is the right choice 18:44:26 cool 18:44:27 jtag is how many signal wires again? 18:44:28 rdrop-exit, as JTAG is the universal fits all 18:45:14 rdrop-exit, if you ever use the MSP430 jtag will do that job also 18:45:19 this looks useful: https://www.cnblogs.com/shangdawei/p/4748751.html 18:45:59 Zarutian_HTC, jtag: Reduced pin count JTAG uses only two wires, a clock wire and a data wire. 18:46:09 Zarutian_HTC, same as SWD 18:46:21 regular JTAG uses 4 or 5 pins 18:46:41 although it recommends to stop the cpu to prevent it from executing partially modified code 18:47:06 but that wouldn't be a problem for a ring buffer of up to 256 bytes with 18:47:15 rdrop-exit, yeah, power, data,clock and /NRST 18:47:38 crest, I can see a lot of possible jam-ups 18:47:53 tp: ? 18:48:12 rdrop-exit, and of course STM32 uses JTAG and SWD 18:48:15 sure i can crash the whole system in 1001 intersting ways 18:48:34 crest, I think the potential is high 18:48:38 :) 18:48:40 tp, rdrop-exit: thanks 18:49:01 it i don't plan to upload raw machine code while the cpu is executing it 18:49:09 crest, the fast that SWD also has a NRST pin 18:49:56 having a way to reset the system without reaching from the keyboard to the puny reset button would be an other advantage 18:49:58 crest, rdrop-exit JTAG is also a lot slower than SWD when programming 18:50:38 tp, rdrop: know of any standardish pogopin pads constellation footprint for such on pcbs? 18:51:37 crest,tabemann, the designer of 'propellor Forth is working on a cortex-m Forth now and his REPL which uses a interrupt includes using the ESC key to reset the MCU 18:52:21 tp, yes but faster then having to interpret from source 18:52:45 Zarutian_HTC, I dont but there are standards for the JTAG board headers 18:53:01 rdrop-exit, definitely 18:54:00 tp: hmm probably the same layout as those headers 18:55:25 The only way to get total interactive control of a target nowadays is the target's debug infrastructure 18:56:41 rdrop-exit, I have two working tethered forths here, one uses the pc serial port, the other uses JTAG generated from a M4. Comparisons: serial tether ... slow and buggy, jtag tether .. flawless 18:57:17 it is just so nice to have an automatic test rig machine (an old p'n'p that was moddified to have pogopin header on its pick head) to test, program and test again 18:57:36 tp, cool 18:59:22 in manifacturing that is 19:00:09 The weak link in the chain in going from a PC to a target is the USB<->JTAG, no good non-proprietary solutions AFAICT 19:00:22 tabemann, do you have a reset word ? 19:00:58 rdrop-exit: how bad are the stlink v2 and its clones? 19:01:47 thats right, stlink v2 is a $4 usb --> jtag dongle 19:02:17 crest, but the stlink v2 doesnt do JTAG ? 19:02:27 crest, only SWD 19:03:03 rdrop-exit, what about the Olimex range of usb JTAG dongles ? 19:03:11 rdrop-exit, I have two of them here 19:03:25 tp: so fat swd is what i want to use for my console 19:03:48 crest, yeah, but rdrop-exit's system requires JTAG 19:03:54 The only low-level solution I found was the MPSSE cable from FTDI, but you have to deal with their Windows derived library, they don't provide a protocol spec 19:04:18 tp: i missed that 19:04:35 https://www.ftdichip.com/Products/Cables/USBMPSSE.htm 19:05:15 There's an OSS alternative library available, but it seems incomplete 19:05:54 "The USB-MPSSE cable is capable of providing a USB to SPI, I2C or JTAG interface. This is accomplished by the MPSSE within the FT232H device which has the ability to emulate synchronous serial protocols while handling all the USB signalling and protocols. 19:07:34 I haven't found a viable alternative, yet 19:07:47 rdrop-exit, these are what I use for general JTAG: https://www.olimex.com/Products/ARM/JTAG/ARM-USB-TINY/ 19:08:45 rdrop-exit, and anyway, you can build a USB or ethernet to JTAG interface with a few different boards or mcu's 19:09:45 my Tiva Connected Launchpad was $25 and has ethernet and usb. mathias turned it into a tethered host using JTAG to talk to the target using Mecrisp-Stellaris Forth 19:10:17 https://mecrisp-across-folkdoc.sourceforge.io/ 19:14:52 I've already done most of the code for interfacing through the MPSSE cable, but maybe at some point I'll rip it out and replace the cable with a board if I get frustrated 19:17:04 rdrop-exit, at least you have plenty of choices 19:17:25 It drives me nuts when a vendor provides a library instead of a protocol spec 19:19:01 the lib is only given as .so or .dll or is it C source code? 19:19:21 closed source, only object 19:20:07 I have gotten the latter and the protocol spec was in there as a massive multiline comment 19:20:10 there's a OSS alternative on github, but it seems incomplete, does not inspire confidence 19:21:08 "Libraries? We don't need no stinkin' Libraries!" 19:21:41 -- Treasure of the Madre 19:23:38 right, one programmer I know got such an object file. He promptly stuffed it throug ida pro and ghandra to get a dissambled version to reverse engineer the protocol 19:23:57 or should that be... 19:23:59 "APIs? We don't need no stinkin' APIs!" 19:25:46 Zarutian_HTC, it's sad one needs to go to such lengths 19:27:13 rdrop-exit: yeah but that case the manifacturer had long evaporated. This was part of an RE project of a older equipment 19:27:27 --- quit: rdrop-exit (Quit: Lost terminal) 19:28:25 --- join: rdrop-exit joined #forth 19:28:50 lost my connection 19:31:44 rdrop-exit: yeah but that case the manifacturer had long evaporated. This was part of an RE project of a older equipment 19:32:03 I see 19:35:10 what drives me nuts is implementers who use an API as an excuse not to fully document internals, pay no attention to the man behind the curtain 19:41:00 "Well there's a difference between, and I don't think this is understood very well by everybody, there's a difference between simplifying and making a higher level of abstraction, we say that's simplifying, but it's actually making things more complicated most of the time because there's more stuff underneath right, and that's what we have not acknowledged as a programming community" - Jonathan Blow 20:04:26 --- join: dave0 joined #forth 20:12:24 --- quit: _whitelogger (Remote host closed the connection) 20:15:27 --- join: _whitelogger joined #forth 20:49:04 --- quit: _whitelogger (Ping timeout: 260 seconds) 20:57:28 --- join: _whitelogger joined #forth 21:23:34 --- join: Blue_flame joined #forth 21:25:05 --- join: jsoft joined #forth 21:34:04 --- quit: rpcope (Ping timeout: 260 seconds) 21:35:16 --- join: rpcope joined #forth 22:23:47 --- quit: WickedShell (Remote host closed the connection) 22:32:57 --- quit: Blue_flame (Quit: Blue_flame) 22:40:13 --- join: gravicappa joined #forth 22:56:36 --- quit: Vedran (Quit: The Lounge - https://thelounge.github.io) 22:57:52 --- join: Vedran joined #forth 23:37:50 --- join: mtsd joined #forth 23:37:54 --- join: xek_ joined #forth 23:41:06 --- quit: xek (Ping timeout: 272 seconds) 23:44:08 --- quit: proteus-guy (Remote host closed the connection) 23:46:35 --- join: dys joined #forth 23:52:58 --- quit: mtsd (Quit: Leaving) 23:59:59 --- log: ended forth/20.05.13