**** BEGIN LOGGING AT Thu Mar 12 02:59:58 2015 **** BEGIN LOGGING AT Thu Mar 12 05:04:06 2015 Mar 12 05:36:50 alexanderhiam: there ? Mar 12 06:41:01 sidbh: there ? Mar 12 07:16:51 sidbh: I just want to make sure that I am going in righ direction. For ADC, when the sampled data is stored in the fifo buffer, An interrupt is triggered. To service this interrupt from PRU, interrupt service routine has to be enabled inside the PRU. So for this PRU interrupt controller has to be configured to service it.. right ?? **** BEGIN LOGGING AT Thu Mar 12 07:26:10 2015 Mar 12 08:20:50 * mr_science up late in the hotal Mar 12 08:21:00 *hotel even Mar 12 08:21:34 _av500_: sorry i was absent so long... Mar 12 08:22:34 * mr_science signed his crew up for too many conferences and other volunteer commitments... Mar 12 08:23:05 np Mar 12 08:30:09 hi Mar 12 08:31:28 one more day tomorrow Mar 12 08:34:13 is this channel for students or mentors? Mar 12 08:36:21 both Mar 12 08:40:23 _av500_: i'll try to check in tomorrow, but it's a full day of talks Mar 12 08:40:46 if not, i'll be home late tomorrow night Mar 12 09:58:25 hello nerdboy: I am interested for Orbital Imaging Cubesat project Mar 12 09:58:44 can I know how to go further for the same Mar 12 10:22:52 can anyone help for the same? Mar 12 10:44:23 vvu: Resolved the issue. Mar 12 10:54:47 nerdboy: ping Mar 12 10:57:25 praveendath92: goodie Mar 12 10:58:29 I changed the down semaphore call to trylock and interruptible. Mar 12 10:58:46 yes, that is what i was thinking :) Mar 12 10:59:30 https://github.com/praveendath92/usctp/commit/bdf4c6b7a21bc48fade8e33cb8ff81ea74515c74#diff-a5b66807f4c76650f0f0b50697a415b3L20 Mar 12 11:00:02 makes sense Mar 12 11:00:33 Error propagation has to be implemented because of these changes. Mar 12 11:00:54 how to service an interrupt in pru interrupt controller ? Mar 12 11:02:39 Got to go. Ciao later. Mar 12 11:02:55 have phun Mar 12 12:21:25 alexanderhiam: ping Mar 12 13:24:51 gm !! Mar 12 13:32:58 Abhishek_: Can please you verify my proposal ? Mar 12 14:26:56 The ideas mentioned on the ideas page ( http://elinux.org/BeagleBoard/GSoC/Ideas ) , are they all active for GSoC 2015 ? Mar 12 14:28:09 Specifically, the one that involves controlling of stepper motors for 3D printers using PRUs ? Mar 12 15:35:40 It would be really helpful if any one could answer that... Mar 12 16:36:27 kiran4399: link? Mar 12 16:46:14 #join risc-os Mar 12 16:55:11 Abhishek__:there ? Mar 12 16:56:26 kiran4399: the proposal looks like a good start. Why create a new IDE from scratch though?? Wouldn't it make more sense to use Cloud9, which already ships on the boards? Mar 12 16:57:50 kiran4399: also, it would be great if you could post the link to your proposal draft on the ml so everyone can give you feedback Mar 12 16:58:12 alexanderhiam: Well, That looks like a great idea to integrate with c9. I will modify it. Mar 12 16:58:45 alexanderhiam: But won't I face any problem if I make it public on ml ? Mar 12 16:59:18 what kind of problem? Mar 12 17:00:38 Everybody (even the students) can view it. I don't know... I am just guessing. Mar 12 17:03:15 alexanderhiam: But if you think that there is no much problem... I will do it.. Mar 12 17:03:28 I wouldn't worry about it, it'll have your name and a date attached, and if students are stealing other people's work on their proposals we'll likely notice it anyway. Maybe other mentors can weigh in the the subject... Mar 12 17:04:11 alexanderhiam: Alright then. I will do it. Mar 12 17:04:58 https://gist.github.com/Apaar/c21f0e7b438df51f1cd2 : i am constantly getting this error when i try to compile any firmware file(have also tried reinstalling the pru c compiler)...this error has started since i updated to bone70(i have compiled firmware files on bone47) . Could someone please help me out :) Mar 12 17:05:23 alexanderhiam: Please go ahead and tell me some more things you would like me to change in the proposal. Mar 12 17:08:46 kiran4399: when you say firmata, do you actually mean the firmata protocol specifically? Or do you just mean a remote cpu command format in general? Mar 12 17:10:04 alexanderhiam: well, It is not exactly firmata protocol.. It is something like https://github.com/ecto/duino/blob/master/src/du.ino for arduino .. Mar 12 17:11:12 kiran4399: you should make that clear then, as firmata refers to this: https://github.com/firmata/protocol Mar 12 17:11:31 alexanderhiam: OK.. point taken !! Mar 12 17:11:42 alexanderhiam: next .. Mar 12 17:14:01 I don't really get the benefit of building a new layer on top of pruspeak is... it already has its own tcp server that you can send commands to from userspace programs Mar 12 17:15:24 alexanderhiam: like this one https://github.com/Apaar/Firmata-Interface :)...also could you please help me out with the issue i mentioned above Mar 12 17:15:48 alexander : i am able to toggle gpio pins other than those tied to _R30 from the pru by accessing gpio module registers. working on adding it to pruspeak now. Mar 12 17:16:02 alexanderhiam: i am able to toggle gpio pins other than those tied to _R30 from the pru by accessing gpio module registers. working on adding it to pruspeak now. Mar 12 17:17:02 shubhangi: awesome. Are you reading/writing the registers directly, or are you using a library for it? Mar 12 17:17:11 alexanderhiam: directly Mar 12 17:17:27 alexanderhiam: address from the am335x manual Mar 12 17:17:54 lots more pins for pruspeak now :) Mar 12 17:18:39 shubhangi: cool, that's certainly the best way to learn how that stuff works. It does get more complicated for the other modules, so while it's good to know how they work as well, it'll be worth looking into other libraries that have already implemented it Mar 12 17:19:20 kiran4399: you're talking about another layer inside the pru firmware, right? Mar 12 17:19:33 alexanderhiam: i guess libpruio is the only other out there that does this thing Mar 12 17:19:51 shubhangi: and starterware Mar 12 17:20:07 alexanderhiam: ohk . will look into it Mar 12 17:20:43 shubhangi: I don't know enough about either to say one is a better choice Mar 12 17:21:30 alexanderhiam: i'll ask karki and abhishek Mar 12 17:22:04 shubhangi: you should evaluate both and see what you think is a better choice Mar 12 17:22:48 alexanderhiam: that would be better (y) Mar 12 17:24:02 alexanderhiam: are you talking about firmata ? Mar 12 17:24:29 kiran4399: this part: "firmata firmware has to be build on the pruspeak interpreter" Mar 12 17:24:58 pruspeak already implements remote commands, so what does the additional layer add to it? Mar 12 17:27:34 kiran4399: it looks to me like you'd have the PRU firmware do a lot of parsing, whereas it would probably be better to parse down to pruspeak commands/scripts in the python server and send those to pruspeak Mar 12 17:31:10 alexanderhiam: no, the python firmata only will do the parsing. firmata will be tied onto the userspace API. Let us say you want to run the function led.blink(13) on the c9 ide... The node interpreter will send that to the firmata via serial port.. then the python server will do the parsing. Mar 12 17:32:28 i am out, its late in my timezone..bye Mar 12 17:35:18 kiran4399: ok, the proposal makes it sounds like you'd parse to pruspeak commands in the pru fw Mar 12 17:38:42 alexanderhiam: Oh.. when I say building ontop of pruspeak interpreter does it mean building ontop of pru fw ? I mean is pruspeak interpreter mainly the firmware ? Mar 12 17:42:46 kiran4399: the pruspeak pru firmware is the interpreter, you definitely want to look through all the pruspeak source and make sure you fully understand it Mar 12 17:47:25 alexanderhiam: OK.. I read about the firmware.. it is stated that pru0 mainly communicates with the main-memory and takes the data, pushes to the shared DRAM in pru.. and pru1 does the main computations part. then why does pru0 have pru0_syscall.asm and pru0_firmware.c but pru1 has only pru1_firmware.c ? Mar 12 17:49:54 Because pru0 communicates with arm and sends upcalls/syscalls as interrupts. Mar 12 17:52:40 yes I got that.. But what is the main use of pru0_firmware.c ? Mar 12 17:55:57 kiran4399: have you read through pru0_firmware.c? Mar 12 17:56:09 pru0 is mainly handling downcalls and also returning values via shm(shared memory) Mar 12 17:56:42 pru0 is also doing the digital io Mar 12 17:56:52 pru1 is currently just soft pwm Mar 12 17:58:30 kiran4399: the pruspeak interpreter event loop runs in pru0: https://github.com/deepakkarki/pruspeak/blob/master/src/pru-firmware/pru0_firmware.c#L793 Mar 12 17:59:52 alexanderhiam: so if a Digtial IO command comes.. It won't go to pru1.. pru0 will only execute it.. right ? Mar 12 18:00:06 correct Mar 12 18:00:16 alexanderhiam: gotcha !! Mar 12 18:01:16 alexanderhiam: One more thing... what is the main use of the timer in the pru firmware ? Mar 12 18:02:07 kiran4399: timing ;) Mar 12 18:02:48 alexanderhiam: but for that pru does have a clock right .. Mar 12 18:03:32 yeah, that's the PRU's internal timer module Mar 12 18:05:01 alexanderhiam: so why not use that ? Mar 12 18:05:18 it is using that... Mar 12 18:11:54 hello is there any emulator available for BB? Mar 12 18:11:59 *BBB? Mar 12 18:12:20 does anyone know where I can find a running bonecard demos prototype? Mar 12 18:13:20 alexanderhiam: OK.. one last thing... Can you tell me something which my proposal lacked in ? I mean in which aspect would you want me to improve ? Mar 12 18:15:08 kiran4399: how about doing a Python library as well? Mar 12 18:15:46 alexanderhiam: for what ? Mar 12 18:16:21 equivalent to the node.js library Mar 12 18:18:46 kiran4399: oh, one thing to keep in mind is that single commands like digitalRead and digitalWrite are never going to be very useful this way since there is so much added latency with all the serializing and parsing, so it would be ideal to support completely custom scritps instead of just built-in ones like sweep and fade Mar 12 18:21:28 alexanderhiam: But even in custom scripts there will be latency right ?? Mar 12 18:22:50 the scripts are run inside the pruspeak event loop, so they're realtime and as fast as pruspeak can be Mar 12 18:28:42 alexanderhiam: so even in the case of fade... the whole script will be ran inside the pruspeak event loop. node.js interpreter will only write led.fade object id, function id and parameters onto the serial port. firmata will then catch the command and invoke the necessary script, plug-in the parameters and then run it inside the pruspeak's event loop. So there will not be any real-time latency problem right ? Am I missing some Mar 12 18:30:41 kiran4399: pruspeak doesn't currently store any scripts besides the currently running onw, as that's not part of the botspeak spec. So every time fade is called it would write out the whole script to the pru and then send the RUN command Mar 12 18:32:20 alexanderhiam: OK.. I got it !! So, what do you suggest me to do about these functions ? Mar 12 18:38:48 kiran4399: what functions? Mar 12 18:42:24 alexanderhiam: functions like sweep and fade Mar 12 18:44:50 hmmm quiet morning Mar 12 18:45:51 kiran4399: well, you tell me. There's at least a few ways they could be implemented at different levels, you should think it over and propose the way you think is best Mar 12 18:52:38 alexanderhiam: can we implement a pwm for fade ? Mar 12 18:52:54 alexanderhiam: hard pwm Mar 12 18:59:47 alexanderhiam: But anyway.. I will think about it and come up with a best one.. :-) Mar 12 19:04:41 kiran4399: that ought to work with any of the pwm outputs that pruspeak implements, hard or soft Mar 12 19:09:37 Is the project that aims at controlling stepper motors using PRUs open for gsoc 15 ? Mar 12 19:13:27 http://elinux.org/BeagleBoard/GSoC/Ideas Mar 12 19:13:37 As is on this page . Mar 12 19:14:24 If it is on that page, it is a valid topic. Topics not on the page are valid, too, if you want to propose one. Mar 12 19:15:37 Ok !! Thank you ! Mar 12 19:38:38 i am digging the ROS documentation to integrate bonescript with ROS Mar 12 19:39:06 but have no idea where I should modify it Mar 12 20:50:02 kiran4399: pong **** ENDING LOGGING AT Fri Mar 13 02:59:59 2015