Hi, Oh, magnificent..!! Yes you are correct I am facing problem in C..!! actually this link depicts exactly my state.. http://c.learncodethehardway.org/book/introduction.html specially the last paragraph in "Introduction" section and 1st in "Core competence" section :-)
and btw two small queries, 1) I have gone through your links, so, did you recompile the kernel? with those modules ON...? 2) your this result is for single shot mode right? Once again thanks for a spell of motivation. Rathin On Tuesday, October 6, 2015 at 9:04:34 PM UTC+5:30, William Hermans wrote: > > *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] > <javascript:>> 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] <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.
