Atmel AVR development tools

crazy,

different locations?

they haven't re-routed the Muncie power grid past your door step recently, have they Dave?

Don...

-- Don McKenzie

Affiliate Program:

Parallax Propeller Powered .96" OLED module

Build your own! Since my Jtag Ice's funnel, I have been programming AVRs with an ARM eval board (programmed as AVR programmer). It's much more reliable than the Atmel tools. Recently, I am starting to program AVRs with another pre-programmed AVR. Once programmed, AVR are very stable.

Dump these as well. I have all the tools avr-gcc and uprog (my USB programmer) on a 1G CF drive.

ISTM, that you would get a better concentration of microcontroller-specific knowledge at comp.arch.embedded.

Goes doubly for

I too have very occasionally seen the code display in AVR studio show silly things for the LDI instruction, usually LDI &h00 when it should be a non-zero. Also seen LDS &h0000 when it should be a valid RAM address. But the code seems to execute ok in a target system. Never tried it in the simulator. Use both JTAG ICE MkII and a USB version of the MkI. Suspect its actually a problem in AVR Studio itself, not in hardware.

As you say, its not consistent, but I never saw it often enough to cause a serious problem. My 'fix' is to go on and develop some more code, then when I come back to the debugger, the problem has gone away. Some fix !

System here is Windoze 2000 SP 2 and AVR Studio 4.12 SP 4.

Southern Georgia, Vancouver, Pittsburgh, Muncie, Indianapolis, Philadelphia and Baltimore come to mind.

Nope.

Unfortunately, S+N/N

Me too, and I suspect they aren't putting much heat on it because it's a "free" tool, nevermind how essential it might be to getting things done.

Right, this is the sort of thing that I have going on.

Nice and fast core but poor set of the peripherals.

The biggest problem is that Atmel keeps dropping and changing the AVR lines. That makes the AVR unsuitable for the long term projects.

Why do you need that?

The only tools I ever used for AVR are the scope, the byteblaster and the debug printout to RS-232. I developed the projects of up to about

Apparently the problem is with you.

You have to stop playing games with the fancy toys and content yourself with the essential. The entities should not be multiplied beyond the necessity.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Funeral?

I've used other "clone" Jtag ices, with the same reliability problems.

One of these days, I may have to start using C, but I've been avoiding it. It seems to add yet another layer (or two) of possible problems, as well as sucking up system resources and cycles. And it wouldn't remove me from the need to run in sim or emulation.

I hear ya. I have in the past, done "crash and burn" with only single pin output of many bytes of data. It's error-prone and tedious, but it does work. The additional code to output the debugging data takes time and space too though, and I don't always have that spare.

:) Yeah. I'm leaning twoard Studio using some memory somewhere that's not initialized. That's sure what it feels like.

This would be the second time I've heard someone tell me to just ditch the Atmel toolchain entirely. Maybe I'm just stuck because it USED TO WORK. It worked flawlessly. I delivered apps one after the other, and NEVER had to worry wether a tool would work. The sim was great, and very useful. Their ICE-200 was wonderful. The ICE-50 was great, up till the first official release, then it went to hell.

Oh, yes. My poor spellings.

The AVR debug core is unreliable, jtag or non-jtag. SPI programming is much more reliable. Also, avoid bootloaders.

I know I am not a normal user, but learned to live with the essentials only, as another poster suggested.

I used the Jtag Ice long enough to develop a set of usable library, mostly serial port and LED/LCD drivers. After that, I have not use any simulator/emulator at all. But I am only doing a simple project of 2000 lines / 8K at most. We will be building thousands of them, so a simple compiler and isp loader is more important than fancy simulator.

Just had the same problem, I downloaded the latest GCC/studio4 stuff, but the thinkulator would not run :

"AVR Simulator: Invalid opcode 0xffff at address 0x00f000"

on a "helloworld.c", but simpler

While(1) { counter++; }

It worked on a 1 year old "not updated" setup on my laptop.

MSP430 anyone?

martin

However better than PICs. What other 8-bit uC do you have in mind?

Marco / iw2nzm

simple solution, get a computer with a real RS-232 port on it, and use that option, using RS-232 converters or direct USB I find is unreliable not just for that process but for other things that really need the attention of the PC also. I Also find that when I used older versions of windows I have much better luck .. 98/W2k is what I normally use for programming the units.

The 16-bit timer of AVR is handy. I wish there could be 3 or 4 timers like that.

I am not familiar with the latest AVRs and PICs. PIC peripheral offering used to be far superior to that of AVRs, and I guess it still is.

The HC12 family.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Not exactly 8 bits, but who care. What about the coldfire MCF51QE128? Price is within our budget, for 2 pennies each. Perhaps with another 49 pennies for silicons.

It is marketed as 16-bitter however it looks no different from the old good 68xx. In HC12 there is even no penalty for the misalignment.

Good one. Thank you for the tip.

Well definitely not worse then the big Mega AVRs.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

The Atmel ATMega168 is used in all the Arduino based platforms. I use Processing as the IDE.

"dbvanhorn" skrev i en meddelelse news: snipped-for-privacy@f47g2000hsd.googlegroups.com...

The way of all software. It gets "improved" until it sucks so much that nobody will use it. Then Symantek buys it and sell it under another label for another round of grief ;.)