**** BEGIN LOGGING AT Tue Mar 11 02:59:59 2014 Mar 11 04:08:22 Morning Mar 11 04:16:26 Abhishek_ : morning! Do you know of any way to initiate DMA transfers using python? eg. start reading a SPI port and write the values into a given location in memory? Mar 11 04:16:46 on the ARM, not pru Mar 11 04:18:16 I am not aware of any such method as of now. Mar 11 04:19:12 Any idea where I can look at? AFAIK your project has a lot to do with DMA/EDMA; these are topics I'm not too familiar with! Mar 11 04:20:19 mranostay: do you know of any such method? Mar 11 04:31:33 is it necessary that the SPI driver itself should support DMA? or can we set it up from userspace somehow? Mar 11 08:26:32 mranostay: ping Mar 11 08:41:21 mranostay, jkridner, mdp, ds2: Update. I have been able to successfully run a code capturing data from the PRU GPIO pins Mar 11 08:42:07 The code was one of those which I had mentioned in my idea thread on the GSoC discussion group Mar 11 11:18:36 * mranostay yawns Mar 11 11:19:03 Abhishek_: capture to PRU DRAM? Mar 11 11:20:52 gm mranostay Mar 11 11:21:23 gm _av500_ Mar 11 11:23:53 jkridner: any chances of a "public" release of the pru compiler anytime soon ? Mar 11 11:24:11 Every time I ask, it is always about a month away. :( Mar 11 11:24:15 anujdeshpande: tomorrow :) Mar 11 11:24:21 always tomorrow :) Mar 11 11:24:28 jkridner: mranostay haha :D Mar 11 11:26:18 jkridner: (for the GSOC application) what do expect to be the impact of the BeaglePilot project on the BeagleBoard.org community? Mar 11 11:26:54 * jkridner continues to monitor https://www-a.ti.com/downloads/sds_support/TICodegenerationTools/download.htm for a stealth PRU Compiler release. Mar 11 11:27:00 +1 for vmayoral's question Mar 11 11:27:42 oh, interesting.... there is a release of the C6000 compiler that runs on ARM! Mar 11 11:28:10 I was asking for that for ages (which is how it got in the work-queue). Nobody told me it was finally done. Mar 11 11:30:40 jkridner: i noticed some folks are working on a library for gpio, etc with pru. i was thinking of tackling pwm and ppm using pru. do you think it's worth it to do it separately ? Mar 11 11:31:40 As part of a GSoC? I doubt it is so complex as to justify having someone only work on GPIO. Mar 11 11:33:32 jkridner: i noticed quite a few discussions around here. i had a bare bones proposal here https://docs.google.com/document/d/1oL0NU4d5ZiujAuXJmI40pziRQlXCEmAf5TgK6NVDap8/edit Mar 11 11:34:53 jkridner: i am thinking of pwm, ppm output and ppm-sum input using the pru. along with porting an existing qt based gcs on the bbb as part of gsoc Mar 11 11:40:30 anujdeshpande: the breakdown between the first two workgroups doesn't make sense to me... seems there is much redundancy and not a clean separation of tasks. Mar 11 11:42:43 jkridner: implementing spi/i2c on the pru would be tedious i think. so those are separated out. sidbh_ what say ? Mar 11 11:43:35 anujdeshpande: yeah i'll be working on that front Mar 11 11:43:36 anujdeshpande, nah Mar 11 11:43:36 jkridner : I was talking to mranostay, mdp and panto about the higher language bindings to talk to the PRU. The project got very interesting. Mar 11 11:43:38 spi is easy Mar 11 11:43:45 i2c only slightly harder Mar 11 11:43:52 Anyone try using the StarterWare library on the PRU to do things like SPI/I2C access? Mar 11 11:44:06 I'm just wondering what is the end result expected out of the project. Mar 11 11:44:20 How much to be done in GSoC time? Mar 11 11:44:43 karki: ah, you mean creating a common firmware load with messaging such that higher-level languages can direct the PRU? Mar 11 11:44:46 jkridner: yeah i'm dealing with that stuff, i told you so i guess, i've a repo with blinkled example using starterware function Mar 11 11:44:52 panto: i see... have you looked at https://docs.google.com/document/d/1oL0NU4d5ZiujAuXJmI40pziRQlXCEmAf5TgK6NVDap8/edit ? we are trying to break down the objectives for beagle pilot into work packs here. comments much appreciated Mar 11 11:44:57 jkridner : Yes! Mar 11 11:45:00 karki: did you look at http://github.com/jadonk/pruduino? Mar 11 11:45:08 yes :) Mar 11 11:45:09 that is where I've been trying to put my thoughts... Mar 11 11:45:23 mranostay probably has some critiques as I never reviewed the idea with him. Mar 11 11:45:26 jkridner: check out https://github.com/BeaglePilot/PRUSS-C/ Mar 11 11:45:26 anujdeshpande, however do that only if the hardware i2c devices are not enough Mar 11 11:46:25 well there was quite a discussion yesterday that gave me a fair idea about the project. I'' scratch it down on a google doc and put it up here! Mar 11 11:46:32 anujdeshpande: so, you are doing the ARM loader part and messaging interface? Mar 11 11:47:30 jkridner: yepp. as well as output generation (pwm & ppm) and input (ppm-sum). ppm is used in rc controllers, etc. Mar 11 11:48:57 jkridner : How will this project impact the beaglebone community? What would be the positive outcomes if this project will be successful? Mar 11 11:49:26 One thing is it would make realtime control from any higher level language much simpler. Mar 11 11:49:39 control of the PRU I mean Mar 11 11:55:08 yes, capture from PRU to DDR (8 MB buffer) Mar 11 11:57:17 All : does the current kernel on the beaglebone black support eCAP in capture mode? Mar 11 11:59:00 hello! I checked the ideas page for gsoc. http://elinux.org/BeagleBoard/GSoC/Ideas. Can I apply to GSoC with a proposal related to one of these ideas or should I come up with a brand new idea? Mar 11 11:59:53 cristian : either way is fine. Mar 11 12:00:07 morning mranostay, jkridner Mar 11 12:00:25 yes, capture to DDR (8MB Buffer) Mar 11 12:02:26 I did get some example code to get up and running, it generates vcd files as well. However PRU assembler source was not there, so I am attempting to disassemble a 352-byte PRU bin file. Mar 11 12:02:46 karki: I am familiar with powerpc device trees and linux sysfs. I also sent a couple of linux patches upstream Mar 11 12:03:36 mdp, mranostay: Need help with this disassembly: https://www.irccloud.com/pastebin/xTqKiZZy Mar 11 12:05:45 Obtained with prudebug. Mar 11 12:07:35 Abhishek_: little more detail what i'm looking at :) Mar 11 12:17:13 mranostay: given that the PRU can access hardware which is under the linux kernel's control, what stops a person from writing a PRU program that'll go completely rogue? Mar 11 12:19:31 mranostay, Initial Search before giving a GSoC idea pointed me to: http://linux.thaj.net63.net/2014/01/logic-analyzer-with-your-beaglebone.htm . I have been experimenting with it; The PRU assembly source isn't given, so I am trying to disassemble the FW to improve it. Mar 11 12:21:05 karki: nothing other than you need root to run it Mar 11 12:21:40 so to load the firmware on the PRU, I need root permissions? Mar 11 12:22:01 well /lib/firmware better be root only permissions Mar 11 13:12:38 jkridner : How will this project impact the beaglebone community? What would be the positive outcomes if this project will be successful? Mar 11 13:12:53 One thing is it would make realtime control from any higher level language much simpler. Mar 11 13:12:54 why are you asking me? didn't I reply? Mar 11 13:13:05 ah. Mar 11 13:13:19 can you say why that is important? Mar 11 13:14:19 * jkridner doesn't want to overly lead the answer Mar 11 13:15:11 karki: you have experience with scripting languages, C and assembly, right? Mar 11 13:16:10 all the current libraries will be running on linux, and it can't completely focus on IO; offloading to the PRU gives us faster IO speeds Mar 11 13:16:28 and it is preferable that this feature of the PRU can be exploited through a high level language :) Mar 11 13:17:15 building such a firmware will let us have a generic way to communicate between the PRU and any high level language Mar 11 13:17:45 So only client side libraries have to be re written Mar 11 13:17:56 yes, C and ARM assembly Mar 11 13:18:08 I'm getting familiar with the PRU assembly Mar 11 13:18:35 oh! yes and python. I also looked up bot-speak Mar 11 13:18:40 why is a higher-level language preferred and what do you mean by a higher-level language? Mar 11 13:19:25 oh! I meant something like python or JS where it will be easy for new comers to code. Mar 11 13:19:49 get the c library done first Mar 11 13:20:00 k, ease of new comers is one good reason, if you have some feel for why it is easier than starting with C. Mar 11 13:20:01 worry about the 'high level' languages later Mar 11 13:20:26 panto: this is just for the justification of the project, not the execution. Mar 11 13:20:40 the question he needs to answer is what is the value to the community... Mar 11 13:20:47 I'd like to make sure he knows. Mar 11 13:21:02 * jkridner uses the pronoun 'he' without any gender knowledge. :-) Mar 11 13:21:30 panto: thats the plan, I'll be starting with C. the final idea is the have integration with other scripting languages! Mar 11 13:22:02 jkridner : I am a 'he' ;) Mar 11 13:23:59 karki: I don't believe that whoever focuses on this PRU firmware should be needing to do the scripting language integration, except in-as-much as is needed for testing.... Mar 11 13:24:09 I think others can focus on that integration. Mar 11 13:24:26 just my opinion on a good division of labor. Mar 11 13:24:32 Got it :-) Mar 11 13:26:15 but as of now, my problem lies with remote proc. I spent a decent bit of time on UIO, but its of no use now :/ and I just started reading up on remote proc! Mar 11 13:32:37 where can I find some "hello world" programs that use remote proc? Mar 11 13:33:53 I read this : https://www.kernel.org/doc/Documentation/rpmsg.txt ; helped me understand the broad idea of the framework, but didn't really explain how to start off with the PRU in specific. Mar 11 13:37:42 jkrinder: hello! i would like to work on "SYSFS entries for IIO and PWM". whom should I speak to ? Mar 11 13:41:40 rpmsg is not remote proc Mar 11 13:41:45 it's something built on top of it Mar 11 13:49:29 cristian_bercaru: just post your questions here Mar 11 13:50:57 cristian_bercaru: +1 to vvu|Log Mar 11 13:51:28 panto : can you please help me understand what this would mean "Rpmsg is a virtio-based messaging bus"; what is remote proc as compared to rpmsg? normally I would RTFM, but in this case I cant really find one ;) Mar 11 13:51:42 you should speak to everyone here and pull in the beagleboard-gsoc list as well as you flesh out your thoughts. Mar 11 13:52:48 cristian_bercaru: checking the existing status of the kernel code is a nice place to start. if that is an excessive challenge, it might not be the right project for you. be sure to use Google. Mar 11 13:53:24 jkridner: I'm trying to create a new thread with the qualification test completed but the attached file (ARM Linux binary) is rejected Mar 11 13:53:24 http://omappedia.org/wiki/Design_Overview_-_RPMsg Mar 11 13:53:24 karki: ^^^ Mar 11 13:53:32 * jkridner should really have an army of BeagleBones available on the Internet for anyone to poke on. Mar 11 13:53:38 i get a message like "application/octet-stream not admitted" Mar 11 13:53:54 btw, anyone in SFO this week? Mar 11 13:54:03 not me :( Mar 11 13:54:35 ok, I git-cloned https://github.com/beagleboard/kernel, but all I find is a series of patches. do you have a makefile or something ? Mar 11 13:54:39 jkridner: ok solved it Mar 11 13:54:56 jkridner: just appended .bin to the file name Mar 11 13:55:16 vmayoral: what was this in reference? Mar 11 13:56:16 av500 : THANK YOU :D Mar 11 13:56:36 does the beagle driver build a module or how? Mar 11 13:56:44 as a Mar 11 13:56:56 jkridner: the GSOC application proposal requires to "submit to the beagleboard-gsoc mailing list a statically-linked...". I was trying to upload a binary file without extension but it seem google groups doesn't allow it. Appending ".bin" to the file name did it Mar 11 13:57:00 av500 : even panto must be thanking you for getting me of his back ;) Mar 11 13:57:08 *off Mar 11 13:57:14 vmayoral: i see your cross-compilation test. Mar 11 13:57:35 mranostay: your PRU led stuff uses remoteproc? Mar 11 13:57:41 or baremetal? Mar 11 13:57:55 vmayoral: how did you solve it? Can you say so others can similarly work around whatever issue you encountered? Mar 11 13:58:14 vmayoral: btw, a pull-request is also acceptable. Mar 11 13:58:22 * jkridner should note that somewhere Mar 11 13:58:48 av500: yes it is using remoteproc Mar 11 13:58:56 av500: I've seen that mranostay's code uses remoteproc Mar 11 13:59:04 hi mranostay Mar 11 13:59:24 karki: did you look at mranostay's code? Mar 11 14:00:20 jkridner: seems Google Groups just allows a certain type of filenames (.bin) is one of them. So people should submit the test with ."bin" extension. That's it, just renamed my file and worked Mar 11 14:01:14 av500 : yes. but I had a few hiccups while following it. Mar 11 14:01:38 hold your breath and count to ten Mar 11 14:02:09 if only that could help ;) Mar 11 14:02:22 for hiccups, yes :) Mar 11 14:04:22 sorry, forgot to run ./patch.sh Mar 11 14:07:01 be sure you are on the right branch Mar 11 14:08:00 remoteproc is used when ARM --> PRU; does it also come into play for PRU --> PRU or PRU --> ARM? Mar 11 14:08:04 mranostay: master or hiccup? Mar 11 14:09:01 what is the right one? master? 3.13 ? Mar 11 14:09:02 karki: yes Mar 11 14:09:09 cristian_bercaru: 3.8 Mar 11 14:09:12 for PRU stuff Mar 11 14:09:29 karki, it's a linux kernel thing Mar 11 14:12:16 afk Mar 11 14:12:42 mranostay: so 3.8 is the branch for PRU. how about IIO and PWM ? Mar 11 14:12:57 if it is a kernel thing then it does not come into play between PRU to PRU, right? Mar 11 14:24:59 hi jkridner Mar 11 14:25:12 hi DiegoTc Mar 11 14:25:28 jkridner: do beagleboard have a template for project proposals Mar 11 14:25:39 or it's free option for students? Mar 11 14:25:52 we do have a template, but it is kinda crusty. Mar 11 14:26:06 I uploaded it yesterday. Mar 11 14:26:11 * DiegoTc do you have the link? Mar 11 14:27:48 DiegoTc: you should find it on melange.... here's a pastebin: http://pastebin.com/JHUr1uvr Mar 11 14:28:48 ah, it is at https://www.google-melange.com/gsoc/org2/google/gsoc2014/beagle Mar 11 14:31:42 thanks Mar 11 14:41:12 jkridner:the hello world will be good if it runs on a raspberry? Mar 11 14:41:24 panto, just one more doubt : is the code on the PRU is oblivious to the remoteproc mechanism? or is there some kind of an interface that has to be followed even while programming the PRU? Mar 11 14:41:27 sir we don't talk about the rpi here :) Mar 11 14:42:25 karki, there is some coarse ground rules to follow Mar 11 14:42:27 but nothing major Mar 11 14:42:34 rpmsg/virtio is another matter Mar 11 14:43:31 I see :) Mar 11 14:43:56 hi EslamSherif.... Mar 11 14:44:09 sorry if I seemed mean or anything.... Mar 11 14:44:28 panto : your testpru on github is based on virtio? Mar 11 14:44:34 just that a bunch of private messages are absolutely unmanagable by me. Mar 11 14:44:40 no i understand to not flood your PMs :) Mar 11 14:44:43 I drop in and out of the room all the time. Right now, I'm on a plane. Mar 11 14:45:05 most of the queries are generic anyway. Mar 11 14:45:11 i am actually reading now in the survival guide posted in the beagle board for irc so i don't make such mistake again :D Mar 11 14:45:23 :-) Mar 11 14:45:47 ok biking to intelplex bbl Mar 11 14:46:44 DiegoTc: if it runs on R-Pi, it should run on Beagle. Just be sure to specify the ABI so we know. Still, it would look better to submit an armv7 binary that is cross-compiled, which is the point. native compilation doesn't really show you understand what an embedded system even is. **** ENDING LOGGING AT Tue Mar 11 14:47:08 2014 **** BEGIN LOGGING AT Tue Mar 11 14:49:11 2014 Mar 11 14:49:13 if you cross-compile for armv7, it won't run on a Pi. Pi uses an older CPU architecture (armv6). Mar 11 14:49:27 but, Beagle will run armv6 instructions. Mar 11 14:49:45 and the Debian images support hard-float. Mar 11 14:50:25 one last question, I want to get out of the doubt. What about the Arduino Due http://arduino.cc/en/Main/ArduinoBoardDue Mar 11 14:51:43 arduino due is a completely different beast all together! Mar 11 14:52:12 it's a MCU! Mar 11 14:53:20 thanks for the info ! Mar 11 14:54:24 karki are you going to be a mentor? Mar 11 14:55:30 no, I'm a participant. Mar 11 14:58:32 karki: what's your project proposal? Mar 11 14:59:23 I'm trying to work on a remoteproc based firmware for the PRU. Mar 11 15:00:04 basically a firmware that can communicate with some userspace libraries on the ARM. Mar 11 15:01:11 using these libraries you can get dozens of functionality from the PRU, without having to reload an application specific code onto it Mar 11 15:01:43 this will help : https://github.com/jadonk/pruduino Something like this! Mar 11 15:07:51 karki: whoa that sounds cool Mar 11 15:08:02 what are you studying at college? Mar 11 15:09:26 i had sent a mail to the list regarding the bonescript webpages idea Mar 11 15:10:22 I'm a CS undergrad :) 3rd year of my bachelors degree. Mar 11 15:10:40 are the things i included feasable for a gsoc project Mar 11 15:12:55 also i should i post my cross compiled binary on the mailing list or should i send a pull request? Mar 11 15:23:39 karki: you like to work with a lot of hardware Mar 11 15:25:31 mranostay : in your led repo, this file "ws28xx-pru0.c" runs on the PRU or on the ARM? Mar 11 15:26:52 DiegoTc : if someone is here, it's cause they love to play with hardware ;) Mar 11 15:38:09 mranostay : ping Mar 11 16:06:24 karki: the pru0 in the filename should giveit away :) Mar 11 16:09:08 oh, yeah :p it's just that I was wondering how you used stdio.h for something that goes on the PRU! Mar 11 16:10:41 karki, magic Mar 11 16:10:51 none of that code runs on the PRU Mar 11 16:11:01 it traps and is executed on the ARM Mar 11 16:11:23 I've named it an upcall Mar 11 16:13:01 ah! Mar 11 16:13:17 so it goes both ways Mar 11 16:13:27 you have an RPC call from ARM to the PRU Mar 11 16:13:38 but you also have an RPC call from the PRU to the ARM Mar 11 16:13:58 obviously if you call into ARM, you're not realtime Mar 11 16:14:04 but that's not a big deal some times Mar 11 16:14:15 like the initialization and when you want to do debugging dumps Mar 11 16:17:03 panto : Thanks :) and one more thing, I was reading that remoteproc handles the loading and initialization of the remote processors. how come remoteproc.h is also included in the "ws28xx-pru0.c"? Mar 11 16:17:43 should it not be doing stuff on the ARM-linux side of things? Mar 11 16:20:00 common stuff for both PRU & arm Mar 11 16:25:15 so how does the loading of the img file for the PRU take place? you are supposed to use remoteproc for that right? Mar 11 16:25:51 do you see the DT overlay that uses the PRU driver? Mar 11 16:26:04 you load it, and you're go Mar 11 16:26:57 ok :) Mar 11 19:20:09 Mar 11 19:23:50 morning again Mar 11 19:37:25 ds2: would it be better to add the frontend node.js design for the LA / protocol visualizer to the proposal or focus only on building a core using PRU and libsigrok for my idea, which I will be converting into a GSoC proposal? Mar 11 19:40:25 Abhishek_: well... it comes down to this - can you give a convincing story that you can finish everything in the GSoC timeframe? Mar 11 19:42:22 I am working on it, I would only like to ask your opinion (with the current background) on how much should be kept in GSoC, and how much outside of GSoC. Mar 11 19:43:40 Abhishek_: I don't know you well enough to comment on that specifically (I've learned that interview questions only go so far...) Mar 11 19:43:46 however - Mar 11 19:44:04 what LA's have you used before? Mar 11 19:45:07 oh keep in mind...expect problems/hitches/issues to arise Mar 11 19:45:18 no matter how well planned, there will be unforeseen gotchas Mar 11 19:48:52 I have normally done debugging my circuits without an LA, this would be my first actually :) . I am well aware of hitches and issues, and because I have worked (practially) independently in the past, I expect to be able to resolve them by reading the ref manuals and all available documentation thoroughly, and if there is something that I would not be very Mar 11 19:48:52 clear with, I look forward to you all for support :) Mar 11 19:51:05 okay Mar 11 19:51:10 how much do you know about the PRU? Mar 11 19:51:37 (yes some questions may be redundant) Mar 11 19:59:57 When I drafted the idea, I had read through the documentation sufficiently enough to recognize what parts I would need for my project (the PRU GPI R31). I have also currently been able to go through an example PRU firmware that does GPIO data acquisition from the PRU, and tested the C application on actual hardware. I am yet to understand the mechanism of Mar 11 19:59:57 data transfer between the PRU and userspace application (this is a crucial part), and choose the best/most efficient way in this. I am currently going through the documentation and understand its working, the instruction set and communication Mar 11 20:00:52 i.e. interface with the rest of the SoC Mar 11 20:06:38 okay Mar 11 20:06:51 this is my thoughts on it then - Mar 11 20:07:40 what about focus on getting the PRU firmware to work but provide at minimal UI. If sigrok is easier, go witht hat other wise, nodejs or some other thing Mar 11 20:07:46 you will need something to test with Mar 11 20:08:01 libsigrok should give you a GUI and a ncurses one to go with Mar 11 20:08:07 but it may be more work Mar 11 20:08:22 if time allows, polish the UI side Mar 11 20:08:36 I personally liked a web-based interface, it would make this LA design stand out Mar 11 20:08:40 but keep in mind - I am a bit biased... my focus is normally non UI centric Mar 11 20:09:12 I agree but you have limited time Mar 11 20:09:21 the PRU is still partially a wild west Mar 11 20:09:33 I just found: http://www.edaplayground.com/w/ Mar 11 20:09:37 indeed Mar 11 20:09:38 did you see pantos comments yesterday about possible arbitration issues? Mar 11 20:09:58 blah...login Mar 11 20:11:23 our interface could be something like that Mar 11 20:11:53 how are you thinking of splitting time between the 2 parts? Mar 11 20:12:26 as of now I was considering 60 (PRU) : 40 (UI) Mar 11 20:12:40 and how are you breaking up the PRU tasks? Mar 11 20:13:00 btw - did you manage to talk to anyone else on this idea? esp the UI part? Mar 11 20:13:36 we did have an initial discussion with jkridner as far as I can remember Mar 11 20:14:28 He mentioned something like some engineers at TI could be able to assist, though this is usually paid work. Mar 11 20:15:00 I guess he's offline right now Mar 11 20:15:53 Abhishek_: what about potential mentors? Mar 11 20:16:07 helping with the UI side is a bit out of my normal stuff Mar 11 20:17:25 I would like to have mranostay as one of my mentors, he has also contributed to libsigrok, and has had experience programming the PRU. Mar 11 20:18:52 mentor assignment are not fixed til the official acceptance date Mar 11 20:19:13 so it is good to talk to as many potential mentors who may be interseted as possible Mar 11 20:19:35 each of us has areas and there might be other projects that need help in Mar 11 20:19:57 but do break up the PRU into manageable chunks Mar 11 20:19:57 yeah, I understand Mar 11 20:20:07 something you canshow progress each week (or more often) Mar 11 20:21:36 are more mentors expected on IRC? Mar 11 20:21:44 we are in and out Mar 11 20:21:47 we have days jobs :) Mar 11 20:22:12 part of the problem is some of them are just getting back...there were trade shows, etc in Europe last few weeks Mar 11 20:22:33 day jobs are pesky Mar 11 20:23:51 I am still ~3 years from a day job. Mar 11 20:24:48 heheh Mar 11 20:24:57 mranostay: prehaps a night job is in order ;) Mar 11 20:29:42 I had mailed Laine, is he available? I am still awaiting a reply from him. Mar 11 20:30:30 donno Laine Mar 11 20:30:59 Laine Walker-Avina, from the Ideas page Mar 11 20:33:01 donno that person Mar 11 20:33:16 okay Mar 11 20:35:34 I hope you have checked the link, this could be a possible interface we can try and emulate for the front-end Mar 11 20:38:33 can't... it wants a login... not goingto do that Mar 11 20:38:54 may I send you a screenshot? Mar 11 20:41:00 ok Mar 11 20:41:19 Here we go: http://s22.postimg.org/g1o96clb3/Capture.png Mar 11 20:43:32 looks fine to me... donno a good way to implement though Mar 11 20:43:43 they seem to SVG for the graphics Mar 11 20:45:27 and jQuery (UI and uploads), bootstrap Mar 11 20:45:35 ewwwwww jquery Mar 11 20:45:48 svg, IIRC is browser specific Mar 11 20:49:43 On both Chrome and Firefox, it uses SVG to render the waveform Mar 11 20:50:08 I would however love it to have "drag-and-scroll" capability which it does not have as of now. Mar 11 20:50:39 I have to click the fwd and back buttons to go through the complete waveforn Mar 11 20:50:45 *waveform Mar 11 20:52:38 The draft proposal would be ready by this weekend, after I run a few experiments and read more on the PRU, to determine how much time I would need to dedicate to that part for my project. Mar 11 20:53:46 'k Mar 11 20:55:35 Abhishek_: have you tried the dso nano ? Mar 11 20:55:58 I am aware of it, haven't tried. Mar 11 20:57:20 try giving it a shot. it's got a pretty decent ui for a non-touch screen. would definitely use something like that with beagle Mar 11 20:57:59 However, I did have plans to port it to the STM32 F4 and extend it further. I currently have a F4D and a LCD up and running, and have used it for quite long.. Mar 11 20:58:44 In case you would like to have a look: http://www.theembeddedkitchen.net/stm32/an-expansion-board-for-the-stm32f4discovery/ Mar 11 21:00:47 * anujdeshpande looks **** BEGIN LOGGING AT Tue Mar 11 21:09:00 2014 Mar 11 21:26:27 Too bad that they have almost taken the F4Discovery out of production now, it's NRND. It has been a very capable board, the F429 Discovery board is even better in terms of hardware, it even has a 8 MB SDRAM and LCD on-board. Mar 11 21:27:16 okay, G'night all Mar 11 21:27:28 *night Mar 11 22:41:58 ds2: do you know if until now there are any candidates for the multi-platform boot project? Mar 12 02:26:27 morning Mar 12 02:28:54 hello! Mar 12 02:43:50 Morning :) **** ENDING LOGGING AT Wed Mar 12 02:59:58 2014