So old to learn? Serious problem

[rstofer]

Ten or twelve years back, I rather enjoyed working with the ATmega128.  It's a 64 pin package so it has a ton of IO, the C compiler is full featured (as opposed to what was available for the PIC 16Fxxx) and programming the device with AVRdude was easy to incorporate right into the makefiles.

The ATmega128 is still my favorite 8 bit chip.

But the original question for this thread was where to start and I took that to mean absolutely zero experience in the arena.  The only correct answer today is Arduino because everything is handed to the user on a plate.  For the ATMega128, I had to write every single line of code.  If I wanted to use a peripheral, I had to do all the User Manual research, set up all the registers and do all the debugging.  There was no application library.

Still is was doable.  It helped that I had been working with uCs since '75, the earliest days of the 8080, Z80 and 8085.  I understood what I was reading.  I'm not so sure how it would have worked out if I were starting cold.  Or, maybe I do! 

I transitioned to the ARM 7TDMI and started cold.  It took a while to get up to speed with the startup code.  In that version of the ARM core, the startup code is written in assembly language and it takes a few hours to get the hang of it.  And more reading of the User Manual.  If I were to start fresh with the ARM processors, the original mbed (LPC1768) and the online toolchain/library would be my platform of choice.  Again, much of the peripheral code is provided.  Networking (lwIP) is provided.  There is still plenty to write but there is a base set of library code and a lot of documentation.

I would think that building a project with a bare iron AVR would be many times more difficult than doing it with an Arduino.  MANY times more difficult.

[ogden]

I don't get all the people who dismiss AVR chips because they only run at 16MHz and aren't 32 bits.

There's point indeed. Unless all your projects are led blink - you can run out of AVR (architecture) performance or peripheral capabilities. On the other hand there always will be ARM microcontroller powerful enough for the task, or you need FPGA + ARM When you learn ARM - you basically are covered from small cheap low pin count chips up-to big performers. All this with single set of knowledge and tools. Why bother to learn first AVR, then msp430, then DsPIC, then TMS320 and their tools when you can just learn ARM and that's it? Only argument _for_  AVR and Arduino (maybe msp430 too) - steeper learning curve and vast amount of information on internet.

[Mr. Scram]

There's point indeed. Unless all your projects are led blink - you can run out of AVR (architecture) performance or peripheral capabilities. On the other hand there always will be ARM microcontroller powerful enough for the task, or you need FPGA + ARM When you learn ARM - you basically are covered from small cheap low pin count chips up-to big performers. All this with single set of knowledge and tools. Why bother to learn first AVR, then msp430, then DsPIC, then TMS320 and their tools when you can just learn ARM and that's it? Only argument _for_  AVR and Arduino (maybe msp430 too) - steeper learning curve and vast amount of information on internet.

There are plenty of things that are totally undoable on the kind of ARM chips we're talking about. ARM isn't a magic bullet, nor are FPGAs. Why not go x86 right away and forget all these anemic chips?

Why start with AVR? Because it's plenty enough for a lot of tasks, it's easy to work close to metal whereas ARM can be very confusing, you'll learn good practices because it's easier to see why, it's cheap to get started and and there is a huge amount of good information available. Why confuse yourself when it's not neccessary?

Besides, if you really think AVR is only good for blinking a LED, that shows why you desperately need some experience with the platform You'll end up being a better developer.

[001]

Is it some sort of holywar here?

[Mr. Scram]

Is it some sort of holywar here?

Yeah, the ARM versus AVR discussion is a common one. Though I couldn't care less, I use both regularly, so I'm just having a bit of fun.

[Fungus]

Is it some sort of holywar here?

Yes.

Some people like to carry a cup of water around in a huge bucket because it looks more important.

