Trying to get away from Arduino

[Aodhan145]

Hi,
   I got into electronics as a hobby through Arduino. I know the downsides of Arduino such as the digitalWrite function taking ~53 clock cycles. I want to be able to program an AVR "properly". Does anybody know of any good websites / tutorials on programming AVRs properly?

[rs20]

Your are to be commended for venturing beyond the cushy world of Arduino! Real AVR code might look strange at first, but with little effort it will soon become second nature.

Find out what chip is on your Arduino board of choice (most like an ATmega328P or an ATmega32U4), and look up the chip's datasheet direct from Atmel:

• ATmega328P
• ATmega32U4

At 400 pages, it may be intimidating but: a) you don't read it like a book, you just read about the peripherals that are relevant to your current project, and b) those 400 pages completely, authoritatively specify every single aspect and detail of the chip*.

This may be too much of a jump for you right now (and I'm sure others will suggest more gentle introductions), but it's good to take a look at the actual datasheet every now and then and pretty soon you'll find yourself needing nothing else.

Don't forget that normal, "real" AVR code can be used in the Arduino IDE: so you don't have to switch all at once. For example, you can ditch digitalWrite and use PORTB and DDRB instead to get really fast GPIO, but still use Arduino's serial functions.

Feel free to ask specific questions if you get stuck (e.g. "how do I do PWM?")

* I'm sure someone will point out that it misses some things, but it's pretty close at least.

[Aodhan145]

For example, you can ditch digitalWrite and use PORTB and DDRB instead to get really fast GPIO, but still use Arduino's serial functions.

Thats what I want to be able to do. How much do they datasheets vary from AVR to AVR? I have a good couple of different chips. I don't have to change IDE/compiler do I?

[Psi]

It's pretty simple once you understand what's happening. It just looks a bit complicated at first.

Use PORTA to change the 8 digital outputs on the A port of the mcu (look up the datasheet and compare with arduino schematic to see what port A pins correspond to arduino digital pins)

There is also PORTB  PORTC etc..

Since PORTA refers to 8 outputs all at once, if you set it you are also setting other outputs that you may or may not want to change.
Therefor you must read PORTA first and "merge" what you want to change with whats already set/cleared.

Since computers work in binary PORTA is 8 binary bits.
eg 00000000 would mean all of the outputs on PORTA are cleared (low).
and 11111111 would mean they are all high.

Introducing the bitwise shift operation << means shift left.   >> means shift right.
you use it the same as you would use + - / *
eg.
something >> something

If we say PORTA is binary 0000 0001 that means the first output on PORTA (called PA0) is high.  (The right most bit is always the first on the port)

If we go
PORTA = PORTA << 1;
Then PORTA now has all its output states shifted left by 1.
So if PORTA was 0000 0001 before then it is now 0000 0010.   PA0 is now low but PA1 is high.


Introducing bitwise OR. The  |  character. This is different to the or you would use on an IF statement which is ||.
Bitwise OR works on the individual binary bits, not the number as a whole.
So if you do
00100000   
    |
00000100
You get
00100100


Now we need to come up with a way to easily set/clear a output without changing other outputs.
The syntax for this is
PORTA = PORTA | (x<<1);
where x is a number between 0 and 7 for the output we want to set.

AVR defines PA0=0 and PA1=1 etc.. (because the AVR datasheet shows the i/o named like this). So for better readability if we want to set PA5 high we can simply go..
PORTA = PORTA | (1<<PA5);

If you evaluate that, it takes a 1 and shifts it along 4 times (into the 5th position) and then bitwise or's that with PORTA current value.
So it forces PA5 high and doesnt effect the other outputs on PORTA.
It is doing a read-modify-write operation.

There are two ways to write exactly the same line in C. Both of these are the same, the 2nd is just a shorthand version
PORTA = PORTA | (1<<PA5);
PORTA |= (1<<PA5);

To clear PA5 it's a tiny bit more complicated.
You go.
PORTA = PORTA &  ~(1<<PA5)
PORTA &= ~(1<<PA5)   <-- or you can do it this way, (its exactly the same)

& is bitwise AND
~ means bitwise invert  (it just inverts all the bits, 0 becomes 1 and 1 becomes 0)

See if you can work through the logic and see how the clear works.


Additional..
To check inputs you use the word PIN.
So, PINA is for the block of 8 "A" inputs. 
eg, this would only run if the PA5 input is high
if (PINA & (1 << PA5))
{
    // do stuff
}

There is one other thing you need to know.
DDRA
This is the Data Direction Register for A   (there's also DDRB DDRC etc..)
You use it to set if a specific i/o is an input or an output.  If there is a 1 in the corresponding position the i/o is an output.
Therefor. The following will make PA5 an output.
DDRA |= (1<<PA5);

[zapta]

I don't have to change IDE/compiler do I?

The arduino IDE uses the standard avrgcc complete so you don't need to change anything. You can even mix direct port access with arduino digital write (but not for the same port) arduino is mostly a s standard compiler with an addition of high level libraries and its up to choose what libraries to use.

You can also search for the source code of fast digital io libraries for arduino, you can see there hire it's done.

Arduino gives you choices, including doing direct io if you want, quick is very nice.

[amyk]

a) you don't read it like a book, you just read about the peripherals that are relevant to your current project

Actually if you have time --- which as a hobbyist you probably have plenty of --- I'd strongly recommend reading every single page of the datasheet. You may experience quite a few "I didn't know it could do that" moments and it could inspire your future projects.

[Mechatrommer]

I don't have to change IDE/compiler do I?

The arduino IDE uses the standard avrgcc

the next thing when your code grows, the abysmality of Arduino the IDE as an IDE such as no debug, no breakpoint, no coloring, archaic multiple window way, enforcing folder=project name, infinitesimal compile time etc will come to mind... yes you do, if you need to change the IDE, the day is today... change to AVR Studio 4 + avrdude.exe, it wont hurt as much as living with Arduino the IDE...

[alho]

Google arduino port manipulation. Plenty of tutorials to get you started on using registers directly in arduinoIDE.

Mixing arduino and avr code might cause some conflicts because arduino hides what is actually happening. Few examples. Lets say you are directly controlling timer1 to do fast PMW  but some arduino function might also use timer1 "behind the curtain" to time something.
Arduino uses pins 0 and 1 for serial communications and change to DDRx (Port x Data Direction Register) or PORTx (Port x Data Register) might interfere whit the serial communication. The silly arduino pin numbering  makes it even more confusing. What AVR pins are Arduino pins 0 and 1? In witch AVR port are Arduino pins 0 and 1?

a) you don't read it like a book, you just read about the peripherals that are relevant to your current project

