8051 on-chip debugging

In message , Schueler writes

This is because most MCU don't have on chip debugging capabilities. Over the last 5 -10 years JTAG has become more common. The 8051 family which is much older does not have it on the majority of parts.

What sort of on chip debugging are you looking for? The Atmel and NXP parts have on chip debug capability when used with an Ice (they use the Hooks and Enhanced Hooks system that does nto require a bondout part)

Others such as Sylabs do have JTAG.

Had you asked last month I had two 8061 ICE to give away (a Nohau and a Hitex) but they have gone now. Might be worth a punt on ebay for Emulators as both iSystem and Signum did Ice for the Dallas/Maxim part you are interested in.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Not easily/cheaply... see the other post.... Closest you will get is to write your own on board 'traps' that dump CPU status/important bits over the com port... or use simple diagnostic LEDs on spare port pins to identify various program points. It's a good processor :)

In message , TTman writes

Or..... If you are using the Keil compiler there is a Monitor system that works well (for a monitor :-)

This is a small piece of SW that will let you put in break points and single step the code on the board etc. It works though the serial port and talks to the Keil uVision simulator debugger.

There are several versions of the monitor depending on the chip and the memory.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Look a the Silabs parts, huge range of nice 8051 derivatives with on chip debug, cheap evaluation boards and debugging tools.

Michael Kellett

Which reminds me that there is a version of the NoICE monitor/debugger for the 8051. I use their ARM debugger with a Segger J-Link quite a lot and their MSP430 on those few occasions lately when I use a 430.

I have not used any of their offerings for the smaller processor families but NoICE has been around for a long time and their lead guy, John Hartman, is pretty fanatical about customer support. If it fits the OP's requirements, I'd definitely recommend it for consideration.

--
Rich Webb     Norfolk, VA

Looks interesting and something to consider if you can't get the Keil system.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

I'd skip any 8051 CPU. Move to ARM and save yourself a couple of headaches. Most ARM controllers have full debugging capabilities. But... you should realise you can't debug realtime processes anyway.

If you want to build a motor controller I'd first calculate the minimum and maximum PWM limits and hardcode these in software. The next step is to prototype the control loop using dummy input values. This can be done on a PC (and debug on a PC) since you are far better of writing complex pieces of software on a PC first and then compile them for your embedded platform.

There should be very little use for a debugger on microcontrollers. In other words: avoid having to use a debugger on a microcontroller.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

We must have very different development styles - I won't use a micro without on chip debug if I can help it. I debug real-time systems on a regular basis and it's on real-time when hardware debug support really matters. Non real-time allows you to use software debugging tools like monitors or even print statements, when you hit a big problem on a real-time system then trace, hardware breakpoints etc etc come into their own.

Recently I've had to work with the AVR32 using IAR tools (rather limited hardware debug) and I really miss all the good debug stuff I've got used with Keil and ARM Cortex M3.

I do agree about skipping 8051 unless there is a very good reason to stay with it - even though the Silabs bits are nice I haven't done a new design with one for some time (in fact not since STM32F.... ARMs appeared).

Michael Kellett

Dear all,

thanks so far for contributing to this fruitful discussion. I finally bought the MDE 8051 Trainer Board populated with the MAXIM DS89C4xx 8051 derivate. It features the ability to being programmed via HyperTerminal by means of a hex file. Since this is my first encounter with microcontrollers, let me ask you for advice how to generate a hex file for this device. Is there any freeware or open source tool for this purpose of how should I proceed? Thank you.

"Michael Kellett" schrieb im Newsbeitrag news: snipped-for-privacy@bt.com...

I don't want to start another battle here about terminal emulators. Everyone seems to have their favourite - but there is a solid consensus that HyperTerminal is the worst option. I'd recommend you get Tera Term Pro - it's free, and works well. If you want to know what's wrong with HyperTerminal, or what alternatives there are, /please/ search the comp.arch.embedded archives before posting anything on the subject. And if anyone else wants to recommend a different program, and really feels it is worth the time and effort to go through the subject /again/, please start a new thread.

