mmap() should max out the ADC's, but I'm going to do it just because I can. So, ADC, to PRU, to DDR, plus userland C to mmap() the region of DDR is very similar. What is not similar and in favor of the PRU is less CPU load, and determinism.
On Sun, Oct 4, 2015 at 11:58 PM, Rathin Dholakia <[email protected]> wrote: > Dear William, > > As Prezemek suggested its an older version of driver user guide!! though > the new version doesn't enlist the limitation at all except 1!! it's > "Limitless".. :-) > I am currently studying continuous mode. stuck with few hurdles, I will > let you know once I get some lead. > > Sincerely, > Rathin > > PS: Yes, there are lot of "jumping through hoops", yet you were able to > manage it, I couldnt :-( I got so confused and clueless.. though I feel > assembly language would be the most easiest way to deal with PRUs even > after considering the efforts in writing the assembly code. what do you > say? > > On Sunday, October 4, 2015 at 7:05:46 AM UTC+5:30, William Hermans wrote: >> >> Ah! >> * ADC Driver Limitations * >> >> This driver is based on the IIO (Industrial I/O subsystem), however this >> is the first release of this driver and it has limited functionality: >> >> 1. No HW trigger Support. Currently only supporting software trigger. >> 2. Limited number of samples in continuous capture mode. (Only 1528 >> samples per capture) >> 3. Limited maximum sample rate in continuous mode: 8K samples / >> second. >> 4. Simultaneous capture on multiple ADC channels is not supported. >> Currently only supports continuous capture on a single ADC input channel >> at >> a time. >> 5. "Out of Range" not supported by ADC driver. >> >> http://processors.wiki.ti.com/index.php/AM335x_ADC_Driver's_Guide >> >> >> >> >> On Sat, Oct 3, 2015 at 6:06 PM, William Hermans <[email protected]> wrote: >> >>> Rathin, on a side note, I did get the pru's working on the kernel Im >>> using now which is: >>> >>> debian@beaglebone:~$ uname -a >>> Linux beaglebone 4.1.9-bone-rt-r16 #1 Thu Oct 1 06:19:41 UTC 2015 armv7l >>> GNU/Linux >>> >>> The pru example code seems to work fine too . . . >>> debian@beaglebone:~/am335x_pru_package/pru_sw/example_apps/bin$ sudo >>> ./PRU_memAcc_DDR_sharedRAM >>> >>> INFO: Starting PRU_memAcc_DDR_sharedRAM example. >>> INFO: Initializing example. >>> INFO: Executing example. >>> INFO: Waiting for HALT command. >>> INFO: PRU completed transfer. >>> Example executed succesfully. >>> >>> But man, lot's of jumping through hoops to get to here. I had to piece >>> together from all over the web, so you can bet once I'm ready I will make a >>> blog post on it. If for no one else, for myself. I still want to write a >>> simplified "hello world" example. Blinking USR0 using the PRU . . . After >>> that, then onto using the on chip ADC. >>> >>> >>> >>> On Sat, Oct 3, 2015 at 5:49 PM, William Hermans <[email protected]> >>> wrote: >>> >>>> *4) I tried with while(1) and it ran perfectly. Now I will try changing >>>>> to continuous mode as well as the no of ADC in to the program and will >>>>> report back to you..!! * >>>>> >>>>> *Thanks for the kick start, It is of immense help and yes I have >>>>> understood since the beginning that Google is our BEST friend when >>>>> working >>>>> on something new...!! though my results are not as accurate as ur's but >>>>> working on it.. :-)* >>>>> >>>>> *Once again thanks.. will post back my new code, soon.* >>>> >>>> >>>> If you get continuous mode working I'd be interested in seeing the >>>> code. Might even be able to optimize it some for you ;) But I know someone >>>> on another forum who is interested in continuous mode. I told him that I am >>>> more interested in getting the PRU's involved, but might get around to it >>>> someday. I know compared to PRU + ADC it will be slow. *But* if you can get >>>> continuous mode working from sysfs, you only need one open(), and close() >>>> call for the lifetime of the application for each file path. Which is to >>>> say that open(), and close() will no longer have an impact on the >>>> application run speed. Then you only need worry about OS latency, and the >>>> efficiency of your code . . . >>>> >>>> You know, a couple friends from different countries, and I have proven >>>> that google results vary from country to country. So maybe your results are >>>> skewed based on your locale some ? There is a way you can specify which >>>> server google uses when you search, but I forget the details. Well, aside >>>> from using a web proxy ;) Have fun ! >>>> >>>> On Sat, Oct 3, 2015 at 1:43 PM, Rathin Dholakia <[email protected]> >>>> wrote: >>>> >>>>> Dear TJF, >>>>> >>>>> Sorry to bug you with a silly question, I thought being a binary it >>>>> must have some specific encoding rel. to library hence I asked it. I didnt >>>>> knew it was lack of knowledge. I am sorry...!! >>>>> >>>>> I Have figured out the way to read binary (code pasted bellow for >>>>> others;) but I have a doubt in it that I have lot of Zeros & negative >>>>> readings as well >>>>> Is it because of my decoding error or is it the samples themselves >>>>> missing. >>>>> >>>>> Thanks a ton..!! >>>>> >>>>> #include<stdio.h> >>>>> int main() >>>>> { >>>>> FILE *fp = NULL; >>>>> >>>>> short result[100]; >>>>> int i; >>>>> >>>>> fp=fopen("output.0", "w+"); >>>>> rewind(fp); >>>>> if(fp != NULL) >>>>> { >>>>> fread(result, sizeof(short), 100 /*# of samples*/, fp); >>>>> } >>>>> else >>>>> return 1; >>>>> >>>>> printf("Result\n"); >>>>> for (i = 0; i < 100; i++) >>>>> printf("%d = %d\n", i, (int)result[i]); >>>>> >>>>> fclose(fp); >>>>> return 0; >>>>> } >>>>> >>>>> >>>>> >>>>> -- >>>>> 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]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>> >> -- > 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]. > For more options, visit https://groups.google.com/d/optout. > -- 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]. For more options, visit https://groups.google.com/d/optout.
