@ Harvey, So, buy a RevC, and join in on the fun :)
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.
