Byte array and bitwise operator for LCD

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

I am trying to get to read individual bits of a byte array. I am basically iterating through the byte array and want to tell whether each individual bit is 0 or 1. 

 

My problem is, I am unable to differentiate between a 0 and 1 bit. The code is always reading each bit as a 1.  

 

This is my code:


    const unsigned char bitmap[] = {

    0x00,0xFF,0xFF,0x00,0x00,0x00,

    0x00,0x00,0xFF,0xFF,0xFF,0xFF,

    0xFF,0xFF,0xFF,0xFF

    };

    void drawBitmap(Framebuffer *fb) {

    uint8_t x = 1;

    for (int i = 0; i < sizeof(bitmap); ++i) {

    for (int p = 0; p < 8; ++p) {

    if ((bitmap[i] >> p) & 1) { // If bit

    fb->drawPixel(x, 1); // **RIGHT HERE** --> I AM ALWAYS GETTING THIS AS TRUE 

    }

    x++;

    }

    }

    }

Note that there are some bytes that should be all zeroes (0x00). I am assuming by default these are bytes (8 bits), right? Any ideas why am I unable to differentiate between a 1 and a 0?

 

Note: Here's the whole code... I am trying to use this library: https://github.com/tibounise/SSD... with an atmega328P... This just doesn't make any sensse. Whenever I use "fb->drawPixel(x, 1);" on it's own it works fine, but on that particular function I always get a "1" (a pixel).

 

    #define F_CPU 14745600

    #include <stdint.h>

    #include <stdio.h>

    #include <math.h>

    #include <avr/io.h>

    #include <avr/interrupt.h>

    #include <avr/pgmspace.h>

    #include <inttypes.h>

    #include <util/delay.h>

    //#include "SSD1306.h"

    #include "Framebuffer.h"

    const unsigned char bitmap[] = {

    0x00,0x00,0x00,0x00,0x00,0x00,

    0x00,0x00,0xFF,0xFF,0xFF,0xFF,

    0xFF,0xFF,0xFF,0xFF

    };

    void drawBitmap(Framebuffer *fb) {

    uint8_t x = 1;

    int z = 0;

    for (int i = 0; i < sizeof(bitmap); ++i) {

    for (int p = 0; p < 8; ++p) {

    if ((bitmap[i] >> p) & 1) { // If bit

    fb->drawPixel(x,1);

    }

    x++;

    }

    }

    }

    int main(void) {

    //const uint8_t *bitmap;

    //bitmap = &bitmap1;

    Framebuffer fb;

    Framebuffer *FB;

    //Pointer to the class

    FB = &fb;

    //fb.drawPixel(5, 5);

    drawBitmap(FB);

    fb.show();

    //delay_ms(1000);

    return 0;

    }

Any ideas?

 

Thanks in advance.

Last Edited: Sat. Feb 10, 2018 - 08:53 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your >> are a very expensive way to do this anyway. Perhaps consider a 1,2,4,8,16,32,64,128 mask array?

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

Care to give any example? ... Still I don't know why this is happening... But as long as there is a way to get the same result in another way, I would take it.

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

I am gobsmacked by how people like to make their lives difficult.

A human can't follow flush code.    At least this human can't.

const unsigned char bitmap[] = {
    0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00,
    0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
    0xFF, 0xFF, 0xFF, 0xFF
};

void drawBitmap(Framebuffer *fb) {
    uint8_t x = 1;
    for (int i = 0; i < sizeof(bitmap); ++i) {
        for (int p = 0; p < 8; ++p) {
            if ((bitmap[i] >> p) & 1) { // If bit
                fb->drawPixel(x, 1); // **RIGHT HERE** --> I AM ALWAYS GETTING THIS AS TRUE
            }
            x++;
        }
    }
}

Your code looks as if it should work.    Obviously it could be written about 10x more efficiently.   As suggested by clawson.

 

Most drawPixel() functions would draw at x, y e.g. with drawPixel(x, y, color)

 

Formatting code in the AS7 editor requires an arduous two keypresses.   Formatting code in the Arduino IDE requires a single ctrl-T

 

David.

Last Edited: Sat. Feb 10, 2018 - 06:27 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

I am gobsmacked by how people like to make their lives difficult.

A human can't follow flush code.    At least this human can't.

const unsigned char bitmap[] = {
    0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00,
    0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
    0xFF, 0xFF, 0xFF, 0xFF
};

