8051 on-chip debugging

In message <hJojp.71343$2_5.68074@newsfe25.ams2>, ChrisQ
<meru@devnull.com> writes
>
>In that respect, jtag has been a real boon, as there is no longer any
>justification for ice.


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

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

In message <4d8e1de9.90993203@news.kpnplanet.nl>, Nico Coesel
<nico@puntnl.niks> writes
>Chris H <chris@phaedsys.org> wrote:
>
>>In message <4d8d35dc.31587953@news.kpnplanet.nl>, Nico Coesel
>><nico@puntnl.niks> writes
>>>YMMV. For ARM you can use GCC + Eclipse which is completely free.
>>
>>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.
>
>GCC + Eclipse are completely free. Nobody is charging you for using
>them.

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...
>
>Nope, just translating the command line options. Most C compilers do
>the same thing: source in - object out.

Oh dear....

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

krw@att.bizzzzzzzzzzzz wrote:

> 
> Got a suggestion for an 8051 derivative with I2C, USB, and complete x51 ports?
> I have a project coming up that's essentially a rehash of a product that's
> been shipping for a decade.  I need to add a bunch of crap to it but the boss
> wants to salvage the code in the original device (he doesn't trust
> programmers' schedules).  If I were starting from a clean slate, I'd probably
> go with a Cortex M0 and throw the thing over the wall to the programmers.  If
> it stays with an 8051 I might do the whole thing myself.

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

On 03/26/2011 06:12 PM, Nico Coesel wrote:
> Chris H<chris@phaedsys.org>  wrote:
>
>> In message<4d8d35dc.31587953@news.kpnplanet.nl>, Nico Coesel
>> <nico@puntnl.niks>  writes
>>> YMMV. For ARM you can use GCC + Eclipse which is completely free.
>>
>> 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.
>
> 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.

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.

On Sat, 26 Mar 2011 17:39:38 +0000, ChrisQ <meru@devnull.com> wrote:

>krw@att.bizzzzzzzzzzzz wrote:
>
>> 
>> Got a suggestion for an 8051 derivative with I2C, USB, and complete x51 ports?
>> I have a project coming up that's essentially a rehash of a product that's
>> been shipping for a decade.  I need to add a bunch of crap to it but the boss
>> wants to salvage the code in the original device (he doesn't trust
>> programmers' schedules).  If I were starting from a clean slate, I'd probably
>> go with a Cortex M0 and throw the thing over the wall to the programmers.  If
>> it stays with an 8051 I might do the whole thing myself.
>
>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. 

You got that right!

>The overall structure is often poor as well. 

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.

>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.

You're preaching to the choir.

>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.

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.

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

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

Arlet Ottens wrote:

> 
> What's the problem with "overkill", if it doesn't come at any extra cost 
> ? The small ARM controllers are very easy to use.
> 
> ARM tool chain (free for small projects), trivial to set up:
> http://lpcxpresso.code-red-tech.com/LPCXpresso/
> 

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

Nico Coesel wrote:

> 
> 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.

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.


> 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 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'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.
>

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

Chris H wrote:
> In message <hJojp.71343$2_5.68074@newsfe25.ams2>, ChrisQ
> <meru@devnull.com> writes
>> In that respect, jtag has been a real boon, as there is no longer any
>> justification for ice.
> 
> 
> That is not correct.  JTAG and ICE are different. The Majority of MCU
> don't have JTAG.
> 

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

On 26.03.2011 12:57, Nico Coesel wrote:
> =?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?=<HBBroeker@t-online.de>
> wrote:
>> On 26.03.2011 01:53, Nico Coesel wrote:

>>> Headaches: no real stack (7 levels deep is not a stack and you must
>>> keep some locations free for interrupts)
>>
>> Pardon the French, but you don't know what you're talking about.
>>
>>> so the compiler must use
>>> overlays for function calls.
>>
>> That it does, for lack of stack size.  But no, the limit is _not_ 7 levels.
>
> Its something like 7 levels.

Nowhere near.

 > Maybe its 5 maybe its 10. Anyway, it is
> not much. It has been too long since I bothered to look at it.

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.

>>> in C, you still can't really port the code due to all the pragmas,
>>
>> None involved.
>
> xram xrom iram?

Aren't pragmas.

>> Yes, it really doesn't like function pointers.  But there's a huge step
>>from that to what you claim.
>
> 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.

It's nowhere near _that_ bad.

> 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.

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

On Mar 27, 4:03=A0am, "k...@att.bizzzzzzzzzzzz"
<k...@att.bizzzzzzzzzzzz> wrote:
>
> I just ran their search tool. =A0With async, I2C, and USB, the best they =
can do
> is 25 bits of I/O in a 32 pin package. =A0That might work, depending on w=
hat's
> left off, but I need to replace an existing (Atmel) part.

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

Perhaps their PDF selector guide is better than a search ?