Как функция/метод может определить, является ли передаваемый массив const PROGMEM (flash) или нет (RAM)?

Боюсь, что у этой проблемы нет хорошего решения. Один вариант делаю например, использовать квалификатор __flash вместо PROGMEM:

const uint8_t ram_array[] = { 1, 2, 3, 4 };
__flash const uint8_t flash_array[] = { 5, 6, 7, 8 };

void function_reading_ram(const uint8_t *array)
{
    uint8_t secondElement = array[1];
    // ...
}

void function_reading_flash(__flash const uint8_t *array)
{
    uint8_t secondElement = array[1];
    // ...
}

int main(void)
{
    function_reading_ram(ram_array);      // ХОРОШО
    function_reading_flash(flash_array);  // ХОРОШО
    function_reading_ram(flash_array);    // Предупреждение
    function_reading_flash(ram_array);    // Предупреждение
}

Обратите внимание, что с __flash вам не нужны pgm_read_byte_near() или ничего похожего. Вы просто используете массив, как если бы вы использовали любой обычный массив, а компилятор достаточно умен, чтобы сгенерировать код, необходимый для получить доступ к флэш-памяти.

Предупреждения, генерируемые gcc:

warning: conversion from address space ‘__flash’ to address space ‘generic’ [-Waddr-space-convert]
     function_reading_ram(flash_array);
     ^
warning: conversion from address space ‘generic’ to address space ‘__flash’ [-Waddr-space-convert]
     function_reading_flash(ram_array);
     ^

Учитывая, насколько хорошо это решение, вы можете удивиться, почему я написал: «Нет хорошее решение». Ну, здесь есть две оговорки, одна маленькая и одна огромный. Небольшое предостережение заключается в том, что вам нужно явно передать опцию -Waddr-space-convert в компилятор, если вы хотите, чтобы он генерировал предупреждения. Это не подразумевается даже с -Стена -Wextra. Огромная оговорка заключается в том, что это работает только на чистом C. Если вы попытаетесь использовать этот трюк в C++, вы получите:

error: ‘__flash’ does not name a type