void drawBitmap(Framebuffer *fb) {
    uint8_t x = 1;
    for (int i = 0; i < sizeof(bitmap); ++i) {
        for (int p = 0; p < 8; ++p) {
            if ((bitmap[i] >> p) & 1) { // If bit
                fb->drawPixel(x, 1); // **RIGHT HERE** --> I AM ALWAYS GETTING THIS AS TRUE
            }
            x++;
        }
    }
}

Your code looks as if it should work.    Obviously it could be written about 10x more efficiently.   As suggested by clawson.

 

Most drawPixel() functions would draw at x, y e.g. with drawPixel(x, y, color)

 

David.

 

But that's the thing... It's not working. I know it should work but it's not. The line

((bitmap[i] >> p) & 1)

is not differentiating the 1's from the 0's. It's always a "1". 

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

lcruz007 wrote:
I AM ALWAYS GETTING THIS AS TRUE 

How did you establish?
.
Code seems true

Majid

Last Edited: Sat. Feb 10, 2018 - 06:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have no idea what you are trying to do.   But this is what your function does :

 

drawBitmap()
00000000
11111111
11111111
00000000
00000000
00000000
00000000
00000000
11111111
11111111
11111111
11111111
11111111
11111111
11111111
11111111

From this Arduino sketch:    Obviously you want 128 bits in one line.   Humans find blocks of 8 easier to read.

const unsigned char bitmap[] = {
    0x00, 0xFF, 0xFF, 0x00, 0x00, 0x00,
    0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
    0xFF, 0xFF, 0xFF, 0xFF
};

//void drawBitmap(Framebuffer *fb) {
void setup(void) {
    Serial.begin(9600);
    Serial.println("drawBitmap()");
    uint8_t x = 1;
    for (int i = 0; i < sizeof(bitmap); ++i) {
        for (int p = 0; p < 8; ++p) {
            if ((bitmap[i] >> p) & 1) { // If bit
                //                fb->drawPixel(x, 1); // **RIGHT HERE** --> I AM ALWAYS GETTING THIS AS TRUE
                Serial.print("1");
            }
            else Serial.print("0");
            x++;
        }
        Serial.println("");
    }
}

void loop(void)
{
}

David/

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

lcruz007 wrote:
It's always a "1"
Since the code looks right, another possibility is that bitmap[] actually contains only FFs instead of the data that is supposed to be there. What build environment do you use? Some self-made Makefile perhaps?

Stefan Ernst

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

Try this code:

for( uint8_t Mask = 1; Mask; Mask <<= 1) {
    if (byte & Mask) {
        // Do something usefull.
    }
}

 

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

Yes I am using my own makefile and I compile it with WinAVR (a bit outdated but it works like a charm)... What do you mean about the bitmap function? 

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

lcruz007 wrote:
Yes I am using my own makefile
Then I suspect that you do not export the .data section into the HEX file.

Stefan Ernst

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

sternst wrote:

lcruz007 wrote:
Yes I am using my own makefile
Then I suspect that you do not export the .data section into the HEX file.

 

What data section? What do you mean?

 

Here's the makefile I have to compile the libraries: 

GS=-g -Os -Wall -mmcu=atmega328p 

all: delay.o lcd.o uart.o I2C.o SSD1306.o Framebuffer.o

delay.o: delay.c
	avr-gcc ${GCCFLAGS} -o delay.o -c delay.c

lcd.o: lcd.c
	avr-gcc ${GCCFLAGS} -o lcd.o -c lcd.c

uart.o: uart.c
	avr-gcc ${GCCFLAGS} -o uart.o -c uart.c

I2C.o: I2C.cpp
	avr-gcc ${GCCFLAGS} -o I2C.o -c I2C.cpp

SSD1306.o: SSD1306.cpp
	avr-gcc ${GCCFLAGS} -o SSD1306.o -c SSD1306.cpp

Framebuffer.o: Framebuffer.cpp
	avr-gcc ${GCCFLAGS} -o Framebuffer.o -c Framebuffer.cpp

 

And the makefile I use to burn the code you saw on my other posts (the one not working) into the chip:

 

GCCFLAGS=-g -Os -Wall -mmcu=atmega328p
LINKFLAGS=-Wl,-u,vfprintf -lprintf_flt -Wl,-u,vfscanf -lscanf_flt 
AVRDUDEFLAGS=-F -p atmega328p -c usbtiny
LINKOBJECTS=../libs/delay.o ../libs/lcd.o ../libs/uart.o ../libs/I2C.o ../libs/SSD1306.o ../libs/Framebuffer.o

all:	storage-upload

