subject:"\[beagleboard\] Re\: Header files for non PRU peripherals"

[beagleboard] Re: Header files for non PRU peripherals

2016-09-14 Thread Kirk


That did it!
Now I'm a happy "CM_PER..."  :)

Now it's on to see if I can get some data moving on the SPI.

Thanks for your help,
Kirk


On Wednesday, September 14, 2016 at 1:23:09 PM UTC-7, Jason Reeder wrote:
>
> #define CM_PER_SPI0_CLKCTRL(*((volatile unsigned int *) 
> 0x44E0004C))
> #define CM_PER_SPI1_CLKCTRL(*((volatile unsigned int *) 
> 0x44E00050))
>
> in your main method after you enable the OCP master port using 
> STANDBY_INIT:
> // to enable SPI0
> while (! (CM_PER_SPI0_CLKCTRL == 0x2) ) {
> CM_PER_SPI0_CLKCTRL = 2;
> }
> //to enable SPI1
> while (! (CM_PER_SPI1_CLKCTRL == 0x2) ) {
> CM_PER_SPI1_CLKCTRL = 2;
> }
>
> Jason Reeder
>
> On Wednesday, September 14, 2016 at 2:48:51 PM UTC-5, Kirk wrote:
>>
>>
>> Jason,
>>
>> I'm trying to use the new sys_mcspi.h header file which you provided.
>>
>> I have a simple test program I adapted from some example code that 
>> toggles a gpio pin which I monitor with a scope.
>> I use the toggle rate seen on the scope to determine whether phaseBit is 
>> zero or not.
>> (the code is below)
>>
>> The code writes a 1 to the phase control bit in the SPI config register.
>> Then it reads it back into the phaseBit variable.
>>
>>
>> I figure if it writes a 1 it should read back a 1.
>> Trouble is it's always reading back 0.
>> The code does what is expected if I force a 1 or 0 into phaseBit
>>
>>
>> Not sure what I'm doing wrong. (remember I'm new to PRU work)
>>
>> Do does the code have to do something to enable access to the SPI 
>> registers?
>>
>> Thanks,
>> Kirk
>>
>>
>> /*
>>  * Based on the examples distributed by TI
>>  *
>>  * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
>>  *
>>  *
>>  * Redistribution and use in source and binary forms, with or without
>>  * modification, are permitted provided that the following conditions
>>  * are met:
>>  *
>>  * * Redistributions of source code must retain the above copyright
>>  *  notice, this list of conditions and the following disclaimer.
>>  *
>>  * * Redistributions in binary form must reproduce the above copyright
>>  *  notice, this list of conditions and the following disclaimer in the
>>  *  documentation and/or other materials provided with the
>>  *  distribution.
>>  *
>>  * * Neither the name of Texas Instruments Incorporated nor the names of
>>  *  its contributors may be used to endorse or promote products derived
>>  *  from this software without specific prior written permission.
>>  *
>>  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>>  * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>>  * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>>  * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>>  * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>>  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>>  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>>  * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>>  * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>>  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>>  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>>  */
>>
>> #include 
>> #include 
>> #include 
>> #include 
>> #include "resource_table_empty.h"
>>
>> volatile register uint32_t __R30;
>> volatile register uint32_t __R31;
>>
>> void main(void)
>> {
>> volatile uint32_t gpio;
>>
>> volatile uint32_t phaseBit;
>>
>>
>> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
>> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>>
>> // attempt to write an SPI configuration bit and read it back
>> CT_MCSPI0.CH0CONF_bit.PHA = 0x1;
>> phaseBit = CT_MCSPI0.CH0CONF_bit.PHA;
>>
>> // by forcing phaseBit to 0 or 1 here I get the expected toggle rate below
>> // phaseBit = 1;
>>
>>
>> /* Toggle GPO pins TODO: Figure out which to use */
>> gpio = 0x000F;
>>
>> // if phaseBit is non-zero toggle fast, otherwise toggle slow
>> while (1) {
>> __R30 ^= gpio;
>> if(phaseBit == 0)
>> {
>> __delay_cycles(100); // toggle at approx 100Hz
>> }
>> else
>> {
>> __delay_cycles(50); // toggle at approx 200Hz
>> }
>>
>> }
>> }
>>
>>
>>
>>
>> On Wednesday, September 7, 2016 at 3:55:36 AM UTC-7, Jason Reeder wrote:
>>>
>>> Kirk,
>>>
>>> Do a 'git pull' on your pru-software-support-package repo and the 
>>> sys_mcspi.h files should be in the include/am335x/ folder. Let me know if 
>>> you run into any problems while using it, I didn't have time to test it out.
>>>
>>> Jason Reeder
>>>
>>> On Saturday, September 3, 2016 at 8:30:56 AM UTC-5, Kirk wrote:


 OK, I see it now.  Thanks for pointing that out
 I overlooked it because I thought he pru_*.h files were specific to the 
 PRU peripherals.
 Should have looked closer.

 Here's the directory I'm looking in and the header files in it:

 /op

[beagleboard] Re: Header files for non PRU peripherals

2016-09-14 Thread Jason Reeder

#define CM_PER_SPI0_CLKCTRL(*((volatile unsigned int *) 0x44E0004C))
#define CM_PER_SPI1_CLKCTRL(*((volatile unsigned int *) 0x44E00050))

in your main method after you enable the OCP master port using STANDBY_INIT:
// to enable SPI0
while (! (CM_PER_SPI0_CLKCTRL == 0x2) ) {
CM_PER_SPI0_CLKCTRL = 2;
}
//to enable SPI1
while (! (CM_PER_SPI1_CLKCTRL == 0x2) ) {
CM_PER_SPI1_CLKCTRL = 2;
}

