**** BEGIN LOGGING AT Thu Aug 13 02:59:59 2015 Aug 13 14:25:31 gm Aug 13 14:26:45 gm rohith Aug 13 14:27:01 Hello jkridner! Aug 13 14:28:53 jkridner: I saw that the BeagleBone Greens are up for preorder Aug 13 14:29:01 yup! Aug 13 14:29:14 Nice! Aug 13 14:29:37 Shaving $16 off the price is quite good too. Aug 13 14:29:51 compared to the BBB Aug 13 14:33:48 indeed. Aug 13 14:33:57 should make it rather popular. Aug 13 15:46:44 gm Aug 13 16:13:41 good morning Abhishek__ Aug 13 16:46:33 arianepaola: How's the UI/UX part of your app coming up? Mind sharing a screenshot? Aug 13 16:50:53 moin Aug 13 16:51:33 nerdboy: morning. Nice stats btw Aug 13 16:53:07 gonna have to fix that guy's math problem some day... Aug 13 16:53:24 * nerdboy will not try to dix perl Aug 13 16:53:30 *fix even Aug 13 17:04:30 moin Aug 13 17:47:42 rcn-ee: What's the best way of imaging a customized system image? Aug 13 17:48:22 Abhishek__, is your image on the microSD or eMMC? Aug 13 17:48:32 any special partition setups? Aug 13 17:48:49 microsd, downloaded a console image to customize Aug 13 17:49:17 okay, just: cd /opt/scripts/tools ; git pull Aug 13 17:49:17 install a few packages and services and zip it up again Aug 13 17:49:45 do you want it to auto flash another device, or just make a small *.img to share? Aug 13 17:50:13 just a small image to share. Aug 13 17:51:59 rcn-ee: BTW, is there also some kind of package list of the console image vs the "normal image" ? Aug 13 17:52:16 Abhishek__, okay i have something, just need to remove a few things.. Aug 13 17:53:26 that would be easy on angstrom Aug 13 17:53:44 Abhishek__, dpkg --list Aug 13 17:57:10 s/angstrom/yocto/ Aug 13 17:58:31 * ds2 refrains from pour more gasoline Aug 13 17:58:59 Abhishek__, https://gist.github.com/RobertCNelson/b54ddad33e839f292eba Aug 13 17:59:59 Abhishek__, just need to change this: https://gist.github.com/RobertCNelson/b54ddad33e839f292eba#file-generate_img-sh-L214 to a rsync call (microSD -> image) Aug 13 18:00:16 Abhishek__, right now it's configured as a 3.6GB image: https://gist.github.com/RobertCNelson/b54ddad33e839f292eba#file-generate_img-sh-L235 Aug 13 18:04:04 I see, so preallocate the image and then fill it. Aug 13 18:08:00 Abhishek__, exactly, it'll crate a blank image, copy your microSD over and then, and dump out an *.img let me get the rsync call in their.. Aug 13 18:09:30 rcn-ee: just wondering, would there be a way to create this image not on the BeagleBone Black itself but using my PC? I believe it could be a bit faster that way... Aug 13 18:10:34 Abhishek__, x86.. yeap.. Aug 13 18:16:35 Abhishek__, okay: https://gist.github.com/RobertCNelson/b54ddad33e839f292eba passed a quick test here, i'm just mountede /dev/sdd1 (microsd) to /tmp/rootfs on my x86... Aug 13 18:19:40 Abhishek__, then just run: sudo bmaptools copy --bmap example-image.bmap example-image.img /dev/sdX (and it'll dump it to your 2nd microSD card) Aug 13 18:35:06 Abhishek__, forgot the dd MLO/u-boot.img... Aug 13 19:22:36 Abhishek__: ping Aug 13 19:22:44 hey Aug 13 19:23:07 need some help Aug 13 19:25:28 how do i continuously stream data to a char device. some buffers arrive on each interrupt and i am not able to synchronize arriving buffers and copy_to_user Aug 13 19:25:52 is the number of buffers fixed or variable? Aug 13 19:26:16 tht depends on the the pru code .. so for one program its fixed Aug 13 19:26:28 remains fixed for an application Aug 13 19:27:51 hmm, what's the relevant code you have for that section? [point to a commit or gist if you haven't committed it yet] Aug 13 19:27:52 cant wait for all data to be transferred since its supposed to be a continuous stream from pru. Aug 13 19:27:59 okay Aug 13 19:28:02 w8 Aug 13 19:28:39 hmm, so the idea is to do some kind of a non-block copy_to_user, right? Aug 13 19:30:15 https://github.com/shubhi1407/PRU-framework/blob/master/drivers/remoteproc/pruss_remoteproc.c#L973-L1020 Aug 13 19:31:16 this callback executes inside interrupt handler of the driver Aug 13 19:31:24 when a vring is kicked Aug 13 19:31:38 by the PRU? Aug 13 19:31:53 yes Aug 13 19:32:01 and this supposed to copy to userspace Aug 13 19:32:03 https://github.com/shubhi1407/PRU-framework/blob/master/drivers/remoteproc/pruss_remoteproc.c#L459-L490 Aug 13 19:34:14 are you missing interrupts or buffers due to copy_to_user taking long or something? Aug 13 19:34:40 latter Aug 13 19:35:04 missing buffers Aug 13 19:35:58 the while loop in recv_cb goes too fast Aug 13 19:36:20 so the rx_data buffer is overwriitten before being copied Aug 13 19:36:24 to user Aug 13 19:37:18 hmm, maybe you need some kind of flow control to pause the transmission on the PRU side until you clear the buffer? Aug 13 19:37:25 i thought of wait_for_completion in the cb but then read that it shouldnt be used inside interrupt context Aug 13 19:37:27 or slow down things a little bit? Aug 13 19:38:10 bringing ds2 into the conversation here ^ Aug 13 19:38:17 the PRU stops sending .. tht is there https://github.com/shubhi1407/PRU-framework/blob/master/firmware/src/rproc-pru1-fw.c#L92 Aug 13 19:39:01 lets say i have just one interrupt ... even then the issue exists Aug 13 19:40:34 lets say 256 buffers arrive with an interrupt .. each has to transferred to userspace Aug 13 19:42:41 and since this happens within an interrput handler i can't put the loop (which reads each buffer) on wait for the copy_to_user to complete Aug 13 19:45:22 the pru wont send any data unless there are empty buffers.. so that wont be an issue .. whenever the driver reads from a buffer, it adds it back to the ring as free buffer. Aug 13 19:48:03 suggestions ? Aug 13 19:51:22 could it be beause you call the https://github.com/shubhi1407/PRU-framework/blob/master/drivers/remoteproc/pruss_remoteproc.c#L973-L1020 virtqueue_get_buf twice? Aug 13 19:52:24 the first call is just to get the first buffer Aug 13 19:52:55 and subsequent calls in a loop to get remaining ones Aug 13 19:53:13 the way I see it, even if you just have one buffer, that function gets called twice. Aug 13 19:54:01 i'll make it a do while Aug 13 19:54:18 then it'll be called once if theres a single buffer Aug 13 19:57:55 Hmmmmm? Aug 13 19:58:43 what part of the interrupt? fast path or slow path? Aug 13 20:00:56 sorry but idk about fast and slow path terminilogy Aug 13 20:01:57 okat .. slow ones could be re interrupted in the middle of existing handler running . right ? Aug 13 20:07:57 https://www.irccloud.com/pastebin/yQwSSvZW/ Aug 13 20:08:33 ^ this is exactly what i face .. LDD chapter 10 , Pg 269 Aug 13 20:13:03 hmm .... the chapter gives the solution as well .. i need a circular buffer in the driver and the handler writes to it .. Aug 13 20:14:10 once written it'll wake_up the waiting read procedure of char device Aug 13 20:16:24 ds2: Abhishek__ : ^can that be the way out ? Aug 13 20:17:19 https://lwn.net/images/pdf/LDD3/ch10.pdf page 12 here talks of the same issue i guess Aug 13 20:17:46 and then the example code on next page Aug 13 20:17:47 okay, so do a memcpy to a local circular buffer and then copy_to_user from the handler ? Aug 13 20:18:36 yes Aug 13 20:19:39 do a memcpy,wake_up the sleeping read routine and return irq_handled Aug 13 20:21:40 the read function can then read from the circular buffer at its own leisure .. although it should finish copying before the next interrupt arrives with its new payload of buffers Aug 13 20:22:34 if its not fast enough then the only option would be to slow things down a bit Aug 13 20:24:38 and try keeping interrupt frequency less by writing to more buffers for each kick .. although that is upto the pru firmware developer .. we can only advice Aug 13 20:44:16 back Aug 13 20:44:24 okay brief lecture on interrupts on Linux Aug 13 20:44:52 On Linux there are 2 possible interrupt handler - the fast path and the slow path respectively. Aug 13 20:45:24 the fast path happens pretty much immediately after the interrupt occurs. You cannot do anything that may sleep within there. Aug 13 20:46:23 the slow path happens latter. it is at the whims of the current scheduler. However, you can do all sorts of stuff there. Aug 13 20:47:05 (just to avoid confusion - there is also the concept of top/half bottom half but I am not referring to that - I am talking about the newer threaded irqs Aug 13 20:47:10 Aug 13 21:43:03 ds2 : ping Aug 13 21:43:07 https://www.kernel.org/doc/htmldocs/kernel-api/API-request-threaded-irq.html Aug 13 21:44:10 ^ i can even wait_for_completion in "thread_fn" Aug 13 22:01:41 shubhangi: that's the slow path Aug 13 22:01:49 no waiting in the fast path Aug 13 22:04:12 ds2 : in the API isn't 'handler' the fast path and 'threan_fn' the slow path ? Aug 13 22:05:27 If you want to set up a threaded irq handler for your device then you need to supply handler and thread_fn. handler is still called in hard interrupt context and has to check whether the interrupt originates from the device. If yes it needs to disable the interrupt on the device and return IRQ_WAKE_THREAD which will wake up the handler thread and run Aug 13 22:05:27 thread_fn. Aug 13 22:06:03 ^description says so Aug 13 22:06:35 okay. You said the same thing . my bad Aug 13 22:07:07 sorry Aug 13 22:25:11 shubhangi: yes. Aug 13 22:53:16 ds2: if a new interrupt arrives while the previous slow path thread is yet to finish its job, will the new slow path to be executed be added to a wait queue or just override the previous one ? Aug 13 23:40:15 shubhangi: IIRC, neither. you need to loop there. Aug 14 00:08:04 gm Aug 14 00:08:19 nerdboy: available? Aug 14 00:20:37 sorta Aug 14 00:21:26 did you ping alexanderhiam ? Aug 14 00:25:26 nerdboy: sent an email back to both of you, should be the inbox Aug 14 00:25:44 can't see him online now (or yesterday before the meeting, though I might have missed him later) Aug 14 00:26:07 The current state is mostly described in the email Aug 14 00:26:30 and the plan going forward, so if you want me to correct course, ping in Aug 14 00:27:17 though, the most burning issue is the solver, so I wanted to ask you if you've got any advice/guidance to give out Aug 14 00:27:17 much appreciated Aug 14 00:28:42 there's a c/matlab package that should work, and there are a couple of python-C interfaces Aug 14 00:29:10 right now you only have time for a "simple" python filter Aug 14 00:30:14 well, I've found a couple of packages that can do python <-> matlab Aug 14 00:30:14 should I go testing them out and see how that works? Aug 14 00:30:14 i would get everything in place with a simple "demo" filter in python Aug 14 00:30:14 ok, was thinking the same Aug 14 00:31:07 python-C would be preferable Aug 14 00:31:19 python-C can work, but I still need to figure out how to convert the eigen() function in matlab to C Aug 14 00:31:24 passing anything from python to octave/matlab would be through file-IO ? Aug 14 00:31:26 will go digging to see what it's made of Aug 14 00:31:52 cython first, than maybe swig Aug 14 00:31:55 python <-> matlab, depends on the library, if I wanna go that route Aug 14 00:32:08 matlab is not free Aug 14 00:32:14 I've seen a couple of different implementations, though some where abandonware Aug 14 00:32:27 yeah, I mean i write Matlab Aug 14 00:32:32 what I mean is Octave Aug 14 00:32:39 finite element toolkit is free/open source Aug 14 00:32:51 force of habit, but they are fully compatible, or usually are Aug 14 00:33:07 so python <-> Octave is an option Aug 14 00:33:12 Python C is what I would like Aug 14 00:33:20 but need either a solution to those non-lin equations Aug 14 00:33:21 octave is not really intended for real-time stuff Aug 14 00:33:33 or will go digging through the eigen function and reproduce that Aug 14 00:33:46 nope, that's why C is best Aug 14 00:33:56 for now you should stick with python Aug 14 00:34:10 but a demo app *wiil* work even in octave Aug 14 00:34:20 i don't care what the demo filter is, it's the interface that's important Aug 14 00:34:32 gotcha Aug 14 00:34:40 have to taken a look at the python API? Aug 14 00:34:48 does it make sense to you? Aug 14 00:34:50 as in you have no time for anything but a simple filter Aug 14 00:35:22 use numpy or scipy or some other python filter package Aug 14 00:35:26 I didn't upload the proper files yesterday, the push got messed up somehow, now ir's fixed Aug 14 00:35:49 ok, sticking to NumPy for the filtering Aug 14 00:36:07 but still would needa solution to those non-lins, since that would be the best case solver i want to produce Aug 14 00:37:02 but anyway, I'm working on that Aug 14 00:37:16 should have some more info by tonight and some code preferably Aug 14 00:37:34 comments on API, still welcome Aug 14 00:37:52 do the other stuff first Aug 14 00:37:57 * neemo likes feedback so that he knows he's going in the right direction Aug 14 00:38:03 then worry about filter Aug 14 00:38:16 ok Aug 14 00:38:42 the input is done, sent a pull to alexanderhiam Aug 14 00:38:49 should work quite well Aug 14 00:38:56 what's left is solver and API Aug 14 00:39:28 I'll be doind the API to completion and then start plugging in the solver/filter Aug 14 00:39:31 makes sense? Aug 14 00:41:25 you have tests and doc stuff too... Aug 14 00:42:15 i mean finish *everything* before going back to play with the filtering/data processing... Aug 14 00:42:42 at least as much as possible Aug 14 00:43:15 somebody will yell at us if i let you get away with anything else... Aug 14 00:51:01 neemo: i have to get some other work done, but we'll touch base as soon as we can both look at it Aug 14 00:51:23 hopefully tonight or first thing tomorrow... Aug 14 00:52:44 roger that Aug 14 00:53:03 I'll be glueing myself to the chair and looking at the API/documenting Aug 14 00:53:13 ping me when you're free Aug 14 01:37:35 * nerdboy ships that palette of super-glue... **** ENDING LOGGING AT Fri Aug 14 02:59:58 2015