8051 on-chip debugging

On 26.03.2011 01:53, Nico Coesel wrote:
> ChrisQ<meru@devnull.com>  wrote:

>> Sorry, but what headaches ?. You can't equate modern gen risc core 8051
>> with the original intel devices. We built a 400Hz 3ph pwm inverter a
>
> 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.

> in C, you still can't really port the code due to all the pragmas,

None involved.

> language extensions

The few ones involved are pretty standard in the embedded world, being 
nothing more but expansions of the traditional __far/__near pattern, and 
can be ported just fine.  You just have to follow standard practice and 
put a macro as a delimiter between your code and the compiler.  Redefine 
the macro and all the language extensions are gone.

> and the inability to really use pointers

The majority of any such inability would be in the users' head.

Yes, it really doesn't like function pointers.  But there's a huge step 
from that to what you claim.

On Mar 26, 12:15=A0pm, "k...@att.bizzzzzzzzzzzz"
> Got a suggestion for an 8051 derivative with I2C, USB, and complete x51 p=
orts?
> I have a project coming up that's essentially a rehash of a product that'=
s
> been shipping for a decade. =A0I need to add a bunch of crap to it but th=
e boss
> wants to salvage the code in the original device (he doesn't trust
> programmers' schedules). ....The current widget uses an Atmel 8051 but it=
's lacking I2C.  I see the SiLabs parts have I2C but it appears they don't =
have full 8051 ports.  SiLabs is interesting anyway. =A0

What do you mean SiLabs do not have full 8051 ports ?

USB is not broadly common on 8051, but Silabs do have 48 pin USB with
external RAM options.

Another option, is to add USB via a USB bridge chip.
Frees up your part selection choices, and  Silabs have those, and the
virtual UART drivers to match.

-jg

=?ISO-8859-15?Q?Hans-Bernhard_Br=F6ker?= <HBBroeker@t-online.de>
wrote:

>On 26.03.2011 01:53, Nico Coesel wrote:
>> ChrisQ<meru@devnull.com>  wrote:
>
>>> Sorry, but what headaches ?. You can't equate modern gen risc core 8051
>>> with the original intel devices. We built a 400Hz 3ph pwm inverter a
>>
>> 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. Maybe its 5 maybe its 10. Anyway, it is
not much. It has been too long since I bothered to look at it.

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

xram xrom iram?

>> language extensions
>
>The few ones involved are pretty standard in the embedded world, being 
>nothing more but expansions of the traditional __far/__near pattern, and 
>can be ported just fine.  You just have to follow standard practice and 
>put a macro as a delimiter between your code and the compiler.  Redefine 
>the macro and all the language extensions are gone.
>
>> and the inability to really use pointers
>
>The majority of any such inability would be in the users' head.
>
>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.

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...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On Sat, 26 Mar 2011 03:00:15 -0700 (PDT), Jim Granville
<j.m.granville@gmail.com> wrote:

>On Mar 26, 12:15&#4294967295;pm, "k...@att.bizzzzzzzzzzzz"
>> 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. &#4294967295;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). ....The current widget uses an Atmel 8051 but it's lacking I2C.  I see the SiLabs parts have I2C but it appears they don't have full 8051 ports.  SiLabs is interesting anyway. &#4294967295;
>
>What do you mean SiLabs do not have full 8051 ports ?

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.

>USB is not broadly common on 8051, but Silabs do have 48 pin USB with
>external RAM options.
>
>Another option, is to add USB via a USB bridge chip.
>Frees up your part selection choices, and  Silabs have those, and the
>virtual UART drivers to match.

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.

In message <xk9jp.288677$Ud7.70304@en-nntp-16.dc1.easynews.com>, Joel
Koltner <zapwireDASHgroups@yahoo.com> writes
>"ChrisQ" <meru@devnull.com> wrote in message news:6e9jp.130137$P95.8394
>1@newsfe05.ams2...
>> Arm are a great solution, but overkill for a small application, even
>> though I do expect to standardise all dev around arm in due course, if poss,
>> once all the infrastructure is in place.
>
>Good approach.  What I've seen a lot of lately is such competitive
>pricing for 32-bit microcontrollers that even though, yeah, they're
>overkill, you might as well get some of the extra creature comforts
>when they're just about free.
>
>> The arm toolchain is more complex
>> to set up as well, unless you spend $K on commercial tools.
>
>If you're paying engineers for their time, *good* commercial tools are
>well worth the money.

And for the 8051 there is no better system than Keil


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

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.

>I admit I have spend quite some time to understand GCC and binutils
>but since its the same for every platform the time is not wasted when
>moving to a different platform. Recently I had to write some firmware
>for a PIC controller. For that purpose I wrote a wrapper around the
>PIC C compiler so it behaves like GCC and so I could use Eclipse
>instead of Microchip's IDE.

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


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

Nico Coesel wrote:

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

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.

>>> and the inability to really use pointers

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.

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

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

Joel Koltner wrote:

> 
> I was thinking more like 3-4k, but yours is close enough (I'm kinda 
> guesstimating the US$ to UKP exchange rate anyway and it's been a year 
> or two since I looked...).  However, I have found that at least with 
> some software companies the rates are quite negotiable -- some years 
> back we were able to get a few seats of IAR Studio for roughly 
> half-price due to IAR's salesguy being (correctly) convinced that 
> without such a price drop, he simply wasn't going to get the business 
> period.
> 
> ---Joel
> 

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

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.

>>I admit I have spend quite some time to understand GCC and binutils
>>but since its the same for every platform the time is not wasted when
>>moving to a different platform. Recently I had to write some firmware
>>for a PIC controller. For that purpose I wrote a wrapper around the
>>PIC C compiler so it behaves like GCC and so I could use Eclipse
>>instead of Microchip's IDE.
>
>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.

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

ChrisQ <meru@devnull.com> wrote:

>Nico Coesel wrote:
>
>> 
>> 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.
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>No, are you perhaps thinking about early pic ?. The C8051F410 that I

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

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

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.

>>>> and the inability to really use pointers
>
>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.

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.

>> No, the 8051 sucks you down into an abyss of archaic programming
>> methods, limits and workarounds.
>>
>
>Again, sorry, tripe and shows a complete lack of knowledge of later
>devices and tools.

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...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------