Hi guys,
I have never developed a driver before. I used to program in C. But I am fairly new to hardware programming.
What I wanna do is using a comX for communicating in a profinet environment. The host is a TI Cortex M3 µC without a running OS.
So I have to use the Low-Level Hardware Access functions with the TI µC to work with the comX.
So I started trying to use the example code in the toolkit manual. But actually I have just no idea how to do that ;-)
First:
Do I need other source files for the low-level functions then the cifXHWFunctions.c?
Second: I have to declare a struct called DEVICEINSTANCE and fill that with the elements described in the toolkit manual. Do I have to have all elements in it? And why is there in the example that line "BYTE* pbDPM". I thought pbDPM is meant to be an element in the DEVICEINSTANCE
Third:
How do I know the address and size of the DPM? I thought, that I have to access the DPM with a data and a control bus from my host µC....
Can you help me to get a better understanding of the whole "thing"?
And by the way:
Now, is it possible to generate interrupts with the low-level
functions or not? On the one hand the manual says, that you have to have
an OS to be able to use interrupts - on the other hand on the first
page of the manual for the low-level functions it claims that there is
an interrupt mode with a generic interrupt handler.
Thanks you very much, MT! That is something to start with :-)
I downloaded the new version of the toolkit (I had an old one) and now I am going to try to look through those examples for the nonOS use.
On the first glance I have another quick question:
Can you tell me, why in the examples there is a folder (next to the cifXTKitHWFunctions folder) called cifXToolkit which is also containing a nonOS directory? I thought without an OS it's only possible to use the HW-Functions. Or what am I getting wrong here?
Hilscher Gesellschaft für Systemautomation mbH
Can you tell me, why in the examples there is a folder (next to the cifXTKitHWFunctions folder) called cifXToolkit which is also containing a nonOS directory? I thought without an OS it's only possible to use the HW-Functions. Or what am I getting wrong here?
You don't need an O/S to use the Toolkit as it is. All O/S functions are abstracted and must be implemented. You can sub out some of the functions (e.g. Mutex, Locks) if you are running in a single threaded environment, to "emulate" an O/S. Functionality will be limited in this case (no reentrancy prevention, etc.).
But there are some functions must not be stubbed out (e.g. memcpy, memset, malloc, strncpy, strncmp, strnicmp, free, realloc, OS_GetMilliSecCounter, OS_Sleep) as they are needed. These are usually also available on bare-metal system (without any O/S) or can be easily implemented.
Events are mandatory for using Interrupt mode, as they are used to signal a waiting application about a change in the DPM. Usually Events are not available without an O/S but there are ways to implement them , to be usable in a bare-metal, single-threaded system (e.g. InterlockedExchange for example).
Regards,
MT
M T
Hilscher Gesellschaft für Systemautomation mbH
First:
Do I need other source files for the low-level functions then the cifXHWFunctions.c?
The newest Toolkit (V1.1.0.0) contains samples for only using the HW access functions. You don't need any other source files from the toolkit itself, but you will need to build some additional sources yourself (Initialization routines, etc.) But that can be seen in the HW Functions Examples.
Second: I have to declare a struct called DEVICEINSTANCE and fill that with the elements described in the toolkit manual. Do I have to have all elements in it? And why is there in the example that line "BYTE* pbDPM". I thought pbDPM is meant to be an element in the DEVICEINSTANCE
If you want to use the HW access functions only, you will need to fill out much more information than written in the standard toolkit manual. The stated fields (Chapter 4.1 of the manual) contain the elements you need to fill out, when using the complete Toolkit. The other fields will be filled out automatically by scanning the DPM and asking a running firmware about the DPM layout. This is NOT possible when using the HW access only functions.
pbDPM is the base pointer to the dual port memory, as stated in the Toolkit manual. Without a pointer to the DPM the toolkit cannot do anything.
Third:
How do I know the address and size of the DPM? I thought, that I have to access the DPM with a data and a control bus from my host µC....
The size of the DPM is given by your target device / connected address lines. COMX for example have a 16 kByte DPM.
The DPM address is host controller dependent. The address must be taken from the reference manual of your host controller and depends where you connected the DPM. The external memory controller of the host always has an area in it's address space, which is redirected to an external bus, connected to the module
And by the way:
Now, is it possible to generate interrupts with the low-level
functions or not? On the one hand the manual says, that you have to have
an OS to be able to use interrupts - on the other hand on the first
page of the manual for the low-level functions it claims that there is
an interrupt mode with a generic interrupt handler.
The Standard Interrupthandler of the toolkit relies on O/S mechanisms like Events and Mutexes/Locks, and is meant to be used with the standard toolkit (not only HW access functions). So you cannot use the standard interrupt handler provided with the toolkit without an OS abstraction. The is stated in chapter 7.4 of the Toolkit manual rev. 4.
But you can surely write your own custom interrupt handler without implementing OS abstraction.
Regards,
MT