Jason Reeder

On Wednesday, September 14, 2016 at 2:48:51 PM UTC-5, Kirk wrote:
>
>
> Jason,
>
> I'm trying to use the new sys_mcspi.h header file which you provided.
>
> I have a simple test program I adapted from some example code that toggles 
> a gpio pin which I monitor with a scope.
> I use the toggle rate seen on the scope to determine whether phaseBit is 
> zero or not.
> (the code is below)
>
> The code writes a 1 to the phase control bit in the SPI config register.
> Then it reads it back into the phaseBit variable.
>
>
> I figure if it writes a 1 it should read back a 1.
> Trouble is it's always reading back 0.
> The code does what is expected if I force a 1 or 0 into phaseBit
>
>
> Not sure what I'm doing wrong. (remember I'm new to PRU work)
>
> Do does the code have to do something to enable access to the SPI 
> registers?
>
> Thanks,
> Kirk
>
>
> /*
>  * Based on the examples distributed by TI
>  *
>  * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
>  *
>  *
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions
>  * are met:
>  *
>  * * Redistributions of source code must retain the above copyright
>  *  notice, this list of conditions and the following disclaimer.
>  *
>  * * Redistributions in binary form must reproduce the above copyright
>  *  notice, this list of conditions and the following disclaimer in the
>  *  documentation and/or other materials provided with the
>  *  distribution.
>  *
>  * * Neither the name of Texas Instruments Incorporated nor the names of
>  *  its contributors may be used to endorse or promote products derived
>  *  from this software without specific prior written permission.
>  *
>  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>  * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>  * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>  * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>  * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>  * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>  * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>
> #include 
> #include 
> #include 
> #include 
> #include "resource_table_empty.h"
>
> volatile register uint32_t __R30;
> volatile register uint32_t __R31;
>
> void main(void)
> {
> volatile uint32_t gpio;
>
> volatile uint32_t phaseBit;
>
>
> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>
> // attempt to write an SPI configuration bit and read it back
> CT_MCSPI0.CH0CONF_bit.PHA = 0x1;
> phaseBit = CT_MCSPI0.CH0CONF_bit.PHA;
>
> // by forcing phaseBit to 0 or 1 here I get the expected toggle rate below
> // phaseBit = 1;
>
>
> /* Toggle GPO pins TODO: Figure out which to use */
> gpio = 0x000F;
>
> // if phaseBit is non-zero toggle fast, otherwise toggle slow
> while (1) {
> __R30 ^= gpio;
> if(phaseBit == 0)
> {
> __delay_cycles(100); // toggle at approx 100Hz
> }
> else
> {
> __delay_cycles(50); // toggle at approx 200Hz
> }
>
> }
> }
>
>
>
>
> On Wednesday, September 7, 2016 at 3:55:36 AM UTC-7, Jason Reeder wrote:
>>
>> Kirk,
>>
>> Do a 'git pull' on your pru-software-support-package repo and the 
>> sys_mcspi.h files should be in the include/am335x/ folder. Let me know if 
>> you run into any problems while using it, I didn't have time to test it out.
>>
>> Jason Reeder
>>
>> On Saturday, September 3, 2016 at 8:30:56 AM UTC-5, Kirk wrote:
>>>
>>>
>>> OK, I see it now.  Thanks for pointing that out
>>> I overlooked it because I thought he pru_*.h files were specific to the 
>>> PRU peripherals.
>>> Should have looked closer.
>>>
>>> Here's the directory I'm looking in and the header files in it:
>>>
>>> /opt/source/pru-software-support-package/include/am335x
>>>
>>> pru_cfg.h
>>> pru_ctrl.h
>>> pru_ecap.h
>>> pru_iep.h
>>> pru_intc.h
>>> pru_uart.h
>>> sys_mailbox.h
>>> sys_pwmss.h
>>>
>>> I don't see anything for SPI0 and SPI1 on the host processor.
>>> I'll be needing to get at them too.
>>> Any ideas?
>>>
>>> Thanks,
>>> Kirk
>>>
>>>
>>>
>>> On Thursday, September 1, 2016 at 5:18:07

[beagleboard] Re: Header files for non PRU peripherals

2016-09-14 Thread Jason Reeder

Kirk,

You probably need to enable the peripheral (and its clocks) using its 
CM_PER register in order to read and write its registers.

Let me look up the address in the TRM real quick and I'll post some 
psuedo-code.

Jason Reeder



