Переход с УНО на ESP32

Проекты Проекты @lilik
1

Пока не пришёл экран e paper на 4,2 дюйма пробую адаптировать ПО с одной платы на другую. Упёрся в строку

if (pgm_read_byte(ptr) & (0x80 >> (i % 8)))
с ошибкой
'pgm_read_byte' was not declared in this scope

Вопрос - почему? В файлах с массивами убирал слово PROGMEM, убирал #include <avr/pgmspace.h>
И везде проходило без ошибок запись вроде

SendData(pgm_read_byte(&blackimage[i + (j*width/8)]));

А тут ругань. Если так исправить, то компиляция проходит, но насколько это работоспособно проверить не могу - модуль ещё не пришёл.

if (/*pgm_read_byte*/(int)(ptr) & (0x80 >> (i % 8)))
2

Вот это заинклюдь.

3

Потому что для esp32 разработчики ядра выпендрились и поместили заголовочный файл не туда, где он у всех остальных ядер лежит )))

#include <pgmspace.h>
4

так если нет каталога avr где ей лежать )))

5

Действительно. И ведь создать нельзя ))

Для esp8266

#include <avr/pgmspace.h>

Для stm32 - и в ядре Кларка, и в ядре от производителя

#include <avr/pgmspace.h>

Для rp2040

#include <avr/pgmspace.h>

А все почему? Потому что PROGMEM - это чисто авровская заморочка, в остальных ядрах он присутствует только для совместимости, а потому заголовочники лежат по тому же адресу. И только у esp32 совместимость с подвохом ))

1 лайк
6

Ни на сколько можете не проверять :slight_smile:

2 лайка
7

“горделивою походкой…” )))
ЗЫ кто жеж знает как бы повёл себя каждый из нас будь он разработчиком ESP32
ЗЗЫ вот по какому пути лежит библиотека в ESP32:
E:\arduino-1.8.19\portable\packages\esp32\hardware\esp32\1.0.6\cores\esp32

а вот по какому в RP2040:
E:\arduino-1.8.19\portable\packages\rp2040\hardware\rp2040\3.0.0\cores\rp2040

“Дело было не в бобине” )))

8

Да ну? А у меня он аж по четырем разным папкам лежит. Поищи получше :wink:

ЗЫ: и, кстати, если ты заглянешь во внутрь приведенного тобой файла, то увидишь там только одну строчку

#include <avr/pgmspace.h>

Так что да, дело было не в бобине )))

9

ну и как тут не быть дураком? )))

10

Не умничать по первому же найденному файлу :wink:

1 лайк
11

Никак не быть :slight_smile:

12

“А так можно было” ??? )
имеем 4-ре файла в следующих каталогах (для RP2040):

  1. E:\arduino-1.8.19\portable\packages\rp2040\hardware\rp2040\3.0.0\tools\libbearssl\bearssl\inc
  2. E:\arduino-1.8.19\portable\packages\rp2040\hardware\rp2040\3.0.0\ArduinoCore-API\api\deprecated-avr-comp\avr
  3. E:\arduino-1.8.19\portable\packages\rp2040\hardware\rp2040\3.0.0\cores\rp2040\api\deprecated-avr-comp\avr
  4. E:\arduino-1.8.19\portable\packages\rp2040\hardware\rp2040\3.0.0\cores\rp2040

Для ESP32 (1.0.6) он один, савсэм адын:

  1. E:\arduino-1.8.19\portable\packages\esp32\hardware\esp32\1.0.6\cores\esp32

Для ESP8266 (3.0.0):

  1. E:\arduino-1.8.19\portable\packages\esp8266-300\hardware\esp8266\3.0.0\tools\sdk\ssl\bearssl\inc
  2. E:\arduino-1.8.19\portable\packages\esp8266-300\hardware\esp8266\3.0.0\cores\esp8266\avr
  3. E:\arduino-1.8.19\portable\packages\esp8266-300\hardware\esp8266\3.0.0\cores\esp8266
  4. E:\arduino-1.8.19\portable\packages\esp8266-300\hardware\esp8266\3.0.0\tests\host\sys
  5. E:\arduino-1.8.19\portable\packages\esp8266-300\tools\xtensa-lx106-elf-gcc\3.0.0-newlib4.0.0-gnu23-48f7b08\xtensa-lx106-elf\include\sys

умом точно не понять )))

13

Ты полез в дебри. Суть была в другом. Имеешь код для ардуино с использованием PROGMEM. Переносишь его на rp2040 - он работает без изменений (по крайней мере в части PROGMEM). А если переносишь его на esp32 - получаешь дулю :wink:

14

так там все эти файлы разные, лживый ваш C++

15

Совместимость требует жертв :wink:

16

То есть пишу это вместо #include <avr/pgmspace.h>, возвращаю назад слово PROGMEM и будет мне счастье? :slight_smile:

Ну почемууу? Так проходит

SendData(pgm_read_byte(&blackimage[i + (j*width/8)]));

, а так нет?

if (pgm_read_byte(ptr) & (0x80 >> (i % 8)))
17

Да… (точки - дабы добить до 5 символов )))

18

Про так я ничего не говорил.

Я говорил про вот так:

Надеюсь, здесь Вам понятно “почему”?
Потому, что Вы здесь вообще ничего не из какого прогмема не читаете.

19
  1. а откуда у тебя уверенность, что картинка лежит именно тут?
  2. какой смыл хранить её в блоке кода, когда есть сегмента DATA
20

Нет у меня никакой уверенности, да и понятия тоже :slight_smile: Но есть чёткая стратегия!

  1. ПО от разных производителей экранчиков взаимозаменяемы.
  2. ПО для уно легко переделывается для ЕСП32 и RP2040 .
  3. Мешают разного рода пустые формальности типа
SendData(pgm_read_byte(&blackimage[i + (j*width/8)]));

которая работает несмотря на отсутствие слов #include <pgmspace.h> и PROGMEM
. А тут встречается одна единственная строчка-условие и всё - нет компиляции.
Вот эта функция целиком:

void Paint::DrawCharAt(int x, int y, char ascii_char, sFONT* font, int colored) {
    int i, j;
    unsigned int char_offset = (ascii_char - ' ') * font->Height * (font->Width / 8 + (font->Width % 8 ? 1 : 0));
    const unsigned char* ptr = &font->table[char_offset];

    for (j = 0; j < font->Height; j++) {
        for (i = 0; i < font->Width; i++) {
            if (pgm_read_byte(ptr) & (0x80 >> (i % 8)))
            {
                DrawPixel(x + i, y + j, colored);
            }
            if (i % 8 == 7) {
                ptr++;
            }
        }
        if (font->Width % 8 != 0) {
            ptr++;
        }
    }

В своём триптихе я просто выкинул все файлы из ПО с букво-цифро-отрезкорисованием и не обратил тогда внимание на проблему.