构建多核支持的FreeRTOS操作系统

需积分: 10 21 浏览量更新于2024-07-16 1 收藏 1.82MB PDF 举报

"这篇PDF文档主要讨论了如何将FreeRTOS扩展到支持多核处理器的环境，作者James Mistry是英国约克大学计算机科学系的学生，该论文是他的硕士毕业论文。他得到了Prof. Jim Woodcock和Dr. Matthew Naylor的指导。论文详细介绍了在嵌入式系统中多核处理器的广泛应用以及FreeRTOS对于满足高性能嵌入式应用需求的重要性。" 在当今的嵌入式系统领域，FreeRTOS作为一个轻量级实时操作系统（RTOS），因其高效、可移植性和开源特性而广受欢迎。然而，原生的FreeRTOS设计并未考虑到多核处理器的环境。随着多核处理器在嵌入式系统中的普及，对FreeRTOS进行多核支持的需求日益迫切。这是因为单核处理器的时钟速度受到物理限制，而多核技术能够提供更高的计算能力，以满足那些对处理器性能有严格要求的应用。论文首先分析了多核处理器在嵌入式系统中的使用趋势，强调了它们在处理复杂任务和提高系统效率上的潜力。接着，它探讨了在FreeRTOS中实现多核支持所面临的挑战，包括任务调度、中断管理、资源分配和同步问题。FreeRTOS的多核版本需要确保在不同核心之间的任务协调，同时保持实时性和确定性，这对于实时系统至关重要。 James Mistry的论文可能详细阐述了以下几点： 1. **任务调度**：多核FreeRTOS需要一个有效的调度策略来决定哪些任务应该在哪个核心上运行，以优化性能并避免资源浪费。 2. **中断管理**：多核环境下的中断处理需要重新设计，确保中断在适当的核心上被服务，并且不会干扰其他核心的任务执行。 3. **资源分配**：在多核系统中，内存和其他硬件资源的分配策略需要考虑如何有效地在多个核心之间共享，以减少冲突和提高效率。 4. **同步机制**：为防止数据竞争和死锁，FreeRTOS需要实现跨核的同步机制，如信号量、互斥锁等。 5. **案例研究与实验**：论文可能包含了对特定多核平台上的FreeRTOS实现的实验，验证其性能和正确性。 6. **移植性与兼容性**：为了保持FreeRTOS的可移植性，设计应允许在各种多核架构上进行平滑移植。 7. **评估与性能分析**：论文可能会对比单核和多核FreeRTOS的性能，包括响应时间、吞吐量和能效等方面的评估。通过这项工作，FreeRTOS可以更好地适应多核处理器的环境，为开发者提供了一个强大且灵活的实时操作系统，用于构建高性能的嵌入式系统。这样的系统不仅适用于工业控制、汽车电子、医疗设备等领域，还可以应用于物联网(IoT)和智能设备等现代应用场景。

Perhaps the most striking examples of this in embedded systems can be found in the incred-

ible explosion of processing power, and speciﬁcally the recent mainstream adoption of multicore

architectures, on smartphones.[7] It is clear that all embedded real–time systems must adapt in

the same way as those in the consumer market. Andrews et al. contend that RTOS designers

have been “ﬁghting”[8] Moore’s Law and must now instead look to make use of processor ad-

vancements to help avoid resorting to ever more complex software solutions designed to squeeze

the required real–time performance from slower hardware, as well as the associated maintenance

problems that arise from this.[8] More fundamentally, a lack of action has the potential to cause

the usefulness of embedded real–time systems to hit a wall. Consider the high–deﬁnition video

processing applications mentioned above: the sheer size of the system’s workload had brought

it close to failure.[2] What will the system designers do when future iterations of the appli-

cation must perform more tasks, process higher–resolution video and provide faster response

times without having access to matching improvements in single–core hardware? Migration to

multicore is inevitable.

1.2 Method

This thesis documents the process of modifying the MicroBlaze FreeRTOS port to run tasks

concurrently on multiple processors. MicroBlaze is a soft processor architecture implemented

through the use of Field Programmable Gate Arrays (FPGAs), special integrated circuits whose

conﬁguration is changeable “in the ﬁeld”. This technology allows for the rapid design and imple-

mentation of customised hardware environments, allowing complete control over the processing

logic as well as system peripherals such as I/O devices and memory. Because of how conﬁg-

urable and relatively inexpensive they are, FPGAs provide an attractive way to develop highly

parallel hardware solutions, with which a multicore embedded RTOS would be incredibly use-