Actually if you have time --- which as a hobbyist you probably have plenty of --- I'd strongly recommend reading every single page of the datasheet. You may experience quite a few "I didn't know it could do that" moments and it could inspire your future projects.

+1

Read most of the datasheet for one chip. If you switch to another chip you already have an idea of what to look for. There shouldn't be much difference between AVR chips.
The important thing is to learn how to read datasheets. If you can find  from datasheet what registers control PORTA on Atmel AVR you should not have much trouble finding out what registers control PORTB on Microchip PIC.

[rs20]

How much do they datasheets vary from AVR to AVR?

The datasheets are very similar; if two chips have the same feature; the relevant sections of the respective datasheets will be essentially identical -- right down to every bit of every register. But different chips do have different features, so certain sections of the datasheet might be deleted or added accordingly. So you should still look at the correct datasheet on the off-chance that something is quirky about that particular chip, but take heart in knowing that it's most likely the same as other chips.

[JacquesBBB]

If you want to understand how goes the direct programming of a MCU, I strongly recommend to follow the MOOC
from Austin University "Embedded Systems - Shape The World"
by Jonathan Valvano and Dr. Ramesh Yerraballi
https://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-03x

Its not about the Atmel chips, but the Ti Launchpad Tiva C  which are very powerful
 evaluation boards similar to the Arduino, but which you  can get  at low price from Ti or any main distributor.

https://youtu.be/YchfhYsQFPc

The Austin team have done an extraordinary job with their course, as  you will be able to directly program a board using a professional IDE (Keil)  with step to step instructions and automatic correction and evaluation
with their special module.
You will have to buy the  EK-TM4C123GXL board which is only 12.5$, and has a on board debugger.



The good news is that the new release of the lectures starts  January 20, 2016.

Even if after that you want to go back to Atmel  MCU, you will have learn all the fundamentals.
You will learn how to use a debugger,
and will be able to easily adapt to any other MCU. You can also choose to continue on Ti MCU, which you can also
program through an Arduino like interface, Energia.



Here is the Syllabus of the Ti online lectures.

Module 1: Welcome and introduction to course and staff
Module 2: Fundamental concepts Numbers, Computers, and the ARM Cortex M processor
?Lab 2. Run existing project on LaunchPad with switch input and LED output.
Module 3: Electronics Resistors, Voltage, Current and Ohm’s Law
Module 4: Digital Logic Transistors, flip flops and logic functions
Lab 4. Debug a system with two inputs and two outputs.
Module 5: Introduction to C programming
?Lab 5. Write a C function and perform input/output.
Module 6: Microcontroller Input/Output
?Lab 6. Write C software that inputs from a switch and toggles an LED output.
Module 7: Design and Development Process
?Lab 7. Write C functions that inputs from a switch and outputs to two LEDs, which is a simulated pacemaker.
Module 8: Interfacing Switches and LEDs
?Lab 8. Interface an external switch and LED and write input/output software.
Module 9: Arrays and Functional Debugging
?Lab 9. Write C functions using array data structures that collect/debug your system.
Module 10: Finite State Machines
?Lab 10. Interface 3 switches and 6 LEDs and create a traffic light finite state machine.
Module 11: UART - The Serial Interface, I/O Synchronization
?Lab 11. Write C functions that output decimal and fixed-point numbers to serial port.
Module 12: Interrupts
?Lab 12. Design and test a guitar tuner, producing a 440 Hz tone.
Module 13: DAC and Sound
?Lab 13. Design and test a digital piano, with 4 inputs, digital to analog conversion, and sound.
Module 14: ADC and Data Acquisition
?Lab 14. Design and test a position measurement, with analog to digital conversion and calibrated output.
Module 15: Systems Approach to Game Design
?Lab 15. Design and test a hand-held video game, which integrates all components from previous labs.
This lab will not be graded, but we will provide a way for you to upload your source to a server and download code from other students to study and to play.
Module 16: Wireless Communication and the Internet of Things
?Lab 16. Connect a CC3100 booster pack to the LaunchPad and communicate with an access point.
This lab will not be graded, but we will provide a way for you communicate with a class server.
Note

You will need to purchase either the EK-TM4C123GXL board from Texas Instruments and a set of electronic components. The cost for these parts is about $40 USD plus shipping. We will provide instructions at: http://edx-org-utaustinx.s3.amazonaws.com/UT601x/index.html .

You will need a PC running Windows XP, Windows 7, Windows 8, or Windows 10. You will need to be able to install the Keil uVision integrated development environment, which will require administrative privileges to the PC. We will provide instructions at: http://edx-org-utaustinx.s3.amazonaws.com/UT601x/index.html .

[rx8pilot]

The avrfreaks forum has been very helpful. Lots of tutorials for beginners. When I get to my normal pc,  I will try to post a few of my favorites.

Sent from mobile device.... Keeping it short and mis-spelled

[Towger]

I strongly recommend to follow the MOOC
from Austin University "Embedded Systems - Shape The World"
by Jonathan Valvano and Dr. Ramesh Yerraballi
https://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-03x

The the above course and the second part of it, which is coming out at the end of the summer.
You may find some of it simple (at first), put covers programming a M4 micro controller at a much lower level using Keil then the Arduino/IDE.

[Simon]

The new Atmel Studio allows you to import an arduino project now and show you the real code.

