Arduino.ru

А что ей размещать, если String - динамический тип?

Евгений, вы беспощадны ;)
Мож. подсказку ТС ждет, как правильно выполнять инициализацию массивом байтов.

Ага, обьект а не тип переменной

придется извращаться.

Размещать string 

кстати подскажите синтаксис для размещения в string чего, очень длинного в несколько строк, наподобие того, что в первом посте в String-е

Используйте Си-строки (char[])

https://arduino.stackexchange.com/questions/19330/store-string-using-f-m...

// String constructor with program memory string literal
String::String(const __FlashStringHelper *str);

А этот конструктор, поди, просто копирует из прогмема в рам?

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

Ну дык , а все равно, если у библиотеки, которую он юзает нет процедуры send, которая принимает строки из флеша, один хрен делать через озу придется. Или действительно размещать строки во флеше и писать процедуру передачи по одному байту.

Хотя на первый взгляд Ethernet.h юзает Print поэтому вероятно можно сделать как то так :

Ethernet.print(F("blablabla"));
Ethernet.println(F("blablabla"));

Ethernet.print(F("blablabla"));
Ethernet.println(F("blablabla"));

можно и без макроса F() отправлять строки из флеша прямо в print() без всяких промежуточных буферов. Print() принимает в качестве параметра ссылку на массив во флеше

Можно, но для одноразовых флеш строк так удобнее. Потому как макрос сам размещает эти строки во флеше и не нужно делать какие либо дополнительные танцы с бубном :)

Вы имеете в виду char * ? Как её что-то длинное присвоить? Если так, то посмотрите вот в этой теме. Там я это делаю во всех примерах, начиная с «Hello, World!»

А мне расскажите - в чем прикол PRGMEM? А чего памяти не хватает или вые-он местный?

Данные в переменных с аттрибутом PROGMEM не перегружаются в ОЗУ. Если их не требуется изменять, то зачем лишний расход ценного ресурса?

А в чём прикол этого вопроса? Ну, вот в этом проекте, битмапов для экрана (цифровой шрифт, значки, обозначения) почти на 10 килобайт, а опреативной памяти всего два. Зато программа не слишком большая и программной памяти свободной - завались. И как бы я без progmem выкрутился? Или ты про что-то другое спрашивал?

А чего ее жалеть. По любому иначе другие не менее ценные ресурсы потратятся.

Как говорил кролик из твоего мультика "я бывают разные !". Для кого то ценно ОЗУ, для кого то флеш, кто то и в епром всякую гадость пихает.

Ну да ,одни флеш экономят, другие озу, третьи быстродействие, некоторые свое личное время, которого не хочется тратить на рисование  новых и очень экономных библиотек и наконец есть те кто экономить свои нервные клетки, которые невосполняемый у человека ресурс. :))

Да нет - сам пользовал в свое время и экранную память. Но проектам, которые запрашивали прогмем, это было не нужно. Или это типа в развитие?

Вот пример - два скетча:

void setup() {
  Serial.begin(115200);
  Serial.print("tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt");
}

void loop() {
}

и

void setup() {
  Serial.begin(115200);
  Serial.print("t");
}

void loop() {
}

Как вы считаете есть ли разница в памяти используемой глобальными переменными ?

В общем адурино хранит все строковые переменные такого вида, вне зависимости от области видимости, в озу. Инициализируются они один раз при загрузке и сидят там пожизненно. Так что для таких плясок только прогрмем, кто бы что бы не говорил.

void setup() {
  Serial.begin(115200);
  Serial.print("tttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt");
}

void loop() {
}

void setup() {
  Serial.begin(115200);
  Serial.print("t");
}

void loop() {
}

А незачем такие глобальные переменные ИМХО. Надо битмап сохранять - так используй внешнюю память. И еще раз - тут я пока нигде не увидел необходимости в использовании програмной памяти.

О да , у меня занято 15% флеша и 70 озу. 

И надо было таблицу стилей с SD перетащить , а с нею стало занято 88% озу.

А я то думал, что прогмемы со String у меня работают o_О

