8051 on-chip debugging

"Schueler" <berti.schueler@arcor.de> wrote:

>Folks,
>
>
>
>I would like to use the 8051 derivate MAXIM DS89C4xx in one of my 
>experiments regaring motor controlling but I am worried about the on-chip 
>debugging capabilites. I could not find any material on this topic. Does 
>anybody know whether the DS89C4xx series support debugging or not? Any other 
>known 8051 derivate which features on-chip debugging and which offers an 
>evaluation board?

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

Nico Coesel wrote:

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

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
couple of years ago with an si labs device and the s/w to drive it was
well within the 4 k toolchain limit. The design included sine lookup
table, voltage reg, current limit, over and undervoltage on input and
inverter rails and a serial port for continuous stream status o/p. More
than fast enough as well.

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. The arm toolchain is more complex
to set up as well, unless you spend $K on commercial tools.

It's all about choosing the right tool for the job...

Regards,

Chris

"ChrisQ" <meru@devnull.com> wrote in message 
news:6e9jp.130137$P95.83941@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.

---Joel

Joel Koltner wrote:
> "ChrisQ" <meru@devnull.com> wrote in message 
> news:6e9jp.130137$P95.83941@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.
>

It's a little way down the road, but there are obvious benefits in terms
of common hardware and software libraries, not to mention the investment
in time that is needed to become fluent in any new architecture.
8 bits can still be usefull though and modern 8051 class devices are
running at 50-100 mips, so well able to keep up at much lower overall
complexity. For the inverter, *everything* was written in C,
including pwm interrupt handlers. Not a line of assembler in sight.
They include a device with 24 bit a-d, which will be used in a current
project. The key thing is that all the a-d, d-a and digital circuitry
will be in one, low pin count package.

I guess an equivalent arm  would be one of the Cortex M0 devices,
but they don't have a a-d resolution.

> If you're paying engineers for their time, *good* commercial tools
> are well worth the money.
> 

No argument there, but it's not always easy to convince the client :-).
Isn't the Keil toolchain for arm now around 4.5K ukp ?...

Regards,

Chris

"ChrisQ" <meru@devnull.com> wrote in message 
news:oG9jp.202369$Bg2.146325@newsfe03.ams2...
> No argument there, but it's not always easy to convince the client :-).
> Isn't the Keil toolchain for arm now around 4.5K ukp ?...

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

On Fri, 25 Mar 2011 23:06:25 +0000, ChrisQ <meru@devnull.com> wrote:

>Nico Coesel wrote:
>
>> 
>> 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.
>
>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
>couple of years ago with an si labs device and the s/w to drive it was
>well within the 4 k toolchain limit. The design included sine lookup
>table, voltage reg, current limit, over and undervoltage on input and
>inverter rails and a serial port for continuous stream status o/p. More
>than fast enough as well.

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

>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. The arm toolchain is more complex
>to set up as well, unless you spend $K on commercial tools.
>
>It's all about choosing the right tool for the job...
>
>Regards,
>
>Chris

ChrisQ <meru@devnull.com> wrote:

>Nico Coesel wrote:
>
>> 
>> 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.
>
>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) so the compiler must use
overlays for function calls. 3 different memory areas. Very cumbersome
(=slow) access to external memory with different instructions to get
data from ROM or RAM. The real problem is that even though you program
in C, you still can't really port the code due to all the pragmas,
language extensions and the inability to really use pointers (which
clutters your program because you'll make all variables global).

Which leads me to a point which IMHO is often overlooked. When
deciding to use a platform you'll also invest time to write specific
libraries for that platform. For some reason the decision never seems
to include calculating the loss when moving to a different platform.

>Arm are a great solution, but overkill for a small application, even

In the end the price counts and ARMs are (getting) cheaper due to the
heavy competition.

>though I do expect to standardise all dev around arm in due course, if poss,
>once all the infrastructure is in place. The arm toolchain is more complex
>to set up as well, unless you spend $K on commercial tools.

YMMV. For ARM you can use GCC + Eclipse which is completely free.
Since GCC and Eclipse support a very wide range of platforms and
programming languages chances are that you don't need to learn a new
toolchain if you already use GCC + Eclipse. Most compiler vendors have
or are switching to Eclipse anyway.

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.

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

On 03/26/2011 12:06 AM, ChrisQ wrote:

>> 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.
>
> 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
> couple of years ago with an si labs device and the s/w to drive it was
> well within the 4 k toolchain limit. The design included sine lookup
> table, voltage reg, current limit, over and undervoltage on input and
> inverter rails and a serial port for continuous stream status o/p. More
> than fast enough as well.
>
> 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. The arm toolchain is more complex
> to set up as well, unless you spend $K on commercial tools.

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/

>>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)
SNIP

how do you arrive a 7 level stack on a 51 ???? Or did I misunderstand ? 

"Nico Coesel" <nico@puntnl.niks> wrote in message 
news:4d8cf865.15853187@news.kpnplanet.nl...
> "Schueler" <berti.schueler@arcor.de> wrote:
>
>>Folks,
>>
>>
>>
>>I would like to use the 8051 derivate MAXIM DS89C4xx in one of my
>>experiments regaring motor controlling but I am worried about the on-chip
>>debugging capabilites. I could not find any material on this topic. Does
>>anybody know whether the DS89C4xx series support debugging or not? Any 
>>other
>>known 8051 derivate which features on-chip debugging and which offers an
>>evaluation board?
>
> 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