I have CDC device. I develop driver for him.
Part of ini file:
[ClassInstall32]
CopyFiles=ClassInstall.CopyFiles
AddReg=ClassInstall.AddReg
[ClassInstall.CopyFiles]
My_USBDriver.dll,,,0x2000
[ClassInstall.AddReg]
HKR,,,,%DEVICEMANAGERCATEGORY%
HKR,,Icon,,"102"
HKR,,Installer32,,"My_USBDriver.dll,MyUSBPortsClassInstaller"
HKR,,NoInstallClass,,1
[DriverInstall]
include=mdmcpq.inf
CopyFiles=DriverInstall.CopyFiles
AddReg=DriverInstall.AddReg
[DriverInstall.CopyFiles]
usbser.sys,,,0x2000
[DriverInstall.AddReg]
HKR,,DevLoader,,*ntkern
HKR,,NTMPDriver,,%DRIVERFILENAME%.sys
[DriverInstall.Services]
AddService=usbser, 0x00000002, DriverService
[DriverService]
DisplayName=%SERVICE%
ServiceType=1
StartType=3
ErrorControl=1
ServiceBinary=%12%\%DRIVERFILENAME%.sys
Installer function have code:
c->ConnectionIndex = iPort;
c->SetupPacket.bmRequest = 0x80;
c->SetupPacket.wValue = (USB_STRING_DESCRIPTOR_TYPE<<8)|descriptorNum;
c->SetupPacket.wLength = n;
Success = DeviceIoControl(
hRoot,
IOCTL_USB_GET_DESCRIPTOR_FROM_NODE_CONNECTION,
c, n,
c, n,
&returnBytes,
NULL);
///Sometime GetLastError == 31 // Device not working
This code normal work on desctop(PC) always, but only sometime work on laptop(notebook) during the installation the device(installation function calling by system). OS of these mashines is Windows7.
BUT if i call installation function from my progrm(created for debuggin) this code always work correctly (on notebook and on pc).
Does anyone have ideas on this issue?
You said Desktop and Laptop, but I don't think the shape of the computer matters. Is one 32 bit OS and the other is 64 bit? I don't see the 64bit INF section.
Related
I try to get my SIM7070G Cat-M/NB-IoT/GPRS HAT running with micropython on a ESP32 MC via UART. Unfortunately I did not find any libraries but I thought this can not be too difficult with micropython. I am working on this problem now for 3 days and do not get any response when sending commands with uart.
USB with computer:
Sending AT commands gives an answer like sending AT and receiving OK.
Micropython:
from machine import UART
from time import sleep
sleep(1)
print("activate")
p = Pin(27, Pin.OUT, Pin.PULL_UP)
sleep(0.1)
p.on()
sleep(1)
p.off()
sleep(0.5)
print("activated")
uart = UART(1, 115200,rx=9,tx=10,timeout=5000)
#uart.init(9600, bits=8, parity=None,rx=25,tx=26,stop=1)
uart.write(b'AT\r\n')
print("uart.write(b'AT\r\n')")
sleep(1)
data = uart.any()
print(str(data))
I just do not get a response. data is always 0.
What I tried:
checked connection 100 times, TX->RX and RX->TX, 5V, GND, PWR
different pins did not work
different baudrate... no difference.
Anyone a solution? That would be really great.
Link to manufacturer of SIM7070G HAT
I figured out the solution. As #hcheung sais, I have to call AT command a few times (up until 10 times) to let the module get the baudrate. It will work than properly.
I am using a Circuit Playground Express from Adafruit, and I'm programming it with Circuit Python.
I want to read data transmitted from the computer to which the Circuit Playground Express is connected via USB. Using input() works fine, but I would rather get the buffer of the serial instead, so that the loop would go on while there's no input. Something like serial.read().
import serial does not work on Circuit Python, or maybe I must install something. Is there anything else I could do to read the serial buffer using Circuit Python?
Aiden's answer lead me in the right direction and I found a nice (and slightly different) example of how to use supervisor.runtime.serial_bytes_available from Adafruit here (specifically lines 89-95): https://learn.adafruit.com/AT-Hand-Raiser/circuitpython-code
A minimum working example for code.py that takes the input and formats a new string in the form "RX: string" is
import supervisor
print("listening...")
while True:
if supervisor.runtime.serial_bytes_available:
value = input().strip()
# Sometimes Windows sends an extra (or missing) newline - ignore them
if value == "":
continue
print("RX: {}".format(value))
Tested on: Adafruit CircuitPython 4.1.0 on 2019-08-02; Adafruit ItsyBitsy M0 Express with samd21g18. Messages sent using the serial connection in mu-editor on macOS.
Sample output
main.py output:
listening...
hello!
RX: hello!
I got a simple example to work based on above posts, not sure how stable or useful it is, but still posting it here:
CircuitPython Code:
import supervisor
while True:
if supervisor.runtime.serial_bytes_available:
value = input().strip()
print(f"Received: {value}\r")
PC Code
import time
import serial
ser = serial.Serial('COM6', 115200) # open serial port
command = b'hello\n\r'
print(f"Sending Command: [{command}]")
ser.write(command) # write a string
ended = False
reply = b''
for _ in range(len(command)):
a = ser.read() # Read the loopback chars and ignore
while True:
a = ser.read()
if a== b'\r':
break
else:
reply += a
time.sleep(0.01)
print(f"Reply was: [{reply}]")
ser.close()
c:\circuitpythontest>python TEST1.PY
Sending Command: [b'hello\n\r']
Reply was: [b'Received: hello']
This is now somewhat possible!
In the January stable release of CircuitPython 3.1.2 the function serial_bytes_available was added to the supervisor module.
This allows you to poll the availability of serial bytes.
For example in the CircuitPython firmware (i.e. boot.py) a serial echo example would be:
import supervisor
def serial_read():
if supervisor.runtime.serial_bytes_available():
value = input()
print(value)
and ensure when you create the serial device object on the host side you set the timeout wait to be very small (i.e. 0.01).
i.e in python:
import serial
ser = serial.Serial(
'/dev/ttyACM0',
baudrate=115200,
timeout=0.01)
ser.write(b'HELLO from CircuitPython\n')
x = ser.readlines()
print("received: {}".format(x))
I'm learning Vulkan by API spec (http://vulkan-spec-chunked.ahcox.com/ch02s09.html), and I'm little confused about how physical devices are in Vulkan. I do have only one intel physical video card device, but vkEnumeratePhysicalDevices returns count of 2. The devices are identical, but the queue flags seems differ, and the queue flags are undocumented (actually they are, but only to flag 8, in second queue I do have the flag values 16 and 32).
typedef enum VkQueueFlagBits {
VK_QUEUE_GRAPHICS_BIT = 0x00000001,
VK_QUEUE_COMPUTE_BIT = 0x00000002,
VK_QUEUE_TRANSFER_BIT = 0x00000004,
VK_QUEUE_SPARSE_BINDING_BIT = 0x00000008,
} VkQueueFlagBits;
here is the output of my vulkan code:
GPU count: 2 ( physical devices )
Physical Device 0:
Device API version: 1.0.42 - 4194346
Device Vendor Id: 0x8086
Device Id: 1916
Device Driver version: 0.0.1 - 1
Device type: 1
Device Name: Intel(R) HD Graphics 520 (Skylake GT2)
Device Pipeline UID: f557cfd4
Queue Properties:
Flags: 7
Count: 1
ts Valid Bits: 24
Physical Device 1:
Device API version: 1.0.42 - 4194346
Device Vendor Id: 0x8086
Device Id: 1916
Device Driver version: 0.0.1 - 1
Device type: 1
Device Name: Intel(R) HD Graphics 520 (Skylake GT2)
Device Pipeline UID: f557cfd4
Queue Properties:
Flags: 49
Count: 0
ts Valid Bits: 1
Someone can help me understand why there is 2 physical devices for the same real device and the missing flags ?
The count=0 of the second device is curious. More seriously, its flags and tsVB values are corrupted (49 is not an valid value for flags and 1 not valid for tsVB).
This pretty much boils down to there being one extraneous *.json file on your system.
These *.json files store informations about ICDs present on the machine. They are stored in standard location(s).
vkEnumeratePhysicalDevices+vkGetPhysicalDeviceProperties are relatively dumb commands doing nothing much else than reading said *.json file(s) and returning its contents. I think though that calling something "real" like vkCreateDevice would not work on the badly installed driver.
What exactly happened to creare this problem is up to your curiosity to explore. For starters I believe on Linux distros there is a command to map a file to its originating package. It will probably be something about bad cleanup of previous driver, or possibly bug in the installation script of the new one. At least one person had this problem before.
Based on what I explained here, I believe this is relatively benign bug. The first device should work just fine. And you can just ignore the second one. Or simply delete its *.json manifest to prevent it from showing up in vkEnumeratePD.
I have an atmel UC3-L0 and compass sensor. Now I install AtmelStudio and download some demo code into the board. But I have no idea where the function printf in demo code will appear the data. How should I do to get the data?
The printf function outputs to stdout.
Usually on a "naked" processor with no operating system you need to define how a character is sent or received from a physical interface (usually an USART, console port, USB port, 4-port LCD interface, etc.). So typically you may want to use the USART port of your processor board to connect to a PC running Hyperterm, PuTTY or similar using a serial cable.
In essence you will need to
create FILE streams using the fdev_setup_stream() macro and
provide pointers to functions get() and put() that tell the printf() function how exactly to read and write from/to that stream (e.g. read/write to a USART, an LCD display, etc.).
you may have libraries - depending on your hardware - that already contain such functions (plus the correct port initialisation functions), like e.g. uart.c/.h, lcd.c/.h, etc.
In the documentation of stdio.h (e.g. here) look for the following:
printf(), fdev_setup_stream()
If you have downloaded Atmel Studio you may look into the stdiodemo.c code for further insight.
In order to use printf in ATMEL studio you should check the following things:
Add and Apply the Standard serial I/O module from Project->ASF Wizard.
Also add the USART module from the ASF Wizard.
Include the following code snippet before the main function.
static struct usart_module usart_instance;
static void configure_console(void)
{
struct usart_config usart_conf;
usart_get_config_defaults(&usart_conf);
usart_conf.mux_setting = EDBG_CDC_SERCOM_MUX_SETTING;
usart_conf.pinmux_pad0 = EDBG_CDC_SERCOM_PINMUX_PAD0;
usart_conf.pinmux_pad1 = EDBG_CDC_SERCOM_PINMUX_PAD1;
usart_conf.pinmux_pad2 = EDBG_CDC_SERCOM_PINMUX_PAD2;
usart_conf.pinmux_pad3 = EDBG_CDC_SERCOM_PINMUX_PAD3;
usart_conf.baudrate = 115200;
stdio_serial_init(&usart_instance, EDBG_CDC_MODULE, &usart_conf);
usart_enable(&usart_instance);
}
Make Sure you call the configure_console after system_init() from the main function.
Now go to tools->extension manager. Add the terminal window extension.
Build and Run your program and open the terminal window from view-> terminal window. put the correct com port to which your device is running on and set the baud to 115200 and hit connect on the terminal window.
You should see the printf statements now. (Float doesn't get printed in Atmel studio)
I was recently puzzling over this myself. I has installed Atmel Studio 7.0 and was using the SAMD21 Dev Board via an example project in which a call to printf was made.
In the sample code I saw that there was a configuration section:
/*!
* \brief Initialize USART to communicate with on board EDBG - SERCOM
* with the following settings.
* - 8-bit asynchronous USART
* - No parity
* - One stop bit
* - 115200 baud
*/
static void configure_usart(void)
{
struct usart_config config_usart;
// Get the default USART configuration
usart_get_config_defaults(&config_usart);
// Configure the baudrate
config_usart.baudrate = 115200;
// Configure the pin multiplexing for USART
config_usart.mux_setting = EDBG_CDC_SERCOM_MUX_SETTING;
config_usart.pinmux_pad0 = EDBG_CDC_SERCOM_PINMUX_PAD0;
config_usart.pinmux_pad1 = EDBG_CDC_SERCOM_PINMUX_PAD1;
config_usart.pinmux_pad2 = EDBG_CDC_SERCOM_PINMUX_PAD2;
config_usart.pinmux_pad3 = EDBG_CDC_SERCOM_PINMUX_PAD3;
// route the printf output to the USART
stdio_serial_init(&usart_instance, EDBG_CDC_MODULE, &config_usart);
// enable USART
usart_enable(&usart_instance);
}
In windows device manager I saw that there was an "Atmel Corp. EDBG USB Port (COM3)" listed under "Ports". However, the one of the "Properties" of this port was listed as 9600 Bits per second. I changed this from 9600 to 115200 to be consistent with the config section above.
Finally, I ran PuTTY.exe and set the Connection-->Serial setting to COM3 and 115200 baud. Then I went to Session, then clicked the Serial Connection Type, then clicked the Open button. And, BAM, there's my printf output via PuTTY.
I have an MFC application which reads system (i.e. Application/System/Security) event logs on Windows Server 2008 R2 in WOW64 environment. I am facing a problem with std SDK ::ReadEventLog() function in Windows Server 2008 R2. Below I have provided the code snippet, but the same code/API works perfectly in Windows XP WOW64 & x64 environment. Error code '87' refers to "The parameter is incorrect" but according me the parameters which I passed to ::ReadEventLog() function seems to be correct.
[Code]
//BufferSize.
const int BUFFER_SIZE = 1024*10
BYTE l_bBufferSize[BUFFER_SIZE];
EVENTLOGRECORD* l_pEvntLogRecord = NULL;
l_pEvntLogRecord = (EVENTLOGRECORD *) &l_bBufferSize;
::SetLastError(0);
/*
Adjust the 'counter' to read logs. 'l_nReadRecordIndex' is mapped with the list control, e.g. on key down, 'l_nReadRecordIndex' is set as "GetCountPerPage() + 1" this is one case as their are many case.
*/
DWORD l_dwLogCounter = (GetTotalNumberOfRecords() - l_nReadRecordIndex) + 1;
//Read logs as per "nCntToReadRecords".
for(l_dwLogCounter;l_nNoOfRecTobeRead <= nCntToReadRecords;l_dwLogCounter--, l_nNoOfRecTobeRead++)
{
//Get Actual position to read.
if(0 != ::ReadEventLog( m_hEventLogHandle, EVENTLOG_SEEK_READ|EVENTLOG_FORWARDS_READ,
l_dwLogCounter, l_pEvntLogRecord, BUFFER_SIZE,
&l_dwReadBytes, &l_dwNeedBytes))
{
DWORD l_dwErrCode = 0;
l_dwErrCode = ::GetLastError(); //87 is returned
return FALSE
}
}
//Data population code
If any one is aware of similar problem or worked on the similar issue please let me know the solution. Please refer the above code snippet and let me know the following things, a) What are the incorrect parameters. b) Is their any another way to read event logs.
Thanks in advance.
--
Ganesh
It is a bug, check this entry in MS's KB http://support.microsoft.com/kb/177199