roboforum.ru
Технический форум по робототехнике.
UART приём-передача файла
UART приём-передача файла
что-нибудь по-проще можете посоветовать?
Re: UART приём-передача файла
переведи
Re: UART приём-передача файла
Наверно z модем кокойнибудь. в примерах CVAVR например.
а может x или y модем подойдет ?
а может x или y модем подойдет ?
Re: UART приём-передача файла
подойдет то, что проще реализовать 
есть у меня вариант - просто конвертировать файл в хекс и передавать строку за строкой, но не кошерно ибо никакой проверки нет, да и совместимости с терминальными прогами - тоже. zmodem смотрю
P.S. делаю картридер для минибота
есть у меня вариант - просто конвертировать файл в хекс и передавать строку за строкой, но не кошерно ибо никакой проверки нет, да и совместимости с терминальными прогами - тоже. zmodem смотрю
P.S. делаю картридер для минибота
Re: UART приём-передача файла
Кодировать в base64 + crc32?
Re: UART приём-передача файла
сделал первый набросок. заморочки со скоростью страшные 
полмегабайта записывает на карточку за 10 мин на скорости порта 115200 бод 
алгоритм такой:
ББ: передаю 78байт данных + 2байта управления потоком(#10#13), ожидаю ответа устройства (2 байта), снова передаю до победного конца)
МБ: принимаю 78 байт, записываю в файл, отсылаю пакет готовности(2 байта + #10#13).
на стороне МБ обратного декодирования base64 пока нет.
такая скорость передачи - нормальное явление?
полмегабайта записывает на карточку за 10 мин на скорости порта 115200 бод алгоритм такой:
ББ: передаю 78байт данных + 2байта управления потоком(#10#13), ожидаю ответа устройства (2 байта), снова передаю до победного конца)
МБ: принимаю 78 байт, записываю в файл, отсылаю пакет готовности(2 байта + #10#13).
на стороне МБ обратного декодирования base64 пока нет.
такая скорость передачи - нормальное явление?
Re: UART приём-передача файла
посмотреть в сторону нормальных имеющихся протокольчиков....
залезть в кишки , например , к старому fastlynx (из под бут-дискеты дистрибутив win95 передавал с компа-на-комп минут 20..40)
залезть в кишки , например , к старому fastlynx (из под бут-дискеты дистрибутив win95 передавал с компа-на-комп минут 20..40)
Re: UART приём-передача файла
Мой совет. Начни со старого доброго Xmodem'a
Потратишь всего 1-2 вечера. И получишь рабочий вариант. Потом с (небольшой вероятностью) начнешь улучшать.
Можешь сделать свой, а можешь на развалах поискать.
Потратишь всего 1-2 вечера. И получишь рабочий вариант. Потом с (небольшой вероятностью) начнешь улучшать.
Можешь сделать свой, а можешь на развалах поискать.
Re: UART приём-передача файла
дык это и есть xmodem собственной сборки. посмотрю как улучшить, много времени тратится на приём пакета.
собственной сборки. посмотрю как улучшить, много времени тратится на приём пакета.Re: UART приём-передача файла
c xmodem от hyperterminal есть заморочка: на самом деле простокол не xmodem, a xmodem-crc; отличие заключается в подсчете последних двух байт: в первом используется контрольная сумма, во втором - crc16, причем полином пришлось подбирать долго итого получилось так:
итого получилось так:- Код: Выделить всё • Развернуть
Иннициализирующее значение : $0000
Выходная XOR маска : $0000
Входные данные : не инвертируются
Выходной CRC перед XOR : не инвертируется
Значение полинома : $1021 (Зеркальное значение = $8408)
Полином : x^16 + x^15 + x^2 + 1
Значение для '123456789' : $31C3
Re: UART приём-передача файла
с гипертерминалом дельного что-то ничего не получилось, так что вводим эхозащищенную модификацию xmodem-crc.
управляющие символы:
новый символ - _can означает отмену передачи/приема, отсылается только приемной строной. необходимость в нём может возникнуть в случае пропуска целого пакета (ситуацию можно отследить по двум packet number байтам). кстати, маркеры пакета и команды управления передачей полностью различны у передатчика (_sot,_eot) и приемника (_ack,_nack,_c,_can).
чуть изменился пакет:
данные передаются в base64, что автоматически не допускает возможность подмены управляющих символов последовательностью данных. далее, crc16 считается для пакета данных, а не их base64 представления, чтобы зря не терять точности обнаружения ошибок. символ конца пакета позволяет передавать сколь угодно малую порцию файла (нужно для экономии оперативной памяти на устройстве).
благодаря модификации удалось получить:
управляющие символы:
- Код: Выделить всё • Развернуть
_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 - прервать операцию
- _ack - пакет принят без ошибок, жду следующий
- передатчик соотвественно команде либо отсылает новый пакет, либо повторяет предыдущий
- допустим, номер пакета вышел за границы 0xFF, тогда следующий номер - 0x00
- после последнего пакета передатчик отсылает символ _eot до тех пор, пока не получит _ack или _can
Re: UART приём-передача файла
есть заморочка с base64: в баскоме функция кодирования работает только для нуль-терминированных строк. понятно, что как только в файле встречается байт 0x00, пакет формируется неверно.
поэтому написал кодировщик [[UUE]]
поэтому написал кодировщик [[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