低端嵌入式系统是否具有过程隔离？
我正在学习记忆管理。特别是，我正在研究MMU以及过程逻辑空间页面和公羊帧之间的映射。 我的问题是：低端嵌入式系统呢？如果我正确，则MMU由于其较小的内存而无法在此系统中使用。那么，可用内存较少的计算机如何避免进程之间共享内存的问题？
I am studying memory management. In particular, I am studying MMU and the mapping between the process logical space pages and the RAM frames.
My question is: what about low-end embedded systems? If I'm correct, MMU can't be used in this systems due to their smaller memory. So how computers with less memory available can avoid the problem of shared memory between processes?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
对于嵌入式系统，您所说的MMU类型仅存在于PowerPC或Cortex A中的高端微控制器中。
低端至中端微控制器确实通常具有一些更简单的MMU形式。不像创建虚拟内存部分那样高级，而是一种简单的类型，可以重新映射RAM，Flash，寄存器等。同样，它们通常具有保护记忆的某些部分免受意外写入的各种机制。他们可能会或可能不够聪明，可以做一个“ MMU样”的实现，即代码正在从数据存储器中执行或在代码存储器中发生数据访问时。哈佛vs von Neumann建筑在这里也很重要。
至于RTO中的多个过程，无法将其与桌面计算机中的多个进程进行比较。 RTO中的每个过程通常都有自己的堆栈，但仅此而已 - MMU不参与其中，而是由RTO处理的。嵌入式系统中的代码通常直接从Flash执行，因此为PC中的可执行代码分配了RAM内存的块是没有意义的。几个进程将简单地从Flash执行代码，并且在过程之间可能是相同的代码或不同的代码，这仅取决于它们是否共享常见代码。
同样，在嵌入式系统中使用堆分配是毫无意义的（请参见为什么我不应该在嵌入嵌入的嵌入式内部中使用动态内存分配系统？）因此，我们也不需要为此目的创建RAM图像。唯一作为唯一过程的东西是堆栈，以及
.data/.bss的单独部分。For embedded systems, the kind of MMU you speak of is only present in high-end microcontrollers like PowerPC or Cortex A.
Low-end to mid-range microcontrollers do often have some simpler form of MMU though. Not as advanced as used to create virtual memory sections, but a simpler kind which allows remapping of RAM, flash, registers and so on. Similarly, they often have various mechanisms for protecting certain parts of the memory from accidental writes. They may or may not be smart enough to do a "MMU-like" realization that code is executing from data memory or when data access happens in code memory. Harvard vs von Neumann architecture also matters here.
As for multiple processes in a RTOS, it can't be compared with multiple processes in a desktop computer. Each process in a RTOS typically got its own stack but that's about it - the MMU isn't involved in that but it's handled by the RTOS. Code in embedded systems is typically executed directly from flash, so it doesn't make sense to assign chunks of RAM memory for executable code like in a PC. Several processes will simply execute code from flash and it might be the same code or different code between processes simply depending on whether they share common code or not.
Similarly, it is senseless to use heap allocation in embedded systems (see Why should I not use dynamic memory allocation in embedded systems?) so we don't need to create a RAM image for that purpose either. The only thing left as unique per process is the stack, as well as separate parts of
.data/.bss.