not entering for loop

Go To Last Post
42 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hello all there!!

Im working with atmega 16 controller, in my algorithm it is not executing for loop properly for the given condition.

example  

for(i=0; i<49; i++)

{

 

for(j=0; j<49; j++)

   graph[i][j] = 0; 

 

}

in this code it is stopping at i=17 or at any value instead it should complete till 49 and come out of the loop.  

what all may be the probable reasons for that?

is there any problem regarding clock, that the clock of controller is moving fast and it is skipping the instructions?

help me..

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Sunny, welcome.

 

1). Use code tags for posting code. It's the "<" ">" icon above.

2). Show us your declaration of graph[][].

 

My guess is it's to small and you are writing outside the array.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ATmega16 has 1K SRAM,

50 x 50 = 2500

You probably run into problems of clobbering the stack.

 

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

David

Last Edited: Wed. Jan 31, 2018 - 07:36 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frog_jr wrote:
Edit: 17 x 50 = 850, Hmmm...
And that's under the assumbtion he uses single byte variables...

Beginners are not unlikely to use int, which would double the size.

 

@OP:

Tell us a bit more about what you want to do.

We may be able to help in unexpected ways.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Wed. Jan 31, 2018 - 07:40 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
Beginners are not unlikely to use int, which would double the size.
True. However, without knowing what else is already occupying the SRAM (strings, variables, etc.), it is hard to say exactly why it fails at that point.

David

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

frog_jr wrote:
However, without knowing what else...

OP -- post a complete test program that demonstrates the symptoms, along with the standard checklist:

 

-- AVR model, clock speed Vcc level

-- Language, toolchain, version, optimizati8on level and other settings

-- Schematic

-- Tell how you are testing; tell what you expect to happen; tell what >>is<< happening.

 

[that said, I will agree about the speculation on runaway operations, in terms of SRAM usage.  cannot put ten pounds of stuff into a five pound box]

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

so here is my approximated code with which im are working.

<"

  #define F_CPU 7372800

  

  #include <avr/io.h>

  #include <avr/interrupt.h>

  #include <util/delay.h>

 

  #define Ver 49

 

  

int *q;

 

  int my( int graph[Ver][Ver],int s, int t,int o)

  {

  int queue[49],temp_ans[49],ans[49],d,a;

  int front=-1,i,u,v,x,k;

  int distance[49];

  int color[49];

  int rear=-1;

  int parent[49];

    

  for(k=0;k<=48;k++)

  {

  parent[k]=-1;

  distance[k]=0;;

  color[k]=1;

  ans[k]=50;

  

  }

  

  color[s]=0;

  distance[s]=0;

  queue[++rear]=s;

  front++;

  while(front!=rear+1)    

  {

  u=queue[front];

  if(u==o)

  {

  front++;

  color[u]=-1;

  continue;

  }

  

  for(i=0;i<49;i++)

  {

  v=graph[u][i];

  if(v==1)

  {

  if(color[i]==1)

  {

  color[i]=0;

  distance[i]=distance[u]+1;

  parent[i]=u;

  queue[++rear]=i;

 

  }

  }

  }

  

  front++;

  color[u]=-1;

  }

  

  x=0;

  i=f;

  while(parent[i]!=-1)         

  {

  temp_ans[x++]=i;

  i=parent[i];

  }

  

  temp_ans[x]=s;

  i=0;

  while(x!=0)                 

  ans[i++]=temp_ans[x--];

  

  ans[i]=temp_ans[0];

  

 

  if(ans[0]==45)

  {

  d=1;

  

  }

 

  

  

  return ans[a-1];   

 

  }

 

  int main(void)

  {

  

  

  int dest=31,ob=38,p=45,i,j;

  int graph[49][49];

  

  /*initialize every element of matrix as 0*/

  

  for(i=0; i<49; i++)

  {

  

  for(j=0; j<49; j++)

  {

  

  graph[i][j] = 0;

  }

  

  }

  /* create 7*7 matrix ,each edge have weight 1 */

  j=0;

  while(j<49)

  {

  

  if(j < 42)

  {

  graph[j][j+7] = 1;

  }

  

  if(j > 6)

  {

  graph[j][j-7] = 1;

  }

  

  if(j%7 != 0)

  {

  graph[j][j-1] = 1;

  }

  if(j%7 != 6)

  {

  graph[j][j+1] = 1;

  }

  j++;

  }

  

   

   

   p=my(graph,p,dest,ob);

   

   

 

  

  }

