Hi,
I use Keil to simulate C8051F120 but I cannot view the all peripherals of MCU (No hardware debug). I can view all peripherals if I use C8051F005. Anyone know about it? Am I missing something?
Thanks, pak
I use Keil to simulate C8051F120
WHY simulate when you can emulate?
Erik
Because simulation can be used as a complement to normal testing for doing automatic regression-testing of complex software before every new release?
Pak; What toolset are you using? I just flipped over into uVision3 and opened a blinkly example and loaded the F120 as the optional device. In simulation, I have all the peripherals available. I'm running uV3 V3.50 with compiler C51 V8.04 (not the latest). The simulator CPU.dll is S8051.dll V3.04 and the dialog dll is DCYG.DLL V2.45. Check your versions for these programs or even later versions of these programs. Bradford
As Al Bradford said,try to update your toolset to a more recent version.
I had the same problem before I updated the Compiler,Simulator library,etc.
Sorry for late reply.
WHY simulate when you can emulate? because software simulation will save time as you know
What toolset are you using? I used C8051F120DK from Silabs and update uV3 and uV3 is V3.50, S8051.dll is V3.10 and DCYG.dll is 2.48f. Al, I can use Keil debugging with C8051F120DK and view all the peripherals. But, I just want to simulate since software simulation is saving time
Thank for suggestion, friends pak
"WHY simulate when you can emulate?"
Well, you wouldn't be emulating, would you?
You'd be "probing" a real chip (using its on-chip debug) - so it'd have to be in a real board...
NO, I do not know that. I have been mislead by a simuulation often enough. How does simulation 'save time' over emulating???
"How does simulation 'save time' over emulating???"
As already noted, he doesn't have emulation
HUH?
all SILabs chip have emulation built in and the software is FREE. Erik
"all SILabs chip have emulation built in"
No, it's not emulation, is it? It's the real thing, with direct access to hardware provided by the on-chip debug stuff.
So, to use this, you have to have a real chip running in a real board.
Thus you can save time by using Simulation while you wait for your real board and/or real chip to arrive...
"Thus you can save time by using Simulation while you wait for your real board and/or real chip to arrive..."
In addition to that, there are so many hardware faults that are not related to the program logic that can go wrong in a on-chip debug session that you can really lose more time using the on-chip debug than you would in the simulator.
The simulator is invaluable to quicly validate algorithms, investigate actual compiled code, and eliminate faulty hardware interference.
I cherish that fact. For many hardware problems, there is no better tool than the emulator. The "lose more time" comes back tenfold in saved time trying to debug the hardware by other means.
Of course, if you are a 'software only' guy, the that may be different, but that would hamper you in many other ways when doing small embedded?
"if you are a 'software only' guy, the that may be different, but that would hamper you in many other ways when doing small embedded?"
Well, if you are a 'software only' guy it will probably be harder for you to tackle an embedded design from head to toe.
My point in this discussion is that the simulator is a very good tool in the development flow. Both the simulator and the on-chip debugger are important in different phases of the system debug and verification.
For example, during development the simulator allows you to feed specific complex patterns to a system using signal functions. You can isolate the software component being tested, sometimes impossible in the full running hardware. This setup is extremely versatile, and can be used to test the system in conditions unfeasible/difficult to setup in real hardware. Also, it allows to test for a variety of 'noise' stimuli under very controlled conditions. On the same token, the on-chip debugger could be used to validate and verify the simulation tests on real hardware.
For example, I use the simulator to predict failsafe conditions on several external failures that would be expensive to test when you have just one prototype of the hardware. These are then verified in the pilot stress and destructive testing.
In addition to that, a good set of bench equipment are also invaluable. I use a multitrace digital storage oscilloscope much more than the on-chip debug after the thing learned to walk and talk. Especially in the 8051, I always have a few pins used as hardware debug flags to monitor and validate the real hardware response.
I totally do not understand arguments like this: "predict failsafe conditions" = important product "when you have just one prototype" = this is not important.