Searching \ for '[EE] The time has come' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/timers.htm?key=time
Search entire site for: 'The time has come'.

Exact match. Not showing close matches.
PICList Thread
'[EE] The time has come'
2008\02\06@111505 by David VanHorn

picon face
I am taking a very long look at my future involvement with the AVR line.
Support from atmel has been thin to non-existent, and although I
really LOVE their internal architecture, I can't continue to work with
tools that only work when they feel like it.   It used to be, that
their tools were dead solid, and support through the local FAE was
excellent.  Ask a question, get an answer that really helped.
Things have changed though, and although I'm sure they support their
10,000,000 part customers, it's feeling awfully Zilog-ish these days
from where I sit.


I've been wrestling with the AVR support line for a long time, over
their "studio" tool, which works well for some people, but decidedly
not for others.
It used to work well for me, but not lately.  Despite much digging on
my part, I can't find a reason.

What would you say, if your favorite tool decided to start throwing
problems like this:

( Initial conditions: ZH = $FF, ZL = $FF, TEMP = $FF, Pointer=$0108)

ldi  ZL,low(pointer)  ;ZL should now be $08
ldi  ZH,high(pointer) ;ZH should now be $01
ldi  TEMP,0  ;TEMP should now be $00

(exit conditions: ZH=$FF, $ZL=$FF, TEMP=$FF)

Not in the chip mind you, this is AVR studio walking through some
really simple code.
In the chip, the code ALWAYS works.  In Studio, the code works on
alternate tuesdays, unless it feels like doing something different.
I don't want to get into the whole mess here, but trust me it's a
problem in Studio, which unfortunately is the only front end for their
debugging tools.




If you had to bet your life on your choice, what microcontroller
family would you choose?

Evaluation criteria:

1: ROCK SOLID DEVELOPMENT TOOLS

2: Third party tools

By "tools", I mean emulation/ICE/IDE, not compilers.

3: Vendor support.  When their tools don't work, what happens?

2008\02\06@123746 by Brendan Gillatt

flavicon
face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

David VanHorn wrote:
{Quote hidden}

I would probably choose some kind of ARM chip - perhaps from NXP. I've
had very little experience with them myself, though from reading about
them and browsing the internet, there seems to be hundreds of bits of
software written on or for the ARM system.

They are a bit pricey, however. The one I'm looking at at the moment, the
LPC2106, weighs in at £13 from RS!

For lower end things, I would choose a PIC! All three of those points are
hit:
1) Never had a problem with MPLAB.
2) Certainly many compilers / disassemblers / debuggers, etc.
3) I found a bug in C18, reported it and an update was released within 2
weeks! They responded within a couple of hours through e-mail.

- --
Brendan Gillatt | GPG Key: 0xBF6A0D94
brendan {a} brendangillatt (dot) co (dot) uk
http://www.brendangillatt.co.uk
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFHqfBQuv4tpb9qDZQRAngeAJ9N9w1pxtzsc+6ljyAkFmwlHHEPIQCgvMQo
gAyi1stq1TfvLBUOBsaGExw=
=zeik
-----END PGP SIGNATURE-----

2008\02\06@134915 by Peter Todd

picon face
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Feb 06, 2008 at 11:15:03AM -0500, David VanHorn wrote:
{Quote hidden}

4: Open source?

Depends on what you're doing of course, but sdcc hasn't let me down, too
much. :)

Still, ICD and open source... not much of that around, only one I've
heard of is ironically for Atmel.

- --
http://petertodd.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHqfsU3bMhDbI9xWQRAmDdAKChxmQ1IZr5DJusFVHgSfMCKfRwDgCfbFJ7
reiHcHtjIMP5RdOOw1cjxVA=
=huI1
-----END PGP SIGNATURE-----

2008\02\06@140103 by David VanHorn

picon face
> > 3: Vendor support.  When their tools don't work, what happens?
>
> 4: Open source?
>
> Depends on what you're doing of course, but sdcc hasn't let me down, too
> much. :)
>
> Still, ICD and open source... not much of that around, only one I've
> heard of is ironically for Atmel.