First you need to learn C which you probably know enough of if you have used the arduino. Then choose a chip, I started with the atmega328 for backup and learn one aspect of it at a time. So start with getting the thing running with the clock you want, then turning outputs on and off, then maybe the PWM/counter channels, slowly work your way through them.

then you can start writing little macros to make it faster and slicker to set the chip up, for example i have a set of macros for PWM configuration, so I may read off the datasheet the mode I need and then put something like "counter_1B_mode1" to set the 4 bits of the register required to set it up without having to keep checking the register and bit names.

I even did it for setting pin as inputs, outputs, turning them on, off everything.

The crucial thing is understand the chip, you are not programming a PC, you have a chip with very specific and possibly limited resources that you need to make the most of and understand properly to make ythe most of.

[miguelvp]

Since you probably have a lot of shields, what about using a pioneer kit?

compiler is free and it has arduino headers, and here are 100 projects using that kit.

http://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true

Later you can use a PSoC5LP prototyping board which is pretty amazing and only costs $10

[rs20]

You don't need to spend a dollar; the Arduino you already have is a perfectly fine ATmega328P/ATmega32U4 breakout board...

[Aodhan145]

Since you probably have a lot of shields, what about using a pioneer kit?

compiler is free and it has arduino headers, and here are 100 projects using that kit.

http://www.element14.com/community/thread/23736/l/100-projects-in-100-days?displayFullThread=true

Later you can use a PSoC5LP prototyping board which is pretty amazing and only costs $10

I have never bought a shield once. I consider them a waste of money.

[Aodhan145]

It's pretty simple once you understand what's happening. It just looks a bit complicated at first.

Use PORTA to change the 8 digital outputs on the A port of the mcu (look up the datasheet and compare with arduino schematic to see what port A pins correspond to arduino digital pins)

There is also PORTB  PORTC etc..

Since PORTA refers to 8 outputs all at once, if you set it you are also setting other outputs that you may or may not want to change.
Therefor you must read PORTA first and "merge" what you want to change with whats already set/cleared.

Since computers work in binary PORTA is 8 binary bits.
eg 00000000 would mean all of the outputs on PORTA are cleared (low).
and 11111111 would mean they are all high.

Introducing the bitwise shift operation << means shift left.   >> means shift right.
you use it the same as you would use + - / *
eg.
something >> something

If we say PORTA is binary 0000 0001 that means the first output on PORTA (called PA0) is high.  (The right most bit is always the first on the port)

If we go
PORTA = PORTA << 1;
Then PORTA now has all its output states shifted left by 1.
So if PORTA was 0000 0001 before then it is now 0000 0010.   PA0 is now low but PA1 is high.


Introducing bitwise OR. The  |  character. This is different to the or you would use on an IF statement which is ||.
Bitwise OR works on the individual binary bits, not the number as a whole.
So if you do
00100000   
    |
00000100
You get
00100100


Now we need to come up with a way to easily set/clear a output without changing other outputs.
The syntax for this is
PORTA = PORTA | (x<<1);
where x is a number between 0 and 7 for the output we want to set.

AVR defines PA0=0 and PA1=1 etc.. (because the AVR datasheet shows the i/o named like this). So for better readability if we want to set PA5 high we can simply go..
PORTA = PORTA | (1<<PA5);

If you evaluate that, it takes a 1 and shifts it along 4 times (into the 5th position) and then bitwise or's that with PORTA current value.
So it forces PA5 high and doesnt effect the other outputs on PORTA.
It is doing a read-modify-write operation.

There are two ways to write exactly the same line in C. Both of these are the same, the 2nd is just a shorthand version
PORTA = PORTA | (1<<PA5);
PORTA |= (1<<PA5);

To clear PA5 it's a tiny bit more complicated.
You go.
PORTA = PORTA &  ~(1<<PA5)
PORTA &= ~(1<<PA5)   <-- or you can do it this way, (its exactly the same)

& is bitwise AND
~ means bitwise invert  (it just inverts all the bits, 0 becomes 1 and 1 becomes 0)

See if you can work through the logic and see how the clear works.


Additional..
To check inputs you use the word PIN.
So, PINA is for the block of 8 "A" inputs. 
eg, this would only run if the PA5 input is high
if (PINA & (1 << PA5))
{
    // do stuff
}

There is one other thing you need to know.
DDRA
This is the Data Direction Register for A   (there's also DDRB DDRC etc..)
You use it to set if a specific i/o is an input or an output.  If there is a 1 in the corresponding position the i/o is an output.
Therefor. The following will make PA5 an output.
DDRA |= (1<<PA5);

This is incredibly useful thanks very much. I never got my head around these operations when looking at avr code.

[RobertBG]

If you're looking to get away from Arduino you could always go back to Basic Stamp (great way to learn code) or  Propeller.

Granted I'm just getting back into things but every time I try and find a reason to use the Arduino platform I cant justify using it for myself.BASIC is a very easy language to pick up,especially if your new to programming and it can handle most of my needs.Lastly it runs on my old gear along with the new Propeller stuff I'm working on.
As far as C/C++  stuff goes,you can run that on propeller too and that is what I've been currently working on learning.So between this and the 8 32 bit cores I've pretty much given up on Arduino and Atmel  

[rx8pilot]

If you're looking to get away from Arduino you could always go back to Basic Stamp (great way to learn code) or  Propeller.

Granted I'm just getting back into things but every time I try and find a reason to use the Arduino platform I cant justify using it for myself.BASIC is a very easy language to pick up,especially if your new to programming and it can handle most of my needs.Lastly it runs on my old gear along with the new Propeller stuff I'm working on.
As far as C/C++  stuff goes,you can run that on propeller too and that is what I've been currently working on learning.So between this and the 8 32 bit cores I've pretty much given up on Arduino and Atmel

RobertBG, it good to see you diving in to the tech discussions ;-)