On Wednesday, September 14, 2016 at 2:48:51 PM UTC-5, Kirk wrote:
>
>
> Jason,
>
> I'm trying to use the new sys_mcspi.h header file which you provided.
>
> I have a simple test program I adapted from some example code that toggles 
> a gpio pin which I monitor with a scope.
> I use the toggle rate seen on the scope to determine whether phaseBit is 
> zero or not.
> (the code is below)
>
> The code writes a 1 to the phase control bit in the SPI config register.
> Then it reads it back into the phaseBit variable.
>
>
> I figure if it writes a 1 it should read back a 1.
> Trouble is it's always reading back 0.
> The code does what is expected if I force a 1 or 0 into phaseBit
>
>
> Not sure what I'm doing wrong. (remember I'm new to PRU work)
>
> Do does the code have to do something to enable access to the SPI 
> registers?
>
> Thanks,
> Kirk
>
>
> /*
>  * Based on the examples distributed by TI
>  *
>  * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
>  *
>  *
>  * Redistribution and use in source and binary forms, with or without
>  * modification, are permitted provided that the following conditions
>  * are met:
>  *
>  * * Redistributions of source code must retain the above copyright
>  *  notice, this list of conditions and the following disclaimer.
>  *
>  * * Redistributions in binary form must reproduce the above copyright
>  *  notice, this list of conditions and the following disclaimer in the
>  *  documentation and/or other materials provided with the
>  *  distribution.
>  *
>  * * Neither the name of Texas Instruments Incorporated nor the names of
>  *  its contributors may be used to endorse or promote products derived
>  *  from this software without specific prior written permission.
>  *
>  * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>  * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
>  * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
>  * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
>  * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
>  * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
>  * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
>  * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
>  * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
>  * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
>  * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
>  */
>
> #include 
> #include 
> #include 
> #include 
> #include "resource_table_empty.h"
>
> volatile register uint32_t __R30;
> volatile register uint32_t __R31;
>
> void main(void)
> {
> volatile uint32_t gpio;
>
> volatile uint32_t phaseBit;
>
>
> /* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
> CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;
>
> // attempt to write an SPI configuration bit and read it back
> CT_MCSPI0.CH0CONF_bit.PHA = 0x1;
> phaseBit = CT_MCSPI0.CH0CONF_bit.PHA;
>
> // by forcing phaseBit to 0 or 1 here I get the expected toggle rate below
> // phaseBit = 1;
>
>
> /* Toggle GPO pins TODO: Figure out which to use */
> gpio = 0x000F;
>
> // if phaseBit is non-zero toggle fast, otherwise toggle slow
> while (1) {
> __R30 ^= gpio;
> if(phaseBit == 0)
> {
> __delay_cycles(100); // toggle at approx 100Hz
> }
> else
> {
> __delay_cycles(50); // toggle at approx 200Hz
> }
>
> }
> }
>
>
>
>
> On Wednesday, September 7, 2016 at 3:55:36 AM UTC-7, Jason Reeder wrote:
>>
>> Kirk,
>>
>> Do a 'git pull' on your pru-software-support-package repo and the 
>> sys_mcspi.h files should be in the include/am335x/ folder. Let me know if 
>> you run into any problems while using it, I didn't have time to test it out.
>>
>> Jason Reeder
>>
>> On Saturday, September 3, 2016 at 8:30:56 AM UTC-5, Kirk wrote:
>>>
>>>
>>> OK, I see it now.  Thanks for pointing that out
>>> I overlooked it because I thought he pru_*.h files were specific to the 
>>> PRU peripherals.
>>> Should have looked closer.
>>>
>>> Here's the directory I'm looking in and the header files in it:
>>>
>>> /opt/source/pru-software-support-package/include/am335x
>>>
>>> pru_cfg.h
>>> pru_ctrl.h
>>> pru_ecap.h
>>> pru_iep.h
>>> pru_intc.h
>>> pru_uart.h
>>> sys_mailbox.h
>>> sys_pwmss.h
>>>
>>> I don't see anything for SPI0 and SPI1 on the host processor.
>>> I'll be needing to get at them too.
>>> Any ideas?
>>>
>>> Thanks,
>>> Kirk
>>>
>>>
>>>
>>> On Thursday, September 1, 2016 at 5:18:07 PM UTC-7, Jason Reeder wrote:

 Check out this header file in the PRU Software Support Package: 
 https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master

[beagleboard] Re: Header files for non PRU peripherals

2016-09-14 Thread Kirk

Jason,

I'm trying to use the new sys_mcspi.h header file which you provided.

I have a simple test program I adapted from some example code that toggles 
a gpio pin which I monitor with a scope.
I use the toggle rate seen on the scope to determine whether phaseBit is 
zero or not.
(the code is below)

The code writes a 1 to the phase control bit in the SPI config register.
Then it reads it back into the phaseBit variable.

I figure if it writes a 1 it should read back a 1.
Trouble is it's always reading back 0.
The code does what is expected if I force a 1 or 0 into phaseBit

Not sure what I'm doing wrong. (remember I'm new to PRU work)

Do does the code have to do something to enable access to the SPI registers?

Thanks,
Kirk

/*
 * Based on the examples distributed by TI
 *
 * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com/
 *
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * * Redistributions of source code must retain the above copyright
 *  notice, this list of conditions and the following disclaimer.
 *
 * * Redistributions in binary form must reproduce the above copyright
 *  notice, this list of conditions and the following disclaimer in the
 *  documentation and/or other materials provided with the
 *  distribution.
 *
 * * Neither the name of Texas Instruments Incorporated nor the names of
 *  its contributors may be used to endorse or promote products derived
 *  from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

#include 
#include 
#include 
#include 
#include "resource_table_empty.h"

volatile register uint32_t __R30;
volatile register uint32_t __R31;

void main(void)
{
volatile uint32_t gpio;

volatile uint32_t phaseBit;

/* Clear SYSCFG[STANDBY_INIT] to enable OCP master port */
CT_CFG.SYSCFG_bit.STANDBY_INIT = 0;

// attempt to write an SPI configuration bit and read it back
CT_MCSPI0.CH0CONF_bit.PHA = 0x1;
phaseBit = CT_MCSPI0.CH0CONF_bit.PHA;

// by forcing phaseBit to 0 or 1 here I get the expected toggle rate below
// phaseBit = 1;

/* Toggle GPO pins TODO: Figure out which to use */
gpio = 0x000F;

// if phaseBit is non-zero toggle fast, otherwise toggle slow
while (1) {
__R30 ^= gpio;
if(phaseBit == 0)
{
__delay_cycles(100); // toggle at approx 100Hz
}
else
{
__delay_cycles(50); // toggle at approx 200Hz
}

}
}

