I am confused about one point: If you use a MCU without a MMU, how exactly can you have multiple processes running. I can see how you could set up a timer to switch CPU focus every so often, but it wouldn't be adaptive to the current load. Also without protected memory spaces, and virtual addressing wouldn't programming be like 10x as hard and full of pitfalls and problems?
Probably the wrong forum to ask but: Is Deffie-Hellman key exchange considered a cryptologically secure algorthim? Also what is the minimum CPU speed requirements for Deffie-Hellman key exchange? I know Blowfish is free to everyone, are Rijndael (AES), Twofish, or RC6 free?
On Sat, 11 Dec 2004 18:50:28 GMT, "dbernat32" wrote in comp.arch.embedded:
First you need to define the term "process". While there are no universally accepted definitions, to me the term means something like "applications". "Processes" are what you have in a desk top or server platform like Windows or Linux or whatever.
For example, on either platform, you might have Open Office open on a word processing document or spread sheet, Firefox open browsing the web, and several other applications at the same time.
Again, that depends on what you are doing. In the type of environment I mentioned above, the platform has to be able to run any number of various applications at the same time, in combinations that were never tested together and probably never even specifically anticipated by the operating system developers.
In this situation the simplest method is to have each different application or process run in its own virtual machine, and isolate and protect each one from the others.
While this is also the case in some of today's larger embedded systems, it is not the typical case. Most embedded systems, particularly the smaller runs, run what is essentially a single application. Multitasking is between what would be called "threads" in desk top environment, not actually separate processes. All of the code in the application is designed and written together to do the specific job.
As for how such multitasking is performed, one method is to do strict time-slicing on timer interrupts, but there are many others, and they do not necessarily require MMUs.
Sorry, can't help you with any of these.
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html
You do a context switch like any other context switch -- you just don't have protected memory spaces to save you from stupid mistakes.
Well, this is an _embedded_ newsgroup. Embedded programming is already
10x as hard and full of pitfalls and problems. If you can't exercise decent discipline with your program then your product is going to fail anyway -- not having an MMU just helps you find this out during development.
Modern micro kernels will do context switches on external events, to "adapt" to the external world.
I agree with Guy on this.
>
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Use threads where you would normally use tasks. Threads share the same address space (shared code and data segment), but have different stacks. This approach works only for static tasks/threads, rather than code that must be loaded and unloaded at run-time.
If you need dynamic tasks/threads, store them in a relocatable format. You can then load them into whatever memory is available and perform "fixups" to make the task run correctly at the address where it's loaded:
formatting link
Memory- and pointer-related bugs may be harder to find if you don't have an MMU. I don't think the programming itself is any more difficult.
Check out Applied Cryptography by Bruce Schneier. It lacks info on the latest algorithms, but it has analysis of CPU time for many different algorithms.
The easiest and simplest way is to compile the OS and all of the processes into one image to download or flash. This implies that all processes are loaded all the time.
If you need to load and unload processes, the most common way is to use position independant or PC relative coding techniques. Some compilers offer this option. In school they talked about some other hokey tricks to work around the problem, but I have never seen them used in the real world.
There is no connection between an MMU and the ability to change your OS's runlist or task sequence. Added memory can be requested by tasks from the OS dynamically (if the OS supports it), the same as in a virtual memory environment. Dynamic memory allocation is a little dangerous in embedded systems, because the allocation request can fail, causing problems.
It's not that different. The only exception to that statement is when you get sloppy and one task corrupts the memory space of another one - that can be ugly to find. You would not want to run a modern multiuser OS this way, but it is common in embedded work.
Exactly the same way as you can run threads in some general purpose operating systems as Linux or Windows.
Sounds like time sharing, which was invented in the 1950/60's
Just cut the time slice, if the current process does not need the whole time slice.
For what do you need memory protection ? Protection against what/whom ?
In a typical embedded environment, all the applications can be statically linked and loaded into the target system, so the addresses for each function can be determined at compile/link time.
In a systems without memory management that needs to run multiple user supplied processes concurrently, you need a program loader that patches the code to run at any load address in a similar way as the .so or .DLL libraries are loaded/relocated into the process address space in some desktop operating systems.
Just as with an MMU: allocate the necessary storage in the runtime's startup code and load a base register with it's adress. Just don't expect this address to be the same for all instances of the same image. If necessay, static data can be initialized by the runtime, too.
Andreas
--
There's no time to stop for gas, we're already late.
- Karin Donker
Perhaps by creating a task/thread/whatever_you_call_a_lightweight_process 1, 10, 1000 times, perhaps with different arguments (if the OS allows for it). The (RT)OS will allocate the necessary stack space and starts the task/thread/whatever: same code (usualy an infinite loop) with a different data space, not necessarily protected from the other tasks ones. At least so it was IIRC with some RTOSes such as RTKernel, AMX and CMX some (several) years ago.
Yes, this technique works quite well. I've written more than one embedded application that controlled multiple motors with one set of motion control code.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.