> At 03:28 AM 2/14/05 -0800, Richard wrote: > >Well, perhaps it's my flawed logic, but my thinking is this - flash > >downloading is just the initial step. Eventually we want to support > >JTAG debugging. Therefore it would be much simpler if the > interface to > >all the chips (SAM, Philips, Analog Devices, OKI, TI, > ...etc.) are done > >using a single interface. Hopefully JTAG is JTAG (mostly) > and we only > >have to worry about different flash algorithm or minor variations in > >the JTAG implementations. > > I think I see what you are getting at now, the communications channel > rather than the actual programming. Since the JTAG debugging > interface is > part of the core from ARM I would expect the different > vendors to be fairly > similar. The access to the embedded ICE macrocell is identical for all ARM7s, except for initialisation and reset and clock timing: * Some devices (eg some LPCxxx) need to initialise some internal stuff before the JTAG is enabled. * Some don't support the JTAG reset. That's OK since they all support clocked TAP resetting. * The maximum JTAG speed is 1/6 the core clock speed. Therefore different cores will accept different clocks.

At 03:28 AM 2/14/05 -0800, Richard wrote: >Well, perhaps it's my flawed logic, but my thinking is this - flash >downloading is just the initial step. Eventually we want to support JTAG >debugging. Therefore it would be much simpler if the interface to all the >chips (SAM, Philips, Analog Devices, OKI, TI, ...etc.) are done using a >single interface. Hopefully JTAG is JTAG (mostly) and we only have to worry >about different flash algorithm or minor variations in the JTAG >implementations. I think I see what you are getting at now, the communications channel rather than the actual programming. Since the JTAG debugging interface is part of the core from ARM I would expect the different vendors to be fairly similar. I prefer the serial interface myself (fewer pins and usually fewer conflicts with pins I want to use) but the communication channel is different vendor to vendor. So far it appears the HW can be identical (the standard ISP header appears to work on all I've tried). Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III

ARM-JTAG debugging is standard (we support four of them - ARM7TDMI, ARM7TDMI-S, ARM9TDMI, XScale) and well documented, the flashing is family/part/board specific. Michael > Well, perhaps it's my flawed logic, but my thinking is this - flash > downloading is just the initial step. Eventually we want to support JTAG > debugging. Therefore it would be much simpler if the interface to all the > chips (SAM, Philips, Analog Devices, OKI, TI, ...etc.) are done using a > single interface. Hopefully JTAG is JTAG (mostly) and we only have to > worry > about different flash algorithm or minor variations in the JTAG > implementations. > > ...But I can be wrong. This is a new market for me, so I am learning as > much as anyone else. > > At 08:55 PM 2/13/2005, Robert Adsett wrote: > >At 05:22 PM 2/12/05 -0800, Richard wrote: > > > From a 3rd party vendor such as myself's point of > > >view, it's much easy if they publish their flash algorithms so we can > > >support all the devices the same way. > > > >I'm missing your point here Richard. How is this different in any > >meaningful way from calling whatever IAP interface they have? I > don't see > >how that is any more difficult to support and maintain than flash timing > >and algorithms. Actually I would expect it could be less since the IAP > >interface is more likely to remain constant as the internal memory timing > >change from generation to generation. I ran into that in another micro. > > // richard (This email is for mailing lists. To reach me directly, please > use richard at imagecraft.com) > * > > *>.

Well, perhaps it's my flawed logic, but my thinking is this - flash downloading is just the initial step. Eventually we want to support JTAG debugging. Therefore it would be much simpler if the interface to all the chips (SAM, Philips, Analog Devices, OKI, TI, ...etc.) are done using a single interface. Hopefully JTAG is JTAG (mostly) and we only have to worry about different flash algorithm or minor variations in the JTAG implementations. ...But I can be wrong. This is a new market for me, so I am learning as much as anyone else. At 08:55 PM 2/13/2005, Robert Adsett wrote: >At 05:22 PM 2/12/05 -0800, Richard wrote: > > From a 3rd party vendor such as myself's point of > >view, it's much easy if they publish their flash algorithms so we can > >support all the devices the same way. > >I'm missing your point here Richard. How is this different in any >meaningful way from calling whatever IAP interface they have? I don't see >how that is any more difficult to support and maintain than flash timing >and algorithms. Actually I would expect it could be less since the IAP >interface is more likely to remain constant as the internal memory timing >change from generation to generation. I ran into that in another micro. // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com)

Re: SAM7 vs TMS470 vs IP2K

At 05:22 PM 2/12/05 -0800, Richard wrote: > From a 3rd party vendor such as myself's point of >view, it's much easy if they publish their flash algorithms so we can >support all the devices the same way. I'm missing your point here Richard. How is this different in any meaningful way from calling whatever IAP interface they have? I don't see how that is any more difficult to support and maintain than flash timing and algorithms. Actually I would expect it could be less since the IAP interface is more likely to remain constant as the internal memory timing change from generation to generation. I ran into that in another micro. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III

