esaulenka

Э-э... а ЛЮБЫХ ДРУГИХ мосфетов под рукой не было? Даже не из соображений, что для задачи "моргать диодом" это явный перебор, а просто потому, что "переключение по сигналам 0 и 5 вольт" тут работать не будет. Если подобрать правильные транзисторы (волшебное слово - logic level mosfet), всё будет работать. А если у Вас ещё и источник тока будет работать как источник тока, то ток через светодиод будет 70 мА. PS по характеристике транзистора видно, что если пропустить через него 2.2 ампера, на нём упадёт 0.7 вольта. А ещё по ней видно, что он откроется при 6..7 вольтах. Для надёжности делают больше, например 10 В, но никак не 5 В.

Первый признак любимых граблей эмбеддера: слово "прерывание" есть, а слова "волатайл" - нету.

Вообще-то там так и написано, что Контроллер CAN работает в обычном режиме ( НЕ Listen only Mode).

Можно у этого товарища спросить. Батарейки, подозреваю, одинаковые. http://www.parts4garmin.ru/product/1893789/ или http://www.parts4garmin.ru/product/1532351/

1. проверить, как себя ведёт плата, если её запитать, а потом перезапустить процессор (замыканием ноги reset, без всяких отладчиков) 2. сделать какой-нибудь вывод в консоль ошибочных ситуаций. Для CAN'а, скажем - не вошёл в режим конфигурирования, не вышел из него. Что с регистром статуса до передачи, после...

Если мне придётся снова работать с LPC'хами, буду делать библиотеку по образу и подобию. Когда-то у меня был набор макросов (в принципе, то же самое - задавался порт, пин, режим пина), но эти хитрые шаблоны удобнее. Варианты ЯadiatoR и AlanDrakes, которые прочитали даташит, явно неудобные. Пусть компилятор нужные смещения считает, он железный.

Взял куб (полугодовой давности, я его не обновляю за ненадобностью). Выбрал STM32F107 (кроме линейки 32F1xx у меня ничего не скачено - тоже не надо). Компилятор - кейл. Включил USB HOST (в режиме mass storage). Нажал кнопку "сгенерировать проект". Запустил кейл, скомпилировал (собралось сразу, честь и хвала!). RTX'ом не пахнет (какие доказательства предоставлять?). Заодно расскажите, как этот куб генерирует проекты и под кейл (якобы с RTX), и под IAR, и под GCC. Там везде RTX ? Или их супер-код сам собой адаптируется?

Странно, что никто не сказал, что единственный правильный путь - это STM32Tpl. Pin<'A',9>::Alternate (ALT_FUNC_USART1); Pin<'A',10>::Alternate (ALT_FUNC_USART1);

Не-а, они просто грабли поглубже спрятали. Если без RTOS у них взводится свой собственный флажок (см. макросы LOCK), то при наличии операционки даже он отсутствует. PS если проект ещё на стадии обдумывания, я б взял SD-карточку вместо этого USB. Там заметно прозрачнее всё устроено (хотя, конечно же, таймауты никуда не денутся, в соседней теме человек страдает...).

Вообще говоря, fprintf - штука довольно очевидная. Легко изучается, легко подменяется на свой велосипед. Времянки по ней посчитать тоже очень легко (хочешь в тактах, хочешь - осциллографом), и они достаточно стабильные. Разговор "всё может САМО поменяться" вообще ни о чём, с чуть меньшей вероятностью Земля завтра налетит на небесную ось. А вот ST'шная библиотека хоста - штука довольно странная. Изучать её можно долго, там наверчено хрен знает что. Можно ли это как-то значительно оптимизировать - не знаю... Бесплатных аналогов этой библиотеки не знаю. Хороших платных - тоже не знаю (в прошлой конторе работали с венграми HCC - тоже есть нарекания, но теперь ещё и за деньги; поддержка не очень помогает). Если не поможет добавление буферов (и запись данных не по одному байту!) - открывается большой простор для творчества и костылестроения. Можно, например, свой драйвер FAT сделать, который будет писать в заранее подготовленный файл - количество записей уменьшится вдвое, не нужно будет обновлять запись FAT. Нет, после всех предварительных действий там просто перекладывание данных из памяти в регистры USB. Правда, действительно, хост неадекватно себя ведёт, если приоритет прерывания достаточно низкий. Кто виноват, понять не удалось. Не читайте советских газет! Куб, конечно, много чего "без ведома" творит, но не настолько же. Кстати, куб в принципе не может работать под ОС (точнее, корректно обрабатывать обращения к одной и той же периферии из нескольких потоков). Хотя может уже и поправили это безобразие: stm32f1xx_hal_def.h #if (USE_RTOS == 1) #error " USE_RTOS should be 0 in the current HAL release " #else