(Or something like that. You'll have to ask them...  )

Me: 16MHz is plenty and 5V@20mA on the pins is useful in all sorts of ways.

[ogden]

There are plenty of things that are totally undoable on the kind of ARM chips we're talking about.

Name those plenty of things which are undoable with ARM MCU yet possible with AVR

Why not go x86 right away and forget all these anemic chips?

You mean Intel Quark? It is not 80186 you are talking about, right?   

Why start with AVR? Because it's plenty enough for a lot of tasks, it's easy to work close to metal whereas ARM can be very confusing, you'll learn good practices because it's easier to see why, it's cheap to get started and and there is a huge amount of good information available. Why confuse yourself when it's not neccessary?

Sure we agree here. You basically repeat myself where I say that AVR is good for learning 

Besides, if you really think AVR is only good for blinking a LED, that shows why you desperately need some experience with the platform You'll end up being a better developer.

Don't put words in my mouth.  I just say that by learning ARM you have your hobbyist needs for MCU mostly covered and you can put your efforts into your builds, not into learning new MCU architecture & tools each time you build something more complex than before. On the other hand if your aim is learning and being better developer (basically coder) - then learn it all for gods sake. Just note that electronics is much more than MCU coding.

p.s. Just having fun as well.

[Mr. Scram]

Name those plenty of things which are undoable with ARM MCU yet possible with AVR

Can you name the things undoable with x86, yet possible with ARM? Go big or go home!

[coppice]

Name those plenty of things which are undoable with ARM MCU yet possible with AVR

Can you name the things undoable with x86, yet possible with ARM? Go big or go home!

Run for a long time from a small cell?

[ogden]

Name those plenty of things which are undoable with ARM MCU yet possible with AVR

Can you name the things undoable with x86, yet possible with ARM? Go big or go home!

I did not bring "things undoable" to the table, not to mention x86. So we can conclude that you gave up answering my question?

[Mr. Scram]

Run for a long time from a small cell?

x86 can be remarkably efficient.

[Mr. Scram]

I did not bring "things undoable" to the table, not to mention x86. So we can conclude that you gave up answering my question?

No, you've just shown that the argument for your platform can also be used against it. I was never talking about that AVR could do plenty of things ARM can't, I was talking about how x86 can do that

[ogden]

No, you've just shown that the argument for your platform can also be used against it. I was never talking about that AVR could do plenty of things ARM can't, I was talking about how x86 can do that

You can always find more powerful tool/chip/whatever. Not even worth of discussion

I hoped that you will come-up with 5V supply and 20mA i/o capability of AVR, so I can remind that ARM uC can do the same in form of ATSAM20/21

[Mr. Scram]

"You can always find more powerful tool/chip/whatever."

Why use AVR? You just explained it.

[ogden]

"You can always find more powerful tool/chip/whatever."

Why use AVR? You just explained it.

Nah. You shall use 4-bit microcontrollers as well - for builds where AVR is too powerful.

[Mr. Scram]

Nah. You shall use 4-bit microcontrollers as well - for builds where AVR is too powerful.

Yes, because there is an easily available and well supported 4 bit platform which is accessible to anyone.

[A Hellene]

Is it some sort of holywar here?

Come on guys, with the my-CPU-is-faster mentality!
Please, stop frightening the OP...

Dear 001, the following are some of the 8-bit AVR ATTiny85 and ATMega328P chips capabilities; when someone will need anything faster for a much more demanding project they could just move on to the 32-bit ARM counterparts:

From my post on AVRFreaks.net in December 29, 2015:

This is the measurement of the DDS modulated digital output (Ch 3) startup time since the PTT button (Ch 2) falling edge, while the generated 67.0 Hz sub-tone output sinewave (Ch 1) can be seen, of the ATtiny85 based CTCSS encoder/decoder I am working on.

From my post at EEVBlog.com on September 25, 2017:

Voltage doubler lead-acid batteries desulfator; mind that it is only a preliminary 350 Ampere prototype...

But, nowadays, I think that I can very well understand why we certainly need an Intel i5 CPU with 2GB DDR3 RAM in order to just blink an LED:

( * ) Just look at the quality of the "engineers" the educational institutions spit out today. Their eduction is oriented rather in their marketing skills than in actual Electrical Engineering. Quoting a friend of mine, "The only engineers who get promoted to management are the ones who can be spared. The real walking disasters are the ones who think they got promoted because they were good."

-George

[ogden]

Come on guys, with the my-CPU-is-faster mentality!
Please, stop frightening the OP...

We are just having fun. For example my recent weekend quickbuild was based on msp430f2013. Lovely, breadboardable PGA-enabled 16-bit SD ADC with uC on-board I have nothing against 8/16 bit uC if some1 for some strange reason though so.

[Fungus]

I hoped that you will come-up with 5V supply and 20mA i/o capability of AVR

I considered it.

I hoped that you will come-up with 5V supply and 20mA i/o capability of AVR, so I can remind that ARM uC can do the same in form of ATSAM20/21

Yeah but nobody's using those. They're all using the cheapo STM things off eBay.

[IanJ]

My vote is for Arduino........lotsa scope to do things outside of the 'black box'......in fact it allows you to concentrate on the external hardware and get straight to coding productively and without getting stuck in huge bloated dev systems that require lots of time and effort in themselves if you are coming from scratch.

Example:


Anyone mention Contextual Electronics........that might be another avenue to learn.
https://contextualelectronics.com/course-types/

Ian.