esaulenka

Ну вот на подобном все эти обсуждения и заканчиваются. В итоге-то что? Сломали? Или просто потратили? А контроллер какой?

И ни разу при этих обсуждениях не было конкретики. Разве что ссылки на отдельные откровенно "дырявые" камни каких-то начальных ревизий. Но и эти "дырки" достаточно оперативно "затыкались".

"там в кейле" необходимо и достаточно объявить этот несчастный массив как const и ничего больше не трогать. А "мегоудобные визарды" ничерта не работают, если хранить во флеше настройки, загрузчик и прочие нестандартные извращения. Впрочем, по статьям на кейл.ком конфигурация линкера пишется легко и непринуждённо, главное - понимать, чего хочется :-)

Насколько я понимаю, вообще никак не настроены фильтры. Поройте в эту сторону. В комментарий "нафиг" я не верю, возможно, фильтр настроен на id=0. Аргументировать (с копаниями в ST'шной библиотеке) лениво :-)

Нет, это какой-то другой глюк. У нас на нескольких машинах 5.11 так себя ведёт, если стоит галка "use cross-module optimization". Раньше работало нормально, в т.ч. и с этой галкой. Детально не разбирался - сейчас переехали под gcc, keil - только для ковыряний в "музейных" проектах.

Сразу предупреждаю, что IAR я видел лет 5 назад, и то это был IAR AVR ;-) Всё правильно, только одно НО: не надо дописывать типовой файл, надо поискать где-то рядом такой же файл, уже модифицированный под Ваш AT91SAM3X8E (или линейку AT91SAM3X.. ). Просто даташит подсказывает, что у этого контроллера 44 вектора прерываний. Аккуратно заполнить их все можно, но зачем эта обезьянья работа? У Keil'а, кстати, нужное Вам прерывание обзывается TC0_IRQHandler. И ещё. FIQ у Cortex'ов отсутствует, для разрешения прерываний (если их запретил стандартный стартап, опять же не знаю специфики IAR'а) нужен __enable_irq().

В STM32F4xx загружал основной код в RAM. Работает именно так, как и должно, граблей не обнаружено. В тот момент - keil, но ничего не мешает обучить линкер любого другого компилятора. Другой вопрос. Кто и как загрузит этот бутлоадер? Основной код? Так проблема обычно в том, что в самый нужный момент этот основной код сломался, и его срочно нужно заменить.

У Атмела есть даже специальный аппноут "как автоматически калибровать RC по внешнему сигналу". Вру. Гугл по запросу "avr internal rc calibration" выдаёт аж три атмеловских документа. Пользуйтесь :-)

Почти правильные. Микроконтроллер должен отправить строчку "AT+CREG?\r\n". Особое внимание - на перевод строки. Перекодировкой этого безобразия в ascii-коды вручную заниматься ни в коем случае не надо - иначе этот код невозможно будут читать.

Чтобы не быть голословным, что "плохие процессоры "эль" взламывают, а хорошие процессоры "ка" - не взламывают", можно увидеть ссылочки на проделанные работы? И порядок цен интересен. Не корысти ради, а из любопытства, когда нам клиенты наши собственные прошивки принесут. Исправленные и дополненные.

errata на статическую память коротенькая, это в более новых камнях с SDRAM треш и угар какой-то... Методом тыка обнаружил, что отключение burst приводит к нормальной работе. Документация только требует, чтобы для burst адреса все были выровнены (это я делаю, причём с запасом - там требования к границе 1 килобайт, я выравниваю на мегабайт - в тестовом коде не жалко). Больше никаких требований нету... Странно всё это. И жалко - burst во внутреннее ОЗУ работает на 10% быстрее. Update. Как и следовало ожидать, самдурак. В документации есть раздел "FIFO threshold and burst configuration" - там многие варианты запрещены. Почему оно работало с внутренним ОЗУ - загадка...

Ситуация. Есть STM32F4xx с внешней шиной, на которой висят SRAM и NAND. Вздумалось мне оптимизировать код, и в функции чтения NAND конструкцию for (i = 2112/4; i; i--) *buffer32 ++ = (*(volatile uint32_t *)(BANK_NAND_ADDR | NAND_DATA_AREA)); заменил работой с DMA (использую DMA2, Stream0) Всё работает прекрасно, пока буфер находится во внутренней памяти. Но стоит перенести его во внешнюю память, DMA ломается. Счётчик данных уменьшается на 32 dword'а (я 32-битными данными работаю, адреса выровнены), регистр FIFO сообщает, что FIFO пустое. А дальше - всё - счётчик данных "тикать" больше не хочет, биты в регистре статуса не устанавливается, enable не сбрасывается. Это фича такая? Что-то я нигде описания не нашёл...

uint8_t x; for (x = 0; x < 16384; x++) Мде. И что, просто "не работает", или вообще "виснет нафиг" ? И вообще - ничерта непонятно (тут мало кто наизусть декламирует даташит на этот LPH9135), некрасиво и неоптимально.

Питание и земля в порядке?

Справедливости ради: это неправда. Там есть assert_param(), который можно включить на этапе разработки драйверов, и который хоть что-то проверяет. Впрочем, я и сам стараюсь обходиться без этой чудо-писанины, просто по ref.manual.

