Надеюсь, что после экспериментов вы всё-таки избавитесь от .exe и перепишите всё на открытом Процессинге
Да перепишу.
Не всё так просто. Если вы смотрели код, то там видно, что как только начинается передача, то ВСЁ блокируется
а в каком месте, в файле upload нет никагого намека на цикл,есть
if (Serial.available() > 0) {
incomingByte = getBuffer(Serial.read());
но они не блокирующие, вот только к сожалению я не догадался во время обновления запустить пинг и посмотреть. Т.е.Вы хотите сказать что во время прошивки устройство блокируется?
Есть предположение, что контроллер по какому-то прерыванию отвлекается и пропускает символы.
контроллер работает на частоте 16 мгц,что такого мы должны делать в обработчике что бы пропускать символы на 9600 и еще с буферизацией,попробуйте по заливайте файлы, интерерует зависимость частоты ошибок от загрузки контроллера, upload построен таким образом что за один вызов uploadWorks(); мы считываем из буфера приема 1 байт с помощью
if (Serial.available() > 0) {
incomingByte = getBuffer(Serial.read());
в прерывании используется кольцевой буфер,может быть иногда промежутки между вызовами uploadWorks(); растягиваются до такого состояния что кольцевой буфер перезаписывается, если так то в файле upload нужно будет организовать явный цикл, видите там строчка
я начал пробовать но пока не доделал, только в понедельник.
Думаю надо сделать следующим образом, на задежки между вызовам uploadWorks() мы повлиять не можем, следовательно, внедрить в утилиту прошивки маркер начала обновления char START_MARKER[4]="STR"; для более уверенного входа в режим программирования передавать символы маркера с задежкой, чтобы устройство могло их гарантированно захватить, затем при обнаружении маркера организуется цикл while, таким образом отсекаются вызовы других функций, по окончании процесса обновления цикл сворачивается и все продолжается обычным порядком, могу попробовать только в понедельник.
