#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) ) {
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
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
*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
>
> 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
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
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
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
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
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
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
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
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
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
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
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
16 matches
Mail list logo
