Newbie testing the waters, looking for advice

Go To Last Post
31 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello All:

Rank newbie here. Cool Forum! Lots of activity.

Years ago I was into microcontrollers big time, mainly 8051 and its variants (Intel & Philips), never went over to Motorola. I did go over to the dark side (management) but now I want to get back to the good stuff.

I'm a bit of an assembler freak, (wrote a lot of drivers) but as the AVR platform is RISC, I'm not sure the gains from assembler would be as big as CISC hand coding.

I just learned about the Atmel line after a friend turned me on to Arduino. Frankly, I'm blown away by the xmega capabilities. The integration, and minimal support chips required is impressive.

Ok, all that said, I really don't know what has been happening across the industry, so I'm looking for some pointers before I invest in the learning curve.

As the name says, you're all AVR Freaks but I'm hoping you guys can give me a leg up on the latest gen of microcontrollers in general.

Is Atmel/AVR the top dog? Who else is in the game? Why would I commit to AVR rather than controller "X"? Are there other uP vendors out there that tempt you?

Any links or keywords would be appreciated; your personal thoughts would be even better.

If I become an AVR freak, I promise to study (lurk in) the forum before you hear from me again :-).

Thanks in advance,

Bob

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Answers depend on what you want to do. Are you strictly at a hobby level? Or do you plan to create and sell a product? Something in between? How much do you plan to invest in a tool chain?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's one personal opinion. AVRs are my favorite 8-bit devices. dsPICs (and PIC24s) are my favorite 16-bit devices. ARMs (ARM7TDMI and now Cortex M3 and M0) are my favorite 32-bit devices. They all can be had with lots of on-board memory and peripherals.

AVR is nice because tools are free and easily obtainable, and because many devices come in prototype-friendly DIP packaging. The 16-bit PIC devices have the same two benefits.

That's about all anybody can tell you until you give more info as to the kind of things you want to do.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dksmall: Good question, but I didn't want to ramble on my first post.

I've done a lot of paid work for proof of concept/prototype/low volume production, sometimes using off-the-shelf hardware, sometimes custom. I'm hoping to use the free tools initially, but I have no problem investing if warranted.

Development platforms/suites are another question, but one thing at a time.

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:

That's about all anybody can tell you until you give more info as to the kind of things you want to do.

Well, that's the thing isn't it?

As I posted above, I did a lot of prototype work; everything from a protocol convertor to a ramp soak temperature controller, to a skeet scoring system.

Sticking with one family appeals to me as a lot of my work is very hardware oriented.

Jumping between platforms suggest to me that most of your dev work is done using high level languages.

Thanks for the vectors, glad to hear the PIC family is still alive and growing.

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pragma wrote:
kk6gm wrote:

That's about all anybody can tell you until you give more info as to the kind of things you want to do.

Well, that's the thing isn't it?

As I posted above, I did a lot of prototype work; everything from a protocol convertor to a ramp soak temperature controller, to a skeet scoring system.

Sticking with one family appeals to me as a lot of my work is very hardware oriented.

Jumping between platforms suggest to me that most of your dev work is done using high level languages.


True, although I've done a ton of assembly in the past (including a 6502 spreadsheet program for the old Atari and Commodore machines). I find that I mostly drop down to ASM now to look at compiler output, and sometimes to fiddle with startup code. Nowadays, unless pennies per part is really critical, it makes so much more sense to go to a part that doesn't need those last few percent of performance that you MIGHT be able to get with assembly. Having said that, I have no quarrel at all with those who simply like assembly.

Quote:
Thanks for the vectors, glad to hear the PIC family is still alive and growing.

I think the 8-bit PIC families are really ugly, but the 16-bit family is a very clean, modern design.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:

Nowadays, unless pennies per part is really critical, it makes so much more sense to go to a part that doesn't need those last few percent of performance that you MIGHT be able to get with assembly. Having said that, I have no quarrel at all with those who simply like assembly.

