I am a newbie.
I want to develop device drivers on Windows CE 7.
I use Adeneo BSP on TI AM33xx Development Board
I want to drive a SPI Flash so I should use SPI driver.
I have written my driver and when I debug it, all functions calling correctly. But when I call the
CreateFile( _T("SPI1:"),
GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE,
NULL, OPEN_EXISTING, 0, NULL);
deviceHandle always return invalid value. So when I debug the low level SPI driver, I seen , SPI_Init() stream function never called.
There is this tines in my platform.reg file
;===============================================================================
; MCSPI driver
#include "$(_PLATFORMROOT)\AM33x_BSP\SRC\DRIVERS\MCSPI\mcspi.reg"
And
My mcspi.reg file is
;-- SPI Driver -----------------------------------------------------------------
IF BSP_AM33X_MCSPI1
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\SPI1]
"Prefix"="SPI"
"Dll"="am33x_mcspi.dll"
"Index"=dword:1
"Port"=dword:1
"Order"=dword:8
"MemBase"=multi_sz:"48030000"
"MemLen"=multi_sz:"00000100"
"Timeout"=dword:300
"PowerFlags"=dword:00000103 ; send pre/post device state changes
; PMCLASS_PMEXT_GUID
"IClass"=multi_sz:"{0AE2066F-89A2-4D70-8FC2-29AEFA68413C}"
ENDIF
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\SPI1] this lines say to us, "SPI1 driver will be loaded at startup", isnt it ??? But spi driver SPI_Init function never loaded at starttup. I havent seen any extra setting in Microsoft White Paper.
And additional,
I have tried
ActivateDeviceEx(TEXT("Drivers\\BuiltIn\\SPI1"), NULL, 0, NULL);
and
LoadLibrary(TEXT("am33x_mcspi.dll"));
functions but result is same.
Is there any extra setting for Driver Loading?
Thanks
Murat.
Make sure your driver is compiled to your flat release directory. Then, add your driver to your platform.bib file. something like this:
am33x_mcspi.dll $(_FLATRELEASEDIR)\am33x_mcspi.dll NK SH
Related
I have a test board for amlogic S905X chip. (p212 reference board) When I burn my ROM into it, the bluetooth constantly shows "stopping" dialog.
The logfile (tombstone) is quite long but the important part is here:
01-01 00:24:15.708 28953 28986 I bt_hci : hci_initialize
01-01 00:24:15.710 28953 28970 D bt_hci : hci_module_start_up starting async portion
01-01 00:24:15.711 28953 28986 I bt_hci : hci_initialize: IBluetoothHci::getService() returned 0xa1b91560 (remote)
01-01 00:24:16.209 28953 28987 F : [0101/002416.209517:FATAL:hci_layer_android.cc(78)] Check failed: status == Status::SUCCESS.
It seems the hardware is initialized but the the HCI can not be started. Is it related to kernel drivers or android user space and HAL modules? or even framework(?!)
How can I approach this problem to solve it?
the full tombstone log file is pasted here
Thanks
EDIT :
logcat is pasted here.
Your tombstone tells you that your process terminated because the assertion CHECK(status == Status::SUCCESS) failed in hci_layer_android.cc:78.
That problem goes back to the Bluetooth HAL calling initializationComplete(Status::INITIALIZATION_ERROR).
You have to check your Bluetooth HAL implementation for how this can happen.
Checking logcat for messages from android.hardware.bluetooth#1.0-impl could help.
The reasons for a failure and the corresponding log messages from the default bluetooth HAL implementation can be found here.
I'm writing a node.js JavaScript app to run on a Mac (macOS server) that will communicate with USB devices that are plugged in. The library I need to use to interact with the device takes a path in the form /dev/pathToDevice - e.g. lib.connect('/dev/pathToDevice'); - whereas the only way I have to identify the USB device from within my code is by the vendorId (VID) and productId (PID) obtained via the usb-detection library from NPM on insertion.
How can I, in JavaScript, identify or derive the path to the device from the VID and PID of the inserted USB device, so I can pass that to the library?
You could write a small C++ program that uses libusbp_generic_interface_get_os_filename function from libusbp. You would then call the C program from node.js. Let me know if you need help writing the C++ program. I would probably start with the port_name example form libusbp's source tree.
Or, you could use the lsusb example from libusbp as is. It returns a path like /sys/devices/pci0000:00/0000:00:06.0/usb1/1-1 for each device. That is a directory with a bunch of special files; one of them is busnum and one of them is devnum, which are the two numbers you need to construct a path like /dev/bus/usb/DEVNUM/BUSNUM.
If that works, you might prefer to write a binding for libusbp from node.js instead of using a C executable.
Try drivelist , It gives you the mountpaths and its cross platform and you can combine this with usb-detection easily.
var drivelist = require("drivelist")
drivelist.list((error, devices)=> { console.log(devices) })
//Output
[ {
//stuff...
device: '/dev/disk0',
raw: '/dev/rdisk0',
mountpoints: [
{"path":"/","label":"Macintosh HD"},
{"path":"/private/var/vm","label":"VM"}
],
isRemovable: false,
//stuff....
]
On macOS, I use IOKit to get and set HID reports over a USB connection (for the curious, this is a controller for a standing desk that allows you to raise and lower the desk programmatically). I can get a list of devices using an IOHIDManager:
_manager = IOHIDManagerCreate(NULL, 0);
NSDictionary *deviceQuery = #{#kIOHIDVendorIDKey: #0x12D3, #kIOHIDProductIDKey: #0x0002};
IOHIDManagerSetDeviceMatching(_manager, (__bridge CFDictionaryRef)deviceQuery);
IOHIDManagerOpen(_manager, kIOHIDManagerOptionNone);
CFSetRef devices = IOHIDManagerCopyDevices(_manager);
// pick a device from the set and you eventually get a...
IOHIDDeviceRef myDevice = foo;
I then build up request buffers and make requests using:
int8_t *_buffer = ...;
IOHIDDeviceSetReport(myDevice, kIOHIDReportTypeFeature, *_buffer & 0xff, (const uint8_t *)_buffer, REQ_BUFFER_SIZE);
… and read responses using:
IOHIDDeviceGetReport(myDevice, kIOHIDReportTypeFeature, *_buffer & 0xff, (uint8_t *)_buffer, RES_BUFFER_SIZE);
What is an analogous way to do this on Linux? I've never worked with USB on Linux before (nor HID devices), and I'm open to pretty much any stack as long as it'll run on a Raspberry Pi.
to list all devices, capturing interfaces,... on linux libsub is used, see this http://www.microchip.com/forums/m340898.aspx
for the HID reports you can use usbhid-dump http://www.pkill.info/linux/man/8-usbhid-dump/ https://github.com/DIGImend/usbhid-dump or hidraw for low-level
I have a postscript file. How can I send it to a printer using Visual C++? This seems like it should be simple.
If the printer supports PostScript directly you can spool a raw print jobs like this:
HANDLE ph;
OpenPrinter(&ph, "Printer Name", NULL);
di1.pDatatype = IsV4Driver("Printer Name") ? "XPS_PASS" : "RAW";
di1.pDocName = "Raw print document";
di1.pOutputFile = NULL;
StartDocPrinter(ph, 1, (LPBYTE)&di1);
StartPagePrinter(ph);
WritePrinter(ph, buffer, dwRead, &dwWritten);
EndPagePrinter(ph);
EndDocPrinter(ph)
Repeat the WritePrinter until you have spooled the whole file.
IsV4Driver() Checks for version 4 drivers, this is necessary in Windows 8 and Server 2012:
bool IsV4Driver(wchar_t* printerName)
{
HANDLE handle;
PRINTER_DEFAULTS defaults;
defaults.DesiredAccess = PRINTER_ACCESS_USE;
defaults.pDatatype = L"RAW";
defaults.pDevMode = NULL;
if (::OpenPrinter(printerName, &handle, &defaults) == 0)
{
return false;
}
DWORD version = GetVersion(handle);
ClosePrinter(handle);
return version == 4;
}
DWORD GetVersion(HANDLE handle)
{
DWORD needed;
GetPrinterDriver(handle, NULL, 2, NULL, 0, &needed);
std::vector<char> buffer(needed);
return ((DRIVER_INFO_2*) &buffer[0])->cVersion;
}
It's more complicated than you suspect. If it's a postscript printer, connected over a serial or usb port, you can just open the device and write the file. Similarly, if it's a postscript printer connected to an Ethernet network, you can connect to port 9100 (telnet my.network.printer 9100 < pic.ps) (I may not be recalling the port number correctly, may need to sniff or do some research) and write the file.
But if it's just any old printer, then you need to interpret the postscript code and send rasterized pages to the printer.
If it's a combined PCL/PS printer, you may need to add a PCL header to enter PS mode depending on the printer settings (if it's all set to "auto-detect", don't worry about this part). You'll know to do this if you get bits of postscript code printed-out, possibly with other gobbeldegook, instead of the desired output.
I'm embarrassed to say I don't actually know how to open a usb device in windows c++, but if it helps, the DOS way was to use lpt1: as the filename (as in copy pic.ps lpt1:) which would use the device.
If it's a shared printer, you really should go through the network print queue, instead of directly to the printer.
It's not that hard. You can use LPD (Line Printer Daemon) protocol to talk to server. The protocol is simple, you can read the specification and write one by your self.
Another way is invoke the lpr command directly. However this command is disabled in windows 7 by default. Search "lpr command windows 7" will tell you how to enable it.
I am just starting out with driver development, and am trying to initialize a device driver through the operating system on start up. The driver is for Windows Embedded CE 6.0.
I have been attempting to have my device send a message through a serial port to my PC whenever it gets initialized.
DWORD MYD_Init(LPCTSTR pContext, LPCVOID lpvBusContext)
{
DWORD dwResult = 1;
RETAILMSG(TRUE, (TEXT("MyDriver: Initializing!\n")));
DEBUGMSG(TRUE, (TEXT("MyDriver: Initializing!\n")));
return dwResult;
} //end MYD_Init
The DLLEntry function is gets called:
BOOL DllEntry(HANDLE hDllHandle, DWORD dwReason, LPVOID lpreserved)
{
switch (dwReason) {
case DLL_PROCESS_ATTACH:
RETAILMSG(TRUE, (TEXT("MyDriver - Process Attached\n")));
DEBUGMSG(TRUE, (TEXT("MyDriver - Process Attached\n")));
break;
case DLL_PROCESS_DETACH:
RETAILMSG(TRUE, (TEXT("MyDriver - Process Detached\n")));
DEBUGMSG(TRUE, (TEXT("MyDriver - Process Detached\n")));
break;
.......
default:
break;
} //end Switch
return TRUE;
} //end DllEntry
And here are a few lines from the serial port log:
FMD_Init: Blocks reserved for the bootloader/run-time image: 3124
I2C Driver: Intialization Started
MyDriver - Process AttachedMyDriver - Process DetachedTurn on clocks for Device block (in OTG_CTRL)
2589 CUSBFN::IsConfigurationSupportable
2593 CUSBFN::IsEndpointSupportable
2595 CUSBFN::IsEndpointSupportable
Line three shows that the driver gets loaded (I think), but MYD_Init is not called afterward. I'm not sure what I am missing. Maybe a missing reference from another file. My .def file includes the MYD_Init under EXPORTS. The .reg key is within the BuiltIn path: [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\MyDriver]. Not sure if there are any others.
I guess my real question is what are possible things I am missing/forgetting to get the MYD_Init function to get called?
Thanks for any help you guys can provide to help me get this work!
Edit:
I have realized that the CreateFile function is never called and feel this is the reason for my problem. What are some steps that I could take to figure out where this function should be placed so that MYD_Init is not called before DllEntry?
Or maybe the ActivateDevice/ActiveDeviceEx functions? Does the OS automatically call these for the drivers listed under [HKEY_LOCAL_MACHINE\Drivers\BuiltIn], or do they have to be called manually?
Thanks again for any insight that can be provided!
Edit 2:
Here are the registry settings easily readable:
[HKEY_LOCAL_MACHINE\Drivers\BuiltIn\MyDriver]
"Prefix"="MYD"
"Dll"="myDriver.dll"
"Index"=dword:1
"Flags"=dword:0
Edit 3:
This is the output after trying to open the driver through an application:
USBFN: dwDeviceStatus: 0x11, m_fAttached: Attached
USBFN: dwDeviceStatus: 0x1, m_fAttached: Attached
MyDriver - Process Attached
MyDriver - Process Detached
COM_Open
COM_Open
IOCTL_SERIAL_SET_COMMTIMEOUTS (50,1,50,5,500)
IOCTL_SERIAL_SET_COMMTIMEOUTS (50,1,50,5,500)
IOCTL_SERIAL_SET_COMMTIMEOUTS (-1,0,0,2,500)
Testing Driver
MyDriver - Process Attached
MyDriver - Process Detached
Driver Tested
Line 3 and 4 is the Load attempt during system boot. The last four lines are output when the application to load the driver is run. "Testing Driver" and "Driver Tested" were placed at the beginning and end of the application.
Edit 4: Dumpbin Output
Dump of file myDriver.dll
File Type: DLL
Section contains the following exports for myDriver.dll
00000000 characteristics
501012DA time date stamp Wed Jul 25 10:38:02 2012
0.00 version
1 ordinal base
9 number of functions
9 number of names
ordinal hint RVA name
1 0 000013D4 DllEntry = DllEntry
2 1 00001348 MYD_Close = MYD_Close
3 2 0000130C MYD_Deinit = MYD_Deinit
4 3 000013B8 MYD_IOControl = MYD_IOControl
5 4 000012B8 MYD_Init = MYD_Init
6 5 00001328 MYD_Open = MYD_Open
7 6 00001364 MYD_Read = MYD_Read
8 7 0000139C MYD_Seek = MYD_Seek
9 8 00001380 MYD_Write = MYD_Write
Summary
1000 .data
1000 .pdata
1000 .reloc
1000 .text
Xxx_Init will be called when the driver is loaded. It might be loaded by calling ActivateDevice manually, or by having it automatically loaded by DeviceManager by setting the proper registry settings in [HKLM\Drivers\BuiltIn] (show us what keys you are using).
Xxx_Init is guaranteed to be called after DllEntry because DllEntry gets called when the DLL is loaded by the OS, which has to occur before Device Manager can load it.
CreateFile calls the Xxx_Open method in the driver, which is after all of these actions occur.
So the order of events is:
OS loads the DLL, calling DllEntry
Device Manager loads the driver (either manually or automatic), calling Xxx_Init
App opens the driver by calling CreateFile, which makes Device Manager call Xxx_Open
There are possibly some power management pieces that can fall at 2.5 on the list, but they are optional and likely unrelated to the issue you're seeing.
Typpically I'll use an explicit call to ActivateDevice/DeactivateDevice from a test app when first testing out driver bring-up. It lets you replace the driver DLL without having to reboot the system every time.
So the questions to you are:
If you manually call ActivateDevice from an app, what happens?
What are the registry keys you're currently using to try to get device manager to load the driver?