Hi!
Can somebody help me? I'm trying to work with CLA, but I cannot send the input data to the task. I can read in the task the AdcResult register, but I want to give another input. Sending back the result to the CPU is working. What am I missing?
If I don't enable the CLA_INT, after CLA finishes the task, will the execution return to the point I've triggered the task (i use software trigger)?
Thanks a lot,
Monica
Monica,
Are you using the shared RAM to pass data from the main CPU to the CLA and back?
I'm not sure I understand your second question. Every time you start a task using the software trigger, the CLA will begin executing the instruction pointed to by the MVECTx register. Your main program will continue executing instructions after the software trigger, as it is independent from the CLA.
Take a look at chapter 9 for more information: http://www.ti.com/lit/spruh18c Also, http://www.ti.com/lit/spruge6b.
Regards,
Alvaro
Hi Monica,
Alvaro is correct. the CPU continues execution after intiating a CLA task. You should use the CPUtoCLAMsgRam to send input data to a task and the CLAtoCPUMSgRam to send data back from a task to the CPU.
Vishal
Thank you both for the replies.
I do something like this in my code:
#pragma DATA_SECTION(in1, "CpuToCla1MsgRAM");#pragma DATA_SECTION(in2, "CpuToCla1MsgRAM");#pragma DATA_SECTION(in3, "CpuToCla1MsgRAM");
#pragma DATA_SECTION(VoltFilt_0, "Cla1ToCpuMsgRAM");#pragma DATA_SECTION(VoltFilt_1, "Cla1ToCpuMsgRAM");#pragma DATA_SECTION(VoltFilt_2, "Cla1ToCpuMsgRAM");
Then, when I get an external interrupt I read some GPIOs and I want to send these values to CLA. The CLA should make some calculations and give back the results (I'm trying to gain some time in this way, coz the calculations are simple - multiplication and addition- but written in C they take too long, coz I have to do this 12 times). The results are needed to continue the algorithm performed in the external interrupt. So it's like an interrupt (task) in an interrupt. Can this work? Or I should just try to write that part of code in assembly without using the CLA? Will this be helpful, for speed I mean?
In XINT I write:
in1=value_volt0[SampleCount]; // 356.025689Cla1ForceTask1();
in1 does not get in task1 (I always get 0 returned values). If I give as input a constant value (see the comment) the returned values are correct. This is strange, I don't understand which is the difference. The datatype of value_volt0 is float32.
Thank you,
If your device has an FPU its probably best to write the arithmetic fucntion in FPU ASM and call it in the interrupt rather than send it to the CLA and keep your C28 idle in an interrupt, which could be interrupted by a higher priority interrupt, if you have set up prioritized interrupts.
But even so, I dont see why the variable isnt passed to task 1. I have a few questions
1. in1 declared as volatile?
2. Confirm that in1 is in the memory section CpuToCla1MsgRAM from the .map file or the watch window
3. Before forcing task 1 can you verify that value_volt0[] is getting copied over to in1. Since it works with a constant Im assuming the CLA has no trouble in reading the location. I want to know what happens when its assigned to another variable
Thanks for the answer!
I've just found the problem with in1. I thought I can use it in both directions. I've commented the line
#pragma DATA_SECTION(in1, "Cla1ToCpuMsgRAM");
and it's working.
I've started to write some operations in ASM, using C-callable function. I've tried a simple one a*(b-c). It's working, but I still don't know how do I know in which register I get the returned value (is always R0H? or is another register and now it's just a coincidence that it's running? I've discovered this using some constants.) Also, I will need to save 3 variables for the next iteration. I didn't find yet a document/ tutorial for ASM. I don't even find the RxH registers in debug.
Could you recommend me some documentation? The one I've used so far for C-callable functions is SPRA806. Here it's not explained why the returned value is in ACC, it's always like this?
Thank you very much!
Section 7.3 of the compiler guide is the most comprehensive doc i found on calling conventions.
http://www.ti.com/lit/ug/spru514d/spru514d.pdf
Thanks again!
The doc was really helpful. I've managed to do the function, send the parameters, get the returned value and other values needed later, but I still have some questions, maybe you can help me.
1. The function has 6 parameters. After the function is called, parameters no.5 and 6 are in SP[4] and SP[6]. In SP[0] ans SP[2] I have some values that I can't figure out what they represent. From the doc I understood that the parameters which don't go in R0H:R3H will be on the stack in reverse order. Should I worry about the values in SP[0/2] or this is how it should work?
2. From some reason the timing for the ADC interrupt is changed. I use a PWM to start an ADC conversion, and EOC gives the interrupt. The frequency was 9KHz, now is 0.5KHz. In the asm function I only use R4H to put some temp results, but I push R4H on the stack and pop before return.
I've added here the asm code.
Best regards,
;--------------------------------------------------------------------------
; RMS = float32 RMS_calc(float32 u2rel,float32 prev_a,float32 prev_b,float32 prev_h,float32 A,float32 B)
;-----------------------------------------------------------------------
.def _RMS_calc .global _RMS .global _sqrt .global _prev_a .global _prev_b .global _prev_h_RMS_calc:;----------------------------------------------------------------------; float32 u2rela,u2relb,u2relh; ;---------------------------------------------------------------------- MOV32 *-SP[14],R4H;----------------------------------------------------------------------; u2relh = A*(u2rel - prev_a) - prev_b; ;---------------------------------------------------------------------- SUBF32 R0H,R0H,R1H MOV32 R4H,*-SP[4] MPYF32 R0H,R4H,R0H NOP SUBF32 R0H,R0H,R2H MOVW DP,#_prev_h MOV32 @_prev_h,R0H;----------------------------------------------------------------------; u2rela = prev_a + B*(u2relh + prev_h); ;---------------------------------------------------------------------- NOP ADDF32 R0H,R0H,R3H MOV32 R4H,*-SP[6] MPYF32 R0H,R4H,R0H NOP ADDF32 R0H,R0H,R1H MOVW DP,#_prev_a MOV32 @_prev_a,R0H MOV32 *-SP[10],R0H;----------------------------------------------------------------------; u2relb = prev_b + B*(u2rela + prev_a); ;---------------------------------------------------------------------- NOP ADDF32 R0H,R1H,R0H ; |1935| NOP MPYF32 R0H,R4H,R0H ; |1935| NOP ADDF32 R0H,R2H,R0H ; |1935| MOVW DP,#_prev_b MOV32 @_prev_b,R0H MOV32 *-SP[12],R0H;----------------------------------------------------------------------; RMS = sqrt( u2rela*u2rela + u2relb*u2relb); ;---------------------------------------------------------------------- NOP MOV32 R0H,*-SP[10] MOV32 R1H,*-SP[10] MOV32 R2H,*-SP[12] MOV32 R1H,*-SP[12]|| MPYF32 R0H,R1H,R0H MPYF32 R1H,R1H,R2H NOP ADDF32 R0H,R1H,R0H LCR #_sqrt ;----------------------------------------------------------------------; return(RMS); ;---------------------------------------------------------------------- MOV32 R4H,*-SP[14] LRETR
hmm, Im a bit confused here. The last two arguments float32 A and B should be assigned to the stack in reversed order, so B gets assigned to SP[-2] and A to SP[-4]. As i understand it the stack pointer points to the top of the stack, which should be empty, and the SP is always increasing. Can you check the locations SP[-2] and SP[-4]?
Also, in your routine I see you stashing stuff on the stack, similar to something you would do on a local frame, but i dont see you allocating space on the stack for these variables. So if I were using 7 floats in my local frame I would do something like this
_func:
ADDB SP,#14 ;Add 14 words to local frame
MOV32 *-SP[14],R4H ;Stash R4H into SP[-14]
.....
_func_end:
SUBB SP,#14 ; Delete local frame
LRETR
I'm sorry, I was mistaking... I was reading the code wrong. *-SP[2] means SP[-2]. So, I have A at SP[-4] and B at SP[-6]. I've checked again SP[-2], it contains a value like 5.8939e-39. No idea what that is.
I check it like this, right after entering the function:
_RMS_calc: MOV32 R0H, *-SP[2] ; puts 5.8939e-39 in R0H MOV32 R0H, *-SP[4] ; puts A in R0H MOV32 R0H, *-SP[6] ; puts B in R0H
I guess now I understand what happens on the stack, and I was modifying the stack. Can I see the stack somewhere in CSS Debugger?
R0H
Param 1
R1H
Param 2
R2H
Param 3
R3H
Param 4
R4H:R7H
unknown
At function call:
SP
?
-2
-4
A
-6
B
ADDB SP,#6 ;Add 6 words to local frame
MOV32 *-SP[6],R4H ; save R4H at SP_old
SP_old+6
SP_old+4
SP-2
SP_old +2
SP-4
SP_old
SP-6
R4H
SP_old -2
SP-8
SP_old -4
SP-10
SP_old -6
SP-12
MOV32 R4H,*-SP[10]
MOV32 R4H,*-SP[12]
MOV32 *-SP[2],R0H ; R0H = u2rela
u2rela
MOV32 *-SP[4],R0H ; R0H = u2relb
u2relb
SUBB SP,#6 ; Delete local frame
The timings for the ADC interrupt are ok again. I've checked the time gain, but it's just 4us (without any optimization option). I've replaced the function in 9 places.
What is strange is that without this asm function but using optimization, the CPU is free for 40us. If I use the asm function and optimization, CPU is free 37.5us. Maybe I'm not using the proper optimization options, I have to read more about this.
Thanks a lot again for the help!
Me again...
I've implemented another function, this time
Uint32 BitToNum(Uint32,Uint32);
The first parameter goes to ACC, but the second one is again at SP[-4].
Is there also a document with ASM instructions, like the one for CLA? I'm using the generated *.asm file to figure out the syntax. For example I've tried MOV AH, AR0H ; but it's not ok and I don't know why. I don't know if it would be faster than MOVL ACC, XAR0 ; anyway.
For the moment I've saved about 20us with another function implemented in ASM, so a big THANK YOU! for helping me start with this. I still have a lot to read and dip, but your help was great!
All the instructions are in this guide: http://www.ti.com/lit/ug/spru430e/spru430e.pdf. If its arithmetic stuff you are doing Id refer you to the Fixedpoint library in controlSUITE
libs/dsp/FixedpointLib/ All the source files are in asm, so you probably can find some code there you could reuse.