**** BEGIN LOGGING AT Thu May 31 03:00:08 2018
May 31 06:04:12 <zeekhuge> muneeb17: abhishek_ Uhm .. I am a bit confused. Do we really need to do anything about the pinmux settings ? The standard is to use `config-pin`. And what pins exactly to use, is highly dependent on the Pru-fw. So, I think the user of these interfaces will have to manually use `config-pin` ...
May 31 06:05:18 <zeekhuge> And, the DTO approach, that has been discussed above, how can that work for different pin configurations based on the PRU-fw ?
May 31 06:05:26 <zeekhuge> Oh ! btw .. Sorry for not being their in the meeting yesterday. Something unplanned came up.
May 31 06:10:38 <anujdeshpande[m]> vaishnav98_: just catching up with messages now - about the secure upload - how different is it from scp?
May 31 06:11:31 <zeekhuge> muneeb17: there ?
May 31 06:22:36 <zeekhuge> I would say those enum (constants) should be all capitals, like `NONE` , `STOPPED` etc ..
May 31 06:29:37 <vaishnav98_> anujdeshpande[m]: I am planning on making use of the bonescript RPC server for the implementation , it should probably be a better solution than using scp for deployment, however I haven't actually started working on it now , I am making the suggested changes to the pru support now , will update you as soon as I create a draft implementation for the remote upload.
May 31 06:35:24 <anujdeshpande[m]> Cool
May 31 06:36:30 <anujdeshpande[m]> I might have missed some updates from the last week or so. Do send any messages that you think I should see again
May 31 06:36:54 <anujdeshpande[m]> Also, how do you develop bonescript? Do you make changes to the repo on your host machine and then push them to the BBB or is there something more convenient? I need to setup my own dev setup tonight
May 31 06:42:47 <zeekhuge> muneeb17: Also, how will you implement writeSharedMem(), writeDataMem() ?
May 31 06:48:12 <vaishnav98_> anujdeshpande[m]: currently i am using sshfs for the development , it seems to be more convenient than making changes to the repository each time . https://vaishnav98.github.io/PocketBeagle-UI this one is a draft implementation of the pocketbeagle ui , just made some changes to the original BBUI ,I did test the features, however it doesn't work well from the GitHub page as the browser blocks loading of mixed active
May 31 06:48:12 <vaishnav98_> content , I am planning to integrate it here finally(after adding all the features) : https://vaishnav98.github.io/bone101/Support/bone101/PBUI/  and then probably integrate it with the bone101/BBUI and submit a PR .
May 31 06:54:27 <anujdeshpande[m]> Nice
May 31 07:00:25 <vaishnav98_> anujdeshpande[m]: also would like to inform you that I wasn't able to provide support for the HCSR04 sensor, I tried out this example https://github.com/dinuxbg/pru-gcc-examples/tree/master/hc-sr04-range-sensor (this was the latest one I found) and didn't have any success, I must admit that for me it would take some time writing a pru firmware example from scratch for the purpose, that's why I was moving on to other
May 31 07:00:25 <vaishnav98_> issues , so will it be okay to make improvements to the general pru firmware loading support now and then look into the sensor example part later after finishing the higher priority issues?
May 31 07:08:14 <Wormo> here
May 31 07:10:02 <Wormo> muneeb17[m] / zeekhuge / abhishek_[m]
May 31 07:15:57 <muneeb17[m]> zeekhuge:  About the pinmux settings, I wanted to include that in the API for completeness (the user need keep using the terminal) but I get your point. One thing we can do is provide a mapping from bits in __r30/31 regs and show the user the pin on which the show is on.
May 31 07:18:06 <zeekhuge> we can provide that as a document - sure ! no problem.
May 31 07:18:06 <zeekhuge> Or is it -
May 31 07:18:07 <zeekhuge>  You want to provide that in form of a code module that will go through the pru-fw and then understand what user wants to do and then use config-pin to set up the pinumes on behalf of the user ?
May 31 07:18:16 <muneeb17[m]> zeekhuge:  Sure, will change them the enums to caps. About the shared mem, isn't it similar to the Data mem access.  Like, only the offset changes, right?
May 31 07:19:45 <muneeb17[m]> zeekhuge:  i always wanted to involve the fw as well, but don't exactly know the parsing overhead will make it worth it?
May 31 07:20:19 <abhishek_[m]> The kernel does parse the firmware anyway
May 31 07:20:39 <abhishek_[m]> There are resource tables just for this purpose
May 31 07:20:43 <zeekhuge> muneeb17: shared-mem/data-mem : I am asking "how do you plan to do it" ? Write your own driver ? write a library for ysers to  coz as far as I know RPMsg does not support anything like that.
May 31 07:21:39 <zeekhuge> abhishek_: Resource table has anything related to Pru pins ?
May 31 07:21:55 <abhishek_[m]> No it doesn't
May 31 07:22:22 <abhishek_[m]> I feel it is best to leave pin configuration to config-pin
May 31 07:22:39 <zeekhuge> thats what I am suggesting too.
May 31 07:22:53 <zeekhuge> users can do crazy things with PRU-fw.
May 31 07:23:00 <zeekhuge> different files, #define s etc
May 31 07:23:13 <zeekhuge> and parsing it will make no sense IMHO
May 31 07:24:01 <zeekhuge> Also .. sorry for that cryptic msg related to "shared-mem/data-mem" above. I must rewrite it.
May 31 07:24:01 <muneeb17[m]> zeekhuge:  I used the mmap like here https://github.com/MuneebMohammed/PRUSS-Bindings/blob/696c6b964b3f8a5be4b346fb562af23d846e19f6/swig/pruss.cpp#L163
May 31 07:24:55 <muneeb17[m]> abhishek_:  zeekhuge : Ok, I will exclude the pinmux from the API.
May 31 07:25:57 <zeekhuge> muneeb17:  Can DMA project be used to Data-mem/Shared-mem ?
May 31 07:26:32 <zeekhuge> I mean, does it already support that ?
May 31 07:26:32 <muneeb17[m]> zeekhuge:  yeah, sure
May 31 07:27:38 <zeekhuge> You mean the existing project code already supports reading directly from Data-mem and shared-mem ?
May 31 07:28:07 <muneeb17[m]> yeah
May 31 07:28:36 <muneeb17[m]> the data memory, atleast
May 31 07:28:58 <zeekhuge> Cool then. We are not using `mmap` then.
May 31 07:29:12 <zeekhuge> We are wrapping these bindings over what RPMsg and Rproc can do.
May 31 07:29:12 <abhishek_[m]> We don't have to?
May 31 07:29:41 <zeekhuge> And then .. once we are using DMA, we can add reading from those memories.
May 31 07:29:57 <abhishek_[m]> Hmm
May 31 07:30:29 <zeekhuge> * is begining to hate the delays in messages .. most probably being cause by matrix.
May 31 07:31:42 <abhishek_[m]> ZeekHuge: another thing I was discussing yesterday was that any program using these bindings must have root access
May 31 07:31:56 <abhishek_[m]> Which is not always a good idea
May 31 07:32:50 <zeekhuge> Right. I saw the daemon based approach.
May 31 07:32:57 <zeekhuge> That works for me
May 31 07:33:03 <zeekhuge> and will also make bindings much simpler.
May 31 07:33:07 <zeekhuge> for all the languages.
May 31 07:33:33 <zeekhuge> As once we have the daemon, other language bindings can simply use the same daemon and same signals
May 31 07:36:15 <Wormo> yes to running as little as possible with privileges
May 31 07:36:17 <muneeb17[m]> zeekhuge: So, can I go forward with the approach? One more thing, what about resource table generation?
May 31 07:36:30 <muneeb17[m]> abhishek_: ^
May 31 07:36:49 <zeekhuge> We are wrapping these bindings over what RPMsg and Rproc can do.
May 31 07:36:49 <zeekhuge> abhishek_:  Makes sense ?
May 31 07:37:22 <abhishek_[m]> Might make sense to cover DMA as well
May 31 07:37:31 <zeekhuge> muneeb17: what about it ? Resource table is responsibility of the fw writer.
May 31 07:38:10 <Wormo> being able to display it I thinks he meant
May 31 07:38:43 <muneeb17[m]> zeekhuge:  most of the part will be the same, so provide a helper function to automate generation based on a few params?
May 31 07:38:49 <zeekhuge> Might make sense to cover DMA as well
May 31 07:38:50 <zeekhuge> Right. But while we are not using it. Should just focus on Rpmsg and Rproc thing and without involving arbitrary mmap read/writes.
May 31 07:39:10 <Wormo> a staged release
May 31 07:40:27 <zeekhuge> Zzeekhuge: most of the part will be the same, so provide a helper function to automate generation based on a few params?
May 31 07:40:28 <zeekhuge> We first do what we have planned to do. Once we are done with that. We can make it as much "futuristic" as we want to.
May 31 07:40:29 <zeekhuge> We planned for the bindings over RPMsg and Rproc, adding DMA support, creating a good documentation, a lot of examples.
May 31 07:41:28 <Wormo> examples and docs will be key to getting others to actually use iy
May 31 07:41:47 <muneeb17[m]> zeekhuge:  Yeah, makes sense.
May 31 07:42:07 <zeekhuge> also, Resource table is very powerful, in general and can be used very efficiently, for the intial settings of the PRUSS. So, a fw designer can use it for various purposes. maybe it will make more sense to give a template form of the resource table format.
May 31 07:42:19 <zeekhuge> but we can look into it later.
May 31 07:43:04 <Wormo> I think that is good planning to prioritize the basics
May 31 07:43:59 <Wormo> all set to continue onwards muneeb17[m] ? other questions?
May 31 07:44:06 <zeekhuge> I pinged Wormo over hangouts. No reply yet. She seems to be busy.
May 31 07:44:20 <Wormo> what?
May 31 07:44:58 <Wormo> I didn't get a hangout ping from you today.. let me reload the page
May 31 07:45:10 <muneeb17[m]> Oh... She did say that she might be late.
May 31 07:45:29 <Wormo> wait what? I'm right here...
May 31 07:45:34 <zeekhuge> muneeb17: About the error codes. Try to use Unix codes as much as possible and where the standard description of that error makes sense with the error in case of your code.
May 31 07:47:06 <zeekhuge> abhishek_: muneeb17 : do you see wormo here ? She said she is up on the channel.
May 31 07:47:40 <Wormo> I am invisible!
May 31 07:47:48 <zeekhuge> this is scary ! seriously ! http://logs.nslu2-linux.org/livelogs/beagle-gsoc.txt
May 31 07:47:55 <zeekhuge> and funny too :D
May 31 07:47:58 <muneeb17[m]> zeekhuge:  I will use the unix codes. About Wormo, Exactly
May 31 07:48:33 <muneeb17[m]> i noticed that yesterday, thought there was some bug
May 31 07:50:23 <Wormo> am I still an invisible lurker?
May 31 07:50:27 <zeekhuge> I am guessing that a problem with `matrix`, as the log-bot is able to see her
May 31 07:51:26 <zeekhuge> *thats
May 31 07:51:55 <Wormo> muneeb17: hi
May 31 07:52:15 <muneeb17> Wormo: HI. Yeah, matrix problem
May 31 07:54:25 <muneeb17> muneeb17[m]: ping
May 31 07:54:30 <Wormo> I agreed with zeekhuge's milestone planning, add dma to the one after
May 31 07:55:00 * ds2 tosses seeing stones around to make Wormo visible
May 31 07:55:35 <Wormo> whoa careful with those
May 31 07:55:59 <zeekhuge> I can see you guys in the logs :P
May 31 07:56:51 <Wormo> zeekHuge_ decided to wake up out of the matrix
May 31 07:57:15 <zeekHuge_> yeah .. freenode web client.
May 31 07:57:25 <zeekHuge_> on the browser.
May 31 07:57:29 <muneeb17> Wormo: yeah.. :D
May 31 07:57:42 <zeekHuge_> This is not good. Matrix is cool otherwise.
May 31 07:58:05 <Wormo> I've used that when firewalled out of normal irssi connections
May 31 07:58:14 <Wormo> the web client
May 31 07:59:07 <Wormo> what's good about matrix besides letting me sneak up on you like a ninja :D
May 31 07:59:51 <zeekHuge_> Okay so. Wormo : any suggestions on what we discussed ?
May 31 08:00:06 <zeekHuge_> We go with the daemon based approach ?
May 31 08:00:24 <Wormo> yes, less code running with privilege is good
May 31 08:00:51 <muneeb17> Ok, so I will go forward with the implementation.
May 31 08:01:21 <zeekHuge_> Wormo: Okay. And we frist wrap the code over RPMsg and Rproc, and not use mmap. makes sense ?
May 31 08:01:28 <Wormo> hopefully things will go well and resource table will be an interesting thing to look into
May 31 08:01:57 <Wormo> yes concur with your milestone planning and priorities
May 31 08:02:04 <zeekHuge_> then when we addd DMA which will add support to read shared-mem/data-mem of the PRUs
May 31 08:02:06 <zeekHuge_> Cool then.
May 31 08:02:16 <zeekHuge_> muneeb17: anything else ?
May 31 08:03:07 <zeekhuge> abhishek_: I think it will be better to see the logs : http://logs.nslu2-linux.org/livelogs/beagle-gsoc.txt and not believe the history that riot is showing.
May 31 08:03:46 <abhishek_[m]> Wow, looks like we're in the matrix :)
May 31 08:04:27 <muneeb17> yep :)
May 31 08:04:35 <muneeb17> zeekHuge_:not that i can think of
May 31 08:12:48 <zeekHuge_> A bit confused now, should I monitor the logs ? or still be on the matrix ? :P
May 31 08:18:02 <muneeb17> zeekhuge: yeah, I'm back to using x-chat :| .Any other alternatives apart from the web client?
May 31 08:18:39 <Wormo> irssi :)
May 31 08:19:34 <Wormo> some ppl run irssi in a screen session wherever they got a server account
May 31 08:20:11 <muneeb17> Oh , ill check that out.
May 31 08:20:20 <Wormo> it gives the ability to attach detach and keep history, though that is less vital here thanks to the logs
May 31 08:20:47 <Wormo> yay logs
May 31 08:21:50 <muneeb17> yeah, they're really handy
**** ENDING LOGGING AT Fri Jun 01 03:00:09 2018