In my project, I need to input some command into my WinCE device through the debug Serial Port. But I found that I can only use "printf" or "RETAILMSG" to output my debug info but I can't simply call "scanf" to get the data of debug Serial Port.
By look up the MSDN, I have found a function named "OEMReadDebugByte". It is a KERNEL function of WinCE, but when I try to call this function in my WinCE application, the Platform Builder post "error LNK2019: unresolved external symbol OEMReadDebugByte referenced in function wmain"
Can I use insert a case in the KernelIoControl? How ? Which file define the "KernelIoControl"?
Or... there are any solutions else?
Thanks a lot!!!
Thank you!
This function is meant to be used in the bootloader to read input from the user to set-up bot mode, network configuration etc. It's not used by the kernel. Serial is used for debug output and there is no easy way to change this. What you may do is to implement an application that provide a serial console and change your BSP removing serial debug and changing it to a system that sends this information to the application (using shared memory or something like this) that then outputs it on the serial port console.
Implementing it will require some knowledge of the OAL and BSP structure and features.
Related
Actually I'm using D-Feet (D-Feet can be used to inspect D-Bus interfaces of running programs and invoke methods on those interfaces) to connect to a BLE peripheral that advertises proximity profile.
When I try the Connect() method on the remote object /org/bluez/hci0/dev_88_6B_0F_00_C4_3A every thing is fine and the connection succeed but when I try to connect only the proximity profile using ConnectProfile("0x1802") method an error occurs saying that the host is down:
g-io-error-quark: GDBus.Error:org.bluez.Error.Failed: Host is down
(36)
Can anyone help me solving this problem (I'm blocked for 2 weeks and there still to much to deal with in the project :/)
ConnectProfile("0x1802")
ConnectProfile (and the Bluez API in general) does not deal with handles, only UUIDs. Your input argument does not look like a UUID: I suggest you find the remote service UUID that matches the handle (I'm assuming your current input argument is a handle).
I believe you can find the UUID with d-feet (after Connect() the service objects should be there) or with bluez command line tools.
I'm writing a Windows kernel driver in C and I need to send and receive data over a serial device, specifically COM3. I am stuck on the CreateFile, ReadFile, and WriteFile functions, as these seem to be user space functions that will not work in the kernel. Am I mistaken? Or if not, what is the best way to open and use a serial port from within the Windows kernel?
Many thanks.
You need ZwCreateFile, ZwReadFile and ZwWriteFile functions for working in kernel mode.
You are writing a driver then You must have to write kernel module for windows .
check this
http://www.codeproject.com/Articles/9504/Driver-Development-Part-1-Introduction-to-Drivers
One more thing once you have finished the driver you need a application to test it.
so you need a user space application to test it.
I have just managed to write my first windows driver (havent registered it yet- but i managed to get the things created!).
I wondered if someone can give me a high overview of how I could achieve the following:
I would like to write a driver which will implement some behaviour when a network packet is received by the computer, before windows does what it does with the packet, i'd like to take this data and output it to the console of a C or C++ program.
Lets assume I have a C/C++ program written, which has a console. How does the C/C++ program interact with the driver I wrote which is hooking the network activity? Is it simply some C code which calls my drivers, the function returns the data as an object and then I can use that object to display in the console?
Thank you in advance for any possible replies
You don't need a driver for this task. Use packet sniffer library like PCap (actually you'll need WinPCap). It's really simple to capture packets and print them to console.
Alternative way is raw socket. But desktop Windows (as opposite to Windows Server) limits raw socket functionality.
If you really want a driver, or have a requirement to manipulate or filter packets before they hit the windows network stack you need to look into filter drivers.
This filter driver can then expose a device file on which your user space application can then read/write. The windows DDK contains examples.
Hello I am working on an embedded linux device with a usb port that uses the g_ether driver for usb networking.
When the usb plug is connected the dmesg output is:
g_ether gadget: full speed config #2: RNDIS
When the usb cable is unplugged no message is written to dmesg.
Using C how can I listen for the connect/disconnect events?
The embedded linux OS does not have any extras. There is no dbus daemon or hotplug helper script. I am not even sure if these would of been helpful.
If you want everything in your single process, you'll have to use libudev to either get events from udevd or directly from the kernel.
Seeing that it might be a problem to use libudev in your application (lack of documentation?), an alternative is to use the udevadm program, which can:
report device events after being processed by udevd (udevadm monitor --udev --property),
report devive events directly from the kernel (udevadm monitor --kernel --property), and
dump udevd's database of current devices (but not the kernel's!) (udevadm info --query all --export-db)
udevadm is part of the udev package, but shouldn't need udevd if you only use it to report kernel events. You can use it by having your process spawn it and parse its standard output (but you'll have to launch it via stdbuf -o L ).
Either way, it'll probably be a lot of work. I've already implemented a lot of this in my NCD programming language, including monitoring of USB devices. You might want to take a look at NCD; it's useful for a lot of configuration tasks, and handles hotplugging well. For example, this NCD program will print USB device events to standard output:
process main {
sys.watch_usb() watcher;
println(watcher.event_type, " ", watcher.devname, " ", watcher.vendor_id, ":", watcher.model_id);
watcher->nextevent();
}
This will make NCD print something like that (with an initial added event for any USB device that was already plugged in):
added /dev/bus/usb/002/045 0409:0059
added /dev/bus/usb/002/046 046d:c313
added /dev/bus/usb/002/047 046d:c03e
added /dev/bus/usb/002/048 0557:2008
removed /dev/bus/usb/002/048 0557:2008
You can also use NCD just for this, and parse this standard output - which is much easier to work with than messing with udevadm directly.
Note that NCD itself uses udevadm, and it does require udevd to be running; but why is that a problem anyway? (with some work this dependency could be removed)
You can use libudev or parse udevadm output as #Ambroz Bizjak suggested. Although, I advise against adding an additional process (stdbuf) and language (NCD), just to parse udevadm's output.
A step between plain libudev and parsing output is modifying the udevadm sources. This solution reduces the needed resources and skips the parsing process altogether. When you look at the udev package, you will find the sources for udevd and udevadm in the udev directory.
There, you have the main routine in udevadm.c and the source for udevadm monitor in udevadm-monitor.c. Every event received will be printed through print_device(). This is where you insert your code.
If you're tight on memory, you can strip off unneeded code for control, info, settle, test-builtin, test and trigger. On my system (Ubuntu 12.04), this reduces the size of udevadm by about 75%.
Unfortunately, there is no udev event produced on connect/disconnect on gadget side, so it is almost impossible to monitor these events.
You could monitor kernel messages (dmesg). It seems to be a stupid idea. Or watch some files in sysfs. Maybe the better way is kernel patching.
update: I do not understand why this answer have got many negative votes.
Maybe some people mix USB host part (which produces UDEV events on device plug/unplug) and USB device/gadget part (which doesn't produce such events)
If your linux host works as a gadget (USB device which is connected to some USB host) there is no good way to catch plug/unplug events.
Proof: message by Greg Kroah-Hartman
another copy if previous link is down
I am writing a mini-filter code for USB (Flash Drives) for blocking i.e (Access Denied).So, could someone help me out, how to detect or block USB or what methods to use in passThrough WDK sample code for USB detection and USB blocking?
I am trying to use *IOCTL_STORAGE_QUERY_PROPERTY in PFLT_INSTANCE_SETUP_CALLBACK*. Am i on right path?? if yes then how to use IOCTL_STORAGE_QUERY_PROPERTY in PFLT_INSTANCE_SETUP_CALLBACK???
After 3 months of work I have finally achieved blocking.
Though I can't give direct code here.
But following link might help.
PassThrough Development
GitHub Link
One way could be to get the device object using FltGetDiskDeviceObject and then check for FILE_REMOVABLE_MEDIA flag in device_object->Characteristics. Once you get to know about the device type, then you can block or allow the required operations (that you need to register with FLT_OPERATION_REGISTRATION).