Welp, I finally did get this working for myself.
-> I just had to recompile pxaregs (the necessary registers aren't in
pxaregs). Noob me, I was thinking before that pxaregs didn't access the regs
because support for them wasn't in the kernel. That was incorrect.
-> I didn't actually get the preferred 32.768kHz, I got 33.333kHz, which is
based on the 1us clock. The 32.768kHz internal driving clock of the PXA270
needs to count (1+n) for each _half_ cycle of the output, and the lowest
setting for n (OSMR10) is 1, which happens to be how the gumstix ships, so
you get 8kHz instead.
I got my 33.333kHz signal by following these steps.
1) Adding the following two lines to the reg_info definition in a local copy
of pxaregs.c placed in org.openembedded.snapshot/packages/pxaregs/
{ "OSMR10", 0x40A00098, 0, 0xffffffff, 'x', "OS Timer Match Register
10 (4-36)" },
{ "OMCR10", 0x40A000D8, 0, 0x000001ff, 'x', "OS Match Control
Register 10" },
Of course these only apply to the PXA27x CPUs.
2) Deleting the existing SRC_URI asignment in
org.openembedded.snapshot/packages/pxaregs/pxaregs_1.14.bb and replacing it
with
PR = "r1"
SRC_URI = "file://pxaregs.c "
(to up the revision value and force bitbake to look at the local file).
3) Recompiling pxaregs (bitbake pxaregs) and replacing the old binary with
it in /usr/sbin/ on the gumstix device.
4) Running the following lines on the gumstix:
pxaregs OSMR10 0x0000000e
pxaregs OMCR10 0x000000cc
echo "AF3 out" > /proc/gpio/GPIO9
First line sets the counter match value to 14.
Second line sets counter source to a 1us signal. Then, the period will be
2*(1+14)*1us = 30us.
Third line has the resulting 33.333kHs signal show up on the GPIO9 pin.
That's all she wrote!
Perhaps there was a more elegant way of doing it but this gets me by.
--
View this message in context: http://www.nabble.com/Q%3A-Change-GPIO9-from-8kHz-to-32kHz...-tp20051182p20132088.html
Sent from the Gumstix mailing list archive at Nabble.com.
|