Is ROM a "must" in up based design?

Is ROM a "must" in up based design?
cannot we replace ROM by RAM?
what's the advantage of using ROM?

It depends on what you want to do.
ROM does not need battery backup but less number of time for changing data, so mostly it is used for storing program or fixed data. RAM needs battery backup but data can be changed more offen, so it is used for temporary working area and / or storage.

You will always need some ROM as a bootstrap loader to load your RAM via e.g. ethernet or RS232. Some processors have this ROM onboard so you don't need to have an external chip, but it is needed, whatever.

barny451 said:

You will always need some ROM as a bootstrap loader to load your RAM via e.g. ethernet or RS232. Some processors have this ROM onboard so you don't need to have an external chip, but it is needed, whatever.

Click to expand...

for initialize RS232, we can have a hardware executing loding program
as soon as hardware reset.

any other reason?

it is not practical to transfer the code through UART or other interface every time you power on the system, the general idea is store the code in cheap flashrom and load the code to ram during the boot-up, even so, you must have a boot rom embedded in the CPU

advantage of ROM: non-volatile
The code is kept even the power lost

If you want to use RAM, you still need a small ROM served
as the boot loader

As others have pointed out, a ROM is required at least for a bootstrap loader, since there is no way of uploading your program onto RAM without a loading program. Whether you want to run your program from ROM or RAM is up to you.
With RAM, you need to load your program into RAM whenever you want to run it. The program could be uploaded from fixed memory ie flash or ROM, or externally ie through serial or other means. RAM is faster, but you would lose the program togather with any associated data when power is cut.
ROM is slower but cheaper, and data is not lost when power is cut. If your program is finalized, store it in ROM instead. If you are in the development stage, use a RAM as it's more convenient to upload program modifications.

waterman said:

advantage of ROM: non-volatile
The code is kept even the power lost

If you want to use RAM, you still need a small ROM served
as the boot loader

Click to expand...

When the power's off. The system cannot work any more right?
So it seemed that the difference's only at if using RAM, it still need
time to load code from external device. As the topic state" Is ROM
a must ?" a simple hardware can do the task of loading code.

It seemed that ROM's not a must, right?

roger said:

When the power's off. The system cannot work any more right?
So it seemed that the difference's only at if using RAM, it still need
time to load code from external device. As the topic state" Is ROM
a must ?" a simple hardware can do the task of loading code.

It seemed that ROM's not a must, right?

Click to expand...

no, ROM is a must, you must have at least one small ROM to store the bootloader.

roger said:

When the power's off. The system cannot work any more right?
So it seemed that the difference's only at if using RAM, it still need
time to load code from external device. As the topic state" Is ROM
a must ?" a simple hardware can do the task of loading code.

It seemed that ROM's not a must, right?

Click to expand...

Let's go back to the basics. On power-on reset, the microprocessor jumps to the starting address. For RAM, there is NOTHING at the starting address as it's volatile. So the microprocessor will hang.
And there is no "simple hardware" that can do the task of loading a program onto the RAM on power-on reset, short of another full circuit comprising at least uP/ROM/RAM.
Besides, I think you have the misconception that the program MUST be loaded onto the RAM before it can be executed. The program CAN actually (and most often do) run on ROM, just that all variables are stored on RAM.
Of course, for development purposes, we use the ROM to store the bootloader program, which would allow the developer to more conveniently upload his/her program onto RAM. Burning a program to ROM is usually slower and more cumbersome.

roger said:

for initialize RS232, we can have a hardware executing loding program
as soon as hardware reset.

any other reason?

Click to expand...

Do enlighten us if you feel this is child's play.

Obviously some way of loading RAM is needed because it loses its content when power is removed from it. Typically this is done using a bootstrap loader (which by definition must be in ROM or some other non-volatile storage like FLASH), but, yes, of course this could be implemented some other way such as dedicated hardware, as long as the RAM is loaded before the processor tries to run code out of it; the hardware must hold the processor in reset (or prevent it running in some other way) while RAM is loaded.

