**** BEGIN LOGGING AT Fri Aug 12 02:59:58 2016 Aug 12 11:47:56 alexhiam, jkridner could you check mailing list? Aug 12 13:52:52 bradfa, There? Aug 12 14:05:13 chanakya_vc: hi Aug 12 14:06:14 hey bradfa I am done with i2c, pushed the code for the driver and firmware. Aug 12 14:07:20 chanakya_vc: ok, good Aug 12 14:07:22 I am going to be pushing code for multibyte transfer of spi in about half an hour Aug 12 14:07:26 chanakya_vc: ok good Aug 12 14:08:43 bradfa, The code for i2c is compiling and working as far I have tested. Aug 12 14:09:17 Just one question where should I document the project? On the elinux page? Aug 12 14:09:59 chanakya_vc: you can start documenting in your github repo wiki Aug 12 14:10:21 chanakya_vc: you may have to enable the wiki first: https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki Aug 12 14:10:45 Okay bradfa I will do that. I will finish this too before monday. Aug 12 14:10:52 chanakya_vc: excellent! :) Aug 12 14:11:36 chanakya_vc: for documentation, if you could include a set of exact steps on how to take the code you have created and to compile it and load it onto a bbb and then how to wire up a logic analyzer or scope to observe the output, that will be very helpful for others who want to try out your code and use it in the future Aug 12 14:11:55 Yes bradfa I will do that. Aug 12 14:12:01 chanakya_vc: but also please include in the docs information on how the firmware and driver interact, having some diagrams will likely be helpful here Aug 12 14:12:18 Okay. Aug 12 14:14:09 chanakya_vc: thank you for working to catch back up for the past week or two, I appreciate it :) Aug 12 14:14:21 I just want to apologise once again for the delay that happened in my work bradfa . I had not really not anticipated that the spi would take me so much time to get it to work Aug 12 14:15:09 Thank you bradfa . I really did not wish to disappoint any of my mentors Aug 12 14:16:01 : ) Aug 12 14:16:36 * chanakya_vc goes afk for some time Aug 12 15:51:05 m_w, I have a doubt. I am working on the multibyte transfer now. And I thought that I could simply run a for loop until i< t->len. Aug 12 15:51:47 I am not able to figure out a way to read the first 8 bits of the buffer. Aug 12 15:52:06 and then continue reading one byte at a time after that. Aug 12 15:53:21 for msb first transfer. I mean this would be the easiest way to do it. Minimum modifications to the firmware if I could just figure out a way to read the buffer a byte at a time Aug 12 15:55:35 SPI? Aug 12 15:56:42 Yup. I just clicked on an idea, hear me out. Aug 12 15:56:45 m_w, Aug 12 15:58:01 So first I will declare a int mask =2^len +2^len-1....+2^len-8 Aug 12 15:59:24 Then for MSB, what I can do is do an and with this number. This will give me the first 8 bits of the buffer. .then shift the buffer by len -8 Aug 12 16:00:06 this will be a 8 bit number. equate it to a uint8_t variable and write to the firmware Aug 12 16:01:20 then after that for the second byte in the loop first shift the contents of the buffer left by 8. do and with this number and then again shift right by len-16 Aug 12 16:01:38 this would give me the second byte in the buffer Aug 12 16:01:45 and continue this process Aug 12 16:02:29 What do you think m_w ? Aug 12 16:02:50 sounds a bit complicated Aug 12 16:03:01 Yep :( Aug 12 16:03:06 is the loop in firmware or the driver? Aug 12 16:03:11 driver Aug 12 16:03:34 Because I am limited by iowrite in the driver Aug 12 16:03:42 I would put the loop in the firmware Aug 12 16:03:58 I need to know the size of the buffer before I can write it by the driver Aug 12 16:04:29 I mean I have to use a variant of iowrite8 or iowrite16 or iowrite32 Aug 12 16:04:54 just set a maximum buffer size and allocate a section that big in shared memory Aug 12 16:05:03 So I need to know the size. Moreover I don't think, iowrite64 or anything higher exists Aug 12 16:05:38 use an array in shared memory Aug 12 16:05:59 how big is the shared memory? Aug 12 16:06:46 Ah I am not exactly sure. Would have to check Aug 12 16:07:34 so the I2C is done? Aug 12 16:08:25 yup Aug 12 16:08:38 how did you test it? Aug 12 16:10:32 Ah I have not really run a device test. So what it sent to bitbang, I looped it back to the driver Aug 12 16:10:44 and just checked the contents Aug 12 16:10:50 so no I haven't Aug 12 16:11:09 I would need your help with that too Aug 12 16:11:14 okay Aug 12 16:11:50 Ah first this multibyte transfer thing. Aug 12 16:14:44 sure Aug 12 16:17:06 m_w, Going to have dinner. Be back in a while Aug 12 16:17:58 okay enjoy Aug 12 17:25:40 m_w, I am back. Let me try what I am thinking. If it doesn't work, I will go your way. Aug 12 17:26:17 sure Aug 12 17:48:07 m_w, One problem, is that tx_buf is const. so I am storing it in a non const buffer and then performing all the actions. Will that be an issue? It is compiling with a warning though Aug 12 17:49:07 you tried casting the type? Aug 12 17:50:39 Ah no. I don't really have an idea what casting is. Would have to search. Aug 12 17:50:58 * chanakya-vc needs to take basic C lessons Aug 12 19:09:47 m_w, I have pushed the code for the multibyte transfer. Please do check it...I think this will work Aug 12 19:10:37 Casting is such a nice thing. Solved a lot of my problems :P I just hope that the logic works. Aug 12 19:11:22 If this works, we could in principle transfer a message of any length we would want. Aug 12 19:13:41 try running it on the target and see if it causes any issues at runtime Aug 12 19:16:09 https://github.com/chanakya-vc/PRU-I2C_SPI_master/blob/wip_on_spi/SPI_Driver/pru0_spi-subsystem.c#L104 Aug 12 19:16:41 this for loop can be done with a single assignment Aug 12 19:17:14 Okay, how m_w ? Aug 12 19:17:33 Is is causing runtime issues? :( Aug 12 19:17:44 I cannot run it Aug 12 19:17:52 I am on windows today Aug 12 19:18:26 Ohh.. Aug 12 19:19:12 I will try to run it. Ah but whenever you are back to Linux, please do give it a try m_w . Aug 12 19:19:12 mask_msb = 0xff << (len-7); Aug 12 19:19:37 this limits the length greatly btw Aug 12 19:20:21 How so m_w ? The void pointer can point to a memory of any length I presume? Aug 12 19:20:22 not sure I understand what you are doing Aug 12 19:20:50 unsigned int is 32bits Aug 12 19:21:30 Ohh, but then the buffers that spi_transfer provides me is itself a void type Aug 12 19:22:22 So in a given transaction ,I cannot pass a message longer than 32 bits then I guess Aug 12 19:23:47 Basically the mask_msb sifts out 8 bits of data at a time starting from the msb Aug 12 19:25:15 So it doesn't matter what size the buffers are or how many bytes are to be transferred Aug 12 19:26:05 and mask_lsb does the same for lsb transfer, sifting out data starting from the lsb. Aug 12 19:40:53 m_w, Ah I am not able to understand the left shift by len-7? I think it should be len-8 Aug 12 19:42:52 Because say in a 16 bit number , the msb of 0xff would initially occupy the 8 position(assuming starting is 1),so I guess it needs to be shifted 8 times in order to reach 16? m_w Aug 12 19:43:42 I have gotten all mixed up now in the bit shifting now :P Aug 12 19:44:16 the for statement went from 0 to 7 Aug 12 19:46:05 ohh sorry m_w . My mistake Aug 12 19:46:27 I should have been careful Aug 12 19:48:04 just verify that it is doing what you expected Aug 12 19:48:48 okay I have to get going Aug 12 19:49:04 bringing the family to the water park soon Aug 12 19:49:42 Okay m_w . I will do that. Will you be online tomorrow? Aug 12 19:50:40 yes Aug 12 19:50:53 Okay m_w . Have fun ! : ) Aug 12 19:50:54 I will try to be online as much as possible to help out Aug 12 19:51:04 crunch time Aug 12 19:55:03 bradfa, I have pushed the code for multibyte transfer. I will test it out now by perhaps looping back mosi to miso Aug 12 19:55:16 It should work. Aug 12 19:56:18 chanakya-vc: ok, sounds good. I won't be able to test this weekend, family is coming into town, but I'll catch up with you on monday Aug 12 19:57:12 Okay np bradfa . I will hopefully complete the project by Monday or by Tuesday. Aug 12 19:57:30 I will also start working on the documentation side by side **** ENDING LOGGING AT Sat Aug 13 02:59:59 2016