8051 on-chip debugging

Its something like 7 levels. Maybe its 5 maybe its 10. Anyway, it is not much. It has been too long since I bothered to look at it.

xram xrom iram?

Its not just function pointers but also pointers to variables and structs lead to extremely bulky & slow code. Making all variables and structs global is the only solution to keep your code running fast.

And then try to have a pointer point to a string which can be in internal ram, external ram or rom and use standard string functions like strcpy, printf, etc, etc.

No, the 8051 sucks you down into an abyss of archaic programming methods, limits and workarounds.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel
Loading thread data ...

lacking I2C. I see the SiLabs parts have I2C but it appears they don't have full 8051 ports. SiLabs is interesting anyway.  

I just ran their search tool. With async, I2C, and USB, the best they can do is 25 bits of I/O in a 32 pin package. That might work, depending on what's left off, but I need to replace an existing (Atmel) part.

This product is designed by management to be a kludge. There is already an FTDI async-to-USB bridge, but that's reserved for existing functions. The new functions are to be tied in through a USB bridge.

Reply to
krw

In message , Joel Koltner writes

And for the 8051 there is no better system than Keil

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

In message , Nico Coesel writes

No it isn't and never has been. IF may be free to download but that is not the same thing. Ask you project manager.

SO you spent a lot of money converting a compiler...

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

No, are you perhaps thinking about early pic ?. The C8051F410 that I used in the inverter has 256 bytes of sram and 2k of xdata ram on chip, as well as 16 or 32 Kbytes of flash. The stack is fully descending in sram space, more than enough for most projects and the Keil linker uses overlays in xdata space where this is exceeded.

Sorry, but that's absolute tripe. I had to make no concessions at all in coding style using these devices and the Keil toochain. Extensive use of pointers, including function pointers and had no problems at all.

Again, sorry, tripe and shows a complete lack of knowledge of later devices and tools.

I never expected be defending 8051 architecture, having last programmed

80c31 in the late 80's with quite primitive tools, but times move on and you need to stay up to date and objective...

Regards,

Chris

Reply to
ChrisQ

We had a similar issue with the Keil compiler package, where the vendor wanted to sell us a dongled copy. We needed the ability to run the tools at client site or mine and since I was the only user, it seemed reasonable that we shouldn't have to pay twice. I think we paid a few hundred extra to have the undongled version, which was still a premium, but we did get a deal done for the overall package, which saved a lot of money and included a hardware emulator.

In that respect, jtag has been a real boon, as there is no longer any justification for ice. Most of the functionality is included and what isn't can be worked around...

Regards,

Chris

Reply to
ChrisQ

GCC + Eclipse are completely free. Nobody is charging you for using them. Yes it takes time to learn to use Eclipse as does any IDE. The real beauty of Eclipse is that you only need to learn it once and you can use it with almost any language on any platform. I've used Eclipse to debug C/C++ code and PHP. It works exactly the same.

Nope, just translating the command line options. Most C compilers do the same thing: source in - object out.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

You're be right about that. That's PIC stuff.

The stack in the 8051 grows up, not down. Since the SFRs and the registers are also in SRAM space you actually have less than 256 bytes of SRAM. And the stack has limited room as well because the SFRs start at 128.

Just look at the machine code. You'll see that a lot of the 8051's CPU power is wasted on juggling with memory. The Keil compiler truly is a work of art but it can't change the laws of the 8051 physics. And I doubt your function pointers where in RAM. AFAIK even the Keil compiler can't handle that because it can't determine how and when to overlay.

I've actually worked on a 8051 project a short while ago and I have done a lot of 8051 projects in the past. I know why I'm avoiding 8051.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

In message , ChrisQ writes

That is not correct. JTAG and ICE are different. The Majority of MCU don't have JTAG.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

IF may be free to download but that is not the same thing. Ask you project manager.

Oh dear....

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
 Click to see the full signature
Reply to
Chris H

