Rathin, Anyways, This morning I decided go ahead and test continuous mode using the ti user space driver. After much testing and fooling around I've come to the conclusion, and perhaps incorrectly. That this userspace driver is dog slow. How I've come to this conclusion is as follows.
With slightly modified code from my one-shot example, I was able to achieve ~15k samples a second right from the get go. Thinking I could improve on this somewhat I was experimenting with something ( sorry do not know exactly what ), and got a figure of 35k samples a second. After this, I started to attempt to control read by using a simple timing mechanism. Both usleep(), and nanosleep() introduce a large amount of latency into the application. So neither of those will work. I have not tried using ualarm() *yet*, and I'm kind of hopeful, but . . . I'm thinking it depends on syscalls so . . .will likely not work either. So after experimenting with couple timing functions, I decided to check what len = read() was collecting. To my surprise, it was returning an awful lot of -1's. SO I figure hey, I'll just check len, and continue like with the old app. Well it worked, except sample rate dropped into the toilette. A "whopping" 300-400 samples a second. This is why I think the ADC userspace driver is dog slow. Anyway, I did full blast testing, no timing, just 100% loop, read, printf() every 100,000 iterations - For 2 million total iterations. I get somewhere between 800k-900k samples a second. Of course, much of that data is redundant, and I did a rough guess count, and figured it was roughly 35k / second unique values. CPU is pretty much pegged at 95-99% CPU like this though . . . Another thing to keep in mind with my testing data. What I'm testing could actually be faster. I do not have a voltage applied to the ADC. I'm just reading the floating pin values off channel 0 . . . Maybe I can hook up an LED to AIN0 to AIN_ground, and aim it at the blinking USER LEDs to get some variation ? heh. Anyway I need to take a little break, then I'm back at it. On Mon, Oct 5, 2015 at 12:52 AM, William Hermans <[email protected]> wrote: > 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.
