00:00:00 --- log: started forth/20.03.14 00:03:25 --- join: patrickg joined #forth 00:25:07 --- quit: WickedShell (Remote host closed the connection) 01:12:25 --- quit: _whitelogger (Remote host closed the connection) 01:15:28 --- join: _whitelogger joined #forth 02:47:59 --- join: gravicappa joined #forth 04:01:48 --- quit: tp (Ping timeout: 240 seconds) 05:06:22 --- quit: mstevens (Quit: Connection closed for inactivity) 05:41:20 --- join: TwoNotes joined #forth 05:41:58 --- part: TwoNotes left #forth 05:49:28 --- quit: X-Scale (Ping timeout: 240 seconds) 05:49:43 --- join: X-Scale` joined #forth 05:50:16 --- nick: X-Scale` -> X-Scale 06:33:26 --- join: xek joined #forth 06:55:09 --- quit: iyzsong (Quit: ZNC 1.7.1 - https://znc.in) 07:17:16 --- join: reepca joined #forth 07:55:31 --- join: dddddd joined #forth 08:00:28 --- join: TwoNotes joined #forth 08:00:38 --- part: TwoNotes left #forth 08:43:53 --- quit: dave0 (Quit: dave's not here) 09:01:47 --- join: dys joined #forth 10:47:02 --- join: DKordic joined #forth 11:00:25 --- quit: jsoft (Ping timeout: 240 seconds) 11:27:57 --- quit: tabemann (Ping timeout: 260 seconds) 11:56:10 --- join: tabemann joined #forth 12:02:03 --- quit: tabemann (Ping timeout: 258 seconds) 12:43:54 --- join: TwoNotes joined #forth 13:22:14 --- quit: TwoNotes (Quit: Leaving) 14:18:08 --- quit: gravicappa (Ping timeout: 258 seconds) 15:56:14 --- join: tp joined #forth 15:58:56 --- quit: C_Keen (Changing host) 15:58:56 --- join: C_Keen joined #forth 15:58:57 --- nick: C_Keen -> C-Keen 16:37:08 --- join: tabemann joined #forth 16:43:25 --- quit: tabemann (Ping timeout: 260 seconds) 16:47:33 --- join: tabemann joined #forth 17:19:21 --- quit: xek (Ping timeout: 260 seconds) 17:34:54 --- quit: Lord_Nightmare (Quit: ZNC - http://znc.in) 17:37:19 --- join: Lord_Nightmare joined #forth 17:46:03 --- quit: dne (Remote host closed the connection) 17:52:20 --- join: actuallybatman joined #forth 17:57:37 --- join: dne joined #forth 18:14:28 --- quit: MrMobius (Read error: Connection reset by peer) 18:55:57 --- join: jsoft joined #forth 19:01:46 --- join: iyzsong joined #forth 19:10:49 --- quit: jsoft (Ping timeout: 256 seconds) 19:42:26 --- join: dave0 joined #forth 19:56:44 --- join: boru` joined #forth 19:56:47 --- quit: boru (Disconnected by services) 19:56:50 --- nick: boru` -> boru 19:57:46 --- join: MrMobius joined #forth 20:04:28 --- quit: dys (Ping timeout: 268 seconds) 20:33:27 tp: I just realized a problem with e4thcom 21:43:20 --- quit: dave0 (Quit: dave's not here) 22:01:22 --- join: gravicappa joined #forth 22:02:02 tabemann, ? 22:02:56 tabemann, the only problem I found with e4thcom is that it only ran on Linux 22:03:36 the issue I've found is it sends data too fast 22:03:53 it's fine when I'm handling input without a multitasker 22:04:10 but with the multitasker I've had to hack in special IO code so it can keep up 22:04:23 oh 22:04:36 i.e. code which buffers all input it can get on every PAUSE 22:04:54 it seems to work with a buffer of 16 characters 22:05:09 I dont understand, I didnt have that problem and I used it for several months 22:05:49 the problem is it was reading input too slowly 22:06:05 another solution would be to use an ISR to handle reading input 22:06:48 it seems to work okay now 22:07:02 at least with three tasks (main and two others) 22:08:02 I know e4thcom must read input slower then other serial terminals as it has to examine the data to remove comments etc 22:08:26 but are you saying it sends data faster than the configured baudrate ? 22:08:26 tp bursts data all at once 22:08:56 I think it sends data as fast as it can at a given baudrate 22:09:08 dont they all ? 22:09:11 but if the code on the MCU doesn't keep up, data is lost 22:09:29 you mean if the usart buffer is overrun ? 22:09:58 if the target mcu buffer is overun thats the only time i have problems 22:09:58 yes, because the software isn't reading data from the USART fast enough 22:10:42 have you tried e4thcom with Mecrisp-Stellaris ? 22:11:20 the strategy I've come up with is to read a full (software) buffer of data at once, and then allow a given task to read data from that buffer as fast as possible 22:11:29 I have 22:11:34 but not with a multitasker 22:11:47 in fact one reason I sent to Screen was that e4thcom has a max baudrate od 115200 baud, in my case e4thcom was too *slow* 22:12:26 likewise, I've only gotten issues when using a multitasker with zeptoforth 22:12:32 ah ok 22:12:46 my does a multitasker make any difference ? 22:12:53 my = why 22:13:13 I did my last prokect with a multitasker 22:13:16 because it makes the time between characters read longer for a naive implementation 22:13:46 so it increase the chances that the software won't keep up with the USART buffer 22:14:00 whereas without one 22:14:13 the refill routine can read as fast as it can 22:14:39 because it doesn't have to share time with any other tasks 22:16:01 ahh 22:16:24 wow, the things doing a new cortex-m Forth turns up! 22:18:07 one thing that annoys me is that code compiled to flash does take up a lotof space 22:18:28 I was reading a article about someone using Mecrisp-Stellaris with freertos where Forth is run in it's own task 22:18:46 more space than ram ? 22:19:14 like with the kernel, the basic compiled code, and the multitasker, it takes up $9800 space 22:19:20 mind you this is with cornerstones 22:19:45 under 10k not bad 22:21:15 with cornerstones removed it's $8CE0 22:21:18 that's in hex 22:21:41 I have stopped using the multitasker because I only really wanted a simple scheduler 22:22:05 it's 35K in size 22:22:20 which feels... large to me 22:22:32 I cant relate hex to binary 22:22:42 intelhex I mean 22:24:09 the kernel is 24K in size 22:24:45 so just he basic Forth words plus the multitasker is 11K in size 22:25:26 you can easily convert ihex to binary with gcc i think 22:25:50 oh! 22:25:52 I see 22:26:44 the kernel is 24k of binary ? 22:27:02 yes 22:27:41 the thing is the kernel does far, far more than twice of what the extras do 22:27:48 well it's for a cortex-m4 and they have tons of flash 22:28:15 I know, but it feels like the extras don't do that much in comparison 22:28:40 they're mostly basic routines missing from the kernel and a multitasker 22:28:44 a CircuitPython binary needs a minimum 256k 22:30:37 okay, just the basic extras take 4K when compiled to RAM 22:31:01 and less than that, because I didn't take into account the extra variables at the base of RAM 22:33:30 okay, the basic extras are also 4K when compiled to flash 22:34:03 as youd know the Mecrisp-Stellaris binary for all the variants is about 20.5kB for the RA version, so I guess thats the lower level for cortex-m forths ? 22:34:33 plus Mecrisp-Stellaris has a lot of inbuilt words 22:35:16 I must compile a kernel only version of Mecrisp-Stellaris and see what size it is 22:35:52 the zeptoforth kernel lacks a lot of things, and isn't register-assigning 22:36:01 the other thing is that all the Mecrisp-Stellaris Words are in assembler, and theyre hand optimised 22:36:34 note that it could be denser, e.g. it contains a partial assembler which is used in many places where just hard-coded instructions could be used 22:37:04 the Mecrisp-Stellaris assembler isnt 100% complete either 22:37:43 that's what the basic extras are for, for adding things like TRUE, FALSE, CREATE, , flash-definable RAM variables, and so on 22:38:27 flash-definable RAM variables! 22:38:31 one advantage of zeptoforth over mecrisp-stellaris AFAIK is that you can easily define RAM variables from flash, even though you have to reboot before you can use them 22:39:08 thats true, Mecrisp-Stellaris cant create ram variables from flash 22:39:21 but Mecrisp-Stellaris does create buffers from flash 22:39:32 which is what everyone uses 22:39:34 oops 22:39:37 you can also create buffers from flash too 22:39:45 Mecrisp-Stellaris does create variables from flash 22:39:48 doh! 22:40:11 theyre just specified in the source thats uploaded to flash 22:40:24 ie "0 variable FOO" 22:40:38 and Mecrisp-Stellaris does something to make that work 22:41:38 but I guess the correct description is that "when running from flash, new variables cant be created" ? 22:41:47 how I do them is as follows: for each ram varialbe defined from flash, I create a word named *RAM* containing the offset for the next ram variable 22:42:22 and then at boot time it looks up the last defined instance of *RAM* to fetch the offset of HERE 22:45:24 hmm, you made me realise that variables created live only run in ram 22:47:01 and that those same variables are only created created when 'compiled' to flash after a reboot and a 'compile to flash' for everything 22:52:10 rebooting is necessary because space needs to be allocated for them before any other space is allocated 22:53:00 that makes sense 22:53:37 --- quit: dddddd (Ping timeout: 240 seconds) 23:08:38 well, multitasking seems to now work properly, with it taking up less memory footprint now that I have optimized the size of the fields used for the multitasking control data 23:08:59 except I haven't yet tested task exiting, which was broken last time I checked 23:09:21 you save all the registers I guess ? 23:09:26 and restore them ? 23:09:33 or the main ones anyway 23:14:19 no 23:14:54 the only registers I save are r6, r7, and sp 23:21:24 --- quit: _whitelogger (Remote host closed the connection) 23:23:56 okay, fixed task exiting 23:24:28 --- join: _whitelogger joined #forth 23:25:46 cool 23:26:42 it was the stupidest of bugs - I had made a mistake in the implementation of ?dup of all things 23:38:15 --- quit: iyzsong (Ping timeout: 272 seconds) 23:39:07 okay, I should get to bed 23:39:10 g'night 23:58:41 --- quit: gravicappa (Ping timeout: 256 seconds) 23:59:59 --- log: ended forth/20.03.14