I'm not aware of anything that takes the place of AVR Studio in
driving their emulation.
Ice/Jtag ice, etc.

2008\02\06@154625 by Matt Pobursky

flavicon
face
On Wed, 6 Feb 2008 11:15:03 -0500, David VanHorn wrote:
{Quote hidden}

I think it's really a moving target. Right now if I had to bet my life and
make only one microcontroller family work for everything it would be the
MSP430 family and tools. Second would be PIC, especially with the new J
series parts and my move totally away from Microchip tools. Third would
probably be any ARM7 and most ARM9 family parts, these are rising fast on
my list and are likely to be co-number 1's soon.

One thing we've done here is to realize that no one family is good for
everything. So we've developed a framework that makes it easy to port code
(and CPU's for that matter) from design to design. We develop everything in
C in a standard framework so if we decide to switch processors it's usually
no more than a week or two process, even on relatively complex designs. And
we've done it more than a couple times too.

One belief I have developed over the past 25 years in this crazy business
is that "Chip Companies" can't do decent code. Maybe "can't" is a little
strong, but almost never do is more accurate. And when they do they tend to
charge exhorbitant prices or they make fixes exceedingly slow. They have
gotten a little better over the years, but generally third party tools are
almost alway better and more cost effective. Technical support is almost
always better too, in my experience. The smaller the company the less
bureaucracy.

The people that do my MSP430 tools (Quadravox) typically send me a bug fix
within 24 hours. Same with the AVR and ARM tools vendor (same company,
Rowley Associates). The PIC tools (CCS PICC) tend to be a bit of a moving
target but once you find a stable version and stick with it, the debugger
alone makes it so much better than MPLAB. CCS also releases bug fix
versions quite regularly and their tech support has been very responsive
the few times I've actually contacted them.

So I guess my short answer is -- there is no perfect chip family or tools.
We just keep looking for those that meet the same criteria as yours, do our
designs so we can change if we have to and if it comes to that, change
chips/tools.

Matt Pobursky
Maximum Performance Systems

2008\02\06@160439 by David VanHorn

picon face
> > ... [snipped typical development tool bug which results in much
> >       hair pulling, cursing and lost time] ...
>
> I think it's really a moving target.

No doubt, the AVR tools USED to be rock solid, but the rock broke.



> One belief I have developed over the past 25 years in this crazy business
> is that "Chip Companies" can't do decent code. Maybe "can't" is a little
> strong, but almost never do is more accurate. And when they do they tend to
> charge exhorbitant prices or they make fixes exceedingly slow. They have
> gotten a little better over the years, but generally third party tools are
> almost alway better and more cost effective. Technical support is almost
> always better too, in my experience. The smaller the company the less
> bureaucracy.

Yup, "we can't fix the tools for last month's chip because we're
working on next month's chip"

>
> The people that do my MSP430 tools (Quadravox) typically send me a bug fix
> within 24 hours.

By "tools", you're meaning compiler though.. I'm specifically talking
about the ICE/SIM side, which is single-sourced with Atmel, in AVR
Studio.


> So I guess my short answer is -- there is no perfect chip family or tools.
> We just keep looking for those that meet the same criteria as yours, do our
> designs so we can change if we have to and if it comes to that, change
> chips/tools.

Yup, no "Mr Right", but maybe I can find "Mr Right Now".

2008\02\06@172943 by Matt Pobursky

flavicon
face
On Wed, 6 Feb 2008 16:04:38 -0500, David VanHorn wrote:
>>> ... [snipped typical development tool bug which results in much hair
>>> pulling, cursing and lost time] ...
>>>
>>
>> I think it's really a moving target.
>>
> No doubt, the AVR tools USED to be rock solid, but the rock broke.

A couple years ago we had a new client with an "emergency" AVR project
-- their existing consultant bailed on them and left them with built
hardware and no software to stick in it. We took the job and became
frustrated with AVR Studio/debugger problems, plus we were right at the
limit of fitting the code in the chip the boards were populated with.

We tried a demo of Rowley Associates AVR tools and haven't looked back.
Code size was about 15% smaller, their debugger is rock solid and tech
support was (is) incredible. I would suggest to anyone that makes money
working with AVRs to check out their tools.

The client was overjoyed, we made their shipping deadline and have since
done 3 or 4 more projects for them. (Interestingly, no AVR though -- two
PIC and one MSP430 based designs).

>> The people that do my MSP430 tools (Quadravox) typically send me a bug
>> fix within 24 hours.
>>
>
> By "tools", you're meaning compiler though.. I'm specifically talking
> about the ICE/SIM side, which is single-sourced with Atmel, in AVR Studio.

Quadravox supplies their own debugger/IDE and uses the standard TI JTAG
debugger interface. Rowley also does the same for the AVR, MSP430 and ARM
family tools. The Rowley IDE/debugger works with the standard Atmel pods, I
can't remember if they include a simulator since I rarely if ever use them.

I think Microchip and Atmel have really hurt 3rd party development tools in
the long run by releasing free IDE (MPLAB, AVR Studio). I one asked a PIC
tool vendor why they didn't do their own debugger interface since MPLAB is
so horrible at C source level debugging -- that answer was "Free is hard to
compete against". If they made MPLAB or AVR Studio open source or public
domain then things might be different and they would get more development
attention from 3rd parties then they seem to be willing to do themselves.

I honestly think you are better off with tools that use the vendors own
IDE/debugger interface since it's their only business and in their best
interest to keep it working and up to date. The chip companies don't have
much motivation to put a lot of resources (and don't) on software tools.

Matt Pobursky
Maximum Performance Systems

2008\02\06@212051 by William \Chops\ Westfield

face picon face

On Feb 6, 2008, at 9:37 AM, Brendan Gillatt wrote:

> I would probably choose some kind of ARM chip

Are you kidding?  I've been on several ARM lists for a while, and it  
looks like very few ARM chip vendors support their own set of tools.  
Some rely on open source tools (which range from "works well" to  
"near disaster" depending on tool and/or chip), and some rely on  
third party development software (similar results.)

Speaking of which, are there any non-Atmel tool sets that might work  
better for AVR?  I looked at a couple vendors whom I though had full  
replacements for AVRStudio, but it looks like simulation is pretty  
rare...

I'm tempted to recommend Freescale, but in truth I have no idea how  
good or bad their support of small customers is (and it used to be  
bad, according to the net.)

BillW

2008\02\06@233036 by Matt Pobursky

flavicon
face
On Wed, 6 Feb 2008 18:20:25 -0800, Chops\ wrote:
>
> On Feb 6, 2008, at 9:37 AM, Brendan Gillatt wrote:
>
>> I would probably choose some kind of ARM chip
>>
> Are you kidding?  I've been on several ARM lists for a while, and it
> looks like very few ARM chip vendors support their own set of tools. Some
> rely on open source tools (which range from "works well" to "near
> disaster" depending on tool and/or chip), and some rely on third party
> development software (similar results.)

Chip vendors not supplying their own tools is a good thing. ;-)

I haven't found any yet that produce anything above mediocre tools compared
to good third party tools. They are good at making chips but not so good at
software tools, in my experience.

Most of the ARM vendors use the ARM gcc compiler as their base, it's a good
compiler and produces good code. What else they include with their tools
(IDE, debugger, etc.) is what separates the men from the boys.

> Speaking of which, are there any non-Atmel tool sets that might work
> better for AVR?  I looked at a couple vendors whom I though had full
> replacements for AVRStudio, but it looks like simulation is pretty rare...

Look at Rowley Crossworks for AVR if you want to see a truly outstanding
tool set. Their tools for the MSP430 and ARM are equally high quality. I
have no affiliation with them, just a satisfied customer and user.

http://www.rowley.co.uk/

I rarely use simulation, even with the packages that include it. I'd rather
run code on real hardware and almost all the debugging necessary is
hardware related anyway or requires interaction with the outside world.

> I'm tempted to recommend Freescale, but in truth I have no idea how good
> or bad their support of small customers is (and it used to be bad,
> according to the net.)

I haven't run across many good 3rd party tools for them but haven't looked
in a while. Last I looked they had acquired Metroworks and were using their
tools. I tried them and thought they were pretty bad. Maybe things have
improved by now but Motorola (back in the day) was what turned me off of
chip company supplied tools to begin with.

All my responses should be tempered with the fact I'm not a hobbyist but a
consultant doing development work for hire. I would likely have a different
attitude if this was just a hobby.

Matt Pobursky
Maximum Performance Systems

2008\02\07@042243 by Mike Harrison

flavicon
face
On Wed, 6 Feb 2008 18:20:25 -0800, you wrote:

>
>On Feb 6, 2008, at 9:37 AM, Brendan Gillatt wrote:
>
>> I would probably choose some kind of ARM chip
>
>Are you kidding?  I've been on several ARM lists for a while, and it  
>looks like very few ARM chip vendors support their own set of tools.  
>Some rely on open source tools (which range from "works well" to  
>"near disaster" depending on tool and/or chip), and some rely on  
>third party development software (similar results.)

Who is likely to do a better job at devtools - a semi maker whose main business is making chips, or
a 3rd party whose main business is making devtools?

>Speaking of which, are there any non-Atmel tool sets that might work  
>better for AVR?  I looked at a couple vendors whom I though had full  
>replacements for AVRStudio, but it looks like simulation is pretty  
>rare...

AVR is a good illustration of my point above....AVR studio took many years to become more than a
toy.
I've found that IAR's software works much more reliably with JTAG-ICE. They do a free code-limited
(4K)  version.
I also use IAR for ARM (NXP) which also works pretty well (once you get the hand of an unnecessarily
complicated project/linker setup)


2008\02\07@103541 by David VanHorn

picon face
> Who is likely to do a better job at devtools - a semi maker whose main business is making chips, or
> a 3rd party whose main business is making devtools?

Well, I would hope that the chip vendor would have the ultimate inside
track on emulation, but my experience with tools provided by chip
vendors has been awful.  Mplab is arguably the best, but it's been a
long time since I used it, and that was before I touched the AVR,
which was also wonderful for a while.


> AVR is a good illustration of my point above....AVR studio took many years to become more than a
> toy.

Hmm.. Not sure of chronology, but I developed my first AVR app in
studo, using the sim, since real silicon for the 8515 was not yet out.
I still have my first 8515 chip, date code "ES".  :)   I went from
"what's an AVR?" to delivered app in six weeks.

Today, I feel I could spend six weeks trying to get Studio to work with:

Here:
   rjmp Here


Studio today suffers from an advanced case of DFW error.





Dosen't F***ing Work.

2008\02\07@110611 by William Couture

face picon face
On Feb 6, 2008 11:30 PM, Matt Pobursky <spam_OUTpiclistTakeThisOuTspammps-design.com> wrote:

> Look at Rowley Crossworks for AVR if you want to see a truly outstanding
> tool set. Their tools for the MSP430 and ARM are equally high quality. I
> have no affiliation with them, just a satisfied customer and user.

Have you tried the IAR compiler / debugger?  How do they compare?

Bill

--
Psst...  Hey, you... Buddy...  Want a kitten?  straycatblues.petfinder.org

2008\02\07@122836 by William \Chops\ Westfield

face picon face

On Feb 7, 2008, at 1:34 AM, Mike Harrison wrote:

> Who is likely to do a better job at devtools - a semi maker whose  
> main business is making chips, or a 3rd party whose main business  
> is making devtools?
>

Well, sure.  But the original complaint is against Atmel tools for  
AVR, so it's hardly fair to compare that (free, manufacturer-
supplied) toolset against an expensive 3rd party toolset.  Rather  
than go to a new processor, the first step should be to go to a new  
toolset for the old processor.

