SoftwareSerial не будет читать всю напечатанную строку при вызове readString()

Я вижу 2 проблемы с вашим кодом:

• Вы написали в комментариях, что файл JSON огромен. У Uno всего 2 КБ ОЗУ, а вы пытаетесь сразу весь файл привести в ОЗУ. Такой файл JSON от Spotify легко превысит 2 КБ (на самом деле у вас даже меньше, потому что фреймворк Arduino и SoftwareSerial также используют часть оперативной памяти). Таким образом, вы просто не сможете одновременно обрабатывать весь файл с помощью Uno.

• Вы используете readString(). Эта функция, безусловно, проста, но также имеет некоторые подводные камни. Он использует класс String, использующий динамическое выделение памяти. Он выделяет больший массив символов в ОЗУ, если текущий массив недостаточно велик. Это означает, что вам потребуется до 2 версий вашей строки, помещающихся в ОЗУ при получении, оставляя только около 1 КБ. Также он будет считываться из интерфейса SoftwareSerial, пока не истечет время ожидания (я думаю, по умолчанию 1 с). Для создания надежной связи между двумя устройствами вы должны читать до тех пор, пока не дойдете до специального символа, например, с помощью readStringUntil(). Этот специальный символ часто представляет собой символ новой строки '\n'.

Возможное решение: Сначала следует поговорить о проблеме ограниченного объема оперативной памяти. Как указано выше, вы не можете обрабатывать весь файл сразу. Вы должны обрабатывать это кусками. Что бы вы ни хотели сделать с данными в конечном итоге, Uno потребуется некоторое время для обработки текущего фрагмента данных. Поэтому вам нужно приостановить передачу данных на ESP, пока Uno не будет готов принять больше. Тут можно пойти двумя путями:

• Отправлять данные блоками предопределенного размера (достаточно маленькими для того, чтобы Uno мог сразу хранить их в своей ОЗУ) и ждать предопределенное время между каждым блоком, которого достаточно для того, чтобы Uno обработала все данные, которые он мог получить. тот кусок. Это проще всего запрограммировать, но обязательно потребуется больше времени на выполнение.
• Позвольте Uno сигнализировать ESP о том, что его буфер заполнен, например, отправив специальный символ в ESP. Затем ESP должен прекратить отправку, пока не получит разрешение от Uno на продолжение передачи. Чтобы отправить без потери данных, Uno, вероятно, также должен отправить количество байтов, полученных в этом фрагменте. Таким образом, ESP точно знает, где в строке данных находится Uno в данный момент. Это немного сложнее, но все же достаточно просто и надежно.

Для обработки отправки фрагментами я бы использовал метод write(const uint8_t *buffer, size_t size) класса SoftwareSerial (на самом деле эта функция исходит из класса Print, от которого наследуется SoftwareSerial). Буфер — это указатель на первый элемент текущего фрагмента в массиве char с данными. Вы можете получить массив char с помощью spotData.c_str(), и вы можете получить указатель на n-й его элемент с помощью &(spotData.c_str ()[n]). Второй параметр — размер чанка в байтах. Он должен быть достаточно маленьким, чтобы данные поместились в ОЗУ UNO вместе со всей оперативной памятью, необходимой для обработки данных.

На Uno я бы читал побайтно. Что-то вроде этого:

char data[BUFFER_SIZE]="";
int pos=0;

void loop(){
    if(ardSerial.available()){
        data[pos] = ardSerial.read();
        if(pos == BUFFER_SIZE - 1){
            // Обработка блока данных
            pos = 0; // сброс позиции для повторного использования буфера
        } else {
            pos++;
        }
    }
}

Я пропустил некоторые части, чтобы продемонстрировать принцип. Также вам необходимо самостоятельно определить BUFFER_SIZE в зависимости от доступной оперативной памяти.

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

Помимо отправки и получения вам нужно будет подумать о том, как обрабатывать блоки данных. Это во многом зависит от того, что именно вы хотите делать с этими данными. Просто отправить их через Serial очень просто. Интерпретировать данные фрагментами сложнее.