У STM'ного уарта есть [плохо документированная] особенность - бит чётности "отнимается" из битов данных. Т.е. при включении чётности у Вас автоматически получится 7-битное поле данных.

Своё. Опытный образец, паяный-перепаяный, но очевидных косяков с питанием нету. Подозреваю, что из-за моих экспериментов "уплыли" стандартные тайминги стирания памяти (я перепрограммирую чип десятки раз в день. уже не первый месяц). Всё никак не одолжу у коллег других подопытных... Не понял вопрос. "Напрямую" из чипа загрузчик чудесно всё стирает, но я им редко пользуюсь. Я хоть и положительно отношусь к опенсорсу, но тут трындец какой-то... :-( Драйвера на jlink переставил (как теперь, интересно, j-flash'ем пользоваться?..). Покурил интернет, написал конфиг. Теперь следующий этап: у Вас SWO работает? Гугл сходу магическое слово не подсказывает. Но пишет-стирает без проблем, тьфу-тьфу...

Вот-вот, не надо NVIC_EnableIRQ() переписывать. Потому что в NVIC->ISER[1] |= (1 << (SPI1_IRQn & 0x1F)); уже есть ошибка. При дальнейшем увеличении прозрачности количество ошибок будет только расти...

Если это ПК, то никто не мешает сделать буфер не из байтов, а из пакетов (длина каждого - максимально возможная по протоколу). А дальше выгребать из массива побайтно и перекладывать в этот буфер. По окончании буфера запомнить состояние "работаем с пакетом №3, в нём 5 байт из N", при появлении следующего "массива" продолжить разбор. Буфер из пакетов, само собой, закольцованный.

Если "не изучать", можно найти всякие разные грабли. Как правило, ооочень невовремя. drozel, у меня используется следующая схема: usbd_poll() вызывается из прерывания, там есть два основных коллбэка: - out ep складывает принятые данные в буфер. Оттуда основная задача по мере сил и возможностей выгребает данные. - in ep пытается "достать" данные из буфера. Заполнение буфера и запуск передачи (однократный вызов write_ep()) - из основной задачи. В эту схему пакет нулевой длины легко приделывается, никаких while (write_ep(...)) {} не нужно. Хотя, конечно, кто ж им мешал возвращать отрицательные значения?.. PS полез рыться на репозитарий libopencm3, обнаружил те же самые грабли, но по обмену control endpoint. Исправили ровно неделю назад. Вот уроды, я ж в этот код уже несколько месяцев не лазил (все дескрипторы у меня короче)... До остальных эндпоинтов у них руки пока не дошли.

Хорошая практика - рисовать ПО на бумажке, в виде квадратиков и стрелочек. Ещё очень полезная абстракция - рисовать буфер в виде последовательности квадратиков-ячеек, с различными положениями указателей на этот буфер. Для выяснения вопроса "какая разница, кольцевой буфер" предлагаю нарисовать его в положении "добавление пошло на второй круг, положение указателя на добавление равно трём, запросили десять записей".

Если почитать-таки код в первом сообщении, там именно это и делается. "Для простоты" там, правда, нет указания, сколько же данных у нас запросили. И ещё, там нет кольцевого буфера (запись не вижу, а на чтение - точно нету!). Зато есть как минимум пара лишних переменных (чтоб никто не догадался). И очень удобный формат, в котором они возвращаются - полностью всё перепутано. Я б ТЗ стряс для начала. Сколько записей, сколько хранить, сколько считывать (считывать только так, или это только один из интерфейсов), ... А то опять угадайка "что хотел сказать автор" с нерабочим кодом...

Думаю, это неправильное желание. Аккуратнее, чем NVIC_EnableIRQ() можно сделать только битбангом. И то, не факт, что оно лучше будет (наверное, даже хуже - ядро будет делать read-modify-write, вместо записи одного бита). И смысл тогда этого велосипеда, если он будет такой же, только нестандартный?

Что-то я не понимаю, откуда весь сыр-бор. Таймер перестаёт тикать, если в ARR ноль. У таймера есть штатная возможность обновлять внутренний ARR в начале нового цикла. Что ещё надо?

Столкнулся с проблемой - отладка стартует через раз. В наличии STM32 и клон JLink'а от otladka.com.ua SEGGER J-Link GDB Server V4.98 Command Line Version JLinkARM.dll V4.98 (DLL compiled Mar 20 2015 18:23:08) -----GDB Server start settings----- GDBInit file: none GDB Server Listening port: 2331 SWO raw output listening port: 2332 Terminal I/O port: 2333 Accept remote connection: localhost only Generate logfile: off Verify download: on Init regs on start: on Silent mode: off Single run mode: on Target connection timeout: 0 ms ------J-Link related settings------ J-Link Host interface: USB J-Link script: none J-Link settings file: none ------Target related settings------ Target device: STM32F105VC Target interface: SWD Target interface speed: 1000kHz Target endian: little Connecting to J-Link... J-Link is connected. Firmware: J-Link V9 compiled Apr 21 2015 18:10:40 Hardware: V9.10 S/N: /* i'm paranoid */ Feature(s): GDB, RDI, FlashBP, FlashDL, JFlash Checking target voltage... Target voltage: 2.99 V Listening on TCP/IP port 2331 Connecting to target...Connected to target Waiting for GDB connection...Connected to 127.0.0.1 Reading all registers Read 4 bytes @ address 0x00000000 (Data = 0x2000FFF8) Target interface speed set to 1000 kHz Select auto target interface speed (2000 kHz) Flash breakpoints enabled Semi-hosting enabled (VectorAddr = 0x08) Semihosting I/O set to TELNET Client SWO disabled succesfully. SWO enabled succesfully. Read 4 bytes @ address 0x00000000 (Data = 0x2000FFF8) Downloading 56 bytes @ address 0x0801C000 - Verified OK Downloading 2904 bytes @ address 0x0801C038 - Verified OK Downloading 4 bytes @ address 0x0801CB90 - Verified OK Comparing flash [....................] Done. Erasing flash [..........ERROR: Failed to erase sectors 56 @ address 0x0801C000 (erase error) ..........] Done. Verifying flash [....................] Done. Спотыкается на стирании первой же используемой страницы (почему перед этим запись с верификацией прошла?! там точно ДРУГАЯ прошивка!). Дальше делает вид, что всё окей, и запускает отладку. Если отладку остановить, видно, что первая используемая страница пустая, остальные - со старым содержимым. Со второго раза прошивается корректно. Собственно, вопросы: - кто-нибудь сталкивался? - кто это вообще пишет? gdb или segger ? Поиграть версией сеггеровских утилит? - может, openocd поможет? они ж нормально работают с SWD и SWO ? И вопрос чуть не в тему. Как к eclipse'у приделать кнопку "залить прошивку, отладку не запускать" ?

Это gcc'шная штука: https://gcc.gnu.org/onlinedocs/gcc/Weak-Pragmas.html Удобно, но, к сожалению, не совместимо со стандартными компиляторами.

Если б кто-то за меня написал функции работы с периферией именно так, как мне нужно, пользовался бы готовым. Вот например SPI - меня полностью устраивает реализация STM32tpl от AHTOXA. рекомендую! GPIO там вообще супер-мега удобные. А изучать (без документации толком на это API) библиотеку смысла нет. Тем более это ж железо - куча не совсем логичных ограничений, завязки друг на друга... Вот ST'шный таймер, например. Какой смысл в библиотеке, если я в любом случае должен влезть в ref.manual, прочитать про ограничения данного конкретного таймера, рассмотреть страничку с типичным применением (там, кстати, работа описывается в терминах регистров, а совсем не API библиотеки!). Или вот, ST'шный UART. Флажок RXNEIE включает не только прерывание Rx not empty, но и Rx overrun. Отличная грабля! Только об этом не написано ни в StdLib, ни в Cube.

Выложил vector_nvic.c для F4, который генерит питоноскрипт: http://pastebin.com/zRuf7Hth Должен лежать здесь: LibOpenCM3\lib\stm32\f4\

Я пользуюсь гибридом - USB'шный стек на libopencm3, а всё остальное - стандарные ST'шные описания регистров (на мой взгляд, они удобнее. И компилятор их лучше понимает) и стандартный же стартап. Почему авторы библиотеки пошли своим путём и наплодили ещё и своих имён для регистров - непонятно...

CONSTANT CURRENT REGION во второй же строчке таблицы в даташите. И график на самой последней странице.