http://www.spetspribor.com/support/software/wake/wake.html
к сожалению исходники для AVR на ассемблере
Если у кого есть на си поделитесь пожалуйста.
Полная версия этой страницы: WAKE исходники на С для AVR
На
http://www.spetspribor.com/support/software/wake/wake.html
к сожалению исходники для AVR на ассемблере
Если у кого есть на си поделитесь пожалуйста.
http://www.spetspribor.com/support/software/wake/wake.html
к сожалению исходники для AVR на ассемблере
Если у кого есть на си поделитесь пожалуйста.
Цитата(Леонид Иванович @ Jul 21 2006, 09:53) 
Спасибо что ткнули носом. Буквально несколько дней назад на ихнем сайте небыло этого исходника.
Я уже начал перелопачивыть "wusource.zip" под АВР а тут такое счастье.
Так я увидел сегодня эту тему и выложил 
Если будут вопросы, пишите.
Если будут вопросы, пишите.
Цитата(Леонид Иванович @ Jul 21 2006, 13:30)
Так я увидел сегодня эту тему и выложил Если будут вопросы, пишите.
Если будут вопросы, пишите.Ухты! Так это Вы автор WAKE-а!
Тогда Вам
и Спасибо 
за протокол.А вопросы конечно же будут
.Вот первый:
Как из main-а узнать передался ли пакет?
Т.е. примерно такая ситуация:
Код
Pc_Tx_Frame();
while( ??? ){} // ждать окончания передачи
while( ??? ){} // ждать окончания передачи
Что подставить вместо "???"?
Цитата(otrog @ Jul 21 2006, 14:01)
Тогда Вам и Спасибо за протокол.
и Спасибо за протокол.Я рад, что кому-то протокол пригодился.
Цитата(otrog @ Jul 21 2006, 14:01)
Как из main-а узнать передался ли пакет?
Т.е. примерно такая ситуация:
Что подставить вместо "???"?
Т.е. примерно такая ситуация:
Код
Pc_Tx_Frame();
while( ??? ){} // ждать окончания передачи
while( ??? ){} // ждать окончания передачи
Что подставить вместо "???"?
После завершения передачи последнего байта пакета Pc_Tx_Sta становится равным SEND_IDLE. Но нет смысла подвешивать Main на всё время передачи пакета. Ведь передача ведётся по прерываниям в фоновом режиме, Main может в это время выполнять другие задачи. А проверить, закончилась ли передача пакета, можно в любой момент.
Подобная проблема актуальна на стороне PC при использовании RS-485 в полудуплексном режиме, когда требуется переключение направления. Под Win затруднительно определить момент окончания передачи посылки. Для Win98 эта проблема решается использованием недокументированного сервиса драйвера COM-порта для получения базового адреса микросхемы UART и прямым чтением ее регистра. Для Win 2000/XP это решается использованием режима RTS TOGGLE, который работает, правда, весьма тормознуто. В любом случае управление сигналом RTS для переключения направления должно осуществляться внутри DLL. В ближайшем будущем я планирую добавить поддержку RS-485 в wsp32.dll.
Цитата
В любом случае управление сигналом RTS для переключения направления должно осуществляться внутри DLL
Зачем это нужно? Переключение направления осуществляется на интерфейсной плате RS-485 автоматически.
Цитата(Igor26 @ Jul 24 2006, 08:55)
Переключение направления осуществляется на интерфейсной плате RS-485 автоматически.
В общем случае, от замены _приемопередатчиков_ RS232 на RS485 никакой "автоматики" не добавляется в принципе.
Это в случае полного дуплекса не добавляется, а в полудуплексе на RS485 надо переключать Rx/Tx.
Цитата(Tran @ Jul 24 2006, 09:43)
Это в случае полного дуплекса не добавляется, а в полудуплексе на RS485 надо переключать Rx/Tx.
Речь идет не о том, что надо или не надо обеспечивать, а о том, что такую функциональность за Вас
тупые приемопередатчики сами собой не обеспечат, посему и вешается переключение на RTS, например.
Цитата(Igor26 @ Jul 24 2006, 08:55)
Зачем это нужно? Переключение направления осуществляется на интерфейсной плате RS-485 автоматически.
Адаптеры RS-232 -> RS-485 с автоматическим переключением направления значительно дороже, к тому же, есть проблемы с выбором скорости передачи (многие из них требуют задания скорости с помощью DIP-переключателей).
2 Леонид Иванович
Вот возник еще вопрос по WAKE.
Как отследить момент окончания приема пакета на стороне МК? Т.е. мне нужно после окончании приема пакета от PC и при отсутствии ошибок, отправить ответный пакет от МК.
Делаю так:
Но это явно не правильно. А как надо?
Спасибо.
Вот возник еще вопрос по WAKE.
Как отследить момент окончания приема пакета на стороне МК? Т.е. мне нужно после окончании приема пакета от PC и при отсутствии ошибок, отправить ответный пакет от МК.
Делаю так:
Код
if ((Pc_Rx_Sta == WAIT_FEND) && (Command != CMD_ERR)) // проверка наличия нового пакета ???????????
{
if (Command == 0x24)
{
PC_TX_ADDR = PC_RX_ADDR;
Pc_Tx_Cmd = Pc_Rx_Cmd; // команда
Pc_Tx_Nbt = sizeof(Parameters); // размер посылки
ptr = (unsigned char *)&Parameters; // указатель на начало посылки
for (i=0;i<sizeof(Parameters);i++) { Pc_Tx_Dat[i] = *ptr++; } // переписать посылку в буфер
Pc_Tx_Frame(); // отправить посылку
}
}
{
if (Command == 0x24)
{
PC_TX_ADDR = PC_RX_ADDR;
Pc_Tx_Cmd = Pc_Rx_Cmd; // команда
Pc_Tx_Nbt = sizeof(Parameters); // размер посылки
ptr = (unsigned char *)&Parameters; // указатель на начало посылки
for (i=0;i<sizeof(Parameters);i++) { Pc_Tx_Dat[i] = *ptr++; } // переписать посылку в буфер
Pc_Tx_Frame(); // отправить посылку
}
}
Но это явно не правильно. А как надо?
Спасибо.
to Леонид Иванович
за WAKE действительно большое спасибо
разбирались с ним год назад по исходникам на Си под UNIX
насколько я помню там в одном месте был баг: при генерации пакета стаффингу мог подвергаться байт контрольной суммы (если имел соотв.значение), однако при приеме байт контрольной суммы обрабатывался без учета того, что он мог быть застаффингован - т.е. сбои могут идти очень редко - только в тех пакетах, в которых байт контр.суммы подвергнут стаффингу.
.
ЗЫ: наверняка сейчас подправили это, но на всякий случай: пользователи WAKE будьте бдительны =)
за WAKE действительно большое спасибо
разбирались с ним год назад по исходникам на Си под UNIX
насколько я помню там в одном месте был баг: при генерации пакета стаффингу мог подвергаться байт контрольной суммы (если имел соотв.значение), однако при приеме байт контрольной суммы обрабатывался без учета того, что он мог быть застаффингован - т.е. сбои могут идти очень редко - только в тех пакетах, в которых байт контр.суммы подвергнут стаффингу.
.
ЗЫ: наверняка сейчас подправили это, но на всякий случай: пользователи WAKE будьте бдительны =)
Цитата(otrog @ Aug 2 2006, 15:22)
Вот возник еще вопрос по WAKE.
Как отследить момент окончания приема пакета на стороне МК? Т.е. мне нужно после окончании приема пакета от PC и при отсутствии ошибок, отправить ответный пакет от МК.
Как отследить момент окончания приема пакета на стороне МК? Т.е. мне нужно после окончании приема пакета от PC и при отсутствии ошибок, отправить ответный пакет от МК.
По успешному завершению приема пакета в переменую Command будет помещен код команды, пришедший от PC. Основная программа на микроконтроллере должна мониторить переменную Command, как только в ней появился код команды, это команда должна выполниться. По окончанию выполнения команды основная программа отправляет ответ PC с кодом выполненной команды и в Command загружает код отсутствия операции CMD_NOP.
Если пакет принят с ошибкой (например, не совпала CRC), в Command обработчиком прерывания по приему помещается код CMD_ERR. В ответ на это основная программа должна передать в PC пакет с кодом команды CMD_ERR без параметров.
Чтобы было понятней, выложил куски исходников здесь:
http://upload.caxapa.ru/Wakesample.zip
Цитата(Doka @ Aug 2 2006, 16:17)
разбирались с ним год назад по исходникам на Си под UNIX
насколько я помню там в одном месте был баг: при генерации пакета стаффингу мог подвергаться байт контрольной суммы
насколько я помню там в одном месте был баг: при генерации пакета стаффингу мог подвергаться байт контрольной суммы
Под UNIX не работаю, но DLL под WINDOWS такого бага не содержат.
Большое спасибо за протокол. И самое главное - за поддержку.
Сожалею, что года черыре назад всего этого еще не было...
Сейчас вынужден притягивать за уши ради совместимости со старыми устройствами свой,
который уже давно не устрамвает по некоторым причинам...
Сожалею, что года черыре назад всего этого еще не было...
Сейчас вынужден притягивать за уши ради совместимости со старыми устройствами свой,
который уже давно не устрамвает по некоторым причинам...
Большое спасибо за протокол. И самое главное - за поддержку.
Сожалею, что года черыре назад всего этого еще не было...
Сейчас вынужден притягивать за уши ради совместимости со старыми устройствами свой,
который уже давно не устрамвает по некоторым причинам...
Сожалею, что года черыре назад всего этого еще не было...
Сейчас вынужден притягивать за уши ради совместимости со старыми устройствами свой,
который уже давно не устрамвает по некоторым причинам...
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.