On Wed, 7 Oct 2015 17:10:49 -0700, you wrote: >More info on the issues I'm having with the FIFO. The data seems to repeat, >and never changes between system reboots. I'm not sure if this is my fault, >or the fault of something to do with this Linux kernel, the iio user space >drivers, or something else. For now, I'm assuming it is my fault. Things >that I am noticing:
What that *sounds* like is when you allocate memory for the FIFO, it is never cleared. The variables that read from the FIFO *ought* to be initialized appropriately, however. So this is puzzling. > >When reading the values out of the ADC via mmap() versus using iio, the >values read out are not in the same range. Using sysfs, the floating >voltage values are around ~4000. But with mmap() these values vary starting >from as low as in the hundreds, or up close to, but not passing 4000. The >ID field for the ADC's *always* stay in the correct range though. Which is >why I think I'm not flushing / clearing the FIFO correctly - More on this >later. I'd clear the FIFO memory (or queue memory) just because. Look for calloc rather than malloc if you're dealing with bare metal (I do....) > >It does not matter how I configure the ADC( sysfs or mmap() ) in this case. >What I've been experimenting with is a header file originally written for >the Beaglebone white, but I checked the base address / offset constants( >against the TRM ), and they seem to be exactly the same. Here, my problem >lies in not completely understanding the hardware, and how various things >interact inside of, or with Linux. Writing the software for all this once >understood. For me, will be trivial. Why do I think pointers are used here? > >What does make sense to me with this problem is that I do not understand >how to flush the buffer, and then tell the ADC "hey send more samples". But >I am not exactly sure this is what my problem is. This is just a guess on >my behalf, that makes the most sense. The ADC in most processors needs to be "started", and depending on the interrupt handler (which may feed the FIFO), is automatic from then on until a specified number of reads is done (or not...). Since the FIFO pointers are supposedly initialized to (beginning:beginning) for read/write (head/tail)... and since data is supposedly written into the FIFO and the pointers are adjusted then (which means clean data).... Either the FIFO is not being set up properly, or the code is wrong.... > >Another thing that did occur to me is that I'm reading from the FIFO too >fast. But there are many factors here, including but not limited to: Reading from the FIFO too fast is not really possible on a well designed FIFO. You either have data available or you do not. Data available should be set when the complete message is written. FIFO ought to be interlocked that read does not interfere with write.... >Averaging, stepping, clock divider, and ADC clock cycles needed to read out >a correct value. These are the things that are foremost on my mind right >now, of which I have limited understanding of - so far. Averaging generally handles noise, and averages n samples for a single reading (and reports it). Stepping I'm not sure of. clock divider simply means that the ADC is not reading at an optimum rate *for the ADC hardware* which has nothing to do with sampling or anything else. ADC clock cycles to read out simply means I say read, how soon (clock cycles) do I get data? So I don't know what's going on. However, I'd try disabling the FIFO for the moment, slowing down the read process to where a software loop could check it, and look for data integrity. *then* I'd go looking for things to blame.... Just me, though. Harvey > >On Wed, Oct 7, 2015 at 4:44 PM, William Hermans <[email protected]> wrote: > >> *Have you experimented with buffer size? is there any optimal value >>> calculation? Would it have any impact on the result, Like if we keep a >>> larger buffer and than directly take that buffer that way it would be >>> faster? I have currently kept 1k.* >> >> >> Yeah sorry, I'm kind of in my own world here at the moment. Anyway, like I >> mentioned above I was speaking of the ADC FIFO. As for buffering into >> system RAM, this is certainly possible, and very likely preferable. This >> can also be done, very easily, using POSIX shared memory. Potentially, this >> is a problem, as once the data is in RAM, how do you get it back out for >> transport. Without using additional CPU cycles, or using the PRU's ? Not >> using the PRU's for this by the way, is a constraint I've placed on myself. >> Just to see if it is *reasonably* possible. Indeed, I do believe it is >> possible, but not quite sure how reasonable that possibility *is*. - Yet. >> >> On Wed, Oct 7, 2015 at 4:34 PM, William Hermans <[email protected]> wrote: >> >>> Well, the buffer I'm talking about is the ADC buffer. I've been looking >>> through others code for PRU -> ADC, and have been attempting to translate >>> that. I'm afraid my ASM skills are very lacking for this task( I have not >>> written ASM code in years ). However the constants used in much of the code >>> out there, are the same. So while I do not yet know what LBBO, and stuff >>> liek r0-r31 mean for program flow, I can figure out the addressing very >>> quickly. Not to mention that the TRM has this information too, but the TRM >>> is very terse reading for many things. It's great for "cherry picking" >>> offsets, but much of the information is not presented in an order that >>> makes the most sense to me. ie, you have to bounce around too much form one >>> place to another in this *huge* manual . . . >>> >>> So, I may have to take a break, and get to know the PRU assembly language >>> well before proceeding much further. Which is something I intended on doing >>> anyhow, just not right at this moment. One thing that has me excited here >>> is an idea that came to me last night. Concerning using the PRU's in a way >>> I've not seen anyone else do - yet. Well, I've seen mention of others >>> touching on the subject I suppose, but . . . yeah I do not want to let my >>> "secrete" out just yet. >>> >>> On Wed, Oct 7, 2015 at 2:48 PM, Rathin Dholakia <[email protected] >>> > wrote: >>> >>>> Hi William, >>>> >>>> Oh, I had already seen that and experimented with it..!!but had >>>> forgotten, after watching your link I recollected. I am really sorry for >>>> silly question. >>>> >>>> Have you experimented with buffer size? is there any optimal value >>>> calculation? Would it have any impact on the result, Like if we keep a >>>> larger buffer and than directly take that buffer that way it would be >>>> faster? I have currently kept 1k. >>>> >>>> And yes, Priority is a priority!! I though you were on break from >>>> BBB,...!! :-) >>>> >>>> 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.
