**** BEGIN LOGGING AT Thu Mar 05 02:59:59 2015 Mar 05 04:42:55 Is there way to get IRC logs for last 11 hours? Mar 05 06:15:41 Is cloud9 bootspeak enabled ide ? Mar 05 06:15:52 oops sorry.. botspeak Mar 05 08:31:43 hi praveendath92: i tried again on beagle Mar 05 08:31:49 I tried 3 times Mar 05 08:31:57 first two times it was crash Mar 05 08:32:15 3rd time it was able to show the desktop Mar 05 08:32:24 but crashed after around 5 minutes Mar 05 08:32:59 i have the log here http://pastebin.com/rrrCdYE2 Mar 05 08:49:15 azizulhakim: Yes. There is a slow path issue. When the USB bandwidth is insufficient. Mar 05 08:50:00 is that the reason of crash also? Mar 05 08:50:03 I added RLE but didn't enable due to too much CPU load on both devices. I will figure out a better solution Mar 05 08:50:05 Yes. Mar 05 08:50:14 The 3rd one. Mar 05 08:50:39 You can see slowpath in the reports. Mar 05 08:50:58 I see. Mar 05 08:51:11 I'm hoping URBs could be a solution. Mar 05 08:51:33 Right now it's all blocking writes over USB. Mar 05 08:52:06 Okay. Do you have any high level documentation of the framebuffer driver? Mar 05 08:52:26 Check the Linux Kernel docs. Mar 05 08:52:30 Framebuffer API Mar 05 08:53:11 It offers specifying call backs while registering a FB driver. Mar 05 08:53:30 And also, do check the USB driver API. Mar 05 08:54:02 If I remember correctly, you mentioned that you have worked with Accessory Protocol before? Mar 05 08:54:08 I've some knowledge about the USB driver API as I was preparing for this project Mar 05 08:54:58 Yes, I was working on keyboard, mouse and ALSA driver. All for the purpose of this project Mar 05 08:55:06 So have basic understanding of USB API's Mar 05 08:55:33 Just needed to know how the driver is encoding the data from frame buffer and how you are decoding them back in your application Mar 05 08:57:48 Look around this https://github.com/praveendath92/bard-droid/blob/master/src/in/co/praveenkumar/bard/io/USBControl.java#L129 Mar 05 08:57:58 The Android part is really simple here. Mar 05 08:58:51 https://github.com/praveendath92/bard-linux/blob/master/udlfb.c#L491 Mar 05 08:59:02 This is called when ever there are page updates. Mar 05 08:59:28 by page do you mean a frame? Mar 05 08:59:31 Read the Framebuffer API, skim through, to get more missing details. Mar 05 08:59:38 A page is 4096 bytes. Mar 05 08:59:59 Resolution is right now fixed at 1024x768 Mar 05 09:00:15 Each pixel is 2 bytes. Mar 05 09:00:32 So, a page is 2 vertical lines of UI. Mar 05 09:00:47 I see Mar 05 09:01:01 The above mentioned fn is called by kernel whenever a page has updates. Mar 05 09:01:18 So, we get changes in 4096 bytes and in our case, every 2 vertical lines. Mar 05 09:02:02 Go through the above fn and the called fn in it. Mar 05 09:02:07 You get an overview. Mar 05 09:02:19 Okay, I'll. Thanks Mar 05 09:02:45 Anytime. Mar 05 09:03:28 I got to go now. I will be at work so, you can reach me over email. Be back at around 7 PM German time. Mar 05 09:03:54 Okay. Have a nice day Mar 05 09:04:28 You too. Bye :) Mar 05 11:29:40 praveendath92: maybe we can swich to Isochronous transgers Mar 05 11:29:44 transfers Mar 05 11:40:20 vvu: I guess that would be best Mar 05 11:40:55 Some updates drops shouldn't do perceivable harm Mar 05 11:41:32 I will go through DisplayLink's original code and see how they are doing it. Mar 05 11:41:38 shouldn't be so hard to change them Mar 05 11:41:52 but the original code was doing some compression ? Mar 05 11:43:10 Yes. RLE. Mar 05 11:43:18 wwhy not reuse that code ? Mar 05 11:43:55 I didn't fully understand their compression code back then Mar 05 11:44:21 And I need to decode it. Mar 05 11:44:58 I will take a look again. Mar 05 11:45:56 <_av500_> I remember some issue around ISO Mar 05 11:46:05 <_av500_> also, what would it gain? Mar 05 11:46:13 <_av500_> we use the usb pipe only for our data anyway Mar 05 11:46:27 <_av500_> ISO helps you to get e.g. audio streaming on a full usb bus Mar 05 11:48:18 ISO? Mar 05 11:48:42 isochronous Mar 05 11:48:56 <_av500_> ja Mar 05 11:49:01 endpoint Mar 05 11:49:31 I forgot the EPs offered in ADK mode. Mar 05 11:49:36 I will check once again. Mar 05 11:49:49 I'm not quite sure if there is an ISO EP too. Mar 05 11:50:22 If that's there, it would be nice. We can have an EP for each data stream. Mar 05 11:56:09 praveendath92: i do not think it has ISO endpoint Mar 05 11:56:13 just bulk in/out Mar 05 11:56:44 Yes. That's what I remember. Mar 05 11:56:55 I'm just checking right now. Mar 05 11:57:28 so at think point you are not doing any compression Mar 05 11:57:29 ? Mar 05 12:00:28 * vvu university's fibre went down and now dwlding at 20KB/s :( Mar 05 12:01:42 Nope. None right now. Mar 05 12:02:07 I did try with compression once - same technique used in original driver. Mar 05 12:02:07 well this needs a fix Mar 05 12:02:22 But it was too much load on both devices. Mar 05 12:02:54 on the android side you are running everything on the main thread ? Mar 05 12:03:30 i had same issues at a hackathon, wanted to do a game usng kinect 2...that thing usses USB3.0 all the bandwidth there and processing was a pain Mar 05 12:04:22 Nope. Mar 05 12:04:40 Only UI updates on MainThread. Mar 05 12:05:06 load on android as in GC went all over the place ? Mar 05 12:05:11 i remember you had an issue like that Mar 05 12:05:34 vvu: _av500_ Just checked. Only 2 EPs. Mar 05 12:05:39 Bulkin and Bulk out Mar 05 12:05:59 Oh yes. That was because of redeclaration of the buffer everytime. Mar 05 12:06:04 yeah Mar 05 12:06:04 You pointed it out. Mar 05 12:06:12 Now I'm using a single buffer. Mar 05 12:06:21 praveendath92: can you give me the link where you found the EPs ? i always lose that one Mar 05 12:06:51 I just checked for my new device actually. Mar 05 12:06:52 http://pastebin.com/Nm2TKjrd Mar 05 12:07:39 ok :) Mar 05 12:08:58 Is this what we you are talking about? http://source.android.com/accessories/aoa2.html Mar 05 12:09:57 vvu: I should be leaving now. I should be at lab. I will ping you in the evening. Mar 05 12:10:26 I'm thinking of a layered structure for the driver since we have limited EPs for many types of comms. Mar 05 12:10:34 Will discuss in the evening. Mar 05 12:10:35 yeah Mar 05 12:10:38 ok, have fun Mar 05 12:10:52 Sure. Bye :) Mar 05 13:01:14 hii..how can i see device tree ovelay of adc ?? Mar 05 13:01:22 in BBB Mar 05 13:02:45 use the source Mar 05 13:03:08 how ?? Mar 05 13:05:22 are u talking abt this ?? http://elinux.org/BeagleBone_and_the_3.8_Kernel#Device_Tree_Overlays Mar 05 13:20:46 no Mar 05 13:20:51 kernel source tree Mar 05 13:28:53 which is in /sys/kernel right ?? Mar 05 13:34:00 your job to find out Mar 05 13:34:19 I could give you the link, but then you wont get to have any fun ;) Mar 05 13:35:08 i have been searching since half an hour..and googling out..but couldn't get it..:( Mar 05 13:38:00 karki: can u plss give me the link ?? i have searched a lot !! Mar 05 13:38:22 nope :p Mar 05 13:38:37 i'll give you a hint Mar 05 13:38:44 okk..:D Mar 05 13:38:50 it's in the bb kernel tree on github Mar 05 13:41:33 ok..hope this time i'll get some result out of it..:D Mar 05 13:53:25 Hi karki !!! Mar 05 14:01:33 What are some ide's on the end user PC which can be used in PRUduino(Botspeak enabled) ? Is cloud9 one among them ? Mar 05 14:02:09 Or is it that we need to create a virtual machine which is compatable with PRUspeak ? Mar 05 14:05:30 Karki , Abhishek_ : ping Mar 05 14:16:39 karki: i found gpio, usb and everything else here https://github.com/beagleboard/linux but no ADC :'( help help !! Mar 05 14:17:08 anujdeshpande: did u see the mail ?? Mar 05 14:17:58 geekswine_: I did, but i personally prefer mail on the bb gsoc mailing list. have you checked it out yet ? Mar 05 14:18:31 yeah i have sent mail there also long time back.. Mar 05 14:18:52 and here also on irc..both the channels.. Mar 05 14:20:20 since last week i have been working on this..but no progress :( Mar 05 14:27:53 sidbh: what are the libraries for ADC in starterware ? Is it tsc_adc.h ? Mar 05 14:28:28 anujdeshpande: could u help in solving some basic doubts regarding this pls? Mar 05 14:29:53 is there any prior work done on this ?? Mar 05 14:31:51 hello there. Am larry, a 4th year computer engineering student of the Faculty of Engineering and Technology Buea, Cameroon Mar 05 14:32:30 i hope to be participating in this year's GSOC with you guys. my next steps are your ideas page. Thanks Mar 05 14:32:49 geekswine_: check your inbox Mar 05 14:33:45 i got top notch skills in Java and Android and have built apps and implemented some concepts around the android platform Mar 05 14:36:07 thanks anujdeshpande Mar 05 14:36:25 and sry for the mistakes i made in the mail..:( Mar 05 14:36:28 lite__: have you tried out android on the bbb yet ?? Mar 05 14:36:33 geekswine_: no issues Mar 05 14:37:29 i'll do the work..:) Mar 05 14:45:41 anujdeshpande: working on it. will get back with my worries and concerns Mar 05 15:08:54 hey can anyone tell me the handle of Siddharth Bharat Purohit ? Mar 05 15:12:31 altairpearl: sidbh Mar 05 15:12:38 altairpearl: he isn’t around right now Mar 05 15:12:59 oh ok I have been working on the BeagleRT project Mar 05 15:13:51 compiled v3.14.31 with and without simple prempt options and also with fully premeptible option after patching it with RT patch Mar 05 15:14:31 I'm trying to patch it now with Xenomai patches Mar 05 15:14:59 can anyone tell me on what I should be concentrating on and How I can contribute ? Mar 05 15:15:04 altairpearl: you could ask vmayoral more about it Mar 05 15:15:18 ok thank you Mar 05 15:15:32 altairpearl, https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-xenomai-3.14.y/patches/ipipe-3.14/0001-ipipe-3.14.patch it's based on ti's 3.14.x Mar 05 15:16:18 thank you rcn-ee Mar 05 15:24:29 anujdeshpande, altairpearl: i won't be mentoring BeagleRT, ask in the mailing list if any other mentor is willing to support the project. Regards Mar 05 15:24:50 oh ok Mar 05 15:50:31 apaar_: pong Mar 05 15:57:28 Abhishek_ : http://imgur.com/6fmtjNy(crude modification of our flowchart :)....i had a discussion discussed with deepak would love to hear your veiws, wanted to be crystal clear on the layout before moving ahead :) Mar 05 15:59:40 :P Mar 05 16:01:08 doesn't the core driver does mem management ? Mar 05 16:02:07 well karki did say that shared memory is the job of the bridge and not the core driver... Mar 05 16:02:27 yes Mar 05 16:02:40 different plugins would want to handle memory differently Mar 05 16:02:48 pru bridge is one such plugin Mar 05 16:03:26 or if necessary, the core driver could have some sort of an api Mar 05 16:03:32 which the plugins could use Mar 05 16:03:58 the last thing we want is the core driver dictating the use of memory! Mar 05 16:04:20 do we have any sort of agreement on the core driver structure? Mar 05 16:04:29 okay Mar 05 16:04:32 Abhishek_ not yet Mar 05 16:04:41 we need panto to drop in Mar 05 16:05:07 I'm still thinking of rpmsg vs custom streams Mar 05 16:05:31 * karki flies back to work Mar 05 16:05:44 Also, why didn't I see the PRU RAM in the block diagram? Mar 05 16:06:24 the diagram has it's flaws Mar 05 16:06:33 is that different from the ddr ram in the diagram(4MB)?? Mar 05 16:06:38 yes Mar 05 16:06:43 much different Mar 05 16:06:51 go through the pru architecture docs Mar 05 16:06:53 NOW Mar 05 16:06:59 ok cool :) Mar 05 16:07:12 at least clean up the block diagram the next time :) Mar 05 16:07:21 or use lucid charts Mar 05 16:07:23 ;) Mar 05 16:07:43 lucid dreams :) Mar 05 16:07:48 lol Mar 05 16:07:56 of the PRU - Bridge framework :D Mar 05 16:11:19 karki: What are some ide's on the end user PC which can be used in PRUduino(Botspeak enabled) ? Or is it that we need to create a virtual machine which is compatable with PRUspeak ? Mar 05 16:11:41 please read the README Mar 05 16:11:48 it's more than clear Mar 05 16:11:57 there are examples to get you started Mar 05 16:12:40 * karki is busy. Mar 05 16:13:41 Abhishek_ : are these 32bit arguments the only data we send with downcalls ? https://github.com/beagleboard/linux/blob/3.8/drivers/remoteproc/pru_rproc.c#L1345-L1346 Mar 05 16:14:11 yep Mar 05 16:14:43 and this is written to pru dram ? Mar 05 16:14:46 And anything else is mutually agreed Mar 05 16:14:53 Figure it out :) Mar 05 16:15:21 okay (y) Mar 05 16:33:04 you know the pru does have plenty of registers...... the arguments could land up there too ;) Mar 05 16:33:47 karki: are we allowed to make changes in rproc.c ?? I guess we need to basic structures Mar 05 16:34:08 yeah change whatever you like Mar 05 16:35:25 they are only using interupts , to read files we need more and what should be file system architecture .. Mar 05 16:35:57 ? Mar 05 16:38:00 karki: Can I send you a pull request for starterware library or you want me to create a standalone repo ? Mar 05 16:38:16 sysfs file system on kernel . how it is going to be different than usual gpio's interfaces , i will take care and avoid latency .anything more ? Mar 05 16:41:13 karki: correct me if I am wrong Mar 05 16:41:54 how will you avoid latency in sysfs? Mar 05 16:42:27 kiran4399 : create a standalone one Mar 05 16:42:35 a pull req makes no sense Mar 05 16:42:53 OK. :-) Mar 05 16:44:35 karki: using enhanced gpio's only , if hardware support it . Mar 05 16:49:02 Aman_singh: As a framework designer, your job is to empower the applications, not restrict what they can use and what they can't Mar 05 16:49:24 There is no running away from latency Mar 05 16:49:48 But we have to ensure some upper bound at least Mar 05 16:50:39 okay ,need to find a midway Mar 05 16:52:05 First make sure that you have reasonable expectations of the possibilities Mar 05 16:52:29 RTM. Mar 05 16:53:10 Aman_singh: typical sysfs latencies are fine anyway, the idea is to offload a task to the coprocessor to go off and do in real time, some reasonable amount of latency initiating that task is excpected and unavoidable Mar 05 16:54:24 if your task is just to set the state of a single GPIO pin then the latency will likely be greater than doing so through the GPIO sysfs interface, but that's not the kind of task that makes sense to do on a PRU Mar 05 16:54:58 not single but there are 16 on each pru . Mar 05 16:55:12 can't we use them ? Mar 05 16:55:24 Aman_singh: Are those 16 accessible from the pin headers? Mar 05 16:55:30 the firmware running on the pru can do whatever it wants with them Mar 05 16:56:27 if a developer needs custom sysfs entries it's up to them to write a custom driver using the pru rproc framework Mar 05 16:56:29 don't know , that's why I said if hardware allows me Mar 05 16:58:31 karki: are you envisioning a single prubridge sysfs entry? Mar 05 17:00:47 okay , it means no need to think wild anyways if we are okay with latency no need to use single prubridge entry . you were right it will do more harm :( Mar 05 17:02:06 what do you mean by "no need to use single prubridge entry"? Mar 05 17:03:26 specifying a particular gpio for communication Mar 05 17:04:18 PRU Bridge isn't just about GPIO communication Mar 05 17:04:43 in fact, prubridge has nothing to do with gpio at all Mar 05 17:04:44 we have 10 channels too Mar 05 17:04:55 It is meant to take into account every single application that has been created using the PRU so far and cater to even more Mar 05 17:07:17 prubridge is just a two-way data transmission line from userspace to kernel space to the pru Mar 05 17:07:33 you mean, like a UART Mar 05 17:08:17 no channels used in pruss_rproc to set interupts Mar 05 17:09:06 jkridner|work: there ? Mar 05 17:13:42 correct me plz according to me in rpoc we are using 10 channels to set interupts and we are communicating through them . these channels are used to create a intermap Mar 05 17:15:46 Aman_singh: prubridge will be built on top of that saame rporc interface Mar 05 17:16:34 the concept for kernel->pru transfer being it will write the data to a location in their shared memory, then signal to the pru that the data there is ready to be read Mar 05 17:16:47 okay , sorry i went through pdfs and started thinking in wrong direction Mar 05 17:17:48 the interrupt map is useful in inter-PRU and ARM signalling Mar 05 17:18:26 this can help http://processors.wiki.ti.com/index.php/PRU_Interrupt_Controller Mar 05 17:18:40 helped me alot Mar 05 17:19:18 but besides the pru and kernel driver telling eachother that there's data ready to be read the interrupt controller is outside the scope of prubridge Mar 05 17:19:32 and kernel is accessing register using virtual address functions in rproc . is that right ? Mar 05 17:19:58 right Mar 05 17:20:57 good find shubhangi Mar 05 17:21:01 Abhishek_: can you tell me how driver gets mapping data specified in the dts ? Mar 05 17:21:21 will quicken things for me Mar 05 17:21:29 thanks all of you :) Mar 05 17:21:31 look in the probe() function Mar 05 17:21:36 okay Mar 05 17:25:32 are all you folks talking PRU here interrested in the prubridge project? Or is anyone looking at upstreaming the rproc framework? Mar 05 17:26:07 i am looking into upstreaming Mar 05 17:26:17 after yesterday's discussion Mar 05 17:26:23 awesome Mar 05 17:29:25 Try reading a book on Linux Device Drivers, in that case Mar 05 17:31:16 read a few pdfs, wrote very simple device driver few weeks back. doesnt really do anything. just exposes device node Mar 05 17:31:22 even I will like give my best :) after so many days feeling attached with pru Mar 05 17:31:44 can you tell me if i should try develop something specific Mar 05 17:32:07 or better continue reading and understanding the existing code first Mar 05 17:32:11 shubanghi: do you have a beaglebone? Mar 05 17:32:15 yes Mar 05 17:32:48 i have one Mar 05 17:33:12 you could try putting together something simple with the current rproc code Mar 05 17:33:33 a simple driver + matching PRU firmware Mar 05 17:34:06 something like a sysfs entry that sets the state of a pru gpio pin Mar 05 17:34:11 sending a char &receiving ACK to toggle led ? Mar 05 17:34:19 sounds good Mar 05 17:34:23 yes, was thinking on the same line Mar 05 17:34:26 okay Mar 05 17:34:29 on it Mar 05 17:35:05 will ping if need assistance Mar 05 17:35:25 anyone looking to work with the pru would benefit from doing that Mar 05 17:35:38 * alexanderhiam should probably do that! Mar 05 17:54:56 hello Mar 05 17:55:49 is anyone working on arduino implementation on beagleboneblack Mar 05 18:03:57 hello everyone Mar 05 18:04:21 I have some question about the Android-based remote display project Mar 05 18:04:34 the bard-droid applicayion more specifically Mar 05 18:04:56 is anyone here familiar with bard-droid? Mar 05 18:08:55 shoot Mar 05 18:09:00 just ask Mar 05 18:12:39 I've forked praveendath92 bard-droid project Mar 05 18:13:02 Hi mateirm94 Mar 05 18:13:13 besider migrating it to Android Studio Mar 05 18:13:47 ? Mar 05 18:13:52 I've also modified a little bit BardReceiver Mar 05 18:14:05 Link? Mar 05 18:14:10 to use android.harware.usb instead of the add-on library Mar 05 18:14:34 https://github.com/Matei94/bard-droid.git Mar 05 18:14:35 Have it Mar 05 18:15:41 the point is that the add-on library does not support USB host mode, idk know yet if this is going to be needed Mar 05 18:15:53 alexanderhiam : "are you envisioning a single prubridge sysfs entry" -- nope Mar 05 18:16:08 mateirm94: Let me check Mar 05 18:16:12 but there is no point to use the add-on library since the minimumSdkversion is 16 Mar 05 18:16:23 one sysfs entry for each channel in communication :) Mar 05 18:16:34 btw, I modified the minSdkversion to 15 to run it on my device Mar 05 18:17:11 karki_: Instead of sysfs entries, there could also be char device nodes Mar 05 18:17:16 yes Mar 05 18:17:21 there could be Mar 05 18:17:21 It's just a matter of "taste" for kernel developers Mar 05 18:17:28 yep Mar 05 18:18:06 actually, device nodes might make more sense since they're essentially virtual serial ports Mar 05 18:18:24 mateirm94: That's a lot of changes in one commit. Mar 05 18:18:27 we can have sysfs entries to get started with exposing upcall/downcall to userspace Mar 05 18:18:32 hmm... Mar 05 18:18:44 I'm too sleepy to think right now guys :( Mar 05 18:18:53 it's been a busy day! Mar 05 18:19:03 * karki_ needs sleep Mar 05 18:19:05 praveendath: there are a lot of changes because of the Android Studio migration Mar 05 18:19:24 you guys carry on the discussion, I'll catch up tomorrow morning :) Mar 05 18:20:08 praveendath: since the official IDE has changed, wouldn't it be nice to make this migration? Mar 05 18:22:13 Actually BardReceiver class has no task at all. Mar 05 18:22:23 I'm not sure why it's still lying around. Mar 05 18:23:17 That class can be removed safely. Mar 05 18:23:58 mateirm94: Take a look at this class for USB related actions Mar 05 18:23:59 https://github.com/praveendath92/bard-droid/blob/master/src/in/co/praveenkumar/bard/io/USBControl.java Mar 05 18:24:45 Yes. Inertia is still stopping but migration is a welcome change. Mar 05 18:24:52 praveendath92: I'll have a look at it Mar 05 18:25:09 Android app part is very little here. Mar 05 18:25:18 Most work is on kernel driver Mar 05 18:25:55 praveendath92: Could you point some simple-path issues for me to work on? Mar 05 18:26:05 on the kernel driver? Mar 05 18:26:23 simple-path issues? Mar 05 18:27:02 simple-one-patch Mar 05 18:27:13 Oh. That. Mar 05 18:27:52 I would instead recommend that you try to setup the project on your PC / Bone and Phone. Mar 05 18:27:53 i do not think we have those now :) Mar 05 18:28:03 start understanding the kernel driver Mar 05 18:28:19 It's a tedious job right now Mar 05 18:28:48 Or go through the Readme and other docs and try to get an overview of the driver structure Mar 05 18:29:18 Ok, I have a Beaglebone Black board and I'll try to setup it there Mar 05 18:29:52 vvu: I'm thinking of making a doc which briefs the basic over of the driver structure and other start pointers, what do you think? Mar 05 18:30:30 mateirm94: Perfect. There are many rough edges so, have some patience. Mar 05 18:30:58 Read me should be sufficient to get the whole setup ready. Mar 05 18:31:52 praveendath92: Thanks for your help. I'll come back with further questions as soon as I understood enough to have some :) Mar 05 18:32:13 Sure :) Mar 05 18:35:06 that would be good Mar 05 18:35:11 with the latest debian Mar 05 18:35:17 default setup Mar 05 18:43:56 hey i wanted to do project under GSOC how should i start Mar 05 18:50:24 Well, have you thought about the particular project that you want to do? Have you looked over the GSoC suggestions from bb.org? Or are you proposing a new project? Mar 05 19:10:32 pru_rproc driver doesnt come with v3.8 ? Mar 05 19:11:28 i have to compile the driver ? Mar 05 19:27:53 Hey I am interested for doing project of Enhancing ADC drivers for BBB. Can you help how to get started? Mar 05 19:37:29 namaste_: a good starting point is to review the AM335x TRM chapter on the Touchscreen Controller... http://www.ti.com/lit/ug/spruh73l/spruh73l.pdf Mar 05 19:38:24 ok thanks Mar 05 19:39:30 namaste_: it's a combined TS and general purpose ADC. Also, it would help to understand what is supported in the current adc iio driver. ds2 and I can help guide a bit on what is missing in the current support. Mar 05 19:40:48 namaste_: one obvious piece is dma support when in continuous mode and ds2 has additional thoughts on periodic sampling features Mar 05 19:42:03 namaste_: an important thing to consider will be the scope of features that can be enabled but also what is feasible to actually upstream during the GSoC schedule. Getting something upstream will usually exceed the calendar time that GSoC allows..but there's some alternatives we can discuss Mar 05 19:42:44 ok Mar 05 19:44:04 oh, there's also some minor things like being able to control the sample averaging that's currently hardcoded in the driver. Mar 05 19:44:34 I'm actually spending some time remembering what all is missing on this myself as I haven't worked with it in some time now Mar 05 19:45:02 ohh Mar 05 19:46:09 hey i want to want to work for project Demo Android app using BBBAndroid. How to start ? Mar 05 19:47:12 mdp: and I am from Electronics background so I have somewhat idea about the hardware Mar 05 19:48:21 namaste_: great, that would help..having some kernel experience would be a huge advantage on this project Mar 05 19:49:36 ya I have worked about cross compilation in BBB and built kernel Mar 05 19:53:22 vvu: https://github.com/praveendath92/bard-linux/blob/master/documentation/dev.md Mar 05 19:58:05 perfect Mar 05 19:58:09 edit the ideas page Mar 05 19:58:14 and include this there Mar 05 19:59:49 praveendath92: any idea about the reason of crash during start up? Mar 05 20:00:36 Not sure. Mar 05 20:00:53 I mean, I probably knew before. I need to check it. Mar 05 20:01:24 Sorry azizulhakim. I just need some more time before I can start fixing it. Mar 05 20:01:38 Too much work piled up at lab :( Mar 05 20:02:27 azizulhakim: consider it as pre-proposal work :) Mar 05 20:05:19 Right Mar 05 20:09:32 vvu: Done. Mar 05 20:18:26 av500: I made an intro doc. Feedback on what else can added / changed? Mar 05 20:18:26 https://github.com/praveendath92/bard-linux/blob/master/documentation/dev.md Mar 05 20:25:18 starprince: Are you still around? Mar 05 20:25:50 yes Mar 05 20:25:55 ^_^ Mar 05 20:26:15 You were interested in a project regarding BBBAndroid? Mar 05 20:26:33 yes, can u guide me how to start Mar 05 20:27:19 How experienced are you are with interfacing simple hardware to the BBB? Mar 05 20:27:44 Say, connecting an I2C chip to the BBB or lighting LEDs with GPIOs? Mar 05 20:29:20 i have worked previously on the beagle. I am used it with debian and accessed GPIO using python and C program. Mar 05 20:29:55 i have also used it for small IOT project Mar 05 20:30:55 OK. Have you done any Android app development before? Mar 05 20:32:07 yes, I have developed android app and used connected it with with online website. I used json for message passing Mar 05 20:33:47 The BBBAndroid distribution is a KitKat 4.4.4 Android built from AOSP sources. But, unlike the other Android reference implementation available for the BBB, it uses the 3.8 Linux kernel. Mar 05 20:34:14 You don't get OpenGL ES (as the SGX blob isn't available for 3.8), but you do get the cape manager. Mar 05 20:34:52 What we'd like to do is have a nice sample app or apps that demonstrate how to interface with hardware connected to the BBB. Mar 05 20:35:33 The general idea is to use one or more AsyncTasks in the background that are using JNI to talk to the hardware. Mar 05 20:35:56 Android typically uses the HAL for this, but we're looking at a quick and simple way to allow people to access the hardware. Mar 05 20:36:17 since android uses JVM. I think the app can be implemented in eclipse of android studio? Mar 05 20:36:46 Either is fine. The tool you use would be your choice. Mar 05 20:36:52 Whatever you feel most comfortable with. Mar 05 20:37:40 If you have a more focused Android-based hardware interfacing project, that would be fine, too. Mar 05 20:38:08 so, is there some JNI code developed previously or we have to start from scratch Mar 05 20:38:36 We're going to guide you and answer your questions, but ultimately you "own" the project. We can provide you with some samples to get you started. Mar 05 20:41:36 ok, i think i should first install Android on my beagle and then see how i can proceed. Mar 05 20:43:02 hendersa, i will keep you updated about my progress Mar 05 20:43:08 If you think that you would like to proceed with the project, start putting your proposal together. Learn about the various BBB hardware interfaces and think about what you can do with each. Mar 05 20:44:24 Keep in mind that we'll probably see several proposals on this topic, and we'll select one that is reasonable and realistic in the timeframe of GSoC without being trivial. Mar 05 20:45:43 ok, its fine. It will be a good learning experience. Mar 05 20:46:19 That's the plan. Good luck. Mar 05 20:46:42 thanks Mar 05 20:50:26 hii mdp.. Mar 05 20:50:33 will you be mentoring "Library_of_Arduino-compatible_functions_for_StarterWare" project this time?? Mar 05 20:51:15 i have gone through this project and started exploring and working on it.. Mar 05 20:51:35 as i have experience of bare metal programming with atmega16a.. Mar 05 20:52:08 interfaced lcd jhd162a with it and even worked with arduino... Mar 05 20:52:35 so very excited to work with BBB.. Mar 05 20:57:04 i mean with jason will you be also there ?? Mar 05 21:02:36 * jkridner|work pokes his head in Mar 05 21:06:01 jkridner|work: i have wriiten some libraries but just needs to rectify some errors .... Mar 05 21:06:23 k Mar 05 21:07:52 in the example GPIO example given in starterware a specific GPIO_INSTANCE_ADDRESS has been used.. Mar 05 21:08:43 so not getting how t make it generalized if we are programming in an arduino..as we have only pinMode instructions... Mar 05 21:10:19 like we have SOC_GPIO_1_REGS and similarly 3 more are there (as i remember).. Mar 05 21:10:34 for GPIO_INSTANCE_ADDRESS Mar 05 21:12:05 geekswine_: is that the base addresses of the different GPIO modules? Mar 05 21:12:30 yes.. Mar 05 21:15:03 you'd need to map integer pin numbers to module and pin (the most confusing approach as it's a custom pin mapping and wouldn't match any bbb docs), have macros to define the pins as something like GPIO1_28, or pass the module and pin number to the GPIO functions Mar 05 21:25:26 okk.. Mar 05 21:25:57 i searched everywhere but couldn't find as its not matching with bbb docs Mar 05 21:42:26 so input in the pinMode function will be P8_12 or P9_12 and on the basis of that GPIO1_28 or GPIO_12 will be pass to the GPIO functions as a pin number..is it right ?? Mar 05 21:50:18 geekswine_: that would work Mar 05 21:51:05 thanx..:) Mar 05 21:53:03 geekswine_: there's also the kernel driver's numbering scheme, which is module*32 + pin (e.g. GPIO1_28 = 1*32+28 = 60) Mar 05 22:03:32 nice..:) Mar 05 23:41:01 sidbh: Hey I'm interested in working on the BeagleRT idea. Can you guide me on that? Mar 06 02:34:27 jkridner, alexanderhiam: there ? **** ENDING LOGGING AT Fri Mar 06 02:59:58 2015