At 05:22 PM 2/12/05 -0800, Richard wrote: >**** >Oops. I meant AFAIK, that should teach me on saving keystrokes :-).... A keystroke here, a keystroke there, pretty soon you've got yourself a novel ;) >Anyhow, the bootloader thing is great from the MCU manufacturers point of >view, because they can tell their customers, "see - you can program our >parts with zero cost!!" From a 3rd party vendor such as myself's point of >view, it's much easy if they publish their flash algorithms so we can >support all the devices the same way. A bigger advantage as a developer I found was that it meant no more socketed chips. It was one less source of problems. The field upgradeability was a nice idea but I've never used it, the last thing we wanted was for customers to be able to change the products code. Service upgrades were useful though. In the latter two cases some form of ISP is useful. Where there is a choice between serial and JTAG I usually prefer serial since it generally uses fewer pins and in my case the serial port can remain uncommitted to general operation anyway. >Our flash downloader/JTAG dongle does support the SAM7, by the way. It's >going to be priced around $175. In the ideal case, we would fold it into >our compiler IDE, but then we really wouldn't be making any money :-) It's >not a dig at competitors per se, but to mention that it is our philosophy - >we are one of the few new ARM vendors that write our own compilers. Even >Keil starts with GNU (they are now moving to their own code generator...) >Nothing wrong with GNU of course, but we like to control our own destiny... It's good to have options :). I believe there is room for both GNU and commercial compilers. I have your beta and am going to be giving it a try shortly. As far as the serial download programs go, there is source available for 2 of the three Philips utilities and one of the two AD utilities that I know of. Fairly liberal licensing on them I believe. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III

Tony Ambrosini wrote: > >Has anyone here ever come across the new ARM micros that TI came out >with (supposedly)? Does anyone know how real the TI parts are? If >they are, what makes the SAM7 better? I have been having trouble >finding comparison data. > >Also, I have heard of people using this IP2000 chip from Ubicom. It >is RISC-based like an MSP430 from TI, but has two SerDes and a >MAC+PHY. Any rumblings about Atmel adding these features in the >SAM7X family? > >Thank you! Any information would be most helpful. > For TI olimex makes the dev board but can only get it via TI. The IAR quickstart kits are available for the TMS470 The IP2000 , thats the high speed (single clock per instruction) pic clone with multiple cores ? or is that the 3000. Like the sx chips, its software not hardware for IO. Heard of a few problems with support and quantity. Appears only get the dev tools when you buy a dev kit. Alex --

I am TERRIBLY sorry. I blame it on a new puppy in the house and we are getting even less sleep than usual and my posts are darned near unreadable. Sorry about that... Let me see if I can fix it... **** Oops. I meant AFAIK, that should teach me on saving keystrokes :-).... Anyhow, the bootloader thing is great from the MCU manufacturers point of view, because they can tell their customers, "see - you can program our parts with zero cost!!" From a 3rd party vendor such as myself's point of view, it's much easy if they publish their flash algorithms so we can support all the devices the same way. Our flash downloader/JTAG dongle does support the SAM7, by the way. It's going to be priced around $175. In the ideal case, we would fold it into our compiler IDE, but then we really wouldn't be making any money :-) It's not a dig at competitors per se, but to mention that it is our philosophy - we are one of the few new ARM vendors that write our own compilers. Even Keil starts with GNU (they are now moving to their own code generator...) Nothing wrong with GNU of course, but we like to control our own destiny... At 01:58 PM 2/12/2005, Robert Adsett wrote: >At 01:43 PM 2/12/05 -0800, Richard wrote: > >GNU does not include a flash downloader, ASAP. Philips and Atmel both have > >bootloader flash download, probably other ARM MCU would have them too, if > >they are smart. > >ASAP? > >Philips and Analog Devices both have documented bootloader support and >command line programs (and GUI as well) for serial downloading. I haven't >seen any documentation for Atmel's bootloader yet only a vague reference to >it using a xmodem protocol. ST promised serial ISP support but has since >apparently abandoned it. > >That covers the small ARMs I'm aware of (ie less than 80 pins) > >Robert > >" 'Freedom' has no meaning of itself. There are always restrictions, >be they legal, genetic, or physical. If you don't believe me, try to >chew a radio signal. " > > Kelvin Throop, III > > >Yahoo! Groups Links > > // richard (This email is for mailing lists. To reach me directly, please use richard at imagecraft.com)

Sandy,

I am curious about why you do not like the GCC compiler. I have only just started fiddling around with the ARM so I have not had a chance to compare the GCC to other compilers yet. I would like to hear about some drawbacks since many people love the GCC.

A compiler question is not specific to the SAM7 and is off topic so if you do not want to respond I understand.

Trent

-----Original Message-----
From: Sandy [mailto:s...@pacbell.net]
Sent: Saturday, February 12, 2005 5:35 PM
To: A...@yahoogroups.com
Subject: [AT91SAM7] Re: SAM7 vs TMS470 vs IP2K with more long comments...

I think that was true of the AVR in early days as well, programmers
AND software were a bit scare then the are now, but hopefully the
ARM's popularity will fix that in short order. ARM SAM vs Mega 128...
no question which I want to use :-).

