or is bit-banging the only way to achieve this?
thanks in advance,
- Michael
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
or is bit-banging the only way to achieve this?
thanks in advance,
- Michael
PRUs do have access to all system peripherals. This is not as fast as the PRU-ICSS integrated peripherals access but it works and we have used SPI with PRU before.
Regards.
Hi Frank,
thanks for the hint.
I assume you used memory-mapped I/O to talk the SPI logic, just that memory access comes from the PRU, not from the main CPU?
best regards
Michael
Hallo Frank,
it's really motivating to hear that a SPI-Module is enabled using PRU. I've been working on it for a long while but without results :/. Do U have any sample code ?
thanks.
Hello,
I need to complete a fast ADC / DAC with some numeric matrix calculation. I thought about using a BBB, and the PRUs seemed to be a very interesting point. The numeric part could be done using Xenomai.
You said that the use of SPI with the PRUs is possible. So can I use SPI ADC / DAC with the PRU ?
Could you be more precise on how to do ? Write SPI drivers for the PRU ?
If I was not clear enough, tell me :)
Thank you very much
Hi Alexis,
The PRU core(s) have direct access to system peripherals such as the SPI port, so there is nothing preventing you from accessing an ADC/DAC assuming it can keep up from a MIPS perspective.
As the PRU does not run the Linux kernel the kernel drivers are not available to the PRU cores; however, if you were to write some code for the PRU to handle the SPI port (i.e., a "driver" as you mentioned) then you could indeed service a DAC/ADC.
Hi Tim, thanks for your answer.
What do you mean by "assuming it can keep up from a MIPS perspective" ?
In which documentation can I find most useful information how to write the code to use ADC/DAC for the PRU via SPI port ?
Alexis,
As long as you are not trying to get the PRU to run more code than it can handle then there's no issue.Alexis Martin said:What do you mean by "assuming it can keep up from a MIPS perspective" ?
Can the PRU access to all ARM register? I tried with a GPIO register address (0x4804c0194 for example, see this link ) and modify a value of a bit in a register, display it by shifting out the register loaded after the modification.
But when I try to modify SPI register it doesn't work. Here is my code, I visualize the value of r4 using the PRU shift out register.
// Enable OCP master port
LBCO r0, CONST_PRUCFG, 4, 4
CLR r0, r0, 4 // Clear SYSCFG[STANDBY_INIT] to enable OCP master port
SBCO r0, CONST_PRUCFG, 4, 4
MOV r1, 0x4803012C // address of SPI_CONF_CH0 register
LBBO r2, r1, 0, 4 // Load MCSPI_CH0CONF Register (for SPI0)
//SPICLK polarity
//0h = SPICLK is held high during the active state 1h = SPICLK is held low during the active state
SET r2.t1
SBBO r2, r1, 0, 4 // copy to MCSPI_CH0CONF Register (for SPI0)
LBBO r4, r1, 0, 4 // and I get 0x00000000
Is it at least possible to make SPI working with this method, by modifying bits into registers ? Am I missing something obvious? I tried with a SPI0 disabled with device tree and SPI1 enabled with device tree and I have the same results.
I don't want to use the kernel space and SPI driver in C. Is there an other way to do it ? Like I said in previous post "write" a SPI "driver" in assembler could be quite complicated, right?
Thanks a lot!