I2C на плате STM32F4Discovery, не проходит запись в CS43L22 Опции

[billidean]

Добрый день.
Изучаю работу с STM32F407 с применением HAL-библиотек.
Завис на изучении I2C. Пробую вести обмен с микросхемой CS43L22, которая стоит на плате.
По схеме на плату вижу подключение ног I2C этой микросхемы к пинам PB6(SCL) и PB9(SDA)

Также по схеме вижу их подтяжку к питанию через 4,7 кОм

В STM32CubeMX создал проект и настроил эти пины STM-ки на интерфейс I2C

настроил скорость и параметры пинов (скорость обмена сделал маленькую - 10кГц, но пробовал и 100кГц)


В даташите на CS43L22 нашел циклограмму чтения

и пытаюсь вычитать ИД микросхемы, т.е. регистр с адресом 0х01

CODE

int main(void)
{
/* Reset of all peripherals, Initializes the Flash interface and the Systick. */
HAL_Init();
/* Configure the system clock */
SystemClock_Config();
/* Initialize all configured peripherals */
MX_GPIO_Init();
MX_TIM6_Init();
MX_I2C1_Init();

LCD_init();
LCD_clear();

HAL_TIM_Base_Start(&htim6);
HAL_TIM_Base_Start_IT(&htim6);

while (1)
{
LCD_clear();
LCD_Cursor(0, 0);
LCD_write_String("BEGIN");
HAL_Delay(1000);

LCD_clear();
LCD_Cursor(0, 0);
aTxBuffer[0] = 0x01;
LCD_clear();
LCD_Cursor(0, 0);
LCD_write_String("Wait ready...");
while( HAL_I2C_GetState(&hi2c1) != HAL_I2C_STATE_READY )
{
LCD_clear();
LCD_Cursor(0, 0);
LCD_write_String("Not ready...");
}
HAL_Delay(1000);
LCD_clear();
LCD_Cursor(0, 0);
LCD_write_String("Wait write...");
while(HAL_I2C_Master_Transmit(&hi2c1, (uint16_t)0x94, aTxBuffer, (uint16_t)1, (uint32_t) 1000) != HAL_OK)
{
if(HAL_I2C_GetError(&hi2c1) != HAL_I2C_ERROR_AF)
{
LCD_clear();
LCD_Cursor(0, 0); // позиция курсора начинается с 0
LCD_write_String("Buffer ERROR!");
}
}
while( HAL_I2C_GetState(&hi2c1) != HAL_I2C_STATE_READY )
{
LCD_clear();
LCD_Cursor(0, 0);
LCD_write_String("..CONTINUE..");
}
LCD_clear();
LCD_Cursor(0, 0);
LCD_write_String("Write OK!");
I2C_ReadBuffer(&hi2c1, (uint16_t)0x94, (uint16_t)1);

HAL_Delay(1000);

}

}

Т.е. я сначала записываю адрес этого регистра 0х01 (использую стандартную ф-цию HAL_I2C_Master_Transmit), затем собираюсь читать (уже использую свою ф-цию I2C_ReadBuffer)...но до чтения прога не доходит, зависает в цикле while(HAL_I2C_Master_Transmit(&hi2c1, (uint16_t)0x94, aTxBuffer, (uint16_t)1, (uint32_t) 1000) != HAL_OK).
Адрес микросхемы 0х94 - по даташиту.

Находил несколько статей по работе именно с этой микросхемой на этой плате, код примерно такой же. Смотрел видео-пример по работе с часами реального времени, там код вообще совпадает.

Если кто работал с этой микросхемой, подскажите плз, где я мог накосячить? Код минимальный.

Сообщение отредактировал IgorKossak - Feb 7 2018, 14:15

Причина редактирования: [codebox] для длинного кода. [code]-для короткого!!!

[Arlleex]

А вообще рекомендую потратить часок на изучение I2C целевого STM32 и написать свои функции чтения/записи (попутно обработку ошибок реализовать, в частности, зависание шины).
Наблюдаю тенденцию каждого третьего вопроса как раз про эти ваши HAL-ы. Создается впечатление, что это г*вно изобретение ленивых людей похуже индусских драйверов на встроенное железо...