The first thing to do is to analyse the original source code and compare against required spec. A lot of early 8 bit projects were written at least partly in asm and the coding standards, commentary and docs were often poor or non existent. The overall structure is often poor as well. If you can't work out how the parts of the code relate to each other, or build the big picture, ie: you don't really understand how it works, then you can't have confidence that any mods or additions won't break something or introduce bugs. Analysing old code can be a very, very time consuming business, even if there are docs, because docs never tell you the whole story, for example, critical timing loop horrors and other undocumented dependencies, buried deep within the code. It's all made worse by the cavaliar use of global variables, making it difficult to analyse what's peeking or poking what. Open source tools like doxygen will generate call trees and variable lists and are really valuable if you are trying to make sense of an old code base.

I don't want to sound pessimistic, but clients will often say "we just need these few mods", thinking it's simple, when gut feeling tells you it will save time to scrap most of the old code and start again.

Of course, you know all this already :-)...

Regards,

Chris

Reply to
ChrisQ

The commercial IDEs/compilers also take time to learn, so there's not much difference. Some of the IDEs are also very poorly made, such as Microchip's MPLAB.

I've programmed H8, AVR, various ARM flavors, x86, MIPS, and PIC, all using GCC. The time invested in learning the GCC tricks has paid off multiple times.

Reply to
Arlet Ottens

You got that right!

Bingo. Spaghetti doesn't even start to describe it. There is a *ton* of dead code in there too. The device is trivial, but firmware isn't my call. I do hardware.

You're preaching to the choir.

When the owner of the company says he wants to do something his way, he gets to. I'm not going to argue about firmware. I get to do enough of that with just the hardware.

Yup. That's one reason I don't do code anymore. I have a severe case of xenocryptophobia. ;-)

Reply to
krw

Don't argue with any of that, just that I don't have all the infrastructure in place yet. That includes toolchain, function libraries and all the other stuff that you gather over time as you work with an architecture. Meanwhile, I need to earn a living, using the most appropriate and economic solutions, irrespective of current fashion status.

For someone with little or no prior experience and for small projects, it would be faster and more cost effective to buy the si labs kits. The simpler architecture is easier to get to grips with and the $50 to $100 kits get you up and running with working code within an hour.

I expect to be using them for some time, despite all the negative reviews. Arm is not yet one size fits all, especially w/regard to analog peripherals...

Regards,

Chris

Reply to
ChrisQ

Descending or ascending is not really relevant, It *is* a proper stack with enough range to get the job done. Have a look at the data sheet for the

-410. 256 bytes of sram *in_addition* to the sfr's. 2 Kb of xram, and 64 bytes on the battery backed up clock.

I don't (thankfully) need to look at the assembler op, as the Keil toolchain is good enough to negate any such requirement. But yes, if I do look, the compiler produces pages of impenetrable assembler, but who cares, if you are riding on a 50 or 100mips device ?. It's more than fast enough even with the 8 bit arch..

I wouldn't give you a thankyou for one of the older style 8051 devices, but as I said, times move on and you need to stay objective...

Regards,

Chris

Reply to
ChrisQ

Agreed, but we are splitting hairs. Rephrase to say that most modern mainstream mcu's have on chip debug capability, either jtag, bdm or some such.

Btw, none of this is new. The pdp11 from the mid 1980's had a microcode debug monitor that used a serial port. Not so flexible as the present stuff, but you could examine / change memory, run from address etc. Porting such ideas to the mcu world was only a matter of time...

Regards,

Chris

Reply to
ChrisQ

Nowhere near.

Well, piece of advice: before you _repeat_ such claims, after having been challenged about them twice, by two different people, maybe you should go check on your facts first.

Aren't pragmas.

It's nowhere near _that_ bad.

Then you just do that. The tools know how to deal with the trickiness this entails. Better than you do, anyway.

Reply to
=?ISO-8859-15?Q?Hans-Bernhard_

can do

hat's

?? Their C8051F340, shows 2 Uarts, SMbus, USB, 64KF, in a QFP48 package ?

Perhaps their PDF selector guide is better than a search ?

Reply to
Jim Granville

There is no project manager so tell me where I should send the money if I use Eclipse.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
 Click to see the full signature
Reply to
Nico Coesel

No USB.

I used their parametric search, clicked UART, USB, and I2C. I only see 28 and

32 pin packages. "Dig I/O" bar only shows between 21 and 25 I/Os.
Reply to
krw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.