Wow, I completely forgot about this thread until someone just emailed me
with a question. Thanks for your interest.
The file I opened is "/dev/mem"
int fd = open("/dev/mem", O_RDWR | O_SYNC); //O_SYNC makes the memory
uncacheable
The file is a view of the entire 4GB physical memory space. You need to be
root to open it obviously.
I also have a conjecture about why reading the clock is slow. The DM timer
isn't part of the ARM architecture, so it has to read it externally. Today
as processors integrate more and more devices onto the same chip, packet
switched networks are used more and more instead of dedicated wires since a
packet interface is general purpose and will have higher utilization. But
packet switching will increase latency.
I'd like to know why ARM didn't include a clock as part of the
architectural state. Sure it can save some power, but it practically all
embedded devices need a clock and reading an external one will use more
power. At least one other computer architect agrees:
https://www.youtube.com/watch?v=J9kobkqAicU
At 22:30, Burton laments about the lack of a user readable clock on today's
processors.
Yale
On Friday, May 24, 2013 12:19:58 AM UTC-7, [email protected] wrote:
>
> Hi, I curentlly have some problem with reading DMTIMER. May I ask how
> exactly you read the value of this counter? by which file is your
>
> file descriptor *fd *referred (I mean when you use *mmap()*)?
>
>
> On Saturday, January 28, 2012 6:18:59 AM UTC+1, Uncle Joe wrote:
>>
>> I got a Beaglebone for robotics, where low latency operation is
>> important (especially, if I want to control 40 pins). I found the
>> sysfs interface to control GPIO is too slow (~2200 ns), so I resorted
>> to directly modifying the GPIO registers, which got the time down to
>> ~200 ns. Then I wanted to read the clock via
>> clock_gettime(CLOCK_REALTIME), but that's also very slow (1500 ns).
>> Again I resorted to directly reading the DMTIMER2 counter and got the
>> time down to about 100ns. I still think this is a bit high. Can
>> someone enlighten me why it would take this long to read an on chip
>> value?
>>
>>
>>
>> volatile uint32_t *dmtimer2_regs = (uint32_t *)mmap(NULL, 0x1000,
>> PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0x48040000);
>>
>> while (true)
>> {
>> uint32_t t0 = dmtimer2_regs[0x3c / 4];
>> uint32_t t1 = dmtimer2_regs[0x3c / 4];
>> cout << t1 - t0 << endl; // typically 5
>> clock ticks (each clock tick is ~41ns), hence each time stamp read
>> takes ~100ns
>> }
>>
>
--
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/groups/opt_out.