Доброго дня. Нужен совет по архитектуре типичнейшей задачи, как правильно соорудить передачу по UART. Мы используем кучу уартов, работая через прерывания. Далее - копипаста по нескольким uart'ам, различающаяся только указателями на uart, и на буфер: обработчик прерывания, который перекладывает байты из софт-буфера (ну и наоборот, в буфер); API - функции "получить 1 байт", "передать 1 байт", "передать N байт". Типичное использование на передачу - функция формирует пакет и налету скидывает его порциями в буфер. Так вот, все примеры общения с DMA, что я видел - сформировать большой буфер, настроить DMA на его передачу, курить бамбук, пока всё не отработает. С нашим API как-то не очень совместимо - постоянно останавливать-запускать DMA при добавлении в очередь ещё одного байта совсем плохо. Я что-то пропустил, или передача по DMA на мою задачу никак не ложится?

Это плохая идея в мире контроллеров, у которых ОЗУ и без того мало.

Можно просто и быстро проверить, что происходит - поискать в выводе линкера (двойной клик на самой первой строчке в дереве проекта с названием таргета) слово "CodeKey" (т.е. название Вашего массива). Дальше внимательно смотрим, по какому адресу оно расположилось, и ищем соответствующий диапазон в документации. Кейл под арм по умолчанию затолкает такой массив во флеш. Кейл под 51-й видел только в страшном сне (надо было в чужом проекте две строки поменять).

К слову сказать, на 2410 у меня криво-косо, но задышал хост от LPC23-что-то-там (это тоже OHCI). Чуть лучше заработал какой-то непонятный китайский стек (был подобран на каком-то варезнике с иероглифами). Разве что скурить нормально работу MMU и USB у меня не получилось. Глючило, что интересно, каждый раз по-новому. Пришлось на время работы стека (у меня это всего несколько секунд, просто проверить наличие воткнутых usb-устройств) отрубать нафиг кэши. Поскольку никакого функционала не требовалось (это был загрузчик с всевозможными "фишечками", основную работу выполняла wince), так оно и осталось. Давно только это было... А по делу - при текущем уровне вопросов про USB лучше не вспоминать. Если что-то пойдёт не так, поможет только многотомная спецификация. Разбираться в этом - то ещё удовольствие...

Если __packed struct, то второй вариант лучше. Если так, как есть, то пофигу совершенно. Разве что char c,d,e во второй вариант проще дописать - можно писать в конец, а объем не увеличится. И да, если заморачиваться с оптимизацией до такой степени, то надо писать не float, а int ;-)

Та-а-ак... А четвёртый куда? :-)

Что-то я неправильно акценты расставил. Пунктом раз пойдёт стоимость, а только пунктом два - потребление. Платить по баксу-полтора откровенно жалко. Но за идею спасибо...

Дискретные входы обсудили, пора приступать к дискретным выходам :-) Задача следующая: выдавать в нагрузку меандр амплитудой 10 вольт. Частота - от нуля до десятка килогерц, к фронтам особых требований нет. Нагрузка, для простоты, резистор в пол-килоома. На входе - контроллер обыкновенный, трёхвольтовый. Ещё хочется обеспечить сравнимые импедансы выхода в режимах "1" и "0" - есть подозрение, что некоторые особо интеллектуальные нагрузки способны его мерять, впадая в состояние "короткое замыкание по входу", если там разница на порядки. Также существует вопрос энергопотребления: в "спящем" режиме наше устройство выдаёт "ноль" и должно потреблять как можно меньше. Ещё хорошо б минимизировать стоимость и место на плате. Собственно, какие я вижу варианты: - открытый коллектор с подтяжкой. Не проходит по энергопотреблению; сильный разброс импедансов в режиме "вкл" и "выкл". - двухтактный эмиттерный повторитель, зараза, сигнал не инвертирует! И сигнал на входе нужно 10-вольтовый. Соответственно, надо ставить перед этим каскадом ещё один NPN, и в спящем режиме он будет открыт. Да и три транзистора с тремя резисторами места сколько-то занимают... - компаратор, запитанный 10 вольтами, сравнивающий входной сигнал с полутора вольтами. Но компараторов с push-pull, а не с открытым коллектором, очень мало.. Собственно, что я пропустил? Склоняюсь к эмиттерному повторителю - потреблять эта конструкция должна раз в 200 меньше, чем текущее решение (открытый коллектор). И ещё с благодарностью приму советы, какие особенности могут быть у цифровой схемы. Понятно, что никакими смещениями можно голову не забивать ввиду отсутствия "нуля" в общепризнанном аналоговом смысле.

Не понял, у Вас не usb-host, а usb-device (картридер) ? Согласно описанию, The LM3526 provides Universal Serial Bus standard power switch and over-current protection for all host port applications Т.е. она нужна для того, чтобы защититься от пользователей, которые будут засовывать всякую дрянь в Ваш хост. По бедности даже в хост можно её не ставить, ограничиться предохранителем (многие производители материнских плат так и делают). В девайсе она так и вовсе не нужна - продумать схему, чтобы она не горела и не выдавала лишнего мусора при включении (где-то в спецификации USB была оговорена емкость конденсаторов по Vbus), а защиту пусть на стороне хоста ставят.

Ну елки ж палки... http://electronix.ru/forum/index.php?showtopic=102112 Ещё было б неплохо указать параметры "другого устройства".