Может ли увеличение размера программного буфера RX вызвать проблемы в Arduino Uno?

Если бы я увеличил размер буферного массива с 64 до, скажем, 512, возникли бы какие-либо долгосрочные проблемы в Arduino Uno?

Изменение с этого:

#ifndef _SS_MAX_RX_BUFF
#define _SS_MAX_RX_BUFF 64 // Размер буфера приема
#endif

к этому:

#ifndef _SS_MAX_RX_BUFF
#define _SS_MAX_RX_BUFF 512 // Размер буфера приема
#endif

Это заголовочный файл программного последовательного порта.

, 👍0


3 ответа

4

Буфер находится в ограниченной (2 КБ) оперативной памяти UNO; вы будете использовать 1/4 из нее для входного буфера. Если ваше приложение достаточно маленькое и простое (в частности, ограниченная глубина вызовов), для его успешного запуска все еще может быть достаточно оперативной памяти. Если у вас много глобальных переменных (не забудьте включить библиотеки, когда вы рассматриваете использование оперативной памяти), выделите много памяти из кучи (с помощью new или malloc()) или у вас сложная структура вызовов, такая, что funcA() вызывает funcB() вызывает funcC() вызывает ... (и т. д.), так что кадры стека многих функций остаются выделенными одновременно — в любой точке вашей программы — ваша программа может пострадать от стековой коллизии: стек вызовов опускается достаточно низко, чтобы он мог перезаписать или быть перезаписанным вашей кучей или глобальными данными.

Зачем вам такой большой входной буфер? Будут ли данные поступать с высокой скоростью или большими пакетами, а обработка данных будет нечастой или происходить нерегулярно? Учитывая ограниченный объем оперативной памяти в UNO, запуск сложных программ на одном из них может потребовать балансировки в том, как вы используете ресурсы.

Обновление:

Я выполнял некоторые AT-команды с программным последовательным портом и ограничением буфера, генерирующим мусорное значение

Другие причины, по которым SoftwareSerial может возвращать неверные данные:

  • Использование слишком высокой скорости передачи данных (9600 бод, похоже, это максимум);
  • Код, который слишком часто или слишком надолго отключает прерывания;
  • Другие устройства, создающие слишком много прерываний (возможно, встроенный таймер, работающий с высокой скоростью).

Ответы на AT-команды большинства известных мне устройств достаточно короткие, чтобы не требовать огромного буфера приема. Запрос списка SSID WiFi от ESP8266 может сгенерировать большой ответ, но большинство ответов не должны переполнять более скромный буфер.

,

Спасибо за совет. Дело в том, что я выполнял некоторые AT-команды с помощью программного последовательного порта, и ограничение буфера генерировало ненужные значения. Но я думаю, что, немного отредактировав свой код, я смог исправить эту проблему, но мне все еще нужно немного больше буферной памяти., @Charles

0

Большинство модулей arduino имеют 2k ram. Так что подумайте об этом. Нужно ли вам больше буфера или больше рабочего пространства. Имейте в виду, что другие библиотеки также используют ту же ram.

,

Я отправляю некоторые символы через программный последовательный порт, и ограничение в 64 байта приводит к появлению нежелательных значений. Поэтому я увеличил значение по умолчанию до четырех раз, чтобы получить больше места для хранения моего буфера., @Charles

@Nolawisolomon, возможно, стоит сначала передать длину сообщения, а затем всё остальное, как в http. Таким образом, получатель будет знать, сколько байт ему нужно зарезервировать., @Mert Gülsoy

@Nolawisolomon - буфер *RX* имеет мало общего с передачей, если только вы не имеете в виду, что передаете данные в режиме блокировки и не обращаете никакого внимания на *полученные* данные, пока не завершится длительная передача., @Chris Stratton

1

SoftwareSerial сохраняет индексы начала и конца в виде беззнаковых символов, поэтому в любом случае нет необходимости устанавливать размер буфера больше 256...

,
Смотрите также: