Re: Hardware driver on xPC Target

Robert,

You need the source code. You absolutely can't use a dll since
there is no way for a target application to load one. You probably
need to make some minor changes so the static lib probably won't work
either without a recompile after the changes.

For access to registers, you don't have a choice. The board designer
chooses either memory mapped or IO mapped. Some PCI boards do let
you have a choice by having hardware where one base address register
is an IO base and another is a memory base. Most just give you one
way to do it though.

Gordon Weast
xPC Target Development
The Mathworks

Robert Weser wrote:

> Gordon,
>
> thanks for answering so quickly!
>
> The manufacturer provided driver consists of a library (.dll and
> .lib) and of some header files. These files describe an interface of
> different profibus services. I just can use this interface!
> My only problem is the hardware driver for the PCI card.
> Therefor SOFTING only provides Windows based device drivers.
> So can you tell me what kind of access mode would be the better one:
> i/o mapping or memory mapping? I think, the CAN drivers were
> implemented using memory mapping access.
>
> How can I manipulate driver libraries consisting of dll's and
> lib's???
>
> Robert Weser
>
> Gordon Weast wrote:
>
>>
>>Robert,
>>
>>Yes, the SOFTING driver was used in constructing the driver for
>>xPC Target. I didn't work on this specific driver, but I have
>>created a few others that use manufacturer provided driver
>>libraries.
>>In general, you have to learn the whole driver and make sure that
>>nothing Windows specific is used. You may have to modify the
>>library source code to handle hardware addresses slightly
>>differently.
>>
>>The code that access the hardware might need a little bit of
>>tweaking
>>as well. For instance, the routines that xPC Target uses to do
>>IO mapped reads and writes are different than the ones that Windows
>>uses. These can be a simple substitution in the code. To do
>>memory
>>mapped register access, the routine that gets a virtual address
>>given
>>the physical address of the board is different. Calling it is
>>necessary
>>to mark the pages as read/write so you don't get a bus error.
>>
>>You have to watch out for memory leaks. In general, if you
>>allocate
>>buffers from calls in mdlStart, you need to free the memory when
>>mdlTerminate is called or you get a memory leak when you download a
>>model again without rebooting the target. The kernel has no
>>concept
>>that memory allocated by a model is owned by the model so it has
>>no way to automatically deallocate memory when a model is unloaded.
>>You have to do it.
>>
>>Gordon Weast
>>xPC Target Development
>>The Mathworks
>>
>>
>>Robert Weser wrote:
>>
>>
>>>Gordon,
>>>
>>>thanks for your answer!
>>>I have a Profibus master card from SOFTING. In the library
>
> there
>
>>are
>>
>>>CAN blocks from SOFTING which can be used within xPC Target. I
>>
>>have
>>
>>>allready contact SOFTING: they told me that the implementation
>>
>>for
>>
>>>xPC Target was made by Mathworks. Can you told me something
>
> about
>
>>>these implementations?!
>>>In my Opinion, the drivers from SOFTING for Windows were used
>
> to
>
>>>create a xPC Target driver. Perhaps, there were no system calls
>>
>>used.
>>
>>>So I tried to get an interface to the DPRAM of the profibus
>
> card.
>
>>>Do you think this could be option to designing a complete new
>>
>>driver?
>>
>>>Robert Weser
>>>
>>>Gordon Weast wrote:
>>>
>>>
>>>>Robert,
>>>>
>>>>If you have the source code to the Windows driver, you may
>
> be
>
>>able
>>
>>>>to grab some pieces for use in an xPC Target driver, but you
>>
>>won't
>>
>>>>be able to use it directly. The Windows driver probably
>
> makes
>
>>>>system
>>>>calls that aren't supported in xPC Target. The driver
>
> environment
>
>>>>is quite different. The layout of the driver is also quite
>>>>different.
>>>>
>>>>Gordon Weast
>>>>xPC Target Development
>>>>The Mathworks
>>>>
>>>>Robert Weser wrote:
>>>>
>>>>
>>>>
>>>>>I have a profibus card on my xPC Target PC. It is not
>
> supported
>
>>>>by
>>>>
>>>>
>>>>>driver blocks out of the xPC Target library. So I have
>
> to write
>
>>>>my
>>>>
>>>>
>>>>>own device driver.
>>>>>I just have hardware drivers for Windows 98, 2000 and
>
> XP.
>
>>>>>Can I use these drivers for use with xPC Target or do I
>
> have to
>
>>>>>create "special" ones?
>>>>
.

Relevant Pages

  • Re: Hardware driver on xPC Target
    ... the SOFTING driver was used in constructing the driver for ... the routines that xPC Target uses to do ... You have to watch out for memory leaks. ... > I have a Profibus master card from SOFTING. ...
    (comp.soft-sys.matlab)
  • Re: XPC-target, s function problem
    ... In trying to run an S function on xPC target built using the S function builder, the code builds to the target, but when I attempt +tg. ... allocate a block of memory ... Rui wrote: ...
    (comp.soft-sys.matlab)
  • Re: Hardware driver on xPC Target
    ... My only problem is the hardware driver for the PCI card. ... implemented using memory mapping access. ... How can I manipulate driver libraries consisting of dll's and ... the routines that xPC Target uses to do ...
    (comp.soft-sys.matlab)
  • Re: Tech: Updating Stern SAM Board Software
    ... I just was at Target and they didn't have ... people want more memory not less. ... is a software map (driver) required to access the memory at the higher ... As much as I hate E-bay, you can probably find some 128Mb drives "New ...
    (rec.games.pinball)
  • [RFCv5 7/9] mm: vcm: Virtual Contiguous Memory framework added
    ... platforms with no MMU. ... sysfs class driver interface to enable/disable a video output device. ... +This document covers how to use the Virtual Contiguous Memory Manager ...
    (Linux-Kernel)