Posts by fs-support_MRO

    FSDeviceSpy & BCSend

    In the Windows IoT environment, F&S Boards usually are assigned an IP address via DHCP.

    Identifying the current IP address of these boards can be challenging, especially without a connected display. But there's a light at the end of the tunnel...

    BCSend

    To address this, F&S has developed a new application 'BCSend' that automatically executes an broadcast on your WinIoT F&S Boards at the beginning.

    This application is standardly implemented on every F&S board. If you don't need this application, you can easily turn it off in the settings:



    Now, the question arises: who initiates with the broadcast? This is where the additional application, FSDeviceSpy, comes into play.

    FSDeviceSpy

    FSDeviceSpy tool can intercept this broadcast. Once a F&S Board (in this case Desktop-U561LPJ) is intercepted, users can establish various connections with their host machine, like SSH or Remote Desktop:



    You can now download FSDeviceSpy in the attachment of the forum post. Have Fun :grin:

    How to debug your Windows IoT application over ethernet with Visual Studio 2019

    To debug a Visual Studio 2019 application on your F&S Single Board Computer / System on Module (now SBC/SoM) running Windows IoT, several actions must be performed. On SBC/SoM the remote tools (i.e. Remote Debugger) need to be installed and launched. Additionally, the project must be set up in visual studio so that a connection to the SBC/SoM can be established. Once configured, you can build your project and it will automatically deploy and execute the application on SBC/SoM.


    Configuration of SBC/SoM

    1) Passwordless connection (only needed when User on SBC/SoM has no password)

    Using a User on SBC/SoM without a password, it is essential to allow a passwordless connection.

    • Launch Regedit as an Administrator
    • Navigate to [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
    • If the "LimitBlankPasswordUse" entry is not already present, create it by right-clicking in the window, selecting New > DWORD (32-bit) Value, and name it "LimitBlankPasswordUse" with value "0"
    • If the "LimitBlankPasswordUse" entry is already present, double-click on it, and change the data to 0 (zero) to allow the use of blank passwords (or to 1 if you want to prevent blank passwords over the network

    • Restart the system

    NOTICE: Of course, it is not recommended not to use a password!


    2) Change sharing options

    First of all you have to activate the network discovery and file & printer sharing. You can find this settings under

    Control Panel > Network and Internet > Network and Sharing Center > Advanced sharing settings


    3) Create target directory

    For the Visual Studio application, create a target directory on the SBC/SoM. In order for this target directory to be accessible from the developer PC, it needs to be shared, either for all users or for the specific (local) user.

    For example: Create a directory named "debug" in the root directory (C:\) of the SBC/SoM. Afterward, access the properties of this directory. Proceed to the "Sharing" tab

    and click on the "Share" button. Select at least the local user of the SBC/SoM to share the directory with.


    Now it should be possible to access this “debug” directory via File explorer from the developer PC.


    4) Remote Debugger Installation

    After all important prerequisites have been met, we proceed with the actual installation and setup of the Remote Debugger Tool.

    For this purpose, you will need the following file: VS2019_RemoteTools.exe. This file can be downloaded directly from Microsoft Visual Studio or from our fileshare.


    Run the .exe file on the SBC/SoM and proceed with the installation. After the application has been successfully installed run this “Remote Debugger” application. The Remote Debugger is a small dialog that displays notifications. We will keep this dialog open and now focus on the developer machine that wants to access it.




    Configuration of developer PC / Visual Studio

    1) Visual Studio Application Property Page

    To establish a remote debugger connection from the developer PC, the following steps must be performed:

    In the project settings of the C++ project (not solution properties!), you have to navigate to the Debugger configuration. Under "Debugging", the "Remote Windows Debugger" has to be selected.


    Described below are the key parameters required for configuring remote debugging settings:

    Parameter
    Description
    Remote Command Refers to the pathway leading to the executable file of your application located on the remote server (SBC/SoM)
    Working Directory Designates the location where the remote command is executed. Utilizing the browse function, you can directly select the previously created "debug" directory. This step is highly recommended because it ensures the accurate pathway. Additionally, this path can be employed for other parameters, such as the remote command or the deployment directory
    Remote Server Name Connection details of the target machine (SBC/SoM). The information regarding the machine's name and port can be found in the Remote Debugger dialog (see Remote Debugger Installation). In our case it is: DESKTOP-ANTON5C:4024
    Debugger Type Determines which type of debugger will be employed to remote debugging. Based on our platform, we choose the "native only" option
    Deployment Directory Path on the remote server(SBC/SoM) where your application files or resources are copied before debugging commences. This step is essential to ensure that the remote application has all the required files to function properly and be debugged effectively.


    NOTICE:

    Instead of using the name "\\DESKTOP-ANTON5C" you can also use the IP address (e.g. \\10.0.0.200) of the SBC/SoM. However, this is not recommended as the IP address tends to change frequently (DHCP).


    2) Visual Studio Solution Configuration Manager

    After configuring the debugging settings, the final step is to set up the deployment of files. This can be achieved by accessing the Configuration Manager within the project solution (right-click on the solution > Configuration Manager).



    It is important here to ensure the correct active Solution configuration and platform are selected. Also, for the specific project (in this case: GPIOTestTool), make sure to check both BUILD and DEPLOY.


    With these steps completed, all settings for remote debugging should be set. Good work:thumbsup:

    Windows IoT Bus Tools

    GPIO, I2C, PWM, SPI and UART TestTool

    Microsoft provides a wide range of tools and samples for Windows IoT, including the bus tools. These tools have proven to be extremely helpful in assessing the performance and reliability of the various interfaces on our F&S boards. Thanks to these tools, we can conduct various test scenarios to ensure that our hardware seamlessly interacts with Windows IoT.

    For those of you who are working with or considering Windows IoT, it's great to know that these tools are free to use. You can download it from the following page.


    In general, these tools utilize the Windows.Devices Namespace. Within this namespace, you'll find sub-namespaces with specific types that allow you to communicate with various peripheral devices directly from your application. The sub-namespaces are the following:


    CAN TestTool

    However, it's important to note that, there's no official test tool provided by Windows for the CAN interface. In response to this, F&S has taken the initiative to develop its own CAN testing tool. This tool is structured in a manner similar to existing Microsoft test tools, ensuring familiarity for users.

    This CAN test tool makes use of the official Input/Output Controls (IOCTL) from the NXP FlexCAN driver. For a more detailed understanding of these IOCTLs, you can refer to the project CAN header file.



    NOTICE:
    The entire project is attached to this post and will be continually updated over time. We're actively working on making the tool more user-friendly.

    It is also possible to debug all these programs. For a comprehensive understanding of how this works, please refer to the other forum entry titled Deploying & Debugging VS applications over Ethernet.

    Hello,


    although the 'F&S Audio Mixer' does not work for us either, nevertheless we can't reproduce the problem with the sound.

    We were able to play our test wav files over 'Volume&Settings' and test all windows sounds. There was nothing to complain about the quality.

    Keyboard and touch inputs also produced windows sound outputs, no matter how many times typed.


    Do you have any other programs running that might have an effect on the sound?

    Can you please also send us an excerpt from "HKEY_LOCAL_MASCHINE\Drivers\BuiltIn\PicoCOMA5\WaveDev"?

    Hello,


    there is a new version for the NetDCU-USB-Loader (V2.5.0.1). With this version we have fixed the bug that sometimes no eboot image was transferred.

    Like usual you will find the new version of the NetDCU-USB-Loader under "MyF&S" in the "Tools" section at our hompage.


    Your F&S support team