I would normally hope that a chip manufacturer would provide a  
certain number of working tools for their chips, even if that only  
means having hired someone to collect, patch, and package the  
appropriate versions of open source tools.  As Dave's frustrations  
indicate, "working" is more important than "fancy."

As for freescale, there are certainly plenty of open source tools  
once you get to their larger CPUs (coldfire, ppc)

BillW

2008\02\07@124804 by Bob Blick

face picon face
--- David VanHorn <.....microbrixKILLspamspam@spam@gmail.com> wrote:

> Today, I feel I could spend six weeks trying to get
> Studio to work with:
>
> Here:
>     rjmp Here
>
>
> Studio today suffers from an advanced case of DFW
> error.

Hi Dave,

I assume you've tried installing AVR Studio on a
machine that previously had no devtools installed on
it, just to rule out some nasty hidden conflict?

And if worst comes to worst, judging from the comments
in another thread, you could try installing Windows
Vista, some users say it's gear fab and runs
everything just fine :)

Best regards,

Bob

2008\02\07@133556 by David VanHorn

picon face
> I assume you've tried installing AVR Studio on a
> machine that previously had no devtools installed on
> it, just to rule out some nasty hidden conflict?

Yup. I've been having this problem intermittently for years.
Sometimes it goes away, and I can get real work done, but then it comes back.
The machine I'm using now, has only XP, office, and similar apps on,
no other programs that have anything to do with AVR development.

