Logical issue with image.sram() functions

[lbratonozic]

image.sram() functions take in two parameters that are both const uint8_t. This would only work with saved images rather than a buffer as described...unless I am missing something?

[ecdr]

Why would it only work with saved images?
I believe the const on argument just mean that this function does not change the contents of the buffer.

[lbratonozic]

For my purposes I an trying to define a bitmap image in a byte array that is changed within the program. I was pointed towards the image.SRAM function to achieve this but it is counterintuitive using a const parameter for a buffer...unless I'm completely off base here

[ecdr]

Do not declare your buffer const, and pass it to the function - should work fine.
(Const just means the item is "read only" - no problem with adding a read only restriction to something, problem would be if you tried to take away constness (i.e. tried to write to a read only item)).

Check C++ FAQ or stack exchange, etc. for help with the language.

[lbratonozic]

But a buffer can't be passed to the function because the parameter in question is defined as a cost.. Therefore, image.sram(buffer) won't work..

[ecdr]

What error message do you get when you try it?
If you haven't tried it, don't say it can't be done.
Suggest you re-read your C++ manual on constants, and do some experiments.

[lbratonozic]

I did try the image.sram() function with my declared byte array which stemmed this whole discussion. When I received an error that I could not pass a buffer to the function, I digged into the libraries to find out the problem. To my suprise, the image.sram() function had the parameters declared as consts. It could be that the original writer of the library intended for the image.sram() method to do something other than what I am looking for...because otherwise the const parameter doesn't make sense. My proposed solution which I havent had time to try yet, would be just to change those parameters to (non-const) uint8_t* and see if that works. There could be a reason that you cant upload buffers into the display but I'm not sure what that is yet...If you have any insight please let me know.

Date: Thu, 6 Nov 2014 22:16:31 -0800
From: [email protected]
To: [email protected]
CC: [email protected]
Subject: Re: [gratis] Logical issue with image.sram() functions (#18)

What error message do you get when you try it?

If you haven't tried it, don't say it can't be done.

Suggest you re-read your C++ manual on constants, and do some experiments.

—
Reply to this email directly or view it on GitHub.

                  =

[ecdr]

Have you tried running the thermo demo?
It uses EPD_GFX (which uses image.sram ).
Works fine for me (in Energia).

Declaring the argument const just tells the compiler that this method does not change the array. Which means that
a) the compiler can give warnings if the method tries to change the value of the array.
b) you can pass it EITHER a constant or a variable array (either one will work). If the argument was not declared const, then handing it a const array would be an error.

[lbratonozic]

I have not, but upon just trying I got this error:

C:\Program Files (x86)\Arduino\libraries\Adafruit-GFX-Library-master\glcdfont.c:13:23: error: variable 'font' must be const in order to be put into read-only section by means of 'attribute((progmem))'
static unsigned char font[] PROGMEM = {
^

[ecdr]

You have an old copy of the Adafruit-GFX library. Download the latest version (which fixes that problem).
https://github.com/adafruit/Adafruit-GFX-Library

https://github.com/adafruit/Adafruit-GFX-Library/blob/master/glcdfont.c

[lbratonozic]

Hi,

Ive downloaded the new versions of all libraries. However, the thermo demo doesnt seem to support 2.7". Is there a reason for this? Note: I'm using a mega2560 with 8K ram.

[hxw]

The problem with the 2.7" display is that you need two buffers for V1 COG so there is not enough SRAM
(264*176/8)*2 = 11616 bytes. Fo V2 (thermo2) it might be possible, but (264*176/8) = 5808 bytes is more than half the SRAM on these devices, not sure if that would leave enough for stack, serial buffers plus any other working storage requirements fo the program to operate correctly (just commnet the #error and see if it can work - must use V2)

For the "const" in normal C programs const indicates that the routine does not modify the buffer, e.g.:

size_t write(const uint8_t *buffer, size_t count);  // only reads buffer
size_t read(uint8_t *buffer, size_t count);         // can write to buffer

(you can add const to the count [parameter also to stop the routines changing the value just in case you need to be sure that the value stays constant inside read/write - C parameters are always pass by value so the caller's variable is never affected)

However the AVR MCUs in the Arduino have two memory spaces; FLASH, SRAM. Which do not map wee on to C's const, you acutally need three states:

1. const and in FLASH - const PROGMEM <type>
2. const and in SRAM - const <type>
   3 non-const) writable and in SRAM - <type>
   This is reason for the different image routines so as to fetch data from the differing memory types since the souce items memory type and the function parameter's memory types must match.

They error seems to indicate you are trying to pass PROGMEM data to the image_sram which is not possible since you a mixing memory types. PROGMEM must use the plain image function and SRAM data can only use the image_sram function.

I have not tried to compile this recently. Has there been an Arduino IDE update with a new compiler that changed the semanics of PROGMEM/const. When I wrote the code the meaing of PROGMEM/const was:

// given 
PROGMEM const uint8_t p[100] = {<data-values>};  // Initialised in flash
uint_8 r[100];  // SRAM data - nnt initialised (might be cleared at reset)
uint8_t b;      // just for demo code below

// to access the memory areas different code is required
b = r[n];       // read a byte from SRAM
r[n] = b;       // write a byte from SRAM
b =  pgm_read_byte_near(n); // read a byte from FLASH

// the result of the next line is undefined 
b = p[n];       // undefined would read a byte from an undefined/unimplemented location

(the line() function uses the above depending on which memory area is being accessed - there is a read_progmem boolean to control this)

Hope that clears things up - but let me know if something is wrong.