For comments on the Motorola stuff...er, Frescale, I love the motorola
automotive lineup, but they generally suck when it comes to getting
things out to the public (i.e., not the OEM's), I have been messing
with the 332/336 for years, but the parts are still expensive, not to
mention the cost for a MPC555x part (then fingure out how to mount the
BGA!).

I downloaded a couple of the GCC based packes (Rowley's, GNUARM, etc)
and I think 2 reason would cause me to buy software for arm devel,
that one is the Flash loader software, and the second is non-GCC
compiler. I use the Codevision for the AVR, and will look at Richards
(imagecraft's) when I get a chance. My needs are more hackish then
other's I'm guessing, so pricing entry is important and GCC in general
is not my friend except it is free! (I use it most every day at work).
Rowley's looked nice, but for me the cost may be a bit high, and I
think the ARM sanctioned maintainer of GCC has some good stuff coming
soon for optimizations, etc.

FYI - I pulled a download of Borland's C++BuilderX which is basically
a cross platform IDE (NOT A GUI DESIGN TOOL) that can host several
compilers, including GCC, Symian O/S, built in debug, etc. Free for
personal version, but you can, as it seems change the compiler from
g++/gcc to what ever you need. Nice environment, code clean/refactor,
etc. Much like ECLIPSE, both are java based and free. (Eclipse has
C/C++ plugs but not very mature as last check), but you generally get
what you pay for (plug for commercial verdors out here).

Back to the questions, does anyone have dev boards with the SAM-a3
processor? I have not been lucky in finding one as yet.

Good list so far!

Sandy
--- In A...@yahoogroups.com, MrMicro <MrMicro@g...> wrote:
> "I like the ATMEL AVR popularity and that is also a big factor in the
> SAM series for me hoping the ARM stuff gets the same reception!"
>
> I'm an AVR user hoping to add SAM7 ARM to my tool kit soon. I think the
> only thing stopping the
> SAM7 being as, or more popular than the AVR is the cost of a programmer
> (hunderds not tens of dollars).
> I've been in contact with a few AVR programmer sellers and serveral of
> them emailed me back saying they were working on some cheap ARMs
> programmers (less than $100, hopefully less than $30) and they hope to
> release these in the first half of this year.
>
> If this happens a lot of people will suddenly be able to flood into the
> ARM community and I think the SAM7 will enjoy the support and community
> as the AVR currently does.
>
> Here is hoping,
> Nigel
>
>
> Sandy wrote:
>
> >
> > Just saw the TI parts yesterday as well as their nice board with JTAG
> > ($399). I have the same question SAMA3 vs the similar TI 470 parts. I
> > am looking at what ever will be easier to get!
> >
> > I like the ATMEL AVR popularity and that is also a big factor in the
> > SAM series for me hoping the ARM stuff gets the same reception!
> >
> > BTW I am very new the the ARM stuff, and will likely use it for an
> > automotive app to replace an aged, unfinished design with the MC68336
> > part.
> >
> > Any SAM7-A3 Dev boards out yet?
> >
> > Lastly does anyone have PROTEL libs for any of the SAM parts?
> >
> > Thanks
> >
> > Sandy
> >
> >
> >
> >
> >
> > --- In A...@yahoogroups.com, "Tony Ambrosini" <tambrosini77@y...>
> > wrote:
> > >
> > >
> > > Has anyone here ever come across the new ARM micros that TI came
> > out
> > > with (supposedly)? Does anyone know how real the TI parts are? If
> > > they are, what makes the SAM7 better? I have been having trouble
> > > finding comparison data.
> > >
> > > Also, I have heard of people using this IP2000 chip from Ubicom. It
> > > is RISC-based like an MSP430 from TI, but has two SerDes and a
> > > MAC+PHY. Any rumblings about Atmel adding these features in the
> > > SAM7X family?
> > >
> > > Thank you! Any information would be most helpful.
> >
> >
> >
> >
> > *
> >
> >
> >

> > *>.
> >
> >
>
>
> >
> >

Not from an Auto company, so out of luck on the Freescale parts. The Nice thing about the ARM stuff is that it is so fast that most of the complex hardware can be removed, the TPU in the automotive parts is crazy complex, but if you can get it working, you can save many cpu cycles, but now you have much more of them 'cycles' you can do it in software as few have with the AVR processors. The SAM-A3 looks good for me! Thanks Sandy --- In , "Anton Erasmus" <antone@s...> wrote: > On 11 Feb 2005 at 19:44, Sandy wrote: > > > > > > > Just saw the TI parts yesterday as well as their nice board with JTAG > > ($399). I have the same question SAMA3 vs the similar TI 470 parts. I > > am looking at what ever will be easier to get! > > > > I like the ATMEL AVR popularity and that is also a big factor in the > > SAM series for me hoping the ARM stuff gets the same reception! > > > > BTW I am very new the the ARM stuff, and will likely use it for an > > automotive app to replace an aged, unfinished design with the MC68336 > > part. > > If you are from one of the bigger automotive companies, then you can > use the Freescale ARMs. They have similar peripherals as the older M68K > and coldfire MCUs. > > Regards > Anton Erasmus > -- > A J Erasmus