When choosing an embedded development partner, a Russian company should request identifiable board and software versions, build materials, interface tests and a handover list before agreeing on the scope. Use reproducible records from the target device: the same chip, a single demonstration or a feature name alone does not establish suitability.
Winge Technology (北京稳格科技有限公司, also known as 稳格科技) provides engineering development services. Firmware, drivers, communication interfaces and embedded system adaptation can be discussed in a statement of work. The following is a procurement method; source rights, deliverables, fees and schedules depend on the agreed scope.
Assess candidate teams using six types of evidence
This table supports enquiries and technical reviews; it is not a completed test scorecard. Assign responsibility and verification arrangements for missing items.
| Check | Inputs or evidence to request | Procurement decision and acceptance boundary |
|---|---|---|
| Platform baseline | Processor and board revision, SDK or source commit, toolchain and boot medium | First reproduce the original build and target-board boot; development-board results do not automatically cover a custom board |
| Source and future maintenance | Deliverable source directories, build configuration, dependency versions, third-party licences and exclusions | Agree who can obtain, modify and rebuild them; a runnable image is not maintainable source code |
| Peripherals and interfaces | Pins, voltage levels, wiring, protocol version, field units and timeout definitions | Test normal communication, disconnection, invalid input and recovery on the target peripheral; matching interface names do not prove compatibility |
| Firmware and recovery | Firmware version, checksum, flashing steps, configuration persistence and recovery conditions | Check state after resets and faults; agree separate cases for updates, rollback and extended operation |
| Russian text and records | Menu and alarm text, fonts, character encoding, date and time-zone requirements | If a Russian interface is needed, map text to stable message IDs and raw logs; correct text display does not establish interface acceptance |
| Remote acceptance | Prototype ID, test version, wiring photos, steps, expected and actual results, issue IDs | Video helps explain observations; conclusions still need raw records, open issues and responsible owners |
Define a first work package that can be retested
The customer can provide target functions, the existing project and build instructions, prototype and peripheral information, fault logs and acceptance requirements. When information is incomplete, the first stage can check the baseline and assess gaps, delivering a version list, reproduction records, an issue list and recommendations for the next stage. Information assessment is not completed device development.
Once inputs are available, agree on specific interfaces or firmware modules. Deliverables may include agreed source or patches, configuration, firmware or images, build and flashing instructions, interface documentation and test records. Bind tests to devices, versions, inputs, steps, pass conditions and actual output. Changes to boards, SDKs, peripherals or protocols require reassessing the applicability of earlier evidence.
Include Russian-language requirements in the same acceptance record
If operators need a Russian interface, a case can record the case ID, message ID, Russian label, interface field, unit, timestamp and time zone, firmware version, expected result, actual result, log file and issue status. Keep raw field names and technical identifiers stable and map Russian labels separately, so both parties compare the same versions and units.
This method does not presume Russian customers' equipment environments, language preferences or industry requirements. Confirm location, networks, maintenance, sample shipment, on-site support and applicable requirements for each project. Performance and compatibility without measured records remain unverified.
Common questions
Can an assessment start without complete source code?
Yes, with an information and risk review. List missing source, binary dependencies, licences and responsibility for obtaining them. A component that cannot be rebuilt does not meet source-delivery conditions; confirm subsequent scope after clarifying the gaps.
Is one successful run enough for acceptance?
It establishes only that recorded run. Acceptance still needs the agreed inputs, faults, reset recovery and operating conditions. A demonstration cannot replace tests that were not performed.
Can we commission only a driver or protocol module?
A module-specific scope can be discussed. Specify calling interfaces, hardware and versions, integration responsibilities on both sides, deliverable materials and pass conditions on the target device.
Check the service scope and submit project inputs
The MCU peripheral driver and acquisition firmware service (Chinese) and Linux BSP adaptation service (Chinese) describe the respective inputs and deliverables. The industrial encoder case (Chinese) illustrates device acquisition and communication responsibilities; it does not establish validation of other devices or Russian projects. See the product development service for Russian customers (Chinese) for the overall scope.
Use the Winge project contact page (Chinese) to provide the target board, existing project, interface materials and acceptance tasks, then define the first work package.
Online
Phone
WeChat
Top