| Author |
Message |
|
|
 Posted: Feb 28, 2012 - 03:20 PM |
|
Joined: Jan 26, 2004
Posts: 119
Location: Hjallerup, Denmark
|
|
@js
Another reason to buy the AVR ONE over let's say JTAG ICEMK2 or ICE3, is the automatic detection of daisy chain coupled devices.
Further more the ONE has daisy chain debug support, where as the ICE MK2 only debugs the first device (bug), and it is much faster to debug.
For my purpose I would buy an AVR ONE if I didn't have one. While AVR Studio 5.1 - 6 - x is still missing some vital issues on jtag daisy chain the ICE3 is not supported by AVR Studio 4. That leaves one with the choice of either AVR ONE or JTAG ICE MK2. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 28, 2012 - 08:22 PM |
|
Joined: Mar 28, 2001
Posts: 20387
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
Quote:
Another reason to buy the AVR ONE over let's say JTAG ICEMK2
I already have a JTAG Mk2
Quote:
ICE3
Only works with Studio 5 which I don't have\don't want at the moment. 
Quote:
detection of daisy chain coupled devices.
Never used in 12 years, not likely to use in the next 12. (hmm I'd be happy enough to even work with a PIC in 12 years time  ) |
_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
|
Posted: Feb 29, 2012 - 06:41 AM |
|
Joined: Mar 27, 2002
Posts: 18575
Location: Lund, Sweden
|
|
| Do I get it right if I say that the AVR ONE only supports AVRs (and not e.g. Atmels Cortex-M series)? Kinda suggested by the name, but just want to be sure.. |
|
|
| |
|
|
|
|
|
|
Posted: Feb 29, 2012 - 07:15 AM |
|
Joined: Jan 23, 2004
Posts: 9830
Location: Trondheim, Norway
|
|
|
Quote:
Do I get it right if I say that the AVR ONE only supports AVRs (and not e.g. Atmels Cortex-M series)? Kinda suggested by the name, but just want to be sure..
Yes, although the hardware shouldn't limit that AFAIK as it's just a great big honking FPGA connected to a USB interface.
Incidentally, I've got some "insider information" regarding this:
Quote:
We are performing a live test of the discount functionality of the web-store. From what we can tell, it’s working perfectly well.
The discount also applies to the EVK1100 and EVK1101. I can see nobody discovered that yet.
So no big conspiracy after all.
- Dean  |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: Feb 29, 2012 - 09:25 AM |
|
Joined: Mar 27, 2002
Posts: 18575
Location: Lund, Sweden
|
|
OK, that was very informative Dean.
(Pity the AVR ONE isnt an "Atmel ONE" then. That could have taken my Cortex-M3 excursions down Atmel Alley if I could get one programmer/OCD dongle for both them and AVRs. As it stands now I'll manage with my Dragons and go for other M3's, with low-cost programmer/OCD.) |
|
|
| |
|
|
|
|
|
|
Posted: Feb 29, 2012 - 09:36 AM |
|
Joined: Jul 18, 2005
Posts: 62337
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I can see nobody discovered that yet.
Dunno about anyone else but I noticed that but thought it was of little / no interest to anyone using AVR8s. |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 01, 2012 - 07:21 AM |
|
Joined: Jan 23, 2004
Posts: 9830
Location: Trondheim, Norway
|
|
I have just been told the following verbatim on this:
Quote:
Yes, you can confirm that we are working on adding SAM3 and SAM4 support to the debuggers, but the the current discount has nothing to do with that upgrade with is still months away.
So while not immediate, it looks like the "AVR ONE!" might just become the "Atmel ONE!" after all. You heard it here first people!
- Dean |
_________________
Atmel Studio 6.1 is now released, grab it here.
Report AS6/ASF bugs here.
|
| |
|
|
|
|
|
|
Posted: Mar 01, 2012 - 07:51 AM |
|
Joined: Mar 27, 2002
Posts: 18575
Location: Lund, Sweden
|
|
|
Quote:
we are working on adding SAM3 and SAM4
Quite interesting, and thank you for digging this out Dean! |
|
|
| |
|
|
|
|
|
|
Posted: Mar 02, 2012 - 08:40 PM |
|
Joined: Oct 05, 2006
Posts: 2250
Location: Poland
|
|
|
Quote:
Yes, you can confirm that we are working on adding SAM3 and SAM4 support to the debuggers
Atmel ONE is a tracing dongle, but do SAM3 and SAM4 have any tracing interface? AFAIK only SAM9 includes those features so I guess Atmel is thinking about adding a debugging and/or programming support, but not tracing.
Both programming and debugging are well supported on nonAtmel's - cheaper and faster dongles. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 02, 2012 - 10:11 PM |
|
Joined: Jul 18, 2005
Posts: 62337
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
but do SAM3 and SAM4 have any tracing interface?
I just picked a datasheet for a 16K SAM3N which seems to reflect the complete SAM3 range:
Quote:
11.1 Description
The SAM3 Series Microcontrollers feature a number of complementary debug and test capabilities. The Serial Wire/JTAG Debug Port (SWJ-DP) combining a Serial Wire Debug Port (SW-DP) and JTAG Debug(JTAG-DP) port is used for standard debugging functions, such as downloading code and single-stepping through programs. It also embeds a serial wire trace.
11.2 Embedded Characteristics
• Debug access to all memory and registers in the system, including Cortex-M3 register bank when the core is running, halted, or held in reset.
• Serial Wire Debug Port (SW-DP) and Serial Wire JTAG Debug Port (SWJ-DP) debug access
• Flash Patch and Breakpoint (FPB) unit for implementing breakpoints and code patches
• Data Watchpoint and Trace (DWT) unit for implementing watchpoints, data tracing, and system profiling
• Instrumentation Trace Macrocell (ITM) for support of printf style debugging
• IEEE1149.1 JTAG Boundary-can on All Digital Pins
The "printf style" debugging sounds nice  |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 02, 2012 - 10:45 PM |
|
Joined: Oct 05, 2006
Posts: 2250
Location: Poland
|
|
|
clawson wrote:
The "printf style" debugging sounds nice
I had visited Lauterbach stand on Embedded World yesterday. You would not consider a printf style debugging "nice" when compared to a tracing capabilities of the dongles they sell..
I would say the relationship between tracing vs debugging capabilities/usefulness is very close to the relationship between debugging vs programming.
printf style debugging == no fun. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 02, 2012 - 11:34 PM |
|
Joined: Jun 21, 2005
Posts: 882
Location: Chicago area, USA
|
|
|
Quote:
tracing capabilities of the dongles
Pardon my ignorance - but what do they trace and why would I want one? (Yes, I know about lmgtfy.com, but why google if there is avrfreaks?) I am a printf guy. Well, may not printf per se exactly, but debugging-over-uart-kind-of guy, with my own little debugging layer allowing me to access any variable and watch them as they change. I rarely use my JTAGICE mkII or Dragon. Pretty much the only time that I might use them if there is no way to do a printf (no hardware UART, no extra pins to do softuart, no flash left for any print - it has been long time since I had a project like that). So, do I really need a tracing dongle, whatever that is? |
|
|
| |
|
|
|
|
|
|
Posted: Mar 03, 2012 - 01:46 AM |
|
Joined: Mar 28, 2001
Posts: 20387
Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweiss)
|
|
|
Quote:
tracing dongle, whatever that is?
The last time I used a tracing debugger was about 25+ years ago and it costed about the same as the average house. 
It was was for the NSC800, C/W 2 x 52Kbytes 8" disks, one for the O/S and one for the debugger.
It basically records the last number of instructions executed according to buffer size, maybe 256, 512 or more, so you know where the processor has been when a crash happens. |
_________________
John Samperi
Ampertronics Pty. Ltd.
www.ampertronics.com.au
* Electronic Design * Custom Products * Contract Assembly
|
| |
|
|
|
|
|
|
Posted: Mar 03, 2012 - 07:17 AM |
|
Joined: Jan 09, 2007
Posts: 1875
Location: Arlington, Texas, U.S.A.
|
|
|
ezharkov wrote:
... but what do they trace and why would I want one?
ARM: CoreSight (on-chip debug and trace)
AVR32 UC3: AVR32UC Technical Reference Manual, go to 9.1.2.6 Program and Data Trace on page 89.
MIPS: PDTrace.
Can be used to search for hardware bugs like this:
What’s the state of your Cortex? by Miro Samek.
Race condition diagnosis; a user says it happens "When I look cross-ways at it"
Went on one bug hunt that depended on when a hardware signal was generated w.r.t. the program counter's value.
ezharkov wrote:
So, do I really need a tracing dongle, whatever that is?
These are rarely used but are sometimes essential. Worked for one company that would rent the expensive tools from a test equipment rental company. |
|
|
| |
|
|
|
|
|
|
Posted: Mar 03, 2012 - 10:19 AM |
|
Joined: Jul 18, 2005
Posts: 62337
Location: (using avr-gcc in) Finchingfield, Essex, England
|
|
|
Quote:
I had visited Lauterbach stand on Embedded World yesterday. You would not consider a printf style debugging "nice" when compared to a tracing capabilities of the dongles they sell..
Oh yes I love Lauterbach. We exchanged a number of our ARM Multi-ICE in favour of using Lauterbach because of the extra facilities they offer. They also have "Linux awareness" in the debugger which is nice for any kind of Linux work.
Quote:
So, do I really need a tracing dongle, whatever that is?
It's like all "tools" it's down to preference. A lot of people (I'm one) think a logic analyser is invaluable when working in programmable digital electronics - others just wouldn't see the point. Another example: when I've worked on USB we've hired a USB protocol analyser. One could have done things like this the "hard way" but having the right tool for the job is "nice".
So a debugger with a trace unit not only allows the usual JTAG like behaviour of breakpoints, single-stepping, register/memory inspection and so on but you get a buffer that shows all the recent opcodes that got you to where you are now. If you have a common routine called from 100 different places that is causing grief on one particular invocation then rather than peperring the code with printf()s saying "calling foo from func1", "calling foo from func2" and so on to try and trace which one is calling it in error. You just set up the break condition then look at the trace to see where the call came from.
Actually even this is not a great example because any decent debugger (but not Atmel/AVR debuggers) will always offer a stack backtrace anyway so you can see the sequence of CALLs that got you into the routine where the error occurs. But a trace unit would show you even if the code JMPd there. One fairly common use of JMP is in interrupt vector tables.
So say you have 50 unused vectors all mapping to a bad_interrupt() routine and you know one of them is firing in error but not which one? You could write 50 different ISR()s, one for each vector to catch which one was getting you there. Or you could use a code trace to see how you got to bad_interrupt.
I think, like so many tools, it's one of those things you just have to use a bit to see the real benefit of.
BTW the printf thing I mentioned previously (as seen in LPCXpresso by the way) simply means that printf()s in the code route over the sme JTAG-like wire/interface back to the PC and are shown in the debugger. So you don't need to configure UA, use it's pins, find a USB-RS232, tie up another USB on your PC and run some additional terminal software. The whole thing just happens in the debugger for "no cost". In the code (certainly in the Xpresso case) you really can write:
Code:
int main(void) {
printf("hello world");
}
and when you debug this "hello world" appears in one of the windows of the debugger.
Personally I still claim this is "fun".
(BTW a lot of the more advanced s/w engineering tools (like trace) only really come into their own when debugging very complex software systems: MB of code, 1,000's of source files, 100's of threads and so on - on something as simple as an AVR they could well be considered over-kill). |
_________________
|
| |
|
|
|
|
|
|
Posted: Mar 03, 2012 - 10:28 AM |
|
Joined: Oct 05, 2006
Posts: 2250
Location: Poland
|
|
|
ezharkov wrote:
I rarely use my JTAGICE mkII or Dragon.
Well, my experience here tells me that most people do not even understand the difference between a programming dongle and debugging dongle. And thus I would not expect the freaks to understand the difference between a tracing dongle and a debugging or programming dongle. Especially in the context of this 8-bit forum.
AVR ONE is a tool which has many purposes:
You can for example use it as a nice stand for a cup of coffee,
or as Dean stated:
abcminiuser wrote:
You can use it to bludgeon pidgeons to death if you get hungry.
I suppose you could even make other stupid things with it, for example pay (then) 599$ and do only ISP programming with it.
This swiss-army-knife is a 200MHz tracing dongle (which also supports debugging and programming of course).
Why would you need a tracing dongle? First of all if you do not need a debugging dongle, then I am sure a tracing dongle is of no use in your job. Second thing is that some chips do not support tracing and some do not even support debugging.
Quote:
what do they trace and why would I want one?
These trace (log) selected states of the core. Not necessarily the program flow, but also data busses/threads/cores etc. |
_________________
No RSTDISBL, no fun!
|
| |
|
|
|
|
|
|
Posted: Mar 03, 2012 - 10:34 AM |
|
Joined: Oct 05, 2006
Posts: 2250
Location: Poland
|
|
|
|
|
|
|
|
Posted: Mar 03, 2012 - 03:53 PM |
|
Joined: Jan 09, 2007
Posts: 1875
Location: Arlington, Texas, U.S.A.
|
|
|
clawson wrote:
BTW a lot of the more advanced s/w engineering tools (like trace) only really come into their own when debugging very complex software systems: ...
Worked on one dual 8-bit system (tightly coupled) where tracing was very handy. Also, it can be used on systems of one MPU/MCU communicating with complex programmable logic (ASIC, FPGA, etc.). |
|
|
| |
|
|
|
|
|
|
Posted: Mar 03, 2012 - 04:43 PM |
|
Joined: Jun 21, 2005
Posts: 882
Location: Chicago area, USA
|
|
|
gchapman wrote:
Worked on one dual 8-bit system (tightly coupled) where tracing was very handy.
Would not something like a logic analyzer be as handy in this case? |
|
|
| |
|
|
|
|
|
|
Posted: Mar 03, 2012 - 05:15 PM |
|
Joined: Jan 09, 2007
Posts: 1875
Location: Arlington, Texas, U.S.A.
|
|
Yes in that case because the programs were stored in and fetched from external memories and some older logic analyzers had machine code instruction decoders.
But that system had custom tracers. |
|
|
| |
|
|
|
|
|
FAQ
Search
Register
Log in to check your private messages
Log in
Maximize
RSS