I agree 100%. My assembler work focuses on drivers, particularly displays and protocols, or high repetition ISRs. These tend to be loop oriented, where optimization can get some you some real gains.

That said, from Programming Pearls, (unfortunately out of print):

"Premature optimization is the root of all evil"

I have made some very good coin, coming in at the 11th hour where the hardware is committed and either the code size or data space requirements are out of bounds, because the development was done by committee.

In cases like this, assembler can really save the day.

Assembler is a double edge sword. Unless it is written with discipline and well documented, "clever" algorithms quickly become impossible to maintain, particularly in a team environment.

I could make the same case for C, but I don't want to start a flame war. :wink:

Thanks for the feedback

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've done mostly assembly with the AVR's, a little C now and then. Probably should start downloading software and playing with it to see if Studio's assembly/simulator is to your liking. Not sure if there are any other free assemblers out there. I use my editor of choice (UltraEdit) and call the AVR assembler from UE's toolbar. I only use Studio if I need to simulate something.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Re assembly on the AVR, it has always seemed to me that you could beat compiled code pretty easily with a smallish project, where you could perhaps make better use of all the available registers. But it also seems you could very easily get your knickers in a twist trying to manage those registers on a larger project.

Or, you could just adopt e.g. the gcc register useage protocol, and perhaps avoid some grief.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I could make the same case for C, but I don't want to start a flame war.

You don't know (yet) but you probably already did:
Quote:
Is Atmel/AVR the top dog? Who else is in the game?

It's just a matter of Leon getting out of bed now, and we are all on our merry way. Again.. :D

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Here's one personal opinion. AVRs are my favorite 8-bit devices. dsPICs (and PIC24s) are my favorite 16-bit devices. ARMs (ARM7TDMI and now Cortex M3 and M0) are my favorite 32-bit devices.

Well,that's clone of me.

There's 8051's for 8-bit and PIC32 for 32-bit.

Jeckson

www.tokopedia.com/madagang cheap and free worldwide shipping

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

Is Atmel/AVR the top dog? Who else is in the game? Why would I commit to AVR rather than controller "X"? Are there other uP vendors out there that tempt you?

If I had a completely free choice and was starting out now I think I'd go with ARM Cortex processors and not AVR8's. Your ARM knowledge and toolchain will then scale all the way from a $1 Cortex M0 to a $50 ARM11. Start with an ST32 Discovery or LPCXpresso for about the same cost as an Arduino (or less even!) and you'll even get a debugger thrown into the mix.

Cliff (not Leon ;-))

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
But it also seems you could very easily get your knickers in a twist trying to manage those registers on a larger project.

Only 32 to choose from. With six tied up for indexing and program memory access and two for multiply results, that leaves only 24 to get confused with. If you can cope with zero-page on a 6502 in assembler, that's nothing!

Cheers,

Joey

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

If I had a completely free choice and was starting out now I think I'd go with ARM Cortex processors and not AVR8's. Your ARM knowledge and toolchain will then scale all the way from a $1 Cortex M0 to a $50 ARM11. Start with an ST32 Discovery or LPCXpresso for about the same cost as an Arduino (or less even!) and you'll even get a debugger thrown into the mix.

The ARM family is impressive, with obviously a large installed base, but my scan of the family showed a lot of the members as basically processors and little more. Depending on the device, a lot more "glue" is required to do anything really useful, wrt to the real world. I could be wrong, I had to stop before my head exploded.

What impresses me about the AVR line is that there is a continuity of features and functions such as ADC and DAC from the smallest to largest. Unless I'm way off base, I could use an Xmega as a dev platform and once I've determined how much grunt I need, I can move down the product line to a better fit, with little or no code changes.

I'm still wrapping my head around how many hardware functions have been crammed into the package. Back in the day, these would all have been peripherals.

