**** BEGIN LOGGING AT Wed Jul 17 02:59:57 2019 Jul 17 05:17:04 zeekhuge: I got it to work; I am now able to use Host 0 for PRU0 to PRU1 interrupt i.e. using bit 30 of R31. Also, all the statements after start() don't seem to execute -https://github.com/pratimugale/PRUSS-Bindings/blob/f20a0483855e26302d9fbb2db07a8b9c23ab2db6/examples/firmware_examples/example7-stepper-control/PRU0/main_pru0.c#L43 Jul 17 05:17:51 So I set the bit 5 of R31 register from the assembly code itself to strobe the interrupt Jul 17 05:18:26 And I do get a proper message back after all pulses have been sent to the driver Jul 17 05:19:34 pratimugale: their is "halt" In your assembly code. If that gets invoked, the pru stops, and the start() method basically won't return. Hence nothing after that gets executed. Jul 17 05:19:45 You think that can be the problem? Jul 17 05:22:06 Yes, I think so, but even after using halt, I need to echo "stop" and then "start" into the sysfs entries. It directly cannot "start" again Jul 17 05:22:20 I'll try it without the halt statement now Jul 17 05:22:55 Yes. That's what i meant. Halt is not required in the assembly. Jul 17 05:23:15 Otherwise the "start()" Will never return. Jul 17 05:23:19 Got it Jul 17 05:24:41 Thanks for the help Jul 17 05:45:08 Well. Jul 17 05:51:40 zeekhuge: I tried removing the halt statement, but it doesn't work as I want, I'll debugging with an led Jul 17 06:57:41 zeekhuge: For now, I'm completing the rest of the things (like direction control), will get back at the proplem as soon as I complete it. Jul 17 07:01:12 pratimugale: okay. But before that, can you please state what exactly the problem is? After removing halt the "start" Was returning right? Then what's the problem now M Jul 17 07:01:14 ? Jul 17 07:04:14 zeekhuge: The memory was getting full "No space left on device". I don't know whether there's a problem in the program because the device space is actually quite full Jul 17 07:18:28 zeekhuge: On removing the halt statement, the motor runs infinitely, because it returns to "start" ; what I want is that the assembly code should exit and the c-code should continue thereafter Jul 17 07:20:56 The .asm file sends precise number of pulses to the driver to rotate the specified degrees by the user, and after sending those pulses, it should send out the interrupt Jul 17 07:21:33 This is irrelevent, sry Jul 17 07:26:56 Is there any way for the c-firmware (main_pru0.c) to continue its normal execution after calling the assembly code? I couldn't find anything in the assembly instructions guide Jul 17 08:19:49 pratimugale: Can you upload the compiled asm file generated (after linking both C and asm code) ? Jul 17 08:20:00 pastebinit or gist it up Jul 17 08:24:45 Sure Jul 17 08:53:04 zeekhuge: https://gist.github.com/pratimugale/920e3ccec31b6379834434510fa209f0 Jul 17 09:00:00 This is when there is nothing in stop: label. Jul 17 09:12:23 pratimugale: No ! Add interlist as well. Jul 17 09:12:37 when invoking clpru Jul 17 09:12:42 add --c_src_interlist Jul 17 09:14:09 Ok Jul 17 09:37:29 zeekhuge: c_src_interlist feature is being used https://github.com/pratimugale/PRUSS-Bindings/blob/06324c2778beaeb4c467b8a7ae1ca0ca9f7d227c/examples/firmware_examples/example7-stepper-control/PRU0/Makefile#L36 Jul 17 10:33:03 pratimugale: Try adding "JMP r3.w2" instruction at the end of your asm code Jul 17 10:35:12 zeekhuge: Will do, I'm making some changes in the driver lib rn; should be done in 10 mins Jul 17 10:36:59 pratimugale: https://github.com/ZeekHuge/BeagleScope/blob/master/docs/clpru_and_C_usage.notes#L145 Jul 17 10:44:39 pratimugale: Let me know if it works. Kinda curious. I haven't really tried it . Jul 17 10:45:30 zeekhuge: ok, will let you know Jul 17 11:15:58 pratimugale: ? Jul 17 11:16:06 did you try ? Jul 17 11:16:15 zeekhuge: I just did Jul 17 11:16:27 It again goes on infiitely Jul 17 11:16:57 the first command sent goes on *infinitely Jul 17 11:17:36 without interrupting Jul 17 11:25:52 pratimugale: C code is the same ? right ? https://github.com/pratimugale/PRUSS-Bindings/blob/sandbox/examples/firmware_examples/example7-stepper-control/PRU0/main_pru0.c Jul 17 11:26:29 And you used "JMP r3.w2" inside the "stop" macro ? https://github.com/pratimugale/PRUSS-Bindings/blob/sandbox/examples/firmware_examples/example7-stepper-control/PRU0/pulse-supply.asm Jul 17 11:27:13 wait Jul 17 11:27:16 you are changing the r3 ? Jul 17 11:27:20 https://github.com/pratimugale/PRUSS-Bindings/blob/sandbox/examples/firmware_examples/example7-stepper-control/PRU0/pulse-supply.asm#L23 Jul 17 11:27:29 and a lot many more places Jul 17 11:28:20 yes Jul 17 11:28:33 infact you are changing a lot more registers that are used by the compiler Jul 17 11:28:39 https://github.com/ZeekHuge/BeagleScope/blob/master/docs/clpru_and_C_usage.notes#L133 Jul 17 11:28:58 this is the complete list of regs one should not modify if want to use C/C++ with asm Jul 17 11:30:09 Okay, I think the list kind of reserves "all" the registers ? Jul 17 11:30:53 yes, which ones are not to be used? Jul 17 11:31:07 But I think you should be able to use the higher expression-registers. Jul 17 11:31:57 Use regs >5 and <15 Jul 17 11:32:09 Oh.. I see Jul 17 11:32:18 <14 Jul 17 11:32:27 5 and <15"> ok, will change the code accorgingly Jul 17 11:32:44 You will not need more than 9 regs. will you ? Jul 17 11:33:24 Nope Jul 17 11:33:39 5 to 14 is enough Jul 17 11:33:51 at the moment Jul 17 11:34:20 The JMP should once you have shifted your computation to 5-14 regs Jul 17 11:34:32 s/should/should work Jul 17 11:36:37 zeekhuge: So I think that right now entire assembly code starts executing again once it reaches the end of the file, because it even loads data from the memory address. I checked this by changing the data at that address offset Jul 17 11:37:05 *loads the data again which should be done only once Jul 17 11:37:57 I would think so. You can use one step and reg lookups to be certain. But I think, it would be easier to change the regs and then check if the code works. Jul 17 11:39:17 zeekhuge: Yes I will change the registers and check Jul 17 12:19:43 zeekhuge: First I'm finishing implementing all the functions for the driver, because setting R31.t5 works; but I will definitely change the registers after that Jul 17 14:29:59 pratimugale: Hope you are set now. Jul 17 14:30:39 I won't be able to make today's meeting but just wanted to make sure you're making progress, and it looks like you are. Jul 17 14:32:26 abhishek_: I have completed most part of it, and have implemented all the functionalities Jul 17 14:33:00 I am trying to make a demonstration video right now, should complete it before the meeting Jul 17 14:39:41 The updated code: https://github.com/pratimugale/PRUSS-Bindings/tree/sandbox/examples/firmware_examples/example7-stepper-control; some changes are required in driver_lib.cpp and the PRU0 registers need to be changed to use R5-R14 Jul 17 15:55:53 hello hendersa Jul 17 15:58:31 pranav_kumar[m]: Hello Pranav. This is the first chance that I've had to review your latest material, as I've been in crunch time at work for the past two weeks and really behind on everything. Jul 17 15:58:45 * hendersa glares at the 400 mails in his inbox. Jul 17 15:59:34 pranav_kumar[m]: I'll get back to you shortly. Jul 17 15:59:51 hendersa: i think you do most of your work through the mail only Jul 17 16:00:47 ok i am just sending you the last mail 🙂 Jul 17 16:31:39 Hi all Jul 17 16:31:54 vaishnav98_: sorry it took so long, but I finally chimed in on your discussion with Greg. Jul 17 16:31:58 I hope I added a bit of clarity. Jul 17 16:32:06 Hi everyone Jul 17 16:32:21 not sure if you've found a general way of adding platform data (or even simply added it for a few devices to see how it goes). Jul 17 16:32:30 howdy pratimugale Jul 17 16:32:48 I'll actually be sitting in front of a computer today and am not on the road! Jul 17 16:32:59 (travel again Friday :-( ) Jul 17 16:33:17 jkridner: Thanks a lot for looping in and replying Greg KH about what we're trying to achieve , I was just going through your mail Jul 17 16:33:53 mdp: it would be great if you could look at that e-mail thread on the greybys dev list as well. Jul 17 16:34:04 jkridner: Yes :) Jul 17 16:34:27 https://lists.linaro.org/pipermail/greybus-dev/2019-July/000804.html Jul 17 16:35:50 I think one confusing point still in your message is if Linux is running on the device side. With gbsim, I think the answer is yes, though I'm not 100% sure if it goes through the drivers or not. Jul 17 16:36:11 does gbsim use the BeagleBone peripheral hardware directly? Jul 17 16:37:32 I've been very confused by the device-tree configfs showing up on some system builds and not others. Jul 17 16:37:36 jkridner: I am able to pass some hardcoded additional platform data to greybus drivers but I am not able to pass it to the spi_new_device call I'll send the commit links for the gbsim and greybus changes now Jul 17 16:38:19 rcn-ee: You are trying to build dt overlay configfs support in, aren't you? Jul 17 16:39:46 mtg? Jul 17 16:39:57 I know cwicks is on travel today. Jul 17 16:40:11 currently gbsim routes all the SPI/I2C messages from the Greybus/virtual SPI to the actual SPI via ioctl calls , I'm not sure if it's best way to do this, but the same template was there in Greybus Simulator before me modifying it too Jul 17 16:40:28 lets make sure all students and at least 1 mentor are here. Jul 17 16:40:38 hi Jul 17 16:41:12 stick with what works. :-) Jul 17 16:41:34 k, I think that means vaishnav98_ pranav_kumar pratimugale and embden are all here. Jul 17 16:42:14 embden: any mentors around for you? Jul 17 16:42:37 jkridner: gbsim change: https://github.com/vaishnav98/gbsim/commit/70fa036b27ef890d234259394b1a6a0b901d01fc , greybus changes: https://github.com/vaishnav98/greybus/commit/59f6173450e8f4bbcb51e5658c5b86a888c5c55c , but this modification gives a kernel panic when loading a new SPI manifest Jul 17 16:43:08 julieng: are you here? Jul 17 16:43:19 hi jkridner Jul 17 16:43:36 Hi all sorry to be late Jul 17 16:43:41 julieng? Jul 17 16:43:54 jkridner: most of the time they are Jul 17 16:44:02 jkridner: Sure Jul 17 16:44:11 pranav_kumar: can you start out with any blockers? Jul 17 16:44:27 cwicks: no worries. know you are on travel today. Jul 17 16:44:45 Vaishnav98 go first? Jul 17 16:45:12 Sorry talked at same time Jul 17 16:45:23 here Jul 17 16:47:05 jkridner: yes , i dont have any blocker for now , I get back to my hostel after winning the hackathon . and for this point time i use to update my mentor on regular basis mostly through mail and try to update my github on regular basis. Jul 17 16:48:04 pranav_kumar[m]: did a status report update go out to the list? Jul 17 16:48:42 means i didnot understand Jul 17 16:49:38 ? Jul 17 16:50:48 i had updated the weekly report on the beagleboard-gsoc google group Jul 17 16:52:02 hmmmm Jul 17 16:52:37 sorry about that... it was Tue Jul 17 16:52:50 see it buried in a different pile of mail :( Jul 17 16:53:25 no problem ,as i was travelling that time so i got a bit late Jul 17 16:56:54 hi, driain . Can you comment on the ML discussion under the patch I proposed. Julien raised the question about the current situation with the existing setup. Jul 17 17:02:09 hmm... maybe riot is a bit slow? Jul 17 17:02:19 ????? Jul 17 17:02:32 driainjulieng : you around to address embden blockers? Jul 17 17:03:19 jkridner: Julien is active in xen ML now Jul 17 17:03:41 k Jul 17 17:03:52 embden: any other blockers to discuss? Jul 17 17:04:07 My status update: My main accomplishment was that I initiailized the crossbar to allow interrupts to go through it. So, the xen now responds to the commands. But this was a pretty naive implementation. Jul 17 17:04:08 The main blocker is probably to understand how to proceed further and how to do those things right. I think we will be able to find out this with mentors. Jul 17 17:04:43 oh, wait.... seems like none of jkridner1's messgages came through. Jul 17 17:05:05 i see msgs from jkridner1 Jul 17 17:05:32 jkridner: i see his message Jul 17 17:05:56 ds2, hendersa , abhishek_ : any additional updates needed from pranav_kumar ? confident he's on-track? Jul 17 17:06:10 jkridner: I am not able to see any messages from jkridner1 Jul 17 17:06:43 me neither Jul 17 17:06:51 jkridner: I can't see any messages from jkridner1 . I had the same issue with sitting from irc - messages from IRC didn't come through. Jul 17 17:06:53 I donno...still waiting to see results... I find it odd to have a level shifter in front of a 74hc part but that's just me Jul 17 17:07:39 pranav_kumar: it would be great if you could get consistent tab/space-width in your code: https://github.com/pranav083/pocket_beagle-work/blob/wip/pru_wip/74hc299_10_v1.p Jul 17 17:08:50 vaishnav98_: sizeof(*response.platform_data) uses a void * pointer, so the size would be invalid. Jul 17 17:09:27 * jkridner[m] would love to see miletones updated on https://elinux.org/BeagleBoard/GSoC/2019_Projects Jul 17 17:09:29 I go there to check the links to the weekly reports. Jul 17 17:09:49 as i was using eclipse so space are bit bifficult to handle . I try to the code consitent .Thanks for the Suggestion jkridner Jul 17 17:10:07 pranav_kumar: Whats the plan for next week ? Jul 17 17:10:09 * jkridner[m] watched https://www.youtube.com/watch?v=R3kSgY7nwpk earlier. Jul 17 17:10:25 jkridner: Will update the page Jul 17 17:10:25 though I didn't really understand what it was showing me. Jul 17 17:11:33 k, I think I got most of my messages out that were useful and didn't show up from jkridner1 Jul 17 17:11:35 * jkridner[m] restarts pidgin Jul 17 17:13:30 jkridner: okay, then how can the platform data be passed in a generic way? the platform data is supposed to be a void pointer by spi_board_info , can you point me to an example? most of the drivers I looked took the data directly from device tree and passed to the driver Jul 17 17:14:14 zeekhuge: doing serial in parallel out communication from one beaglebone and taking that as parallel input to other beaglebone to read the output as parallel in serial out to other beaglebone using shift register in middle of it. as suggested by hendersa in his mail and defining a set of control instruction for it .so , that it have a smoother flow of data Jul 17 17:14:55 vaishnav98_: well, for one, use sizeof on an object of the right type. Jul 17 17:15:26 vaishnav98_: I wasn't able to find in your code where the platform_data was allocated either. Jul 17 17:15:28 pranav_kumar: once you are done with the code-cleaning etc, we can discuss how to go about it. Jul 17 17:15:44 vaishnav98_: yes, you can add that as a milestone. Jul 17 17:17:26 jkridner: for this wouldn't we need the corresponding platform_data struct for the corresponding device(clickboard) included with the greybus-spi Jul 17 17:17:41 vaishnav98_: you've found articles like https://lwn.net/Articles/448499/, right? Jul 17 17:19:23 vaishnav98_: use the structure and size for the device type for which you are loading the driver. Jul 17 17:21:10 jkridner: currently I am sending a fixed platform data structure for an mmc_spi device : https://github.com/vaishnav98/gbsim/commit/70fa036b27ef890d234259394b1a6a0b901d01fc Jul 17 17:21:15 vaishnav98_: also, I think I (or we) might still be a bit confused on some aspects as I'd expect them to somehow be generic on the host-side where it seems they would be needed. Jul 17 17:21:25 jkridner: Thank you Jul 17 17:21:56 pratimugale: haven't heard much from you yet.... down to our last 10 minutes. Jul 17 17:22:00 pratimugale: any blockers? Jul 17 17:22:15 jkridner: I have seen it, I'll go through it again Jul 17 17:22:45 ds2: yes you are right about the level shifter thing as , if see from the data sheet it reduces the shift register capabality of transfrering data by 5 times and also the the shift register that i am using work at the speed of 50 MHz. So if level shifter is in btw the shift register and beaglebone . The max transfer speed that can be achived will be 10 MHz only(as refered the operating condition of from the Jul 17 17:22:46 datasheet of TXS0108E ) . Though, i will test it tomorrow on with my college DSO and frequency generator . The maximum speed that can be achieved by this level shifter TXS0108E that is widely available and i am using in this circuit. Jul 17 17:23:17 pratimugale: abhishek_ , zeekhuge around to help solve any blockers? Jul 17 17:23:26 jkridner: Posting my update for the week: Accomplishment: I was able to write PRU firmware and a userspace library for accurately controlling stepper motors: https://github.com/pratimugale/PRUSS-Bindings/tree/master/examples/firmware_examples/example7-stepper-control. Jul 17 17:23:49 jkridner: but this is done at the Greybus driver level, so when adding support for a new click wouldn't a modification need to be made there to include the corresponding structure there? Jul 17 17:23:50 * me neither Jul 17 17:24:01 Blockers: Wasn't able to exit assembly code (from PRU0) to send out an interrupt to PRU1; discussed this with zeekhuge; will implement his solution and update asap i.e using R5-R14 registers. Temporary solution is to strobe the interrupt using R31.t5 within the assembly code itself. Jul 17 17:24:01 Working on: Some rework is required in driver_lib.cpp, and the communication scheme and math needs to be Documented. Jul 17 17:24:16 pranav_kumar[m]: but why is it there at all? Jul 17 17:24:32 IIRC - 74HC should be able to handle 3.3V I/O directly Jul 17 17:24:59 pratimugale: cool! Jul 17 17:26:07 pratimugale: it would be a very cool alternative firmware on BeagleBone Blue, where 4 DC motor drivers are built-in. Jul 17 17:26:16 a sample 74hc299 (nexpedia flavor) puts the range from 2V-6V Jul 17 17:27:06 as shift register run at 5 v logic and beagle board support 3.3v logic .so, i have to make these modification for the sake of bi directional communication .Earlier i had used trasistor as a switching circuit. when i have to only do the one way communication Jul 17 17:27:11 jkridner: also I am a bit confused on how to proceed with provide a generic method for adding support for new clicks , should I proceed with Device Tree based method or should I try passing the platform data directly via manifests through Greybus Simulator Jul 17 17:27:33 pranav_kumar[m]: but why run the shift register at 5V? Jul 17 17:27:56 it isn't like it is a 74hct/74ls/74 etc part Jul 17 17:29:03 great, trying to go through BB Blue's specs Jul 17 17:29:53 reading the datasheet again to confirm ds2 Jul 17 17:29:57 jkridner zeekhuge College hours have started, so my working hours will probably change from evening till after midnight. Whenever possible, I will try to work during the day. The college load is less during the initial weeks Jul 17 17:30:10 vaishnav98_: help me better understand where the issue exists. these drivers without platform data exist on the "host" side before you get to greybus, right? shouldn't we be somehow exposing these gpio pins through greybus and using the same platform data each time? Jul 17 17:30:38 * jkridner[m] has call that just started. Jul 17 17:30:40 pratimugale: noted. Jul 17 17:30:41 * jkridner[m] waves Jul 17 17:32:16 if you really need 5V IO on the parallel side, put the levelshifter there....signals there are at least a factor of 8 slower Jul 17 17:32:59 zeekhuge jkridner Video of Working: https://www.youtube.com/watch?v=joPQ1JjVkvU UserSpace Program for it: https://gist.github.com/pratimugale/76e6b637896ac96093ae396efd5f020e Jul 17 17:33:00 I'm sorry if the video seems confusing, I made it in a hurry, will try to demonstrate it better in another video Jul 17 17:34:22 nice. Jul 17 17:37:55 jkridner : I'm not sure what you were asking, greybus currently provides ways to expose gpio pins through manifests, I have tried that as you suggested in a previous week, but I couldn't really understand how it could then be passed to the SPI/I2C device driver for the clickboard Jul 17 17:37:59 ds2: i will try and update the result on what the output i will get after removing the logic level converter. and the shift register that i am using is of CMOS logic CD54hc299 as the 74 series is little bit oudated and unavilable at many places .Though, i have that ic also . Jul 17 17:40:37 vaishnav98_[m]: that's where you need of_bus support so the driver can get that info Jul 17 17:41:44 pranav_kumar[m]: they should be functionally the same 54 has higher specs then the 74 series...but 54 series is likely to cost more Jul 17 17:42:44 ds2: thanks for pointing it out. As i go through the datasheet and it says that it can work on the logic that are provided by beaglebone black . Also it will make my circuit lot easier to make . Thanks for the suggestion . These changes i had made when i was using 74hc595 and implemented the same here. Jul 17 17:44:15 ds2: as the datasheet suggest 74 series of universal shift register can run at max freq of 70Mhz and 54 series run at max freq of 50Mhz Jul 17 17:44:25 pranav_kumar[m]: general rule - the HC family will run from a variety of voltages...the other members often prefer a strict 5V... in any case, the level shifters can be a bit touchy which may also be a reason for some of your issues Jul 17 17:44:48 ds2: But dont know why they cost more???? Jul 17 17:45:03 pranav_kumar[m]: I would not go above 20MHz if your real circuit is like yr diagram (with the plug in breadboards) Jul 17 17:45:32 ds2: I think that might be the case. Jul 17 17:45:49 mdp: Thanks a lot , I was a bit confused on which method to proceed with, also could you please guide me whether my understanding of adding of_bus struct to greybus is correct, Jul 17 17:46:09 pranav_kumar[m]: 54 series have a higher spec (works at higher temperatures and are often in ceramic cases). Both factors drive up the price. Cermaic packaging is more expensive then plastic packages Jul 17 17:46:57 ds2: hmmm , As thier would be interferance come from the lose wiring as in my case ,During using the breadboard. Am i right. Jul 17 17:47:04 ok Jul 17 17:48:07 pranav_kumar[m]: partially... loose wires and long wires along with a lot of stray capacitance and inductance means you can't go very fast Jul 17 17:48:24 plus your diagram show a funky ground wiring Jul 17 17:48:54 you have a thin wire going all the way to the far end then you form a star off that to distribute the ground Jul 17 17:48:58 unstable?? Jul 17 17:49:32 general rules with high speed stuff - short wires, generous ground planes. neither a doable with plug in breadboards Jul 17 17:49:59 neither are.... Jul 17 17:50:20 plus you don't have bypassing on the chips Jul 17 17:50:55 putting a 0.1uF cap across V+ and ground as close as possible to the chip is almost always required for anything of reasonable speed Jul 17 17:51:22 what do you mean by bypassing on chips Jul 17 17:51:40 ds2: ok i will do that Jul 17 17:51:54 but I am getting too far in to the EE stuff. GSoC is a SW program focus is on SW Jul 17 17:53:27 no things are making sense to me as i have the EE background as well. And making something robust need to good from both the sides. Jul 17 17:55:08 as these things i have to apply only once in my circuit and after that i will have to focus on the Software part only . So , thanks for your valuable suggestion. Jul 17 18:26:38 vaishnav98_[m]: what is the other method? Jul 17 18:31:58 mdp : I was able to pass some additional platform data to greybus through gbsim (greybus spi transfer response), could this be extended to pass the platform details to the corresponding driver Jul 17 21:16:15 ~.. Jul 17 21:16:17 .~. **** ENDING LOGGING AT Thu Jul 18 02:59:56 2019