On Wednesday, September 7, 2016 at 3:55:36 AM UTC-7, Jason Reeder wrote:
>
> Kirk,
>
> Do a 'git pull' on your pru-software-support-package repo and the 
> sys_mcspi.h files should be in the include/am335x/ folder. Let me know if 
> you run into any problems while using it, I didn't have time to test it out.
>
> Jason Reeder
>
> On Saturday, September 3, 2016 at 8:30:56 AM UTC-5, Kirk wrote:
>>
>>
>> OK, I see it now.  Thanks for pointing that out
>> I overlooked it because I thought he pru_*.h files were specific to the 
>> PRU peripherals.
>> Should have looked closer.
>>
>> Here's the directory I'm looking in and the header files in it:
>>
>> /opt/source/pru-software-support-package/include/am335x
>>
>> pru_cfg.h
>> pru_ctrl.h
>> pru_ecap.h
>> pru_iep.h
>> pru_intc.h
>> pru_uart.h
>> sys_mailbox.h
>> sys_pwmss.h
>>
>> I don't see anything for SPI0 and SPI1 on the host processor.
>> I'll be needing to get at them too.
>> Any ideas?
>>
>> Thanks,
>> Kirk
>>
>>
>>
>> On Thursday, September 1, 2016 at 5:18:07 PM UTC-7, Jason Reeder wrote:
>>>
>>> Check out this header file in the PRU Software Support Package: 
>>> https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/include/am335x/sys_pwmss.h
>>>  
>>>
>>> The eQEP, ePWM, and eCAP modules make up the PWMSS peripheral.
>>
>>

-- 
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/331248af-61bf-465b-90d6-aa2d52832d01%40googlegroups.com.
For

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-09 Thread Kirk

Makes sense.  Thanks for your ideas.
Is there a header file, along the lines of sys_mcspi.h that Jason provided, 
that you use for the GPIO?

Kirk


On Wednesday, September 7, 2016 at 2:28:43 PM UTC-7, Charles Steinkuehler 
wrote:
>
> On 9/7/2016 1:02 PM, Kirk wrote: 
> > 
> > What is the recommended way to access NON PRU GPIO pins? 
> > 
> > I'm asking because I'm working with a custom cape board on the 
> Beaglebone Black 
> > that has already been built. 
> > And I'm trying to move some time critical code to the PRU. 
> > I don't think all the GPIO pins that are used are in the group of PRU 
> GPIO pins. 
>
> IMHO it works best if you setup the GPIO banks with Linux, then use 
> the PRU to twiddle the output bits using the set and clear registers 
> in the GPIO bank.  That way you don't have to worry about any sort of 
> locking to insure consistent updates.  Note the Linux side also needs 
> to use the set/clear registers for output updates (and not a 
> read-modify-write sequence) to insure no updates get lost. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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/323348a0-6800-4b5d-9450-d08d5a364f45%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-08 Thread William Hermans

*25.4.1.18 GPIO_DATAOUT Register (offset = 13Ch) [reset = 0h]*

*GPIO_DATAOUT is shown in Figure 25-24 and described in Table 25-23.*

The GPIO_DATAOUT register is used for setting the value of the GPIO output
pins. Data is written to the
GPIO_DATAOUT register synchronously with the interface clock. This register
can be accessed with
direct read/write operations or using the alternate Set/Clear feature. This
feature enables to set or clear
specific bits of this register with a single write access to the set data
output register
(GPIO_SETDATAOUT) or to the clear data output register (GPIO_CLEARDATAOUT)
address.

Ok thats confusing . . .but I guess I read this and understood the opposite
of what it's saying ? e.g. I was thinking DATAOUT would be fast ?

On Thu, Sep 8, 2016 at 1:56 PM, William Hermans  wrote:

> Oh...while we're on the subject, there's one more significant reason
>> the set/clear registers are helpful even if you're not worried about
>> multi-threaded operation:  They're *FAST*
>>
>
> I did notice that it seemed to be that way from your description. But the
> way I read the TRM. TO me it seems that the SETDATA(direction) registers
> actually write to DATAOUT. did I read that wrong ?
>
> On Thu, Sep 8, 2016 at 1:51 PM, Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
>
>> On 9/8/2016 3:35 PM, Charles Steinkuehler wrote:
>> > On 9/8/2016 12:41 PM, William Hermans wrote:
>> >>
>> >> It has long been programing technique to use DATAOUT |= BITx to set a
>> register
>> >> bit DATAOUT &= (~BITx) to clear a register bit, or something like
>> if(DATAOUT &
>> >> BITx){} or if((DATAOUT &BITx) == 0 or 1) to read a bit from a register.
>> >
>> > Yes, it has.  But those short-hand snippits of C code are hiding an
>> > implicit read-modify-write cycle:
>> >
>> > DATAOUT |= BITx
>> >
>> > ...turns into:
>> >
>> > Read  :  = DATAOUT
>> > Modify:  =  | BITx
>> > Write : DATAOUT = 
>> >
>> > ...where  is probably a CPU register (unless your C compiler is
>> > _really_ bad!).  But if you use the set/clear registers it's just:
>> >
>> > Write : SETDATAOUT = BITx
>>
>> Oh...while we're on the subject, there's one more significant reason
>> the set/clear registers are helpful even if you're not worried about
>> multi-threaded operation:  They're *FAST*
>>
>> The ARM core on the BBB is running at 1 GHz, but the I/O is only
>> running at about 100 MHz.  So that simple DATAOUT |= BITx stalls the
>> CPU until the system can provide the current value of DATAOUT to the
>> processor core, which likely takes a couple hundred nanoseconds (based
>> on the time it takes for the PRU to read a GPIO register).
>>
>> The write, however, is very fast (for both the set/clear case and for
>> writing directly to DATAOUT).  Writes are posted and the ARM has weak
>> memory ordering, so as long as you're not saturating the on-chip
>> interconnect fabric, the write will appear to complete instantly, the
>> ARM core will carry on executing instructions, and about 100 nS later
>> the GPIO register will update with the new value once the write
>> transaction has worked it's way through the on-chip interconnect fabric.
>>
>> --
>> Charles Steinkuehler
>> char...@steinkuehler.net
>>
>> --
>> 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/ms
>> gid/beagleboard/66e45786-85b9-2302-bef4-3213f6848a8d%40steinkuehler.net.
>> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrCVVmifF_V1KyUFwpGb-X%3D0j8o%3DeGMQwOtXHawK%2Bx-Vg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-08 Thread William Hermans

