**** BEGIN LOGGING AT Sat Mar 11 03:00:02 2017 Mar 11 05:19:38 whowas Mar 11 05:19:47 WHOWAS Mar 11 05:20:11 whois jj2baile Mar 11 06:17:07 what do you think about the smart traffic system in the mailing list? Mar 11 06:19:11 i want to improve it Mar 11 11:53:35 zeekhuge: Hey you did the BeagleScope project last year right? I’m interested in the Serial Terminal Server project in GSoC 2017 and am thinking about how to buffer I/O inputs. While reading your weekly reports I figured out that you already made it possible to write I/O data into a buffer. Mar 11 11:54:01 My goal is to let the PRUs handle all the I/O input so that no data is lost and to write the buffer from DDR to the sd card periodically with the help of the CPU Mar 11 11:55:04 So, do you think adapting your code to buffer UART data is a good idea? From my point of view, it should absolutely be possible although I have not looked into the codebase yet. Mar 11 11:55:32 Yeah ! Definitely ! That can be done .. Mar 11 11:56:02 And I dont think its going to he too difficult .. Mar 11 11:57:00 Though I am not up-to-date with the changes made after SoC. But we can look into it . Mar 11 12:01:20 Ok cool! Mar 11 12:02:23 Did I understand it correctly that you targeted SPI and I2C or did you some kind of generic I/O buffer which puts the input from an I/O pin into a buffer, no matter from which input I/O pin its coming from? Mar 11 12:09:33 ordsen: you taking about data from PRU to the CPU right ? Mar 11 12:21:49 Not exactly: PRU0 reads e.g. the SPI inputs and puts it into a small buffer. PRU1 then puts that one into DDR and interrupts the CPU when it is filled (that's what your code does how I understand it, please correct me if I'm wrong). Now the CPU can copy the content to the sd card. As the SPI is in fact just an I/O pin I am wondering if it will be possible to implement a generic solution which runs o Mar 11 12:21:49 n the PRU and does not care if it takes the input from the SPI or UART or any other I/O pin Mar 11 12:24:24 That way the code which performs the buffering could by used for any pin in further projects Mar 11 12:24:31 Oh yes. Its actually called RPMsg framework (representing Remote Processor Messaging) . Mar 11 12:24:32 And its used to exchange data between different (remote) processors on the same SoC. Mar 11 12:25:07 so , no matter from where the PRU gets the data. RPMsg will just be responsible to carry that data from PRUs to the CPU. Mar 11 12:25:46 so if you need data transfer from PRUs <---> A8 , it can be used. Mar 11 12:26:59 tokencolour: Hi ! sorry , didnt show up was stuck here. But glad you were able to boot the kernel .. Mar 11 12:28:28 Hey zeekhuge! That's okay. Thanks for the help all along. :) Mar 11 12:46:17 zeekhuge: Oh okay, thanks for clarifying! I will look into your code as soon as I can and come back here if I got any questions if that's okay Mar 11 12:47:34 Definitely. no problem ! Mar 11 12:51:30 I also thought of using DMA for I/O buffering, but it seems like people who tried this had a lot of issues with that attempt. Mar 11 12:55:28 Though, modifying the UART driver could be another option. But I need to inspect drivers more detailed before I can make any assumptions about how good this solution would be Mar 11 13:01:00 ordsen: well, I think .... you can just write a UART driver that would be a RPMsg client and get data from the PRUs but would expose itself as a UART device. Mar 11 13:02:48 as about DMA, its a project in itself .. and is on the ideas page. Not sure if all that (serial terminal server + DMA) would be possible in those 3 months. Mar 11 13:13:58 I guess I lack of some fundamental knowledge about drivers, so it's a bit hard for me to follow your thoughts. Mar 11 13:14:07 The UART driver runs on the A8, he is the RPMsg client. Mar 11 13:14:13 As such, he communicates with the PRU (which just knows about the RPMsg client, nothing about that its a UART driver). Mar 11 13:14:32 And from an application’s point of view it’s just an UART device. Did you mean that? Mar 11 13:15:18 That is correct . Mar 11 13:17:26 So you have USER SPACE <--> [UART device interface<>UART driver<>RPMsg client] <--> PRU <--> I/O pins used for UART Mar 11 13:17:43 exactly Mar 11 13:17:52 OK nice Mar 11 13:18:49 Its a IIO driver and a RPMsg client : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/beaglescope/beaglescope_driver.c Mar 11 13:20:34 and this is an example on how to use rpmsg APIs : https://github.com/ZeekHuge/BeagleScope/tree/port_to_4.4.12-ti-r31%2B/examples/kernel_examples/n-blinky Mar 11 13:24:01 Awesome, that will help me a lot! Mar 11 13:54:34 zeekhuge: OK that looks really promising, thank you. I'll be off for now, bye :) Mar 11 13:54:53 No problem. :) **** ENDING LOGGING AT Sun Mar 12 03:00:00 2017