> And if worst comes to worst, judging from the comments
> in another thread, you could try installing Windows
> Vista, some users say it's gear fab and runs
> everything just fine :)

Funny.. Real funny...

:-P



Here's what I just sent to Atmel regarding the problem, after they
again asked me to tell them how to exactly repeat it:


To summarize.

I know I'm asking you to do something difficult, to track down an
intermittent problem that you aren't seeing in your installation.

What you're asking me to do though, is pretty much impossible, to tell
you WHY it's intermittent.


It's as if I wrote some routine that used uninitialized memory, then
shipped it to you inside a product, and told you to define exactly how
to reproduce the problem, and refused to do anything about it until
you did.


I'm willing to go to any reasonable length to solve this, install any
additional diagnostic software, send you memory dumps or whatever, but
it sounds like you're asking me to do the impossible here.


Please, for my sake, and all the other users having these problems,
ASSUME that the problem is real, and investigate how it might happen.
I have had to deal with a number of incidents like this over my
career, and while it's not easy, it is workable.

I will say it again for clarity.

There MAY be multiple problems here, but from my point of view as a
Studio user, I don't see anything that indicates this is the case, so
I will refer to the issue as a single problem:

The problem is not dependent on the debugger used (jtag ice or whatever).

The problem is not code dependent.