>
> Oh...while we're on the subject, there's one more significant reason
> the set/clear registers are helpful even if you're not worried about
> multi-threaded operation:  They're *FAST*
>

I did notice that it seemed to be that way from your description. But the
way I read the TRM. TO me it seems that the SETDATA(direction) registers
actually write to DATAOUT. did I read that wrong ?

On Thu, Sep 8, 2016 at 1:51 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/8/2016 3:35 PM, Charles Steinkuehler wrote:
> > On 9/8/2016 12:41 PM, William Hermans wrote:
> >>
> >> It has long been programing technique to use DATAOUT |= BITx to set a
> register
> >> bit DATAOUT &= (~BITx) to clear a register bit, or something like
> if(DATAOUT &
> >> BITx){} or if((DATAOUT &BITx) == 0 or 1) to read a bit from a register.
> >
> > Yes, it has.  But those short-hand snippits of C code are hiding an
> > implicit read-modify-write cycle:
> >
> > DATAOUT |= BITx
> >
> > ...turns into:
> >
> > Read  :  = DATAOUT
> > Modify:  =  | BITx
> > Write : DATAOUT = 
> >
> > ...where  is probably a CPU register (unless your C compiler is
> > _really_ bad!).  But if you use the set/clear registers it's just:
> >
> > Write : SETDATAOUT = BITx
>
> Oh...while we're on the subject, there's one more significant reason
> the set/clear registers are helpful even if you're not worried about
> multi-threaded operation:  They're *FAST*
>
> The ARM core on the BBB is running at 1 GHz, but the I/O is only
> running at about 100 MHz.  So that simple DATAOUT |= BITx stalls the
> CPU until the system can provide the current value of DATAOUT to the
> processor core, which likely takes a couple hundred nanoseconds (based
> on the time it takes for the PRU to read a GPIO register).
>
> The write, however, is very fast (for both the set/clear case and for
> writing directly to DATAOUT).  Writes are posted and the ARM has weak
> memory ordering, so as long as you're not saturating the on-chip
> interconnect fabric, the write will appear to complete instantly, the
> ARM core will carry on executing instructions, and about 100 nS later
> the GPIO register will update with the new value once the write
> transaction has worked it's way through the on-chip interconnect fabric.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> --
> 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/66e45786-85b9-2302-bef4-3213f6848a8d%40steinkuehler.net.
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqzEj8dmkmxmpftnCY5RTGVg5f9HKzoAeZhR%3DdE_xH2TA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-08 Thread Charles Steinkuehler

On 9/8/2016 3:35 PM, Charles Steinkuehler wrote:
> On 9/8/2016 12:41 PM, William Hermans wrote:
>>
>> It has long been programing technique to use DATAOUT |= BITx to set a 
>> register 
>> bit DATAOUT &= (~BITx) to clear a register bit, or something like if(DATAOUT 
>> & 
>> BITx){} or if((DATAOUT &BITx) == 0 or 1) to read a bit from a register.
> 
> Yes, it has.  But those short-hand snippits of C code are hiding an
> implicit read-modify-write cycle:
> 
> DATAOUT |= BITx
> 
> ...turns into:
> 
> Read  :  = DATAOUT
> Modify:  =  | BITx
> Write : DATAOUT = 
> 
> ...where  is probably a CPU register (unless your C compiler is
> _really_ bad!).  But if you use the set/clear registers it's just:
> 
> Write : SETDATAOUT = BITx

Oh...while we're on the subject, there's one more significant reason
the set/clear registers are helpful even if you're not worried about
multi-threaded operation:  They're *FAST*

The ARM core on the BBB is running at 1 GHz, but the I/O is only
running at about 100 MHz.  So that simple DATAOUT |= BITx stalls the
CPU until the system can provide the current value of DATAOUT to the
processor core, which likely takes a couple hundred nanoseconds (based
on the time it takes for the PRU to read a GPIO register).

The write, however, is very fast (for both the set/clear case and for
writing directly to DATAOUT).  Writes are posted and the ARM has weak
memory ordering, so as long as you're not saturating the on-chip
interconnect fabric, the write will appear to complete instantly, the
ARM core will carry on executing instructions, and about 100 nS later
the GPIO register will update with the new value once the write
transaction has worked it's way through the on-chip interconnect fabric.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/66e45786-85b9-2302-bef4-3213f6848a8d%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-08 Thread William Hermans

I guess I just tend to think, and do things a bit differently than some, or
maybe even most.

1) If I could avoid having writes happen on both sides I would. Normally
this isn't an issue, but if it is, see 2.
2) If writes *had* to happen on both sides. I would implement a locking
mechanism. A single bit somewhere in the PRU's shared memory.

I did this with an application I wrote that read data out of the CANBUS,
and had to write the parsed data to a shared memory file. Where locking
semaphores were far too slow. As I was writing around 1400 data parameters
out over a websocket a second. Where the second half of the app( separate
process ) had to be on the ball, and send that data out in real-time as it
was available . . . Anyway, first half of the application would only write
if this bit were set to 0 while the second half would only read while bit
was set to 1. So in effect, a blocking write, then read, but it turned out
to be very fast.

