Why is small-scale ARM development such a pain

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Ok, I'm spoiled by AVR Studio.  Works great,
lets me use assembly language with a single
.asm file, debugger takes one pin, not much
to complain about.

Why isn't there an equivalently painless
solution for the small ARM devices?  Everything
we've tried is a great mass of codependent
GNU software stuck together with a less-than-
user-friendly value-added front end.



Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

I don't find it a pain at all.  I've used Rowley Crossworks with either Row=
ley or Segger JTAG devices, and it all works quite nicely.  No one-pin debu=
gging, but I don't consider that lack a pain.  And I'd give my neighbor's r=
ight arm if AVR Studio had the equivalent of Rowley's tasking library.

Re: Why is small-scale ARM development such a pain
On Wed, 18 Apr 2012 14:22:14 -0700 (PDT), snipped-for-privacy@scriptoriumdesigns.com

Quoted text here. Click to load it
or Segger JTAG devices, and it all works quite nicely.  No one-pin debugging,

Do you mean serial wire debug (SWD)? If so, it is supported. Check under
"target interface type" in the JTAG properties.

--
Rich Webb     Norfolk, VA

Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

Look harder. Most ARM toolchain vendors (Keil, IAR etc.) support the
Cortex-M0/M3 and debugging over the SWD (single-wire debug) interface.

-a

Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

Back in the old days we used to debug with a logic analyser and an ICE the size
 of a small house. The code was programmed into UV eraseable EPROMS. We could
 manage about 4 edit/compile/debug cycles per day. If you think ARM development
 is a pain, you don't know real pain :)

To be serious though, the ARM dev systems I have used are pretty good. You have
 to pay a bit of learning curve for your 32 bits though. I would avoid anything
Eclipse based or that requires external gdb servers though.

Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

I think you mis-spelled LED.

Quoted text here. Click to load it

Who doesn't remember the smell of the ozone from the UV eraser!

Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it


For starters, one man's "painless" is another man's "painful".  :)

Quoted text here. Click to load it

You had ICE and a logic analyzer?  Lucky pup.  I remember a lot of
projects that were developed using the just "edit-compile-burn-crash"
cycle with UV EPROMs.  If you were lucky you had a spare port pin you
could toggle and an storage oscilloscope to look at the pin.  Storage
scopes were rare and expensive, so more often that not you had to
settle for "I/O pin debugging" that was limitted to stuff in loops
that could run fast enough to light up the phospor frequently enough
to be visible.

And we had to walk to work and back in a blizzard -- up hill both
ways!

As one of the developers I worked with used to say "the best debugger
is looking at source code and thinking".

Quoted text here. Click to load it

I tried AVR studio for a while and found it slow, clumsy, and overly
restrictive. Add in the fact that you had to use Windows to run, and I
dropped it pretty quickly and went back to an occasional diagnostic
"printf" and sometimes command-line gdb via JTAG or the like.

If you really want something more like AVR studio, a lot of people
seem to like Rowley CrossWorks.  It's vendor and OS neutral, which
wins them a lot of points in my book.

I also know people who try to use Eclipse for Embedded work...

--
Grant Edwards               grant.b.edwards        Yow! I feel like I am
                                  at               sharing a ``CORN-DOG''
We've slightly trimmed the long signature. Click to see the full one.
Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

The percentage of people using Eclipse for Embedded work is rising
rapidly.  Steadily more toolchain IDE's were either Eclipse from day
one, or are moving to it on newer versions.  It is quickly becoming
/the/ standard IDE.

Eclipse is a little daunting when you first use it, and older versions
were very slow and bloated - but modern versions are pretty fast, and
there are a lot of convenient tools in it.  Once you have got over the
initial hurdles (understanding workspaces, perspectives, etc.), it's
fast and easy to use.

I don't think anyone knows why Atmel moved away from Eclipse to use MSVS
for their IDE - it is at least as big, slow, bulky, and unsuited as the
worst Eclipse IDE I've seen, and adds non-standard and single-platform
into the mix.


Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it
development
Quoted text here. Click to load it


Kind of. If we take another step backward, it took three quarters of a
hour to feed the assembler into a Nova 1200 or PDP-8 using an ASR-33
and paper tape (provided the reader did not make an error). The net
effect was one edit/assemble/debug cycle per day, if you were lucky.

Quoted text here. Click to load it
anything
Quoted text here. Click to load it

I'm happy with the GNU toolset and an editor (kedit on Linux etc).
For debugging OpenOCD and a wiggler perform well enough. A correction
cycle is usually less than 10 minutes.

--

Tauno Voipio

Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

Maybe you need to go next door for a little management training solution !

http://maps.google.com/maps?q14%03+5th+St.+Suite+D,+Davis,+CA+95616&ll38%.548635,-121.733708&spn=0.005605,0.011362&sll38%.548730,-121.733695&layer=c&cbp13%,323.21,,0,-11.89&cbll38%.548653,-121.733593&gl=us&hnear14%03+5th+St,+Davis,+California+95616&t=h&z17%&panoid=gp34YFZCI9YnNjtH4jgBkQ


Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it
http://maps.google.com/maps?q14%03+5th+St.+Suite+D,+Davis,+CA+95616&ll38%.548635,-121.733708&spn=0.005605,0.011362&sll38%.548730,-121.733695&layer=c&cbp13%,323.21,,0,-11.89&cbll38%.548653,-121.733593&gl=us&hnear14%03+5th+St,+Davis,+California+95616&t=h&z17%&panoid=gp34YFZCI9YnNjtH4jgBkQ

