Binary Numbers in Progmem array....

@westfw

To test the functionality of pgm_read_byte_near(), I have made a hardware setup in which a cc-type 7-segment display device is driven by PORTD and DPin-12 of UNO. The cc-codes for the digits 0 - F are taken from a Flash based Lookup Table (pls see codes below). (During uploading I take out jumper wires from DPin-0 and DPin-1.) My query is to know why both the following two instructions work equally. According to Post#16 (if I have understood correctly), the second one should not work.

PORTD = pgm_read_byte_near(&ccArray[7]); //7seg display device show 7
PORTD = ccArray[7]; //7seg display device shows 7

#include<avr/pgmspace.h>

const byte PROGMEM ccArray[16] = {
0x3F, 0x06, 0x5B, 0x4F, 0x66, 0x6D, 0x7D, 0x07,
0x7F, 0x6F, 0x77, 0x7C, 0x39, 0x5E, 0x79, 0x71
                                };
void setup()
{
  
  DDRD = 0xFF;
  pinMode(12, OUTPUT);
  //PORTD = pgm_read_byte_near(&ccArray[7]);  //7seg shows 7
  PORTD = ccArray[7];                                         //7seg device shows 7
  digitalWrite(12, LOW);
}

void loop()
{

}

PORTD = ccArray[7]; //7seg display device shows 7

Again, this looks to the compiler like a constant array index to constant array data, so it compiles to something like:

ldi r24,0x7
out PORTD, r24

In this case, the ccArray WILL be stored in the program binary, since other things use it, but that doesn't mean the compiler has to use the actual array to get a know piece of data.

@westfw

The operand of ldi r24, 0x07 is 0x07. Is it the array index or the cc-code pointed by the index? Coincidentally, in this example, the array index and the cc-code pointed by the index are the same. This is different in this case: PORTD = ccArray[3] – the array index is 3, but the cc-code pointed by the index is 0x4F. So, to see character 3 on the cc-type 7-seg display device, 0x4F must be sent to PORTD and not 0x03.

GolamMostafa:
Coincidentally, in this example, the array index and the cc-code pointed by the index are the same.

Actually, coincidentally, in this example, the array index and the cc-code, and the displayed numeral pointed by the index are the same. :slight_smile:

Actually, coincidentally, in this example, the array index and the cc-code, and the displayed numeral pointed by the index are the same.

1+ observation!

westfw:
That has nothing to do with PROGMEM. Nor anything to do with whether your compile-time constants are in binary or hex…

There’s no PROGMEM in the code you posted. However, from the video, it seems that you expect that using PROGMEM in the variable definition is all you need to do to move data from RAM to Flash. That is NOT the case on the AVR CPUs - you have to add pgm_read_byte() around your accesses, probably about like this:

        BufferM[i][j] = pgm_read_byte(&BitMask[Message[i]][j]);

See the pgmspace tutorials for more info…

(Interestingly, you wouldn’t need to do that on an ARM. Search “Harvard architecture” if you want to start understanding why…)

THANK YOU!!! i had reviewed the tutorials but your answer and solution was no where in any of the tutorials on the first 5 pages of google, i guess i wasnt googling the right thing. ive looked at the architectures before and for what i use it for most of the time those arent really anything i need to know about. the coeds that i had posted from the first page however did include the progmem declaration, i was pretty sire the code i used in the video example was still declared as prog mem, I THANK YOU TREMENDOUSLY for showing me that i was missing a step this will help me immensely in the future.

my usage is now down to 5% and that is a wonderfully amazing thing.

THANK YOU one more time .

You're welcome. It can be difficult to explain the PROGMEM stuff in an arduino-like beginner-friendly tutorial, because it involves relatively advanced concepts. It'd all be easier to explain to people who learned microcontroller architecture and assembly language programming first :slight_smile: (but there weren't enough people who did that, leaving any number of "neat things" undone. So Arduino (and similar competing projects) were needed.)

There's more technical tutorial here that MIGHT help:
http://www.fourwalledcubicle.com/AVRArticles.php
AVR-GCC and the PROGMEM Attribute

ASM was a long time ago for me. I originally had to use ASM for PIC Microcontrollers, and a parallel port programmer yadda yadda, then after about the most horrible pain staking year of my life in programming i stumbled onto Protons PICBasic, which was an amazing blessing, slower yes but when you are working at 20 and up Mhz the customer wouldnt notice slower, in addition to the code being simpler to read understand and come back to later it used the MeLabs U2 programmer which was great because it was USB and parallel ports were getting harder and harder to come across and the USB to Parallel adapters wouldnt run the programmers in the beginning.

As for arduino and the similar kits that are out today, i just migrated to them about 3 years ago, originally my put off with them was that they were expensive, and they worked in C which i was familiar with but i have mainly followed less formal languages in the past, with the exception of PHP, which i used at work. in addition to cost and the migration to a whole new coding language, i still had a few hundred starter board that i had made in a batch that were for pic controllers, as these supplies dwindled i was faced with the option to start a new platform or reorder, so i took a gamble and i haven't used a PIC in years.

Arduino to this point has been a fun sort of challenge,it has pushed me to create projects that are larger and more complicated than i would have ever taken on before. i feel as an IDE they have succeeded where many failed because they have great community support , its open source, and every thing you could ever possibly want to use is already in a library, if adafruit, sparkfun or banggood has it someone has already worked out how to make it work with arduino. That was another major drawback to PIC, i remember writing a library for the ST7735 when it came out in a module form. took me a week, which pushed my production time back quite a bit and aggravated a few customers.

i definitely plan to read all the information on the links you suggested because i highly doubt that this will be the last project to use massive constant tables. I really do appreciate that you took the time to point me in the right direction. It has emmense value to me.