Hi Alexa Flame,
Can we have an external linkage for our user C code files similar to such when I call the functions from KFlop library like MoveAtVel(), fast_abs(), WaitNextTimeSlice() etc?
What I could not solve myself was linking from one file to the functions implemented in another module (file). This is available in standard C-language model.
Linking together multiple C Files is a bit beyond the intended use of typical simple C Programs. A simpler method to use multiple files is just to use #include to combine and compile the files together. We recently provided an example how to link two files together. Here are two simple C files and a header:
file1.c
Code:
#include "KMotionDef.h"
#include "file2.h"
int main(void)
{
printf("Called do_something at time %f\r\n",Time_sec());
do_something();
}
file2.c
Code:
#include "KMotionDef.h"
void do_something(void)
{
printf("Called do_something at time %f\r\n",Time_sec());
}
file2.h
Code:
#ifndef FILE2_H
#define FILE2_H
void do_something(void);
#endif
Here are the command line options used for TCC67. BTW hex 80050000 is the address of Thread 1 memory in KFLOP (see PC_DSP.h)
Code:
-text 80050000 -g -nostdinc -I "c:\KMotionSrc\DSP_KFLOP" -I "c:\KMotionSrc\C Programs" -o "c:\KMotionSrc\C Programs\file1(1).out" "c:\KMotionSrc\C Programs\file1.c" "c:\KMotionSrc\C Programs\file2.c" "c:\KMotionSrc\DSP_KFLOP\DSPKFLOP.out"
This creates the file c:\KMotionSrc\C Programs\file1(1).out
I then go to KMotion.exe c Programs Screen and load c:\KMotionSrc\C Programs\file1.c into Thread #1
Then select Download and Run (do NOT select compile)
Console shows:
Called do_something at time 187.922084
Called do_something at time 187.922332
Another option is to use the Texas Instruments Compiler. We had a discussion in the Yahoo Group recently. See Here:
And the video
Having existing model of threads it whould be helpful to add at least one input parameter to the KMotionCNC interface when executing user programs (threads). This parameter would be an input to the tread. Often it can be more efficient (less code and faster) to run the same thread with different input parameters than loading each time to KFlop a new piece of code even though very similar to what was executed just before. Similar thing already exists for I/O, DAC options.
The MCode Number (or Button Action index) is stored in the Specified UserData Variable. So you could use that as a Key to have the same C Program do slightly different things.
I would add more flexibility for user threads, inluding ability to create/assign them dynamically plus more options to synch between them.
Now we have only functions to capture and release mutex object. By the way, what should be the initial state of "yet free" mutex? (I guess zero from my experiments).
We try to keep things as simple and fast as possible. Yes 0 is the available state for the mutex.
What is added to each compiled user program? The output file is ~28K, while the TCC compiler says it should be only 160 bytes!?
There is symbol table and debug info included in the binary file. That data is not downloaded to KFLOP.
Does anyone know if the user threads are isolated from each other (running in the protected memory) or not? May I call some function code of one thread from the other thread?
All KFLOPs memory is globally accessible. You can use the 200 persist.UserData variables to pass addresses of functions or data structures between Threads.
HTH
Regards