Here:
  ldi  R16,0    ; I have every reason to believe that this is enough
  ldi  R16,1    ; code to duplicate the problem, when and if the problem
  rjmp Here     ; chooses to surface.

  You would see the sim or emulation fail to load R16, or it might
fail to execute the rjmp, and if there were some other routine below,
it would drop into that.  I've seen it fail to step into subroutines,
both with and without actually executing the code in the routine. Less
frequently, I've seen compares fail where the Z or other flag should
have been set or cleared, but it wasn't.  Whatever code you'd be
having problems with, would run perfectly in a real chip. (except of
course for any ACTUAL errors in the code, but the machine would be
doing EXACTLY what the code said to do)

The problem is not dependent on a particular PC. I've had this problem
on at least a dozen different PCs.

The problem is not dependent on a particular ICE. I've had it on
multiple ICE-50 units, multiple Jtag Ices, from Atmel and clones, and
on the MkII, as well as having times that studio would completely
refuse to program a
chip using the AVRISP. That same chip and code programmed perfectly
the day before, and later that day when I drove it down to PRIIO in
Indianapolis to use their CableAVR.  Later that week, Studio was able
to again program the chip using exactly the same PC, serial port,
cable, AVRISP, etc.  This is when I spoke to Sarah Cox, and was told
that they had simply given up on using Studio because of these same
problems.

The problem is not dependent on a particular build of Studio, though
there MAY be builds that do not exhibit the problem, and I just
haven't been lucky enough to install any of them in the last several
years.