">

 

im using atmega 16 controller. actually this  algorithm gives me random array of numbers between 0 to 48. the problem is that the execution stops in middle of for loop unexpectedly. or sometimes it does not comes out of the for loop. and while loop also. i tried with all optimization levels but no solution

help please..

thankyou    

Last Edited: Fri. Feb 2, 2018 - 07:34 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

 

sunny28 wrote:
int graph[49][49];

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

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


In my post #2 I asked you to use code tags. the icon with the picture of < > just above the editor window.

 

Frog_jr already gave the answer to your problem in #3.

your array graph[][] is too big:

  int graph[49][49];

It does not fit in the memory of a atmega16.

This is very important !!!

If you use too much memory your program can NEVER work.

 

Why are you using integers?

 

Each integer has a size of 2 bytes, but you only seem to be using a single bit of each integer.


Edit 1). Typo, ints are of course 2 bytes on AVR.

Edit 2).  Removed total brainfart. Data is created on the stack if it is declared inside a function. Duh!

(Tnx, Johan)

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Fri. Feb 2, 2018 - 09:11 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
And on top of that you also declare a second array on the stack.

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.

 


 

Paulvdh wrote:
Each integer has a size of 1 bytes

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Fri. Feb 2, 2018 - 08:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Also, @sunny:

 

Are you using Atmel Studio? If so, what version?

 

I ran a small test, defining a global two-dimensional array (49 x 49) of int. I get a failed build with a quite clear error message:

 

sunny28(0,0): error: 		Program Memory Usage 	:	174 bytes   1,1 % Full
				Data Memory Usage 	:	4802 bytes   468,9 % Full	(Memory Overflow)

 

I'm using Atmel Studio version 7.0.1417 .

 

Did you not get a failed build and that error?

 


Footnote: This is my minimal test program, provoking the memory allocation:

#include <avr/io.h>

#define ARRAY_SIZE 49

void foo(int bar[ARRAY_SIZE][ARRAY_SIZE]) {
	for (int i = 0; i < ARRAY_SIZE; i++) {
		for (int j = 0; j < ARRAY_SIZE; j++) {
			PORTD = bar[i][j];
		}
	}
}

int array[ARRAY_SIZE][ARRAY_SIZE];

int main(void)
{
	foo(array);	
}

The "trick" with outputting the array contents is one (of several) ways to make sure the array and the whole function call is not thrown out by the optimizer as "meaningless code".

 

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Fri. Feb 2, 2018 - 09:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
Did you not get a failed build and that error?

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

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
OP has all of his arrays as local/automatic data (on the stack) and not global.

Yeah.

 

I must do more practice on reading flush-left code...

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
I must do more practice on reading flush-left code...
Copy paste in an IDE with decent formatting capabilities?

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah..

 

Or use the website that Cliff used the other day.

 

Or use the indent command in my Linux Mint.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or use the indent command in my Linux Mint.

It would be even better to use astyle (does improve c++ ; ident does not).

Both can be installed in Debian derived (Mint is somewhat, directly or indirectly) by apt-get install astyle indent

(or by source compiling; are short)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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...

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

astyle is better for cpp beautifying (best way is to try both : I gave the command line for having both on a debian/ubuntu platform , both astyle and indent are window ported);

for *.c , I could not decide... (perhaps two beautifiers is enough; suppose there are 100 : would lead to a huge (> 4000 , with say 100 posts per war) number of wars "my beautifier is more beautiful than yours")

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

Let's give him time to respond...

David

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

isn't there any alternative for this? i want to use atmega 16 only and 49X49 array is important part of my algorithm. if  reduce that array, algoritm will not give required result. 

please any other alternative code changes..

need suggestions from all of you..help me

im using atmel studio 6 and not getting any build error for this code.

 

 

Last Edited: Sun. Feb 4, 2018 - 10:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Last Edited: Sun. Feb 4, 2018 - 11:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

then you have to tell what you really want to do! 

 

you use the name "graph" perhaps you can draw one at the time.

 

If you use a LCD perhaps you can store the array in some of it's RAM. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sunny28 wrote:

isn't there any alternative for this? i want to use atmega 16 only and 49X49 array is important part of my algorithm. if  reduce that array, algoritm will not give required result. 

 

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.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brian, his array is "int" so that 2,401 is really 4,802 bytes!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Brian, his array is "int" so that 2,401 is really 4,802 bytes!

 

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

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The path of least resistance for you is probably an aduino mega2560 board:

