AVR Freaks

The ATmega16 has 1K SRAM,

50 x 50 = 2500

You probably run into problems of clobbering the stack.

Edit: 17 x 50 = 850, Hmmm...

It would be nice to see the real code not what the OP thinks they have written.

Now learn how to use the Code tags, <> on the formatting toolbar, to preserve formatting.  Flush-left code is too hard to read.

Posting the program is indeed a good thing.  But -- have you heeded what was said about using too much SRAM on the stack, and overflowing the stack area?

Just that line alone is 5000 bytes!  You cannot put ten pounds of stuff into a five pound box.

No Paul. An array as a parameter to a function is passed as a pointer to the array. The array itself is not pushed onto the stack.

Worse. It's actually two bytes if using avr-gcc (which the code kind-of suggests), so roughly 5000 bytes as theusch says (let's not nitpick.. ;-)

@sunny:

Now, if you actually need about 49*49 bits, then that's 4802 bits. Divide by 8 and you need 601 bytes (rounding up from 600.25).

The ATmega16 has 1K bytes of RAM so if you do not allocate too much memory elsewhere you'll be fine with storing your data in single bits. It will take extra coding to pack and unpack the data, but it should be doable.

You definitively can not have several such large data structures allocated at the same time because then you'd end up using more than the 1K bytes of RAM the ATmega16 has.

Remember that in addition to your variables consuming RAM you also meed to have some to spare for holding return addresses during function calls.

No, OP will not get that error.  OP has all of his arrays as local/automatic data (on the stack) and not global.

Just to say that website I linked to was just one of many hits for "C indent online" so there could well be better ones (like allowing OTBS to be selected etc.)

I dunno if "astyle" is better than "indent". The general magic words seem to be "code beautifier" and there are quite a lot of them. (A "decent" IDE will have something similar already build in).

https://duckduckgo.com/html?q=co...

Gee, 20 posts (well 21 now) and only 2 from the OP?

Let's give him time to respond...

You can't get a quart into a pint pot. 1K is what that micro has. Either that's enough or it isn't. When you did the original project design one of the things you should have done is a "memory budget" and that would aid in the selection of the correct micro for the job. On the whole AVRs tend to have 1/16th as much RAM as flash (presumably as a result of silicon area) so maybe consider trading up to a larger device? The ultimate AVR (for RAM) is the mega1284.
.
But as suggested above consider whether you need "int". On AVR "int" are 16 bit so "int graph[49][49]" is 49*49*2 bytes. Do you really need 2 bytes for each element? In fact, because you are only storing 0 or 1 you can get the stat of 8 elements into 1 byte (as Lee said) so you can reduce that array to 49*49/8 bytes.
.
It does look like you are more used to PC programming where you can just use "int" for everything and the number available are almost infinite. Microcontrollers are not like this. You have to think about the very limited resources and weigh up the use of every bit and byte and keep a "memory budget" so you know your worst case RAM usage at any moment.

The bottom line is that you cannot have a 49x49 matrix in a mega16. End of story.

49 x 49 = 2401. The mega16 only has 1024 bytes of RAM. It will not fit.

You have made the classic mistake of choosing your chip before doing any work on your problem and now you are stuck.

You have two choices...

1) Use a chip with more RAM (I'd suggest a mega1284) or

2) Use a smaller matrix

...your choice.

There might be a third choice but that requires a careful analysis of your code so that you work with just a small number of rows or a small number of columns at a time but as you haven't provided any comments as to what it does, or how it does it, then it's going to take someone with time on their hands to help you on that.

So it is. In that case he's even further up the creek with no means of propulsion.

Edit:

@sunny28:

Just what are you needing to do with this array?

As others have mentioned, the more information you give us the better we may be able to help.

Wasn't there some talk and analysis earlier that talked about OP only using one bit of each array element?  So...

...OP can use/invent some kind of packed bit arry, and sacrifice some cycles and code space .

What are you basing that conclusion on?

It seem clear that the OP needs an array of 49 x 49 bits. That is 49*49/8 bytes, which sums up to 301 bytes.

Lets make things relatively simple here and say that we store a row of 49 bits in an array of 7 bytes. (We'll accept a loss of 7 bits per row.)

Then take 49 such rows and store in an array. Now we have 7 * 49 bytes consumed. I.e. 343 bytes. Well under the capacity of an ATmega16.

Now for the access. Let's think.. When the op accesses elements of his array of bytes he does so with by using the C indexing operator, e.g. array[i][j]. We want to do something similar but getting and setting individual bits using those indices. So.. We need two functions:

void setbit(uint8_t array[7][49], int i, int j, uint8_t value);

uint8_t getbit(uint8_t array[7][49], int i, int j);

I am using the data type uint8_t for values to get or set, but only the lowest bit of those will actually be used.

I could leave it to "the interested reader" to write those two functions, but I'll be nice and sketch them here. I have not actually tested them. There might be minor mistakes or spelling errors, but the principle should hold. You need to be familiar with bitwise operations to follow along here!

void setbit(uint8_t array[7][49], int i, int j, uint8_t value)
{
   // Calculate which byte in the row bit i is​
   int theByteIndex = i / 8;

   // Calculate which bit in that byte the desired bit is in
   int theBitNumber = i % 8;

   // Set the bit
   if (value & 1)
   {
       // Set the bit (set to 1)
       array[theByteIndex][j] = array[theByteIndex][j] | (1<<theBitNumber);
   }
   else
   {
       // Clear the bit (set to zero)
       array[theByteIndex][j] = array[theByteIndex][j] & ~(1<<theBitNumber);
   }
      
   // We're done!
}

uint8_t getbit(uint8_t array[7][49], int i, int j)
{
   // Calculate which byte in the row bit i is​
   int theByteIndex = i / 8;

   // Get that byte
   uint8_t theByte = array[theByteIndex][j];

   // Calculate which bit in that byte the desired bit is in
   int theBitNumber = i % 8;

   // Get the bit (isolate it and shift it so that it is in bit position zero)
   uint8_t theBit = (thebyte & (1<<theBitNumber)) >> theBitNumber;

   // We're done!
   return theBit;
    
}

I'll leave the usage to "the interested reader" for now. ;-)

The above functions are not in any way "perfect". E.g. I might break out the calculation of theByteIndex and theBitNumber into separate (inlined) functions.

Yes, some extra code is needed, but the extra flash consumption is negligible. Whether the added execution time will matter "depends"..

Conclusion: If the language itself does not offer a specific functionality you can often supply it yourself. (After all, this is what writing computer programs is all about..)

Snide remark: Now, if we where coding in C++ we could actually get rid of thew somewhat awkward syntax that is needed to use these functions. Since C++ supports operator overloading we could implement a nice class to hols the data structure and overload the indexing operator. Such a solution should, certainly in principle and probably in practice, add no overhead as compared to the above C functions. And it would be a much cleaner interface to the data structure.

So, the_real_seebs, its certainly is physically possible to do what the OP wants.

Oops!
I m late

I was beautifying my code!
anyway I hope useful
Cheers

More things that are less than stellar in my functions:

• I have array dimensions literally coded in many places. Ugly. They should, at least, be #defined symbols.
• I'd probably typedef the two-dimensional array.
• The functions I wrote should be inlined.
• My code requires the "set value" to actually have the significant bit in position zero. m.majids solution relaxes this and thus he can code a somewhat slimmer solution. Which approach to take here again "depends"..

and probably more...

But the principle of our two solutions hold!

Keep in mind that the OP has only said that the code they posted was "approximated". We have been given no indication as to what they actually want to do.

Besides, we are only at post #41 and still none the wiser. Plenty of posts to go.