00:00:00 --- log: started forth/20.05.26 00:06:06 --- join: [1]MrMobius joined #forth 00:06:46 --- quit: MrMobius (Ping timeout: 256 seconds) 00:06:46 --- nick: [1]MrMobius -> MrMobius 00:13:44 --- quit: TCZ (Quit: Leaving) 00:37:01 --- join: gravicappa joined #forth 00:37:48 --- join: proteus-guy joined #forth 01:16:41 --- join: xek joined #forth 02:42:44 --- quit: proteus-guy (Ping timeout: 272 seconds) 03:20:47 --- quit: reepca (Remote host closed the connection) 03:20:59 --- join: reepca joined #forth 03:23:32 tp: i spent last night on the second prototype 03:23:54 the first one just used four bytes in a single cell 03:24:05 that worked but was very inefficient 03:24:26 because the host and stm32 are always waiting for each other 03:25:00 and the host just polled the whole 32bit word again and again until something changed 03:26:16 if it wanted to change something it wrote (ack a byte, send a byte and mark the buffer used) it used one or two 8 bit writes 03:26:47 it tranfered very little data per command 03:27:02 interesting! 03:27:26 and every single byte transmission that direction was blocked until the receiver polled 03:28:06 now i used a large 256 (- 1) byte ring buffers per direction 03:28:21 so you won the battle of the buffers ? 03:28:41 all four indicies (read and write per direction) still fit in a single 32bit word 03:29:36 the host still polls a single word for changes 03:29:41 wow, serious design skills you have there 03:30:08 --- quit: antaoiseach (Quit: leaving) 03:30:12 but this time host drains the whole buffer with one or two commands 03:30:27 so 4x faster ? 03:30:30 for the data and on 8 bit write to move the data 03:30:37 much more 03:30:43 very nice 03:31:21 because the stlink does a block copy of 32bit words 03:31:53 --- quit: reepca (Remote host closed the connection) 03:32:03 --- join: reepca joined #forth 03:32:08 the host only has pad the read sizes to natural alignment and ignore the padding 03:32:40 i wanted to avoid using aligned loads because they result in twice as many sram accesses 03:32:53 stolen by the debug hardware 03:33:25 now i have to find time to implement the host -> stm32 direction 03:33:37 and add things to make it useful like file upload 03:33:54 and the ability to reset the stm32 via swd 03:35:16 is your new technique responsible for the under one second wordlisting ? 03:36:05 reset the stm32 via swd, hmm thats handy if it can reset under any conditions 03:37:30 it should be able to reset under all conditions except if you disabled swd at runtime 03:38:56 yes adding a ring buffer to decouple the producer and consumer helped a lot 03:38:58 I'm going to fit a touch pad on the development box for resetting the MCU as I do it a million times a day anyway 03:39:19 unlike a PB switch I cant wear a touchpad out 03:39:41 the device is always right next to me anyway, so resetting it is second nature now 03:39:41 but doing the data transfers in large batched made a real difference 03:40:47 crest, seems like youyre making real headway there 03:41:21 tis will be the first 'new' mecrisp-stellaris thing Ive seen in a while 03:41:57 we received a donated python 'ok-wait' program the other day 03:42:24 $ picocom -b 115200 /dev/ttyACM0 --imap lfcrlf,crcrlf --omap delbs,crlf --send-cmd "./xfr.py" 03:42:24 1 03:42:24 2 03:42:24 3 03:42:24 4 03:42:25 5 03:42:27 6 03:42:29 7 03:42:31 8 03:42:33 03:42:35 #!/usr/bin/env python3 03:42:37 import sys 03:42:39 for l in open(sys.argv[1], "rt"): 03:42:41 sys.stdout.write(l) 03:42:43 r = sys.stdin.readline() 03:42:45 sys.stderr.write(r) 03:42:47 if not r.endswith("ok.\n"): 03:42:49 sys.exit(1) 03:42:51 oops 03:42:55 didnt translate well to irc 03:43:12 The script waits for an "ok." before sending consecutive lines so the transmission is somewhat faster than when using a fixed delay per line. 03:43:35 yes but suffers from data transparency problems 03:44:16 what if my code includes as literal "ok.\n" at the end of a line? 03:44:26 you mean when the 'ok' prompt is not consistent so it gets locked up ? 03:44:43 then you have a problem I suppose ? 03:45:01 exactly 03:45:08 this is of course why I use RTS handshaking 03:45:29 all software handshaking can run into problems 03:45:33 unless your usb<->serial adapter is buggy 03:46:01 my $0.90 usb-serial dongles have been fine 03:46:08 I bought 20 at a time 03:46:14 e.g. a ftdi232 has an errta notice that some versions of the chip send up to 3 bytes after hardware flow control stopped them 03:46:29 mine have different chips 03:46:39 theyre not fttdi 03:47:02 but I have the ftdi ones in cables and they seemed ok when I used them 03:48:01 i use Silicon Labs CP2102 03:48:20 devices as they have all the control lines available 04:05:16 but your SWD technique sounds very exciting 04:05:27 be interesting to see where it leads 04:06:30 --- quit: dave0 (Quit: dave's not here) 04:22:02 --- join: xek_ joined #forth 04:22:56 --- quit: xek (Read error: Connection reset by peer) 04:26:24 --- join: dddddd joined #forth 04:55:19 --- join: proteus-guy joined #forth 05:02:18 --- join: va_ joined #forth 05:03:55 --- quit: va (Ping timeout: 256 seconds) 05:18:48 --- join: X-Scale` joined #forth 05:19:10 --- quit: X-Scale (Ping timeout: 272 seconds) 05:19:49 --- nick: X-Scale` -> X-Scale 05:58:53 --- quit: Zarutian_HTC (Ping timeout: 260 seconds) 06:08:26 --- join: Zarutian_HTC joined #forth 06:19:29 --- quit: reepca (Remote host closed the connection) 06:19:41 --- join: reepca joined #forth 06:19:51 --- quit: Zarutian_HTC (Ping timeout: 256 seconds) 06:24:27 --- quit: APic (Ping timeout: 240 seconds) 06:28:41 --- join: APic joined #forth 06:29:59 --- quit: mtsd (Quit: Leaving) 06:32:53 --- quit: proteus-guy (Ping timeout: 246 seconds) 06:36:32 --- quit: APic (Ping timeout: 260 seconds) 06:38:05 --- quit: reepca (Remote host closed the connection) 06:38:17 --- join: reepca joined #forth 06:49:06 --- join: APic joined #forth 06:58:38 --- quit: reepca (Read error: Connection reset by peer) 07:03:10 --- join: proteus-guy joined #forth 07:20:56 --- quit: jsoft (Ping timeout: 265 seconds) 07:27:57 --- join: Zarutian_WEB joined #forth 07:33:07 --- join: antaoiseach joined #forth 07:35:41 --- join: xek__ joined #forth 07:38:03 --- quit: xek_ (Ping timeout: 256 seconds) 07:38:21 --- part: antaoiseach left #forth 08:05:12 --- quit: jackdaniel (Remote host closed the connection) 08:08:09 --- join: jackdaniel joined #forth 08:13:24 --- quit: jackdaniel (Remote host closed the connection) 09:07:17 --- quit: dys (Ping timeout: 244 seconds) 09:33:45 --- join: jackdaniel joined #forth 09:50:56 --- quit: arrdem (Ping timeout: 265 seconds) 09:55:16 --- quit: guan (Read error: Connection reset by peer) 09:56:44 --- join: arrdem joined #forth 09:58:16 --- join: guan joined #forth 10:03:11 --- quit: arrdem (Ping timeout: 258 seconds) 10:08:43 --- join: arrdem joined #forth 10:13:44 --- quit: arrdem (Ping timeout: 256 seconds) 10:13:47 --- quit: guan (Ping timeout: 264 seconds) 10:20:04 --- join: arrdem joined #forth 10:22:13 --- join: guan joined #forth 10:38:10 --- join: WickedShell joined #forth 10:49:04 --- join: karswell joined #forth 11:22:58 --- quit: Zarutian_WEB (Quit: Zarutian_WEB) 12:06:52 --- join: reepca joined #forth 12:08:38 --- join: Zarutian_HTC joined #forth 12:39:43 Hello. Does anyone know gforth? Is there a way to modify the ctrl-z behavior? I'd like to reuse it for my app... 12:59:44 andrei-n: what does ctrl+z do on your platform? 13:12:16 crest, it exits to linux shell. 13:12:32 And the process goes to background. 13:15:46 This is how it's done in C: https://www.geeksforgeeks.org/c-program-not-suspend-ctrlz-pressed/ 13:16:13 you can't catch the stop signal, but you can put the tty in raw mode 13:16:54 but you can register a handler for SIGTSTP 13:17:06 So that will require calling C code from Forth... 13:51:17 andrei-n, signal() and sigaction() are linux system calls 13:51:18 --- join: TCZ joined #forth 13:59:42 --- quit: xek__ (Ping timeout: 258 seconds) 14:39:40 --- quit: gravicappa (Ping timeout: 272 seconds) 14:51:34 --- join: dave0 joined #forth 14:56:29 yes... 14:57:11 Is it possible to do the same without C calls? 15:08:28 --- quit: andrei-n (Quit: Leaving) 15:31:01 --- join: boru` joined #forth 15:31:01 --- quit: boru (Disconnected by services) 15:31:02 --- nick: boru` -> boru 15:33:30 --- quit: C-Keen (Ping timeout: 272 seconds) 15:34:32 --- join: C-Keen joined #forth 15:34:56 --- nick: C-Keen -> Guest46854 15:37:19 --- join: L1 joined #forth 15:37:34 --- quit: CORDIC (Remote host closed the connection) 15:37:59 --- nick: TCZ -> DoomSlayer2020 15:39:29 --- quit: jn__ (Ping timeout: 272 seconds) 15:42:04 Chuck just said registers are better than stacks! 15:42:10 (watching Forth Day 2019) 15:42:55 it really is the end of times 15:43:29 oh nevermind 15:43:43 hes just talking about certain pointers 15:48:10 --- quit: Guest46854 (Changing host) 15:48:11 --- join: Guest46854 joined #forth 15:48:13 --- nick: Guest46854 -> C-Keen 15:50:52 --- join: jn__ joined #forth 16:01:05 --- quit: DoomSlayer2020 (Quit: Leaving) 16:42:50 --- join: TCZ joined #forth 16:47:50 --- nick: TCZ -> DoomSlayer2020 17:07:53 --- quit: DoomSlayer2020 (Quit: Leaving) 18:15:46 --- join: boru` joined #forth 18:15:55 --- quit: boru (Disconnected by services) 18:18:49 --- quit: reepca (Read error: Connection reset by peer) 18:19:02 --- join: reepca joined #forth 18:57:04 --- join: gravicappa joined #forth 19:28:05 --- quit: proteus-guy (Ping timeout: 260 seconds) 19:43:03 hey guys 19:50:00 hey tabemann 19:51:58 I wonder what would be a better use of $100... the higher end nRF board... or the numworks calculator (which I know has a mecrisp-stellaris impl. for but which I'd like to see if I could make a zeptoforth impl. for) 19:52:12 here are a 200mhz Forth compiling stats : 706 lines and 7,234 bytes compiled, with 0 errors in 2,323ms ok 19:52:39 tabemann, hard question :) 19:53:17 and my setup on a 72Mhz M0: 11 seconds to upload and compile 42,606 bytes of source with no comments 19:53:40 hmm, theyre about the same ? 19:54:14 the first Forth uses interrupts and buffers and Im using default Mecrisp-Stellaris 19:54:15 and an advantage that zeptoforth has over mecrisp-stellaris is that zeptoforth has sleeping right out of the box, whereas you need to connect the numworks calculator to a power supply or reimage it at he end of the day or else it'll drain its battery 19:54:59 tabemann, yes, but your sleeping isnt the lowest power option is it ? 19:55:10 that is true 19:55:36 low power is only a 'on/off' choice on the MSP430, for everything else it's very complex 19:55:40 and I have it being frequently woken up by the systick, so I'd need to turn systick off 19:56:03 but systick is only really essential if I want to do something timing-related 19:56:20 yeah, basically one can't slap 'low power' on afterwards, it has to be designed in from the very start 19:56:51 I've been a dismal failure with cortex-m0 and low, low power 19:56:56 (so far) 20:05:36 ugh numworks isn't actually free software, as it is non-commercial... but of course I'd be replacing the numworks image with my own, so that wouldn't matter 20:09:41 yeah, but the numworks design is open 20:10:54 tabemann, a programmer is going to be attracted to the numworks, a embedded person to the higher end nRF board 20:15:53 I'm obviously not an embedded person as all I do with my boards is hook up serial and usb and blink leds 20:16:16 and play around with software 20:22:54 maybe the numworks is a better choice for you then ? 20:23:10 it's a excellent bit of hardware also 20:23:49 it has a ton of flash 20:24:20 64K internal, which is small, but 8M external, which is humungous 20:37:33 the calculator has been ordered 20:39:30 the only thing is that I'd like to figure out how to control the screen, rather than just serial 20:41:03 so ideally the user could enter forth code with the keyboard 20:42:17 --- quit: reepca (Read error: Connection reset by peer) 20:42:39 --- join: reepca joined #forth 20:44:57 the keyboard is just a scanned martrix, I'm sure you could make it do anything 20:45:53 well yes 20:46:19 at least the source code for epsilon is available, if not completely free 20:47:34 does it matter as Mecrisp-Stellaris is available for it under the gpl ? 20:49:06 oh wait a minute, now I've found driver code for it 20:49:35 so I'm not going to have to reverse engineer epsilon 20:49:53 that is good, because I was worried about the license used by numworks infecting my code 20:50:14 I'm okay with the GPL3 infecting my code, OTOH ha ha 20:55:00 very nice calculator, excellent purchase! 20:58:27 now I'm gonna shameless steal the driver code from mecrisp-stellaris so I can make zeptoforth run on the board :D 20:59:48 about this: 20:59:49 Flashing of Mecrisp-Stellaris to the numworks calculator: 20:59:49 dfu-util -i 0 -a 0 -s 0x08000000 -D mecrisp-stellaris-numworks-with-sources.bin 20:59:50 No need to disassemble your calculator, terminal is on USART6: PA11 = D- = TX. PA12 = D+ = RX. 20:59:50 Just cut an old USB cable and connect it to a USB-serial-brige with 115200 Baud 8N1. 20:59:50 You need to type "eraseflash" once to clear the free dictionary space after you flash the Forth binary, 20:59:51 as dfu-util leaves old contents in flash blocks which are not used. 21:00:18 how are we to know which wires in the cut USB cable to connect? 21:05:33 youll need a usb cable wiring diagram I guess 21:05:52 plus usb wires are very thin 21:06:02 I think there are only 3 wires 21:06:26 +v, d+, d- and 0v is the shield or may be a wire 21:07:39 but this is confusing 21:08:37 the calculator has a usb port with a virtual modem as the terminal ? 21:09:07 if it did it'd be far more helpful than chopping up USB cables 21:11:43 i hate usb cables, very fragile 21:12:15 and to get super high speeds they must have very low internal capacitance, which means very thin wires 21:18:28 from an example I saw what they did was connect a USB-A connector to connections on a breadboard, then connected each of these to serial RX and TX 21:19:15 so no actual cutting took place 21:22:58 1689 bytes/sec uploaded and compiled with tachyon Forth at 200Mhz ... thats a bit slower than my system at 3873 byte/sec 21:26:39 tabemann, I've no idea what that numworks connection text means 21:33:45 I think I've figured it out 21:34:08 and I've put together everything I've gotta do to make it work 21:34:48 tabemann, ok the numworks has a USB Micro-B connector on the case 21:35:26 it's simply taking a Micro B to A cable and plugging it into a breakout board, then plugging the breakout board into a breadboard, then plugging male to female dupont cables into the breadboard and hooking them up to a serial-to-USB dongle 21:35:27 thats connected to the MCU serial port 21:36:08 what theyre doing is using the USB Micro-B connector on the case as a 3.3 SERIAL connector 21:37:07 and why theyre cutting the cable, tho Id use a usb socket myself and solder the wired to that, then just use a full usb cable instead of cutting it 21:37:56 the calculator is only usb when it's running firmware that uses the MCU usb peripheral, which Mecrisp-Stellaris doesnt 21:39:19 yes 21:40:45 I'm using a USB socket and a breadboard, because I can't see how I'd get cutting the cable and then reconnecting the wires right, and I can't solder 21:41:27 good idea 21:42:04 besides, the usb wires are so thin they can easily break when used outside the cable 21:42:14 exactly 21:43:04 very handy having usb and serial connections on the same pins on the stm32 21:43:14 sensible design strategy 21:43:35 brilliant design indeed 21:45:50 I should get to bed though 21:46:04 have done enough shopping for today 21:46:39 shopping! 21:46:46 buybuybuy 21:46:51 night tabemann 21:48:04 well today I bought a calculator, another usb-serial-converter (so I don't have to disconnect my current one from my F407 board, as reconnecting the two is a royal pain in the ass), usb a to micro b cable, a usb a breakout board, a breadboard, and a fuckload of male to female dupont cables 21:48:50 I don't know why you can't buy dupont cables in small numbers 21:49:12 as I only need two of them 21:49:18 they dont last long 21:49:31 better to buy in bulk as theyre crap 21:49:41 might as well then 21:49:47 it's not like theyre expensive 21:49:58 they're really cheap 21:50:06 so true 21:50:10 + nasty 21:50:17 anyways, time to hit the sack - g'night 21:50:22 theyre the worst of the worst 21:50:28 cya 22:20:14 --- join: jsoft joined #forth 22:43:28 --- quit: dddddd (Ping timeout: 260 seconds) 23:01:45 --- quit: WickedShell (Remote host closed the connection) 23:14:34 --- join: andrei-n joined #forth 23:53:31 --- join: antaoiseach joined #forth 23:54:40 --- join: mtsd joined #forth 23:59:59 --- log: ended forth/20.05.26