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.
