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

billidean

Свой
 Профиль  Обзор контента

  • Постов

    245

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

  • Посещение

 Тип контента 

Сообщения, опубликованные billidean

  2. Опубликовано · Пожаловаться

    Добрый день всем.

     

    Начал разбираться с USB на stm32f4. Необходимо проследить обмен компа с контроллером. Побродил по инету, скачивал несколько прог для контроля интерфейса, но ни одна толком не заработала, вернее, вообще ни одна из 6-7ми штук не показала мне трафик USB.

     

    Поделитесь, ПЛЗЗ, ссылочкой на такую прогу (под Win 7/8).

  3. Опубликовано · Пожаловаться 

    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. в таске, в начале тела ждем семафора, после чего делаем то, что надо, сбрасываем семафор

    ну, это примерная модель, а уже для каждого конкретного случая может немного изменяться.

  5. Опубликовано · Пожаловаться

    Да. Спасибо.

    Еще один вопрос.

    Кто может подсказать, как во время отладки в ChibiStudio контролировать состояние портов?

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

  7. Опубликовано · Пожаловаться

    Спасибо за желание помочь.

    Я решил пока поработать с HD44780.

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

    В-общем придется пока довольствоваться текстовым "монитором", а потом может и попробую методом подбора кодов разобраться с Моторовским экраном.

  8. Опубликовано · Пожаловаться

    Приветствую всех.

    Разобрал телефон Motorola v150, хочу подключить дисплей от него к smt32f4-DISCOVERY. На дисплее маркировка 0103563801 T1 LP-8815-B 03-03 Z3422765 M3 и больше ничего.

    Нашел в инете схему на телефон (не надеялся, что найду), по которой видно, что дисплей имеет интерфейс SPI. Это вселило надежду.

    На форумах народ при начале работы с дисплеями первым делом начинают с чтения регистров ID и т.п.

    НО не понятно по каким адресам читать и вообще какими командами, какой формат у этих команд должен быть для данного дисплея.

     

    Кто-нибудь работал с этим дисплеем? Или может есть похожие по командам дисплеи, работа с которыми уже описана в сети? Или все-таки методом "научного тыка" придется все делать?

  10. Опубликовано · Пожаловаться

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

     

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

  11. Опубликовано · Пожаловаться

    Добрый день всем.

    Разбираю проект 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.

     

    ПЛЗ. Помогите разобраться.

  14. Опубликовано · Пожаловаться

    Ясно, спасибо.

     

    У stm32f4 из внешних интерфейсов имеются SPI, UART, CAN, I2C и вроде как всё. Так вот с помощью этого набора и возможно общение с внешним ОЗУ.

    Подскажите, пожалуйста, как с таким набором интерфейсов можно осуществить общение с SDRAM (с ДДР, я понимаю, нельзя работать от МК).

    Или на данном МК это вообще сделать не реально.

    Но, если это решаемо, то подскажите, плз, где про это можно покопать.

  15. Опубликовано · Пожаловаться

    Если подключаться к ДДР'ке через ПЛИС, то этот путь мне довольно-таки ясен.

     

    У меня вопрос более конкретный: возможно ли к STM32F407.. подключить внешнее ОЗУ большого размера типа ДДР. Или возможно ли подключение другого типа памяти с большим объемом.

    Про объем уточняю на всякий случай.

     

    Я со своей стороны пытаюсь рассмотреть этот вопрос, но пока что и времени не хватает, и информации по этому маловато.

  16. Опубликовано · Пожаловаться

    Добрый день всем.

    С ARM разбираться начал недавно, в основном работаю с ПЛИС.

    Появился такой вопрос: возможно ли подключение к stm32f4 внешнего ОЗУ большого объема, порядка 4 ГБ?

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

    Может применение другого типа памяти, не ДДР, позволит решить данную задачу?

     

    У кого есть какие идеи/подсказки?

     

    ЗЫ: Возможно есть уже готовые решения/проекты, но я их не нашел.

  17. Опубликовано · Пожаловаться

    Так-то автор пишет, что

    АЦП опрашивается, в буфер данные идут
    . Правда, он не сказал, как он это выяснил, методом медитации или отладчиком. То, что осциллографом видны тики таймера еще не говорит, что "АЦП опрашивается, в буфер данные идут".

    Я не знаю наполнение функции DataIN_OUT_toUSB, но не может ли получиться так, что 2мс не хватает (или хватает, но впритык) для полного выполнения этой ф-ции, и МК почти все время висит в обработчике таймера?

    Раньше все работало, потому что не было жесткой привязки к запуску этой ф-ции, т.е. когда закончила (может это занимало и более 2мс), тогда и опять начала выполняться, но при этом она могла быть прервана контроллером USB.

  19. Опубликовано · Пожаловаться

    Эта картинка, как я понимаю, когда у Вас все хорошо и все работает, времена между пакетами маленькие. Видно арп-запрос, затем арп-ответ, и далее уже идет пакет данных на девайс.

     

    Но посмотреть бы картину при длительной паузе, можно в виде файла. а не картинки.

     

    И еще, при переводе Вашего стека в режим 1Г Вы все необходимые сигналы/частоты/настройки выставили в необходимое состояние?

  20. Опубликовано · Пожаловаться

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

    Т.е. может не в самом стеке дело, не в том, что он так долго анализирует принятый арп-ответ, а в том, что творится на линии.

  21. Опубликовано · Пожаловаться

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

     

    Длительная пауза при первом обмене может быть связана с посылкой-приемом арп-запросов/ответов. Нужно смотреть сниффером (wireshark), что происходит на линии езернета, какой сформирован арп-запрос, какой приходит арп-ответ, время между ними и т.п.

     

    Диаграммы можно было бы посмотреть, может они что-нибудь прояснят.

  23. Опубликовано · Пожаловаться

    ЕСС - конечно же поможет, но только с одним-двумя ошибочными битами в массиве битов. Наверное есть алгоритмы и для большего количества ошибок, но я их не изучал.

    Так что при применении ЕСС можно использовать страницу с одним постоянно испорченным битом, а при появлении второго испорченного бита блокировать(помечать) страницу.

    Но, если у Вас иногда ошибочные биты появляются и пропадают в разных местах, то можно случайно забраковать и небитую страницу, а затем следующую ... и так у Вас не останется страниц вообще.

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

     

×
×
  • Создать...