**** BEGIN LOGGING AT Tue Jul 12 02:59:58 2016 Jul 12 15:22:25 alexhiam, There? Jul 12 15:25:13 mdp, are you free right now? Jul 12 16:01:25 Abhishek_: ds2 alexhiam : any idea how to use the MVI instruction in PRUs ? Jul 12 16:59:14 ZeekHuge: what's your question about it? You trying to read code in an example, or thinking about using it yourself instead of MOV? Jul 12 17:00:14 Wormo: Hi ! trying to use it instead of MOV .. This is basically to resolve issue #1 Jul 12 17:00:38 Actually I tried to use some extra code to resolve that Jul 12 17:00:54 but the total size of the code exceeds the limit Jul 12 17:01:13 and therefore .. I had to go through the manual again . Jul 12 17:01:38 I think the MVI instruction can reduce the size of SAMPLE_CYCLE_8 macro to a lot extent ... Jul 12 17:02:06 ok I'll take a look at that Jul 12 17:02:16 and then we will have space to add code and then resolve the issue. Jul 12 17:03:01 looking at the TI wiki it's a little disappointing, the autodec/inc stuff is said not to be implemented :( Jul 12 17:03:21 http://processors.wiki.ti.com/index.php/PRU_Assembly_Instructions#Move_Register_File_Indirect_.28MVIx.29 Jul 12 17:03:39 "The only forms of the instruction supported in this environment are the following: " Jul 12 17:34:54 Wormo: I think thats for V1.. AM335x uses V3 and it probably has full support .. isnt it ? http://processors.wiki.ti.com/index.php/PRU_Assembly_Instructions#PRU_Core_Revision Jul 12 17:36:18 ZeekHuge: that's good. You got a handy link to abishek's code? I would think he probably used it in that case. Jul 12 17:36:33 nope .. he hasnt .. Jul 12 17:36:43 I already searched it for .. Jul 12 17:36:48 oh ok Jul 12 17:37:08 https://github.com/abhishek-kakkar/BeagleLogic/tree/master/beaglelogic-firmware Jul 12 17:46:46 so you were thinking of using MVI in pru1? I think it's meant for transfers to memory, that would be pru0 Jul 12 17:47:13 to/from memory Jul 12 17:48:23 hm looks like there is a separate command for that, which is what abishek used, SBBO Jul 12 17:48:43 I guess MVI would be more memory-to-memory Jul 12 17:50:38 m_w There> Jul 12 17:50:41 * ? Jul 12 17:53:26 yes Jul 12 17:53:51 ZeekHuge: my strategy for balancing the duty cycle would be to separate the 2nd clock toggle from TAKE_SAMPLE_8 Jul 12 17:56:07 Wormo: https://drive.google.com/file/d/0BwwIRlF3oxJfNDJhZGVyWHdhekU/view?usp=sharing Jul 12 17:56:19 Hey m_w , I just stumbled upon this:https://github.com/torvalds/linux/blob/master/drivers/spi/spi-bitbang.c Jul 12 17:56:37 So do you think I can build my spi code something like this? Jul 12 17:57:05 Wormo: section 5.3.4.2.3 Jul 12 17:57:23 Yeah thats the plan ... let me push the code ... just a sec.. Jul 12 17:57:38 ok good Jul 12 17:58:08 chanakya_vc: you can use it as a reference but we are trying to offload from the main processor Jul 12 17:58:37 that driver will heavily load the main processor Jul 12 17:58:42 Yes m_w , but these are essentially the functions that I need to call right? Jul 12 17:59:03 essentially Jul 12 17:59:29 there are a few way to implement SPI controller drivers Jul 12 17:59:57 Actually to be honest, I havenot found any place where they give the entire structure of the driver(like in the case of a char driver) Jul 12 18:00:02 Ohh m_w Jul 12 18:01:13 Wormo: So... https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/firmware/main_pru1_def.asm#L72 ; this THE_DELAY macro will replace all other delay macros ... and it will be like STARTLOOP ----- CLK_UP --> THE_DELAY --> SAMPLE --> THE_DELAY --> CLK_DWN --> THE_DELAY --- ENDLOOP Jul 12 18:01:44 And special thing about THE_DELAY is that the least delay it can have is 1 cycle. Jul 12 18:01:45 _transfer_one vs _transfer_one_message Jul 12 18:02:25 _transfer_one allows for easier use of GPIO chip selects Jul 12 18:02:35 as it is built into the core Jul 12 18:02:38 So LOOPSTART ------- CLK_UP --- 1 cycle delay --- SAMPLE ---- 1 cycle delay ---CLK_UP ---- 1 cycles delay ------ENDLOOP Jul 12 18:03:07 **that second CLK_UP is actually CLK_DWN Jul 12 18:03:50 and each delay is configurable without loss of achievable highest sampling frequency Jul 12 18:03:52 isn't there a CHECK_INT in the second half in place of the SAMPLE ? Jul 12 18:04:59 LOOPSTART -- CLK_UP -- delay -- SAMPLE -- CLK_DOWN -- delay -- CHECK_INT ? Jul 12 18:05:12 m_w, Also in the link that I sent above, it calls on EXPORT_SYMBOL_GPL() after every function, I don't understnd it's purpose. Jul 12 18:05:47 chanakya_vc: means only GPL modules allowed to call it license-wise Jul 12 18:06:07 as opposed to vendor binary blob modules Jul 12 18:06:40 ahh .. actually after sampling of 44bytes, we need to send it to the PRU0 ... after the last sample we take, this sending process will take atleast 2 cycles. now, after sending we need to get back in the loop, so a jump statement , which is again another cycle. and only then we can take the next sample Jul 12 18:06:54 Ohh so it will only work it the modules calling the function are themselves GPL right Wormo ? Jul 12 18:07:01 yes Jul 12 18:07:49 So ... to keep this gap consistent .. we need a delay of about 3 cycles between all other sampling processes, even if we just waste it. Jul 12 18:08:17 So in earlier versions ... there was no check_int, but only a delay of 3 cycles. Jul 12 18:08:40 check_int is actually using one cycle that was getting used for nothing. Jul 12 18:09:04 and what remains is a delay of 2 cycles Jul 12 18:09:38 this code.. as of now... can sample at about 28MHz Jul 12 18:09:47 chanakya_vc: they are exporting the symbols to be used in other drivers Jul 12 18:10:19 ZeekHuge: so where in this plan would MVI fit in to improve it? Jul 12 18:10:41 chanakya_vc: as you can see from the comments it is a set of utilities not an actual driver Jul 12 18:12:20 hmmn, m_w And I was happy thinking I got the entire code structure at one place :( Jul 12 18:13:29 There are so many examples for slave drivers and almost none for master. Jul 12 18:13:58 basically ... that SAMPLE_CYCLE_8 macro is too long. That is because we are using TAKE_SAMPLE_8 macro 44 times to save data into 44 different locations. What MVI does is, we can just save the address of the 1st register in it and keep it in a loop, incrementing this pointer. So MVI has this support of writing to a pointer pointing to the register file. Jul 12 18:14:16 this way we can use a loop ... to decrease the number of instructions Jul 12 18:14:25 and save code space Jul 12 18:14:56 chanakya_vc: there is a whole directory full of SPI master driver to reference Jul 12 18:15:22 MOV can write only to a Register . MVI can write to a pointer pointing to the one of the registers Jul 12 18:16:00 chanakya_vc: https://www.kernel.org/doc/Documentation/spi/spi-summary Jul 12 18:16:26 the methods are explained here ^^ Jul 12 18:16:35 under SPI MASTER METHODS Jul 12 18:31:53 ZeekHuge guess you can use mvi up till the last sample, where register address needs to wrap? Jul 12 18:34:27 yeah .. but using the instruction, the assembler gives the error 'Invalid instruction' Jul 12 18:34:40 Even when i am using it simply with registers Jul 12 18:34:45 MVI R0, R1 Jul 12 18:36:15 or MVIB/D/W R0, R1 Jul 12 18:37:30 Wormo: even this says that the instruction is supported : http://downloads.ti.com/codegen/esd/cgt_public_sw/PRU/2.1.2/readme.txt Jul 12 18:37:38 the Assembler section Jul 12 18:38:18 yes I was just seeing that in my local PRU_CGT area Jul 12 18:43:40 ZeekHuge: it won't even accept the example in the PRU reference guide Jul 12 18:45:29 Wormo: PRU reference guide ? the one at github/jadonk ? Jul 12 18:45:53 The one you linked to above Jul 12 18:46:16 oh .. okay. Jul 12 18:46:28 section 5.3.4.3.18 Jul 12 18:46:38 no it wont. Jul 12 18:47:29 could be a toolchain bug, maybe av500 or jkridner will recommend somebody to talk to about clpru Jul 12 18:47:41 wait a sec .. Jul 12 18:50:15 I have to head out, but if whatever you're trying doesn't pan out, should send an email & move back to driver side or something Jul 12 18:50:30 It worked Jul 12 18:50:30 don't beat your head too much against a possible toolchain bug Jul 12 18:50:33 ah! Jul 12 18:50:37 What syntax? Jul 12 18:51:00 MVIB R9, *R1.b0 Jul 12 18:51:18 the ponter just works with R1 Jul 12 18:51:42 it seems atleast one pointer is required Jul 12 18:51:59 compiling it with both registers isnt doing Jul 12 18:53:00 and ... some more points that i dont understand.. but its working in some cases and not working in other .. so probably some experimenting with it. Jul 12 18:53:19 I waste lot of time on some stupid stuff :( Jul 12 18:53:30 huh specifically R1 Jul 12 18:53:31 anyway .... its working now ! ... somewhat Jul 12 18:54:12 Thanks Wormo ;) Jul 12 18:54:26 you are magic ... as nerdboy said earlier ;) Jul 12 18:54:35 nope nope! Jul 12 18:54:54 but good job, carry on Jul 12 18:55:07 * Wormo is "away" Jul 12 18:55:11 so its somewhat confusing .. and need to play hit and try with it. Jul 12 18:55:32 R1 seems to be critical for that purpose Jul 12 18:55:36 *trial Jul 12 18:55:40 yes Jul 12 18:55:58 Note that register pointer registers are restricted to r1.b0, r1.b1, r1.b2, and r1.b3 Jul 12 18:56:07 thats what the reference guide says Jul 12 18:56:53 Why does this happen ? things become visible when we already know that and invisible when we keep searching for a hint .... Jul 12 21:01:18 ZeekHuge: So now that you have figured out how to use MVI, how would you use it to your advantage? **** ENDING LOGGING AT Wed Jul 13 02:59:58 2016