As for how to generate a hex file, you get that from your compiler. The top-class compiler for the 8051 is Keil, with a matching price. There are a number of mid-level commercial tools at varying prices and functionality (in particular, they vary as to which 8051 devices they support directly). Then there is the open source SDCC. My understanding (without having used any of these tools) is that SDCC generates good, sensible code, but is not nearly as clever as Keil at re-using and merging memory. But then, if you were interested in writing efficient code that runs quickly, you wouldn't be using an 8051 in the first place.

Be prepared for another battle here, by the way. There will be people who reject the idea of using anything other than Keil as heresy and false economy, and others that recommend different tools. After all, if a tool is good enough, then it is good enough - you don't need the best, you only need something that will do the job required.

[Please don't top-post.]

The Small Device C Compiler (aka sdcc) is free open-source software and is reasonable to start out with. You're probably best to begin poking around with getting your first "Hello, world!" program (i.e., get a selected pin to toggle at a selected rate) in assembler so that you get accustomed to the 8051 architecture before moving on to C programming.

--
Rich Webb     Norfolk, VA

In message , David Brown writes

I have used this one and it supports only the mainstream 8051's The Dallas parts are not mainstream and use a non standard core with additional non standard SFR's

SDCC does not generate good or sensible code. Last time we had this discussion and it got heated someone (no names to protect the guilty) who was arguing very strongly for the SDCC was going to produce a comparison between the two. Some two years later and we are still waiting....

Keil used to recommend the Dunfield 8051 compiler for hobby users with no money.

There is the option of course of the Keil evaluation compiler. The biggest problem with the 8051 is the very small amount of RAM. You usually run out of this first rather than program memory. The Keil uses a rigorous calling tree analysis to do data overlaying. Something you should not do manually! I have seen 120 bytes of data shrink to 19 bytes in the Keil compiler.

It also comes with a large number of example programs.

The other point of the Keil system is the extremely good simulator debugger. It will also mate with the

PCB design software which also has a spice simulator. SO you can actually simulate the hardware and software. The Lancenter SW is not expensive.

NOTE it is worth looking around at come of the 8051 dev kits as the limit on their eval Keil compilers is twice the normal one.

Ouch! Be fair the 8051 is very cost effective for a lot of things. Not everything warrants a PPC :-)

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Well, I'm not going to argue for or against tools I haven't used, and don't intend to use - I was merely passing on what I've heard, with some predictions on how this thread would proceed.

The 8051 is a good choice if you have a lot of legacy code, or if you want a weird chip that happens to contain an 8051 core. Otherwise there are much better choices in almost every way - both in terms of the chips themselves and the tools around them. I fully agree that not every project warrants a PPC - you don't buy a chip that is more expensive, requires more power, or is more difficult to use than necessary. But you are talking about an architecture that is stuck in the land that time forgot - if you drop the 8051 requirement, then you can always find better chips.

Well, having different SFRs doesn't hurt the compiler. As long as the controller can run 8051 code you can use SDCC. The term support for microcontroller families is always a bit vague. The people maintaining GCC for the MSP430 finally agreed not to have a command line option which specifies the controller. Instead you select the proper link file and header files.

Sorry, but the Dunfield 8051 compiler is a real piece of crap. CRAP! CRAP! CRAP! CRAP! Yes, I admit I'm one of the dumb suckers who actually bought the Dunfield 8051 compiler. If you have no money use SDCC. Even the very first versions of SDCC will outperform the code generated by the Dunfield compiler at 1/4 the clock rate.

I'd rephrase that as: if you want to use good quality free tools, the

8051 is a really bad choice.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

ght

t

hex

you

are

You can move from a DS89C4xx, to a more modern device, and make up any compiler differences in the silicon.

So the SiLabs C8051F581 for example, has 128KF, and 8KRam, and has OnChip debug that works with SDCC.(not a terminal download-and-hope)

Search for TOOLSTICK582DC, and TOOLSTICKBA, for the low cost pair to develop.

-jg

Then don't bring it up. The trouble with hyperterminal is that in the end of the day it can do everything including releasing the serial port without closing the program (which AFAIK Tera term can't do).

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------