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.
