Good question. To some extent it has to be Von Neumann if we're going to be loading and unloading programs on demand from a storage device.

I'm thinking that maybe the solution would be to have the central 8052 boot off of fixed code in EPROM--or in flash memory if the part we choose supports it. This boot code would serve no purpose other than to load the operating system off of storage into RAM. Once the OS is in RAM (starting at 0000h) the system would output a signal so that the EPROM would be disabled and execution would be from RAM thereafter.

Assuming that, say, P3.5 is "high" to map code memory to the boot EPROM and P3.5 is "low" to map code memory to RAM, I envision something like this:

** EPROM BOOTLOADER:

0000h LJMP 0060h
0050h CLR P3.5
0060h -- Code to boot from storage goes here
....
01FFh LJMP 0050h

** OS LOADED INTO RAM BY BOOTLOADER:

0000h LJMP INITOS
0003h-0032h: ISR vector table
0052h AJMP 0000h

So when the system boots up it's executing from EPROM. The EPROM, at 0060h, does whatever it needs to do to access external storage, loads the OS into RAM, and when it's done it jumps to 0050h which clears P3.5 and, in doing so, changes the memory map so that code is executed from RAM rather than EPROM. The Program Counter is then at 0052h but the next instruction will be executed out of RAM which now holds the OS that was loaded. The instruction at 0052h jumps to 0000h which initializes the OS and we're ready to go with a completely Von Neumann architecture.



I'm of the opinion that the inter-8052 communication should be done on a direct bus. But I guess doing some kind of data mapping is possible, too. What would be the benefits of such an approach?



I initially thought it would be part of the central 8052, but it was suggested that I/O have its own dedicated 8052. The benefit of this is that less memory (and CPU time) of the central 8052 would be consumed with I/O. All the central 8052 would have to do is communicate with the I/O "co-processor."



Funny, I was just thinking of that myself. It would be great if the other 8052s could access memory directly. Although it does increase the risk of major system crashes if the code in *any* of the 8052s is bogus and starts writing to the wrong place.



Another good question.



If we assume that the "mass storage" is actually handled by an 8052 dedicated to I/O, the bootcode on the main processor only needs to be sufficient to query the I/O chip for the data of the OS via whatever interchip communication protocol we agree on. The I/O chip would then get the data for those OS itself from whatever is considered to be the boot device on that particular system. With this approach the actual boot firmware on the central 8052 could be very, very short.

Regards,
Craig Steiner