Jump to content

    

vguard

Участник
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

0 Обычный

About vguard

  • Rank
    Участник

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. По мне так хороший прибор соблюдает сам стандарт, но подстраивается под некритичное отклонение от стандарта своих собеседников. Пользователю прибора не нужно строгое соблюдение стандарта в ущерб надежности связи с различными коммуникационными устройствами. Ему не важна химия, ему важно чтобы спички горели. Пример. Некоторые преобразователи Ethernet<->RS485 (например moxa) разбивают длинные modbus пакеты на несколько более коротких. В результате, по шине RS485 пакет приходит частями с паузой превышающей требование стандарта. Ваш принципиальный прибор не сможет работать с такими преобразователями, и очень вероятно будет заменен на продукцию конкурента. Есть смысл таймауты при приеме пакета сделать конфигурируемыми.
  2. При всем уважении, Ваше утверждение о том, что на текущий момент fastboot+yocto является пром стандартом для загрузки LINUX ни на чем не основано и не имеет подтверждений в документации и исходниках от TI. Для загрузки linux TI предоставляет свою версию u-boot.
  3. Это для загрузки Android а не linux. Документ называется AM335x_Android_eMMC_booting. А для загрузки linux u-boot рулит.
  4. To MIkler. Вот ссылка на скрипт из yocto для сборки u-boot: http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-bsp/u-boot Вот ссылка на изменения u-boot от TI: https://git.ti.com/gitweb?p=ti-u-boot/ti-u-boot.git;a=summary - последний коммит 22 часа назад. Где можно узнать об альтернативе u-boot для загрузки linux от TI под названием fastboot?
  5. TI предоставляет свое SDK на базе Yocto. По мере исправления ошибок и поддержки новой функциональности в загрузчике/ядре/драйверах/скриптах и т.п., выходят новые версии SDK (раз в 3-4 месяца). Да, Yocto тормознутая, да, бывало, процесс сборки завершается ошибкой, для исправления которой требуется несколько дней копания в питоновском коде. Но, перейдя на buildroot, процесс поддержки исправлений от TI и opensource сообщества (переход на новые версии u-boot/kernel), как минимум, станет трудозатратнее.
  6. 1. Код не рабочий. Второй и третий циклы while (pg < 16000) будут либо бесконечными, либо завершаться в разных местах. 2. Писать на SD большой кусок побайтово плохая идея. Пишите большими блоками.
  7. Подкину дров. 1200 за комплект.
  8. Интересно было бы понять сколько таких программаторов, на текущий момент, в месяц продает Чип и Дип, не госконторам, а считающим деньги разработчикам. А так на avito полно китайских альтернатив примерно в районе 1000-2000руб. Но может с китайскими альтернативами могут быть проблемы с обновлением. У Вас оригинал от segger и это наверное гораздо лучше.
  9. Готов забрать программатор ну скажем за 500руб + доставка за мой счет.
  10. Отсутствие уведомления о выборе другого исполнителя и последующий игнор обычное свинство. Это показатель отношения к другим людям.
  11. Ваши рассуждения верны. Пульт шлет скорость и наклон, для чего еще шлет пакет F9/9F Вам до лампочки, просто шлите его также. Соответственно для решения задачи Вам нужно примерно с теми же паузами между пакетами слать 3 пакета: 00 FF F1 02 00 (скорость) CRC 00 FF F6 02 00 (наклон) CRC 00 FF F9 00 90 - запрос непонятно чего, скорее всего защита от применения пульта с другими дорожками, потому что в ответе 6-й байт формируется явно по какому-то хитрому алгоритму. Почему-то относительно ранее присылаемых логов у Вас байты в новых логах развернулись (старший бит стал младшим и наоборот). Но это не принципиально байты развернете как нужно без проблем.
  12. Дорожка то работает? Может передатчик механической (приводной) части сдох, и не пересылаются ответы по RS485. Этим объясняется и то, что пакеты пересылаются по 8 раз повторно. Центральный контроллер не получает ответ от приводов и повторяет запрос 8 раз. Приводная часть кстати может работать, потому что ее микроконтроллер не знает что передатчик сдох. Подключитесь снова к шине RS485 и посмотрите там трафик. Если даже такое произошло, то лечится заменой микросхемы драйвера RS485.
  13. Имхо, выложенного Вами с ошибками объема данных для анализа недостаточно. Если хотите раскрутить протокол, объем измерений должен быть на порядок больше. Длительности 5 секунд, в которой всего 9 пакетов (80 30 9F ...) недостаточно, нужно хотя бы пол минуты для начала. Естественно не путать дампы. Как работают кнопки тоже не понятно. Позволяют ли кнопки длительное нажатие, при котором скорость (наклон) дорожки изменяется. Или одно нажатие приводит к одному шагу изменения скорости (наклона) дорожки, вне зависимости от длительности нажатия. Допустим в протоколе передается код нажатой кнопки (а это может быть и не так), тогда Вам нужно нажать кнопку и держать в течение всего измерения, а не давить кнопку несколько раз.
  14. Ну возьмите, например, первый и второй из опубликованных Вами файлов и сравните в WinMerge/WinHex или любым другим образом и убедитесь что файлы одинаковые. Все опубликованные. Или расскажите мне как эти Ваши файлы выгрузить в Excel?