> > *OK, so while the executable is running. How much CPU is being used ? The > reason I ask may be less than obvious, but I'm asking because I do not know > what type pruIo *is*. But the assignment of this type looks remarkably > similar to mmap(). e.g. a file mapped to a region in memory.*
err . . .heh , What I was getting at here is that if the executable is using more than say 5% CPU. Then there is a good possibility that the file descriptor object is non blocking. But if the executable is using a small amount of CPU, then it most likely is a non blocking file descriptor. Which in English means it is probably the majority of the "slowness" problem. On Tue, Sep 29, 2015 at 4:08 PM, William Hermans <[email protected]> wrote: > OK, so while the executable is running. How much CPU is being used ? The > reason I ask may be less than obvious, but I'm asking because I do not know > what type pruIo *is*. But the assignment of this type looks remarkably > similar to mmap(). e.g. a file mapped to a region in memory. > > So a few things to take notice of. > > First, you're making a call to select() every while loop iteration. That > is to say: every 1ms, assuming the OS lets you. select() I believe is a > system call, and can slow things down. If the call to the file descriptor > object is blocking. It can slow things down quite considerably. Here, > again, I'm not familiar with TJF's library to know. One potential "fix" > might be to change the file descriptor object to O_NONBLOCK using fcntl(). > Then perhaps look into using epoll() which has none of the performance > issues that select(), or poll() have. Which is something I do not > experience with personally, but have been reading a lot about lately for my > own purposes. > > Second, you making a call to every while loop cycle to fprintf() which > has to format 8 variables down to every 1ms. fprintf(), I'm not very > familiar with, but if it is similar to printf() this can be another > performance hit. With that said, I'm not sure how you could avoid this. > That is to say, I know what the function does, I just have never read the > actual implementation code . . . so could not tell you how it does, what it > does. I'm assuming, it behaves exactly like printf(), but allows one to > send this formatted output to an alternate "file stream". Without . . > .heh . . . "magic hand waving". > > Thirdly, and I'm still not quite sure how often this happens. Because I > have not even a clue what the TEMP_FAILURE_RETRY macro does. Here, Im > assuming it returns some condition based on the state of the file > descriptor( ready read, etc ). But once you break out of the while loop, > into the outside do loop, you have *cough* 3 what I think are also system > calls to tcgetattr(). But once again, I'm not all that familiar with termios > either . . . > > Anyway, are you seeing a pattern here ? For very performant code, system > calls are *baaaaaaaaad*. Did I emphasize that enough ? This is why many > people when working with file descriptors often use mmap() Or rather is one > very good reason why. Unfortunately I'm also not all that familiar with the > ADC on this platform either . . . However, assuming there is a sysfs pseudo > file available for the ADC, using mmap() to map to it should not be all > that difficult. After that, I think the majority of the difficulty would be > working out timing. Or in other words it is very possible using mmap() on > the file descriptor to the ADC and just pumping that data straight into the > termios buffer may be too fast. > > Anyway, sorry I could not answer your question better . . . but hopefully > I did give you a few things to consider. Perhaps TJF can elaborate on some > of the points I made, and prove / disprove what I'm assuming in many cases. > > On Tue, Sep 29, 2015 at 1:38 PM, Rathin Dholakia <[email protected] > > wrote: > >> Hi, >> Thank u very much for prompt response. I am using the default C wrapper >> example from libpruio and modified it. HEre are the changes and the paste >> bin >> >> Modifications: >> 1. changed steps - 8 >> 2. Made delay = 0, >> 3. Start sample delay = 0 >> Paste bin: http://pastebin.com/yBHdN548 >> <iframe src="http://pastebin.com/embed_iframe.php?i=yBHdN548"; >> style="border:none;width:100%"></iframe> >> >> On Wednesday, September 30, 2015 at 1:59:05 AM UTC+5:30, William Hermans >> wrote: >>> >>> Well essentially, you probably need a review of your code. If it's >>> large, past it on a pastebin site, and give us a link here. Also ALL code >>> would be best. bit's and pieces won't be enough. >>> >>> On Tue, Sep 29, 2015 at 1:16 PM, Rathin Dholakia <[email protected]> >>> wrote: >>> >>>> Dear Community Members, >>>> >>>> I am trying to implement a fast 8 channel Analog capture using on board >>>> ADC on BBB. I know there are only 7 available on pin header, but as I am >>>> starting off & learning I am ok with count of 7. :) >>>> >>>> I just wanted to have an opinion about the approach to opt for, What >>>> would be the most optimum (& preferably faster to implement) option to >>>> achieve it? >>>> >>>> I have read quite a few articles and thread (& more confused ) and >>>> currently I am using libpruio >>>> <http://beagleboard.org/project/libpruio/> for implementing it but as >>>> of now even after configuring libpruio I am only getting 900 - 1000 samples >>>> per seconds. >>>> >>>> So, is it my configuration wrong or for such high speed I should opt >>>> for external ADC? or something else? >>>> >>>> I am completely NEW to EMBEDDED domain. So please pardon me. >>>> >>>> It would be great if someone could guide me, precisely towards some >>>> direction. >>>> >>>> Sincerely, >>>> Rathin >>>> >>>> -- >>>> 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.