I never spent any time with Arduino personally but some young engineers I hired showed me the environment. At the time, I had not yet designed anything with a microcontroller, but I was familiar with the basic block diagrams. From the beginning, I was intersted in developing commercial products so I elected to skip Arduino altogether and go straight to a 'pro' environment for AVR development.

Step 1: As other have already pointed out, learn the hardware and it's capability as much as practical. You cannot and should not bother memorizing the data sheet but it it very close, you will need to refer to it all the time. There are also many design considerations that of course require an understanding the hardware and electronics. Interfacing with A/D, de coupling caps, current sink capability, etc. To get started I found myself simply copying known good circuits from others and then figuring out why they work.

Step 2: Get Atmel Studio. It is intimidating at first since it is setup for professional development. It's not unlike using Photoshop to crop and image when you get started. There is a LOT of stuff that you will not need to know until you get further along.

Step 3: Get an overview of C language in general. Arduino is C like, but its not C so you may have to unlearn a few things. There are a million tutorials on the internet - some of them are specific to embedded programming and some are generic. C does not know the difference between a micro-controller and and other CPU.  One of the biggest differences is interrupts. This is a strange twist that will impact the approach to programming. Essentially, an interrupt is when some internal or external event needing immediate attention - it could be a button press or a timer running out. Whatever the cause of the interrupt, the main program goes on PAUSE and another program (interrupt service routine) is run, and then it goes back to the main program. Learn C, header files, bit shifting, learn the difference between a keyword and external function, bit shifting, bit shifting, and bit shifting.

Step 4: Don't kill yourself on steps 1-3 before you are able to get an LED to blink. The reason I suggest this it because getting an LED to blink means that you have the physical part setup and the software is able to connect to the programmer. Once you have that working, you can quickly run experiments as you learn something in the data sheet or in a C lesson. I would read a little, play a little and repeat. Reinforcing the lesson just learned.

Step: 5 Repeat 1-4 over and over.

Excellent resources, tutorials and discussions.
http://www.avrfreaks.net/

Gotta run for now....

[linux-works]

one word of caution: the benefit of arduino API is that its abstract and NOT tied to an atmel.

sometimes the arduino system is NOT atmel and if you assume its always atmel, you are in for a rude awakening.  many 3rd party libraries assume ONLY atmel and they are, therefore, highly unportable.

you lose speed if you use abstractions but you gain portability.

just throwing this out there.  its often forgotton and when you decide to port to a bigger chip later on (arm, other vendors..) then you will be bitten by this if you don't plan for it.

I'm going thru this right now when I'm testing lots of libraries on a non-atmel 'arduino' board.  lots of code does not work (or even compile) because people seem to incorrectly assume "arduino == atmel"

[rx8pilot]

Its true that Arduino abstraction is good in terms of portability. When I was first learning,  one of my first projects was porting an LCD library from a PIC/unkown compiler to AVR/GCC. It was an accidental but very beneficial lesson. I focused on understanding code from other libraries and how to tweak it to what I needed quickly. With that said, there is a massive pile of libraries for AVR so it does not matter that much if your Arduino does not compile. The biggest benefit of learning C for embeded,  is that you have very few limitations. Take the next step to ASM that can augment your C and you really have control regardless of what hardware you have.

High level abstraction is remarkably useful to learn concepts. Learning C and ASM really lets someone exploit every clock cycle and feature. I am so happy that I took the time to dig in.  Super satisfying.

Sent from my SAMSUNG-SM-G890A using Tapatalk

[zapta]

Step 3: Get an overview of C language in general. Arduino is C like, but its not C

It's called C++.

[mtdoc]

If you want to understand how goes the direct programming of a MCU, I strongly recommend to follow the MOOC
from Austin University "Embedded Systems - Shape The World"
by Jonathan Valvano and Dr. Ramesh Yerraballi
https://www.edx.org/course/embedded-systems-shape-world-utaustinx-ut-6-03x

I second this recommendation. It is an excellent course and will take you far on the road to learning embedded C. I completed about 1/2 of the course the first time it was offered 2 years ago before other life responsiblities pulled me away. I plan to repeat it and hopefully finish it this year.  You can't beat the price - it is FREE!

Even if you never plan to use a TI MCU  or any ARM chip in the future -almost everything you learn in this course will be applicable to programming 8 and 16 bit Atmel chips.

[retrolefty]

Step 3: Get an overview of C language in general. Arduino is C like, but its not C

It's called C++.

 It's always amazes me how many people think of or talk of the 'Arduino programming language'. It's simply C++. If you learn C++ on an arduino there is nothing one has to 'unlearn' to program in C++ in other environments.

 I suppose they mean the utilization of Arduino provided functions and libraries, as if using them means one is using a different language.

 I understand if one is explaining that by only learning and utilizing for example the Arduino provided library such as Serial() without ever learning how the underlining USART hardware peripheral actually is programmed then that individuals learning of a specific microcontroller is not complete. But that is another argument all together.

Arduino is C++

[RobertBG]

I never spent any time with Arduino personally but some young engineers I hired showed me the environment. At the time, I had not yet designed anything with a microcontroller, but I was familiar with the basic block diagrams. From the beginning, I was intersted in developing commercial products so I elected to skip Arduino altogether and go straight to a 'pro' environment for AVR development.

Step 1: As other have already pointed out, learn the hardware and it's capability as much as practical. You cannot and should not bother memorizing the data sheet but it it very close, you will need to refer to it all the time. There are also many design considerations that of course require an understanding the hardware and electronics. Interfacing with A/D, de coupling caps, current sink capability, etc. To get started I found myself simply copying known good circuits from others and then figuring out why they work.

Step 2: Get Atmel Studio. It is intimidating at first since it is setup for professional development. It's not unlike using Photoshop to crop and image when you get started. There is a LOT of stuff that you will not need to know until you get further along.

