|
|
View previous topic :: View next topic |
Author |
Message |
PICFAN1 Guest
|
pse info... |
Posted: Thu Sep 24, 2009 8:43 am |
|
|
Do I have some curiosities, is someone able to give me an answer?
-What difference is there among to use const and #define?
-There is a specific motive because the function glcd_text57 in the driver GLCD.c doesn't write the pixels of background of the characters?
Before overwriting a text, needs always to cancel the preceding text before.
- There is a specific motive because the function read_int32_eeprom (and write_int32_eeprom) in the driver internal_eeprom.c does read the bytes in LSB? In this way, it needs to upset the byte as in this example:
10.000.000 = 0x00989680
Code: |
#rom int8 0xf00000 = {0X80, 0X96, 0X98, 0X00 } // 10.000.000
|
Thank in advance.
Picfan |
|
|
barryg
Joined: 04 Dec 2006 Posts: 41
|
|
Posted: Thu Sep 24, 2009 6:31 pm |
|
|
"const" is a modifier, so we might need to see how you are using it. But for a general explanation, #define does not create anything in your program. It simply tells the compiler that anytime you use that name, to substitute the number (or expression). For example, if you it means that anywhere in the program the word BGND appears, it gets changed to 44, just as sure as you had searched and replaced it. So it is a convenience. It also means that whatever BGND does is going to be dependent on the line it is found in.
const, on the other hand, is usually used with defining a number that's put into memory. So it really does create a number in memory. If I say then I can actually find somewhere in the program ROM where the number 66 is stored.
I just realized that there are 3 separate questions here. I think there's a translator being used, so (as a note for anyone else looking at the questions) I'm guessing "specific motive" in English would be "reason why" |
|
|
barryg
Joined: 04 Dec 2006 Posts: 41
|
|
Posted: Thu Sep 24, 2009 6:44 pm |
|
|
So, taking on the other two questions...
[Why the lcd routines just overwrite the screen without erasing it first?]
Probably because most useful drivers try to keep everything simple. If you need to erase the screen, you can add your own function that will do this. If they had written it so that it cleared the area, that might be bad for someone else, and there's no function you can write to undo the erasing.
[Why does the EEPROM function read_int32_eeprom read the bytes in the order that it does?]
I don't see a function by that name. Nonetheless, you are asking about number formats, and the answer usually is that it was convenient or made sense for someone or some thing (like the hardware, or the math routines). And yes it may be inconvenient for someone else. That's just how things are. And again, like the driver answer above, somewhere there will be a simple byte-at-a-time routine (like CCS's read_eeprom() function) that you can use to build a bigger read that works the way you want it to. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu Sep 24, 2009 7:21 pm |
|
|
Quote: | I don't see a function by that name. |
Look in this file:
Quote: | c:\program files\picc\drivers\internal_eeprom.c |
|
|
|
picfan1 Guest
|
Thank |
Posted: Fri Sep 25, 2009 1:39 am |
|
|
I thank for the answers and I apologize me for the errors of translation.
In fact I have used a translator on line, otherwise the translation would have been worse straight...
Bye, Picfan |
|
|
picfan1 Guest
|
|
Posted: Tue Sep 29, 2009 1:22 am |
|
|
I have tried to modify the function glcd_text57 to also stamp the pixels of background and making some tests, I have found 2 small bugs in the original function underlined with <==
Code: |
/------------------------------------------------------------------------------
// Purpose: Write text on a graphic LCD WITH BACKGROUND //
// Inputs: (x,y) - The upper left coordinate of the first letter //
// textptr - A pointer to an array of text to display //
// size - The size of the text: 1 = 5x7, 2 = 10x14, ... //
// color - ON or OFF //
// background - YES or NO //
// Dependencies: glcd_pixel() //
//------------------------------------------------------------------------------
void glcd_text57(int x, int y, char* textptr, int size, int1 color, int1 background)
{
int i, j, k, l, m; // Loop counters
BYTE pixelData[5]; // Stores character data
for(i=0; textptr[i] != '\0'; ++i, ++x) // Loop through the passed string
{
if(textptr[i] < 'S') // Checks if the letter is in the first text array
memcpy(pixelData, TEXT[textptr[i]-' '], 5);
else if(textptr[i] <= '~') // Check if the letter is in the second array
memcpy(pixelData, TEXT2[textptr[i]-'S'], 5);
else
memcpy(pixelData, TEXT[0], 5); // Default to space
//if(x+5*size >= GLCD_WIDTH) // Performs character wrapping
if(x+5*size > GLCD_WIDTH) // <==Performs character wrapping
{
x = 0; // Set x at far left position
y += 7*size + 1; // Set y at next position down
}
for(j=0; j<5; ++j, x+=size) // Loop through character byte data
{
//for(k=0; k<7*size; ++k) // Loop through the vertical pixels
for(k=0; k<7; ++k) // <==Loop through the vertical pixels
{
if(bit_test(pixelData[j], k)) // Check if the pixel should be set
{
for(l=0; l<size; ++l) // The next two loops change the
{ // character's size
for(m=0; m<size; ++m)
{
glcd_pixel(x+m, y+k*size+l, color); // Draws the pixel
if (j == 0 && i != 0 && background) // if first x-axis pixel and not first char
{
glcd_pixel(x-1, y+k*size+l, !color); // Draws a background pixel before char
}
}
}
}
else if (background)
{
for(l=0; l<size; ++l) // The next two loops change the
{ // character's size
for(m=0; m<size; ++m)
{
glcd_pixel(x+m, y+k*size+l, !color); // Draws the background pixel
if (j == 0 && i != 0 && background) // if first x-axis pixel and not first char
{
glcd_pixel(x-1, y+k*size+l, !color); // Draws a background pixel before char
}
}
}
}
}
}
}
}
|
Bye, Picfan |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|