Гвоздик

Уважаемые админы, возможно ли обьединить две учетные записи Гвоздика и Enthusiast'а в одну учетную запись Enthusiast'а? Учётку Гвоздика можно было бы удалить, а его сообщения подписывать Enthusiast'ом. Все данные на получившуюся учетную запись можно взять из Enthusiast'а. Это возможно сделать? Мне было бы проще пользоваться форумом под одной учётной записью. Зачем я занял две учетные записи? С возрастом люди меняют место жительства, автомобиль, жён и мужей - это признак взросления. Правила форума я нарушил, каюсь.

Спешу поправить на верное название зайлинксовской программы стыковки с "Матлабом", которую я использовал - "AccelDSP".

Некоторое время назад я тоже столкнулся с задачей вычисления алгоритма с дробными числами на ПЛИСине. По моим практическим наблюдениям опенкоресные и закрытые от копирования умножители, сумматоры и делители чисел с плавающей запятой работали слишком медленно, чтобы их можно было серьезно применять. Решением оказалось применение Матлаба в связке с зайлинксовским "AccelEDA". Все исходные данные и результат автоматически приводились Матлабом к целым числам соотвествующей разрядности. Точность вычислений терялась, но в пределах ТЗ. Зато написать все и отмоделировать можно очень быстро.

При прошивке через СДФлэш с плагином через последовательный порт необходимо вогнать по сбросу микроконтроллер в режим загрузки с последовательного порта или можно в любое время прошивать, т.е. загрузившись с внутренней флэш памяти? Т.е. при программировании через последовательный порт с компьютера необходимо ли подтягивать выводы микроконтроллера, отвечающие за способ загрузки, к состоянию загрузки с последовательного порта? Про флэш АПИ я прочитал, пробовал писать и читать во внутреннюю флэш память микроконтроллера. Медленно, но работает. Однако, я не нашел ни слова об адресации и способе "укладки" файла прошивки во внутреннюю флэш память микроконтроллера. Там ведь пароли нужно куда-то писать и т.п. На зарубежных форумах нашел сообщение о предоставлении Тексасом загрузчика для перепрошивки микроконтроллера по КАНу и без исходников. В наилучшем случае хотелось бы перешивать микроконтроллер в рабочем режиме через последовательный порт с компьютера или другого микроконтроллера без использования утилиты СДФлэш. Кто-нибудь делал подобное?

Каким образом можно перепрошить процессор без использования внутрисхемного эмулятора? Замысел состоит в удаленном обновлении прошивки. Прошивку планирую хранить во встроенной в процессор флеш-памяти. В обычном режиме запускаться оттуда же. Хотя это можно и изменить. Видел несколько способов загрузки, в том числе и с последовательного порта (УАРТа). Это как-нибудь может помочь? Буду рад совету.

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

Что ж, смелое утверждение на мой взгляд. А не могли бы Вы подробнее сказать почему? И что на Ваш взгляд более предпочтительно Майкрочипу?

Поделюсь впечатлениями от использования этой Flash API: стирание одного сектора размером 8 КСлов (16 КБ) происходит за 5 секунд, а всей флэш-памяти контроллера размером 128 КСлов (256 КБ) за 80 секунд. Хотел применить внутренную флэш-память контроллера для хранения параметров, однако из-за такой скорости придется заливать их во внешнюю флэш. Для перепрошивки, впрочем, вполне сгодится.

Вчера проверил обмен данными по CAN'у с этими приемопередатчиками от Майкрочипа, все работает как и было задумано. Так что домыслы о нестабильной работе микросхем от Майкрочипа оказались не более чем слухами.

Ножками "подрыгали", толку нет, задержка таже - 15 мс и более. Для сведения пробовали мы измерять задержку с использованием аппаратного последовательного порта RS-232C на том же оборудовании с тем же ПО. Задержка от отправки 8 байт запроса до приема 8 байт ответа составила 3..5 мс в зависимости от материнской платы ПК. Т.е. в три раза быстрее, чем по УСБ с микросхемой от FTDI, вот такие вот пирожки печет FTDI. Придется на микроконтроллере с УСБ "на борту" делать заново, пока смотрю в сторону Майкрочипа, драйверы и АПИшные библиотеки для Винды они прилагают.

Спасибо за совет по таймауту. Однако, это мы уже пробовали и неоднократно. На самом деле изменение значения таймаута таймера в драйвере не помогает, квалификации виндового программиста я доверяю. Подергать ножкой попробуем, может и поможет. Если не секрет, то какова задержка от отправки до приема пакета с применением микроконтроллера с USB "на борту"?

Здравствуйте, уважаемые форумчане! Сначала кратко опишу существующее оборудование: преобразователь сигналов из USB в RS-485, созданный на основе микросхемы FTDI RS232RL; внешний аппаратный блок, отвечающий на запросы по шине RS-485; персональный компьютер с интерфейсом USB. Скорость обмена на шине равна 1 Мбит/с, что нас вполне устраивает. Суть загвоздки в следующем: при замере времени от выдачи команды с ПК до приема ответа на него проходит не менее 15 мс, причем внешний аппаратный контроллер вносит задержку не более 1 мс. В пачке содержится 8 байт запроса и 8 байт ответа. При уменьшении скорости обмена по шине RS-485 время между запросом и ответом увеличивается, но незначительно. Основная задержка остается примерно одинаковой (15 мс). Мы пробовали сначала использовать виртуальный последовательный порт для работы с компьютера, потом переписали ПО под использование динамических библиотек, пытаясь увеличить скорость обмена, все безрезультатно. Похоже, что микросхема от FTDI упорно вносит эту задержку выдачи первых данных в шину. Скажите, пожалуйста, уважаемые форумчане, какие еще существуют наиболее простые в исполнении решения для ведомого устройства на шине USB? Скорости в 1 Мбит/с нам вполне достаточно, необходимо лишь уменьшить время отклика хотя бы до 5 мс. Если использовать микроконтроллер с USB "на борту", какая задержка приемопередачи данных будет в этом случае? Идеальным решением было бы применение готовой микросхемы, принимающей данные из USB-шины и выдающую их в параллельном или последовательном виде, и наоборот. Это для того, чтобы избежать дополнительных иженерных усилий по программированию и технологических операций при изготовлении. Буду рад совету.

Наверное я сделал не очень грамотно, но я для непрерывного чтения потока бит из флэшки вообще весь протокол сделал программным, т.е. не используя аппаратного ЭсПиАйя. Получилось так, что для чтения 1 КБ чистых данных требуется 18 мс (вместе с обменом служебной инфой). Скорость, конечно, далеко не та, что с использованием аппаратного ЭсПиАйя, однако, вполне удовлетворяет ТЗ 8-) А вы ловко придумали использовать ДМА буфер, я не додумался 8)

Здравствуйте. Мысль такая: во время работы из внутреннего ОЗУ процессор, получая новую версию прошивки извне, перепрограммирует свою внутреннюю флэш-память программ, затем перезапускается по сбросу от сторожевого таймера. Где можно об этом почитать? Буду рад совету.

Ну что же, практика все покажет.