Step 3: Get an overview of C language in general. Arduino is C like, but its not C so you may have to unlearn a few things. There are a million tutorials on the internet - some of them are specific to embedded programming and some are generic. C does not know the difference between a micro-controller and and other CPU.  One of the biggest differences is interrupts. This is a strange twist that will impact the approach to programming. Essentially, an interrupt is when some internal or external event needing immediate attention - it could be a button press or a timer running out. Whatever the cause of the interrupt, the main program goes on PAUSE and another program (interrupt service routine) is run, and then it goes back to the main program. Learn C, header files, bit shifting, learn the difference between a keyword and external function, bit shifting, bit shifting, and bit shifting.

Step 4: Don't kill yourself on steps 1-3 before you are able to get an LED to blink. The reason I suggest this it because getting an LED to blink means that you have the physical part setup and the software is able to connect to the programmer. Once you have that working, you can quickly run experiments as you learn something in the data sheet or in a C lesson. I would read a little, play a little and repeat. Reinforcing the lesson just learned.

Step: 5 Repeat 1-4 over and over.

Excellent resources, tutorials and discussions.
http://www.avrfreaks.net/

Gotta run for now....

While this is good advice I dont see any reason for someone who is looking to get away from Arduino to stay pigeon holed into Atmel.Maybe it's just me but there's tons of others out there that might make for a easier transition depending on his final goals.


For me personally,most everything that comes across my desk has a Motorola or one of it's derivatives in it.Hence why I am trying to go in that direction and why I've been lurking around for some time .Depending on goals there may be a better option than AVR.Also I've personally found that AVR is a tricky platform to learn on in my opinion.Again it's been close to 10 years or so since I've been involved in depth with things unlike most of the guys here so take this with a grain of salt.Surely some things have changed since then.One thing that hasnt changed is Basic is a very simple language to learn compared to others and with Propeller I can teach myself to rewrite something I did in Basic in the past and test it out on the same platform

[Aodhan145]

I understand if one is explaining that by only learning and utilizing for example the Arduino provided library such as Serial() without ever learning how the underlining USART hardware peripheral actually is programmed then that individuals learning of a specific microcontroller is not complete. But that is another argument all together.

Thats why I want to learn.

[Aodhan145]

Blinky Blinky

Code: [Select]

void setup() {
  DDRB |= (1 << PB5);
}

void loop() {
  PORTB = PORTB | (1 << PB5);
  _delay_ms(100);
  PORTB &= ~(1 << PB5);
  _delay_ms(100);
}

[zapta]

I understand if one is explaining that by only learning and utilizing for example the Arduino provided library such as Serial() without ever learning how the underlining USART hardware peripheral actually is programmed then that individuals learning of a specific microcontroller is not complete. But that is another argument all together.

Thats why I want to learn.

You can find here an example of direct digital i/o for Arduino. It works directly with the avr's registers. You can do the same for serial, timers and anything else. 

https://github.com/zapta/linbus/blob/master/analyzer/arduino/io_pins.h

Arduino does very little behind the setup() and loop().  Here is an example of an arduino program that uses it's own serial, timer and i/o.

https://github.com/zapta/linbus/blob/master/analyzer/arduino/arduino.ino

It's not all or nothing. Arduino gives you choices which is awesome.

I would start with blinking a LED without calling the arduino port setup and digital write.  As other said, the MCU datasheet is very important and you will need to spend time understanding the registers model, at least the ones you want to use. This will be the case with whatever MCU architecture you will chose and in general, AVR is easier to understand than ARM.

[Aodhan145]

I would start with blinking a LED without calling the arduino port setup and digital write.  As other said, the MCU datasheet is very important and you will need to spend time understanding the registers model, at least the ones you want to use. This will be the case with whatever MCU architecture you will chose and in general, AVR is easier to understand than ARM.

Look at my last post.

[rx8pilot]

I never spent any time with Arduino personally but some young engineers I hired showed me the environment. At the time, I had not yet designed anything with a microcontroller, but I was familiar with the basic block diagrams. From the beginning, I was intersted in developing commercial products so I elected to skip Arduino altogether and go straight to a 'pro' environment for AVR development.

Step 1: As other have already pointed out, learn the hardware and it's capability as much as practical. You cannot and should not bother memorizing the data sheet but it it very close, you will need to refer to it all the time. There are also many design considerations that of course require an understanding the hardware and electronics. Interfacing with A/D, de coupling caps, current sink capability, etc. To get started I found myself simply copying known good circuits from others and then figuring out why they work.

Step 2: Get Atmel Studio. It is intimidating at first since it is setup for professional development. It's not unlike using Photoshop to crop and image when you get started. There is a LOT of stuff that you will not need to know until you get further along.

Step 3: Get an overview of C language in general. Arduino is C like, but its not C so you may have to unlearn a few things. There are a million tutorials on the internet - some of them are specific to embedded programming and some are generic. C does not know the difference between a micro-controller and and other CPU.  One of the biggest differences is interrupts. This is a strange twist that will impact the approach to programming. Essentially, an interrupt is when some internal or external event needing immediate attention - it could be a button press or a timer running out. Whatever the cause of the interrupt, the main program goes on PAUSE and another program (interrupt service routine) is run, and then it goes back to the main program. Learn C, header files, bit shifting, learn the difference between a keyword and external function, bit shifting, bit shifting, and bit shifting.

Step 4: Don't kill yourself on steps 1-3 before you are able to get an LED to blink. The reason I suggest this it because getting an LED to blink means that you have the physical part setup and the software is able to connect to the programmer. Once you have that working, you can quickly run experiments as you learn something in the data sheet or in a C lesson. I would read a little, play a little and repeat. Reinforcing the lesson just learned.

Step: 5 Repeat 1-4 over and over.

Excellent resources, tutorials and discussions.
http://www.avrfreaks.net/

Gotta run for now....

While this is good advice I dont see any reason for someone who is looking to get away from Arduino to stay pigeon holed into Atmel.Maybe it's just me but there's tons of others out there that might make for a easier transition depending on his final goals.


