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

guest53493

Участник
  • Постов

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

  • Посещение

Репутация

0 Обычный
  1. Не особо надеюсь на удачу, но вдруг. Был когда-то такой ARM Firmware Suite - сборник загрузчиков, отладочных мониторов и т.п., которые прошивались изготовителем во флэш микроконтроллеров типа LPC21xx, LPC23xx и др. В инете я его нигде не нашёл, в том числе и на сайте ARM - везде только даташиты. Здесь, на форуме, его тоже искали, но это было больше 10 лет назад! :) Может, у кого-нибудь валяется где-нибудь, а? Выложите, пожалуйста!
  2. Здравствуйте! Разбираюсь с интерфейсом VNC1L. Задача: записывать данные в файл на USB-флэшке. Работаю через UART. Запись происходит очень медленно - файл размером 1 Мб записывается около 7 минут. Пробовал на разных скоростях (от 115200 до 3Мбит), при включенном и выключенном RTS/CTS. Результат примерно одинаковый, если не хуже. Гугление дало только одну более-менее вразумительную ссылку - на этот форум (https://electronix.ru/forum/index.php?showtopic=32406). Вопрос: можно ли как-то увеличить скорость записи в файл? Я так понимаю, использование SPI скорости тоже не прибавит?
  3. Здравствуйте. Ситуация такая. LPC2388. CAN настроен на прерывание по приёму. Прерывания исправно генерятся, сообщения принимаются. Но когда запрещаю аппаратные прерывания (SPSR.I = 0), сообщения начинают теряться. Я ничего не имею против, но по идее CAN при этом должен выставлять бит overrun в статусе. А этого не происходит. Так как же CAN на данном МК принимает сообщения при запрещённых прерываниях?
  4. Всё заработало. Короче, надо внимательно следить за настройками (в моём случае - PCONP и Acceptance Filter). А кейловский пример не работал потому, что Acceptance Filter был настроен не на тот идентификатор, который я посылал из скрипта. На кейловском форуме надоумили. :)
  5. Спрашивал на форуме. Даже расписал по шагам, как воспроизвести это на кейловском же примере. Но они там, похоже, не читатели, а писатели, поэтому пишут пока хрень типа "ты наверное прерывания неправильно настроил". :) Ладно, посмотрим, что дальше будет...
  6. Отлаживаю программу в IDE и пытаюсь сэмулировать прерывание от CAN с помощью следующего отладочного скрипта: func void CAN_transmit(void) { CAN1ID = 0xC7; // CAN message ID CAN1L = 7; // message length CAN1B0 = 0x07; // message data byte 0 CAN1B1 = 0xD4; // message data byte 1 CAN1B2 = 0x0C; // message data byte 2 CAN1B3 = 0x1F; // message data byte 3 CAN1B4 = 0x0A; // message data byte 4 CAN1B5 = 0x01; // message data byte 5 CAN1B6 = 0x00; // message data byte 6 CAN1B7 = 0x00; // message data byte 7 CAN1IN = 1; // send CAN message } define button "Send CAN message", "CAN_transmit();" Программа рабочая, т.е. на реальном железе прерывания генерятся как надо, но в симуляторе почему-то этого не происходит. Вопрос: а вообще с помощью отладочного скрипта возможно сэмулировать прерывание от CAN? У кого-нибудь получалось? Инет на эту безмолвствует, в лучшем случае есть что-то про эмуляцию прерываний для 8085. P.S. А вот от UART прерывание по нажатию клавиши генерится! :)
  7. Спасибо ответившим. У меня наоборот: без эха работало корректно, с эхом - хрень. При внимательном прочтении описания протокола обмена обнаружилась интересная деталь: Короче, я подозреваю, дело у меня было вот в чём. Загрузчик воспринимает три типа строк: с '\r' на конце (ввод с клавиатуры), с '\n', и с '\r\n'. При этом, после получения '\r' он, видимо, ещё некоторое время ждёт '\n', и, если тот не приходит, считает это концом строки и начинает выдавать свой ответ. У меня программатор работает посимвольно, т.е. посылает символ - ждёт эха - сравнивает ответ - посылает следующий символ и т.д. Я думаю, что пока я дожидаюсь эха на '\r', сравниваю ответ и посылаю следующий '\n', наступает таймаут ожидания и загрузчик решает, что строка закончилась. Всё нормально заработало, когда я стал завершать все вводимые строки не '\r\n', а '\n'. Что интересно, все известные мне программаторы заканчивают строки на '\r\n', но все они посылают команды строками, а не посимвольно. При этом ответы всегда приходят с '\r\n' на конце, независимо от вида строки запроса. И да, без эха всё работает ощутимо быстрее. Основное время приходится на передачу данных по UART.
  8. Возникла необходимость написать собственную программу прожига прошивок для LPC2129 (версия загрузчика 1.70). При реализации протокола ISP обнаружилась следующая особенность. Когда посылаешь команду через UART, загрузчик, как известно, по умолчанию возвращает эхо этой команды. Команда должна заканчиваться парой символов возврата каретки и перевода строки ('\r\n'). Так вот, бывает так, что в эхе символ '\r' приходит, а '\n' - нет. А вместо '\n' приходит, например, буква 'O' (первая буква слова OK - результат выполнения команды). У меня прога ждёт эха на каждый отосланный символ, поэтому, естественно, возникает ошибка. Проблему эту, конечно, можно обойти, но всё-таки интересно - это такая "особенность" ISP или я делаю что-то не так? Знающих прошу отозваться. :)
×
×
  • Создать...