Uh-oh, I may be getting my "freak" on.

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jeckson wrote:
Quote:
Here's one personal opinion. AVRs are my favorite 8-bit devices. dsPICs (and PIC24s) are my favorite 16-bit devices. ARMs (ARM7TDMI and now Cortex M3 and M0) are my favorite 32-bit devices.

Well,that's clone of me.

There's 8051's for 8-bit and PIC32 for 32-bit.

Jeckson

The 8051 is near and dear to my heart, but adding features that were never envisaged in the original architecture can end up being a kluge. Sometimes it's better to just move on.

Not like uSoft of course. Win95 fixed everything, or was that 98? No wait it was ME, or Vista......

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pragma wrote:
The ARM family is impressive, with obviously a large installed base, but my scan of the family showed a lot of the members as basically processors and little more. Depending on the device, a lot more "glue" is required to do anything really useful, wrt to the real world. I could be wrong, I had to stop before my head exploded.

You definitely weren't looking at the right families (forgivable, since there is such a range of families). Look at the ARM7TDMI, Cortex M3 and Cortex M0 architectures. For example, see the NXP and ST parts. You'll find exactly the kinds of peripherals as on the AVR.

To repeat (and expand) on my list of particular AVR plusses, I count the free and easy tools (AVR Studio coupled with WinAVR), the DIP packages for many parts to ease prototyping, and the one I forgot before, operation from 5V down to 1.8V. AVRs also have a higher drive current rating than many devices (but not all).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:

You definitely weren't looking at the right families (forgivable, since there is such a range of families). Look at the ARM7TDMI, Cortex M3 and Cortex M0 architectures. For example, see the NXP and ST parts. You'll find exactly the kinds of peripherals as on the AVR.

At first I thought you were nuts but mea culpa there is a bit of a trick when searching for ARM data.

Because ARM technology is mainly (totally?) licensed, searching on the above model nos. almost always comes up with information on the ARM core itself, not the actual device that the licensee implements. In fact, searching ARM7TDMI came up with bupkis as far as real devices go.

Edit: I just found out that the Qualcomm Snapdragon is an ARM7. Sheesh! Who knew? , uh, never mind.

On the way, I studied the instruction set and found no instructions referencing I/O, DAQ registers etc., so are the peripherals memory mapped, I/O mapped or is the ARM instruction set extensible?

If the peripheral glue is added by various manufs., how does this impact development? Does one chose ARM and then a specific manuf. and dev suite?

It seems unlikely that different manufs. are going to be consistent in device mapping, so this may be a big point in AVRs favor.

I figured this out when I came across the TSX1001 by Triad, which has some pretty high perf. analog add-ons, wrapped around a Coretex M0.

So, to continue my search, I need to track down manufacturers names that are heavy into ARM.

I tried a number of Google approaches with minor success, so if anyone could drop a few big names my way, (with the best eval boards, dev suites) it would be greatly appreciated.

Cheers :wink:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's right, companies take the core (or one of the cores, for the ARM), and add their own peripherals. For example, NXP tends to have 32-bit timer/counters, while ST tends to have 16-bit. For the earlier (but still quite viable, don't let anybody tell you otherwise) ARM7TDMI core, the vectored interrupt controller was an external-to-the-core peripheral so companies did it differently, but that is now part of the architecture definition for the Cortex devices, IIRC.

I tend to look at the NXP devices first, followed by the ST devices. You can find lots of boards using different MCUs at www.microcontrollershop.com.

Any good toolset should let you work with any device from any family. I like the Rowley Crossworks personal license ($150), which comes with a very nice little tasking library.

BTW, if you go to e.g. mouser.com or digikey.com and search "cortex m3" you'll find most of the big players.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you are looking for the next step up from AVR8 then google some of these model numbers:

LPCXPresso (series of dev boards)
LPC1114 (one of the Xpresso processors)
LPC1343 (one of the Xpresso processors)
LPC1768 (one of the Xpresso processors)

STM32-Discovery (dev board)
STM32F100RB (one of the STM32 processors)

