Re: [beagleboard] Re: PRU I/O max speed
It was really a ping-pong buffer, not a ring.
I did check the timing with an Agilent 54846B scope.
this is snipped from a backup copy, I have re-purposed the BBB
I did comment about this here already a year ago or so.
My memory about that gets fuzzy...
volatile register unsigned int __R30; // CPU register R30
connects directly to some output pins
volatile register unsigned int __R31; // CPU register R31
connects directly to some input pins
#define SELECT 8 /* 2 BITS addressing of the 4 bytes in CPLD Bit8
= P8.27 und Bit9=p8.29 */
#define PROG_CLK 10 /* P8.28 prog_dat green wire to SDI of ADC*/
#define PROG_DAT 11 /* that works unexpectedly. probably the BBB
handbook is wrong/incomplete. */
/* should be possible according to CPU data
sheet. */
#define DAT_AVAIL 16 /* Pin P9.26, the only PRU1 pin on P9 input busy
oŕ drl, depending on output used */
// GPIO, Clearing or setting takes about 40 nsec
#define PROG_ENA (1<<2)
#define USE_CHAN_B (1<<4)
// variables in main end up on the stack. We only have 0x100 bytes by
default.
// global variables are on the heap. Stack and heap are on the bottom of
the PRU data RAM.
volatile int heapmarker = 0x; // Easy to find in a memory dump
volatile char *bla = "HEAP @ @ @ ";
int i;
volatile int *pipo_pointer;
int pipo_offset;
// data avail is either not busy or not drl. It is high active.
// When the ADC is busy, it is low for 600 nsec.
// The CPLD then takes a little more than 32 Clocks
// to get the 32 bits. Then we can read them out, bytewise.
// It is probably harmless if that extends slightly into the next
// conversion since the read activity is decoupled from the ADC core.
// inline saves 20 nsec.
inline void wait_data_avail(void){
while ( __R31 & (1 << DAT_AVAIL)) {}; // wait for the high
time of p9.26 = data_avail
while (!(__R31 & (1 << DAT_AVAIL))){}; // wait for the low time
// now the ADC transaction window opens.
// next 320 ns we will read the data into the CPLD or program the ADC
}
// read 4 bytes from the CPLD, mask them, shift them & convert to one int.
// I must read at least 3 times that the results are right ( for address
setup time)
// removing a single read makes it 60 nsec faster, 15 nsec per read.
Should be 5 nsec???
// reading 3 times takes 40 nsec per bit. That should be enough.
// reading 4 times takes 60 nsec per bit. Reading __R31 takes abt. 20
ns. :-(
// Von der steigenden Flanke von data_available am P9 bis zum return
dauert 725 nsec.
// kill 320 nsec, the time the CPLD needs to fill the shift register
// das sind 340 nsec für 5 Schleifendurchläufe. LAHM??
// 1 = 42 ns 2 = genauso?? 11 = 104 ns 31 = 208 ns 51 = 304 ns
// 61 = 355 nsec 60 = 350 ns
// Once through the empty loop costs 5 nsec.
// for( retval=60; retval; retval--){};
// D.h. es bleiben 250 nsec zum ABspeichern im pingpong-Buffer. Das CPLD
könnte sagen,
// wann die Daten für den BBB fertig sind. Dann hätte man 350 nsec mehr
Zeit für sonst was.
// Das ist jetzt gemacht. Data_rdy_bb geht jetzt 330 nsec low, solange
das CPLD den ADC auslutscht.
// Wenn data_rdy_bbb hochgeht, können wir gleich anfangen, das CPLD
leerzunuckeln.
// Genug Zeit für noch 2 Kanäle.
inline int read_adc(void){
int retval;
// Without volatile it runs 3 times as fast, even though __R31 is
volatile
volatile unsigned int byte0, byte1, byte2, byte3;
wait_data_avail();
// __R30 &= ~(3 << SELECT); // address 0 Trigger
// __R30 |= (3 << SELECT); // address 3
// from here to parking address wires at return it takes 350 nsec.
__R30 &= ~(3 << SELECT); // address 0
byte0 = __R31; // address setup time for byte 0
byte0 = __R31; // 5 nsec each line
// byte0 = __R31;
byte0 = __R31;
__R30 |= (1 << SELECT); // address 1
byte1 = __R31;
byte1 = __R31;
// byte1 = __R31;
byte1 = __R31;
__R30 &= ~(3 << SELECT); // address 2, remove old bit field
__R30 |= (2 << SELECT); // insert new bit field
byte2 = __R31;
byte2 = __R31;
// byte2 = __R31;
byte2 = __R31;
__R30 |= (1<< SELECT); // increment to address 3
byte3 = __R31; //
byte3 = __R31;
// byte3 = __R31;
byte3 = __R31; // get the last byte
retval = ((byte0 & 0xff) )
| ((byte1 & 0xff) << 8 )
| ((byte2 & 0xff) << 16)
| ((byte3 & 0xff) << 24);
__R30 &= ~(3 << SELECT); // park address at 0, may be removed.
return retval;
}
---
Am 24.04.21 um 08:16 schrieb Jason Kridner:
https://pub.pages.cba.mit.edu/ring/
On Thu, Apr 22, 2021 at 11:02 AM Gerhard Hoffmann
mailto:g...@hoffmann-hochfrequenz.de>>
wrote:
I think I can read in about 3 pcs. LT2500-32 via
Re: [beagleboard] Re: PRU I/O max speed
https://pub.pages.cba.mit.edu/ring/ On Thu, Apr 22, 2021 at 11:02 AM Gerhard Hoffmann < g...@hoffmann-hochfrequenz.de> wrote: > I think I can read in about 3 pcs. LT2500-32 via the PRU in Software. > > The LT2500 ADC delivers 32 bit results via SPI, and with the capture and > > conversion time slots it needs 100 MHz SPI to process each 1MHz sample. > > The ADC feeds its data to a shift register in a Xilinx 2c64 Coolrunner. > > The PRU then reads it bytewise and writes the collected 32 bit words > > into a ring buffer in the shared RAM. > > Up to now I have tested 1 ADC, but bandwidth should be enough for 3, > > just so. > > regards, Gerhard > > > > Am 22.04.21 um 15:53 schrieb rpaulb...@gmail.com: > > I got it working, and I hope to never revisit it. It was kind of a > surprise. I selected a 1MS/s 16-bit SPI ADC and assumed a 16 Mhz SPI clock > to get the data out. I totally missed that the ADC can’t sample, convert, > and send at the same time, so I basically have 300nS to get my 16 bit out. > Everything else I had done with the PRU monitored and responded to an > external clock, so this is the first time I was generating the clock and > sampling the incoming data. I had noticed a previous oddity where I had > some debugging statements (set an output pin) and when I removed them > things stopped working. There is definitely a speed limit. > > > > > > > > > > > *From:* beagleboard@googlegroups.com > *On Behalf Of *Andrew P. Lentvorski > *Sent:* Thursday, April 22, 2021 5:01 AM > *To:* BeagleBoard > > *Subject:* [beagleboard] Re: PRU I/O max speed > > > > I would be stunned if the GPIOs don't have synchronizer flip-flops as they > are sampling a signal asynchronous to the 200MHz clock. That would account > for 2 clocks. You probably need one extra to clock data into R31. And > then one clock to read R31. > > > > 50MHz is a pretty smoking speed for SPI--you normally need to start > thinking about series termination and some basic signal integrity. You > normally need the clock to capture to flop directly if you want things to > work. > > > > I suspect you probably need to use the 16-bit Parallel Capture Mode while > feeding your clock out back as clock in. You'll still probably be 4 clocks > behind when the data hits R31, but the data will get *captured* by the > PRU_CLOCKIN edge properly so the delay will now be deterministic if you > are generating the 50MHz clock yourself. > > > > On Thursday, February 25, 2021 at 12:15:18 PM UTC-8 rpau...@gmail.com > wrote: > > With a sample size of one, r31 appears to be 4 instructions behind the > state of the pin. > > On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote: > > I am, unfortunately, bit-banging SPI with the PRU, and I seem to be > running into a speed limit < 50 MHz I desire. I can certainly create a > clock that fast, but reading data seems to be delayed. I can see on the > logic analyzer a "0" clearly being read as a '1" so there is either a delay > in my clock output or a delay in my input or both. I would like to think > that r30 and r31 are tied directly to the outside world, but now I am > thinking there is something in between that is either clocked or just has > significant output delays. Anyone else encountered this? > > -- > 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/9GdOGgGv-eY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > beagleboard+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com > <https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com?utm_medium=email_source=footer> > . > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.com > <https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.com?utm_medium=email_source=footer> > . > > -- > For more options, visit http://beaglebo
Re: [beagleboard] Re: PRU I/O max speed
I think I can read in about 3 pcs. LT2500-32 via the PRU in Software. The LT2500 ADC delivers 32 bit results via SPI, and with the capture and conversion time slots it needs 100 MHz SPI to process each 1MHz sample. The ADC feeds its data to a shift register in a Xilinx 2c64 Coolrunner. The PRU then reads it bytewise and writes the collected 32 bit words into a ring buffer in the shared RAM. Up to now I have tested 1 ADC, but bandwidth should be enough for 3, just so. regards, Gerhard Am 22.04.21 um 15:53 schrieb rpaulb...@gmail.com: I got it working, and I hope to never revisit it. It was kind of a surprise. I selected a 1MS/s 16-bit SPI ADC and assumed a 16 Mhz SPI clock to get the data out. I totally missed that the ADC can’t sample, convert, and send at the same time, so I basically have 300nS to get my 16 bit out. Everything else I had done with the PRU monitored and responded to an external clock, so this is the first time I was generating the clock and sampling the incoming data. I had noticed a previous oddity where I had some debugging statements (set an output pin) and when I removed them things stopped working. There is definitely a speed limit. *From:* beagleboard@googlegroups.com *On Behalf Of *Andrew P. Lentvorski *Sent:* Thursday, April 22, 2021 5:01 AM *To:* BeagleBoard *Subject:* [beagleboard] Re: PRU I/O max speed I would be stunned if the GPIOs don't have synchronizer flip-flops as they are sampling a signal asynchronous to the 200MHz clock. That would account for 2 clocks. You probably need one extra to clock data into R31. And then one clock to read R31. 50MHz is a pretty smoking speed for SPI--you normally need to start thinking about series termination and some basic signal integrity. You normally need the clock to capture to flop directly if you want things to work. I suspect you probably need to use the 16-bit Parallel Capture Mode while feeding your clock out back as clock in. You'll still probably be 4 clocks behind when the data hits R31, but the data will get *captured* by the PRU_CLOCKIN edge properly so the delay will now be deterministic if you are generating the 50MHz clock yourself. On Thursday, February 25, 2021 at 12:15:18 PM UTC-8 rpau...@gmail.com <mailto:rpau...@gmail.com> wrote: With a sample size of one, r31 appears to be 4 instructions behind the state of the pin. On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote: I am, unfortunately, bit-banging SPI with the PRU, and I seem to be running into a speed limit < 50 MHz I desire. I can certainly create a clock that fast, but reading data seems to be delayed. I can see on the logic analyzer a "0" clearly being read as a '1" so there is either a delay in my clock output or a delay in my input or both. I would like to think that r30 and r31 are tied directly to the outside world, but now I am thinking there is something in between that is either clocked or just has significant output delays. Anyone else encountered this? -- 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/9GdOGgGv-eY/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com <mailto:beagleboard+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com <https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com?utm_medium=email_source=footer>. -- 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 <mailto:beagleboard+unsubscr...@googlegroups.com>. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.com <https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.com?utm_medium=email_source=footer>. -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/78b77aa0-0115-7281-8319-78e14b26a6ce%40hoffmann-hochfrequenz.de.
RE: [beagleboard] Re: PRU I/O max speed
I got it working, and I hope to never revisit it. It was kind of a surprise. I selected a 1MS/s 16-bit SPI ADC and assumed a 16 Mhz SPI clock to get the data out. I totally missed that the ADC can’t sample, convert, and send at the same time, so I basically have 300nS to get my 16 bit out. Everything else I had done with the PRU monitored and responded to an external clock, so this is the first time I was generating the clock and sampling the incoming data. I had noticed a previous oddity where I had some debugging statements (set an output pin) and when I removed them things stopped working. There is definitely a speed limit. From: beagleboard@googlegroups.com On Behalf Of Andrew P. Lentvorski Sent: Thursday, April 22, 2021 5:01 AM To: BeagleBoard Subject: [beagleboard] Re: PRU I/O max speed I would be stunned if the GPIOs don't have synchronizer flip-flops as they are sampling a signal asynchronous to the 200MHz clock. That would account for 2 clocks. You probably need one extra to clock data into R31. And then one clock to read R31. 50MHz is a pretty smoking speed for SPI--you normally need to start thinking about series termination and some basic signal integrity. You normally need the clock to capture to flop directly if you want things to work. I suspect you probably need to use the 16-bit Parallel Capture Mode while feeding your clock out back as clock in. You'll still probably be 4 clocks behind when the data hits R31, but the data will get *captured* by the PRU_CLOCKIN edge properly so the delay will now be deterministic if you are generating the 50MHz clock yourself. On Thursday, February 25, 2021 at 12:15:18 PM UTC-8 rpau...@gmail.com <mailto:rpau...@gmail.com> wrote: With a sample size of one, r31 appears to be 4 instructions behind the state of the pin. On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote: I am, unfortunately, bit-banging SPI with the PRU, and I seem to be running into a speed limit < 50 MHz I desire. I can certainly create a clock that fast, but reading data seems to be delayed. I can see on the logic analyzer a "0" clearly being read as a '1" so there is either a delay in my clock output or a delay in my input or both. I would like to think that r30 and r31 are tied directly to the outside world, but now I am thinking there is something in between that is either clocked or just has significant output delays. Anyone else encountered this? -- 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/9GdOGgGv-eY/unsubscribe. To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscr...@googlegroups.com <mailto:beagleboard+unsubscr...@googlegroups.com> . To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com <https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com?utm_medium=email_source=footer> . -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/02f301d7377e%24d9e9e3b0%248dbdab10%24%40gmail.com.
[beagleboard] Re: PRU I/O max speed
I would be stunned if the GPIOs don't have synchronizer flip-flops as they are sampling a signal asynchronous to the 200MHz clock. That would account for 2 clocks. You probably need one extra to clock data into R31. And then one clock to read R31. 50MHz is a pretty smoking speed for SPI--you normally need to start thinking about series termination and some basic signal integrity. You normally need the clock to capture to flop directly if you want things to work. I suspect you probably need to use the 16-bit Parallel Capture Mode while feeding your clock out back as clock in. You'll still probably be 4 clocks behind when the data hits R31, but the data will get *captured* by the PRU_CLOCKIN edge properly so the delay will now be deterministic if you are generating the 50MHz clock yourself. On Thursday, February 25, 2021 at 12:15:18 PM UTC-8 rpau...@gmail.com wrote: > With a sample size of one, r31 appears to be 4 instructions behind the > state of the pin. > > On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote: > >> I am, unfortunately, bit-banging SPI with the PRU, and I seem to be >> running into a speed limit < 50 MHz I desire. I can certainly create a >> clock that fast, but reading data seems to be delayed. I can see on the >> logic analyzer a "0" clearly being read as a '1" so there is either a delay >> in my clock output or a delay in my input or both. I would like to think >> that r30 and r31 are tied directly to the outside world, but now I am >> thinking there is something in between that is either clocked or just has >> significant output delays. Anyone else encountered this? > > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/f88c700e-69c2-4ac4-bc64-d44a1715460dn%40googlegroups.com.
[beagleboard] Re: PRU I/O max speed
With a sample size of one, r31 appears to be 4 instructions behind the state of the pin. On Thursday, February 25, 2021 at 12:26:16 PM UTC-5 Paul Beam wrote: > I am, unfortunately, bit-banging SPI with the PRU, and I seem to be > running into a speed limit < 50 MHz I desire. I can certainly create a > clock that fast, but reading data seems to be delayed. I can see on the > logic analyzer a "0" clearly being read as a '1" so there is either a delay > in my clock output or a delay in my input or both. I would like to think > that r30 and r31 are tied directly to the outside world, but now I am > thinking there is something in between that is either clocked or just has > significant output delays. Anyone else encountered this? -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1781cc2e-8871-4312-bd1e-a312ab32ed3en%40googlegroups.com.
[beagleboard] Re: PRU I/O
Thanks Brandon. I did get some of the pins working, but am getting all
zeros on PRU1_R31 0 through 7. I'm trying to use the interacto pru code
to capture images from a CMOS camera, which I've copied into my own
repo:
https://github.com/Rose-Hulman-ROBO4xx/1314-BeagleBone-Quadcopter/blob/master/code/i2c_bitbang/pru_sw/example_apps/camera/camera.p.
PRU1_R31_16, 8, and 9 are definitely working, as the program will run to
completion when I supply a clock to the camera, and does not run to
completion when there is no clock. I've tested the memory mapping by
moving dummy test values into r0 before storing it into dram at line 92,
but when it comes time to actually store the camera's data, I only get
zeros, even when I wire one of the data pins to 3.3v (through a 2.2k
resistor for safety). I've also confirmed that there is data coming from
the camera using my BusPirate, which shows the voltage getting up to 2.76,
and a frequency in the range of 1.8MHz, which does seem about right.
Any ideas why this is happening?
On Thursday, January 23, 2014 12:29:53 AM UTC-5, Brandon I wrote:
Here's mine:
/dts-v1/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
part-number = AQ-PRU-MDIO;
exclusive-use = P8.43, P8.44, P8.45, P8.46, P8.39, P8.40,
P8.41, P8.42, P8.27, P8.28, P8.29, P8.30, pru1;
fragment@0 {
target = 0xdeadbeef;
__overlay__ {
pinmux_pru_mdio_pins {
pinctrl-single,pins = 0xa8 0xd 0xac 0xd 0xa0 0xd 0xa4 0xd 0xb8 0x35 0xbc
0x35 0xb0 0x35 0xb4 0x35 0xe0 0x36 0xe8 0x36 0xe4 0x36 0xec 0x36;
linux,phandle = 0x1;
phandle = 0x1;
};
};
};
fragment@1 {
target = 0xdeadbeef;
__overlay__ {
status = okay;
pinctrl-names = default;
pinctrl-0 = 0x1;
};
};
__symbols__ {
pru_mdio_pins = /fragment@0/__overlay__/pinmux_pru_mdio_pins;
};
__fixups__ {
am33xx_pinmux = /fragment@0:target:0;
pruss = /fragment@1:target:0;
};
__local_fixups__ {
fixup = /fragment@1/__overlay__:pinctrl-0:0;
};
};
I constructed mine by modifying one of the existing dts files on the
beaglebone. I'll admit I don't completely understand it, but you could
trimming it down to only your pins.
On Tuesday, January 21, 2014 6:56:41 PM UTC-8, Christopher Hopwood wrote:
Hello all,
I'm trying to use the PRU gpio pins, but cannot get them to work. I've
modified Doctor Yoder's device tree example to enable the PRU pins, but my
program is still not getting the input. What am I doing wrong?
Here is my overlay:
/dts-v1/;
/plugin/;
/{
compatible = ti,beaglebone, ti,beaglebone-black;
part-number = MAY-gpio-set;
version = 00A0;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
pinctrl_test: MAY-gpio-set {
pinctrl-single,pins =
0x0e4 0x36
0x0e0 0x36
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = pinctrl_test;
status = okay;
};
};
};
};
--
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/groups/opt_out.
[beagleboard] Re: PRU I/O
Here's mine:
/dts-v1/;
/ {
compatible = ti,beaglebone, ti,beaglebone-black;
part-number = AQ-PRU-MDIO;
exclusive-use = P8.43, P8.44, P8.45, P8.46, P8.39, P8.40,
P8.41, P8.42, P8.27, P8.28, P8.29, P8.30, pru1;
fragment@0 {
target = 0xdeadbeef;
__overlay__ {
pinmux_pru_mdio_pins {
pinctrl-single,pins = 0xa8 0xd 0xac 0xd 0xa0 0xd 0xa4 0xd 0xb8 0x35 0xbc
0x35 0xb0 0x35 0xb4 0x35 0xe0 0x36 0xe8 0x36 0xe4 0x36 0xec 0x36;
linux,phandle = 0x1;
phandle = 0x1;
};
};
};
fragment@1 {
target = 0xdeadbeef;
__overlay__ {
status = okay;
pinctrl-names = default;
pinctrl-0 = 0x1;
};
};
__symbols__ {
pru_mdio_pins = /fragment@0/__overlay__/pinmux_pru_mdio_pins;
};
__fixups__ {
am33xx_pinmux = /fragment@0:target:0;
pruss = /fragment@1:target:0;
};
__local_fixups__ {
fixup = /fragment@1/__overlay__:pinctrl-0:0;
};
};
I constructed mine by modifying one of the existing dts files on the
beaglebone. I'll admit I don't completely understand it, but you could
trimming it down to only your pins.
On Tuesday, January 21, 2014 6:56:41 PM UTC-8, Christopher Hopwood wrote:
Hello all,
I'm trying to use the PRU gpio pins, but cannot get them to work. I've
modified Doctor Yoder's device tree example to enable the PRU pins, but my
program is still not getting the input. What am I doing wrong?
Here is my overlay:
/dts-v1/;
/plugin/;
/{
compatible = ti,beaglebone, ti,beaglebone-black;
part-number = MAY-gpio-set;
version = 00A0;
fragment@0 {
target = am33xx_pinmux;
__overlay__ {
pinctrl_test: MAY-gpio-set {
pinctrl-single,pins =
0x0e4 0x36
0x0e0 0x36
;
};
};
};
fragment@1 {
target = ocp;
__overlay__ {
test_helper: helper {
compatible = bone-pinmux-helper;
pinctrl-names = default;
pinctrl-0 = pinctrl_test;
status = okay;
};
};
};
};
--
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/groups/opt_out.