https://www.aliexpress.com/whole...

 

The processor on that PCB has 8kiBi or RAM.

https://www.microchip.com/wwwpro...

 

If you change this line:

sunny28 wrote:
int graph [49][49];
to one of these lines:

int8_t graph[49][49];    // Each number can be from 0 to 255.

uint8_t graph[49][49];   // Each number can be from -128 to + 127.

then each array item will just be one byte and you have halved the amount of memory you need.

Edit: Clarification: You will NEED a bigger chip to fit your memory needs. Reducing the variable size to int8_t gives you more headroom on this bigger processor. (Tnx Clawson #30).

I can't make it much simpler than this.

 

I'm not sure what a 2 dimensional array of bools would look like in memory. Would that work?

Edit: Frog #29 says each bool still occupies a byte. I was afraid of something like that, but not sure.

bool graph[49][49];   // Each value can be "true" or "false".

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

Last Edited: Sun. Feb 4, 2018 - 01:33 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
I'm not sure what a 2 dimensional array of bools
A bool still occupies a byte in memory in the AVRs.

 

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.

David

Last Edited: Sun. Feb 4, 2018 - 01:25 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paulvdh wrote:
then each array item will just be one byte and you have halved the amount of memory you need. I can't make it much simpler than this.
You're going to have to do better than that. You reduced 4802 bytes to 2401 in a micro with just 1024 bytes.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
You're going to have to do better than that.

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

 

sunny28 wrote:
isn't there any alternative for this?

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

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

isn't there any alternative for this?

 There is, and I told you (briefly).

 

Your 49x49 array seems actually to use only 1 bit "per position" . Thus, you can store 8 such bits in one byte. This will need extra coding since there is no functionality built into C to handle bits as an intrinsic data type (in arrays).

 

If you don't want to explore that the brutal answer is that you have picked the wrong microcontroller for the job. 

 

 

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It's also possible that, while your conceptual object is a 49x49 array, you can represent it with something smaller. For instance, if your goal were "I need to indicate which space in a 49x49 grid each of five objects is in, so I'm storing 0 for unoccupied squares, and the number of the object in the square the object is in", you could do that as five 2-byte coordinates instead of an array. But you'd have to talk about what you're doing.

 

Realistically, though: It is almost certainly simply not physically possible to do what you want, because what you want is to manipulate more data than your chip can hold.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note (as has been mentioned) that 49*49 bits will fit 301 bytes.  If all you need is 0/1, this can easily be done with a 1K micro, with a bit (ha) of code.

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"Wisdom is always wont to arrive late, and to be a little approximate on first possession."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"We see a lot of arses on handlebars around here." - [J Ekdahl]

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

the_real_seebs wrote:
Realistically, though: It is almost certainly simply not physically possible to do what you want, because what you want is to manipulate more data than your chip can hold.

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.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I tried myself to implement the idea described in #31 and #32

Not tested! 

char graph[49][7]; //49*7 bytes = 49*56 bits

void write_graph (char i, char j, char d)
{
    char byte = j / 8;
    char mask = 1 << (j % 8);

    if (d)
        graph[i][byte] ¦= mask;
    else
        graph[¡][byte] &= ~mask;
}

char read_graph (char i, char j)
{
    char byte = j / 8;
    char mask = 1 << (j % 8);

    if (graph[i][byte] & mask)
        return 1;
    else
        return 0;
}

 

Majid

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oops!
I m late

I was beautifying my code!
anyway I hope useful
Cheers

Majid

Last Edited: Sun. Feb 4, 2018 - 06:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Beat you by 11 minutes m.majid!   ;-)

 

And I claim the (abstract) invention of this way back in #11  ;-)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Note that back when I was your age, often graphing/plotting/image generation was done doing "banding" -- work on one "scan line" at a time, then output that, then recalculate all the pixel (or equivalent) values for the next scan line, and repeat.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

#1 Hardware Problem? https://www.avrfreaks.net/forum/...

#2 Hardware Problem? Read AVR042.

#3 All grounds are not created equal

#4 Have you proved your chip is running at xxMHz?

#5 "If you think you need floating point to solve the problem then you don't understand the problem. If you really do need floating point then you have a problem you do not understand."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fair, if it really does just need to be bits, then yes, it can be fit in only 301 bytes of memory. I think I was assuming that "int" indicated an intention that there be more than two possible values.