ful in providing a platform to abstract both the real–time scheduling behaviour as well as the

underlying hardware away from application code.

As well as enabling discussions with researchers at York who are very familiar with the

MicroBlaze platform, this processor architecture provides another important beneﬁt: simplicity.

MicroBlaze FPGA designs are readily available and can be implemented with relatively little

eﬀort, particularly important given the author’s lack of experience with this technology. Also,

by being able to strip down the hardware conﬁguration (for example by disabling processor

tasks for simultaneous execution on a multicore processor.

caching and limiting the number of hardware peripherals), it is possible to greatly reduce the

complexity of the software components that interact with the hardware at a low level, thus

reducing implementation time and limiting the risks of non–completion in the relatively little

time available.

Inevitably, the identiﬁcation of design and implementation issues of one component during

the design or implementation of another would sometimes need to retroactively be used to

inform previous design, requirements or implementation details. It was thus deemed important

that allowances be made in the project for experimental cycles of design, development and

requirements reﬁnement. The overarching methodology and how each iteration step ﬁts into it

is explained below.

Planning An exploration of the technical feasibility of the project, as well as an assessment of

the technology required for the following stages.

Requirements An analysis of the current iteration’s requirements as a decomposition of the

broader project aims, combined with experience from previous iterations. Before the next

stage, this is incorporated as a tentative agreement of what should be accomplished within

the current iteration.

Design Applies the agreed requirements for the current iteration as a technical design appropri-

ate to the subject matter. This could be in the form of code sketches, an initial hardware

design or actions planned to resolve tool conﬁguration issues on the basis of consultation

with a domain expert.

Implementation The production of a new version of a prototype deliverable, either in the

form of a hardware design or code. In addition, the incorporation of this deliverable with

the other project deliverables to create a complete test environment.

Testing and Analysis The running of purpose–built test tasks to test the modiﬁcations made

in this iteration. This includes standard test tasks which test the core context switching

features and task management API in both pre–emptive and co–operative scheduling

modes. Note that due to time limitations, FreeRTOS co–routines and the queue API are

not included within the scope of this project. Also included is an analysis of the testing

results which informs an assessment of the work required to be carried forward to the next

iteration.

Figure 2.1: Executing two tasks on a single–core processor

that share the processor, the fewer of each task’s instructions the processor can execute in a

given amount of time. In Figure 2.1, for example, the processor only needs to divide its time

in two because there are only two tasks that need to be executed. Thus, each one gets a 50%

share of the processor’s time. If three tasks were sharing the processor, this would be reduced

to a third and thus it would take more time for each of the tasks to complete. Now consider

a single–core processor with 10,000 long–running tasks to complete. In this situation it could

well be that their sheer quantity would destroy the illusion of simultaneous execution, because

each task would only beneﬁt from one–ten thousandth of the processor’s time, and take very

long to ﬁnish.

Until the early 2000s,[5] this problem was often lessened in each new generation of hardware

by reducing the time it would take for processors to execute their instructions. However, due

to various manufacturing factors beyond the scope of this thesis, there came a point when an

upper limit on the speed at which instructions could be executed was reached. It was then, for

example, that mainstream processor manufacturers such as AMD and Intel began developing

multicore processors to continue to oﬀer improved performance and faster execution time.

Processors with multiple cores can execute instructions asynchronously, more than one at a

time. Because each core executes instructions independently, the same number of tasks as cores

can be executed simultaneously in a multicore system. Note that, unlike a single–core system,

this is true simultaneity: multiple instructions are actually executed at the same time.

In Figure 2.2, both tasks have a 100% share of their respective core’s time. Assuming both

tasks require an equal quantity of time to complete, this means that the processor is able to

execute them both in the same time as it would take to execute just one of them, and in half

the time it would take a single–core processor of the same speed to complete them both. Note

剩余112页未读，继续阅读

bauldeng

粉丝: 0
资源: 4

构建多核支持的FreeRTOS操作系统

puremvc-js-multicore-framework-master

multicore-intel multicore-intel multicore-intel

TASKING-WP-AURIX-Multicore-Tricore-Programming.pdf

liblinear-multicore-2.11-1.zip_源码

Programming.multicore.and.many-core.computing.systems.epub

multicore-0.2.15.tar.gz_Windows编程_C/C++_

The Coupling Waves of Multicore-Fiber

multicore-开源

sicsa-multicore-challenge-iii:第三届SICSA多核挑战

Wrox.Professional.Multicore.Programming.Design.and.Implementation.for.C.Plus.Plus.Developers.Sep.2008.eBook-DDU

最新资源