Тут нет ни одной глобальной переменно !!! Но компилятор выделил место для текстовой строки в озу, так же как он выделил бы для глобальной... Че правда не втыкаешь ?

И что такое внешняя память у ардуино ?

Видимо я объяснить не смогу.

Если не знаешь зачем - не используй :) Квон прав.

Кстати о внешней памяти ... я тут FRAM прикупил i2с . Вроде как у ея анонсировано отсутствие износа в отличие от EEPROM.

завтра поиграюсь.

Это жжж неспроста - Вы что-то знаете из будущего их программ?

нафига внешняя память, когда внутренней еще полно?

>>>> занято 15% флеша и 70 озу.

И кстати, если вы не можете понять, как положить строки в ПРГМЕМ - вы думаете запихнуть во внешнюю ЕЕПРОМ по I2C вам будет проще? :)

ну про ПРОГМЕМ ты правда фигню сморозил. Попробуй на Атмеге328 собрать любую программу с длинными строчками - экранное меню какое или скажем СМС или HTTP - и очень быстро упрешься в ограничение ОЗУ, в то время когда флеша еще полно.

У меня уже привычка - если текстовых переменных больше 100-200 байт - автоматически уже кладу их в ПРОГМЕМ, даже если программа на 100 строк

Вы сами признались, что это привычка. Не стоит это рапространять на ЛЮБУЮ программу. Когда памяти не хватит - и я использую прогмем, внешнюю память, SD. Но не надо это вводить в религию.

Это у принта есть, а все остальное его наследники.

Если говорить про ESP, то смотря что ею считать. Если модуль, то внутренняя, если отдельную микросхему , то не знаю :)

Как раз для ардуино это и нужно туда вводить. Потому как кроме плюсов, лично я никаких минусов в этом не вижу.

Минусы есть - идиотские и необоснованные вопросы на форуме.

Идиотские вопросы появляются даже на вязальных форумах. 

+1000

Ты удивительно самокритичен сегодня...

Так в большом деле  с себя надо начинать :)

ну и ну, кажется я нечаянно спровоцировал БОЛЬШОЙ ПЯТНИЧНЫЙ СРАЧ :)

FRAM это не для css, это писать текущее состояние на предмет например неожиданного сбоя общего питания вместо организации кратковременного резервного питания для сохранения в еепром и ухода в слип.

оказалось,что  

client.println

замечательно поддерживает синтаксис типа

client.println(F("<div class=\"left-sidebar\">"));

что после небольших переформатирований исходника позволило добавить css и снизить использованность ОЗУ до 57%, что, учитывая стабильную работу на 70% , позволит воткнуть еще воз функционала, не переходя на  DUO.

также не могу не согласиться с уважаемым brokly: еще ни разу не испытывал дефицита FLASH , но о RAM приходится постоянно беспокоиться, потому отныне возведя в "религию" буду сразу писать с учетом дефицита RAM.

конструкция

                        webFile = SD.open(css_filename);        // open css file
                        if (webFile) {
                            while(webFile.available()) {
                                client.write(webFile.read());          // send css to client

                            }
                            webFile.close();
                        }

оказалась нестабильна, потому пришлось искать способ размещения css в PROGMEM.

возможно стабильнее было быгнать через буфер, типа

    myFile = SD.open(log_filename);         
           byte cB[64];
           int cC=0;
    while (myFile.available())
       {
         cB[cC]=myFile.read();
         cC++;
       if(cC > 63)
        {
         client.write(cB,64);
        cC=0;
        }
       }
   client.write(cB,cC);     
   myFile.close();
   client.println();

но было мало памяти :)

А че был срач ? А где был я ?
Я кстати сказать как раз и говорил о том, что флеша обычно валом, а вот ОЗУ не хватает. И настойчиво советовал матрос F.

Не ну конечно до срачей 2-3 летней давности с участием тех_о_ком_не_принято_упоминать далеко, но так, подсрачник :)

а по F я собсенно и последовал 

про чисса Си это не ко мне :)

с благодарностью ко всем , принявшим участие в обсуждении с  поздравлениями с наступившим 23.02 :)

Да..... чистый си....