For me personally,most everything that comes across my desk has a Motorola or one of it's derivatives in it.Hence why I am trying to go in that direction and why I've been lurking around for some time .Depending on goals there may be a better option than AVR.Also I've personally found that AVR is a tricky platform to learn on in my opinion.Again it's been close to 10 years or so since I've been involved in depth with things unlike most of the guys here so take this with a grain of salt.Surely some things have changed since then.One thing that hasnt changed is Basic is a very simple language to learn compared to others and with Propeller I can teach myself to rewrite something I did in Basic in the past and test it out on the same platform

Learning C with AVR is not pigeon holing at all. Its just a great place to learn the fundamentals that are common to almost all MCUs.  I have been able to work with PICs and TI with very little trouble.  The basics don't change much. While I started with Atmel, the last thing I wanted is to get stuck with them. With that said,  I  have not yet had a compelling reason to use the other options. My experience with PIC and TI is having to deal with established designs that needed and update. They all seem to have various strengths and weaknesses but my designs have yet to find such a limitation with Atmel AVR or XMEGA that I  needed to design with another manufacturer. I do feel totally comfortable that the skills I built learning the Atmel system gives me what is needed to succeed with any manufacturer out there. I have no allegiance to Atmel other than the time I have spent learning thier ways. Jumping ship is not a problem if PIC or whoever comes up with an awesome whiz bang option that Atmel does not have.

Software development skills and C coding skills will benefit anyone developing on any platform.

Yes, I understand that Arduino is C but the libraries abstract the power that lies beneath. I guess 'unlearning' is a poor term to use,  maybe digging deeper to understand what the library functions are actually doing. It is nice to be able to really understand the details. For example, I was told to use Peter Fleury library for i2c, but it could not deal with some of my requirements. I wrote my own implementation for i2c. It was a fairly steep learning curve but I was able to do something the library could not.



Sent from my SAMSUNG-SM-G890A using Tapatalk

[zapta]

Look at my last post.

Here you go!

BTW, in case you are not aware,  one very useful thing to learn is programming without delay(), that is, using state machines.

[rx8pilot]

BTW, in case you are not aware,  one very useful thing to learn is programming without delay(), that is, using state machines.

+1

[rx8pilot]

How much do they datasheets vary from AVR to AVR? I have a good couple of different chips. I don't have to change IDE/compiler do I?

Not much within the family. They are all very similar.

For me personally,most everything that comes across my desk has a Motorola or one of it's derivatives in it.Hence why I am trying to go in that direction and why I've been lurking around for some time .Depending on goals there may be a better option than AVR.Also I've personally found that AVR is a tricky platform to learn on in my opinion.Again it's been close to 10 years or so since I've been involved in depth with things unlike most of the guys here so take this with a grain of salt.Surely some things have changed since then.One thing that hasnt changed is Basic is a very simple language to learn compared to others and with Propeller I can teach myself to rewrite something I did in Basic in the past and test it out on the same platform

For the hobbyist, Motorola is pretty obscure. The Atmel range is huge - tons of options. Same with PICs. The advantage of these platforms is they are hugely supported in the hobby community as well as commercial applications. They are not very difficult either and learning C is a fundamental requirement of any embedded developer. It is a good idea to consider a path that has tons of free resources and you will not likely outgrow anytime soon. When my AVR designs outgrew the 8bit AVR, it was a piece of cake to move up to the the XMEGA for example. I have not designed with PICs but I have had to interface and program others designs, and the transition is not difficult at all after I learned C for embedded. Since I use AVR's everyday, I am partial to the system but only because its my comfort zone. The members of the avrfreaks forum have been very generous helping me though rough patches too.

[Rick Law]

Blinky Blinky

Code: [Select]

void setup() {
  DDRB |= (1 << PB5);
}

void loop() {
  PORTB = PORTB | (1 << PB5);
  _delay_ms(100);
  PORTB &= ~(1 << PB5);
  _delay_ms(100);
}

Aodhan145,

I too started with writing a few lines of "direct to MCU" code inside the Arduino IDE - to make PWM using the 16 bit timer so I can get 16 bit PWM.  But the rest of the MCU remained unknown to me for a while.  I am no expert, so I can understand how the task looks so overwhelming until you actually get started.  The trouble really is getting rolling: starting from no platform or tools - how to get a blank MCU to boot and see if it does...  After which, things kind of click.

So, beginner to beginner, here is how I got rolling (accidentally in my case):

I started messing around with the 18650 flashlights, I got one, and I hated the way the "driver" works.  I managed to do some hardware hacks and get it to work better, but still rather unsatisfactory.  I found that there is a driver out there (Nanjg 105c) using the ATTINY13a MCU and some folks out there have been rolling their own software for the ATTINY13A MCU on the Nanjg 105c.

0. Some time ago, I learned how to use the Arduino UNO to flash a virgin 328 chip on the breadboard with the Arduino UNO as the ISP programmer, so I know I have the tool to burn program onto a blank MCU.

1. So, I got a NINJG1105c driver ($3) a Cree (work alike) LED on aluminum base ($3), an SOIC clip ($4), to be experimented with using the Arduino as the ISP-programmer.