STM32 Circle (series of dev boards)
STM32 Primer 1 (one of the circle boards)
STM32 Primer 2 (one of the circle boards)
STM32F103RB1 (primer 1 processor)
STM32F103E (primer 2 processor)

Welcome to the world of Cortex M3 ;-)

Websites worth looking at:

http://www.stm32circle.com/resou...
http://www.st.com/internet/evalb...
http://ics.nxp.com/lpcxpresso/
http://www.embeddedartists.com/ (they actually make the Xpresso boards for NXP)

Even Atmel have Cortex M3 procesors:

http://www.atmel.com/dyn/product...

but the problem is that they appear to be made of pure unobtanium right now. Though it does look like there might now be some stocks of the dev board:

http://www.atmel.com/dyn/product...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Welcome to the world of Cortex M3 ;-)

Dang!

Just when I was leaning towards AVR. :wink:

I appreciate the time taken to be so detailed. Maybe now is a good time to thank everyone that has been so helpful on my vertical learning curve.

As far as eval and dev items, it looks to me like the Atmel offerings, like the XMega Xplained or the Xplained kit are the way to go, if I chose AVR. Good prices and high functionality to get my feet wet and start coding. I can then pick and chose other vendors, depending on the app.

It's going to take me a while to wade through all this Coretex info, but I need to do it.

One other thing is the code base. I assume that ARM has a bigger base, but how much of it is public domain?

Onward

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

kk6gm wrote:
That's right, companies take the core (or one of the cores, for the ARM), and add their own peripherals. For example, NXP tends to have 32-bit timer/counters, while ST tends to have 16-bit. For the earlier (but still quite viable, don't let anybody tell you otherwise) ARM7TDMI core, the vectored interrupt controller was an external-to-the-core peripheral so companies did it differently, but that is now part of the architecture definition for the Cortex devices, IIRC.

Thanks for the details. The variants between vendors makes me a little nervous wrt coding familiarity, and portability so if I go ARM, I'll probably stick with one family, unless another manuf. really blows my socks off.

The microcontrollershop link is great. It gives a smorgasbord of everyone's latest offerings and reminds me of uPs I had forgotten about.

Cheers

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Pragma wrote:
kk6gm wrote:
That's right, companies take the core (or one of the cores, for the ARM), and add their own peripherals. For example, NXP tends to have 32-bit timer/counters, while ST tends to have 16-bit. For the earlier (but still quite viable, don't let anybody tell you otherwise) ARM7TDMI core, the vectored interrupt controller was an external-to-the-core peripheral so companies did it differently, but that is now part of the architecture definition for the Cortex devices, IIRC.

Thanks for the details. The variants between vendors makes me a little nervous wrt coding familiarity, and portability so if I go ARM, I'll probably stick with one family, unless another manuf. really blows my socks off.


That's a reasonable approach. It even applies to the different architectures (ARM7TDMI, Cortex M3 and Cortex M0) within one manufacturer. The Cortex parts do things rather differently than the ARM7 parts.

The nice thing is that your one tooset will work with such a wide variety of parts, even if it does take some brainwork to move from one "neighborhood" to another.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello All:

Ok, I'm back. I've looked at a number of ARM vendors, but generally, I'm not feeling the love.

The processors I've found (so far) seem very capable, but getting the details can be frustrating.

Even within one manufacturer, getting a family spreadsheet is rare so I don't know if any product I've found is high, low or mid range.

As for a general ARM or even Coretex M3 spreadsheet, forget it.

Many of the eval board pages just talk about the board, not the processor, so I have to drill down to find out what I'm getting. Has the manufacturer showcased the good stuff or is it a cheap token? This now, is not a technology issue, but an information issue. A web war if you will.

IMHO, this is where Amel shines. The whole family line-up is right there. When I select a device, I get the specs in detail and a whole slew of application notes and links in one spot.

