billidean

Спасибо.

Добрый день всем. Начал разбираться с USB на stm32f4. Необходимо проследить обмен компа с контроллером. Побродил по инету, скачивал несколько прог для контроля интерфейса, но ни одна толком не заработала, вернее, вообще ни одна из 6-7ми штук не показала мне трафик USB. Поделитесь, ПЛЗЗ, ссылочкой на такую прогу (под Win 7/8).

void task2(void* pdata) { while (1) { alt_irq_register(BUTTONS_IRQ, (void*)BUTTONS_BASE, button_isr); printf("Hello from task2\n"); //OSTimeDlyHMSM(0, 0, 1, 0); } } Это вообще ... какая-то, в бесконечном цикле регить обработчик.... А вообще, более правильный механизм выглядит так: 1. регим обработчик прерывания 2. заводим семафор 3. заводим таск, которому нужно это прерывание 4. в обработчике прерывания взводим семафор 5. в таске, в начале тела ждем семафора, после чего делаем то, что надо, сбрасываем семафор ну, это примерная модель, а уже для каждого конкретного случая может немного изменяться.

Всё, нашел.

Да. Спасибо. Еще один вопрос. Кто может подсказать, как во время отладки в ChibiStudio контролировать состояние портов? У меня есть возможность делать это снаружи анализатором, но хотелось бы это делать прям в Студии.

Еще один вопрос. Кто может подсказать, как во время отладки в ChibiStudio контролировать состояние портов? У меня есть возможность делать это снаружи анализатором, но хотелось бы это делать прям в Студии.

Спасибо за желание помочь. Я решил пока поработать с HD44780. Сам дисплей от Моторолы пока не очень нужен, я просто начал разбираться с графической библиотекой uGFX под ОС ChibiOS. Почитал доки, примеры в инете, и подумал, что вроде ничего сложного в работе с дисплеями нет, нужно лишь знать интерфейс, адреса регистров, и коды команд. А под рукой был мертвый телефон Моторола v150, вот и решил начать с его экрана. Тем более, что телефон довольно распространенный (был), и я не думал, что будет проблема с доками на него. НО дальше того, что интерфейс к этому дисплею - SPI, я продвинуться не смог, даже не ясно с какими ширпотребами он схож по командам/регистрам. В-общем придется пока довольствоваться текстовым "монитором", а потом может и попробую методом подбора кодов разобраться с Моторовским экраном.

Приветствую всех. Разобрал телефон Motorola v150, хочу подключить дисплей от него к smt32f4-DISCOVERY. На дисплее маркировка 0103563801 T1 LP-8815-B 03-03 Z3422765 M3 и больше ничего. Нашел в инете схему на телефон (не надеялся, что найду), по которой видно, что дисплей имеет интерфейс SPI. Это вселило надежду. На форумах народ при начале работы с дисплеями первым делом начинают с чтения регистров ID и т.п. НО не понятно по каким адресам читать и вообще какими командами, какой формат у этих команд должен быть для данного дисплея. Кто-нибудь работал с этим дисплеем? Или может есть похожие по командам дисплеи, работа с которыми уже описана в сети? Или все-таки методом "научного тыка" придется все делать?

Что-то как-то в ДШ я так и не глянул. Спасибо большое за помощь.

Т.е. получается, когда указываем, что порт В (например) будет использоваться SPI-контроллером, то к этому контроллеру SPI можно подключить только определенные ноги порта В, конечно при условии использования АФ(5)? Тогда не подскажите, где про эти взаимосвязи выводов портов и SPI-контроллеров (да и не только SPI, но и всех остальных) посмотреть? Т.е. где узнать, какие выводы портов будут задействованы при подключении всяких контроллеров периферии?

Добрый день всем. Разбираю проект testhal/STM32F4xx/SPI. В целом все понятно. Настраиваем SPI-контроллер (структура, порт, ...). НО совсем непонятен один вопрос: 1. Инициализируем структуру static const SPIConfig hs_spicfg = { NULL, GPIOB, 12, 0 }; Здесь видно, что для SPI-контроллера будет использован порт B, где вывод 12 будет использован как CS(ЧипСелект) 2. В одном из потоков будет использоваться SPI-контроллер 2, и он будет использовать вышеуказанную структуру SPIConfig: spiStart(&SPID2, &hs_spicfg); 3. В майне есть такие строки: /* * SPI2 I/O pins setup. */ palSetPadMode(GPIOB, 13, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST); /* New SCK. */ palSetPadMode(GPIOB, 14, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST); /* New MISO. */ palSetPadMode(GPIOB, 15, PAL_MODE_ALTERNATE(5) | PAL_STM32_OSPEED_HIGHEST); /* New MOSI. */ palSetPadMode(GPIOB, 12, PAL_MODE_OUTPUT_PUSHPULL | PAL_STM32_OSPEED_HIGHEST); /* New CS. */ palSetPad(GPIOB, 12); И вот здесь я в ауте... Как SPI-контроллер 2 узнает, что пин 13 порта В должен использоваться именно как SCK??? И про все остальные пины также. А если мне нужно будет другие пины назначить на SCK или на MOSI? Например на пине 14 чтобы был SCK, а на 13 MISO. Просмотрел все файлы ОСи и как-то не нашел нигде этого момента, как SPI-контроллеру указать какой именно пин за какую функцию должен отвечать (SCK, MISO, MOSI). Только про CS описано, что он указывается в структуре SPIConfig. ПЛЗ. Помогите разобраться.

Спасибо, посмотрю.

Спасибо, посмотрю.

Ясно, спасибо. У stm32f4 из внешних интерфейсов имеются SPI, UART, CAN, I2C и вроде как всё. Так вот с помощью этого набора и возможно общение с внешним ОЗУ. Подскажите, пожалуйста, как с таким набором интерфейсов можно осуществить общение с SDRAM (с ДДР, я понимаю, нельзя работать от МК). Или на данном МК это вообще сделать не реально. Но, если это решаемо, то подскажите, плз, где про это можно покопать.

Если подключаться к ДДР'ке через ПЛИС, то этот путь мне довольно-таки ясен. У меня вопрос более конкретный: возможно ли к STM32F407.. подключить внешнее ОЗУ большого размера типа ДДР. Или возможно ли подключение другого типа памяти с большим объемом. Про объем уточняю на всякий случай. Я со своей стороны пытаюсь рассмотреть этот вопрос, но пока что и времени не хватает, и информации по этому маловато.

Добрый день всем. С ARM разбираться начал недавно, в основном работаю с ПЛИС. Появился такой вопрос: возможно ли подключение к stm32f4 внешнего ОЗУ большого объема, порядка 4 ГБ? С ПЛИС работал с ДДР3 используя Альтеровское ядро. Сейчас хотелось бы повторить один из проектов, работающих с внешним ОЗУ ДДР3 на 4 ГБ, на СТМ'ке. Может применение другого типа памяти, не ДДР, позволит решить данную задачу? У кого есть какие идеи/подсказки? ЗЫ: Возможно есть уже готовые решения/проекты, но я их не нашел.

Так-то автор пишет, что . Правда, он не сказал, как он это выяснил, методом медитации или отладчиком. То, что осциллографом видны тики таймера еще не говорит, что "АЦП опрашивается, в буфер данные идут". Я не знаю наполнение функции DataIN_OUT_toUSB, но не может ли получиться так, что 2мс не хватает (или хватает, но впритык) для полного выполнения этой ф-ции, и МК почти все время висит в обработчике таймера? Раньше все работало, потому что не было жесткой привязки к запуску этой ф-ции, т.е. когда закончила (может это занимало и более 2мс), тогда и опять начала выполняться, но при этом она могла быть прервана контроллером USB.

ну...тогда статистика по указанным нанд'ам Вам в помощь.

Эта картинка, как я понимаю, когда у Вас все хорошо и все работает, времена между пакетами маленькие. Видно арп-запрос, затем арп-ответ, и далее уже идет пакет данных на девайс. Но посмотреть бы картину при длительной паузе, можно в виде файла. а не картинки. И еще, при переводе Вашего стека в режим 1Г Вы все необходимые сигналы/частоты/настройки выставили в необходимое состояние?

Имея картину от сниффера (сохраненный файл), можно было бы полнее проанализировать ситуацию. Т.е. может не в самом стеке дело, не в том, что он так долго анализирует принятый арп-ответ, а в том, что творится на линии.

При отправке самого первого пакета Ваш стек отправляет арп-запрос для того, чтобы выяснить, какой МАК-адрес имеет девайс, которому предназначаются передаваемые далее данные. После принятия арп-ответа стек должен сохранить этот МАК-адрес в таблице ассоциации IP-адресов и МАК-адресов. Где-то в этом месте должен и выставляться сигнал dst_rdy. А уже при передаче следующих пакетов стек знает, какой МАК-адрес у девайса с IP-адресом, на который будут переданы данные, и поэтому пауза далее идет минимальная. Я не знаю, что из себя представляет Ваш UDP/IP stack, но логика работы должна быть такая. Длительная пауза при первом обмене может быть связана с посылкой-приемом арп-запросов/ответов. Нужно смотреть сниффером (wireshark), что происходит на линии езернета, какой сформирован арп-запрос, какой приходит арп-ответ, время между ними и т.п. Диаграммы можно было бы посмотреть, может они что-нибудь прояснят.

Пробовал симулировать, не получается, нужна библиотека DWARE, которая вроде под какой-то платной лицензией. Да и делителя плав. я не увидел.

ЕСС - конечно же поможет, но только с одним-двумя ошибочными битами в массиве битов. Наверное есть алгоритмы и для большего количества ошибок, но я их не изучал. Так что при применении ЕСС можно использовать страницу с одним постоянно испорченным битом, а при появлении второго испорченного бита блокировать(помечать) страницу. Но, если у Вас иногда ошибочные биты появляются и пропадают в разных местах, то можно случайно забраковать и небитую страницу, а затем следующую ... и так у Вас не останется страниц вообще. При случайных появлениях и пропаданиях неверных данных при чтении (не совпадающих с записанными), дело может быть в НЕстабильности работы интерфейса с флэшкой, какой-нибудь дребезг на линии данных или тактовой, и т.п.

Можете привести картинки AssignmentEditor'a и PinPlaner'a?

Ура, конечно же, но мне это не поможет.