Recently Browsing 0 members
No registered users viewing this page.
Let me get it straight...
I've been having such a great experience with AutoIt, it helped me a lot at my work. And now, I gotta make some configurations in the BIOS of many computers at my work. So, I'd like to know, is it possible to use AutoIt (or some programming language) to write an algorithm that when compiled and transefered to a pen drive, it's "plug and run"?
I didn't know where to put this; my apologies if this is the wrong location.
When you plug a Samsung mobile device (phone, tablet, etc.) into the USB of a Windows PC, you can right-click the device in My Computer and select Properties. Here, it will show you the correct serial number of the device. Clearly Windows doesn't use adb to get the SN so I'm stuck at how to get the SN without adb and where the device doesn't have a drive letter assigned to it.
When I last picked this up, I tried seemingly everything I could from wmi(?) and winmgmts(?) but either it's hidden cloak-and-dagger style or I can't see the forest for the trees...
Does anyone know what API Windows uses when getting the serial number of a device Windows calls a Portable Media Player?
here's another UDF for the serial port. It is very similar to CommAPI using kernel32.dll, but all code is packed into a single file without any dependencies, not even using WinAPI.au3. It differs from existing UDF that it doesn't allow a timeout when reading, instead it always returns immediately, either with the requested amount ob bytes read or with a failure status. And of course there is a function provided to query the amount of available bytes in the receive buffer. The reason behind this design decision: You can do 1000 other things in the main loop while checking from time to time if enough data bytes arrived. There's no point to block the program waiting for the serial port.
It is currently a work-in-progress, as I didn't test all functions yet. The code was developed and tested on Windows 7 64 bit. The ComUDF-Tests.au3 shows some tests and basic usage of the UDF. Maybe there's no reason to use this UDF, given the existence of the others UDFs, but I did it to get to know DllCall better - I use structs no only to pass but also to get data back (I don't use the array returned by DllCall to read that data, unless required). You're welcome to test it on older and newer Windows versions.
Here's a list of the implemented functions:
; _ComListPorts ; _ComOpenPort ; _ComSetTimeouts ; _ComClosePort ; ; _ComSetBreak ; _ComClearBreak ; _ComGetInputcount ; _ComGetOutputcount ; _ComClearOutputBuffer ; _ComClearInputBuffer ; ; _ComSendByte ; _ComReadByte ; _ComSendBinary ; _ComReadBinary ; ; _ComSendChar ; _ComReadChar ; _ComSendCharArray ; _ComReadCharArray ; _ComSendString ; _ComReadString ; ; __ComClearCommError ; __PurgeComm Maze
I am trying to open a dll using DLLOpen, however everytime i try to do so the function fails and returns -1 result.
I have the dll in the same folder as the auto it script.
Local $hDLL = DllOpen("C:\Users\310255155\Downloads\COMMGvv2\commg.dll") DllCall($hDLL, "int", "MessageBox", "hwnd", 0, "str", "Some text", "str", "Some title", "int", 0) DllClose($hDLL) MsgBox(0,'result',$hDLL)
So I'm trying to send a string of data to Arduino using CommMG UDF. It seems that Arduino is not receiving it. I used Device Monitoring Studio and it shows that the data is sent fine and looks exactly the same as if I sent it from Arduino Serial Monitor. Is CommMG compatible with USB?
Global $CMPort = 9 Global $CmBoBaud = 9600 Global $sportSetError = '' Global $CmboDataBits = 8 Global $CmBoParity = "none" Global $CmBoStop = 1 Global $setflow = 2 _CommSetPort($CMPort, $sportSetError, $CmBoBaud, $CmboDataBits, $CmBoParity, $CmBoStop, $setflow) If @error Then MsgBox(16,"Error!","Can't connect to Arduino on port - "&$CMPort) Exit EndIf _CommSetRTS(0) _CommSetDTR(0) _CommSendString("x" & 128 & "y" & 256 & "e", 1)