I've opted for the XMegaExplained Kit. The price is right and the functions are impressive. I could go third party and save maybe 10 bucks. Atmel has a vested interest in providing a solid development path, rather than selling boards. I suspect the kit is a big loss leader. There may be better boards out there, but I can sample them at a later date, when I have confidence in my code. If anyone here has had to debug hardware and software simultaneously, you'll know it's about as much fun as a vasectomy with a Weed Wacker.

In other words, it's all about support. Deciphering some obscure function in a processor may be worth the time if you plan to make ten thousand of them, but I want to get up and coding. Vague or hard to find documentation just frustrates me and gives me a rash.

So, I may have missed some good stuff. Google may have failed me, but digging deeper is like optimizing an init routine that is used at power up and forgotten.

At some point, you have to ship it, or in my case, buy into it.

Thanks again.

Bob

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But the xmegas have some hardware problems STILL. The ADC is the most well known I think. Search here about what freaks are saying about using xmegas, esp. ArnoldB.

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

indianajones11 wrote:
But the xmegas have some hardware problems STILL. The ADC is the most well known I think. Search here about what freaks are saying about using xmegas, esp. ArnoldB.

Thanks for the head up. ADC is important for me.

I will check it out, but in a nutshell, is it a showstopper or are there workarounds?

TIA

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

I will check it out, but in a nutshell, is it a showstopper or are there workarounds?

Search "frankvh" (I think it is) - he has blog entries about the endless faults in the Xmega ADC and some ways to workaround some of them. Personally I'd put in an external ADC if forced to use Xmega.

EDIT: frankvh it was (what a memory!!):

http://blog.frankvh.com/2010/01/...
http://blog.frankvh.com/2010/09/...
https://www.avrfreaks.net/index.p...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
about as much fun as a vasectomy with a Weed Wacker.
You've done this? Successfully? I had nothing but trouble! :smile:

--greg
Still learning, don't shout at me, educate me.
Starting the fire is easy; the hardest part is learning how to keep the flame!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

gregsmithcts wrote:
Quote:
about as much fun as a vasectomy with a Weed Wacker.
You've done this? Successfully? I had nothing but trouble! :smile:

LMFAO!

It's definitely a two person job, unless you have very long arms.

A very steady hand is also required.

Position the subject to let gravity help you to um, get things out of the line of fire, so to speak. Think yoga poses.

The Uttanasana position has been shown to be effective, but must be done with the legs forward and spread, lest you bang the hell out of your inner thighs.

If you have a gas (petrol) powered trimmer, it must be done outdoors, so choose a location that won't offend the neighbours.

Cheers and Good Luck

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For lowest cost to start on Cortex, the Mbed & LPCXpresso based on NXP LPC1768/69 Cortex M3. $30 LPCXpresso comes with PLC-Link (jtag/swd) and C compiler with limite to 128KB of code. Mbed is twice the cost, online c++ compiler, no limites but no debug. Currently NXP is giving free M0 LCPXpresso board.

TI Stellaris, lots of library source code & driver for almost everything. Much more extensive then LPC. Entry level is a little bit more expensive then NXP.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been scared away from Xmega based on all the discussion of problems. Prudent or foolish, I don't know. But it really doesn't matter to me, since at the low and mid end, the rest of the AVR family offers plenty of performance. If I need performance that pushes the 8-bit AVRs, I'd rather take a big jump to another family, than to take a 60% jump to Xmega.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read ArnoldB go, go, go !

https://www.avrfreaks.net/index.p...

Also the Atmel AT32-series looks good ( haven't used them yet myself ). 32 bitters, some are 64 pin TQFPs and you can prog. / debug using the dragon ! Stable compared to xmega and may have more functionlity ( both series have 64 pinners ).

1) Studio 4.18 build 716 (SP3)
2) WinAvr 20100110
3) PN, all on Doze XP... For Now
A) Avr Dragon ver. 1
B) Avr MKII ISP, 2009 model
C) MKII JTAGICE ver. 1