Well, what I mean is a cheap board like the NMIY-0031 that I encountered about 15 years ago. That board provides features that enable the end-user to exploit all the on-chip resources and the full complement of external memory resources. Further, the manufacturer provides "feature" boards that plug into this one if desired. Now I don't pretend that the NMIY-0031 is the ideal 805x application board, nor do I imagine even for a moment that this type of board could support absolutely every type of MCU, but it's certainly conceivable that a "nearly" universal interface could be provided. Naturally, compromises are imposed by the combination of two circuits.


The goal never was to "be running Linux on them" but to run LINUX on a low-cost EVB capable of being connected to a target circuit with the intent of running code residing on the board running LINUX, but addressing hardware on the target. I mentioned that this is similar to using an ICE.

Back in the 8-bit microprocessor days, we didn't have to have a VAX to develop hardware and firmware. We simply built up our target hardware around the host system. I typically built a system that could be plugged into the host. This was often done by simply using the MPU socket. Naturally this won't work with dissimilar MCU's, nor will it work with MCU's that don't have a tristate external bus. With some Motorola MCU's, it was possible to "jam" instructions into the target MCU during a portion of the internal cycle when it expected to "hear" from its internal code memory. Most generally, one has to provide a buffered connector by means of which the host MCU can drive the target system.

That's the way in which I'd hope to capitalize on an ARM processor, operating with a GB of on-board SDRAM, to drive a target board that has much more limited resources, but can benefit from the fact that the host has the same core as the target. That way you can use LINUX to develop, try, and debug code for a target that uses the same core.

RE