AVR Studio memory vs. HEX file size using webbotlib

[mstacho]

A weird question perhaps:

I'm making a program using webbotlib.  AVR studio says the program is:

Device: atmega640

Program:   21088 bytes (32.2% Full)
(.text + .data + .bootloader)

Data:        623 bytes (7.6% Full)
(.data + .bss + .noinit)

So in theory I'm only using 21KB of the axon memory.  But the HEX file itself is 58KB, meaning I'm coming way up to the edge of my axon memory.  Which of the two is correct?  I'm only using one quadrature encoder, one PWM, and one PID, so I find it hard to believe I'm maxing out the axon...Does the *.hex file get dumped right into axon memory as is, or is it processed in some way beforehand?

MIKE

[waltr]

Most hex files for programming u-processors have the memory address on each line, check-sum and config bits it ASCII. So the hex file can be much larger than the code space it represents. Try opening the hex file in a text or binary editor to see what is really in the file.
The webbotlib's output of the program size should be true and trusted not the size of the hex file.

[mstacho]

That's great to know.  :-P I thought I'd run out of space before I get anything done!

Just out of curiosity, what does the hex file tell me?  I've opened it in notepad a few times, but it's all meaningless to me.  For instance, it begins like:

:100000000C9464020C9481020C9481020C94810281
:100010000C9481020C9481020C9481020C94810254
:100020000C9481020C94A1100C9479100C94511032
:100030000C9481020C94A6060C9480060C94FC0788

Where does the actual program start in those lines?

MIKE

[dmclifton]

Look at it not in notepad but in a hexadecimal editor.

[waltr]

The hex file is actually in ASCII that is interpreted by the programming tools.
The output you showed looks like the INTEL HEX format.
Check this:
http://en.wikipedia.org/wiki/Intel_HEX

Then you'll see how much of the file is code that goes into the u-processor's memory and remember that the file is in ASCII so that it that two ASCII characters for an 8bit byte.

[Webbot]

Yep - the hex file is in 'human readable' text format - so its much bigger than the space it actually takes on the device.
Trust the compiler output from your original post - that is the actual amount.

WebbotLib V2 tends to generate smaller, and faster, code

[Admin]

I'd be very shocked if you ran out of memory on the Axon.

This is the specs for my ERP using WebbotLib v1.29

Program:   28792 bytes (43.9% Full)
(.text + .data + .bootloader)

Data:       1429 bytes (17.4% Full)
(.data + .bss + .noinit)

[mstacho]

I'm pretty sure now that I won't run out of memory.  But here's the specs of the robot so you can see why I might be worried :-P

7 motors controlled by PWM

