AVR Assembler article
-
Does this subject appeal to the masses here?, and would anyone be interested in it? I have it on my site and it gets a lot of hits but don't know if it would be an interesting addition here.
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
-
count me up as interested :)
Done! AVR Assembler 101[^]
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
-
It's hard to get people to change I've been in a couple of positions where I've pushed C++ even to the point of writing a framework, giving classes and such but they were set in there ways and I finally just did my own thing and left them to there's. I'm using the ATMega1280 and ATMega2560 boards for my C++ projects and the have 128K and 256K flash memory respectively so there's no "limited memory" excuse and since C++ runs just about as fast as C that shouldn't be a problem. The IDE has finally started to support it and I've been writing a lot of libraries in C++.
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
Mike Hankey wrote:
I'm using the ATMega1280 and ATMega2560 boards for my C++ projects and the have 128K and 256K flash memory respectively so there's no "limited memory" excuse and since C++ runs just about as fast as C that shouldn't be a problem. The IDE has finally started to support it and I've been writing a lot of libraries in C++.
The "memory problem" rather lies in the fact that even on a Mega2560, you still have only 8KB of RAM. So you have to still be fairly conscious about any dynamic memory allocation (avoid virtual methods at all cost) on top of the fact that AVR MCUs are prone to lock up on heavy memory fragmentation... And the Arduino IDE was always using C++, the "sketch" that you write is nothing more than an include file for a main() file wrapper and the "Arduino language" isn't actually more than using methods of the default libraries (which in turn are written in C++). After all, the compiler underneath is nothing more than a AVR targeted GCC (ok, there's now a ARM option to support the Due and Intel has their own version of the IDE to support the x86 in their Galileo board). Ralf ;)
-
Mike Hankey wrote:
I'm using the ATMega1280 and ATMega2560 boards for my C++ projects and the have 128K and 256K flash memory respectively so there's no "limited memory" excuse and since C++ runs just about as fast as C that shouldn't be a problem. The IDE has finally started to support it and I've been writing a lot of libraries in C++.
The "memory problem" rather lies in the fact that even on a Mega2560, you still have only 8KB of RAM. So you have to still be fairly conscious about any dynamic memory allocation (avoid virtual methods at all cost) on top of the fact that AVR MCUs are prone to lock up on heavy memory fragmentation... And the Arduino IDE was always using C++, the "sketch" that you write is nothing more than an include file for a main() file wrapper and the "Arduino language" isn't actually more than using methods of the default libraries (which in turn are written in C++). After all, the compiler underneath is nothing more than a AVR targeted GCC (ok, there's now a ARM option to support the Due and Intel has their own version of the IDE to support the x86 in their Galileo board). Ralf ;)
Bitbeisser wrote:
The "memory problem" rather lies in the fact that even on a Mega2560, you still have only 8KB of RAM
Agreed but that is always a consideration no matter what language you are using.
Bitbeisser wrote:
(avoid virtual methods at all cost)
Why? It just uses a virtual table right? I tend to stay away from doing to much dynamic allocation because as you say memory does get fragmented easily and the memory management sucks.
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
-
Bitbeisser wrote:
The "memory problem" rather lies in the fact that even on a Mega2560, you still have only 8KB of RAM
Agreed but that is always a consideration no matter what language you are using.
Bitbeisser wrote:
(avoid virtual methods at all cost)
Why? It just uses a virtual table right? I tend to stay away from doing to much dynamic allocation because as you say memory does get fragmented easily and the memory management sucks.
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
Mike Hankey wrote:
Bitbeisser wrote:
The "memory problem" rather lies in the fact that even on a Mega2560, you still have only 8KB of RAM
Agreed but that is always a consideration no matter what language you are using.
But with C++ and the craze of a lot of people to inherit the heck out of it, it is much more likely becoming a problem as it isn't as obvious how much RAM a certain object/method is using...
Mike Hankey wrote:
Bitbeisser wrote:
(avoid virtual methods at all cost)
Why? It just uses a virtual table right?
Correct. And where do you think those VMTs are created? Ralf
-
Mike Hankey wrote:
Bitbeisser wrote:
The "memory problem" rather lies in the fact that even on a Mega2560, you still have only 8KB of RAM
Agreed but that is always a consideration no matter what language you are using.
But with C++ and the craze of a lot of people to inherit the heck out of it, it is much more likely becoming a problem as it isn't as obvious how much RAM a certain object/method is using...
Mike Hankey wrote:
Bitbeisser wrote:
(avoid virtual methods at all cost)
Why? It just uses a virtual table right?
Correct. And where do you think those VMTs are created? Ralf
I guess my point is in my Init method I create say an CSpi object and use it for the lifetime of the run I don't create and destroy every time I use it. I agree when you're working with limited resources of any kind you need to be conscious of what you're doing but I believe the price is worth it for the extra benefit gained from C++. I believe we're saying the same thing!
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
-
Does this subject appeal to the masses here?, and would anyone be interested in it? I have it on my site and it gets a lot of hits but don't know if it would be an interesting addition here.
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
-
As a 'hobbyist' (and one who is not at all insulted by the term) I love assembly language. It is fascinating to see how computers work on a more fundamental level. I would like to see more articles on assembly language - any instruction set.
I love assembly language also, it has a kind of elegance to it. I don't use it as much as I use to but at least I know how. Over the years it has allowed me to get very close to the hardware I was on.
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
-
Done! AVR Assembler 101[^]
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
thank you
-
Should be similar. Published it about 1-2 hours ago! AVR Assembler 101[^]
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
-
Cool let me know what you think! Enjoy!
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
-
Bitbeisser wrote:
The "memory problem" rather lies in the fact that even on a Mega2560, you still have only 8KB of RAM
Agreed but that is always a consideration no matter what language you are using.
Bitbeisser wrote:
(avoid virtual methods at all cost)
Why? It just uses a virtual table right? I tend to stay away from doing to much dynamic allocation because as you say memory does get fragmented easily and the memory management sucks.
VS2010/Atmel Studio 6.1 ToDo Manager Extension Relax...We're all crazy it's not a competition!
Bitbeisser wrote:
(avoid virtual methods at all cost)
Why? It just uses a virtual table right?
That is the point, those VT are using up (a lot!) of the valuable RAM space... Ralf
