ATmega8 resources (by Ziggy)
Hello Forum,
I have just last week tried to use this approach to solving a problem and I must admit it's not a bad way to tackle certain issues.
I hope to get some feedback/guidance on the issue of typical number of rungs versus memory limitations of an ATMega 8 processor.
I would imagine there would be certain memory overheads irrespective of ladder complexity. Is there a feel for this number is it does exist?
And finally in light of above questions just how practical is the ATmega8 micro when compared to larger ATMega16 and 32 micros?
Your opinions and experiences sought.
(no subject) (by Ziggy)
I compiled a blank ladder consisting of a single comment line into 688 bytes of hex code.
I then altered the size of the comment and on recompiling the ladder ended up with same size hex file.
I hope those who did not know appreciate the number.. and those who knew.. well there isn't much to be added.
(no subject) (by Jonathan Westhues)
What were you expecting? An empty program compiles to the runtime (i.e., the code to set up the processor and its peripherals, and then to run the user program repeatedly at the cycle period) and nothing else. That's around 256 bytes for the ATmega processors, so the IHEX file is a little more than twice that.
The text of the comment does not affect the generated code; that's the point of comments.
(no subject) (by Ziggy)
I expected some overhead but did not know just how much it would be.
The reason for compiling blank ladder was just so I could understand how much of the resource would be taken up in this fashion.
This is in no way a comment on quality of generated hex code, just an attempt to understand the application.
LDmicro is beyond my capabilities to comprehend at the moment.
(no subject) (by Jonathan Westhues)
A lot of the generated code is pretty bad, but the runtime is relatively tight (since that's mostly hand-coded assembly, of course).
If you look in avr.cpp, starting from CompileAvr(), then you can see where all that code gets generated.