What is the difference between "Inbox driver" and "Direct Memory Mapped driver"? My basic LED blink remote application worked only after selecting Direct Memory mapped driver. What is the unique things associated with this driver?
The Direct Memory Mapped Driver(DMAP) is an in-developement driver that provides GPIO performance improvements over the default inbox driver. If you use Lighting Driver in your application, you should set the controller driver as Direct Memory Mapped Driver,or there will be exception thrown.As far as i know,there is no more official statement about the detailed difference.
Related
I'm a software developer but I'm a newbie to embedded software development.
I have a Zynq Ultrascale board that has an Axi DMA in its Hardware and I want to access this DMA from Linux.
I know I should use DMA-Engine to Access DMA in Linux and I found the following link which is the Xilinx DMA driver, but I can't add these files to my qt project without any errors and I received file(header file) not found errors.
drivers/dma/xilinx/xilinx_dma.c
I have a piece of scattered information about the DMA driver, Device tree, and DMA-Engine but I know nothing about how to utilize these to access hardware DMA.
I built a Petalinux project and add DMA-Engine and DMA Test client to its kernel.
I don't know adding DMAEngine to the Petalinux project is enough or I should have a driver as well.
I don't know adding hardware specification (by .xsa file and .bit file) to the Petalinux project is enough or I should add a device tree to my Linux for detecting DMA as well
I lookup a step-by-step tutorial on how to set up Linux and qt creator for accessing DMA,
or at least a clear roadmap to my target.
thank you in advance.
First of all, you are facing errors when adding xilinx_dma.c to the Qt project because this file is meant to be compiled as part of kernel or as a kernel module.
Adding DMA Engine to Petalinux is not enough to work with DMA from user space. DMA Engine only provides a standardized API to let different DMAs be integrated into kernel. You need to add a client driver as well. Xilinx, as far as I know, has provided a simple client driver called DMA Proxy Driver. It also includes some simple examples that show how you can access DMA from the user space. However, if your application needs high bandwidth, you probably need to consider other options.
There is also an open source client driver for Axi DMA which achieves higher bandwidths compared to Proxy DMA Driver. It's user space API also allows you to register a callback function to be called whenever a transaction is finished.
The third option is to implement the driver in the user space. This can be done by defining the DMA as a UIO device in the device tree and access its register map directly from the user space. In this case, you need to allocate some contiguous memory blocks in the kernel space to avoid complications with MMU, which cannot be dealt with from the user space.
I am developing a smartcard UMDF windows driver. I would like to achieve following behaviour:
When listing all connected readers by using API call SCardListReaders I want to retrieve the correct friendly names for each attached reader. So for example if I have two readers of same brand I want this to be returned by the driver:
SmartcardBrand USBReader 0
SmartcardBrand USBReader 1
I know that the friendly name is composed of the attributes SCARD_ATTR_VENDOR_NAME, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT the driver returns.
My question is, in my driver, how can I distinguish between SmartcardBrand USBReader 0 and SmartcardBrand USBReader 1?
What shall I return to the OS when SCARD_ATTR_DEVICE_UNIT is requested. I cannot use and increment a global static variable in my driver because every time a new reader gets connected a new UMDF host process is launched (I can see it in the task manager) resulting in a separate new memory area.
What is the proper way of counting device instances in a UMDF driver?
I solved the problem by using memory-mapped files. Basically each UMDF process of my driver creates a memory-mapped file with name of the reader's friendly name. When an other process tries to create a file with the same name it indicates that a driver is already running.
However, there is inconsistency when I connect a reader which uses my driver and afterwards connect a reader which uses Windows native driver. The Windows driver will not see my memory-mapped file I created and apply index 0 for its device.
I found out that, when the Windows driver is loaded it queries SCARD_ATTR_VENDOR_IFD_TYPE, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT from my driver (and from all other drivers currently loaded). I guess this way the Windows driver can know which device units are taken and apply a free one to its reader.
I want to write a program which will "lock" a computer to a user determined wireless network.
It should automatically establish and maintain the connection with the specified network
Other networks should be hidden and/or inaccessible while the program is running
Should be compatible with Windows XP - 8
Should work for all wireless cards
Could I create an NDIS filter driver or NDIS intermediate driver for this? Which one is a better option? Also, the MSDN documentation I linked does not seem to provide good information about how to actually write the driver, where can I find that?
I heard about USB to LPT adapters that are capable of mapping PC legacy parallel port address. What is the level of such mapping? I mean - is it possible to access the adpater's pins by using 'in' or 'out' x86 assembler instructions (in Windows or Linux)? If not, what does it mean that the addresses are mapped? What kind of emulation is this?
Thanks.
Marcin
A mapping from legacy I/O port addresses to a USB device is most likely handled by trapping the port access in kernel mode operating system code. For several generations of systems now, the operating system has been able to impose itself between application code and the hardware in such a way that even things that look like raw hardware access to the application are not necessarily so.
Effectively, when the processor comes upon that raw port access, it isn't executed but an operating system service routine is called instead.
How to get the CPU Temperature info from Bios using c# I gave a try to the code in CPU temperature monitoring
But no luck. enumerator.Current threw an exception.
How can i achieve this ? Thanks.
Error :
"This system doesn't support the required WMI objects(1) - check the exception file
Not supported
at System.Management.ManagementException.ThrowWithExtendedInfo(ManagementStatus errorCode)
at System.Management.ManagementObjectCollection.ManagementObjectEnumerator.MoveNext()
at CedarLogic.WmiLib.SystemStatistics.RefreshReadings() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\WmiLib\SystemStatistics.cs:line 25
at CedarLogic.WmiLib.SystemStatistics.get_CurrentTemperature() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\WmiLib\SystemStatistics.cs:line 87
at TemperatureMonitor.SystemTrayService.CheckSupport() in D:\Downloads\TempMonitorSrc\TemperatureMonitorSln\TemperatureMonitor\SystemTrayService.cs:line 260"
Have a look at OpenHardwareMonitor.
I'm having the exact same problem:
https://superuser.com/questions/183282/cant-query-cpu-temperature-msacpi-thermalzonetemperature-on-windows-embedded-7
The code in the link you cited is correct. My .exe works fine on Windows/XP and Windows/Vista (as long as I "run as Administrator" on Vista) ... but fails with the WMI error "not supported" on Windows Embedded 7.
At this point, I don't know if the problem is the OS (WES7) or my motherboard (an Intel DH57jg).
Although not ideal, the closest/best solution I have found is to use Speedfan (free), which can expose its probe information to external applications, via a memory-map. Somebody has done the C# conversion:
Reading SpeedFan shared memory with C#
"Building on what I spoke about in my
previous post, lets say we want to
access the data that SpeedFan provides
from a C# application. As a small
aside, reading information from the
SMBus and other low level interfaces
can only be done from the kernel. So
applications like SpeedFan (HWMonitor,
Everest, etc etc) generally run a
driver at kernel level and then a
front-end GUI to present the
information.
In the case of SpeedFan, shared memory
(actually its technically a memory
mapped file on Windows I think) is
used to communicate between the kernel
driver and the userspace GUI
application. Even better, the format
of this file has been made public by
the author of SpeedFan. So, enough
talk, lets see some code!"