Dear William, Thanks for the detailed reply..!
1) Thanks for the sprintf tip, I will work on it and put a code here..!! 2) 14 MB/S data rate, yes, I have read that post :-) that was one of the reason I got impressed by BBB & choose..!! but thing is over there an external ADC + buffer is used..!! 3) Regarding kernel question , sorry I felt silly after asking it. I asked it because I wanted to use system time & Ethernet socket so I thought there would be some separate API. (just like Xenomai, it has its own command) - Oh you are in to Power Electronics.. wonderful..! yeah this can be used in converters but interesting application would be sensor-less BLDC motor controller.. or HIL recorder-player!! 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. Rathin On Saturday, October 3, 2015 at 10:12:58 PM UTC+5:30, William Hermans wrote: > > *1) This program samples only 1 ADC correct? involtage0_raw To extend it >> for all 7 channels woudl I have to create 7 such pointers, correct?* > > > Technically, yes. The pointer is actually a string pointer for the given > file pah. However, you could use a for loop, and generalize the string, > using the for loop to "inject" 0-7. Look into the function sprintf(), and > while at it google "sprintf() dangers" or you could just red this post: > http://stackoverflow.com/questions/3662899/understanding-the-dangers-of-sprintf > > > > *2) this is Ti rt kernel, is it same as TI-RTOS? and if not, where can I >> find it's APIs?* > > > No. For the Linux API's, you just need to become familiar with std libc / > POSIX functions. Then google. Each libc POSIX function when you need more > information, etc. I actually goolge A LOT when it comes to API calls, as I > do not always remember exact details. Anyway, TI-RTOS is potentially > problematic for this hardware. First I'm not even sure it would run on this > hardware. Second, you would have to write much functionality yourself. > Besides you could use just plain Linux to do what you want, using the > PRU's. I've read at least one blog post where a person was achieving 14MB > /s + data using the PRU's + a non rt kernel. Yes, that's 14 Megabytes a > second. > > *3) This kernel has completely new structure, so now my PRUs are >> completely unusable :-) any suggestions? initially it was accessible by >> "/sys/devices/bone_capemgr.*/**slots" which now doesn't exist!!* >> > Yes, the PRU's do not work on this kernel. I believe I mentioned this > before, but in case I did not this is why I recommended if you experimented > with this to keep your old sdcard as well. However, and with with that > said. Currently I am working on a similar non TI kernel that does support > the PRU. That, and I WILL be using the PRU to access the on chip 200k SAR > module. Not sure how long this will take me to get working though. Anyway, > I have interest in this as well. Remember one of my electronics interests > is power electronics ;) So using the ADC, and a PWM could be used as a > control for a SEPIC( or similar ) DC-DC power converter. If not, well then, > it's still useful for testing. > > *4) Is your existing code able to reach 3K sample speed? if not can you >> suggest changes for that?* > > > Reload my blog post and read the update. ~2960 samples a second seems to > be max for a single channel, in one-shot mode. This also uses ~77% CPU, so > there is not much room for improvement. One thing that I did consider, was > using fork(), with some form of timing, and multiple channels. Also note > that my code has changed a little. Specifically . . . > > if(len == -1){ >> close(fd); >> continue; >> } >> > > This enables the code to run continuously without problems related to the > device being busy. So in effect you could remove the while loop check, and > just run it in an infinite loop. If you want to know how it works. I > briefly describe that on my blog post in the update part at the bottom. > > So . . . I've not done this yet, but I think one might be able to achieve > between 3-4k a second samples using multiple processes, on multiple > channels, and with tight timing. I've done some reading, and this seems to > be inline what others have achieved in the past. The biggest hindrance will > be the CPU in this case however. > > Using continuous mode on the ADC should be able to improve the situation > somewhat. But according to what I've read. ~10k samples a second while > using sysfs will be the maximum. I've read that mmap() can improve this > considerably. But honestly, and for the moment this is over my head. I know > mmap() fairly well, but in this case, I do not know what address should be > mapped through /dev/mem/, or how I would get the data out of the ADC > running in continuous mode. I do think that using mmap() + /dev/mem/ > *could* come close to the maximum theoretical limit of the 200k SAR module > though . . . But this is just a hypothesis based on various things I've > read. > > > > -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
