Embedded Firmware Design

Embedded Motherboard

Embedded Motherboard

As hardware developer, we are keeping continue to expand our embedded solution, and meet client's critical programming and cost objectives.

Thermal Printer

Thermal Printer

Jarltech is well-experienced to develop highly reliable thermal printer. Include 2 inch and 3 inch thermal printer.


Over 30 Years Embedded Firmware Design Developer And Manufacturer | Jarltech

Based in Taiwan, Jarltech International Inc., since 1987, provides Embedded Firmware Design | electronic products and hardware integration to assist clients from idea to real product. Main product, including circuit design, electronic develop, PCB assembly, industrial design, hardware develop, low volume production, PCB DIP, EMS solution, assembly production, PCB manufacturing and so forth.

Jarltech's custom electronic products, along with engineering development such as circuit, software, enclosure and sample designs, tooling and molding, industrial manufacturing, certification and marketing services are provided as well. Idea + Design + Production + Service = Jarltech.

Jarltech has been offering customers high-quality POS system and peripherals, both with strong engineering knowledge and 29 years of experience, Jarltech ensures each customer's demands are met.

Embedded Firmware Design

Offer system tests verify that the product exceeds the stated requirements

Embedded Firmware Design
Embedded Firmware Design

Embedded Firmware Design which offer system tests verify that the product exceeds the stated requirements

We design firmware in five steps

Over the past few years, we've spent a large amount of time consulting with and training software development teams and had already developed the firmware inside successful long-lived products or product families. Although learning to create solid firmware architecture and simultaneously re-architecting legacy software may take months of hard work, five key steps are easily identified which we use this step-by-step process to help our team get started on the right foot.

Step 1: Identify the requirements

Before we can begin to architect an embedded system or its firmware, we must have clear requirements. Properly written requirements define the WHAT of a product. WHAT does the product will do for the user, and note that a properly written requirement is silent about HOW this particular part of the overall WHAT is to be achieved.

Each requirement statement must also be two other things: unambiguous and testable. An unambiguous statement requires no further explanation. It is as clear and as concise as possible. Testability is the key. If a requirement is written properly, a set of tests can be easily constructed to verify that requirement is met. A proper set of requirements is a written list of statements each of which contains the key phrase "the [product] should ..." and is silent about how it is implemented, unambiguous, and testable. Thus, good architecture depends on good requirements.

Step 2: Distinguish architecture from design

Over the years, we’ve found that many engineers (as well as their managers) struggle to separate the various elements or layers of firmware engineering. The architecture of a system is the outermost layer of HOW. Architecture describes persistent features; the architecture is hard to change and must be got right through careful thinking about intended and permissible uses of the product.

The design of a system is the middle layer of HOW. The architecture does not include function or variable names. A firmware design document identifies these fine-grained details, such as the names and responsibilities of tasks within the specific subsystems or device drivers, the brand of RTOS (if one is used), and the details of the interfaces between subsystems.

An implementation is the lowest layer of HOW. If the interfaces are defined sufficiently at the design level above, individual engineers are able to begin implementation of the various component parts in parallel. These difficult parts vary in importance somewhat from industry to industry, but always center on three big challenges that must be traded off against each other: meeting real-time deadlines, testing, and diversity management. Addressing those issues comprise the final three steps.

Step 3: Manage time

Some of the product's requirements will mention explicit amounts of time. Most products feature a mix of non-real-time, soft-real-time, and hard-real-time requirements. Soft deadlines are usually the most challenging to define in an unambiguous manner, test, and implement. With deadlines identified, the first step in architecture is to push as many of the timeliness requirements as possible out of the software and onto the hardware.

Keeping the real-time functionality separate from the bulk of the software is valuable for two important reasons; first, because it simplifies the design and implementation of the non-real-time software. With timeliness requirements architected out of the bulk of the software, code written by novice implementers can be used without affecting user safety. The second advantage of keeping the real-time functionality together is it simplifies the analysis involved in proving all deadlines are always met.

Step 4: Design for test

Every embedded system needs to be tested. Generally, it is also valuable or mandatory that testing be performed at several levels. The most common levels of testing are:
1. System tests verify that the product as a whole meets or exceeds the stated requirements. System tests are generally best developed outside of the engineering department, though they may fit into a test harness developed by engineers.
2. Integration tests verify that a subset of the subsystems identified in the architecture diagrams interact as expected and produce reasonable outcomes. Integration tests are generally best developed by a testing group or person within software engineering.
3. Unit tests verify that individual software components identified at the intermediate design level perform as their implementers expect. That is, they test at the level of the public API (Application Programming Interface) the component presents to other components. Unit tests are generally best developed by the same people that write the code under test.

Of the three, system tests are most easily developed, and of course, a test harness may need to be developed for engineering and/or factory acceptance tests. But this is generally still easier than integration and unit tests, which demand additional visibility inside the device as it operates. To make the development, use, and maintenance of integration and unit tests easy, it is valuable to architect the firmware in a manner compatible with a software test framework. The single best way to do this is to architect the interactions between all software components at the levels you want to test.

Step 5: Plan for change

The key consideration during the firmware architecture phase of the project is the management of feature diversity and product customizations. To plan for change, you must first understand the types of changes that occur in your specific product. Then architect the firmware so that those sorts of changes are the easiest to make. If the software is architected well, feature diversity can be managed through a single software build with compile-time and/or run-time behavioral switches in the firmware. Similarly, new features can be added easily to a good architecture without breaking the existing product's functionality.

Press Release