4.0 includes many changes both visually as well as architecturally which are designed to support upcoming platforms, improved modularity and performance. This document will help you navigate the various changes as you begin developing with OpenPV 4.0.
Table of Contents
New / Changed Extensions in 4.0
Migrating Extensions and Services to 4.0
Other Developer Toolkit Changes
Overview of Changes
New Device Manager– As we extend the functionality of OpenPV to support modular / external devices as well as composite devices, it became clear we needed a central “Device” Service. Also note that several system service features have moved her such as RS485 Setup, USB Port Management and Touch Tune Updates.
Improved Performance for C# Applications and Build in Applications – There have been numerous upgrades to performance in C# Applications
- Support for Local Sockets – When running services in the same process as your application, the new “Local” socket bypasses the TCPIP Stack allowing up to a 10x improvement in throughput for repetitive service calls.
- Migrate from Cairo to a new Accelerated Skia system for all drawing operations (Demos, InstallerUI) resulting in lower CPU and Higher Framerates. In addition, this new system support damage rectangles allowing very high-performance low-level drawing apps to be built in C#
Multi-Targeting Support – For developers targeting both Pro and Select platforms with a single application, you can now manage multiple separate packageInfo and related configuration files. All demos that can support multiple platforms have been converted to this new project format. OpenPV 4.0 is of course backward compatible with previous packageInfo files so they should upgrade in place to the latest formats.
Atlas Connect Support – OpenPV now has Native Support for the Atlas Connect Gateway our first OpenPV based IOT Device
Pro Platform Support (Beta) – OpenPV 4.0 ships with initial support for our next generation “Pro” display platform. Note that Support is currently only targeting the Development Kits (GenericARM64 for example). With Pro comes several new capabilities.
- Support for USB Device Management (plugging / unplugging) via the Device Service.
- Support for the new Infotainment Shell which allows application frames to be moved and sized as well as management of z-order in the Pro Platform.
New Networking Services – OpenPV 4.0 ships with a new set of Networking Services that support WiFi Client, WiFi Access Point and Cellular Radios. This new set of services replaces the existing “networking service” and is a breaking change for existing users. However, if your application uses the utility WiFiNetworkManager, these changes are handled for you.
New / Changed Extensions in 4.0
Bluetooth Classic Support – OpenPV now includes a Bluetooth Classic Extension and demos. With this you can support common service as A2DP Sink, AVRCP Source, MAP, PBAP and SPP.
Reach Services Support – 4.0 now supports the Cygnus Reach which allows customers to easily integrate Reach Support Services directly into their application (C# Only).
Storyboard Extension – The storyboard Extension has been upgraded with a new SBIO API as well as support for multi-targeting. These changes allow the engine to be selected for ANY platform allowing customers to select the version (7.0-8.2), and specific engine runtime (OpenGL, Processor, etc.) based on their target platform preferences.
CAN Services (Extension) – The CAN Service has received numerous upgrades for usability and reliability.
- Co-Processor Communication now uses a serial communication system simplifying the underlying architectures for both MPU and MCU.
- New CAN Gateway sockets can be used to route OpenPV Services message over CAN to OpenPV Applications running on another device connected ONLY via CAN. A demo CANGateway.Target and CanGateway.Client application are available upon request.
- Reworked Multi-Packet Handling to improve performance and decrease latency.
BSP Updates in OpenPV 4.0
OpenPV Supports only Minimal Changes to the BSP that are considered optional for existing hardware.
OpenView Select BSP – Added support for USB Serial, Cellular Radios and RTC Support for Atlas Connect.
OpenView Pro BSP – Added initial Pro BSP with support for early Pro Development Kits. This BSP is considered “Experimental” for developers beginning support in this new platform.
Developer Toolkit Changes
The following are changes which impact the Developer Toolkit in OpenPV 4.0.
Multi-Targeting Support – When opening demos in OpenPV, you can now select the target platform to select when opening the project. To do this selec the “Selected Platfrom” dropdown.
Packaging Tab – Support for Creating Custom Packages as well as Loading Custom Packages has moved to this tab. Support for Delete Package and Show Package Folder has been removed.
Services Tab – Services can now select if they should be available Local Only, preventing external systems from connecting to these services and exposing potential cybersecurity gaps. Starting in 4.0, only SystemService and SparkService default to “LocalOnly = False”
Display Tab – Formally the “Options Tab” now allows you to completely configure the display for device which include an LCD Screen.
On the Pro Platform, this tab is used to configure a new service called Layer Manager which manage the showing and hiding of various application surfaces in the IVI Shell. To assist with debugging and understanding the Layer Manager service, you can also view the Layer Manager Journal with the “Watch Layer Manager” button in the OpenPV Console.
When using the IVI Shell, you can use this UX to pre-configure the “Surface ID’s” and Default Draw Positions for any application running with the IVI Shell. As you configure initial positions, you will see a sample visualization based on the selected hardware at the bottom of the screen. This allows the system to correctly show your application surface at a known position during startup. In addition, you can check if new “unknown surfaces” should be shown by default. When unchecked, any unconfigured surfaces will be left hidden allowing you to position these surfaces in code prior to showing the surface.
Hardware Tab – This new tab allows you to completely configure the hardware in your system including both onboard and optional USB Devices. This configuration if passed to the Device Service to allow you to configure the initial and dynamic behaviors of hardware in the system.
- Initial USB Port Setup – You can now configure the default state of the Primary and Secondary USB Ports on your hardware. This allows the application to startup with the ports in Host or Device mode depending on your application needs.
- Add and Remove Support for both Onboard Devices (WiFi, Bluetooth, Ethernet, etc.) as well as configure if the module should automatically be enabled on application start. This eliminates the need to Enable / Disable the module in your application startup.
Migrating to 4.0 (Important SDK and API Changes)
While most changes to packageInfo and configuration files will be migrated the first time you open the package there are several “Breaking Changes” you may encounter when migrating to 4.x
C# Namespace Changes – Due to collisions with the dotnet “System” namespace we have chosen to coalesce and move several namespaces. In general, the namespace changes are as follows and can be accomplished with a single search and replace in your source code.
| Original Namespace | Resulting Namespace |
| Ahsoka.System | Ahsoka.Core |
| Ahsoka.ServiceFramework | Ahsoka.Core |
| Ahsoka.Utility | Ahsoka.Core.Utility |
| Ahsoka.Dispatch | Ahsoka.Core.Dispatch |
| Ahsoka.Spark | Ahsoka.Core.Spark |
| Ahsoka.System.Hardware | Ahsoka.Core.Hardware |
Device Manager Changes – For applications which rely on a hardware module (typically WiFi and Bluetooth) your application will need to be modified to add the “Device Service”. Depending on your needs you may be able to simply setup the module in the Hardware Tab making the application changes minimal (starting the device service). For advanced use cases you now will use the device service to manage the “physical” device.
General Service Changes – For those rare instances where you have implemented your own OpenPV Services, the service functions have changed name. Most customers will not be impacted by these changes however they are listed here.
| Original Function | New Function |
| AhsokaClient.OnHandleReceive | AhsokaClient.OnRecieveNotification |
| AhsokaClient.SendNotificationWithResponse | AhsokaClient.SendMessageWithResponse |
| AhsokaService.OnHandleReceive | AhsokaService.OnHandleServiceRequest |
| AhsokaService.SendNotification |
AhsokaService.SendResponse AhsokaService.SendNotification |
Network Service Changes – Networking Service has several changes that will impact your application.
- Enable / Disable Device function have been removed. Use Device Service
- All Client Function (same name) have moved to WiFiClientService.
- All AP Functions have moved to WiFiAccessPointService.
If you are using the WiFiNetworkManager the changes are minimal since this object manages the WiFiClient service for you. This component now allows you to pass in a DeviceServiceClient if you are managing devices yourself. If you don’t pass one in, a device service is created and initialized for you.
Storyboard Configuration Changes – Because of the need to support multi-targeting applications several breaking changes were needed. Most of these involve moving values from source code to configuration.
- Storyboard Configuration files can now be multi-targeted by placing them in a subfolder with the packageInfo for the platform such as “Platform_OpenView” and / or “Platform_OpenViewPro”
- Storyboard SBIO Channel Names are now configured in the extension and have been removed from the API for Startup. This allows OpenPV to generate your startup script rather than relying on first start.
- Storyboard Engine startup arguments are now configured in the Storyboard Configuration file and no longer available in the API allowing for different startup arguments based on target platform.
- You will no longer select the “program folder” and “version” and will instead select the specific “Storyboard Engine” folder you wish to run. This engine / api will be packed for you by the extension so you no longer need to include this in your .csproj file. (you should remove this when upgrading).
- When converting to multi-targeting, you will need to adjust any relative paths to reference up to the correct project folder. Typically, this is simply adding ../ to the front of the SB Project and Generated Output File paths.
- Finally, Windows is now considered a “Target” when running Storyboard Applications. This means you will need to add a “Platform_Windows” folder with a storyboard configuration file and appropriate engine when running on Windows. The windows plugin will execute the export and engine load based on your configuration.
Bug Fixes and Improvements
Version 4.8.5
- Fixes an issue that prevents showing / fetching VersionInfo in GetHardwareInfo when connected to older versions of the tool.
- Bumps the Device Manager's external nuget package (Usb.Events) to include a fix for USB thumb drive disconnects.
- Fixes the link to "Release Notes" to point to the 4.0 Documentation (was pointing to the 3.0 Documentation File).
- Fixed CAN source address override and DLC control on transmitted messages. Use in conjunction with CAN Extension version 4.3.6 or later.
Version 4.8.3
- Adds an Optional BrightnessRaw API. This optional api returns the brightness Max and RawValue allowing you to use integer steps for brightness. For example on Select you can send 0-19 instead of 0-100%.
Version 4.7
- Improved Logging when adding SDK's
Version 4.3
- Added logic to upgrade Network Service to WiFiClientService when opening 3.x Packages.
Version 4.2
- Fixed issues with Brightness Control not returning new value and using incorrect step count.
- C++ Clients would fail with memory errors caused by incorrect return types.
- C++ Client API has been upgraded to match the C# Changes in 3.x. Developers can now use a more simple Start / Stop function for managing clients and no longer need a runtime (as with C#).
- Added support allowing Extensions to deploy custom binaries (.so, resources, etc) depending on platform.
- Added support for a signed Pro DFU Driver.
Version 4.0
- Fixed - CAN Coprocessor applications may fail to start when under high bus load.
- Fixed - The Installer UI fails to install the correct .opv file when multiple files are located on a USB Stick.
- Fixed – Application installs did not remove previous environment setup files which could result in incorrect environment setup.
- Fixed – Upgrading from previous version of OpenPV did not clear invalid extensions.
- Fixed – Container Names between teams could cause collisions between Team Projects resulting in failed uploads.
- Fixed – Nuget Packages that included Core may not deploy all needed libraries to the target.
- Fixed – Installer UI has numerous drawing errors when installed in Portrait Display Orientation.
- Fixed – WiFi Client Disconnect was non-functional. Issues with Device Start / Stop and Restart are corrected with the new Device Service.
- Fixed – IOS Bluetooth Error – When creating non-encrypted. BLE services, iPhones would still prompt for “Pairing”.
- Fixed – Linux and Mac Boot Logos are not correctly rotated during generation causing a packaging error.
- Fixed – Checking for updates on first login could cause a crash.
- Fixed – macOS Toolkit builds were being published dependent on dotnet 8.0 runtime. 4.0 builds should run without the dotnet runtime installed.
- Fixed – Large desktop specific binaries were being included in embedded packages.
- Fixed – Several demo zip files were being included in binary outputs.
- Fixed – Discover Networks was not returning the connected network state.
- Fixed – Brightness is not being saved correctly and replied on startup.
- Fixed – Ubuntu Upgrade / Downgrade Button is not functioning correctly.
- Improved – Connection Management between the toolkit and display has been improved when running the toolkit for long periods of time or loading multiple times.
- Improved – When loading an application and a timeout occurs, the system will now correctly recover and allow a reload.
Comments
0 comments
Please sign in to leave a comment.