odd mmap behavior
pavlovevidence at gmail.com
Wed Oct 21 17:22:59 CEST 2009
On Oct 21, 6:50 am, Brett <brettgra... at gmail.com> wrote:
> I also posted this question to the linux-omap list and received some
> helpful (and timely) assistance. I'm running this on an ARM (omap
> 3530, gumstix). Here is the take-home message (from the omap technical
> reference and reported to me herehttp://www.spinics.net/lists/linux-omap/msg19347.html):
> The GP timer registers are limited to 32-bit and 16-bit data accesses;
> 8-bit access is not allowed and can corrupt the register content."
> So... instead of calling mmap.read_byte() i'm calling mmap.read(4).
> The thing I'm still wondering, is if python 'under-the-hood' is still
> making 8-bit accesses. I thought it was fixed, but just got another
> 'Unhandled fault'. Any hints?
Yes, read() operates by copying the value as a string, which means
byte-by-byte access. (It's probably using a function such as
PyString_FromStringAndLen under the convers.)
I'm not sure you can even access the the memory through the mmap
object except byte-by-byte.
One way to get word access would be to use buffer protocol, which mmap
supports, and create a numpy ndarray that references the mmap data.
More information about the Python-list