Part Number: AM3358
First the simple question.
How does one prevent a dedicated hobbyist or an IP ripoff site from copying our IP burned into an AM335x’s flash ROM? Please direct me to the documentation where I can find out how to protect our IP.
Now the more complex question.
My boss wants me to write a driver using the PRU-ICSS. I’ve seen enough PRU documentation to know writing that driver is well within my capabilities. But first I will have to learn the PRU instruction set. So far I have been unable to find the compiler/assembler that is said to run on Linux on your A8 products. What I need to get started learning PRU-ICSS code is a Windows version that can compile/assemble PRU code. And a Windows PRU simulator where I can practice. The documentation I have seen so far extols the speed and predictability of the PRU. But the documentation is unhelpful when it fails to mention little things like . . .
I think that the PRU has the ability to fetch one of its program memory words into a register. But can it store a register in its program memory? I read about 3 sets of r0-29. How is this managed? I see things like r5.b2 for byte 2 in register 5. This will be useful for my driver. But can I fetch a 3-bit field in one register and add it to a 5-bit field in another register? What are the limits of arbitrarily sized bit field operations? I’m confused about the carry flag. As I understand the PRU now, the only PRU assembly code I’ve seen has a nasty bug. (The code says it’s multiplying pairs of 32-bit integers and summing the 64-bit products. And it’s written as if the carry flag works like it does in regular ARM assembly.) Or my understanding is off? There is dedicated I/O space in the A8 for PRU memory access. I assume I could read 6 words from that region at 5 nSec per word. Is that assumption correct? I also assume that my PRU code can read or write anywhere in the A8’s 4-gigabyte address space. This, especially for flash ROM access, will require wait states. How is this managed?
The first cut on my driver will only write to I/O pins. However, the device I am driving is bidirectional on an 8-bit bus. Thus the input and output pins for each bit will have to be connected. That means that the output pins will have to be set to high impedance to allow my device to send data. Will A8 code have to do this for my driver, or can my driver reach into the GPIO pin setup and do this without assistance?
About me:
My experience extends back to the first generation of supercomputers, the CDC 6000 series. Most of my work was with the PPU I/O coprocessors. The PP’s, as they where known, were 4Kx12 bit at 1 MHz. PPs could read or write to any 60-bit main memory word in 5 clocks. On the 6000 series mainframes, PPs were the ONLY way ANY I/O could be performed. Most systems had 10 PPs. Some few systems had 20 PPs.
How does one prevent a dedicated hobbyist or an IP ripoff site from copying our IP burned into an AM335x’s flash ROM? Please direct me to the documentation where I can find out how to protect our IP.
Now the more complex question.
My boss wants me to write a driver using the PRU-ICSS. I’ve seen enough PRU documentation to know writing that driver is well within my capabilities. But first I will have to learn the PRU instruction set. So far I have been unable to find the compiler/assembler that is said to run on Linux on your A8 products. What I need to get started learning PRU-ICSS code is a Windows version that can compile/assemble PRU code. And a Windows PRU simulator where I can practice. The documentation I have seen so far extols the speed and predictability of the PRU. But the documentation is unhelpful when it fails to mention little things like . . .
I think that the PRU has the ability to fetch one of its program memory words into a register. But can it store a register in its program memory? I read about 3 sets of r0-29. How is this managed? I see things like r5.b2 for byte 2 in register 5. This will be useful for my driver. But can I fetch a 3-bit field in one register and add it to a 5-bit field in another register? What are the limits of arbitrarily sized bit field operations? I’m confused about the carry flag. As I understand the PRU now, the only PRU assembly code I’ve seen has a nasty bug. (The code says it’s multiplying pairs of 32-bit integers and summing the 64-bit products. And it’s written as if the carry flag works like it does in regular ARM assembly.) Or my understanding is off? There is dedicated I/O space in the A8 for PRU memory access. I assume I could read 6 words from that region at 5 nSec per word. Is that assumption correct? I also assume that my PRU code can read or write anywhere in the A8’s 4-gigabyte address space. This, especially for flash ROM access, will require wait states. How is this managed?
The first cut on my driver will only write to I/O pins. However, the device I am driving is bidirectional on an 8-bit bus. Thus the input and output pins for each bit will have to be connected. That means that the output pins will have to be set to high impedance to allow my device to send data. Will A8 code have to do this for my driver, or can my driver reach into the GPIO pin setup and do this without assistance?
About me:
My experience extends back to the first generation of supercomputers, the CDC 6000 series. Most of my work was with the PPU I/O coprocessors. The PP’s, as they where known, were 4Kx12 bit at 1 MHz. PPs could read or write to any 60-bit main memory word in 5 clocks. On the 6000 series mainframes, PPs were the ONLY way ANY I/O could be performed. Most systems had 10 PPs. Some few systems had 20 PPs.