Long gone.  Now a holistic health center. Should
I go there instead?


Re: Why is small-scale ARM development such a pain

Quoted text here. Click to load it

Because you haven't gone out and built your own gnu toolset (Google for
"summon-arm-toolchain") along with your own startup code, then gone on to
have a ball?

gnu arm tool chain, gnu debugger, Eclipse -- joy.

--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
We've slightly trimmed the long signature. Click to see the full one.
Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

Or s/Eclips/emacs/g.

The point is you have lots of choices.  It's not a one-suit-fits
everybody situation.

--
Grant Edwards               grant.b.edwards        Yow! Am I having fun yet?
                                  at              
We've slightly trimmed the long signature. Click to see the full one.
Re: Why is small-scale ARM development such a pain

Quoted text here. Click to load it

What's emacse?  Is than a newer version that's even harder to figure out
how to get out of?

--
Tim Wescott
Control system and signal processing consulting
We've slightly trimmed the long signature. Click to see the full one.
Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it


Nah. Emacsis easy to get out of:

ps -aux | grep emacs

<result is a PID>

kill -9 <PID>

--
Les Cargill

Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

Touché!

--
Grant Edwards               grant.b.edwards        Yow! Mr and Mrs PED, can I
                                  at               borrow 26.7% of the RAYON
We've slightly trimmed the long signature. Click to see the full one.
Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it

Put simply, because when I want to produce a
metal part, nobody expects me to build a lathe
and mill first.

Quoted text here. Click to load it


Re: Why is small-scale ARM development such a pain

Quoted text here. Click to load it

Jim, I know where you are coming from and I agree, so I apologise for not
having given a really practical reply before.

For the direct question, and at the risk of stating the obvious, Atmel have a
different business model to ARM. Atmel sell silicon and see an advantage to
providing a good free IDE for developers. ARM don't sell silicon, they sell IP
to companies who make silicon and then sell tools to end-users. Since both
companies seem to be doing pretty well, it appears they have chosen market
strategies that work well for them.

The implicit question is what ARM IDE is as good as AvrStudio? Not used
AvrStudio for a while, but I have recently evaluated Keil, IAR, CodeSourcery,
Crossworks, CooCox, as well as Eclipse+CDT+gcc+gdb, and by default vanilla
text editor + gcc + printf. This is not a comprehensive survey by any means
only a sample of the main players.

I assume you are using windows, you don't mention whether it is for personal
or professional use. CodeSourcery and CooCox are Eclipse based, so we
eliminate those. I marginally prefer IAR, but my employer went for Keil, Keil
is perfectly adequate for my needs. For hobby stuff I am liking CrossWorks. I
have tried Eclipse + free tools, some swear by them, but they do not suit me.

You could also look at software bundled with dev boards e.g: mBed (NXP),
Xpresso (NXP, CodeRed), STM Discovery (ST, Atollic?). These and the other
commercial IDEs above all have limited free versions or evaluation versions.

I doubt there is an ARM IDE to exactly match AvrStudio, but IMO there are
several
IDEs that are perfectly usable. The caveat being that the better ones are not
free for non-trivial applications.

Re: Why is small-scale ARM development such a pain
Quoted text here. Click to load it
 and there you have a nice summary as why " small-scale ARM development such a
pain".

 It's the classic falls between two stools problem :

 Atmel sell chips, and so long as their BIG customers have a solution, they are
ok.
 ARM _sell_ tools, so they are in no hurry to help small scale / open source
offerings. Why would they lower their profits ?

 So something like AVR Studio, which Atmel MUST have to sell AVR8 & AVR32s, will
always be ahead of any small scale ARM offerings.

 There may be some good news, as Atmel's newest offering is now renamed "Atmel
Studio 6", and it includes ARM debug flows.

["Atmel Studio 6 Integrates ARM and AVR Design in Single Environment"]

 I think you may need to buy their SAM-ICE, and it is not clear how 'other
brands' might work, but they do now claim ARM support in Studio.

 Press release is also sketchy on Simulator support for ARM. ( WIP? )
-jg

Re: Why is small-scale ARM development such a pain

Quoted text here. Click to load it
IP
Quoted text here. Click to load it
pain".

It doesn't have to be. Rowley sells their full kit, including the RTOS,
for only $150 for a personal, non-commercial license. The deeper innards
are accessible to those who want them but it's pretty much install, load
the "package" for the target processor, and go. Decent IDE and debugger
and it supports the cheap Olimex JTAG dongles out of the box as well as
a score of others. I can't imagine how it could be any more pain free.

Get a $30 header board from Olimex or one of their resellers and it's
game on.

#disclaimer: just a customer (full commercial license, though)

--
Rich Webb     Norfolk, VA

Site Timeline