I do have another board here, that is potentially more suitable for the task I have in mind - The EK-TM4C129EXL "Crypto" Launchpad. Indeed it has dual 12bit 2Msps ADC's, and 10/100 ethernet MAC / PHY. On top of that the board can more easily run bare metal, thus not having an OS to "get in the way". *That* will be another board, that will be fun to explore. Right now though, the BBB is still a lot of fun, exploring.
On Thu, Oct 8, 2015 at 7:54 PM, Harvey White <[email protected]> wrote: > On Thu, 8 Oct 2015 19:41:33 -0700, you wrote: > > >@ Harvey, > > > >So, buy a RevC, and join in on the fun :) > > I have one already.... > > It's on my list of things to do. > > It has to run either linux or android, and I need the whole spectrum > of I2C available on one interface, it's existing hardware. > > Still need to get that stuff up and running completely, but the BBB > (or equivalent) will be a high level controller (over I2C) running > custom data acquisition hardware. > > Harvey > > > > > > >On Thu, Oct 8, 2015 at 5:56 PM, Harvey White <[email protected]> > wrote: > > > >> On Thu, 8 Oct 2015 14:57:28 -0700, you wrote: > >> > >> >> > >> >> *no longer returns any value or doesn't return a value you expect? > You* > >> >> * should be able to read the memory regardless. What it says is > >> another* > >> >> * matter.* > >> > > >> > > >> >devmem2 returns a NULL value. Meaning, the completes the procedure, but > >> >returns a NULL value. Which is because the ADC module is in effect - > >> >Disabled. I'm convinced it works. > >> > >> Ok, I'm puzzled why you'd get a null value. To me, says that an > >> allocation failed, or memory is not there. > >> > >> If I were writing this, it would mean that the driver could not be > >> found, or that the memory address is invalid... > >> > >> I probably don't understand that at all, just guessing how it might > >> work. > >> > >> > >> > > >> >*Just offhand, I'd suggest not messing with the hardware directly, but* > >> >> * using the system drivers unless you want to write system level* > >> >> * drivers.* > >> >> > >> > > >> >The whole idea, at least for me( and many others ) is to use the > hardware > >> >without drivers that can unnecessarily add application execution > overhead. > >> >Which is exactly how the PRU's control the ADC hardware in many > examples > >> >I've seen. Some might consider this "the non Linux "way" ", But I'd > argue > >> >that doing things the way *you*(generic term) want, is the true Linux > way. > >> >i.e. Flexibility. > >> > >> OK, better system drivers, I can see that. > >> > >> Generally you get lots of different levels in an operating system > >> > >> Hardware -> driver -> medium level interface -> system level interface > >> -> application > >> > >> Hardware -> driver -> medium level interface -> high level interface-> > >> system level interface -> application > >> > >> You get either. Idea is that the driver messes with the hardware, and > >> the medium level interface does sequences, data fetches from the > >> driver (knows how to make the driver work) and provides resources to > >> the system level interface... > >> > >> System level interface is optional, but allows you to treat the ADC > >> (for instance) as a subsystem, while the medium level interface has a > >> bunch of device independent primitives (set resolution, make > >> measurement, set reference, etc....) > >> > >> System stuff would be (make list of measurements using port/adc, > >> return scaled values, make averaged measurements, etc....) Depends on > >> how you treat a device. > >> > >> Graphics GUI commands can go to a system driver which commands remote > >> displays or on board hardware. On board hardware driver selects > >> graphics hardware. Driver makes dots appear.... > >> > >> That kind of thing. > >> > >> I think what you are doing is wanting to roll the hardware driver and > >> the medium level together, and then let the application do the work. > >> > >> I'm thinking that this has more to do with directly writing the > >> hardware driver, providing hardware agnostic routines to the > >> application program and letting it go at that. > >> > >> In a sense, this has nothing to do with linux, except the mechanism > >> for getting at the memory/hardware and such system things as fifos, > >> queues, semaphores and the like. > >> > >> > >> > >> > >> > >> > > >> >*Guess there isn't a linux ADC driver for this chip. I'm used to* > >> > > >> >* writing bare metal drivers myself, but not for linux at all.* > >> > > >> > > >> >There is a Linux driver for the on chip ADC, but it is "slow". Well, > to be > >> >100% accurate I suppose I should say that technically, there is a iio > >> >driver, or capability for a iio driver to have better performance. It > also > >> >uses mmap(), but there may not be such a driver for this specific ADC. > I > >> >honestly have no looked into that *yet*. To be honest( again ), I'm not > >> >sure I care if there is such a driver or not - Either. But what I've > read, > >> >is that iio drivers can come in two varieties. Slow, and fast. > Sometimes > >> >both exist, sometimes not. > >> > >> Let alone how well written an existing driver is... been there..... > >> > >> > > >> >*The heap memory is effectively the *remaining* memory that the* > >> >> * operating system doesn't use, it should include all of the data* > >> >> * segments, the ram data, and the current stack. From this, malloc* > >> >> * pulls memory, (in the GCC-AVR) from the bottom up.* > >> >> > >> >> * So it doesn't at all seem to be the same as the "mem" array, or > the* > >> >> * "port" array...* > >> >> > >> > > >> >I have no hands on with the "port" device. But what I took away from > that > >> >link I pasted, and others, is that it is related, but not the same > thing. > >> > >> Yep. I suspect that if the I/O devices are in a separate memory space > >> (x86) then you get the "port" array. Else you get the "mem" array, > >> and nothing but. > >> > >> > > >> >So thinking on this a little, you're probably right. As far as kernel > >> >space, heap etc Because we have /dev/kmem , /dev/mem/, and /dev/port/. > In > >> >this context it makes sense that they're all separate. In the end > however, > >> >I'm doing a lot of speculation on stuff I *think* I understand. Which > is > >> to > >> >say, I understand a small portion of it all, but still need more > >> >understanding. Which is why I want to find a good read on the subject. > >> > >> I'd be happy to help if I knew a good linux reference that was slanted > >> towards the ARM architecture. Don't, though. > >> > >> > > >> >In the end it's all about the learning - For me. Which it does indeed > seem > >> >I have a lot to keep me busy for a good long while. > >> > >> Know that feeling. > >> > >> Harvey > >> > >> > > >> >On Thu, Oct 8, 2015 at 2:30 PM, Rathin Dholakia < > [email protected] > >> > > >> >wrote: > >> > > >> >> I m just sitting here astonished & awed by the discussion!! > >> >> Congratulations on success..! :-) > >> >> > >> >> Take away from this discussion for me is that, I have a long way to > go! > >> >> > >> >> Rathin > >> >> > >> >> On Friday, October 9, 2015, William Hermans <[email protected]> > wrote: > >> >> > >> >>> *Well, I'd guess something like this: the FIFO data is stored on > the* > >> >>>> * heap, which is malloc'd. You need the pointers as needed to > figure* > >> >>>> * out where it is. Standard pointers to head and tail of the > ring* > >> >>>> * buffer will be stored locally, unless someone did a pointer to > the* > >> >>>> * data structure of the FIFO (but not the data itself). I'm doing > >> that* > >> >>>> * in an OS that I'm writing. The only advantage here is that heap* > >> >>>> * memory (or managed memory) is managed by the OS, and should not > >> belong* > >> >>>> * to any one task. (you could argue that, but it's more convenient > >> this* > >> >>>> * way for me.)* > >> >>>> > >> >>> > >> >>> I can not say it any better than this: > >> >>> http://linux.about.com/library/cmd/blcmdl4_mem.htm So basically, > when > >> >>> you mmap() /dev/mem/ you get a pointer to any system address you > point > >> it > >> >>> to. In this case, for me, the physical address space assigned by the > >> >>> kernel, for the peripherals. This is what I *think* is happening. > I'm > >> still > >> >>> learning how this works, by starting off with examples by others. > >> >>> > >> >>> So what I've figured out already is that the code I'm using, and > have > >> >>> partly written myself. Gives me a pointer to the ADC registers - and > >> more. > >> >>> I know it works, as I can enable the ADC, take readings with my > >> executable, > >> >>> or devmem2, the values are very likely accurate for reason mentioned > >> >>> previously. Then I've written code myself based on information I've > >> read > >> >>> from the TRM to disable the ADC clock when done. After which > devemem2 > >> no > >> >>> longer returns a value from this area of memory - Which is the > memory > >> >>> location for the first FIFO ( FIFO0 ) Of the ADC. > >> >>> > >> >>> What I would really like to find is a good comprehensive guide, > >> document, > >> >>> or something about this whole process. I have not really found this > >> yet, > >> >>> and maybe I've been looking in the wrong places ? Stuff like POSIX > >> shared > >> >>> memory, etc, may be considered advanced topics in programming. But > I'd > >> >>> personally consider the topic of /dev/mem/ far more advanced. > >> Certainly, it > >> >>> can be "dangerous" to start poking around in random memory locations > >> on a > >> >>> live system. Which is why in this case, I started off experimenting > >> with > >> >>> code written by others. > >> >>> > >> >>> Being able to write code from scratch to disable the ADC when done > with > >> >>> it, has boosted my confidence *some*. But I know I have a lot to > learn > >> >>> about this topic, and at least the Linux kernel memory addressing > >> schema. > >> >>> > >> >>> On Thu, Oct 8, 2015 at 12:18 PM, Harvey White < > [email protected]> > >> >>> wrote: > >> >>> > >> >>>> On Wed, 7 Oct 2015 19:18:02 -0700, you wrote: > >> >>>> > >> >>>> >Harvey, > >> >>>> > > >> >>>> >Actually, you're right. the previously mentioned FIFO is actually > >> 100h > >> >>>> in > >> >>>> >size, my bad. Too much on my brain here. What I described above is > >> >>>> actually > >> >>>> >what each 32bit field *in* that buffer *is*. hah ! > >> >>>> > >> >>>> Good, that means that there *is* a FIFO. > >> >>>> > > >> >>>> >Anyway, I make it a habit to jump into things like this because > >> they're > >> >>>> >hard to do. So I often find myself struggling with details like > this. > >> >>>> But > >> >>>> >in this case, not only am I "fighting" the hardware. I'm also > >> fighting > >> >>>> my > >> >>>> >ignorance of how Linux stores this information in memory. > >> >>>> > > >> >>>> > >> >>>> Well, I'd guess something like this: the FIFO data is stored on > the > >> >>>> heap, which is malloc'd. You need the pointers as needed to figure > >> >>>> out where it is. Standard pointers to head and tail of the ring > >> >>>> buffer will be stored locally, unless someone did a pointer to the > >> >>>> data structure of the FIFO (but not the data itself). I'm doing > that > >> >>>> in an OS that I'm writing. The only advantage here is that heap > >> >>>> memory (or managed memory) is managed by the OS, and should not > belong > >> >>>> to any one task. (you could argue that, but it's more convenient > this > >> >>>> way for me.) > >> >>>> > >> >>>> > >> >>>> >What I hope to take away from this is something like: "God, that > was > >> a > >> >>>> pain > >> >>>> >in the butt, but man was it worth it!" Meaning: hopefully I'll > learn > >> >>>> >something worth knowing ;) > >> >>>> > >> >>>> I suspect you will, so go for it. > >> >>>> > >> >>>> Best of luck > >> >>>> > >> >>>> Harvey > >> >>>> > >> >>>> > > >> >>>> >On Wed, Oct 7, 2015 at 6:58 PM, Harvey White < > [email protected] > >> > > >> >>>> wrote: > >> >>>> > > >> >>>> >> On Wed, 7 Oct 2015 18:36:00 -0700, you wrote: > >> >>>> >> > >> >>>> >> >> > >> >>>> >> >> *You're working with two things, FIFO and ADC.* > >> >>>> >> >> > >> >>>> >> >> * What does the ADC do when the FIFO is full?* > >> >>>> >> >> > >> >>>> >> >> * What does the FIFO do when it is full?* > >> >>>> >> >> > >> >>>> >> >> * How do you know?* > >> >>>> >> >> > >> >>>> >> >> * Do you record it?* > >> >>>> >> > > >> >>>> >> > > >> >>>> >> >Hey Harvey, > >> >>>> >> > > >> >>>> >> >There is nothing wrong with my code per se. What is wrong > however, > >> >>>> and > >> >>>> >> >possibly indirectly related to the code in question. Is that > I'm > >> >>>> still > >> >>>> >> >learning the hardware, and some very obscure details as to how > >> Linux > >> >>>> plays > >> >>>> >> >a part in that. > >> >>>> >> > >> >>>> >> Oh, I'm not suggesting that there is something wrong with your > >> code, > >> >>>> >> but I am wondering if there is something wrong with the process > >> >>>> >> involved. > >> >>>> >> > >> >>>> >> Just off the top of my head (and without offence, since I'd > apply > >> the > >> >>>> >> same list to myself... and have.... > >> >>>> >> > >> >>>> >> 1) do we know what the OS is doing? > >> >>>> >> 2) do we know what the hardware is doing? > >> >>>> >> 3) do we know what the firmware/driver is doing? > >> >>>> >> 4) have we made a mistake? > >> >>>> >> 5) is someone else's code not doing what's designed? > >> >>>> >> 6) have we run into a boundary condition of some sort that is > not > >> >>>> >> handled? > >> >>>> >> 7) how do we know the above answers? > >> >>>> >> > >> >>>> >> Has nothing to do with programmer (your) competence. I'd > decent at > >> >>>> >> this, and I've graduated to more complex and obscure mistakes, > >> >>>> >> although I will occasionally make simple ones just to keep > myself > >> in > >> >>>> >> practice (for what, I don't know....) > >> >>>> >> > >> >>>> >> > > >> >>>> >> >So, the way I understand it is that stepping is related to > >> >>>> averaging. In > >> >>>> >> >this context, a step is a single sample in a set of samples > >> >>>> contained in > >> >>>> >> an > >> >>>> >> >average. Here is what I think I understand. Once enabled, the > >> first > >> >>>> step > >> >>>> >> >reads from the pin, stores the value, decrements the stepping > >> value, > >> >>>> then > >> >>>> >> >checks if step > 0 - to possibly restart the sampling. Once all > >> >>>> steps are > >> >>>> >> >finished ( 1, 2, 4, 8, or 16 possible steps ), the step enable > >> bit is > >> >>>> >> >toggled. So this last part here, I'm not clear on, but I think > I > >> >>>> have the > >> >>>> >> >rest correct. But assuming this last part is correct, what > could > >> be > >> >>>> >> >happening is that once I have a full buffer, the step enable > bit > >> is > >> >>>> >> >enabled, and the ADC then "goes to sleep" until one, or more > >> >>>> channels have > >> >>>> >> >their step enable bit set. > >> >>>> >> > >> >>>> >> Sounds more like a sequence where the "stepping" is used to > >> indicate > >> >>>> >> which samples the multiplexed input of the ADC is actually > sampling > >> >>>> >> and measuring. > >> >>>> >> > >> >>>> >> The AVR megas and Xmegas do this. > >> >>>> >> > >> >>>> >> Analog multiplexer hooked to ADC. > >> >>>> >> > >> >>>> >> > > >> >>>> >> >The FIFO, in my case FIFO0DATA is only a single 32bit register. > >> 12bit > >> >>>> >> data, > >> >>>> >> >4bit reserved, 3bit channel id, the rest reserved. So, > >> technically, > >> >>>> it is > >> >>>> >> >always full. I never clear the whole register, only the data > >> field 12 > >> >>>> >> bits. > >> >>>> >> >When I do this with devmem2, the value resets, and the whole > field > >> >>>> >> >refreshes with new values. > >> >>>> >> > >> >>>> >> Now *that* is not what I'd call a FIFO. It's a single buffer, > not > >> a > >> >>>> >> First In First Out multibyte buffer with lots of storage, but a > >> single > >> >>>> >> byte buffer for one reading. The most you can ever get behind > is > >> one > >> >>>> >> reading cycle. > >> >>>> >> > > >> >>>> >> >With the above said, I suppose you are right in that my code > >> might be > >> >>>> >> >wrong, but still I think it is more of a hardware > >> misunderstanding. > >> >>>> Not > >> >>>> >> >that I think that I am the greatest C programmer to ever live, > but > >> >>>> >> usually, > >> >>>> >> >I can code my way out of a wet paper bag. > >> >>>> >> > >> >>>> >> Oh, and a few dry ones as well.... That, as I mentioned, is not > the > >> >>>> >> issue. > >> >>>> >> > >> >>>> >> Often times I find it useful to go back and check the > fundamental > >> >>>> >> assumptions just because. > >> >>>> >> > >> >>>> >> <yoda voice> > >> >>>> >> Is no fault, is only program. > >> >>>> >> <end yoda voice> > >> >>>> >> > >> >>>> >> > >> >>>> >> > > >> >>>> >> >At any rate. Believe it or not prior to answering your post. I > did > >> >>>> hit on > >> >>>> >> >the idea that I could either manually toggle step enable ( was > >> just > >> >>>> >> reading > >> >>>> >> >a bit of code on this ), or I could manually clear the lower > >> 12bits > >> >>>> on the > >> >>>> >> >FIFO register, and see what happens. > >> >>>> >> > >> >>>> >> Not sure what that'll do, but give it a try. > >> >>>> >> > >> >>>> >> Not sure about the ARM hardware, but I know how other processor > do > >> >>>> >> this, and there are some little gotchas. > >> >>>> >> > >> >>>> >> Harvey > >> >>>> >> > >> >>>> >> > > >> >>>> >> > > >> >>>> >> >On Wed, Oct 7, 2015 at 5:45 PM, Harvey White < > >> [email protected] > >> >>>> > > >> >>>> >> wrote: > >> >>>> >> > > >> >>>> >> >> On Wed, 7 Oct 2015 17:20:26 -0700, you wrote: > >> >>>> >> >> > >> >>>> >> >> >Oh and dahm, one more thing heh. Sorry people I'm kind of > >> >>>> remembering > >> >>>> >> this > >> >>>> >> >> >as I think about it. Normally I keep notes, but was up late > >> >>>> attempting > >> >>>> >> to > >> >>>> >> >> >track this issue down. So, I'm reasonably sure the FIFO is > not > >> >>>> >> refreshing, > >> >>>> >> >> >as if I flush the data value manually ( value address &= > >> ~0xFFFF > >> >>>> ), it > >> >>>> >> >> >never gets repopulated. > >> >>>> >> >> > > >> >>>> >> >> >Once more, if I read out the sample in order based on > channel > >> id, > >> >>>> the > >> >>>> >> >> >values stay the same form one iteration to the next. But If > I > >> >>>> burst > >> >>>> >> read > >> >>>> >> >> in > >> >>>> >> >> >whatever comes from the FIFO next, the values do change, but > >> >>>> repeat > >> >>>> >> after > >> >>>> >> >> >many read. Which let us just assume, for now, it's the > length > >> of > >> >>>> the > >> >>>> >> >> buffer > >> >>>> >> >> >I set through iio:device0. > >> >>>> >> >> > > >> >>>> >> >> >*Perhaps* I just need to enable / disable the ADC once the > >> buffer > >> >>>> >> fills - > >> >>>> >> >> >via iio ? I'm not sure, as I've only been working with the > ADC > >> for > >> >>>> >> about > >> >>>> >> >> >what ? A week now ? With no prior experience . . . > >> >>>> >> >> > >> >>>> >> >> You're working with two things, FIFO and ADC. > >> >>>> >> >> > >> >>>> >> >> What does the ADC do when the FIFO is full? > >> >>>> >> >> > >> >>>> >> >> What does the FIFO do when it is full? > >> >>>> >> >> > >> >>>> >> >> How do you know? > >> >>>> >> >> > >> >>>> >> >> Do you record it? > >> >>>> >> >> > >> >>>> >> >> Harvey > >> >>>> >> >> > >> >>>> >> >> > >> >>>> >> >> > > >> >>>> >> >> >On Wed, Oct 7, 2015 at 5:10 PM, William Hermans < > >> >>>> [email protected]> > >> >>>> >> >> 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: > >> >>>> >> >> >> > >> >>>> >> >> >> 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. > >> >>>> >> >> >> > >> >>>> >> >> >> 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. > >> >>>> >> >> >> > >> >>>> >> >> >> 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. > >> >>>> >> >> >> > >> >>>> >> >> >> 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: > >> >>>> >> >> >> 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. > >> >>>> >> >> >> > >> >>>> >> >> >> 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. > >> >>>> >> >> > >> >>>> >> > >> >>>> >> -- > >> >>>> >> 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. > >> >>>> > >> >>> > >> >>> -- > >> >>> For more options, visit http://beagleboard.org/discuss > >> >>> --- > >> >>> You received this message because you are subscribed to a topic in > the > >> >>> Google Groups "BeagleBoard" group. > >> >>> To unsubscribe from this topic, visit > >> >>> > https://groups.google.com/d/topic/beagleboard/OXe88RyHqX8/unsubscribe. > >> >>> To unsubscribe from this group and all its topics, send an email to > >> >>> [email protected]. > >> >>> For more options, visit https://groups.google.com/d/optout. > >> >>> > >> >> > >> >> > >> >> -- > >> >> Rathin A. Dholakia > >> >> "Dont GO through life, GROW through life" > >> >> > >> >> -- > >> >> 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. > >> > > -- > 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.
