Hello,
I am developing a project that may push the limits of SRAM in the
larger AVRs family (ATmega1281). After comparing prices and a quick
browse over datasheets, the AT91SAM7S128 is looking like a better option
(SPI over DMA could be useful). I am very familiar in developing with
the AVR using WinAVR tool chain, and flash programming with a simple
printer port cable. However I have no experience with the ARM7
architecture or WinARM. My question is what sort of learning curve is
involved migrating from AVR to AT91SAM7S ? I'm assuming I can be
totally ignorant about most peripherals I don't use, eg. USB, SSC.
I'm trying to decide if I'm better off sticking with the AVR and
reduce
my development time with something I already know. There is a slight
chance the AT91 might prove useful in future projects.
Adam
moving from AVR to AT91
Started by ●April 3, 2007
Reply by ●April 4, 20072007-04-04
On Wednesday 04 April 2007 12:42, Adam Seychell wrote:
> Charles Manning wrote:
> > On Wednesday 04 April 2007 09:59, Adam Seychell wrote:
> > > Hello,
> > > I am developing a project that may push the limits of SRAM in the
> > > larger AVRs family (ATmega1281). After comparing prices and a quick
> > > browse over datasheets, the AT91SAM7S128 is looking like a better
> > > option (SPI over DMA could be useful). I am very familiar in
> > > developing with the AVR using WinAVR tool chain, and flash programming
> > > with a simple printer port cable. However I have no experience with
> > > the ARM7 architecture or WinARM. My question is what sort of learning
> > > curve is involved migrating from AVR to AT91SAM7S ? I'm assuming I can
> > > be totally ignorant about most peripherals I don't use, eg. USB, SSC.
> > >
> > > I'm trying to decide if I'm better off sticking with the AVR and
> > > reduce my development time with something I already know. There is a
> > > slight chance the AT91 might prove useful in future projects.
> >
> > This is not so much a move from AVR to AT91 as a move from AVR to ARM.
> > That the AT91 come from Atmel does not simplify anything.
> >
> > I have worked with numerous micros, including AVR and many different ARM
> > variants over 20-odd years of embedded development. Moving to ARM is
> > challenging if you want to deep end on how everything works.
> >
> > The biggests benefit of becoming ARM savvy is that ARM is used by many
> > different companies in devices small to large (a few kb to multi-mb)
> > costing
> > from less than $2 upwards.
> >
> > One toolchain + Jtag debugger sets you up for all these variants.
> >
> > If you just view learning about ARM as a cost for this project then it
> > might
> > be hard to justify. If you rather see it as a career investment to be
> > amortised over many years, then it is definitely worth moving.
> >
> > -- Charles
>
> Thanks Charles for the advice. My reasons for considering ARM are not
> purely on cost, but also the extra memory, and DMA for high speed SPI it
> offers could benefit in this project. Then on the other hand, I don't
> plan perusing a career involving ARM embedded systems. I fear its
> inevitable to acquire a comprehensive understanding of the ARM7
> architecture before it can be use in any embedded system. From you
> reply, it seems I'm better off staying with the AVR.
Unless you are planning on retiring from embedded development pretty soon, I
would suggest that it is a wise thing to consider ARM because almost every
CPU manufacturer is pushing out ARM chips. Soon, not having ARM will be
almost as career limiting as not knowing C.
If you don't want to deep-end on the more complex parts of ARM, you can
actually get going reasonably quickly. There are numberous projects kicking
around that serve as a start-off point. For example, if you want to write
your own interrupt handling etc from scratch that is pretty difficult to do.
If instead you just pick up what an existing project uses, that's a lot
easier.
-- CHarles
> Charles Manning wrote:
> > On Wednesday 04 April 2007 09:59, Adam Seychell wrote:
> > > Hello,
> > > I am developing a project that may push the limits of SRAM in the
> > > larger AVRs family (ATmega1281). After comparing prices and a quick
> > > browse over datasheets, the AT91SAM7S128 is looking like a better
> > > option (SPI over DMA could be useful). I am very familiar in
> > > developing with the AVR using WinAVR tool chain, and flash programming
> > > with a simple printer port cable. However I have no experience with
> > > the ARM7 architecture or WinARM. My question is what sort of learning
> > > curve is involved migrating from AVR to AT91SAM7S ? I'm assuming I can
> > > be totally ignorant about most peripherals I don't use, eg. USB, SSC.
> > >
> > > I'm trying to decide if I'm better off sticking with the AVR and
> > > reduce my development time with something I already know. There is a
> > > slight chance the AT91 might prove useful in future projects.
> >
> > This is not so much a move from AVR to AT91 as a move from AVR to ARM.
> > That the AT91 come from Atmel does not simplify anything.
> >
> > I have worked with numerous micros, including AVR and many different ARM
> > variants over 20-odd years of embedded development. Moving to ARM is
> > challenging if you want to deep end on how everything works.
> >
> > The biggests benefit of becoming ARM savvy is that ARM is used by many
> > different companies in devices small to large (a few kb to multi-mb)
> > costing
> > from less than $2 upwards.
> >
> > One toolchain + Jtag debugger sets you up for all these variants.
> >
> > If you just view learning about ARM as a cost for this project then it
> > might
> > be hard to justify. If you rather see it as a career investment to be
> > amortised over many years, then it is definitely worth moving.
> >
> > -- Charles
>
> Thanks Charles for the advice. My reasons for considering ARM are not
> purely on cost, but also the extra memory, and DMA for high speed SPI it
> offers could benefit in this project. Then on the other hand, I don't
> plan perusing a career involving ARM embedded systems. I fear its
> inevitable to acquire a comprehensive understanding of the ARM7
> architecture before it can be use in any embedded system. From you
> reply, it seems I'm better off staying with the AVR.
Unless you are planning on retiring from embedded development pretty soon, I
would suggest that it is a wise thing to consider ARM because almost every
CPU manufacturer is pushing out ARM chips. Soon, not having ARM will be
almost as career limiting as not knowing C.
If you don't want to deep-end on the more complex parts of ARM, you can
actually get going reasonably quickly. There are numberous projects kicking
around that serve as a start-off point. For example, if you want to write
your own interrupt handling etc from scratch that is pretty difficult to do.
If instead you just pick up what an existing project uses, that's a lot
easier.
-- CHarles
Reply by ●April 6, 20072007-04-06
On Friday 06 April 2007 02:53, miro_atc wrote:
> Let me add few cents.
>
> It's a good thing to be familiar with AVR, some peripherals share the
> same concept. At least you already know how to read a datasheet from
> Atmel.
>
> About the ARM core - I think you should learn it. It is not that
> difficult if you have the right book. If you start with the ARM7TDMI
> technical reference you will get quite confused I guess.
> I can recommend you to start with "ARM Architecture Reference
> Manual", it was available as DDI0100E_ARM_ARM.pdf
This book is good, but IMHO the best book is ARM System's Developer's Guide by
Sloss et al (available at Amazon etc). They are in many ways complementary so
having both is good.
>
> Some say that you don't have to learn the core - true, but for
> application software guy ;-)
> The arm core requires some assembly code, you can't get away with a C-
> stuff only. Of course you can get some 3'rd party code, but if you
> don't know what you are using and how it is working you will get in
> trouble soon or later.
I've recently been looking at stuff to help a friend get going. Boy it's a
**lot** easier today than in the old days (5 years back) ans I sincerely
apologize if my earlier posts were frightening.
For example you can go to Amontec. Buy a JYAGkey-Tiny for EURO29 + shipping
and download the sdk4arm and Jim Lynch's tutorial and accompanying samples.
Or you could even download the tools and use them with a "Wiggler clone"
which you could make for $5.
If you're not doing anything too funky (eg. nested interrupts), you can tool
along in C with pretty much zero assembler (some start up needed, but not
much), doing all your debugging in Eclipse which is pretty warm and fuzzy.
If you start wanting to make the CPU to more funky stuff (eg. writing nested
interrupts or schedulers etc), you'll then need to find code you can use as a
black box or get in deeper.
--Charles
> Let me add few cents.
>
> It's a good thing to be familiar with AVR, some peripherals share the
> same concept. At least you already know how to read a datasheet from
> Atmel.
>
> About the ARM core - I think you should learn it. It is not that
> difficult if you have the right book. If you start with the ARM7TDMI
> technical reference you will get quite confused I guess.
> I can recommend you to start with "ARM Architecture Reference
> Manual", it was available as DDI0100E_ARM_ARM.pdf
This book is good, but IMHO the best book is ARM System's Developer's Guide by
Sloss et al (available at Amazon etc). They are in many ways complementary so
having both is good.
>
> Some say that you don't have to learn the core - true, but for
> application software guy ;-)
> The arm core requires some assembly code, you can't get away with a C-
> stuff only. Of course you can get some 3'rd party code, but if you
> don't know what you are using and how it is working you will get in
> trouble soon or later.
I've recently been looking at stuff to help a friend get going. Boy it's a
**lot** easier today than in the old days (5 years back) ans I sincerely
apologize if my earlier posts were frightening.
For example you can go to Amontec. Buy a JYAGkey-Tiny for EURO29 + shipping
and download the sdk4arm and Jim Lynch's tutorial and accompanying samples.
Or you could even download the tools and use them with a "Wiggler clone"
which you could make for $5.
If you're not doing anything too funky (eg. nested interrupts), you can tool
along in C with pretty much zero assembler (some start up needed, but not
much), doing all your debugging in Eclipse which is pretty warm and fuzzy.
If you start wanting to make the CPU to more funky stuff (eg. writing nested
interrupts or schedulers etc), you'll then need to find code you can use as a
black box or get in deeper.
--Charles
Reply by ●April 6, 20072007-04-06
Charles Manning wrote:
>
> This book is good, but IMHO the best book is ARM System's Developer's
> Guide by
> Sloss et al (available at Amazon etc). They are in many ways
> complementary so
> having both is good.
> >
> > Some say that you don't have to learn the core - true, but for
> > application software guy ;-)
> > The arm core requires some assembly code, you can't get away with a C-
> > stuff only. Of course you can get some 3'rd party code, but if you
> > don't know what you are using and how it is working you will get in
> > trouble soon or later.
>
> I've recently been looking at stuff to help a friend get going. Boy it's a
> **lot** easier today than in the old days (5 years back) ans I sincerely
> apologize if my earlier posts were frightening.
>
> For example you can go to Amontec. Buy a JYAGkey-Tiny for EURO29 + shipping
> and download the sdk4arm and Jim Lynch's tutorial and accompanying samples.
> Or you could even download the tools and use them with a "Wiggler clone"
> which you could make for $5.
>
> If you're not doing anything too funky (eg. nested interrupts), you can
> tool
> along in C with pretty much zero assembler (some start up needed, but not
> much), doing all your debugging in Eclipse which is pretty warm and fuzzy.
>
> If you start wanting to make the CPU to more funky stuff (eg. writing
> nested
> interrupts or schedulers etc), you'll then need to find code you can use
> as a
> black box or get in deeper.
>
> --Charles
Thanks, Everyone has been a great help. I download and had a quick brows
over the "ARM ARM" pdf. This manual looked easier reading than the ARM
Technical Reference which I originally looked at and scared me off a
little.
There is an abundance of information and support available for the ARM
so it looks like a good thing to get into. From my experience with AVRs
I know the ARM core will eventually need to be understood as projects
evolve. Even using the ARM to blink a LED requires reasonable knowledge
of its architecture, and learning to use development tools, debuggers,
and necessary libraries, plus chip programming hardware.
A blinking LED in embedded system is equivalent to the "Hello World"
program running on a higher level system. If I get that happening, than
the ARM thereafter might not be so scary to learn.
Adam
>
> This book is good, but IMHO the best book is ARM System's Developer's
> Guide by
> Sloss et al (available at Amazon etc). They are in many ways
> complementary so
> having both is good.
> >
> > Some say that you don't have to learn the core - true, but for
> > application software guy ;-)
> > The arm core requires some assembly code, you can't get away with a C-
> > stuff only. Of course you can get some 3'rd party code, but if you
> > don't know what you are using and how it is working you will get in
> > trouble soon or later.
>
> I've recently been looking at stuff to help a friend get going. Boy it's a
> **lot** easier today than in the old days (5 years back) ans I sincerely
> apologize if my earlier posts were frightening.
>
> For example you can go to Amontec. Buy a JYAGkey-Tiny for EURO29 + shipping
> and download the sdk4arm and Jim Lynch's tutorial and accompanying samples.
> Or you could even download the tools and use them with a "Wiggler clone"
> which you could make for $5.
>
> If you're not doing anything too funky (eg. nested interrupts), you can
> tool
> along in C with pretty much zero assembler (some start up needed, but not
> much), doing all your debugging in Eclipse which is pretty warm and fuzzy.
>
> If you start wanting to make the CPU to more funky stuff (eg. writing
> nested
> interrupts or schedulers etc), you'll then need to find code you can use
> as a
> black box or get in deeper.
>
> --Charles
Thanks, Everyone has been a great help. I download and had a quick brows
over the "ARM ARM" pdf. This manual looked easier reading than the ARM
Technical Reference which I originally looked at and scared me off a
little.
There is an abundance of information and support available for the ARM
so it looks like a good thing to get into. From my experience with AVRs
I know the ARM core will eventually need to be understood as projects
evolve. Even using the ARM to blink a LED requires reasonable knowledge
of its architecture, and learning to use development tools, debuggers,
and necessary libraries, plus chip programming hardware.
A blinking LED in embedded system is equivalent to the "Hello World"
program running on a higher level system. If I get that happening, than
the ARM thereafter might not be so scary to learn.
Adam
