> > *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 [email protected]. For more options, visit https://groups.google.com/d/optout.