7 PD controllers + 3 adaptative laws for force control at the tip of multi-link fingers (:-P THIS one is going to be a doozy to do efficiently, but I'll worry about processing power later...)

7 quadrature encoders, one for each motor, with ~1300 pulses/revolution (I'm not even sure if the Axon has enough IO pins that can act as encoder interrupts, as is required by webbotlib?)

UART communication with the PC to receive instructions

(in theory) 150 tactile sensors, in 25-sensor arrays, each monitored by a PIC (probably) communicating with the axon through (again, probably) UART -- this one is in theory only, because the tactile sensors are still being worked out.  I may only be using 75 sensors on 3 chips, instead of 150 on 6 chips...

With all of that, it's possible that the axon will instead just act like a brain-stem, sending commands to PICs that are doing all the actual processing.  But I think it can handle it...

MIKE

[Admin]

You won't have any memory probs with this.

7 quadrature encoders, one for each motor, with ~1300 pulses/revolution (I'm not even sure if the Axon has enough IO pins that can act as encoder interrupts, as is required by webbotlib?)

Yeap, the Axon can do 7+
That is quite a lot though and may or may not cause scheduling issues. I'd say it's worth a try.

(in theory) 150 tactile sensors, in 25-sensor arrays, each monitored by a PIC (probably) communicating with the axon through (again, probably) UART -- this one is in theory only, because the tactile sensors are still being worked out.  I may only be using 75 sensors on 3 chips, instead of 150 on 6 chips...

You can use multiplexers for this and connect it directly to the Axon, no prob. With a 16 bit multiplexer, and 16 ADC channels on the Axon, using only 4 control pins, that'll give you 256 different sensors you can connect to.

This is what I'm using on a project of mine:
http://www.sparkfun.com/products/9056

I can send you the code if you want.

[mstacho]

I do intend to use multiplexers.  I'm using a chip that I can't recall its name right now -- it's in the lab and I'm at home.  But please do send me the code, that'd be great to see.  I figure your chip and mine have enough similarities to get me started, since I haven't yet tried to integrate the sensors.


As for the 7 encoders...yes, that's something of an issue at the moment.  I may end up putting at least one of them under PIC control to avoid the scheduling bottlenecks, but I'll try the axon first and see what happens.

(WARNING: What follows is intensely nerdy and deals with the inner workings of tactile systems.  To prevent boredom, I advise against reading it.  But if you're as fascinated by this stuff as I am, read on!  )

I know that the axon can handle the processing load of the chips under a multiplexer.  But the idea behind the PICs is a bit different: Our tactile system (that is...a human's tactile system :-P ) has a lot of in-situ processing to reduce the amount of information being processed at the higher levels (this is why you don't usually feel your clothes until you think about it...).  The reason behind this is that it's often irrelevant to detect just exactly what the texture of the stove burner is when the real thing you should be doing is getting your hand off the hot stove.  While at the same time, we learn a lot through touch.  So the amount of information has to be regulated so that during important, fast events, we aren't bogging down with tons of information, and during slower, learning-style events, we have access to the full range of our senses.

The PICs will form the first level of processing.  They will monitor what the hand is doing, and what the tactile system is sensing.  If we're in the middle of a grasping operation where it's possible that the object can slip, they'll only feed through the most relevant sensors and the slip detection and correction will be handled by a reactive system.  If the hand is learning texture or shape of an object for later reference, they'll open up the reducing valves and send all the tactile information up to the PC (through the axon), at the expense of a lot more processing being required.  Similarly, the PICs will constantly query all the sensors in each sensor chip -- only the sensor that has appreciably changed will be updated. 

But since the axon will have its hands full with encoders, PC-to-Control communications, PWM and so on, the PICs form the lowest level of processing.  They'll probably be 8 pin PICs with the minimal amount of processing power, just acting as watchdogs and control valves for information.

[left behind in tech]

Nerdy or not, it's cool to be able to do this stuff. I just wish I had continued with the my training after getting out of High School 31 years ago! Now I am back into working with Electronic stuff and man am I behind. I find all this stuff keeping me up all night and loosing sleep, this doesn't help the ability to think and remember. Anyway I have the code for one of the UV photo exposure projects which was originally done with a PIC, but the guy that posted this one has changed the PIC out for an ATmege 8 and all the necessary re-connections done, I have the code in hex file, which I still don't understand yet, I am wanting to know if and how this file gets rewritten by the PC using AVR studio, or which program is needed to do this. The code is about 2 pages of numbers and letters and stuff. The other thing I was wondering is can this code be run through the Computer to an Arduino Uno on a breadboard into the Atmega 8 or am I going to have to buy and STK600 and learn how to use that one too! I haven't gotten any manuals for this stuff yet but I know I am going to have to soon and so far all the online tutorials I have been taking in are not helping that much yet. As a last resort is anyone interested in loading the file I have into an Atmega 8 and sending me a loaded processor ? At least with that I could get the Box up and working so I can go on with making the control circuits I am doing for someone else. That way I could finish that job and then have more time to spend learning the software stuff , I do fine with the hardware stuff but doing both is too much for now.

[mstacho]

Unless you're REALLY bored one day, I don't recommend trying to read the HEX file to understand it :-P They are made for the computer to understand, and from my reading include things like memory addressing, gotos and so on that you'd have to be a compiler writer to really get anyway.  Remember: your code is written in C, then it gets turned into HEX.  Going backwards is...hard to do, and is a form of reverse engineering (which is...hard to do haha).

Although this is a guess, it's also probably easier to just get a breakout board of some kind for the ATMega8, instead of tossing it through the Arduino, although my *guess* is that it's possible?  Anyone?

MIKE

[Webbot]

The HEX file contains all the compiled program but if the HEX you have is for a PIC then its using the PIC instruction set and will assume various devices are connected to certain pins on the PIC. So you can't just load it onto an AVR (as it speaks a completely different compiled program instruction set).

What you really need is the code because then you can pass it through the AVR compiled to generate an AVR hex file. Of course you will still need to change the C program because it if uses various pins or more complex stuff like PWM then the registers your C code needs to deal with will be completely different.

Its a bit like saying "I already have an assembled Ducati motorbike - can you just take it apart and put it back to together as a Maserati car" !!  Both are vehicles but they have different engines, different wheels etc. At least if you have the C code then you have access to the 'assembly line' !

[hopslink]

The way I read your post I take it you have a .hex file for the ATMega8...

...can this code be run through the Computer to an Arduino Uno on a breadboard into the Atmega 8...

...my *guess* is that it's possible?  Anyone?

It is simple enough using any of the older FTDI based Arduinos as an ISP programmer. Though it is suggested that the Uno doesn't work people have been reporting success so it is worth a try.

The Arduino page only covers burning a Bootloader via the Arduino IDE. Follow the link back to the Mega-isp page and there is a brief guide on uploading .hex files using AVRDude. I have used this setup several times, but never with an Arduino Uno.

[kl22]

A weird question perhaps:

I'm making a program using webbotlib.  AVR studio says the program is:

Device: atmega640

Program:   21088 bytes (32.2% Full)
(.text + .data + .bootloader)

Data:        623 bytes (7.6% Full)
(.data + .bss + .noinit)

So in theory I'm only using 21KB of the axon memory.  But the HEX file itself is 58KB, meaning I'm coming way up to the edge of my axon memory.  Which of the two is correct?  I'm only using one quadrature encoder, one PWM, and one PID, so I find it hard to believe I'm maxing out the axon...Does the *.hex file get dumped right into axon memory as is, or is it processed in some way beforehand?

MIKE

I've been doing some development for a uploader for the Axon, and I came up with some accurate calculations to see how much information each .hex file requires on the MCU/how much bytes get uploaded. Only the actual hex data gets pushed onto the Axon.

There are two ways of doing it:

1. ([Windows file size] - [(totalLine-1) * 13] - 11)/2
 
*13 is to remove, the ":", the byte count, address, record type, CRC and newline characters. -11 is to remove the the line ":00000001FF". /2 because ASCII uses 1 byte to represent each digit hex, so 2 ASCII characters actually represent 1byte.

ex. (43,748 - (974-1)*13)/2 = 15544bytes

or

2. Look at the last line of the .hex file right before the ":00000001FF" line. Take the first two hex values (byte count), ex. 02, add it to the next 4 hex values (address), ex. 3CB6, so you get 3CB8. = 15544bytes.


Both methods should give you the same answer. The values used in the example above are from an actual .hex file I had.

Looking at the bootloader .hex,
it contains 2 + (FFFE - FC00) + 2 = 1026 bytes

So in total for my program I should be using up around 17kb. And most of the 15544bytes is not even what I wrote, I wrote like 4 lines. And the full available user flash on the Axon is 64512bytes. So you got ALOT of coding to do, to fill that up.


(please correct me if I'm wrong )