I need to write driver (DXE), that can transmit "couple of bytes" from virtual machine (QEMU) to the host system (OS - Ubuntu). I've read the UEFI_Spec and Guide for developers, but I still don't understand, how to write the code and what protocol should I use (tried to use TCPv4 but can't even LocateHandleBuffer).
EFI_STATUS Status = gBS->LocateHandleBuffer(ByProtocol, &gEfiTcp4ProtocolGuid, NULL, &HandleCount, &HandleBuffer);
I get:
EFI_UNSUPPORTED
If somebody can explain me or can show examples of the code, I'll be very grateful. Thanks.
For most network related protocols you first have to use the corresponding "Service Binding Protocol" to get a handle which contains the protocol you are looking for.
Use this steps to access the Tcp4Protocol:
gBS->LocateHandleBuffer(ByProtovol,gEfiTcp4ServiceBindingProtocolGuid, NULL, &HandleCount, &HandleBuffer);
// Loop over the HandleBuffer Array and pick the one you need
gBS->HandleProtocol(HandleBuffer[YourIndex], &gEfiTcp4ServiceBindingProtocolGuid, &Tcp4SBProtocol);
Tcp4SBProtocol->CreateChild(Tcp4SBProtocol, &Tcp4Handle);
gBS->HandleProtocol(Tcp4Handle, &gEfiTcp4ProtocolGuid, &Tcp4Protocol);
To check if a NIC is available you can use:
// This should return EFI_SUCCESS
gBS->LocateProtocol(&gEfiSimpleNetworkProtocolGuid, NULL, &SimpleNetworkProtocol);
There is a complete code sample for the HttpProtocol inside the Uefi specification (starting at page 1548), the Tcp4Protocol is not very different.
Related
I'm using the NuGet package Plugin.BluetoothLE v6.3.0.19 and I can scan for nearby devices but mostly the names are blank. A few devices show their names but most do not. I also cannot see the mac address of the device I'm looking for.
The scenario is that I know the device name but need to look up the mac for connecting.
As I check the devices I need to check the device.name to see if it matches the device I'm looking for. If found it will attempt to pair and connect.
I'm thinking this LE (Low Energy) version does not get the names from every device unless it broadcasts it. So maybe I need to request more info? If so I don't know how to do that with this plugin.
var adapter = CrossBleAdapter.Current;
adapter.ScanExtra(new ScanConfig { ScanType = BleScanType.Balanced });
var scanner = CrossBleAdapter.Current.Scan().Subscribe(scanResult =>
{
var x = scanResult.Device;
System.Diagnostics.Debug.Print($"{x.Name} - {x.Status} _ {x.ToString()}");
});
I am not very familiar with the BluetoothLE, but I found a course about the problem. I hope this can help you.
In addition, you can put the issue on this git. People who know the problem may help you.
I am using WsReceive() function of the ATEasy framework and wanted to ask what is the meaning of the values "aioDefault
and aioDisableWsReceiveEarlyReturn" of "enMode" parameter?
I found this in the ATEASY documentation:
If enMode, input receive mode includes aioDisableWsReceiveEarlyReturn,
it prevents WsReceive from an "early return" when there is a momentary
interruption in the data being received.
And this from the online help of ateasy (By a tip of an expert from the ateasy forum) :
If sEos parameter is an empty string and aioDisableWsReceiveEarlyReturn mode flag is not used (default case), the function will return immediately if characters are found in the input buffer, and the timeout will be ignored. Using the aioDisableWsReceiveEarlyReturn flag will ensure that the function will return only if the timeout is reached or all lBytes characters were received.
I use twain 2.3 (TWAINDSM.DLL) in my application with HP Scanjet 200 TWAIN Protocol 1.9.
My TWAIIN calls are:
OpenDSM: DG_CONTROL, DAT_PARENT, MSG_OPENDSM
OpenDS: DG_CONTROL, DAT_IDENTITY, MSG_OPENDS
EnableDS: DG_CONTROL, DAT_USERINTERFACE, MSG_ENABLEDS
ProcessDeviceEvent: DG_CONTROL, DAT_EVENT, MSG_PROCESSEVENT
and as a result of the last call I allways get TWRC_NOTDSEVENT instead of TWRC_DSEVENT.
Could please someone help with this?
Once you use DG_CONTROL / DAT_EVENT / MSG_PROCESSEVENT, all messages from the applications message loop must be sent to the data source for processing. Receiving TWRC_NOTDSEVENT means the forwarded message isn't for the source so the application should process it as normal.
Keep forwarding all messages to the source until you receive MSG_XFERREADY which means there is data to transfer. Once the transfer is finished and you have sent MSG_DISABLEDS that's when you can stop forwarding messages to the source.
Twain is a standard, and when many company implement that standard, not all of them do the same way. Along the way to support Twain, we will learn and adjust the code to support all the different implementations.
I experienced this situation before, and this is my workaround:
Instead of placing (rc == TWRC_DSEVENT) at the beginning of code (will skip the following MSG_XFERREADY processing afterward) you can move the comparison to the end after MSG_XFERREADY processing, so that MSG_XFERREADY is always checked and processed.
(rc == TWRC_DSEVENT) is only to determine if we should forward the window message or not.
I don't know your specific situation. I ran into a similar issue because I called OpenDSM with a HWND/wId which is from another process. You should call OpenDSM with the HWND of
the active window/dialog which is owned by current process.
I have a GSM modem and a PLC. The PLC sees a modem (I use a *.lib and functional block "openPort"), but I don't understand how send an "AT command" to the modem, for example, "ate0".
First, to increase your understanding of AT commands in general, read the V.250 specification. That will go a long way in making you an AT command expert.
Then for the actual implementation, I do not know Codesys, so the following is pseudo code of the structure you should have for handling AT commands:
the_modem = openPort();
...
// Start sending ATE0
writePort(the_modem, "ATE0\r");
do {
line = readLinePort(the_modem);
} while (! is_final_result_code(line))
// Sending of ATE0 command finished (successfully or not)
...
closePort(the_modem);
Whatever you do, never, never use delay, sleep or similar as a substitute for waiting for the final result code. You can look at the code for atinout for an example for the is_final_result_code function (you can also compare to isFinalResponseError and isFinalResponseSuccess in ST-Ericsson's U300 RIL, although note that CONNECT is not a final result code. It is an intermediate result code, so the name isFinalResponseSuccess is not 100% correct).
I am in a need to send data thru serial port in vxworks. I am using the following code. But
it is not working.can anyone point out what went wrong?
int f;
if(f=open("/tyCo/1",O_RDWR,0)<0)
{
printf("Error opening serial port.");
return 1;
}
write(f,"hello",5);
after running this code, no data is comming thru serial port but instead it comes thru
terminal(Tornado shell). The system has two serial devices /tyCo/1 and /tyCo/0. I tried them both, but the problem persists.
Thanks in adavnce
Likhin.
Have you set the baud rate?
if (iocl(m_fd, FIOBAUDRATE, rate )) == ERROR )
{
//throw error
}
It is possible that you are using the wrong name for the device, and that Tornado Shell is set to your default device. From vxdev.com:
If a matching device name cannot be found, then the I/O function is directed
at a default device. You can set this default device to be any device in the
system, including no device at all, in which case failure to match a device
name returns an error. You can obtain the current default path by using
ioDefPathGet( ). You can set the default path by using ioDefPathSet( ).
The 3rd parameter of "open" command is, if I am not wrong, the mode. I do not really understand what it is needed for in vxworks, except for code comparability with UNIX. In short -try to give some value like 0644 or 0666. I think this will help.