iMX8mp Windows 10 Iot Enterprise gpio uart

[okuda]

OS of W21H2-1-3-0 was successfully started.
Next, I would like to check the operation of the GPIO driver and the UART driver.

1.Is there any sample code for an application that accesses the GPIO driver from an application?
　If sample code exists, how do I get it?

2.To access the UART driver from an application, should I create it using the CreateFile, WriteFile, 　ReadFile, and CloseHandle functions using the WIN32API?
　If sample code exists, how do I get it?
　

[hector_delgado]

Hi @okuda ,

I hope you're doing well. Could you let us know what board are you using? And please specify if it's a custom board or one of our boards. Thank you.

Best regards,
Hector,

[okuda]

Hello Hector.

The board used is the reference board of iMX8mp made by NXP.
The binary that can be downloaded from the NXP homepage is used as it is.
(Nothing has changed in software.)

Best regards,
Koji Okuda.

[hector_delgado]

Hi @okuda ,

I hope you're doing great. I've attached UART and GPIO testing tools. Regarding the second question "To access the UART driver from an application, should I create it using the CreateFile, WriteFile, 　ReadFile, and CloseHandle functions using the WIN32API?" Please refer to the following link for more information: Windows-iotcore-samples/main.cpp at develop · microsoft/Windows-iotcore-samples · GitHub

Best regards,
Hector

[okuda]

Hello Hector.

Thank you for the useful information regarding the problem.
I will check the sample source once.

Best regards,
Koji Okuda

[hector_delgado]

Hi @okuda ,

Great, let me know if it was of any help.

Best regards,
Hector.

[okuda]

Hello Hector.

We are still able to confirm only the serial driver.
We have confirmed that we can open a serial device using the sample program.
In the future, we plan to check whether serial-related APIs supported by windows work properly.

We have attached a program that we have written for that purpose.

The attached zip file has x64 and ARM64 executables built with MFC.
If possible, please check with your company.
（Do not use WaitCommEvent.In the worst case, the program locks in the middle of the implementation.）

By the way, using ftdi's usb-serial and its corresponding arm64 driver, it is successfully recognized as a com port in device manager.
An application can open a serial device using its COM device name.
（”COM**” : ** is the COM number）
Is it possible for the serial driver installed by your company to be recognized by "COM**"?
For Windows users, it is common to open the serial driver by device name.
(rather than device path)

Best regards,
Koji Okuda.

[jakub_zigacek]

Hi @okuda and @hector_delgado,

in another thread about uart driver we have got statement about usage of serial port from Microsoft, i will paste it here:

"Accessing serial ports from application is different on SerCx/SerCx2 devices compared to Serial.sys devices. Namely, the SerCx2 device needs to publish device interfaces. Using COM interfaces with SerCx2 is not supported. Please follow this guide on how to expose a SerCx2 serial port to applications: Device Interface publication for a SerCx or SerCx2 managed Serial Port - Windows drivers | Microsoft... Once the application gets a handle to the SerCx2 serial port and configures it, it can interact with it as it would've in the past with COM ports."

Best Regards, Jakub

[okuda]

Hi jakub_zigacek.

Thank you for your reply.
I referred to the documentation in the link.

As a result, since the driver format is different, is it correct to recognize that the method of opening the driver is also different?

Best Regards, 
Koji Okuda

[jakub_zigacek]

Hi @okuda,

exactly. I would say that it is a Microsoft's design decision of SerCx1/2 framework implementation to abandon Serial.sys approach and use this new one.

Best Regards. Jakub

[hector_delgado]

Hi @jakub_zigacek ,

Thank you!

Best regards,
Hector.

[Frantisek_Prochaska]

Hello @okuda ,
We are investigating this COM naming issue.

The WaitCommEvent problem is interesting. Could you give us additional info for that? ("In the worst case, the program locks in the middle of the implementation.") Is there a way to improve behavior from the driver itself or does the locking seem to be operating system problem?

[okuda]

Hello Frantisek.

The WaitCommEvent locking issue is currently an application issue.
Since the test application is not threaded, calling WaitCommEvent will wait until the event occurs.
As a result, the application appears to be locked.
We believe this problem can be solved by threading the application and calling WaitCommEvent.
What has not been confirmed is whether all events that can be waited for by WaitCommEvent are correctly sent.
We have confirmed that some events are sent correctly and can be recognized by WaitCommEvent.
We believe that drivers are also involved in correctly sending events when the corresponding event occurs.

Best regards,
Koji Okuda.

[hector_delgado]

Hi @okuda ,

Let me review this and I'll get back to you as soon as possible.

Best regards,
Hector.

[hector_delgado]

Hi @okuda ,

I hope you're doing great. Sorry for the late response. We're currently consulting our team for any sample code or applications that may have what you're asking for. I'll let you know any updates as soon as possible.

Best regards,
Hector.