Anyway, I think this is similar how I would approach what's being discussed
here.

On Thu, Sep 8, 2016 at 1:38 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/8/2016 1:40 PM, William Hermans wrote:
> > So here is my contention, but note that I'm emailing you directly.
> Because it is
> > not my intention necessarily to argue with you, and feel good or
> righteous
> > about. Especially since I have nearly no hands on with the PRU's or how
> they
> > behave in relation to usrspace, or even kernelspace Linux.
> >
> > 25.4.1.18 GPIO_DATAOUT Register (offset = 13Ch) [reset = 0h]
>
> Yes, the TRM correctly describes the behavior of the DATAOUT,
> SETDATAOUT, and CLEARDATAOUT registers, but I don't think you
> understand the potential contention issues in a multi-threaded system
> which is what makes the set/clear registers very helpful.  Believe me,
> they wouldn't be in the hardware if they didn't have a very useful
> purpose!  :)
>
> I replied with more details to your post on the list.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
>

-- 
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/CALHSORr2yE4C7yZ5kJO6ZQcPwHkZPMFZNSjq%3D6wt5pbgjgzxig%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-08 Thread Charles Steinkuehler

On 9/8/2016 12:41 PM, William Hermans wrote:
> 
> 
> On Thu, Sep 8, 2016 at 6:36 AM, Charles Steinkuehler 
>  > wrote:
> 
> On 9/7/2016 7:50 PM, William Hermans wrote:
> >
> > SETDATAOUT -> |= BITx
> > CLEARDATAOUT -> &=(~BITx)
> >
> > I gues I'll have to reread the TRM again.
> 
> The set/clear registers only affect the bits that are written with a
> '1' value, all other bits remain unchanged, while writing directly to
> the DATAOUT register affects the value of all 32 bits in the GPIO
> bank.  Using the set/clear registers allows a single atomic write
> operation to affect the specific bit(s) you want to change without
> having to perform a non-atomic read-modify-write cycle.
> 
> Since the write to the set or clear register is atomic, if both the
> ARM and the PRU both use this method, no locks or other hand-shaking
> is required to prevent corruption.
> 
> --
> Charles Steinkuehler
> char...@steinkuehler.net 
> 
> 
> It has long been programing technique to use DATAOUT |= BITx to set a 
> register 
> bit DATAOUT &= (~BITx) to clear a register bit, or something like if(DATAOUT 
> & 
> BITx){} or if((DATAOUT &BITx) == 0 or 1) to read a bit from a register.

Yes, it has.  But those short-hand snippits of C code are hiding an
implicit read-modify-write cycle:

DATAOUT |= BITx

...turns into:

Read  :  = DATAOUT
Modify:  =  | BITx
Write : DATAOUT = 

...where  is probably a CPU register (unless your C compiler is
_really_ bad!).  But if you use the set/clear registers it's just:

Write : SETDATAOUT = BITx

If you have multi-threaded code (or interrupts or the PRU) that can
modify GPIO output states, you have to protect the read-modify-write
cycle with some sort of lock.  With the set/clear registers, no lock
is necessary for reliable operation.

> So I'm having a very hard time taking what you're saying without a grain of 
> salt. Especially after having read that section of the TRM in detail, and not 
> getting what you got from it. But I do feel that if you read a gpio register 
> bit 
> first, before writing to it there should be no contention as to what the 
> register should be.

In a multi-threaded system, the time between the read and the write in
the read-modify-write cycle is when corruption can happen.  If another
process writes to the GPIO after the read, but before the write, that
update can get lost (this was covered in a previous email with
specific examples).  Take with as much salt as required for it to make
sense, but controlling access to shared resources (like a GPIO bank,
or a shared variable) is a very basic part of multi-threaded
programming...but it's still _really_ easy to get wrong!

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/8e97f79a-7c13-9c0b-b5e4-5e0bf26c0799%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-08 Thread William Hermans

On Thu, Sep 8, 2016 at 6:36 AM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/7/2016 7:50 PM, William Hermans wrote:
> >
> > SETDATAOUT -> |= BITx
> > CLEARDATAOUT -> &=(~BITx)
> >
> > I gues I'll have to reread the TRM again.
>
> The set/clear registers only affect the bits that are written with a
> '1' value, all other bits remain unchanged, while writing directly to
> the DATAOUT register affects the value of all 32 bits in the GPIO
> bank.  Using the set/clear registers allows a single atomic write
> operation to affect the specific bit(s) you want to change without
> having to perform a non-atomic read-modify-write cycle.
>
> Since the write to the set or clear register is atomic, if both the
> ARM and the PRU both use this method, no locks or other hand-shaking
> is required to prevent corruption.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net

It has long been programing technique to use DATAOUT |= BITx to set a
register bit DATAOUT &= (~BITx) to clear a register bit, or something like
if(DATAOUT & BITx){} or if((DATAOUT &BITx) == 0 or 1) to read a bit from a
register.

So I'm having a very hard time taking what you're saying without a grain of
salt. Especially after having read that section of the TRM in detail, and
not getting what you got from it. But I do feel that if you read a gpio
register bit first, before writing to it there should be no contention as
to what the register should be.

With that said, I've only ever used /dev/mem + mmap(), but have never done
this with a PRU to date. So, while I do firmly believe in what I say above,
I do have respect for what you're saying. Plus I do know you have hands on
with the PRU . . . I wonder if anyone could whip up a test case for others
to play around with- to demonstrate 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/CALHSORr_8zckA59v6qwp50D3mookqT2Sr2tg1-3Vi2gQZjGzdw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-08 Thread Charles Steinkuehler

