Hello! Yes you are right! Something was wrong with my client and I only 
just now saw all of these replies!

I don't understand why, but I was not receiving emails with updates on this 
post of mine :/ I was getting email updates with daily summaries of other 
questions getting answered right away and I was beginning to feel 
discouraged. But somehow I just found all of these ! Thank you for all the 
replies everyone. 

As far as using kmalloc and vmalloc inside kernel space, it definitely 
looks challenging, but kernel space programming is something I think I will 
want to learn someday so I'm not too intimidated to consider it. I read 
Derek Molloy's 3 articles about loadable kernel modules on the beaglebone, 
and I thought they were really well done, but I wasn't sure if I really 
knew everything I needed to know to make a kernel module that uses 
kmalloc/vmalloc. Does a kernel module that allocates this kind of memory in 
external ram need to happen in the boot up process? or will a run-time 
Loadable Kernel Module be able to do it? Any one have any good resources 
for a beginner to learn kernel space memory allocation?

I was originally trying to program the PRU using libprussdrv, but I was 
unable to make it work on 4.9... :( prussdrv_open() would always fail me no 
matter what I tried. If anyone could tell me what I was doing wrong, I 
would definitely go back to libprussdrv because it made more intuitive 
sense to me than pru_rproc, but as of now pru_rproc (using 4.4) is the only 
way I've been able to get at my beaglebone's PRUs! So I gotta ask, is there 
anything like the "sudo modprobe uio_pruss extram_pool_sz=0x12500" 
solution that would work with pru_rproc? I definitely think that kind of 
command is idealic, I'm willing to switch to uio_pruss if I can use it and 
it works... but is there anything similar that works with pru_rproc? 
because that would save me a lot o f time and backtracking.

Thank you so much for reading!
Evan


On Tuesday, February 27, 2018 at 12:19:58 PM UTC-8, Evan Carter wrote:
>
> Hello,
>
> I've been working with PRU0 on the Beaglebone Black for a couple weeks now 
> (only a beginner) and have made some hopeful progress towards developing a 
> real time system that will change gpio logic states based on given location 
> data from a pupil tracking system. 
>
> So far I've been using the examples given in the BeagleScope project 
> (found here 
> <https://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg>) to 
> program the PRU using pru_rpmsg, and I'm currently using: Linux beaglebone 
> 4.4.113-ti-r147 #1 SMP Tue Feb 20 20:58:22 UTC 2018 armv7l GNU/Linux
>
> Things are going well! 
> *But I wanted to ask the community about the simplest way to build a large 
> 1-D array (look up table of ~310,000 indexes of just integers) that can be 
> accessed by PRU0 on the fly* to know how to set the gpios when it 
> receives a new set of pupil location values. Previously I've built this 
> array in userspace from an existing .txt file that is read byte by byte 
> from a C script that builds the array, but I need that array to be 
> accessible from PRU0. What is the simplest way to do this?
>
> I've looked into trying to build the array in DDR memory (which could in 
> theory be accessed by the PRU using address pointers), but allocating that 
> kind of space to be available to a user space program looks pretty 
> complicated (especially to ME who has never done any kernel space 
> programming). I'm hoping that someone out there can give me inspiration for 
> a simpler way to get this array to PRU0.
>
> Please get back to me soon! Thank you for reading
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/c863cf7e-ab16-49ea-bbf9-c3056f73fd43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to