I have been engaged in the embedded business for many years, but it is still unclear whether "cooperative development" refers to a way for managers to realize the progress of ultra-efficient project development, or it is a torment for software developers. Perhaps it just means that software development and hardware platform design go hand in hand. Apart from the hardships of software personnel, I really don't know what it means.
In the embedded world, it is often necessary to write software for a board or chip that is being designed. Sometimes software is written for complex ASIC designs in EDA vendor simulation environments such as Mentor Graphics or Cadence Design Systems. Sometimes software is written for a powerful FPGA design from companies like Xilinx or Altera. The FPGA device has an embedded microprocessor core connected to standard and custom IP blocks. It is also time to write software for a programmable system-on-chip that integrates programmable digital/analog functions with a microcontroller (such as Cypress's PSoC device). These features are very powerful and can achieve incredible innovation, but at the same time it also brings pain, that is, the hardware may change at any time, and software developers are difficult to parry.
I am not suggesting to slow down the pace of innovation, but rather to give software engineers a chance to breathe. But in fact it is just the opposite. Hardware tools need to be better integrated with the software IDE to speed time to market. Designers need more tools and methods to protect applications from hardware changes. I am not talking about adding or removing the main communication module from the design. If you really need to add or remove the main communication module, then your software engineer should really find something else, because it means that the hardware design is not in place at all. The changes I am talking about here are minor changes to the defined function modules at a later stage of the design cycle, such as register address changes, bit redefined, buffer size changes, and so on. These "small changes" can also affect the software, which can lead to product defects, and even long-term rework of the software when forgetting the cause of hardware changes.
Software engineer, now is the time for us to fight back! Here are three tips for how to flexibly apply your application to the changing goals. Don't forget these suggestions before starting a new project!
1 Don't write HAL, you want to generate it!
The first change we need is for hardware development tools to generate software interfaces, also known as hardware adaptation layers (HALs). The HAL should include boot code that reliably initializes the programmable hardware and provides an API interface to support the software control of the system. HAL not only simplifies firmware development, but also abstracts the implementation from the interface. This means that small changes in hardware do not affect the firmware.
There is really no new concept in HAL. Many experienced designers have wisely pointed out that constants, functions and variables should adopt a consistent and intuitive naming convention. However, for programmable devices such as FPGAs, CPLDs, and PSoCs, we need to extend this specification further, that is, HAL should be generated by hardware design tools, otherwise how can software engineers ensure reliable interfaces?
In environments with little or no change (such as fixed-function MCUs or large-scale ASIC projects), we can think of HAL as a separate set of APIs that can be modified as part of a hardware design change. However, for modern programmable devices, the hardware changes several times a day. Manual HAL maintenance does not match the current situation, and there will be errors in the implementation phase, not to mention the pain and suffering of software engineers! I think that HAL auto-generation should be a must for any programmable platform.
Figure 1: PSoC Creator work area screen capture, where we see the API file (HAL) used for the system controller design using the FanController module and a pair of comparators (Comp_Hi) and (Comp_Lo).
2 Integrate your favorite IDE
Programmable devices offer tremendous opportunities for innovation, but often the tools needed to design hardware can impact normal software development practices. Engineers often have to use simple, underperforming tools and cannot be well integrated with existing processes.
Most collaborative design environments evolved from hardware design tools that have supported ASIC and FPGA or CPLD processes for many years. As embedded CPUs become more popular, the need to add software development capabilities to the tool portfolio becomes so obvious that one tool can support both hardware and software, but not both. ideal. In this case, engineers will reduce feature selection and even lose feature selection in both areas.
The solution is not to let tool vendors provide industry-leading debuggers, bundle them into hardware design tools, and announce success, then wonder how software engineers are constantly complaining. Adding a source code editor and debugging features for hardware-centric tools does not really solve the problem because the tools are still not integrated into the user's process. Source control interfaces, software test suites, automated builds, etc. are the tasks that developers are currently exposed to every day. Integrating hardware design tools into their daily work is the real challenge.
The right thing to do is not to integrate the debugger, editor, or the entire IDE, but to get the software developer to work in the traditional IDE development environment that they really like and use from the start of the project. Hardware designers may still need software features in the tool to create and run small test programs, but true application development should always be done in the engineer's preferred IDE.
One way to meet this requirement is to be able to export projects from one tool to another. For example, Cypress's PSoC Creator can import PSoC designs directly into the Keil μVision tool. In many programmable systems, the "hardware" is actually provided as a block of data that can be programmed into the device at startup to create a configured device. For software, it is just data, so exporting the design requires only hardware tools to generate project files for the target product, and then implant them with HAL source files and initialization code. The application can then be built on top of the hardware without interfering with the automated test and source control systems used in modern environments.
Figure 2: PSoC Creator's IDE Export GUI. This dialog is used to create and update the Keil μVision project for application development.
Of course, for a dynamic hardware platform, a one-time export is not a complete solution, but must also provide seamless update design features without damaging the application. For the IDE that supports the library, the update process is simple, because the design can be split into application projects and configuration libraries, which completely isolates the application and allows the hardware library containing configuration data and HAL to be changed in design. Automatically updated.
Figure 3: The system controller project exported above is opened in Keil μVision for application development.
3 beyond the scope of software debugging
The third feature that designers need is to improve debugging. In modern devices, the definition of "processor" is not limited to the registers and instruction sets of the CPU. The processor chip integrates a variety of additional on-chip features such as common communication modules and standard interfaces, as well as ubiquitous timers and counters, as well as analog functions that provide a digital interface to the software, sometimes including custom logic and switchable Routing features, etc. This customizability is the reason why we originally chose collaborative design. If the debugger only supports the CPU, it will disappoint the software developers. We need to seriously solve the following problems around the hardware: Is the hardware started? Is the clock activated and stabilized? Is the peripheral working properly? Does the communication module generate an interrupt? Can I send and receive data? Can it work properly on the internal bus?
If this sounds scary enough, I haven't said that changing the hardware from the debugger is actually a change in the role of the persecutor and the victim. I need to symbolize the access of the peripheral hardware so that I can monitor and control the state changes that affect the application.
Of course, the symbol information must be generated from the hardware tool, just like the HAL above. By simply adding this, the debugging process becomes simpler and more powerful. The reason why it is simpler is that we no longer need to query the documentation all the time to find and confirm the address of the key registers in the debugger. The reason why it is more powerful is because it can now support more complex debugging. In addition to quickly getting a snapshot of the peripheral module state, sometimes we can control the function block from the debugger, without having to write code to programmatically reconstruct the situation to understand the specifics of the situation.
The typical way to exchange this information is to have the IDE use an XML file generated by a hardware tool. The ARM CMSIS-SVD (Software Interface Standard - System View Description) standard is a good example. It is an XML-based hardware description designed to allow debuggers to support highly integrated microcontrollers. CMSIS is a standard definition of HAL for ARM Cortex microcontrollers and is widely adopted by many vendors. The SVD extension is mainly for hardware descriptions, such as registers, memory, peripherals, etc., which makes the people engaged in the development of programmable systems really benefit.
Figure 4: This is a small piece of XML that introduces the Cypress PSoC Creator debugger for a register in the CAN implementation. The address, size, and description of the CAN_CSR_ERR_SR register are defined. There are five fields in the register that define the name, size, and access rights.
An important factor in shared hardware definition is the ability to define peripheral registers. In other words, it provides access to fields in registers, ensuring that the debugger takes the read/write modifiable bits seriously. The hardware provides us with clear-on-read and zero-to-toggle bits as well as state processing interfaces that various other transistors can sense but the software can't handle. Only with a good machine-generated definition of the hardware can we guarantee that the user will not waste time or cause unexpected results when debugging registers or individual bits on the peripheral module.
With a high-level view of the programmable hardware, we can not only check the status register and error status, but also implement more functions. For example, if the hardware supports register-controlled switches that enable flexible routing of peripheral I/O to device pins, software developers can manipulate the internal routing of the device from the debugger! Some people may feel a little scary when they hear it, but if the SVD information is generated correctly, then we can limit the allowed changes and ensure "safe" editing, such as multiplexer channel selection or two physics on digital signals. Analog input switching between pins.
Hardware tools generate debugging information for software developers, which is expected to significantly reduce application development time. Not only that, but importantly, we also have the opportunity to detect hardware design errors early on, because software developers are more likely to find unexpected behavior when they find confusion and code rewriting.
Complete product for programmable devices
Now, the concept of “complete product†has been fully understood and widely accepted, and has become an important factor for success. Only the best tools or the best chips are not enough. The programmable solutions we use today come in many forms: perhaps a fully customizable ASIC that integrates an ARM core and multiple IP blocks in a highly specialized solution; or a more versatile platform with integrated programmable Chips and design tools such as FPGA solutions from Altera and Xilinx, or PSoC devices from Cypress Semiconductor. Although these environments vary widely, they all face the same problem—there is no way to effectively migrate hardware modifications to the software world, affecting application development.
I think the root of this problem is that the hardware design tools and IDEs used in the project use a narrow approach. Software madmen like me (joking) always like to blame all the problems on hardware tools and engineers, but in fact the hardware tools and software toolsets are too biased towards their specific domain. It's hard to see that the two add the features I mentioned above because they don't seem to have anything to do with their respective customers. I believe this situation is changing, and tools such as PSoC Creator that support device configuration on programmable hardware while also integrating third-party IDEs such as ARM's Keil μVision IDE will continue to evolve. Implementing application development in the engineer's preferred IDE, while giving the tool access to unique and powerful information and controlling the hardware platform, is clearly the only way to more efficiently develop products and speed time to market. At the same time, reducing the torment of engineers is also a good thing!
Busbar Type Switching Current Transformer
Busbar Type Switching Current Transformer,Clamp Type Current Transformer,Low Voltage Current Transformer,Low Voltage Switching Current Transformer
Zibo Tongyue Electronics Co., Ltd , https://www.tongyueelectron.com