"Didi" <dp@tgi-sci.com> wrote: [Freescale PPC debug interface]>None of the newer ones (8xxx, 5xxx etc.) have separate BDM, all >has gone JTAG - which is good enough an interface, my sole issueDoes PPC JTAG support real "background" memory access, or is it like the ARM debugging where you need an interrupt routine? If the latter, that's not "good enough an interface" IMNSHO. Oliver -- Oliver Betz, Muenchen (oliverbetz.de)
Arm7 or Freescale Coldfire?
Started by ●April 3, 2006
Reply by ●April 5, 20062006-04-05
Reply by ●April 5, 20062006-04-05
Oliver Betz <OBetz@despammed.com> wrote:> Does PPC JTAG support real "background" memory access, or is it like > the ARM debugging where you need an interrupt routine?Not true anymore. Background memory access while the core is running (and infact entirely separate from the core) is supported by SOCs with an ARM CoreSight debug interface as long as the SOC is designed in the correct way. -p -- "What goes up must come down, ask any system administrator" --------------------------------------------------------------------
Reply by ●April 5, 20062006-04-05
Oliver,> Does PPC JTAG support real "background" memory access, or is it like > the ARM debugging where you need an interrupt routine?I don't know. Since the interface is secret, I am not using it, all my debug tools rely on infortmation the manufacturer is willing to provide - BTW, I am doing quite well, although it would be nice to use all the capabilities since I do use JTAG anyway for boundary scan and initial flash programming. Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Oliver Betz wrote:> "Didi" <dp@tgi-sci.com> wrote: > > [Freescale PPC debug interface] > > >None of the newer ones (8xxx, 5xxx etc.) have separate BDM, all > >has gone JTAG - which is good enough an interface, my sole issue > > Does PPC JTAG support real "background" memory access, or is it like > the ARM debugging where you need an interrupt routine? > > If the latter, that's not "good enough an interface" IMNSHO. > > Oliver > -- > Oliver Betz, Muenchen (oliverbetz.de)
Reply by ●April 5, 20062006-04-05
Paul Gotch <paulg@at-cantab-dot.net> wrote: [real "background" memory access on ARM]>Not true anymore. Background memory access while the core is running (and >infact entirely separate from the core) is supported by SOCs with an ARM >CoreSight debug interface as long as the SOC is designed in the correct way.thanks for this interesting information! Is it enough to look for "CoreSight" in the specs to see whether it's supported, or are there other names for it? Do you know which derivatives, especially smaller (cheap) ones (e.g. up to 128K Flash and 100 pins) support it? Oliver -- Oliver Betz, Muenchen (oliverbetz.de)
Reply by ●April 5, 20062006-04-05
David Brown wrote:> Roberto wrote: > >> Thank you for all the replies. >> >> Since my next designs will involve Ethernet and Can I think I will choose >> Freescale with its >> new MCF5223x (ethernet MAC+PHY, CAN, onboard 128Kb or 256Kb flash, >> 32Kb ram) >> >> Roberto >> > > I haven't heard anything about the pricing and availability of these > chips yet, but they look *very* nice.You've probably now seen http://www10.edacafe.com/nbc/articles/view_article.php?section=ICNews&articleid=258015 Funny how LOTS of devices announce around ESC time :) -jg
Reply by ●April 5, 20062006-04-05
"Didi" <dp@tgi-sci.com> wrote in message news:1144075938.870483.194470@j33g2000cwa.googlegroups.com...>> Sometimes a tool that converts >> from one assembly to another, your "virtual processor assembler", can >> make sense - but it's very rare, and only suitable in the case when you >> have very large quantities of assembly software that you must use >> without change on a new platform, and even then it is only a stop-gap >> until a real maintainable solution is found. > > It is very rare indeed, and it is quite maintainable. It is by far not > just > an assembler, it is an entire environment you live in. Times more > efficient than existing C based alternatives.In what way more efficient? I can imagine it assembles faster but it sounds unlikely that it can produce more efficient code than a good C compiler - writing assembler is a lot more tedius than C, and compilers are really good at brain damaging tasks like register allocation, parameter passing, data layout etc. There has been a lot of research into universal assemblers, and the result is often something similar to C (C-- for example, others consider C an assembly language), or a high level assembler with some macro facilities to get loops, if and switch statements, structures etc. Who does the data layout and register allocation? Do you have a description of VPA and what it looks like?>> The PPC architecture has it's strong points - being easy to understand, >> easy to use, and suitable for a small device as a step up from 8-bit are >> not among them. >> .... > > Having written many megabytes of sources for both CPU32 and PPC, > I can say that PPC is beyond reach for competing architectures > nowadays.PPC has some pretty good implementations as they were targeting desktops, and they are indeed high-end (and as a result high-power). However there is no reason to believe other architectures can't produce high-end implementations with similar performance. Many embedded architectures already have fast superscalar implementations or are working on them (eg MIPS, ARM, SH). It is now possible to do 1GHz with less than 1 Watt, so you'll see more high-end implementations. Wilco
Reply by ●April 5, 20062006-04-05
> Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > introduced on the 68010, is.I don't remember (perhaps I never knew) what it was on the 010, but I do remember the loop mode on the CPU32 - it is when you use the dbcc instruction with an offset of $fffc (-4), so the loop repeats a single single-word opcode. The CPU stops fetching, does just the data accesses (CPU32 has no cache memory). I have used it here and there, I remember using it in an LZW compress (the inner-most search loop); while it yielded a noticeable improvement, the same code ran times more efficiently on the PPC - just sligthly modified to take advantage of the ctr register. Was loop mode the same on the 010? Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Dave wrote:> On Wed, 05 Apr 2006 13:54:38 +0100, David Brown wrote: > > > The CPU32 also has a couple of additions compared to the 68020, such as > > a fast loop mode > > Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > introduced on the 68010, is. > > > ~Dave~
Reply by ●April 5, 20062006-04-05
Didi wrote:> > Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > > introduced on the 68010, is. > > I don't remember (perhaps I never knew) what it was on the 010, but I > do remember the loop mode on the CPU32 - it is when you use > the dbcc instruction with an offset of $fffc (-4), so the loop repeats > a single single-word opcode. The CPU stops fetching, does just > the data accesses (CPU32 has no cache memory). > I have used it here and there, I remember using it in an LZW compress > (the inner-most search loop); while it yielded a noticeable > improvement, the same code ran times more efficiently on the > PPC - just sligthly modified to take advantage of the ctr register. > > Was loop mode the same on the 010? > > Dimiter > > ------------------------------------------------------ > Dimiter Popoff Transgalactic Instruments > > http://www.tgi-sci.com > ------------------------------------------------------ > > > >Yup the 68010 operates in a similar manner. It looks like the CPU stops fetching the opcodes but continues to test for the loop termination condition. Well this is what I got from Motorola's docs (they print 'em and send em to you for free if you didnt know already). -Isaac
Reply by ●April 5, 20062006-04-05
On Wed, 05 Apr 2006 13:54:38 +0100, David Brown wrote:> The CPU32 also has a couple of additions compared to the 68020, such as > a fast loop modeOkay, I'll bite. What is "fast loop mode"? I know what loop mode, introduced on the 68010, is. ~Dave~
Reply by ●April 5, 20062006-04-05
> Yup the 68010 operates in a similar manner. It looks like the CPU stops > fetching the opcodes but continues to test for the loop termination > condition.Thanks, apparently same thing.> Well this is what I got from Motorola's docs (they print 'em > and send em to you for free if you didnt know already).Hey, I knew that :-). But last time I considered the 68010 was during the 80-s... Whatever literature I have needed from Motorola I have received it - except for things they want to keep secret (like the JTAG based debug port data, they did not give them to me while I had an active NDA, it is for much narrower circles...). Dimiter ------------------------------------------------------ Dimiter Popoff Transgalactic Instruments http://www.tgi-sci.com ------------------------------------------------------ Isaac Bosompem wrote:> Didi wrote: > > > Okay, I'll bite. What is "fast loop mode"? I know what loop mode, > > > introduced on the 68010, is. > > > > I don't remember (perhaps I never knew) what it was on the 010, but I > > do remember the loop mode on the CPU32 - it is when you use > > the dbcc instruction with an offset of $fffc (-4), so the loop repeats > > a single single-word opcode. The CPU stops fetching, does just > > the data accesses (CPU32 has no cache memory). > > I have used it here and there, I remember using it in an LZW compress > > (the inner-most search loop); while it yielded a noticeable > > improvement, the same code ran times more efficiently on the > > PPC - just sligthly modified to take advantage of the ctr register. > > > > Was loop mode the same on the 010? > > > > Dimiter > > > > ------------------------------------------------------ > > Dimiter Popoff Transgalactic Instruments > > > > http://www.tgi-sci.com > > ------------------------------------------------------ > > > > > > > > > > Yup the 68010 operates in a similar manner. It looks like the CPU stops > fetching the opcodes but continues to test for the loop termination > condition. Well this is what I got from Motorola's docs (they print 'em > and send em to you for free if you didnt know already). > > -Isaac