On 9/7/2016 7:50 PM, William Hermans wrote:
> 
> SETDATAOUT -> |= BITx
> CLEARDATAOUT -> &=(~BITx)
> 
> I gues I'll have to reread the TRM again.

The set/clear registers only affect the bits that are written with a
'1' value, all other bits remain unchanged, while writing directly to
the DATAOUT register affects the value of all 32 bits in the GPIO
bank.  Using the set/clear registers allows a single atomic write
operation to affect the specific bit(s) you want to change without
having to perform a non-atomic read-modify-write cycle.

Since the write to the set or clear register is atomic, if both the
ARM and the PRU both use this method, no locks or other hand-shaking
is required to prevent corruption.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/4db8f6f0-f70a-0d28-29f9-3d0aba8dd690%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-07 Thread William Hermans

On Wed, Sep 7, 2016 at 5:39 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> On 9/7/2016 5:18 PM, William Hermans wrote:
> >
> > I agree with Charles with one exception. I personally prefer to use
> DATAOUT
> > directly instead of using SETDATAOUT / CLEARDATAOUT.
>
> If you write directly to DATAOUT from either the PRU or the ARM side,
> you risk data corruption.  Example access patterns causing data
> corruption:
>
> 1:
> * PRU reads DATAOUT
> * ARM modifies DATAOUT
> * PRU writes DATAOUT
> * ARM Update is *LOST*
>
> 2:
> * ARM reads DATAOUT
> * PRU modifies DATAOUT
> * ARM writes DATAOUT
> * PRU update is *LOST*
>
> Both the PRU and the ARM need to use the set/clear registers for
> updates or some updtes can get *LOST* (which can be *REALLY* hard to
> debug in the RealWorld).
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
>
It does not say anything about that in the TRM. In fact as I recall it
mentions that SETDATAOUT, and CLEARDATAOUT directly write to DATAOUT.
Something like

SETDATAOUT -> |= BITx
CLEARDATAOUT -> &=(~BITx)

I gues I'll have to reread the TRM again.

-- 
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/CALHSORpxBHmNoHRQDEi8VjJKc1zup0AEoH7MWnZURi0fieDX-Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-07 Thread Charles Steinkuehler

On 9/7/2016 5:18 PM, William Hermans wrote:
> 
> I agree with Charles with one exception. I personally prefer to use DATAOUT 
> directly instead of using SETDATAOUT / CLEARDATAOUT.

If you write directly to DATAOUT from either the PRU or the ARM side,
you risk data corruption.  Example access patterns causing data
corruption:

1:
* PRU reads DATAOUT
* ARM modifies DATAOUT
* PRU writes DATAOUT
* ARM Update is *LOST*

2:
* ARM reads DATAOUT
* PRU modifies DATAOUT
* ARM writes DATAOUT
* PRU update is *LOST*

Both the PRU and the ARM need to use the set/clear registers for
updates or some updtes can get *LOST* (which can be *REALLY* hard to
debug in the RealWorld).

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/c7da32a4-e33f-3c60-eafd-66fc188595f5%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-07 Thread William Hermans

On Wed, Sep 7, 2016 at 2:28 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

>
> IMHO it works best if you setup the GPIO banks with Linux, then use
> the PRU to twiddle the output bits using the set and clear registers
> in the GPIO bank.  That way you don't have to worry about any sort of
> locking to insure consistent updates.  Note the Linux side also needs
> to use the set/clear registers for output updates (and not a
> read-modify-write sequence) to insure no updates get lost.
>
> --
> Charles Steinkuehler
> char...@steinkuehler.net
>
> I agree with Charles with one exception. I personally prefer to use
DATAOUT directly instead of using SETDATAOUT / CLEARDATAOUT.

I'd actually recommend that people also let the OS setup stuff like the ADC
as well. Then just read form the FIFO buffer.

-- 
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/CALHSORra_zbyps%3D0hiGxCLTkPiQR-R6kGimgwkuwCV37Q_uKnw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Header files for non PRU peripherals

2016-09-07 Thread Charles Steinkuehler

On 9/7/2016 1:02 PM, Kirk wrote:
> 
> What is the recommended way to access NON PRU GPIO pins?
> 
> I'm asking because I'm working with a custom cape board on the Beaglebone 
> Black 
> that has already been built.
> And I'm trying to move some time critical code to the PRU.
> I don't think all the GPIO pins that are used are in the group of PRU GPIO 
> pins.

IMHO it works best if you setup the GPIO banks with Linux, then use
the PRU to twiddle the output bits using the set and clear registers
in the GPIO bank.  That way you don't have to worry about any sort of
locking to insure consistent updates.  Note the Linux side also needs
to use the set/clear registers for output updates (and not a
read-modify-write sequence) to insure no updates get lost.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
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/a43516b8-e0f1-d8f0-8850-505077dc9689%40steinkuehler.net.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Header files for non PRU peripherals

2016-09-07 Thread Kirk

Jason,
I just grabbed the sys_mcspi.h file.  Much appreciated!  I'll let you know 
how it goes.  I'm still climbing up the learning curve.

While I have your attention can I ask you one other question:

What is the recommended way to access NON PRU GPIO pins?

I'm asking because I'm working with a custom cape board on the Beaglebone 
Black that has already been built.
And I'm trying to move some time critical code to the PRU.
I don't think all the GPIO pins that are used are in the group of PRU GPIO 
pins.

Thanks again,
Kirk
 