The problem is not dependent on the particular device type, or the
physical device at all.. I've had these problems with the tiny-11,
tiny-15, tiny-26, 2343, 8515, M8, M128, and M168.  (In short, every
AVR i've done any real work on)  Different date codes, clocks,
crystals, internal RC, you name it. 5V, 3.3V.  On the STK-500, on my
own target boards, on prototypes, on anything.

The problem is not about simulation or emulation, it happens in both.

Studio, itself, is broken.
The problem is intermittent.
Those of us who are having the problems, have no idea why.
Those of us who are not having the problems, have no idea why not.

2008\02\07@142914 by Bob Blick

face picon face
--- David VanHorn <microbrixspamKILLspamgmail.com> wrote:
> The problem is not about simulation or emulation, it
> happens in both.
>
> Studio, itself, is broken.
> The problem is intermittent.
> Those of us who are having the problems, have no
> idea why.
> Those of us who are not having the problems, have no
> idea why not.

People have file-copy problems in Vista sort of the
same way. Until it happens, it doesn't happen.

I'd be tempted to make a VMware XP or W2K image that
definitely exhibits the problem, and mail it to Atmel,
and convince others to do the same. And write a
letter(snail mail) to an executive or two.

And contact someone in investor relations asking if
they care to comment on reports that some major
customers were planning to switch because of unfixable
flaws in the dev tools :)

Cheerful regards,

Bob

2008\02\07@142953 by sergio masci

flavicon
face


On Thu, 7 Feb 2008, David VanHorn wrote:

> I'm willing to go to any reasonable length to solve this, install any
> additional diagnostic software, send you memory dumps or whatever, but
> it sounds like you're asking me to do the impossible here.

David, would it be at all possible to install VM Ware on your XP box,
running a virtual XP inside it and sending a snapshot of that to Atmel?

Regards
Sergio

2008\02\07@144041 by David VanHorn

picon face
> David, would it be at all possible to install VM Ware on your XP box,
> running a virtual XP inside it and sending a snapshot of that to Atmel?

Interesting.
I've never done VMware before, but I'd be willing to do that, if they
could use it.

2008\02\07@150101 by Bob Blick

face picon face
Here's a link to VMWare server. You need to
register(free and immediate) for a serial number:

http://www.vmware.com/download/server/

Cheers,

Bob



--- David VanHorn <.....microbrixKILLspamspam.....gmail.com> wrote:

> > David, would it be at all possible to install VM
> Ware on your XP box,
> > running a virtual XP inside it and sending a
> snapshot of that to Atmel?
>
> Interesting.
> I've never done VMware before, but I'd be willing to
> do that, if they
> could use it.
> --

2008\02\07@152317 by David VanHorn

picon face
On Feb 7, 2008 3:00 PM, Bob Blick <EraseMEbbblickspam_OUTspamTakeThisOuTsbcglobal.net> wrote:
> Here's a link to VMWare server. You need to
> register(free and immediate) for a serial number:
>
> http://www.vmware.com/download/server/


Got it, thanks.


I set up the most trivial app that I could think of, that actually
does something demonstrable.
I single-stepped it in the Studio debugger using their JtagIceMkII

;
; For a mega-168 with reset vector set to $1E00
; Internal RC clock, any speed
;
.org $1E00

Reset:        ;At this point, R16 is uninitialized with $00

       ldi                R16,$01
;At this point, R16 has $FF

       ldi                R16,$FE
       ;At this point, R16 has $FF

       rjmp        Reset
       ;This jump did not go to reset, it went somewhere else,
       ;and I had to RESET the ice to recover.

2008\02\07@171702 by David VanHorn

picon face
On Feb 7, 2008 3:00 PM, Bob Blick <bbblickspamspam_OUTsbcglobal.net> wrote:
> Here's a link to VMWare server. You need to
> register(free and immediate) for a serial number:
>
> http://www.vmware.com/download/server/

Hmm.. XP and studio installed ok, but I can't connect to the Jtag ice.
I got the device enumerated ok on the emulated system, but after 20+
tries, still no connect.
It only usually takes 5-6 normally.

2008\02\07@171829 by Matt Pobursky

flavicon
face
On Thu, 7 Feb 2008 11:05:49 -0500, William Couture wrote:
> On Feb 6, 2008 11:30 PM, Matt Pobursky <@spam@piclistKILLspamspammps-design.com> wrote:
>
>> Look at Rowley Crossworks for AVR if you want to see a truly
>> outstanding tool set. Their tools for the MSP430 and ARM are equally
>> high quality. I have no affiliation with them, just a satisfied
>> customer and user.
>>
>
> Have you tried the IAR compiler / debugger?  How do they compare?

