Post by David Murray on Dec 28, 2007 10:27:24 GMT -5
After looking at a few tutorials I see that I can program the ATMega32 in C++ or Assembly.
The problem with C++ is I've forgotten how to use it. About 10 years ago I used to be a wizard with it under Linux, but literally haven't used it it 10 years and I couldn't even remember how to do the simplest thing. I'll have to go read some C tutorials and see if it comes flooding back to me.
The problem with Assmebler is that I am only really familiar with the 6502 instruction set. About 15 years ago I did some 8086 code, but I've totally forgotten all of that. From the sample code I've looked at, it isn't much like Commodore assmebler.
I've noticed a lot of the code out there appears to be written in assembly. But what are the main advantages and disadvantages here? When programming C++ on the PC, the resulting file is usually a lot larger due to a runtime module or something being included. Will this be the case on a microcontroller too? I have 32K to mess with, but that could get used up pretty quickly.
Is it possible to merge the two? Back in the days of DOS, I used to write code in PASCAL (yes, I've forgotten how to use that too!) and for certain subroutines that needed more speed, I would write assembler code right in the middle of the PASCAL code and the compiler would happy assemble it for me. Can I write C++ and Assembler in the same code on the ATMega?
There's a C++ wrapper for the all the standard routines in AVRlibc but C++ is inherently more complex and memory-hungry, so C is the norm.
C being a lower-level language fits well with controllers, too. There really is a lot of C code for the AVR out there. You can use arrays, etc. as you remember from your C days.
There are tricky things about memory management and AVRGCC. Most important is that string constants also use an equal amount of RAM! But there are work-arounds for this.... You may never encounter it, but if you're integrating an LCD display, you might...
Yes, you can integrate assembly into your C code with AVRGCC, just as with GCC on an Intel or AMD microprocessor. I've never done it, as it's never been necessary for my projects.
AVRGCC programs compile into pretty darn small sizes--I've written some that seem pretty complex to me, yet the most ROM I've ever used has been about 2000 bytes. The compiler optimizes by default, too (you can control that feature.)
Using C functions like printf() will incur extra memory overhead, however. They require more memory for the libc library...
Post by iamdenteddisk on May 5, 2008 18:08:35 GMT -5
The better choice is allways assembler ,the following is why,portability heres the thing all cpus work from mL "machine language which is a list of %binary,$hex numbers these list come in a few different flavors depending on platform and if you got any asm support manuals,helplines,buddy in counter sales you can get the answer to the following question- what command structure dose my cpu use? the answer will come in the following formats 1-opcode,opperand1 2-opcode,operand1,flag1 3-opcode,operand1,flag2 4-opcode,operand1,operand2 5-opcode,operand1,operand2,flag1 6-opcode,operand1,operand2,flag1,flag2 these are machine language structures there are more of these but for the most part you will understand my point . depending on bit count ,meaning byte/word size the opcode is usually a byte long meaning binary number of digits for some four or eight 16,32,64,128 this means if you got 8 bit 0000:0000 now if we turn all bits on 1111:1111 this is maximum opcode dont plug this in as usualy half is all you get the rest is illegal usualy the vallue is 0-255,these are known as Equates or equ.. these equates are assembly commands ld=load or mov=move so on... opperands this is usualy a register name or memory location agian equated to a list 0-255. the instruction lda =load acumulator is opcode,operand
flag1=where to put the result of our opperation. flag2=where in memory to read our next instruction. now with this information we can make sense of 0000:0000:0000:0000:0000:0000 if we know what the equates are the command set is the opcode list the opperands are a list of all known registers&memory locations "sometimes symbolic" the flags are memory locations and can be from 0 to max byte size "sometimes symbolic"
To access other memory wich is grater than byte size it is paged so we can read it a page at a time,
All other languages compile into ML . so if you know ml you can write any software the machine is capable of on any machine and you only need to know limmits like byte size,commandset,memorymap Now that said ASM "assembly" is the closest language to ML it only has to convert the input to its equate no calculation is done, so it is the fastest in compile,execution. the only reason we have other languages is object orientation ,meaning we can use larger calculations than we have registers to store the string containing the calculations. how is this done ,by ganging the registers this still is ML but what it actualy dose is redefine our comand structure meaning all bytes in a line are an "object" the first section of the byte is the handle all following sections are memory locations and each location ends with a flag wich is the rest of the original command structure. I think I put this out there well,im hopeing it is correct as it isnt from a book but the calculator god gave me,so it is programming as I understand it. I dont know if it answer's your question dirrectly as it was a rant but readers will appreciate it im sure..email@example.com
Post by iamdenteddisk on May 5, 2008 18:37:14 GMT -5
want a better brain definition of c or your favorite scripting language, they are all self restructuring assembler's meaning they translate or interpret the commandline structure. hows that for a java,html programming manual. why is scripting languages slower ,because each line must be restructured before it can be assembled then it is actualy compiled. I learned this from qbasic oddly enough .