Hi checkmate:
Let's go back to the basics. On power-on reset, the microprocessor jumps to the starting address. For RAM, there is NOTHING at the starting address as it's volatile. So the microprocessor will hang

can we just let the hardware of up wait for the completness of loading
code onto RAM , then the microprocessor will not hang . right?

The crux of the problem is in how you are going to upload your program to RAM?

In most case, we have both ROM & RAM, as a hardware engineer,
I am curious about the necessity of ROM, so I post the topic & consult
your idea, tks anyway.

because somebody told me ROM 's smaller than RAM. And there would be
a fatal problem once your romcode's wrong & trapped in somewhere or some defeat in processing. That would make the chip a trash and no
rescue. But if we turn ROM to RAM , any programming error or defeat
will not make the chip a trash.

How to upload code from external device? It can be done by a simple
state machine, the state machine can gen some common protocol like
i2c or spi & issue read command from external device.

I'd appreciate your effort, but firstly I think that you've got to get your notions of RAM and ROM right.
There are many types of ROM. Most on the market now are reprogrammable. If you upload a wrong program, you just reprogram it. Reprogramming may mean using a EEPROM programmer or UV eraser and such depending on the type of EEPROM used. But it won't be trash by all means.
As for RAM, uploading a buggy program can also cause the program to crash. You remedy it by reprogramming it, similar to using ROMs. Except in most cases, reprogramming the RAM can be done after the uP has begun execution (using a bootloader on ROM), and hence more convenient.
Lastly, RAMs are meant to be high-speed. While I have seen some serial RAMs around, those meant for uPs are often parallel with a full address/data bus. We are talking with a lot of pins here.
Even if you do implement a "simple" state machine, THAT state machine would most probably be implemented using another uP/ROM/RAM device, so it all ends up in square one. A ROM is still required. Many people have mentioned that ROMs are a NECESSITY, and probably simply because it is.

In case you are still confused, a uP is a "stupid" device. Upon power-up, it only knows how to jump to the starting address and start executing the first instruction. It does not come along with any pre-born knowledge how to implement any serial protocols, nor does it know of any method to upload a program into RAM.

Roger is right, a system can be run prefectly well out of RAM, given that there must be a way of getting this RAM initialised with code.

A bootstrap loader into RAM (or Flash for that matter when doing in-system programming) is a very common solution to loading the RAM, and it requires a ROM to hold the program. The bootstrap loader is a very common solution because it can handle any source of data, and Roger is right that there can be bugs in code which is in ROM, so there is a risk of problems.

His alternative proposal to use hardware to load data into RAM is also perfectly technically feasible, but this sort of approach is less commonly used because it demands dedicated hardware, which is probably completely unique to each project/company; but then if you've got logic in a gate array for example which is already connected to the RAM address/data anyway, the extra cost could be very small.

However this approach hasn't eliminated the risk of problems, just displaced them; the risk now is that there is a bug in roger's hardware loader. Maybe because the gate array program (RAM-based gate array?) is itself loaded from a programmable memory, this could be updated with relatively simple technology if needed?

Seems like the real solution is in-system programming into flash (e.g. via JTAG or similar); you can download just a bootstrap, or the full application into flash, if its a bootstrap, then it can dowload code into RAM. This gets around roger's objection to a bootstrap (that it can't be changed because it is in ROM) and meets his need to be able to update the software when bugs are found.

Of course JTAG in-system programming is just some dedicated hardware logic which implements a download protocol which can load data into a programmable memory..........aaaagh! it could have bugs!........brain overload.........unrecoverable fault detected........system halti

Hi,

If it is a development board, it is best to have a bootloader in ROM and some amount of RAM to load the code into it, if it is a final roduct, you should consider ROM or even better, a Von-Neumann wired FLASH program memory with a bootloader for In-System Programming.

Regards.