Перейти к содержанию

my504

Свой
  • Публикаций

    178
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о my504

  • Звание
    Частый гость
  • День рождения 24.09.1959

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    М.О. г.Фрязино
  1. про MPLAB SIM вопрос

    Вы решили сами написать стек для USB device? :biggrin: Осторожно предложу Вам ознакомиться с ГОТОВЫМ стеком в MLA (под произвольный класс USB) дабы понять характер и объем задачи. Если Вам лень прочитать ограничения MPLAB SIM, приведу Вам цитату из мануала на сей инструмент в применении к PIC18F:
  2. про PCLATH вопрос

    Чуть добавлю. Смысл команды movff совсем не в краткости записи. Эта команда, не модифицирует контекст (аккумулятор и флаги состояния АЛУ). И именно в таком качестве ее следует применять. Если аккумулятор и флаги могут быть произвольно изменены, то нет никакого практического смысла в применении movff.
  3. про MPLAB SIM вопрос

    Открываете мануал на симулятор (MPLAB SIM) и смотрите ограничения (Limitations) Если мне не изменяет память, модуль USB не симулируется. Да и симулировать там что либо стремно - слишком большой нужен буфер. Я правил HID USB device из MLA на 18F14K50 под себя. Никакой отладки не потребовалось, тем более, что дебаг в этом МК перекрыт расположением USB на пинах ICSP.
  4. про PCLATH вопрос

    Я в курсе. Речь шла о Вашем упоминании.
  5. про PCLATH вопрос

    Нынче и все относительно новые 12...16-ые тоже позволяют. Причем даже проще, чем 18-ые. Флеш доступен, начиная с адреса оперативной памяти 0x8000.
  6. про PCLATH вопрос

    Под hight label кроется номер сегмента, в котором размещена таблица. Если таблица имеет размер более одного сегмента, то hight label нужно предварительно вычислить. При выполнении команды RETLW в таблице, возврат произойдет БЕЗ ПРИВЯЗКИ К PCLATH, поскольку стек имеет ПОЛНУЮ РАЗРЯДНОСТЬ счетчика команд. Из чего следует, что Ваши выкрутасы с вершиной стека не имеют никакого смысла и лишь приведут к разрушению стека. Регистр PCLATH - это просто буфер, с помощью которого синхронизируют изменение младшего байта счетчика команд с изменением старшего байта того же счетчика. Никакого отношения PCLATH не имеет к самому PC (PCL:PCH), который собственно и управляет выборкой из программного флеша очередной команды.
  7. дадада... Все участники альянса выработавшего стандарт ошибаются, а наш упрямый товарисч - нет. Пешы исчо.
  8. Милейший, как Вы сами понимаете, мне совершенно безразлично что Вы допускаете и куда Вы это допущенное относите. Я, как и Вы, пользуюсь лишь общепринятой терминологией. А эта терминология ДОПУСКАЕТ использование четырехпроводной RS485. Гомерически смешно доказывать это или иное "по очкам". На основании чего я делаю окончательный вывод об ошибочности Вашего начального комментария. Тем более, что он не имел никакого отношения к поставленному ТС вопросу.
  9. Мне начинает надоедать хождение по кругу: https://www.maximintegrated.com/en/app-note...ndex.mvp/id/736 http://ftp1.digi.com/support/documentation/90000848-88.pdf https://www.moxa.com/doc/manual/OPT8I/OPT8I_HIG_v1.pdf https://www.mikrocontroller.net/attachment/39674/digione.pdf http://dinorte.com.ar/pdf/RS485_RS422_Basics.pdf Нужно еще? Или все они ошибаются? Вот еще Аналог девайс с ЯВНЫМ указанием в заголовке на full duplex RS485 http://www.analog.com/media/en/technical-d...5_4856_4857.pdf Вот у Техаса https://www.ti.com/lit/ds/symlink/iso35.pdf http://www.farnell.com/datasheets/1856006.pdf Вот еще: https://www.surveillance-video.com/media/la...mport/D1315.pdf http://www.8051projects.net/files/public/1...s458_on_avr.pdf Можете сами поискать в интернете по ключевой фразе full duplex RS485
  10. И я применяю. Но ни Ваши применения, ни мои ничего не доказывают. Вы полагаете, что я не читал?)))) Можете ограничиться правой главной рамкой из статьи. Внизу этой рамки ПРЯМО указано на наличие и полнодуплексного и полудуплексного режимов, а так же обозначения сигналов для обоих этих случаев. Это Ваша фантазия. RS485 может иметь как одну, так и две витых пары. И даже в даташитах Аналог девайса на ДУПЛЕКСНУЮ ADM488/489 прямо так и указано про RS485: http://www.analog.com/media/en/technical-d.../ADM488_489.pdf Это так же Ваша фантазия. Мало того, я так же как и Вы долгое время был в аналогичном заблуждении. ЗЫ. В догон: https://www.maximintegrated.com/en/app-note...ndex.mvp/id/736
  11. Ремарка ошибочна. RS485 - это многоадресный (в т.ч. мультимастерный) дуплекс или полудуплекс С ВОЗМОЖНОСТЬЮ ВЕТВЛЕНИЯ линии RS422 - это дуплекс Р2Р Читаем: https://ru.wikipedia.org/wiki/RS-485 https://ru.wikipedia.org/wiki/EIA-422
  12. 1. 115200 бод - это скорость передачи ОДНОГО БИТА и именно эта скорость является декларируемой в интерфейсах применяющих УАРТ. 2. При вашем кварце получить точно 115200 невозможно - получаемая сетка частот УАРТа допускает ближайшую частоту 111709. Это ошибка -3%. С такой ошибкой УАРТ будет работать с другим устройством, где выставлена скорость 115200 БЕЗ ВСЯКИХ ПРОБЛЕМ. 3. Совершенно непонятно о какой иной "скорости с учетом задержек" Вы пытаетесь рассуждать. Время передачи одного байта (режим 8 бит) равна 10*время передачи бита=86,8 мкс. Задержки между байтами определяются возможностями КОДА обрабатывать входящий и исходящий поток. Причем возможностями кода С ОБЕИХ СТОРОН. Нет и не может быть никаких нормативов по этому поводу. Если с обеих сторон на прием и на передачу работает ДМА, то брутто скорость будет почти не отличима от нетто. Если через прерывания, то зависит от упаковки данных в МК и латентности обработчика прерываний. Если в программном режиме - значит от латентности кода суперлупа (главного цикла). 4. Определить скорость обмена на уровне данных можно с помощью осциллографа и свободного пина, который инвертируется всякий раз, когда завершается прием блока данных. Смотрим осциллографом длительность импульса на этом пине и получаем брутто-скорость обмена. 5. Протокол обмена должен содержать элементы СИХРОНИЗАЦИИ данных, то есть нужно помимо самих данных передавать метки начала блока данных (при фиксированной длине блока), а так же слово верификации этих данных (CRC8, например). Кроме того, интерфейс RS485 может быть как дуплексным, так и полудуплексным. Сиречь, обмен может быть как одновременно в обе стороны, так и поочередно. Во втором случае появляются так же управляющие байты мастера к слейву с целью обозначить направление передачи.
  13. objcopy для pic30/xc16

    А симулятор реализует RTSP? Что то я не припомню такой возможности у него?
  14. objcopy для pic30/xc16

    Дебаггер (аппаратный через ICSP) не работает непосредственно с релизом кода. Для запуска отладки нужен цельный исходник (вместе с отладчиком), который будет скомпилирован в код ДЛЯ ОТЛАДКИ. В этом коде даже маппинг ОЗУ перемещен, так как работа дебаггера требует использования части ОЗУ. Единственным методом отладки при работе с произвольным кодом прошитым через бутлоадер, является формирование своего канала обмена данными между кодом и софтом на ПК. При отладке через житаг ситуация иная, но Вы ничего не упоминали про житаг. ЗЫ. Присмотрелся к сканам. А о какой отладке идет речь. когда в среде вообще нет подключенного отладчика?
  15. Извините, но Вы - жертва стереотипов. С чего Вы взяли, что строки для LCD будут обязательно определены как DB? Элементарно и целесообразно их определять как DW. Но дело даже не в этом. Я не понимаю чем поможет восстановлению исходника отделение полей констант. Ну отделили, и что? И LCD может быть графическим, и упаковка графики не иметь формата экрана, а состоять из примитивов... Опять же главное в восстановлении исходника - восстановление глобального алгоритма, а так же выделение основных функций этого алгоритма. Поэтому начинать надо с выделения main, то есть участка общей инициализации и главного цикла (суперлупа). И из функций вызываемых этим циклом развернуть остальной код. А где будут константы, - укажут команды табличного чтения. Это элементарно и определяется В САМОМ КОНЦЕ реверсинжиниринга.