Actually, where 'C' language programming is of major use for microcontrollers with limited (<<4MB) code space, is the case in which fairly sizeable modules have to be combined and integrated to work together. People were writing code blocks of up to 8KB in assembler with few complaints for years before 'C' became available for MCU's. 'C' language does generate bigger object files than ASM, but at less cost in terms of effort. However, what really makes the difference is how well the support tools, e.g. linker, debugger, simulator, work to make the integration task happen.

However, with 2KB code size limits, it's hard to evaluate how well the toolset helps with tasks like that. It would have to be a really contrived task to allow one to evaluate that. If I have a task that I'd estimate will generate 2KB of code, there's no problem using ASM, but if I have several of them, particularly if I want them in 'C', I'd like to see how well, smoothly, seamlessly, I can put them together in a single code block for the 8052. Thta's what helps in choosing an MCU for the task. After all, a Motorola processor might work out better, cheaper, faster, or in some other way advantageous. How much help do I get with that task from the "demo" version? The biggest part, of course, will be in simulating and debugging the simulation result. Since the simulation is just functional, and since it can't be synchronized with realtime events, or even crudely simulated in that mode using an external stimulus file, there's really little help.

RE