Yeah, TI distributes a limited version of it with their MSP430 "Kickstart"
kits.

IAR produces very compact code, best of all the tools or very near it. I
don't care for their debugger and user interface as much, it seems a bit
disjointed (the debugger runs separately from the Compiler/IDE). It's a
quality tool set from a solid company that's been around a long time. I
think it's overpriced compared to the quality of some other 3rd party
tools. Large company guys seem to feel comfortable with IAR much in the
same way corporate IT guys are comfortable with Dell or IBM.

As a quick summary, this is how I'd rate the MSP430 tools:

Rowley Crossworks: Mid priced, excellent code output, excellent tech
support and excellent features.

Quadravox AQ430: Low priced, solid tools. Kind of a "poor man's" IAR. Good
code size, I like the user interface better than IAR, excellent tech
suport. Good buy for a developer on a budget.

IAR: A little pricey, excellent code output, solid company. This is the
standard everyone else is compared to.

ImageCraft: Least expensive, least features. Good but not excellent code
output. Very good tech support. They've been around a while and produce
solid tools.

Really any of these tools are workable for professional development work.
They are all good, some are just better. They all have evaluation versions
and you can get a feel for what fits your style and budget best by trying
them.

Matt Pobursky
Maximum Performance Systems

2008\02\07@174502 by Bob Blick

face picon face
--- David VanHorn <KILLspammicrobrixKILLspamspamgmail.com> wrote:

> Hmm.. XP and studio installed ok, but I can't
> connect to the Jtag ice.
> I got the device enumerated ok on the emulated
> system, but after 20+
> tries, still no connect.
> It only usually takes 5-6 normally.

USB? Set it in VMWare to "exclusive" use if possible.
But didn't you say the AVR Studio error appears in
simulation as well? I'd try it that way since what
you'll want to send Atmel as proof is the simplest
thing possible.

Cheerful regards,

Bob

2008\02\07@174548 by Mark Rages

face picon face
On Feb 7, 2008 4:18 PM, Matt Pobursky <RemoveMEpiclistTakeThisOuTspammps-design.com> wrote:
{Quote hidden}

...

>

You didn't mention mspgcc.  I just switched a project over from IAR
when we hit the code size limit.

The code from gcc is about as compact as IAR was.  The closed-source
debugging stuff is a little flaky, but gcc seems solid as usual.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
TakeThisOuTmarkragesEraseMEspamspam_OUTmidwesttelecine.com

2008\02\07@180124 by David VanHorn

picon face
> USB? Set it in VMWare to "exclusive" use if possible.
> But didn't you say the AVR Studio error appears in
> simulation as well? I'd try it that way since what
> you'll want to send Atmel as proof is the simplest
> thing possible.

Yeah, but the sim screws up significantly less.
That's ok though, I got it to connect, and it hosed up that three line program.
Interesting too, it's exactly the same as it was on the "real" system.

Now I have a snapshot of it in the hosed state, so I just email them
the snapshot?

2008\02\07@180805 by sergio masci

flavicon
face


On Thu, 7 Feb 2008, David VanHorn wrote:

{Quote hidden}

How big is your snapshot? I would have thought it was quite big.
Personnally, I'd get them to agree to look at it first.

Regards
Sergio

2008\02\07@180832 by Bob Blick

face picon face
I was wrong on that, it is RS232 so use is exclusive
by default. So no help :(

Cheers,

Bob

--- Bob Blick <RemoveMEbbblickspamTakeThisOuTsbcglobal.net> wrote:

{Quote hidden}

> --

2008\02\07@181210 by Bob Blick

face picon face

--- David VanHorn <EraseMEmicrobrixspamgmail.com> wrote:

> Now I have a snapshot of it in the hosed state, so I
> just email them
> the snapshot?

It'll be a big image even if you zip it(especially if
it's XP), and you'd want to send them the virtual
machine, it will be the current state(snapshots are to
go back to an earlier time).

Cheers,

Bob

2008\02\07@182015 by David VanHorn

picon face
> How big is your snapshot? I would have thought it was quite big.
> Personnally, I'd get them to agree to look at it first.

600-ish K when RARed for sending.
Smaller than the flash files I sent them to show them the problem.

Not bad for debugging a four word program.
:)

