> > *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*
Just know that no one is born knowing any of this, or anything for that matter. We all have to start from square one - as it were. As far as learning C, or any programming language, that just comes with lots of code writing. The more you write, the more you fail, and hopefully learn from. I do think it is important to emphasize the key point: That failure in this context is not a bad thing. So long as you eventually learn *why* something failed. Hopefully in many cases, sooner rather than later. On Thu, Oct 8, 2015 at 2:57 PM, William Hermans <[email protected]> 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. > > *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. > > *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. > > *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. > > 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. > > 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. > > 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.
