**** BEGIN LOGGING AT Thu Apr 04 02:59:57 2019 Apr 04 04:31:06 rashbirsingh: you have to "cross compile" that hello-world program. I expect you'll figure out what that means. Apr 04 04:31:19 pratimugale: very busy at work. I'll try to go through it today. Apr 04 04:36:20 zeekhuge: Can I cross compile it using raspberry pi? Apr 04 04:52:49 @ZeekHuge_:matrix.org: plz review my proposal and if you have any feedback plz tell : https://elinux.org/Beagleboard:Gsoc_2019:gpio_paralle_bi_dir_comm Apr 04 10:44:10 Hello are there anyone who has submitted their proposals? Apr 04 11:35:44 See the logs Apr 04 12:34:50 Yes, but is there a way to keep using the assembly? We enjoyed the fine grain control in timings, so we wouldn't like to switch from assembly to c. Would there be a way to keep the pru firmware as is with minimal changes? Apr 04 12:39:38 lromor : You can look at BeagleLogic firmware that I've written, you can combine C and assembly in the same project Apr 04 12:40:27 Thank you! Apr 04 15:04:08 Hi everyone, please, review my proposal idea: https://elinux.org/BeagleBoard/GSoC/2019Proposal/Xen_on_BeagleBoard-x15 (and be quoted). What do you think about such a project? Will it be useful? Apr 04 15:07:40 I think that your proposed port of Xen is a good and useful project for GSoC. The X15 has a lot of processing power, lending itself well to topics (like virtualization) that have historically not been a focus in ARM-based hobbyist/maker platforms. Apr 04 15:09:17 It is good to see that there might be a chance that expertise in the community can support virtualization on the board and provide a starting point for containers for security and the like.. Apr 04 15:10:13 It is an ambitious and non-trivial project, but you've done much of the background exploration on it and appear to have a good grasp on how much effort it will take. Apr 04 15:17:18 hendersa: thanks! I can say for sure that I will have a lot of fighting with the board and debugger, a lot of documentation reading, a lot of frustration and at the end it will work to some extent. (I think it is a usual thing in embedded development) Apr 04 15:52:56 pratimugale: I liked the idea of a GUI debugger. It must run on the termimal, something based on ncurse maybe. About other things, we had a student who worked on this project in previous years. I would like to see some code reuse from there. Also, I don't think disabling HDMI should be daemon's job. It need to be done explicitly, and should be left upto user to do it. Apr 04 15:54:39 And more details regarding the interface and the functionality would be appreciated. Arrange them in a good timeline. And look into a tool called "swig" to generate APIs. It can be useful. Apr 04 17:52:00 pratimugale: zeekhuge: have you seen debuggers like https://github.com/poopgiggle/prudebug already? Apr 04 17:52:23 also, I wonder if anyone has done any debuggers for remoteproc Apr 04 17:52:53 https://markayoder.github.io/PRUCookbook/04debug/debug.html Apr 04 22:20:48 @zeeHuge_ : sry,by mistake I have share wrong link before https://elinux.org/BeagleBoard/GSoC/2019Proposal/GPIOParallelBidirComm its the correct link please see and give your feedback on it Apr 05 01:56:33 pranav_kumar: have you looked at LEDscape and Falcon Christmas Playet? Apr 05 01:57:06 the problem of too few GPIOs is very common in the world of LED signage. Apr 05 01:57:35 I like the idea of having something simple to understand and to build... Apr 05 01:57:56 but there are already some very advanced solutions. Apr 05 01:58:43 Is there a way to connect the simple to the complex in an understandable/progressive way? Apr 05 02:29:30 @jkridner:matrix.org: yes , i know the working of led signage .and it is possible to make this from beaglebone but the only difference is that it will need few more gpio than what i am using now Apr 05 02:29:42 In this project Apr 05 02:30:28 I'm just wondering if you can think about the project in a way that scales. Apr 05 02:31:44 maybe the hardware you are building is only for a small number of GPIOs, but can a subsystem be built to expand GPIOs using the PRU to parametrically speak to whatever is being used to expand them? Apr 05 02:32:13 Basically i came to the practicle use of shift register from there only Apr 05 02:32:14 then further, can the parallel streaming of data to those GPIOs be generalized as well? Apr 05 02:32:37 things like the HUB75 panels are just shift registers. Apr 05 02:33:07 Yes a i think thats the beauty of the shift register Apr 05 02:34:46 this is a nice graphic of HUB75 scanning: https://forum.arduino.cc/index.php?topic=310346.15 Apr 05 02:35:01 For using a small no gpio in a very efficient manner Apr 05 02:36:36 hmmm.... http://www.ti.com/tool/TIDA-00161 Apr 05 02:40:47 For the first link ,I know the working of led single led color led light board and know the working of neo pixles led ,i can combine then to make it possible Apr 05 02:46:17 I've officially found a new rabbit hole: https://github.com/PreyMa/ScreenBuffer Apr 05 02:49:40 I had seen the datasheet of TIDA-00161 AND the thing is that as they have shown the difference in testing of the ic tida-00161 and other pictire .I think that is some thimg we can achieve through the ti tida only as making an efficient model only shift register at that scale starts to have ghosting effect in it due hardware as it in asyc comm. Apr 05 02:51:06 By using simple sghift registerblike 74hc595 in cascade Apr 05 02:52:01 By using 74hc595 a 8 bit shift register in cascade form Apr 05 02:59:31 As i have mention in. The proposal also i will be making atleast two project using the library i will create during the project time i would like to make some thing like that but as gsoc is more about software as told .I get stick more on the software is than hardware. But using pru of that much clc freq 200mhz will give higly suttisfying result if it gets apply on that level. **** ENDING LOGGING AT Fri Apr 05 02:59:57 2019