Сообщение отредактировал Arlleex - Feb 6 2018, 16:12

[op3op3]

А вообще рекомендую потратить часок на изучение I2C целевого STM32 и написать свои функции чтения/записи (попутно обработку ошибок реализовать, в частности, зависание шины).
Наблюдаю тенденцию каждого третьего вопроса как раз про эти ваши HAL-ы. Создается впечатление, что это г*вно изобретение ленивых людей похуже индусских драйверов на встроенное железо...

HAL stm-овский проект, который активно развивается и его вылизывают на сотнях, тысячах проектов. а ваши самопальные библиотеки, заточенные под ваши личные проекты, используете только вы и сколько там косяков вам еще предстоит узнать. RTOS, файловую систему, .... вы видимо тоже свои пишете, по ночам, в свободное от основной работы время..

billidean, в репозитории куба есть готовый драйвер CS43L22, можно в нем глянуть как реализовано
смотрите куда в кубе у вас настроено сохранение Help > Updater Settings > Firmware Repository
драйвер
~/STM32Cube/Repository/STM32Cube_FW_F4_V1.19.0/Drivers/BSP/Components/cs43l22/

готовые рабочие проекты с примерами использования этого драйвера
~/STM32Cube/Repository/STM32Cube_FW_F4_V1.19.0/Projects/STM32F401-Discovery/Examples/BSP/readme.txt
~/STM32Cube/Repository/STM32Cube_FW_F4_V1.19.0/Projects/STM32F411E-Discovery/Examples/BSP/readme.txt

Сообщение отредактировал op3op3 - Feb 9 2018, 02:24

[картошка]

HAL stm-овский проект, который активно развивается и его вылизывают на сотнях, тысячах проектов. а ваши самопальные библиотеки, заточенные под ваши личные проекты, используете только вы и сколько там косяков вам еще предстоит узнать. RTOS, файловую систему, .... вы видимо тоже свои пишете, по ночам, в свободное от основной работы время..

Косяки не пишу уже лет так 15, из 20 ... к примеру.

Кто его развивает ? Специалисты ?! Кто будет вылаживать нормальный код, труд обкатанный годами во всеобщее пользование ?, это мягко говоря - антисоциально по отношению к проффесионалам.
Для всех этих hardware опен сорсе - есть много общего: очень сложно выкорчевать, нереально дописать, присел - раб (трать время = деньги) - так как читать не умеешь документацию.
Из всех неудобных мест по применению "универсального" кода - микроконтроллеры занимают первое место, так как постоянно приходится иметь дело с компромиссами (размер + скорость + оптимальная архитектура задачи + оптимальная работа с периферией). Применение языковых подходов для оптимизации кода, требует знания возможности и методов адресации процессорного ядра применяемого микроконтроллера. Всё это лучшее в существующей реализации кхала - отсутствует. А когда она будет допилена - то превратится в обычный код разработчика, с которым спорите по целесобразности применения кхала. Имел в виду разработчика со стажем, а не студента мечтателя.

1. Выгода применения аппаратной системы прерывания CORTEX - убита в корне. (ленивой программной реализацией - откатили до уровня 7TDMI).
2. Килобайты кода к контексте прерываний. (благо дело можно настроить приоритеты и разрешить вложенные, но это уже извращения на ровном месте).
3. Включаются прерывания, которые не разрешал. Корявая обработка. (неожиданные отработки прерываний, которые принципиально по архитектуре задачи не планировал и не разрешал)
4. Разработчики теряются и неправильно реализуют состояния программных статусов. (непонятный блуд с программными флагами и состояниями, невозможность гибкости в плане быстрого реагирования )
5. Неумение работать даже с банальным UART, документацию не читают !!! (I2C)
6. Доведение до ума требует гарантированного выкорчевывания - 98 % кода, с куда более большими затратами по вниманию и времени.

Любое из этого для меня лично критически - не приемлемо.

STDLIB на stm32f7 - уже не поддерживается - жаль.

Сообщение отредактировал картошка - Feb 21 2018, 08:18