[beagleboard] PRU to DMA DDR caching issues
Tom, I had a hard time understanding exactly what your problem is, so I really don't have an answer for you. I'll just try to address the "what you are trying to do part", because it seems you may be making things harder on yourself. Firstly, I am taking that what you mean by "a nanosecond scale" is actually "on the order of nanoseconds". A PRU instruction takes 5ns to execute and I'm counting at least 4 or 5 instructions in that loop. A solution for you to completely avoid the issues you have by using another pin (polled by the linux kernel, which will give you some non deterministic timing) is to do everything in the PRU. First, use the dedicated RAM in the PRUs. The bridge to the rest of the ARM core (OCP) is not in the real-time domain of the PRUs and has to deal with clashes and resources being occupied by the kernel. Second, use the PRU to ARM interrupt to signal that there was an edge. You'll get less latency and lower jitter, although you really can't do much better than lower here. Also, PRUs have two RAM banks so you can do a ping pong buffer too. If your problem requires you to do some action on the rising edges (and any delay or jitter is unacceptable in your application), I would suggest you do everything in the PRUs (if it is not too complicated, after all there's some code size limitations). Sorry I couldn't be of more help. If you give me more details on your applications, I can try again... ;) Cheers! -- 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/d/optout.
[beagleboard] Re: C code for PRU writing to shared RAM
That is one of those little things you need to be careful when writing code for the clpru: that code will work fine for pasm, but clpru will complain (I am talking about the assembly, no idea about inline or C, I've only worked with assembly in the PRU). Basically two things: 1) you need to "dereference origin registers" (I have no better way to say this, just use &): SBBO , r0, 0, 4; 2) you need to explicitly use LDI instead of MOV when working with immediate values. In your case, LDI32: e.g., LDI32r3, 0x You can try this and see if it helps. Cheers! -- 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/d/optout.
[beagleboard] Re: PRU memory layout and linker command file
It depends a lot on what you are using. Are you programming in C or assembly? I'll assume you are using TI's compiler (since pasm doesn't really use linker files). If you are programming in assembly, then you don't really care about most of the stack and other constructs the compiler will create. What this memory map is saying is that you have 8kB of instructions and 8kB of data RAM. The ARM core can access that data RAM and write on that. I've only programmed the PRU in asm, so I don't really know how it would go for C. BTW, the information you are looking for is in TI's compiler manual (http://www.ti.com/lit/ug/spruhv7a/spruhv7a.pdf). You might find the assembly language description from http://www.ti.com/lit/ug/spruhv6a/spruhv6a.pdf useful. Cheers, -- 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/d/optout.
[beagleboard] Re: more than two interrupts with a pru
I don't remember exactly, but I don't think there are more than 2 PRU-ARM
interrupts on the PRUs. I believe the other interrupts can be mapped to
system interrupts using the interrupt map that you pass to
prussdrv_pruintc_init() (you'd have to write your own instead of using
PRUSS_INTC_INITDATA). It's been a while since I saw this, so maybe someone
else should confirm this.
An alternative solution to your problem is use something like a interrupt
vector, i.e., use part of the PRU RAM (maybe the first byte) to identify
which interrupt happened. You'd send the interrupt as
; Set c24 and c25 (data RAM in PRU1 and PRU0)
LDI32 r0, 0x24020
LDI r1, 0
SBBO , r0, 0, 4
MOV , INTERRUPT_NUMBER
SBCO r28, c24, 0, 4 ; Not sure about this
line, you should check
MOV r31.b0, 32 | PRU_EVTOUT_0
and read it as
prussdrv_map_prumem(PRUSS0_PRU1_DATARAM, _mem); /* You might
need to cast this to uint32_t */
prussdrv_pru_wait_event (PRU_EVTOUT_1);
prussdrv_pru_clear_event (PRU_EVTOUT_1, PRU1_ARM_INTERRUPT);
if(pru_mem1 == 0){
} else if (pru_mem1 == 1){
} ...
This is sort of a sketch, no guarantees it will work out of the box! Still,
hope it helps...
--
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/d/optout.
[beagleboard] Re: more than two interrupts with a pru
The PRU have 10 interrupts: 2 for the host and 8 that are exported to general ARM interrupts. You should check page 225 of the TRM. Host 0 and Host 1 (which are the low bits on the INTC0 register or something like that) are reserved for the PRUs to signal the ARM core. The other 8 can be attached to many different interrupts (64 with codes presented in Table 4.21 of the TRM). I recall vaguely concluding that it wasn't possible (or was too complicated) when I looked into that, but if you find a way it's great. Still, you'll have to rewrite the INTC initialization vector yourself to associate the appropriate interrupts to each channel and each channel to each host. If your application is not really sensitive to timing issues (i.e., if you can manage to stick a few more commands in there to control/check for the interrupts), I would not bother and would simply implement an interrupt vector. -- 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/d/optout.
Re: [beagleboard] Random shutdown
That makes sense... I'll try to upgrade soon then. From what I understand there is no cape manager in the 3.14, right? I would have to load the device tree at boot time (editing uEnv?!), correct? Thank you very much for your help! -- Luiz CHAMON Signal Processing Lab University of São Paulo http://www.lps.usp.br/chamon -- 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/d/optout.
Re: [beagleboard] Random shutdown
Robert, Thanks for the pointer. It has happened to me a few times when I connect something else on the VDD_5V, probably because the AC fluctuates (although I'm connected directly to an Agilent bench PSU). - Is there a specific reason for this (protecting the AM335X somehow) or would it be OK to change that behavior? - Would I need to recompile the whole kernel or could I just recompile the TPS driver and replace it somehow? Cheers, -- Luiz CHAMON Signal Processing Lab University of São Paulo http://www.lps.usp.br/chamon -- 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/d/optout.
Re: [beagleboard] Random shutdown
Hi Robert, I have a similar problem when using the 5V jack. When I turn off VDD_5V (always) or out of the blue (less frequent), the BBB will turn off issuing a Power button pressed message. I am using an element BBB with Debian 3.8.13-bone47. Cheers, -- 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/d/optout.
