Hello William, So you were able to run the continuous mode driver? I am on to it since 1.5 day.. You are talking about the driver program that is "generic_buffer.c" am I correct? and your 800k - 900k samples are for single channel correct, so in that case for 8 channels it would be 100K which is really exciting!! :-)
btw you are using RT kernel have you tried giving priority to the program while running? it might improve the results.. Your results are exciting me.. please I will make my program work somehow and paste it here. Please dont paste your code yet.. let me figure out my way and then if i face problem, you can guide 0:-). Rathin On Tuesday, October 6, 2015 at 4:09:21 AM UTC+5:30, William Hermans wrote: > > 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] > <javascript:>> 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] >> <javascript:>> 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] <javascript:>. >>> 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.