On Wednesday, September 7, 2016 at 3:55:36 AM UTC-7, Jason Reeder wrote:
>
> Kirk,
>
> Do a 'git pull' on your pru-software-support-package repo and the 
> sys_mcspi.h files should be in the include/am335x/ folder. Let me know if 
> you run into any problems while using it, I didn't have time to test it out.
>
> Jason Reeder
>
> On Saturday, September 3, 2016 at 8:30:56 AM UTC-5, Kirk wrote:
>>
>>
>> OK, I see it now.  Thanks for pointing that out
>> I overlooked it because I thought he pru_*.h files were specific to the 
>> PRU peripherals.
>> Should have looked closer.
>>
>> Here's the directory I'm looking in and the header files in it:
>>
>> /opt/source/pru-software-support-package/include/am335x
>>
>> pru_cfg.h
>> pru_ctrl.h
>> pru_ecap.h
>> pru_iep.h
>> pru_intc.h
>> pru_uart.h
>> sys_mailbox.h
>> sys_pwmss.h
>>
>> I don't see anything for SPI0 and SPI1 on the host processor.
>> I'll be needing to get at them too.
>> Any ideas?
>>
>> Thanks,
>> Kirk
>>
>>
>>
>> On Thursday, September 1, 2016 at 5:18:07 PM UTC-7, Jason Reeder wrote:
>>>
>>> Check out this header file in the PRU Software Support Package: 
>>> https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/include/am335x/sys_pwmss.h
>>>  
>>>
>>> The eQEP, ePWM, and eCAP modules make up the PWMSS peripheral.
>>
>>

-- 
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/f23c7d5e-a732-4536-8f3f-624743c3b9bc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Header files for non PRU peripherals

2016-09-07 Thread Jason Reeder

Kirk,

Do a 'git pull' on your pru-software-support-package repo and the 
sys_mcspi.h files should be in the include/am335x/ folder. Let me know if 
you run into any problems while using it, I didn't have time to test it out.

Jason Reeder

On Saturday, September 3, 2016 at 8:30:56 AM UTC-5, Kirk wrote:
>
>
> OK, I see it now.  Thanks for pointing that out
> I overlooked it because I thought he pru_*.h files were specific to the 
> PRU peripherals.
> Should have looked closer.
>
> Here's the directory I'm looking in and the header files in it:
>
> /opt/source/pru-software-support-package/include/am335x
>
> pru_cfg.h
> pru_ctrl.h
> pru_ecap.h
> pru_iep.h
> pru_intc.h
> pru_uart.h
> sys_mailbox.h
> sys_pwmss.h
>
> I don't see anything for SPI0 and SPI1 on the host processor.
> I'll be needing to get at them too.
> Any ideas?
>
> Thanks,
> Kirk
>
>
>
> On Thursday, September 1, 2016 at 5:18:07 PM UTC-7, Jason Reeder wrote:
>>
>> Check out this header file in the PRU Software Support Package: 
>> https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/include/am335x/sys_pwmss.h
>>  
>>
>> The eQEP, ePWM, and eCAP modules make up the PWMSS peripheral.
>
>

-- 
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/dfcfa1ad-3a60-4aa8-b07e-6fa58871e796%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Header files for non PRU peripherals

2016-09-03 Thread Kirk


OK, I see it now.  Thanks for pointing that out
I overlooked it because I thought he pru_*.h files were specific to the PRU 
peripherals.
Should have looked closer.

Here's the directory I'm looking in and the header files in it:

/opt/source/pru-software-support-package/include/am335x

pru_cfg.h
pru_ctrl.h
pru_ecap.h
pru_iep.h
pru_intc.h
pru_uart.h
sys_mailbox.h
sys_pwmss.h

I don't see anything for SPI0 and SPI1 on the host processor.
I'll be needing to get at them too.
Any ideas?

Thanks,
Kirk

On Thursday, September 1, 2016 at 5:18:07 PM UTC-7, Jason Reeder wrote:
>
> Check out this header file in the PRU Software Support Package: 
> https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/include/am335x/sys_pwmss.h
>  
>
> The eQEP, ePWM, and eCAP modules make up the PWMSS peripheral.

-- 
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/7d72eeb2-c25c-4ff8-a61c-e7b9a6d44cf9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Header files for non PRU peripherals

2016-09-03 Thread Kirk


OK, I see it now.  Thanks for pointing that out
I overlooked it because I thought he pru_*.h files were specific to the PRU 
peripherals.
Should have looked closer.

Here's the directory I'm looking in and the header files in it:

/opt/source/pru-software-support-package/include/am335x

pru_cfg.h
pru_ctrl.h
pru_ecap.h
pru_iep.h
pru_intc.h
pru_uart.h
sys_mailbox.h
sys_pwmss.h

I don't see anything for SPI0 and SPI1 on the host processor.
I'll be needing to get at them too.
Any ideas?

Thanks,
Kirk



On Thursday, September 1, 2016 at 5:18:07 PM UTC-7, Jason Reeder wrote:
>
> Check out this header file in the PRU Software Support Package: 
> https://git.ti.com/pru-software-support-package/pru-software-support-package/blobs/master/include/am335x/sys_pwmss.h
>  
>
> The eQEP, ePWM, and eCAP modules make up the PWMSS peripheral.

-- 
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/2e83b6fa-a6a5-4f46-a41a-694034b71d0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Header files for non PRU peripherals

[beagleboard] Re: Header files for non PRU peripherals

[beagleboard] Re: Header files for non PRU peripherals

[beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

Re: [beagleboard] Re: Header files for non PRU peripherals

[beagleboard] Re: Header files for non PRU peripherals

[beagleboard] Re: Header files for non PRU peripherals

[beagleboard] Re: Header files for non PRU peripherals

[beagleboard] Re: Header files for non PRU peripherals

20 matches

Site Navigation

Mail list logo

Footer information