storage.hex:	storage.cpp
	make -C ../libs
	avr-gcc ${GCCFLAGS} ${LINKFLAGS} -o storage.o storage.cpp -lm ${LINKOBJECTS}
	avr-objcopy -j .text -O ihex storage.o storage.hex
	
storage.ass:	storage.hex
	avr-objdump -S -d storage.o > storage.ass
	
storage-upload:	storage.hex
	avrdude ${AVRDUDEFLAGS} -U flash:w:storage.hex:a

 

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

Life is a mystery.

 

God gave you the Arduino.

 

Atmel gave you AS4 and AS7.

 

You choose to create a bad Makefile.

 

In the days of AS4 there was a utility called Mfile that would create the Makefile for you.

 

David.

 

Edit.   You can run the Arduino on Windoze, Linux, Mac, ...

You can probably run it on a a RaspberrryPi or Android phone.

Last Edited: Sat. Feb 10, 2018 - 09:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

Life is a mystery.

 

God gave you the Arduino.

 

Atmel gave you AS4 and AS7.

 

You choose to create a bad Makefile.

 

In the days of AS4 there was a utility called Mfile that would create the Makefile for you.

 

David.

 

Edit.   You can run the Arduino on Windoze, Linux, Mac, ...

You can probably run it on a a RaspberrryPi or Android phone.

 

Hey David,

 

How is it a bad Makefile? It would be really helpful if you would point out the problem. 

 

P.S I don't want to use Arudino's bootloader. Which is why I am using an ISP programmer

 

Thanks

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

I am not suggesting that you use any particular operating system.    But it is always wise to snoop on a working system.    Then compare it with your own.

 

I happen to use Arduino hardware almost all of the time.   It is so convenient to have a single USB cable and standard headers to receive prototyping boards.

 

Yes,  I use the bootloader whenever possible.    Much more convenient than hooking up a USBASP.    But if I do choose to use USBASP or STK500 I would never use avrdude -F

 

This is a typical objcopy command from an AS7 project:

	@echo Building target: $@
	@echo Invoking: AVR/GNU Linker : 5.4.0
	$(QUOTE)C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe$(QUOTE) -o$(OUTPUT_FILE_PATH_AS_ARGS) $(OBJS_AS_ARGS) $(USER_OBJS) $(LIBS) -Wl,-Map="I2C_t817.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=attiny817 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.2.118\gcc\dev\attiny817"
	@echo Finished building target: $@
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "I2C_t817.elf" "I2C_t817.hex"
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "I2C_t817.elf" "I2C_t817.eep" || exit 0
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "I2C_t817.elf" > "I2C_t817.lss"
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "I2C_t817.elf" "I2C_t817.srec"
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "I2C_t817.elf"

You could study a working Makefile from any IDE or working project.   Make sure that your homegrown Makefile follows a similar pattern.

 

It seems quite clear that your bitmap function works just fine.    Efficiency does not matter.

 

I suggest that you examine the LSS file to see the compiler has produced.   However objdump works on the ELF file.    The HEX file might have omitted some records due to wrong objcopy switches.

 

David.

Last Edited: Sat. Feb 10, 2018 - 10:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

I am not suggesting that you use any particular operating system.    But it is always wise to snoop on a working system.    Then compare it with your own.

 

I happen to use Arduino hardware almost all of the time.   It is so convenient to have a single USB cable and standard headers to receive prototyping boards.

 

Yes,  I use the bootloader whenever possible.    Much more convenient than hooking up a USBASP.    But if I do choose to use USBASP or STK500 I would never use avrdude -F

 

This is a typical objcopy command from an AS7 project:

	@echo Building target: $@
	@echo Invoking: AVR/GNU Linker : 5.4.0
	$(QUOTE)C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-gcc.exe$(QUOTE) -o$(OUTPUT_FILE_PATH_AS_ARGS) $(OBJS_AS_ARGS) $(USER_OBJS) $(LIBS) -Wl,-Map="I2C_t817.map" -Wl,--start-group -Wl,-lm  -Wl,--end-group -Wl,--gc-sections -mmcu=attiny817 -B "C:\Program Files (x86)\Atmel\Studio\7.0\Packs\atmel\ATtiny_DFP\1.2.118\gcc\dev\attiny817"
	@echo Finished building target: $@
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O ihex -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures  "I2C_t817.elf" "I2C_t817.hex"
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -j .eeprom  --set-section-flags=.eeprom=alloc,load --change-section-lma .eeprom=0  --no-change-warnings -O ihex "I2C_t817.elf" "I2C_t817.eep" || exit 0
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objdump.exe" -h -S "I2C_t817.elf" > "I2C_t817.lss"
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-objcopy.exe" -O srec -R .eeprom -R .fuse -R .lock -R .signature -R .user_signatures "I2C_t817.elf" "I2C_t817.srec"
	"C:\Program Files (x86)\Atmel\Studio\7.0\toolchain\avr8\avr8-gnu-toolchain\bin\avr-size.exe" "I2C_t817.elf"

