On Thu, 8 Oct 2015 14:00:39 -0700, you 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.
mem is the whole system memory, protected or otherwise. It doesn't seem to include ports; port is the I/O memory. I suspect that you're right (not a linux type, but it seems to be what's going on). > >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. 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. > >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. Just offhand, I'd suggest not messing with the hardware directly, but using the system drivers unless you want to write system level drivers. > >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. 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. 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... Harvey > >On Thu, Oct 8, 2015 at 12:18 PM, Harvey White <ma...@dragonworks.info> >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 <ma...@dragonworks.info> >> 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 <ma...@dragonworks.info> >> >> 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 <yyrk...@gmail.com> >> >> >> 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 < >> yyrk...@gmail.com> >> >> >> 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 < >> yyrk...@gmail.com> >> >> >> >>> 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 < >> >> >> >>>> rathindhola...@gmail.com> 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 beagleboard+unsubscr...@googlegroups.com. >> >> >> >>>>> 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 beagleboard+unsubscr...@googlegroups.com. >> >> >> 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 beagleboard+unsubscr...@googlegroups.com. >> >> 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 beagleboard+unsubscr...@googlegroups.com. >> 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
