UART приём-передача файла

MiBBiM

что-нибудь по-проще можете посоветовать?

EdGull

переведи

avr123.nm.ru

Наверно z модем кокойнибудь. в примерах CVAVR например. http://www.hpinfotech.ro/html/download.htm

а может x или y модем подойдет ?

MiBBiM

подойдет то, что проще реализовать

есть у меня вариант - просто конвертировать файл в хекс и передавать строку за строкой, но не кошерно ибо никакой проверки нет, да и совместимости с терминальными прогами - тоже. zmodem смотрю
P.S. делаю картридер для минибота

Vooon

Кодировать в base64 + crc32?

MiBBiM

сделал первый набросок. заморочки со скоростью страшные

полмегабайта записывает на карточку за 10 мин на скорости порта 115200 бод

алгоритм такой:
ББ: передаю 78байт данных + 2байта управления потоком(#10#13), ожидаю ответа устройства (2 байта), снова передаю до победного конца)
МБ: принимаю 78 байт, записываю в файл, отсылаю пакет готовности(2 байта + #10#13).
на стороне МБ обратного декодирования base64 пока нет.
такая скорость передачи - нормальное явление?

nest

посмотреть в сторону нормальных имеющихся протокольчиков....
залезть в кишки , например , к старому fastlynx (из под бут-дискеты дистрибутив win95 передавал с компа-на-комп минут 20..40)

zubr

Мой совет. Начни со старого доброго Xmodem'a
Потратишь всего 1-2 вечера. И получишь рабочий вариант. Потом с (небольшой вероятностью) начнешь улучшать.
Можешь сделать свой, а можешь на развалах поискать.

MiBBiM

дык это и есть xmodem

собственной сборки. посмотрю как улучшить, много времени тратится на приём пакета.

MiBBiM

c xmodem от hyperterminal есть заморочка: на самом деле простокол не xmodem, a xmodem-crc; отличие заключается в подсчете последних двух байт: в первом используется контрольная сумма, во втором - crc16, причем полином пришлось подбирать долго

итого получилось так:

Код:

Иннициализирующее значение  : $0000
Выходная XOR маска          : $0000
Входные данные              : не инвертируются
Выходной CRC перед XOR      : не инвертируется
Значение полинома           : $1021 (Зеркальное значение = $8408)
Полином                     : x^16 + x^15 + x^2 + 1
Значение для '123456789'    : $31C3

MiBBiM

с гипертерминалом дельного что-то ничего не получилось, так что вводим эхозащищенную модификацию xmodem-crc.
управляющие символы:

Код:

   _eot = &H04         'End of Transmission
   _ack = &H06         'Acknowledge
   _nack = &H15        'Not Acknowledge
   _c = &H43           'ACII "C"
   _can = &H18         'Cancel Transmission

новый символ - _can означает отмену передачи/приема, отсылается только приемной строной. необходимость в нём может возникнуть в случае пропуска целого пакета (ситуацию можно отследить по двум packet number байтам). кстати, маркеры пакета и команды управления передачей полностью различны у передатчика (_sot,_eot) и приемника (_ack,_nack,_c,_can).
чуть изменился пакет:

Код:

[Start of Header] [Packet Number] [~Packet Number] (Packet Data,base64) [[16 bit CRC]] [End of Packet]
квадратные скобки - один байт
~Packet Number - дополнение Packet Number до 0xFF, т.е. Packet Number + ~Packet Number = 0xFF

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

произвольный размер пакета (но из-за base64 кодировки обязательно кратный 4 байтам)
полная защита от эхо-эффекта
возможность прервать передачу

как это все работает:

приемник отсылает _c, символизирующий готовность принять данные. если передатчик не среагировал, то отправка повторяется ещё 2 раза. если же и на этот раз возникла ошибка, то операция прерывается.
передатчик отсылает пакет под номером 1.
приемник может ответить тремя способами:
- _ack - пакет принят без ошибок, жду следующий
- _nack - пакет повредился, нужен повтор
- _can - прервать операцию
передатчик соотвественно команде либо отсылает новый пакет, либо повторяет предыдущий
допустим, номер пакета вышел за границы 0xFF, тогда следующий номер - 0x00
после последнего пакета передатчик отсылает символ _eot до тех пор, пока не получит _ack или _can

MiBBiM

есть заморочка с base64: в баскоме функция кодирования работает только для нуль-терминированных строк. понятно, что как только в файле встречается байт 0x00, пакет формируется неверно.
поэтому написал кодировщик [[UUE]]

Код:

Sub Uue_encode_print()
'кодирование в uue
   Const _amount = 7                                        'размер пакета/3-1

   Local B_buf As Byte : Local L_buf As Long : Local L_buf2 As Long
   Local Index As Byte : Local I As Byte : Local K As Byte

   For I = 0 To _amount
      Index = I * 3
      'три последовательных байта
      Incr Index : L_buf = Packet(index) : Shift L_buf , Left , 8
      Incr Index : L_buf = L_buf + Packet(index) : Shift L_buf , Left , 8
      Incr Index : L_buf = L_buf + Packet(index)
      'преобразование тройки
      L_buf2 = L_buf
      For K = 3 To 0 Step -1
         Index = K * 6
         Shift L_buf2 , Right , Index
         B_buf = L_buf2
         B_buf = B_buf And &B00111111
         B_buf = B_buf + 32
         Printbin B_buf
         L_buf2 = L_buf
      Next
   Next
End Sub

roboforum.ru

UART приём-передача файла

Кто сейчас на конференции