**** BEGIN LOGGING AT Fri Jul 18 03:00:00 2014 Jul 18 05:50:10 vvu : are you familiar with ART? Jul 18 07:09:22 karki: nop, but ask Jul 18 07:41:52 morning (ugt) Jul 18 08:04:19 karki_: how's JIT coming along? Jul 18 12:37:58 * vvu thinks devices run based on smoke...when smoke comes out of em they do not work anymore Jul 18 12:49:33 of course Jul 18 12:49:38 thats old wisdom Jul 18 12:49:47 its called magic smoke Jul 18 12:50:46 now i'm working with a source meter controlled via PC, maybe i can get some magic smoke out of an msp430 chip Jul 18 13:23:08 alexanderhiam, panto, jkridner : I'm working on the return values to userspace. For every single inst, there will be a return value. for instructions such as "GET" which are parts of scripts, I won't be generating a return value (issue gets *complicated* if I do) Jul 18 13:31:35 KumarAbhishek : how did you handle concurrency while moving data into userspace? Jul 18 13:39:48 karki: I believe the idea is you get a return value every time you send an instruction, so with scripts you get the return values as you send each line of it, before it's running. So something like a 0 for if the instruction is ok and a non-zero error code if not Jul 18 13:40:21 ah! Jul 18 13:40:33 so in this case the return values when sending script instructions would be sent by the python code buffering the script Jul 18 13:41:12 and maybe you could return an array of return values if multiple instructions are sent as one string Jul 18 13:41:17 +1 Jul 18 13:41:23 you have made me happy Jul 18 13:41:30 :) Jul 18 13:41:37 I was over thinking it Jul 18 13:41:43 yeah, otherwise that would get crazy Jul 18 13:43:23 alexanderhiam : This is simpler than having multiple kernel buffers, concurrency control, overflow detection, two threads handling two parallel TCP ports (send and receive) :p Jul 18 13:43:56 of course you still need to return values from the pru to userspace for single instruction Jul 18 13:44:06 thats not a problem Jul 18 13:44:13 I have that covered Jul 18 13:44:18 :) Jul 18 13:44:42 alexanderhiam : you know about the COM[] inst, right? Jul 18 13:44:54 no Jul 18 13:45:12 oh, it's like a serial.write Jul 18 13:45:58 ah, using the UARTs or bitbanging so you can use any pins? Jul 18 13:46:38 yes, thats what it is. but I thought having it would be good way to stream ADC/DI values back to userspace too Jul 18 13:46:47 like "/dev/pruspeak_data" Jul 18 13:48:03 I think the main way to get data back and forth should be through variables, since that's the standard way in botspeak Jul 18 13:48:14 Given that I can't "GET ADC[1]" in a script, I can rather "SET COM[0], ADC[1]". and user can read "/dev/pruspeak_data" Jul 18 13:48:26 or maybe instead of COM, something else? Jul 18 13:48:37 COM can be used for UART Jul 18 13:49:29 alexanderhiam : I'll talk to chris about creating a new command for this purpose if we want to reserve COM for UARTs Jul 18 13:49:46 ^ Jul 18 13:50:44 the botspeak way would be to do 'SET adv_val, ADC[1]', then do 'GET my_val' as a single instruction Jul 18 13:51:47 yeah, but we get the variable values by the return value of GET. This won't work in a script. Jul 18 13:51:52 so the server will need to be smart about how long it stores variable names Jul 18 13:52:06 what if you want to fetch values in a loop? Jul 18 13:52:36 yeah, and that set instruction should store the current value in my_val Jul 18 13:53:15 behind the scenes it samples AIN1, gets the value, then stores that in my_var Jul 18 13:54:38 same with DIO as a 'source' value, e.g. 'SET DIO[0], DIO[1]' should cause DIO0 to mirror DIO1 Jul 18 14:01:50 karki: an example: https://gist.github.com/alexanderhiam/5055d27d7508e6d80440 Jul 18 14:02:58 alexanderhiam : ah, so the GET is a individual command? Jul 18 14:03:40 and we keep executing it whenever we want to get the AIN value Jul 18 14:07:50 right Jul 18 14:08:25 :) Jul 18 14:08:25 that's how chris does it Jul 18 14:08:39 which brings up another issue... Jul 18 14:08:45 :( Jul 18 14:08:59 which is..... Jul 18 14:09:22 you certainly want to destroy variables created in scripts when said script exits, and you want variables to persist if created by single commands Jul 18 14:09:40 which means you might want a command to delete a variable Jul 18 14:09:43 like DEL Jul 18 14:10:45 because you could potentially fill up the variable space if you're doing a bunch of different tasks over time using the same interpreter instance Jul 18 14:14:51 which also brings up the issue of fragmentation Jul 18 14:15:24 but luckily the variable names are all handled by the pyton server, so it'll be pretty straight forward to take care of all that Jul 18 14:19:15 yes, I have thought about that :p Jul 18 14:21:10 alexanderhiam : If I wanted to run the pru for some other purpose and the old variables made no sense anymore, I thought I'll have a inst like RESET which will put the interpreter in its initial state. (I was thinking of DEL, but thought thats better done after GSoC) Jul 18 14:22:35 ok, you still may want to handle fragmentation though Jul 18 14:26:29 do you see how you can do that entirely in the server? Jul 18 14:45:21 praveendath92: ping Jul 18 14:45:45 pong Jul 18 14:45:54 how is it going ? Jul 18 14:46:38 Setting up gdb. Jul 18 14:46:50 uu Jul 18 14:47:01 never tried debug a kernel with gdb Jul 18 14:47:07 maybe i should do it sometimes Jul 18 14:47:14 Then? Jul 18 14:47:18 keep me posted, i'm really curious Jul 18 14:47:35 What would you recommend? Jul 18 14:47:40 For debugging? Jul 18 14:47:41 gdb :) Jul 18 14:47:46 i said that I never tried Jul 18 14:47:50 not that you should not try it Jul 18 14:48:22 Oh. I read as 'never "try"' Jul 18 14:48:24 ;) Jul 18 14:48:38 :p Jul 18 14:48:47 anyway need to go Jul 18 14:48:50 have fun :) Jul 18 14:49:16 I will be around. Jul 18 14:59:12 gdb on the kernel?! sounds like a great time! Jul 18 14:59:53 alexanderhiam: What do you think? Not good? Jul 18 15:00:16 oh no, not being sarcastic, it sounds really fun :P Jul 18 15:00:33 Okiee. Jul 18 15:00:45 I'm getting, remote hung-up error on git push :( Jul 18 15:01:05 uh-oh, corrupt git object? Jul 18 15:01:30 I used git commits only. Jul 18 15:01:47 No manual mods on git files. Jul 18 15:01:53 what's the whole error message? Jul 18 15:02:13 The repo is big. 34MB after compression. Jul 18 15:02:27 where's your local copy? not in a dropbox folder by any chance is it? Jul 18 15:02:44 error: RPC failed; result=55, HTTP code = 200 Jul 18 15:02:45 fatal: The remote end hung up unexpectedly Jul 18 15:03:02 No. Not in dropbox. Jul 18 15:03:07 oh, maybe just a network problem then Jul 18 15:03:39 Hmm. Every time this happens with this repo :/ Jul 18 15:03:48 It works later. Jul 18 15:03:54 GIT_CURL_VERBOSE=1 git push Jul 18 15:04:05 Hopefully this time too. Jul 18 15:04:18 are you using https? Jul 18 15:04:26 Yes. Jul 18 15:04:33 might work better with ssh Jul 18 15:05:17 I will try ssh then. Jul 18 16:45:42 praveendath921: there's KDB for the kernel like GDB for userspace apps Jul 18 16:46:21 KumarAbhishek: Thanks :) I will check it. Jul 18 16:46:21 karki: Concurrency, as in? Jul 18 16:47:39 how do you make sure you don't read more than what you have written? (though in your case your driver may take care of it since there is no direct userspace - pru interaction) Jul 18 16:48:04 karki: there's wait queues and IRQs Jul 18 16:48:24 exactly, kernel takes care of it :) Jul 18 16:48:35 I had some other problem Jul 18 16:48:40 the read blocks on the queue, and is woken up by the IRQs Jul 18 16:48:51 for non-blocking, poll() handles it Jul 18 16:49:05 * karki has to take some time off and read Abhiaheks kernel driver Jul 18 16:49:11 praveendath921: what's the issue currently? Jul 18 16:49:37 how does KDB work? Jul 18 16:49:48 I'm getting a kernel paging error. Want to check fro m which part of the code. Jul 18 16:50:02 is there a stack trace? Jul 18 16:50:03 I just have to enable KDB support right? KumarAbhishek Jul 18 16:50:15 I've not yet tried it Jul 18 16:50:25 Let me check. I should have one on gist. Jul 18 16:55:27 praveendath921: hack the kernel! Jul 18 18:37:00 panto, alexanderhiam , jkridner: return values are working :) Jul 18 18:37:18 It does have a bug though, but I'll fix it later as it's not specific to this feature and is quite simple to fix! Jul 18 18:37:25 karki: i admire your pinging system :) Jul 18 18:37:51 vvu : system :p ? Jul 18 18:39:01 technique Jul 18 18:42:29 vvu : whats special? Jul 18 19:03:48 karki: do you downcalls for the return values? Jul 18 19:03:56 *do downcalls Jul 18 19:04:09 no, shared memory Jul 18 19:05:09 have you measured the time it takes to get a return value (as in, time from setting a value in the shared memory and then waiting to read a value back)? Jul 18 19:05:45 nope Jul 18 19:06:21 why? Jul 18 19:07:16 just curious, as in, IIRC you describing that the script execution rate is quite slow Jul 18 19:07:30 (the blinking LED part) Jul 18 19:08:16 I believe some overhead is also due to your sysfs interface, though I cannot really make a comment on that Jul 18 19:08:46 *the sysfs interface Jul 18 19:08:51 yeah, it was a bit too slow....... Jul 18 19:10:19 though reading a value from a sysfs entry seems like a good idea. Jul 18 19:11:15 i don't even remember the reasons why i went for shared memory :p Jul 18 19:11:52 shared memory should be the fastest method I guess, if cache coherency is maintained Jul 18 19:13:36 because there isn't the overhead of context switching, which is certain for any system call Jul 18 19:14:31 but it doesn't really matter so much in this case :p Jul 18 19:14:46 why? Jul 18 19:15:10 cause its one return value at a time, no streaming or bulk copy Jul 18 19:16:01 I also have the overhead of maintaining concurrency issues in the userspace Jul 18 19:16:14 so its the same sort of Jul 18 19:16:20 as in multiple mmaps to the shared memory? Jul 18 19:16:31 no Jul 18 19:17:04 I should make sure that I don't read more than what the PRU writes. and this is in userspace Jul 18 19:18:01 "read more than what the PRU writes" : you know how many byte the PRU is going to write? Jul 18 19:18:05 *bytes Jul 18 19:20:15 just always write a fixed number of bytes >= the largest possible return value and pack smaller values with zeros Jul 18 19:21:56 alexanderhiam : I used a different method, which gives more flexibility but is slightly complex :) Jul 18 19:22:02 which would probably be 4 bytes, == 1 pruspeak integer Jul 18 19:22:13 what would you return besides an integer? Jul 18 19:22:17 like SYSTEM and stuff have varying size return values Jul 18 19:22:24 oh right Jul 18 19:22:30 I return just integers Jul 18 19:22:46 but how many is the question :p Jul 18 19:25:28 alexanderhiam : I might have complicated stuff a little bit, remember the assumption I had in the morning about scripts returning values and stuff? so I made the shm into a circular buffer :p Jul 18 19:25:44 I'll change it to linear buffer now :p Jul 18 19:26:03 just have to remove a few lines for this........ Jul 18 19:26:12 shm? Jul 18 19:28:26 shared memory Jul 18 19:28:31 ah Jul 18 19:28:35 :p Jul 18 19:29:02 btw, do you think having a sysfs interface to read the return value will make more sense? Jul 18 19:29:36 as opposed to what? are you mmaping to get it? Jul 18 19:30:13 yeah, there is a shared memory b/w PRU and my python bindings where the ret vals are dumped Jul 18 19:30:29 ideally you would get it by reading from the same file you write instructions to Jul 18 19:31:11 if you're mmaping then you could potentially read partially written responses Jul 18 19:31:49 nope, there is a valid flag that has to be set before the ARM can read the ret values Jul 18 19:31:52 and it's less language agnostic that way, e.g. you can't really get return values if you're sending commands straight from bash Jul 18 19:32:08 +1 Jul 18 19:32:16 I'll change it to sysfs Jul 18 19:32:42 I'd like to be able to do '# echo "SET DIO[0], 1" > PRUSPEAK_FILE && cat PRUSPEAK_FILE Jul 18 19:33:02 can you block a sysfs read? Jul 18 19:33:18 i.e. have a read blocked until a value is ready? Jul 18 19:33:33 haven't done it before, but yeah it is possible Jul 18 19:34:20 I think that would be the ideal interface in terms of developer friendliness Jul 18 19:34:43 but PRUSPEAK_FILE is going to be a FIFO anyway, so you can "cat" it anyway Jul 18 19:34:45 oh, except it would have to be tokenized first Jul 18 19:34:57 yeah fifo does the tokenising Jul 18 19:35:04 oh right Jul 18 19:35:23 forgot that's how you're doing it Jul 18 19:36:16 so having sysfs is also a pain, I have to add an "upcall without downcall" support, and block on read. Jul 18 19:36:31 just that its a cleaner interface :) Jul 18 19:36:39 will move to it eventually. Jul 18 19:37:50 well this is all driver level anyway right? if it's working now I'd say focus on the interpreter Jul 18 19:37:56 alexanderhiam : I don't want to spend too much time on something that already works fine! anyway sysfs or shm, it does not matter to the external API, all that is internal Jul 18 19:38:05 yeah driver level! Jul 18 19:38:27 I guess we're in agreement then :P Jul 18 19:38:32 :) Jul 18 19:39:24 I have to go to sleep :p [but should first fix my implementation........] Jul 18 19:39:54 * karki is tired having only 4-5 hrs of sleep every night! Jul 18 19:40:42 karki: did you reference an example for the timer based delay? Jul 18 19:40:56 no, why? Jul 18 19:41:46 I'm working on a pru blink tutorial and was thinking it would be nice to teach people something better then a noop loop delay Jul 18 19:41:58 meh Jul 18 19:42:03 I used the almighty datasheets :D Jul 18 19:42:48 alexanderhiam : I have well commented code for the timer! Jul 18 19:43:24 plus if you go thru the git history, you will find an example where I did exactly blinking :) Jul 18 19:43:37 that should get you started Jul 18 19:43:47 thanks Jul 18 19:44:17 might just use some uio based code I already wrote with a noop delay though, I'm feeling lazy Jul 18 19:45:22 ;) isn't that the reason why we are programmers in the first place? Jul 18 19:46:18 not me, I'm solving all the worlds problems Jul 18 19:46:21 with the PRU Jul 18 19:47:08 *PRU - timer :p Jul 18 19:47:40 exactly Jul 18 19:53:18 when is the code to bring world peace ready, alexanderhiam? :D Jul 18 19:58:30 ds2: it was all set to go, but I type rm instead of mv... Jul 18 19:59:50 I actually did that once... I somehow type rm -r when I meant to do an mv... the day before a code demo... and I wasn't under version control... Jul 18 20:00:34 that was a fun night Jul 18 20:02:57 :| Jul 18 20:03:23 thats why I back up on cloud every half an hour Jul 18 20:04:22 I keep everything in dropbox now, that way the NSA can keep backups for me Jul 18 20:10:11 I keep mine on Gdrive, that way Google can make money while NSA keep backups for me :) Jul 18 20:11:14 oh that's very generous of you, they really need the money Jul 18 20:12:05 :) Jul 18 20:12:21 good night alexanderhiam! Jul 18 20:12:31 talk to you later Jul 18 20:13:04 * karki is happy he'll get an extra half an hour of sleep tonite :) Jul 18 20:13:14 4.5Hrs FTW Jul 18 20:16:07 sleep is for the dead Jul 18 20:36:36 ds2: or for the weak Jul 19 01:56:54 Morning **** ENDING LOGGING AT Sat Jul 19 03:00:00 2014