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-----
|
SAM7 vs TMS470 vs IP2K
Started by ●February 10, 2005
Reply by ●February 12, 20052005-02-12
Reply by ●February 12, 20052005-02-12
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) |
Reply by ●February 13, 20052005-02-13
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 -- |
Reply by ●February 13, 20052005-02-13
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 |
Reply by ●February 14, 20052005-02-14
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 |
Reply by ●February 14, 20052005-02-14
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) |
|
Reply by ●February 14, 20052005-02-14
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) > * > > *>. |
Reply by ●February 14, 20052005-02-14
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 |
Reply by ●February 14, 20052005-02-14
> 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. |