**** BEGIN LOGGING AT Sun Jun 08 02:59:59 2014 Jun 08 04:07:29 * karki wonders where panto is....... Jun 08 04:20:39 mranostay : my mmap gives me an invalid argument error, I can't figure out why. the mmap function is called in the driver and seems to execute perfectly, but return value of mmap is -1 and error a bit is set! Jun 08 07:57:37 _av500_: i should aricrack those, the problem is here that he has a fritzbox and it automatically closes at 00:00 Jun 08 07:57:41 until lik 6 AM Jun 08 08:56:46 Abhishek_ : did you get the mmap stuff? Jun 08 09:36:42 not yet, still finalizing the PRU stuff Jun 08 11:01:57 alexanderhiam : :) Jun 08 15:20:56 jkridner : did you get my mail? Jun 08 16:16:38 hey karki Jun 08 16:16:48 hey! Jun 08 16:17:00 alexanderhiam : got a few minutes? Jun 08 16:17:12 sure Jun 08 16:17:58 So first things first, I'm able to communicate to the PRU via python :) [well, in userspace in general] Jun 08 16:18:07 awesome Jun 08 16:18:28 now I'll be coding the interpreter logic for 1 PRU Jun 08 16:19:20 So I'm hoping PyBBIO will have PRU support within a month of GSoC ending ;) Jun 08 16:19:35 that would be great Jun 08 16:20:03 I had a few design questions for the PRU part as such, one of them being how to start off. Jun 08 16:20:19 one way is to start with one PRU and later expand Jun 08 16:20:46 another way is to develop a complete bare bones version and take it from there Jun 08 16:21:08 like the first iteration itself will have support for 2 PRUs Jun 08 16:21:18 but very basic support Jun 08 16:21:42 So its the "Iterative" model vs "incremental" model Jun 08 16:22:20 I think if the kernel driver is loading the scripts into shared memory and generating an interrupt in the PRU that says "stop what you're doing and start executing this", then I think I'm leaning more towards the 1 PRU model for now Jun 08 16:22:40 yep, my driver does that for now Jun 08 16:22:55 but I'm forgetting exactly what the 2 PRU model looks like, what would their roles be? Jun 08 16:23:21 PRU0 interacts with kernel, PRU1 will work with IO stuff Jun 08 16:23:34 PRU0 is mainly a control component Jun 08 16:24:49 but I did forget one thing...... (First let me assume that I have one PRU only to work with) Jun 08 16:25:41 alexanderhiam : assume I have loaded a botspeak script in memory, and the PRU is executing it. Jun 08 16:26:53 now I get another set of instructions! how do I handle this? [It would be easy to handle one instruction coming my way, but a stream of instructions..... ] Jun 08 16:28:59 I assume you have a reserved space in the shared memory for 2 way communication; you could have the driver send a signal to the PRU to say "I have a new script for you", then the PRU would finish it's current instruction and do what ever cleanup was needed, then signal back that it was ready. Jun 08 16:29:17 once the driver got the ready signal back it could safely overwrite the previous script Jun 08 16:30:22 so my problem is that : Jun 08 16:30:35 say I'm executing something in a loop Jun 08 16:30:53 and want to execute something something in between Jun 08 16:31:00 and get back to the loop Jun 08 16:31:20 though now as I'm typing this out, this feature seems a stupid one to have..... Jun 08 16:32:39 not stupid, I think concurrent scripts would be awesome, but if you're limiting this to a single script for now then I think that sending a single instruction can count as a whole script Jun 08 16:34:41 well, concurrent scripts would mean........ Jun 08 16:35:10 loss of precision and guarantee of what is executed when..... Jun 08 16:36:22 yeah, from the userspace perspective, if you need a bunch of single instructions in a row you should just send them in a script Jun 08 16:36:31 as of now I will just keep an 1 instruction interruptible loop :) Jun 08 16:38:50 you could have a "single insctruction ready to execute" flag that the driver sets after loading the single insctruction into a special spot in the shared memory Jun 08 16:39:14 the interpreter loop could just check that flag between each instruction Jun 08 16:40:44 well thats the plan for now, lets see how it will work out :) Jun 08 16:41:24 just make sure you have adequate semaphores for everything Jun 08 16:41:50 hopefully by wednesday's meeting I'll have a basic python library wipped up :) Jun 08 16:41:53 i.e. never overwrite anything the PRU hasn't given permission to overwrite Jun 08 18:39:48 * karki goes to sleep early :) (finally I'll be able to sleep for more than 5 hours tonite ;) ) Jun 08 18:40:03 :)\ Jun 08 18:41:03 g'nite karki **** ENDING LOGGING AT Mon Jun 09 02:59:58 2014