You could study a working Makefile from any IDE or working project.   Make sure that your homegrown Makefile follows a similar pattern.

 

It seems quite clear that your bitmap function works just fine.    Efficiency does not matter.

 

I suggest that you examine the LSS file to see the compiler has produced.   However objdump works on the ELF file.    The HEX file might have omitted some records due to wrong objcopy switches.

 

David.

 

Ok I see... I am now suspecting there is a problem with AVR-DUDE or WINAVR, as I am also trying other operations with arrays and none of them work. For some reason it's not working with arrays.... Why would that be...?

 

The only thing left to try is.... well, I will try to compile this code with Atmel Studio and see if things improve.

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

lcruz007 wrote:
I am now suspecting there is a problem with AVR-DUDE or WINAVR
No, it is definitely a problem of your Makefile, in particular this line:

	avr-objcopy -j .text -O ihex storage.o storage.hex

As I already said, the root of your problems is that you do not export .data into the HEX file.

Stefan Ernst

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

lcruz007 wrote:
I am now suspecting there is a problem with AVR-DUDE or WINAVR,

So probably millions of people and millions of apps use the mentioned tools.  Yet none of them until you have uncovered a problem with arrays?  Sounds unlikely.

 

Create the smallest complete test program that demonstrates your symptoms, and post it in its entirety including build sequence, ISP sequence, what you expect, what you see, etc.

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

Ok so here is a small test program:

 

Keep in mind that I am using this library https://github.com/tibounise/SSD... and I am basically driving a LCD OLED display, 128x64. What I am trying to accomplish is turn specific pixels ON. 

 

void drawBitmap(Framebuffer *fb) {			

	fb->drawPixel(10, 1);
	fb->drawPixel(11, 1);
	fb->drawPixel(12, 1);

	fb->drawPixel(90, 1);
	fb->drawPixel(91, 1);
	fb->drawPixel(92, 1);
}
int main(void) {

	Framebuffer fb;
	Framebuffer *FB;

	//Pointer to the class
	FB = &fb;

	drawBitmap(FB);

	fb.show();

	return 0;
}

The above code works like a charm! Works as expected These are the results:

 

 

 

Now if I do this....

 

void drawBitmap(Framebuffer *fb) {

	uint8_t x = 1;

	for (int i = 0; i < sizeof(bitmap); ++i) {
		for (int p = 0; p < 8; ++p) {
			if ((bitmap[i] >> p) & 1) { // If bit
				fb->drawPixel(x,1);
			}
			x++;
		}
	}

}

int main(void) {

	Framebuffer fb;
	Framebuffer *FB;

	//Pointer to the class
	FB = &fb;

	drawBitmap(FB);

	fb.show();

	return 0;
}

The above code does NOT work at all!! This is what I get:

 

 

So it's like the MCU is basically reading just a "1" for every item in the array. This part "if ((bitmap[i] >> p) & 1) {" is always TRUE according to the results... What I expect to see is some pixels OFF at the start, and then some of them will be ON. (depending on the array I initialize).

 

Both codes compile correctly though:

 

 

 

I see no reason why this is happening... I have even tried some other operations with arrays (just to try to get the correct results) and it's the same always. It's like "if ((bitmap[i] >> p) & 1)" meant "if there is an element in the array make it TRUE regardless of the value"... It's weird, I have no idea what could be wrong with it.

Last Edited: Sat. Feb 10, 2018 - 11:52 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

sternst wrote:

lcruz007 wrote:
I am now suspecting there is a problem with AVR-DUDE or WINAVR
No, it is definitely a problem of your Makefile, in particular this line:

	avr-objcopy -j .text -O ihex storage.o storage.hex

As I already said, the root of your problems is that you do not export .data into the HEX file.

 

You sure about that? I have used the same makefile for years and I have never had a problem before... The only difference this time is that I am using a library for SSD1306 LCDs, and that it's written in a cpp file instead of a .C. But it should work the same I suppose, I have even tried avr-g++ instead and I get the same results... What do you recommend I do to fix this? I just posted more information of my results, maybe that helps?

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

I can't  believe you've used that makefile "For years" and have never been previously bitten by the lack of -j .data in the obcopy?? Most sensible makefiles these days seem to prefer -Rs anyway as that will include any "private" data/code sections you add automatically. 

 