2008\02\07@182427 by David VanHorn

picon face
> It'll be a big image even if you zip it(especially if
> it's XP), and you'd want to send them the virtual
> machine, it will be the current state(snapshots are to
> go back to an earlier time).
>

Maybe I got the wrong thing.. It was 17M before RAR.
"VMware virtual machine snapshot"

There's a pair of 1G Vmem files, and an 8G Vdisk file

2008\02\07@183306 by sergio masci

flavicon
face


On Thu, 7 Feb 2008, David VanHorn wrote:

{Quote hidden}

When I said "snapshot" I actually meant a copy of the entire virtual
machine frozen at the point at which you had the problem, so that they
could load it and run it themselves. I haven't done this myself - yet. It
was just a thought. You will need to look at this in more detail yourself
but I'm guessing the files you'll want to send are going to be VERY big
:-)

Regards
Sergio

2008\02\07@184004 by Bob Blick

face picon face
--- David VanHorn <RemoveMEmicrobrixEraseMEspamEraseMEgmail.com> wrote:

> There's a pair of 1G Vmem files, and an 8G Vdisk
> file

You'll probably want to get advice from someone who
knows more about VMWare than me, there are probably
easy ways to do it. I've never used the snapshot
feature(it saves the state of the machine and ram
image), I've always just saved the virtual disk image,
and I've always used dynamic allocation, so the image
is only the size of "used" disk, and I with a win2k
machine zipped it's about 300 meg.

Cheers,

Bob

2008\02\07@195913 by David VanHorn

picon face
Well, either way, this clinches it for me.
This is about as sterile an environment as it's possible to get in a
wintel box, and studio went DFW on the first try.

2008\02\07@212844 by James Newton

face picon face
Do I understand that Studio is interfacing to a JTAG ICE module of some
sort? If so, and the problem surfaces under two different software
configurations, then I would tend to expect the problem is hardware related.

Can you setup on a different machine? Different JTAG ICE? Different USB
cable? I had a horrible problem in IAR for the MSP430 that went away when I
switched to a shorter USB cable. That fix may have had more to do with the
relative quality of the cables rather than their length, but the point is,
change things until it starts working.

--
James.

-----Original Message-----
From: RemoveMEpiclist-bouncesspam_OUTspamKILLspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspamspammit.edu] On Behalf Of
David VanHorn
Sent: Thursday, February 07, 2008 16:59
To: Microcontroller discussion list - Public.
Subject: Re: [EE] The time has come

Well, either way, this clinches it for me.
This is about as sterile an environment as it's possible to get in a
wintel box, and studio went DFW on the first try.

2008\02\07@214420 by sergio masci

flavicon
face


On Thu, 7 Feb 2008, James Newton wrote:

> Do I understand that Studio is interfacing to a JTAG ICE module of some
> sort? If so, and the problem surfaces under two different software
> configurations, then I would tend to expect the problem is hardware related.
>
> Can you setup on a different machine? Different JTAG ICE? Different USB
> cable? I had a horrible problem in IAR for the MSP430 that went away when I
> switched to a shorter USB cable. That fix may have had more to do with the
> relative quality of the cables rather than their length, but the point is,
> change things until it starts working.

Yes but David was saying that he gets the same problem without hardware
even when he is just using the simulator.

Regards
Sergio

2008\02\08@084110 by David VanHorn

picon face
On Feb 7, 2008 9:29 PM, James Newton <EraseMEjamesnewtonspamspamspamBeGonemassmind.org> wrote:
> Do I understand that Studio is interfacing to a JTAG ICE module of some
> sort? If so, and the problem surfaces under two different software
> configurations, then I would tend to expect the problem is hardware related.

Different machines, different ices, etc, over several years.

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...