*921234.4541685859* Samples a second exactly. You need to understand though. Many, many samples are the same value. At this time I was sampling just one channel. Late last night before bed, I was sampling all 7 available channels, and was noting that some channels were putting values into the buffer more often than others. It was nothing concrete, and almost seemed random. So I implemented reading the channel ID for each channel, and started sampling by ID. Samples / second went way down as a result, but now I have accurate 1-7 samples in order. Anyway, I think this has to do with ADC data averaging, but there is no way that I know of through userspace to set averaging. I think if I disable averaging, the buffer should be populated more consistently. But again . . . this is a guess. Also, I've read that one can change the clock multiplier of the ADC too. Default is 0x7, and it can be set to 0x0. From a 24Mhz source. But maybe this is a mmap() or PRU thing ?
With mmap() I should be able to manipulate the ADC registers just like how the PRU's do things. Anyway, I think I've shown that Linux can keep up with more than 200k / second samples. Now, to find a way to make the ADC keep up ;) So Rathin, let me give you a hint: http://processors.wiki.ti.com/index.php/Linux_Core_ADC_User's_Guide#Beaglebone.2FBeaglebone_Black and http://elinux.org/images/6/65/Spruh73c.pdf#page=1573&zoom=auto,0,719 Is all the information I needed to get all this working. So, in fact should be all you need as well. However, I think you might be struggling more with the C aspect . . . On Tue, Oct 6, 2015 at 3:18 AM, Rathin Dholakia <[email protected]> wrote: > 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]> >> 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. > -- 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.
