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

hd44780

Members
  • Постов

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

  • Посещение

Информация о hd44780

  • День рождения 30.06.1977

Информация

  • Пол
    Мужчина
  • Интересы
    Программист, увлекающийся электроникой.
    В основном STM32.
  • Город
    Донецк, ДНР, РФ

Электроника

  • Стаж в электронике
    6-10 лет
  • Сфера радиоэлектроники
    Цифровая техника, микроконтроллеры
  • Оборудование
    Обычный неразвязанный сетевой паяльник 25W, мультиметр M890D, примитивненький цифровой осциллограф UT-81B.

Посетители профиля

7 392 просмотра профиля

Достижения hd44780

Завсегдатай

Завсегдатай (8/14)

  • 10 постов на форуме
  • Пост-машина Редкий
  • Неделя на форуме
  • Месяц на форуме
  • Год на форуме

Последние значки

189

Репутация

  1. Поздравляю. У STM, видать, упрощённая реализация драйверов ... У меня руки уже давно никак не дойдут пошаманить там
  2. как появятся новости, я сюда отпишу.
  3. ясно. Пошёл я расчехлять свою пушку ....
  4. А Вы клавиши нажимали на клавиатуре? Туда должны скан-коды прийти.
  5. а выпихните плиз в уарт, что он пихает в очередь в ветке case HID_POLL:
  6. Ну хз, чего там они намутили. Попробую у себя - отпишусь. usart3 у меня как раз свободен ... Но сегодня-завтра-послезавтра - не знаю - работа ... fifo_read - чтение очереди. если оно возвращает 0, значит очередь пуста. а это, в свою очередь, означает, что проц не принял ничего от клавиатуры. Ветка HID_GET_DATA не сработала. ладно, посмотрю в железке - может и скажу что-то внятное Если можете, подскажите плиз мне куда в вашем кубе воткнуть переключение PA10 на выход и выставление на нём лог 0? Этим у меня на плате подаётся питание на USB гнездо.
  7. Вы про HID_IDLE в моём посте прочитали? Условие, о котором Вы пишете - следствие какого-то сбоя в USBH_HID_KeybdDecode. Если USBH_HID_KeybdDecode сработает, то всё остальное, я думаю, сразу оживёт. Типы я просмотрел, вроде норм. Да и компилятор бы выругался..
  8. Посмотрел кубовый USB драйвер HID класса, сопоставил с некубовыми либами. Заметил одно на мой взгляд существенное отличие. Детально не копался, т.к. смотрел лишь в код, в железе не проверял. Короче - в файле usbh_hid.c (это драйвер HID класса, там общий код для мышей и клавиатур) есть функция USBH_HID_Process. Там в switch есть ветка case HID_IDLE. В ней вызывается fifo_write - закомментарьте её и проверьте. Эта штука пишет что-то в очередь. Очередь читается в USBH_HID_KeybdDecode (и больше нигде, драйвер мыши не в счёт), там пытается вытащить из очереди сканкоды клавиши и потом декодировать их. Мне сложно сразу сказать, что именно пишется в очередь в HID_IDLE и зачем оно туда пишется, т.к. реальные данные (хоть от мыши, хоть от клавы) приходят в этой же функции в ветке HID_GET_DATA, а в очередь загоняются в следующей ветке - HID_POLL. Пихать в эту очередь что-то ещё кроме данных - как по мне - явно лишнее. Пока так .... PS. А вообще - как-то стрёмно у них это сделано... даже не знаю, как поточнее сформулировать. В очередь пишет по сути функция MX_USB_HOST_Process(), вызывающаяся в главном цикле. Она кладёт туда сканкоды, кол-во байт которых м.б. разным. Декодер вызывается из функции USBH_HID_GetKeybdInfo где-то в пользовательском коде ... Причём декодер использует HID_Handle->length для получения длины данных в очереди. HID_Handle->length изменяется в недрах той же MX_USB_HOST_Process(). Чувствуете чем всё это пахнет? Банальным рассинхроном, когда в очереди будут лежать данные, а HID_Handle->length уедет куда-то дальше .... В итоге работать ничего не будет, хоть в очередь будут попадать правильные коды. Я не знаю, насколько это вероятно, но такое вполне может быть. Если не лезть в кубовый код, я бы посоветовал сделать что-то такое: if(Appli_state==APPLICATION_READY) { if(USBH_HID_GetDeviceType(&hUsbHostFS) == HID_KEYBOARD) { k_pinfo = USBH_HID_GetKeybdInfo(&hUsbHostFS); if(k_pinfo!=NULL) { char chr = USBH_HID_GetASCIICode(k_pinfo); } } сразу после MX_USB_HOST_Process() и класть этот chr в какой-то свой буфер и потом использовать где надо. В старых либах это сделано более грамотно - там данные клавы/мыши не кладутся в очередь, а сразу декодируются. А в очередь попадает уже готовый символ.
  9. HID_KEYBD_Info_TypeDef *USBH_HID_GetKeybdInfo(USBH_HandleTypeDef *phost) { if(USBH_HID_KeybdDecode(phost) == USBH_OK) { return &keybd_info; } else { return NULL; } } Возвращается NULL, т.к. не пашет USBH_HID_KeybdDecode, что мы выше уже определили - длина данных не совпадает. Там надо рыть. Я постараюсь сегодня глубже вдуматься в суть того, как оно работает. Эту часть в кубе заметно переписали, работает оно не так, как в докубовых либах, которые я использую . А с кубом я считай не работал, и без него хорошо
  10. Про проходы я не понял. USBH_HID_KeybdDecode - эта функция вызывается при каждом нажатии любой клавиши. И её задача - расшифровать сканкоды клавиатуры. 1 нажатие = 1 порция сканкодов. Сколько именно это байт - зависит от клавиши. Максимально там вроде 8 байт, но я сейчас в этой цифре не уверен. Если вы ничего не нажимаете, то эта функция вообще не должна вызываться. Какие тут проходы? Это уже следствие .... Когда USBH_HID_KeybdDecode отработает нормально, оно само взлетит. Про отладку сразу не отвечу.
  11. Привет Ну поменяйте ихний printf на что-то своё. printf-ом в МК я вообще не пользовался, ни на аврах, ни на stm32, потому не могу сказать ничего. Изредка на просторах интернета натыкался на какие-то жалобы, что этот механизм как-то странно работает. К тому же и сильно зависит от используемого компилятора... Но в детали не вникал. Сам использую самописные функции - по сути sprintf + то, что Вы назвали Usart1_Send_String. А кому не нравится - его проблемы .
  12. 1. Сомневаюсь. У f407 ядро Cortex-M4F, у него есть какие-то ограничения на исполнение кода не из flash. Точно не скажу, нужно проверять. Но что-то по этой части он умеет. 2. C++ - для данного проца чересчур. ООП (классы, объекты) предполагает интенсивное использование динамически выделяемой памяти, а с внутренним RAM в 192 кила, да ещё и разодранным на 3 или 4 разных куска Вы на плюсах далеко не уедете. В каком-то минимальном варианте оно, конечно, взлетит, но в целом - хило .... Если хотите плюсы на STM32 - берите хотя бы F4x9 + SDRAM. 3. Исключено. Забудьте. Ф407 слишком слаб для этого. Тюльпаны - вообще отдельная тема, насколько я знаю, на аврах, равно как и на STM32 её путём никто не решил. Разъём TFT - интерфейс FSMC проца - для дисплеев типа SSD1289, ILI9320, SSD1963 и родственных им. Либо что-то на SPI. Но это ещё тормознутее. Лучше уж этот FSMC. 4. Про внешнее ОЗУ забудьте полностью. У вас 100-ногий корпус, у него урезанный FSMC, ничего путного, кроме дисплея, к нему не прицепишь. С учётом п. 1 - хз, что выйдет ... 5. Прогу вы по-любому пишете на обычном компе, в специальных программах (Coocox, IAR, Keil и пр). Они умеют компилировать язык Си в код для этих процов. И заливать полученный код в процессор через программатор. 6. Без комментариев ... Прочитайте предыдущие пункты ... Может быть, у вас что-то изменится.
  13. ну да, я тоже в 99% случаев без неё обхожусь. Но если в процессор зашили какой-то левый мусор, то без неё тяжко
  14. На будущее - всегда протягивайте сброс от программатора к процу - жить сразу станет легче .
×
×
  • Создать...