2. I connected the 105c to the LED, and use an adjustable PSU to simulate the battery.  Got the 105c running the LED, and got comfortable with how to control NANJG 105c with a push button (power cycle changes LED brightness - as with a flashlight's on/off clicking switch).

3. I down loaded WinAVR from source forge, and learn how to READ the flash/eeprom/fuse from the chip (ATTINY13a).  Now I know I have a hardware platform that talks from MCU all the way to the PC.

4. I downloaded some publicly available NANJG105c driver (nlite).  I have no intention of using it in my light, but I downloaded it onto the MCU and check that the 105c is now running the new firmware properly.  Now I know I have bi-directional connection to the ATTINY13a MCU.  It can accept programs I will write.  Hardware platform for software development is working.

5. I downloaded a mini-driver (bare bone) source example from a fellow "Dr. Jones."  Thanks to Dr. Jones, I know I have working source to figure out how to use WinAVR to compile.

6. Compiled and downloaded the mini.c and my LED is now controlled by a program I compiled.

7. Now I have all the tools to write a program, get it down to the MCU, actually see how that works.

8. I downloaded another publicly available more complex driver with source (from a fellow called Johnny C) showing how to "handle the stars".  (Stars are connection points if soldered to ground selects different options for the driver.  The ATTINY13a does "digitalRead" on them to setup the driver characteristics.  Learning to use the Star is to learn to do IO without the Arduino library.)

9. I use the publicly available source as reference and examples.  I wrote mine from the ground up using those available source (Dr. Jones' mini driver and Jonny C's Star and flashlight-off-timer programs).  Thanks to Dr. Jones and Jonny C, they helped me learn.

10. The WinAVR's make creates temporary files.  It shows the object code, the data...  That is another good source to see what is going on.

11.  Now I have the platform to read/write a virgin MCU with just what I wrote.  I also made a proto-board with SOIC pin header and DIP switches so my NANO on the protoboard now work as the ISP-programmer, and can be fully disconnected to the MCU (via 6 dip switches) with the SOIC clip still on.  I know I can program for any AVR with an ISP connector.

I just finished my "dream" driver (second version) fully my own code (and no Arduino library), got that into the Nanjg 105c, and the 105c into my flashlight.  Not much features, (to show level of complexity), the features are: 2 sets of selectable modes one with 4 different levels of brightness and the other with 6 levels, eeprom-write wear leveling, an auto-off when on full intensity to avoid overheating, and blink out the battery voltage on my command.  (3.5v battery will have 3 high intensity blinks followed by 5 low intensity blink)  Plus I use a Star (IO-read) to enable/disable to full-intensity timer so, software alone can't disable this safety feature.  Oh, I also learned to do the "analogRead" (ADC raw code to read) to time "how long has the light been turned off) by using another Star to ADC read how far a capacity bleed down.

With a working platform, learning can progress easily.  The flashlight driver is not an ideal platform but a working platform with everything necessary.  Writing a program that "select command by turning the MCU (flashlight) off" is kind of strange and requires some mind twisting.  After doing some mind adjustments, it works.

At this point, my only dependent on the Arduino is using it as an ISP-programmer.  I can as easily get any other AVR ISP flasher hardware and thus be completely independent from Arduino.

So now while I cannot claim I am a competent MCU programmer, I think I know the MCU a lot better now than before this project.  Now I have turned a bare MCU to a working MCU run a program I developed - freed from some bootloader/library others created.  I feel while I don't yet know most of the features of the MCU, I have a platform to experiment.  My next project will be replacing the TINY13a with the TINY85V.  1K of flash and 64 bytes of RAM on the 13A is limiting.  So I look forward to the arrival of my 85v to do more experiments with.

I hope you find this info helpful.

Rick

[Aodhan145]

Blinky Blinky

Code: [Select]

void setup() {
  DDRB |= (1 << PB5);
}

void loop() {
  PORTB = PORTB | (1 << PB5);
  _delay_ms(100);
  PORTB &= ~(1 << PB5);
  _delay_ms(100);
}

Aodhan145,

I too started with writing a few lines of "direct to MCU" code inside the Arduino IDE - to make PWM using the 16 bit timer so I can get 16 bit PWM.  But the rest of the MCU remained unknown to me for a while.  I am no expert, so I can understand how the task looks so overwhelming until you actually get started.  The trouble really is getting rolling: starting from no platform or tools - how to get a blank MCU to boot and see if it does...  After which, things kind of click.

So, beginner to beginner, here is how I got rolling (accidentally in my case):

I started messing around with the 18650 flashlights, I got one, and I hated the way the "driver" works.  I managed to do some hardware hacks and get it to work better, but still rather unsatisfactory.  I found that there is a driver out there (Nanjg 105c) using the ATTINY13a MCU and some folks out there have been rolling their own software for the ATTINY13A MCU on the Nanjg 105c.

0. Some time ago, I learned how to use the Arduino UNO to flash a virgin 328 chip on the breadboard with the Arduino UNO as the ISP programmer, so I know I have the tool to burn program onto a blank MCU.

1. So, I got a NINJG1105c driver ($3) a Cree (work alike) LED on aluminum base ($3), an SOIC clip ($4), to be experimented with using the Arduino as the ISP-programmer.

2. I connected the 105c to the LED, and use an adjustable PSU to simulate the battery.  Got the 105c running the LED, and got comfortable with how to control NANJG 105c with a push button (power cycle changes LED brightness - as with a flashlight's on/off clicking switch).

3. I down loaded WinAVR from source forge, and learn how to READ the flash/eeprom/fuse from the chip (ATTINY13a).  Now I know I have a hardware platform that talks from MCU all the way to the PC.

4. I downloaded some publicly available NANJG105c driver (nlite).  I have no intention of using it in my light, but I downloaded it onto the MCU and check that the 105c is now running the new firmware properly.  Now I know I have bi-directional connection to the ATTINY13a MCU.  It can accept programs I will write.  Hardware platform for software development is working.

5. I downloaded a mini-driver (bare bone) source example from a fellow "Dr. Jones."  Thanks to Dr. Jones, I know I have working source to figure out how to use WinAVR to compile.

6. Compiled and downloaded the mini.c and my LED is now controlled by a program I compiled.

7. Now I have all the tools to write a program, get it down to the MCU, actually see how that works.

8. I downloaded another publicly available more complex driver with source (from a fellow called Johnny C) showing how to "handle the stars".  (Stars are connection points if soldered to ground selects different options for the driver.  The ATTINY13a does "digitalRead" on them to setup the driver characteristics.  Learning to use the Star is to learn to do IO without the Arduino library.)

9. I use the publicly available source as reference and examples.  I wrote mine from the ground up using those available source (Dr. Jones' mini driver and Jonny C's Star and flashlight-off-timer programs).  Thanks to Dr. Jones and Jonny C, they helped me learn.

10. The WinAVR's make creates temporary files.  It shows the object code, the data...  That is another good source to see what is going on.

11.  Now I have the platform to read/write a virgin MCU with just what I wrote.  I also made a proto-board with SOIC pin header and DIP switches so my NANO on the protoboard now work as the ISP-programmer, and can be fully disconnected to the MCU (via 6 dip switches) with the SOIC clip still on.  I know I can program for any AVR with an ISP connector.

I just finished my "dream" driver (second version) fully my own code (and no Arduino library), got that into the Nanjg 105c, and the 105c into my flashlight.  Not much features, (to show level of complexity), the features are: 2 sets of selectable modes one with 4 different levels of brightness and the other with 6 levels, eeprom-write wear leveling, an auto-off when on full intensity to avoid overheating, and blink out the battery voltage on my command.  (3.5v battery will have 3 high intensity blinks followed by 5 low intensity blink)  Plus I use a Star (IO-read) to enable/disable to full-intensity timer so, software alone can't disable this safety feature.  Oh, I also learned to do the "analogRead" (ADC raw code to read) to time "how long has the light been turned off) by using another Star to ADC read how far a capacity bleed down.

With a working platform, learning can progress easily.  The flashlight driver is not an ideal platform but a working platform with everything necessary.  Writing a program that "select command by turning the MCU (flashlight) off" is kind of strange and requires some mind twisting.  After doing some mind adjustments, it works.

At this point, my only dependent on the Arduino is using it as an ISP-programmer.  I can as easily get any other AVR ISP flasher hardware and thus be completely independent from Arduino.

So now while I cannot claim I am a competent MCU programmer, I think I know the MCU a lot better now than before this project.  Now I have turned a bare MCU to a working MCU run a program I developed - freed from some bootloader/library others created.  I feel while I don't yet know most of the features of the MCU, I have a platform to experiment.  My next project will be replacing the TINY13a with the TINY85V.  1K of flash and 64 bytes of RAM on the 13A is limiting.  So I look forward to the arrival of my 85v to do more experiments with.

I hope you find this info helpful.

Rick

I have use an arduino as ISP and used winavr a couple of times mainly for burning fuses but I did write a hex file to an atmega1284p a while ago. I didnt write or compile the cope I just used avrdude to program it.

[Rick Law]

Blinky Blinky

Code: [Select]

void setup() {
  DDRB |= (1 << PB5);
}

void loop() {
  PORTB = PORTB | (1 << PB5);
  _delay_ms(100);
  PORTB &= ~(1 << PB5);
  _delay_ms(100);
}

Aodhan145,

I too started with writing a few lines of "direct to MCU" code inside the Arduino IDE - to make PWM using the 16 bit timer so I can get 16 bit PWM.  But the rest of the MCU remained unknown to me for a while.  I am no expert, so I can understand how the task looks so overwhelming until you actually get started.  The trouble really is getting rolling: starting from no platform or tools - how to get a blank MCU to boot and see if it does...  After which, things kind of click.

So, beginner to beginner, here is how I got rolling (accidentally in my case):

...
...

I have use an arduino as ISP and used winavr a couple of times mainly for burning fuses but I did write a hex file to an atmega1284p a while ago. I didnt write or compile the cope I just used avrdude to program it.

So, time to write a small program from outside Arduino...

Change your loop() into main(), and try to get it to compile using WinAVR, figure out how to compile (using WinAVR's mfile to get "make all" to work on your "something.c" file) and then figure out all the includes (.h files) you need to get it to compile.  The process of looking through the include for the missing stuff is very educational.

After you get it to compile and but before you flash your MCU with your blinky:
1. check by READING your MCU's flash for good connection to verify your set up can at least read.
2. then check by flashing the Optiboot hex (from Arduino) onto your MCU (which should then run the regular Arduino's led fader - fader so it is different then your blink) for proper flash writing.  Now you know your set up can read and write properly.
3. now the system is ready to test your newly minted blinky from your own c-code compiled by WinAVR.  Since you last ran the fader, if it now blinks instead of fades, it is gold - the world is yours.  You are freed from the Arduino library.
4. as you may know, be careful with the damn fuses - mistake there can brick your MCU.

AmyK's suggestion on reading the entire datasheet is a good one.  I scan through it (I am too impatient).  I then read through in detail for of the keywords I found in the include file I needed.   As much as my patience permits, when I run into a keyword PORTB or like _delay_ms(), I look at the Arduino's code to see how they did that.

With _delay_ms(), it was particularly helpful in my quest.  My program was too big.  Looking at the .lss file generated, I decided to write a csDelay(centi-second ie hundredth of second) just to learn.  In my application, it saved over 100 bytes.  For a system with 1K flash, that was huge.  (Damn, where is my ATTINY85 with 8K flash!!  I hope that plane with my package didn't crash - don't worry about saving the passengers, just grab my package...)

My eye-glasses work well for me too, but I am sure it likely wont help you.  So, I am keenly aware that what works for me may not work for you.  However, thought I will make my suggestion anyhow to see if you found it applicable.

I've learned making PWM, reading ADC, port IO...  Next on my queue to learn is interrupt.  I want to make my own centiSecondsSinceStart().  After that, I would feel I "got out of boot camp".

[rx8pilot]

This fellow on YouTube has done a very useful series on microcontrollers (using AVR's). I got a ton of mileage out if this one. Very well explained.

57 Videos
https://www.youtube.com/playlist?list=PLE72E4CFE73BD1DE1

[Landrew2390]

I've found this website to be useful for explaining basics of how specific pieces of AVR hardware work under the hood.  It's been a real eye opener and allowed me to bridge what I knew from the Arduino IDE into legitimate C++ code in AVR Studio.

http://maxembedded.com/category/microcontrollers-2/atmel-avr/

One other thing I've started doing is reading through the Arduino core libraries.  I still don't understand all of the code, but I can comprehend it enough to see how they perform each operation behind the scenes.  I then copy that into my current project in AVR studios and make it a function.  Because I did that, I now see that code every single time I proofread that program and it helps me memorize it faster.