Why don't you update to a 2018 toolchain?

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

clawson wrote:

I can't  believe you've used that makefile "For years" and have never been previously bitten by the lack of -j .data in the obcopy?? Most sensible makefiles these days seem to prefer -Rs anyway as that will include any "private" data/code sections you add automatically. 

 

Why don't you update to a 2018 toolchain?

 

I see.... Yes I'd definitely do that. I am using the pocket AVR ISP programmer from Sparkfun. I guess that if a new toolchain is available and it supports my programmer I am happy... What would you recommend?

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

lcruz007 wrote:
I have even tried some other operations with arrays (just to try to get the correct results) and it's the same always. It's like "if ((bitmap[i] >> p) & 1)" meant "if there is an element in the array make it TRUE regardless of the value"... It's weird, I have no idea what could be wrong with it.

To establish if the issue is related to arrays try to use a fixed variable as test

something like this:

 

void drawBitmap(Framebuffer *fb) { 	
uint8_t temp = 0x0F;
uint8_t x = 1;
for (int i = 0; i < sizeof(bitmap); ++i) { 		
    for (int p = 0; p < 8; ++p) { 			
        if ((temp >> p) & 1) {
           fb->drawPixel(x,1); 			
        } 			
        x++;
    }
} 
}

This shuold draw dashed line

Majid

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

m.majid wrote:

lcruz007 wrote:
I have even tried some other operations with arrays (just to try to get the correct results) and it's the same always. It's like "if ((bitmap[i] >> p) & 1)" meant "if there is an element in the array make it TRUE regardless of the value"... It's weird, I have no idea what could be wrong with it.

To establish if the issue is related to arrays try to use a fixed variable as test

something like this:

 

void drawBitmap(Framebuffer *fb) { 	
uint8_t temp = 0x0F;
uint8_t x = 1;
for (int i = 0; i < sizeof(bitmap); ++i) { 		
    for (int p = 0; p < 8; ++p) { 			
        if ((temp >> p) & 1) {
           fb->drawPixel(x,1); 			
        } 			
        x++;
    }
} 
}

This shuold draw dashed line

 

 

I have no problem with the temp variable, I just tried! When setting it to 0X00 all pixels are off, when I set it to something like 0XFF then I some pixels on. So the issue is definitely related to arrays! I have no clue why this is the case!! it doesn't make any sense... Why do I have problems only with arrays?? Does that has to do with my makefiles...? Why only arrays though...? This is so weird...

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

clawson wrote:

I can't  believe you've used that makefile "For years" and have never been previously bitten by the lack of -j .data in the obcopy?? Most sensible makefiles these days seem to prefer -Rs anyway as that will include any "private" data/code sections you add automatically. 

 

Why don't you update to a 2018 toolchain?

 

Ok so you were right!! The makefile was the problem all this time. Just like you said, the data part... I changed it to this: 

 

avr-objcopy -j .text -j .data -O ihex storage.o storage.hex

Is it not recommended at all to do that? Well it's working for me now...

 

It's weird I hadn't had this problem in the past... And I have used the same makefile for a lot of my other projects before... Hmm.. Well it's good to know what the problem was. 

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

Maybe it is because of "const"
Try
unsigned char bitmap[]
İnstead of
const unsigned char bitmap[]

Majid

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

Not to hijack the thread, but where are your XTAL caps & all the bypass caps for your regulator and each of the various components (the modules prob have their own)?  Lack of those can cause working code to develop odd happenings.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

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

Just to pint out that it was Stefan not me who identified missing .data

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

It's weird I hadn't had this problem in the past... And I have used the same makefile for a lot of my other projects before... Hmm.. Well it's good to know what the problem was. 

Not all code has a .data section.  It is used to store the initial values of any local static or global variables which are initialised to non-zero values.  If you don't have any of those, you won't miss .data.  Perhaps coincidentally none of your projects had any?  Or, if they did, they were tolerant of being initialised to 0xFF.

"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

clawson wrote:

Just to pint out...

Had a good day eh? ;-)

"I may make you feel but I can't make you think" - Jethro Tull - Thick As A Brick

"void transmigratus(void) {transmigratus();} // recursio infinitus" - larryvc

"It's much more practical to rely on the processing powers of the real debugger, i.e. the one between the keyboard and chair." - JW wek3

"When you arise in the morning think of what a privilege it is to be alive: to breathe, to think, to enjoy, to love." -  Marcus Aurelius

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

I have just come back from the pub too.

 

David.