А 64КБ двоичный файл с ПК передавать кто будет?
А Ардуине какая разница?
Ее дело слушать COM-порт и все пришедшее писать в EEPROM.
Максимум, о чем она может догадаться, это что на той стороне провода CH340 (но это не точно).
Разница в том, с какой скоростью будет идти передача. Так вот, terminal передаёт с интервалом между байтами, поэтому буфера на 64 достаточно. При нормальной же передаче, за время записи ЕЕПРОМ ~8мс, этот буфер переполнится.
Начт, нужен транспортный протокол с квитированием. Пока не придет ответ о готовности принять “следующую партию”, не отправлять.
на DTR резет заточен остаётся тока XON-XOFF
я не про физический протокол
А что, запись в EEPROM - блокирующая? Она разве не происходит аппаратно из буфера?
Физически, в ЕЕПРОМ передаётся блок данных, после чего нужно тупо ждать 5мс, потому что в это время ЕЕПРОМ отключается от TWI. Поэтому просто нужен ещё один 128-ми байтный буфер, который бы заполнялся во время ожидания конца записи. А ещё проще снизить скорость до 57600. Ну будет писаться 18 секунд, вместо 9-ти, подумаешь.)
Вот и я про то же. У Хмодем-а именно такой протокол. С подтверждением, с CRC, с повторами. А тогда не будет ограничения на скорость UART. Т.е., UART может работать быстрее чем I2C.
1 лайк
Всё так, как Грин вещает: чтобы гарантировать запись и обойтись без особо замороченных вычислений - нужно что-то из нижеперечисленного:
- занижать UART передатчику скорость , чтобы сравнять её со скоростью записи в EEPROM при максимальной задержке;
- иметь большой быстрый буфер (в идеале - на весь объём данных);
- взаимодействовать с передатчиком на предмет старт/стоп/повтор.
Я тут поэкспериментировал слегка. Никакие софтверные XON/XOFF не помогают - иногда происходят потери символа в момент отключения передатчика. Может, конечно, криво написал код…
просто аппаратный буфер на 1 байт - мало, хотя бы 16, но лучше 64
PS Петрович поправит, если я не прав, он как-то обмолвился, что достаточно
Цифры из катушки? Не стоит их сюда транслировать.
ну да в IBM же дураки сидели, когда компорты закладывали
Какое отношение к твоему высказыванию имеет IBM?
там у компортов буфер 16 байт почему-то
Где - там и как это должно повлиять на ситуацию здесь?
Но, если получится быстро принимать, то тогда уже ЕЕПРОМ будет лимитировать общее время записи. А тут уже будет определять скорость интерфейса (I2C/SPI) и сама память (ЕЕПРОМ, FRAM, FLASH) с ихней размером сектора и временем записи. Для 24LC512 чуть больше 4-х сек минимум. Вот и подумаешь, стоит ли за это бороться.) Другое дело, если таких 24LC512 несколько.
Возможно, я чего не понимаю, но терминал не сможет переслать значения чисел, лишь их ASCII код. Тогда вопрос: зачем вообще пересылать что- либо в Ардуино , ведь на лету сортировать неудобно, всё равно придётся записать весь файл, ну или хотя-бы по-блочно заморачиваться…
Как по мне, лучше или
сразу писать в EEPROM, ну а затем уже разбираться.,
или
решить вопрос на ПК, тем более он от ардуинки не сильно и отличается, тоже язык Си понимает))
Не понимаешь. Терминал может то, что ты себе даже не представляешь. На данный момент. Пока не загуглишь.)
Спасибо, буду разбираться