I am studying embedded system which typically includes MCU and so on. I use the thinking method of using 8051 that using peripheral unit must be done in software. But I learned that some MCUs like S3C2440 have special interface that can map SDRAM into internal RAM address, which is done by using any software.
So What should hardware do and What should software do? How do we know it?
Simply put, you use whatever tools and talents you have available to get the job done, in the time required, and within budget. In the end, that is all that matters.
While some tasks naturally lend themselves to a hardware or a software solution, there are a lot of tasks which it does not matter. For example, I could use a 555 timer to blink an LED, or I could use a US$0.30 MCU. There are pros and cons for either, but in the end it really doesn't matter so long as you get the job done. I have seen blinking LEDs done with either approach in commercial products.
I cannot give you a list of things that should be done in software, or a list for hardware. That list would be long, boring, and mostly meaningless. Technology progresses. 20 years ago I would have never thought of using an MCU just to blink an LED. The tasks that are appropriate for hardware/software is always changing. If I gave you a list now, it would be out of date tomorrow.
To make matters worse, the line between hardware and software is blurring. FPGAs come to mind, which are programmed in a way similar to writing software, but the end result is hardware. And even FPGAs frequently have logic inside of them that resembles some form of CPU. But even GPUs and some CPUs have FPGA-like features that may or may not remain hidden from the software programmer.
Knowledge and experience will have to guide you in knowing what is appropriate for hardware and software. Your first step is to know the problem that you are trying to solve and how to solve it. The second step is knowing different ways to solve it-- CPUs, FPGAs, analog circuits, etc. In many cases you will need to know several different CPUs, or several different FPGAs in order to figure out what the best approach is.
There is no substitute for knowing your craft.
It depends on your solution. There are always inherent trade offs between space (Hardware), performance (Software), cost ($), etc. As embedded processors have gotten more complex and faster, they've absorbed some of the burden typically placed on HW. Additionally, some solutions lend themselves better to HW or SW.
Years ago, to turn a device ON/OFF was a simple hardware button. Now, since microcontrollers have become so low power when in sleep mode (often less than the self-discharge of the battery powering the device), it has become standard to simply route the power button to the microcontroller and let the micro handle the power management. This allows you to do things like de-bouncing, LED lighting, accepting different length button presses, all in SW. Many of these capabilities were previously impossible using only a HW solution before. So by changing the domain, you've increased the ability of product. That seems to be a pretty good guiding principal on when to pick one solution (HW or SW) over the other.
Some factors to consider:
When you view these constraints and others as a whole, it'll help you settle in on the right balance between SW and HW. Engineering is a practice, and as such, there's no one formula to solve every problem. When there is, a computer will do it and we'll all be out of a job/hobby.
Hardware is (almost by definition) necessary for tasks which must be done faster than the CPU can do them. It is very helpful for tasks which require timely responses to external events which may occur at unpredictable times. It is also helpful to do things which require performing a number of actions some considerable time apart, especially if those actions must be precisely timed.
As a general rule, it's easier for CPUs to make things happen on its own time-frame than respond to things which happen, or make things happen on a timeframe which must meet externally-imposed requirements. Hardware helps with the latter tasks.
As per me, using peripherals is almost always beneficial in case of Micro-Controllers. It saves:
Only in cases where hardware is NOT available within the MCU and if available NOT good enough to serve my purpose (for ex a 10-bit ADC while i need one with 16 bit), I try to implement the same via software.