Это реализация расширения «именованных адресных пространств» для стандартный C. Поскольку ничего подобного в C++ не стандартизировано, авторы gcc предположил, что это не будет полезно для пользователей C++. :-( Вы можете смешивать C и исходники C++ в Arduino, но вы не можете вызывать методы класса из C.

Возможно также объектно-ориентированное решение с использованием шаблона проектирования стратегии, но оно сопряжено с некоторыми (небольшими) потерями памяти и производительности. Для этого вам нужно использовать C++.

• Поместите каждый массив, который вы хотите различать между флэш-памятью/SRAM, в отдельный класс (по одному для каждого типа). Вы получаете сокрытие данных и возможное разделение ответственности бесплатно.
• Вместо того, чтобы помещать массив в каждый класс, поместите ссылку/указатель или используйте его напрямую.
• Вы можете использовать наследование:
  • Создайте класс Flash Array со средством чтения/записи массива SRAM
  • Создайте класс массива SRAM с помощью устройства чтения/записи массива флэш-памяти
  • Наследуйте каждый из используемых вами типов массивов от одного из этих классов, где базовый класс заботится о чтении/записи.
• Альтернативное решение: используйте шаблон стратегии; требует немного больше работы, но вы можете предотвратить множественное наследование (хотя, поскольку вы сейчас используете C, вы не используете наследование (пока)). Это будет включать примерно:
  • Создайте средство чтения классов Flash и SRAM Array, как указано выше.
  • Вместо наследования создайте указатель на один из этих классов, соответствующий типу массива.

Хотя я могу предположить, что это будет означать некоторые изменения в вашем скетче.

Объяснение использования наследования

(запрошено комментарием)

@Casey Я полагаю, вы имеете в виду способ наследования. Предположим, что в классе у вас есть x_array типа FlashArray. Вы просто вызываете x_array.Read(...). Этот метод реализован в FlashArray, но также с теми же параметрами в RamArray. Вы можете применить это, унаследовав как FlashArray, так и RamArray от базового класса (например, ArduinoArray и создав (чистую) виртуальную функцию Read с теми же аргументами. В любом случае реализация метода Read в FlashArray должна читать из Flash, а тот же метод в RamArray должен читать из оперативной памяти.

При изменении типа x_array с FlashArray на RamArray или наоборот ничего менять не нужно (кроме виды). Чтобы упростить эту задачу, рассмотрите возможность определения типа для x_array, чтобы впоследствии, когда вам понадобится его изменить, вам нужно будет сделать это только в одном месте.

Классический способ avr-gcc – это специальные функции с разными именами

например, void* memcpy(void* dest, const void* src, size_t n); // Работает, только если src — это оперативная память

по сравнению с void* memcpy_P(void *dest, PGM_VOID_P src, size_t n); // Работает, только если src равен PROGMEM

Кстати: это уже упоминалось в комментарии к вопросу @Delta_G. Подробнее о примере memcpy_P здесь

Здесь я расширю комментарий KIIV.

Эта проблема известна тем, кто написал платформу Arduino. По сути, указатели на PROGMEM и RAM являются указателями данных (думайте об указателе как об индексе массива, но для всего RAM/Flash, а не для одного его фрагмента, которым вы управляете) одинакового размера и типа. Их нельзя отличить друг от друга, поскольку типы указателей определяются только размером данных, а не их расположением.

Итак, они использовали умное решение: сделать указатель другим указателем, который не совместим с обычным указателем RAM. Это делается путем приведения к классу __FlashStringHelper (и последующего приведения, когда его необходимо прочитать). Класс FSH на самом деле не имеет никаких методов и ничего не делает; он просто используется для определения пользовательского типа указателя, отличного от обычного const *.

Вы можете напрямую прочитать одно из лучших руководств, которые я видел по нему здесь (Обратите внимание, что это для ESP8266, но эта часть работает так же), или я могу попытаться объяснить это. Я предлагаю прочитать его в любом случае, так как в нем много другой информации, полезной, но не относящейся к этому вопросу. Обратите внимание, что у них есть несколько примеров ближе к концу, которые не освобождают память, когда они ее используют, поэтому их прямое копирование может вызвать утечку памяти (см. Мой пример обработки строк, чтобы увидеть правильный метод).

Во-первых, вам нужно привести массив к классу FSH:

const byte MyProgmemArray[] PROGMEM = {4,4,4,4,4,4,4,4}; //Исправляет проблему №82 (добавляем случайность); подробности см. на https://xkcd.com/221/: D
__FlashStringHelper * MyArray = (__FlashStringHelper *) MyProgmemArray;

Я не знаю, есть ли какой-либо метод (и я искал), чтобы объявить их на месте, то есть сделать исходное объявление массива напрямую * __FlashStringHelper. Таким образом, вам все равно нужно, как программисту/пользователю, знать, какие строки находятся во флэш-памяти, когда вы их добавляете, и добавлять строку преобразования. Это означает, что то, что вы хотели (полностью автоматическое определение ОЗУ/флэш-памяти), вполне невозможно, но это, насколько я думаю, близко. Еще одно предупреждение заключается в том, что исходный массив все еще существует, а это означает, что он может быть случайно использован вместо него (все равно вызовет исходную проблему несоответствия), а новое определение занимает немного больше памяти для дополнительного указателя (если компилятор не оптимизирует его?).

Как ни странно, он отлично работает, если вы хотите сохранить строку:

__FlashStringHelper * MyString = PSTR("yaddayaddayadda...");

Строки могут быть встроенными, но я думаю, что это из-за макроса PSTR и потому, что определения строк могут обрабатываться иначе, чем массив значений (даже если они физически одно и то же). Возможно, вы могли бы поэкспериментировать с тем, как работает PSTR (на самом деле это макрос, который что-то делает, а не просто ключевое слово) и посмотреть, сможете ли вы реализовать это в своем собственном коде.

Теперь вам все еще нужно получить данные из массива в той функции, которую вы упомянули. Для этого мы фактически используем две версии этой функции. Это называется перегрузкой (и я думаю, что это только C++, но это Arduino, который по определению является C++, так что это безопасно).

Функция ОЗУ, которую вы объявляете как обычную:

void MyFunction(const uint8_t *MY_ARRAY){
  byte index_two = MY_ARRAY[1];
  ...
}

Функция PROGMEM, которую вы объявляете следующим образом (при условии, что pgm_read_byte_near - это правильная функция. Также обратите внимание, что она усложняется, если вам нужны многобайтовые значения, такие как int или что-то в этом роде...):

void MyFunction(__FlashStringHelper *MY_PROGMEM_ARRAY){
  const byte *MY_ARRAY = (const byte *)MY_PROGMEM_ARRAY; // конвертируем обратно в обычный
  byte index_two = pgm_read_byte_near(MY_ARRAY+1); //конечно, все равно нужно читать как flash
  ...
}

В качестве бонуса к информации, которая не связана с вопросом, заданным, но может заинтересовать вас/быть актуальным позже:

Есть еще несколько замечаний, если вы используете это для строковых данных (или притворяетесь, что это строка для этой части, что работает, если ваши данные не содержат нулей и заканчиваются единицей). Под последним я подразумеваю тот факт, что строки в C (НЕ C++ std::string или String Arduino, так что имейте это в виду) в основном являются char массивы с 0 на конце. Все функции обработки строк выполняют бесконечный цикл до тех пор, пока не прочитают 0 в своем текущем индексе, что позволяет им работать со строками любой длины, но при этом знать, когда они сделаны. В результате при чтении вы можете обращаться с данными как со строкой, но с тремя оговорками:

1. Он никогда не может содержать 0, за исключением самого последнего элемента, который не будет прочитан.
2. При его определении вам все равно придется использовать {} вместо "", поскольку большинство значений не содержат печатных символов ASCII. (И даже в этом случае вам придется написать " " для 32, например.)
3. На самом деле вы не можете напечатать предполагаемую строку, так как данные не будут содержать печатных символов. Вы получите любое сочетание цифр, букв, знаков препинания и забавных вещей, таких как пробел и новая строка, смешанные вместе. Вам нужно будет прочитать каждый символ и преобразовать его (например, с помощью String num = <your value here> или itoa() и т. д.).

Если вы хотите напечатать его, используя существующую функцию Arduino, например Serial.print, и это фактически строка (а не данные, притворяющиеся строкой), она изначально поддерживает __FlashStringHelper * , поэтому вам не нужен шаг преобразования (это позволяет вам выполнить Serial.print(F("Здесь не используется статическая RAM!")); и тому подобное).

Однако существует два способа чтения данных, если они предназначены для вашей собственной функции обработки строк. Первый, простой, не использует память и создает полную копию данных или строки в ОЗУ во время использования. В результате он не способен обрабатывать строки, которые слишком велики для ОЗУ, и могут возникнуть проблемы, если он вызывается, когда много ОЗУ уже используется, или он вызывается глубоко внутри набора вложенных функций. Однако это очень удобно:

//преобразование из __FlashStringHelper * как указано выше, но давайте предположим, что здесь это char*
int size = strlen_P(MY_ARRAY);
if (size!=0){
  char * data = new char[size];
  if (data!=NULL){
    strcpy_P(data,MY_ARRAY);
    // делаем что-то со строкой
    delete data;
  }
}

Второй метод более утомительный, и требует большего контроля над обработкой данных, но вы также можете считывать данные побайтно, как показано в моем первом примере декодирования выше, используя pgm_read_byte_near. Это позволяет работать с данными, которые слишком велики для размещения в оперативной памяти, а также поддерживает постоянный размер стека. Недостатком является то, что для этого требуется, чтобы вы действительно могли передавать данные байт за байтом во всех местах, где они затем используются (или чтобы вы перечитывали их, когда к ним нужно обращаться не по порядку).