> > > > *I'm reading sensors using the analog inputs on my BBG and for my real > application the SFS system is plenty fast enough but I do occasionally get > share violation exceptions. I'm assuming that I'm attempting to read the > file exactly when it is being written and therefore I get the exception. A > try/catch handles that but I'd much rather just check to see if the > conversion/write has finished and not generate exceptions.Problem is I > can't seem to find any information on what to check or even if there is > anything I can check. Anyone have any information on this?* >
So, try / catch blocks add a performance hit when used, and should be avoided on "fast moving" code. You've shown us no code, so there is no way really we can say what you need to / need not do. It's been a long while since I've written any C# code, however look as this C example I wrote on my blog site, and how I deal with the problem in that code. http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/ Do you see how it's dealt with ? len = read(fd, adc, sizeof(adc - 1)); if(len == -1){ close(fd); continue; } The major key to the above code snippet is understanding how the API call read() works. The rest is academic. But in short. If the length of read() is -1, close the file descriptor, and *continue*. There are probably better definitions of what continue does in code on the internet. But basically, continue jumps execution to the top of the code block ( { } ) the code is executing in. Which in fact, starts over by attempting to reopen the file descriptor. On Wed, Mar 2, 2016 at 5:11 AM, 'PatM001' via BeagleBoard < [email protected]> wrote: > I'm reading sensors using the analog inputs on my BBG and for my real > application the SFS system is plenty fast enough but I do occasionally get > share violation exceptions. I'm assuming that I'm attempting to read the > file exactly when it is being written and therefore I get the exception. A > try/catch handles that but I'd much rather just check to see if the > conversion/write has finished and not generate exceptions. > > Problem is I can't seem to find any information on what to check or even > if there is anything I can check. Anyone have any information on this? > > The second part of the question is about speeding up the conversions. > Since I'm reading sensors and this BBG is mucho fast I made a simple > oscilloscope using Zedgraph to see the effects of my low pass filter > combinations (Its MUCH easier than using my real oscilloscope!). Problem is > that if I just read the ADC values and stuff them into an array I get tons > of exceptions. I have to slow down the reading of the adc file by doing > other operations in the loop (I tried thread.sleep() but that only goes > down to 1ms and cuts the sample rate in half. > > I did run across mentions of changing the ADC conversion rate but only > with assembler or C running on a PRU. I'm nowhere near skilled enough to do > PRU programming and there doesn't seem to be any library for C# for > accessing the registers (I see there is for Python and C/C++). > > Any clues on how to change the conversion rate from C# (maybe a PyPRUSS > like library for C#?) > > Thanks! > > -- > 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.
