**** BEGIN LOGGING AT Sat Apr 08 03:00:02 2017 Apr 08 14:38:54 zeekhuge: I was thinking about some use-case for "PRUs to offload processing of raw data from on-board Peripherals" and I have something in mind. Why search for a use-case, it is obvious. Let's say you have a computer (which has some intel processor) connected to various peripherals say monitor or printer etc. Apr 08 14:39:04 For displaying the output on the monitor we use a graphics card (It is a separate module/controller). The card takes in data and power from the motherboard, the card has its own processor to decide what to do with each pixel on the screen along with some memory to hold information about each pixel and temporarily storing the complete picture. Finally, Apr 08 14:39:04 sending data to monitor for display. Apr 08 14:39:16 A computer has graphics capability built into the motherboard, but for fast-paced games, the computer has to go through this process about sixty times per second. Without a graphics card to perform the necessary calculations, the workload would be too much for the computer to handle. Apr 08 14:39:25 Similar is our situation, we have CPU as Cortex A8 and PRU as a separate controller. When the workload is small, even A8 can handle the processing the raw data of peripherals (just as we shut down everything else running in the background down to play a game if PC is not equipped with a graphics card, which is equivalent to lower down the workload on PC) but Apr 08 14:39:25 in case workload increases (there are many components or one component is consuming too much of CPU processing) the A8 will not be able to perform well. To optimize the working and the using the available resource to boost up the performance, we can utilize the PRUs to handle the task of I/O handling. Apr 08 14:39:34 To me, this project aims at optimizing the processing by efficiently distributing the workload and using the available resources to its fullest capabilities. Apr 08 14:50:30 Akki: Comparing it with the case of GPUs in a PC, is not entirely correct. GPUs are literally build for the purpose they serve. PRUs are build for I/O through their own GPIOs. But since there have been projects for "yet another SPI or I2C using PRUs" so I guess this project might prove to be helpful in some situations. I would ask you to ping other mentors Apr 08 14:50:30 and see if they could suggest some use cases ... Apr 08 17:47:50 hey all Apr 08 17:47:52 m_w: got a minute? Apr 08 17:49:26 ordsen: sure Apr 08 17:49:31 whats up? Apr 08 17:50:09 m_w: I completed all tests with the serial port. Looks like the system gives it exactly one page to buffer inputs Apr 08 17:50:41 so with canonical input mode I can receive up to 4096 bytes without needing to read anything Apr 08 17:51:34 is it safe to assume that serial devices will never write more than 4096 bytes without NL ? Apr 08 17:54:02 no Apr 08 17:55:03 if it is a console maybe but otherwise all bets are off Apr 08 17:55:42 m_w: OK, what about using non-canonical input mode to get around that? Apr 08 17:55:47 That way I can control after how many bytes the buffer is copied to a file Apr 08 17:56:18 ordsen: sure Apr 08 17:56:46 That worked perfectly when all four serial ports where spammed with 20000 bytes :) Apr 08 17:57:26 m_w: but how do you determine when a message has to be logged with a new time stamp then? Apr 08 18:02:21 ordsen: good question Apr 08 18:03:42 the timestamp should be based on when the first character of a packet of data comes in Apr 08 18:04:09 perhaps a polling mechanism could work Apr 08 18:04:58 the trick is knowing how big a packet can be Apr 08 18:06:24 you have any code to look at? Apr 08 18:11:56 m_w: Yeah https://github.com/ordsen/gsoc-preparation/tree/master/io_buffer_userspace/beaglebone the uart_tester.c is where coordinating input happens Apr 08 18:12:46 I made 3 branches for async canonical, sync canonical and sync canonical input mode Apr 08 18:13:16 m_w: We could check the RTC/CTS lines Apr 08 18:13:28 or (alternatively) track when the last message arrived and if the difference to the next message exceeds the time needed for one byte we figured out that a new package arrived Apr 08 18:19:29 yeah Apr 08 18:21:06 ordsen: please make sure that binaries are not committed to the repository Apr 08 18:21:58 at least in the officially repository Apr 08 18:25:10 may want to use a thread for each port Apr 08 18:28:39 ordsen: any experience with threads? Apr 08 18:28:55 m_w: ok i'll remove the binaries Apr 08 18:29:01 yeag posix threads Apr 08 18:29:07 good Apr 08 18:39:26 m_w: I also got the C wrapper working for node js. I built a sample shared library and linked to it from the wrapper, so that part should also work out.. Apr 08 18:40:23 Also found a node module for serial I/O, but I did not try it out yet Apr 08 18:43:06 ordsen: sounds like the project is materializing already Apr 08 18:45:59 m_w: not exactly :D I'm just trying to look at every part so that I get some experience in the technologies I have not used before. Apr 08 18:49:53 m_w: I wanted to set up the detailed architecture during May, so that will give me a basic understanding of how things will work out Apr 08 18:51:09 awesome, keep it up Apr 08 19:35:44 m_w: plz give some suggestions on the use-case that i was discussing with zeekhuge . Apr 08 19:35:56 nerdboy: u too plz Apr 08 20:11:09 Akki: what was the use case that was discussed? Apr 08 20:12:33 I was thinking about some use-case for "PRUs to offload processing of raw data from on-board Peripherals" and I have something in mind. Why search for a use-case, it is obvious. Let's say you have a computer (which has some intel processor) connected to various peripherals say monitor or printer etc. Apr 08 20:12:39 For displaying the output on the monitor we use a graphics card (It is a separate module/controller). The card takes in data and power from the motherboard, the card has its own processor to decide what to do with each pixel on the screen along with some memory to hold information about each pixel and temporarily storing the complete picture. Finally, Apr 08 20:12:39 sending data to monitor for display. Apr 08 20:12:48 A computer has graphics capability built into the motherboard, but for fast-paced games, the computer has to go through this process about sixty times per second. Without a graphics card to perform the necessary calculations, the workload would be too much for the computer to handle. Apr 08 20:12:54 Similar is our situation, we have CPU as Cortex A8 and PRU as a separate controller. When the workload is small, even A8 can handle the processing the raw data of peripherals (just as we shut down everything else running in the background down to play a game if PC is not equipped with a graphics card, which is equivalent to lower down the workload on PC) but Apr 08 20:12:54 in case workload increases (there are many components or one component is consuming too much of CPU processing) the A8 will not be able to perform well. To optimize the working and the using the available resource to boost up the performance, we can utilize the PRUs to handle the task of I/O handling. Apr 08 20:13:00 To me, this project aims at optimizing the processing by efficiently distributing the workload and using the available resources to its fullest capabilities. Apr 08 20:22:26 not sure that I understand the workload that you have in mind Apr 08 20:24:15 you need to have an idea of what tasks the PRU can handle efficiently Apr 08 20:36:54 Can you provide some direction to start? Apr 08 20:37:28 something that requires a degree of determinism that the main processor cannot provide Apr 08 20:39:07 Do you mean something which is to be done in real time? Apr 08 20:39:19 yeah Apr 08 20:40:27 look back at other sucessful projects that involve using the PRU Apr 08 20:42:43 it seems you are talking about accessing UART, GPIO, and SPI from the PRU Apr 08 20:43:10 plenty of projects access the GPIO Apr 08 20:43:33 think of a use case where having the PRU access the SPI makes sense Apr 08 20:43:54 or the UART Apr 08 20:53:20 anything? Apr 08 20:55:36 SPI analog convertor perhaps, explain how this might benefit from the PRU handling the SPI transaction Apr 08 20:55:47 Ok i will try to think about it...But as far as i know there is a separate controller McSPI . So using PRU will not give any such advantage over doing same task using! Apr 08 20:55:57 Mpu Apr 08 20:56:47 think about the nature of the SPI tranactions to converters Apr 08 20:56:54 Ok **** ENDING LOGGING AT Sun Apr 09 03:00:01 2017