Just to close the loop on this question, I learned from TI's E2E forum how the A/D channels and steps relate. Basically, the steps allow the configuration of how the channels are read. There are only 8 channels but you can create a sequence of up to 16 steps to read them.
Here's my explanation. So, STEPENABLE lets me enable the steps that I want to be executed. (I missed that concept before.) So if I had an application that had a sensor A that needs to be read every 10ms and sensor B that only needs to be read every minute, I could wire channel 1 to sensor A and assign it to step 1 and wire channel 2 to sensor B and assign it to step 2. Then at startup, when I want to read both sensors, I enable steps 1 and 2 but not 3-16. This saves time on the read as channels 3-7 aren't needed and steps 3-16 aren't needed so I don't use them. Then after the initial read when I don't need to read sensor B until a minute passes, I can change STEPENABLE so only step 1 is enabled and execute a read every 10 ms. Only sensor A would be read. Then at one minute intervals, I change STEPENABLE so steps 1 & 2 are enabled and when read is triggered, sensors A and B are read. BTW - I don't have a real-world application like this but I guess someday I could. This is a very flexible system! On Wednesday, April 14, 2021 at 11:03:30 AM UTC-4 Walter Cromer wrote: > The TSC_ADC only has 8 channels. So why are there 16 STEP registers? > > On Wednesday, April 14, 2021 at 11:02:56 AM UTC-4 Walter Cromer wrote: > >> My setup is a Windows 10 PC with a Black connected via USB or a Black >> wireless connected via wi-fi. So far I have done all the C development on >> the ARM side with Cloud9 and only occasionally use Nano. It's met my needs >> just fine so far but this is getting more complex. I installed TI's CCS >> but it (or TI) prefers to be on a Linux box apparently. >> >> >> >> On Wednesday, April 14, 2021 at 1:39:56 AM UTC-4 TJF wrote: >> >>> Nano isn't best choice for polyglot applications. I'm using Geany (on PC >>> exchanging source files via virtual file system), while I compile and test >>> under LINUX on the BB. >>> >>> [email protected] schrieb am Dienstag, 13. April 2021 um >>> 20:25:06 UTC+2: >>> >>>> Here's one more thing I am struggling with though. It's a mental block >>>> I think. I'm used to controlling GPIOs on the ARM side using sysfs. It >>>> appears that on the PRU, we use __R30 instead but I don't understand how >>>> that works. I read through it this morning and it still isn't sinking in. >>>> >>>> If anyone can help make this clearer, I'd appreciate it. >>> >>> >>> Check out example pruss_toggle >>> <https://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/ChaExamples.html#sSecExaPruToggle> >>> . >>> >> -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/04dbe2ba-1c09-43a7-9f7c-5707456bdd06n%40googlegroups.com.
