USMI

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.

Вы здесь » USMI » MCU, SoC, CPU Микроконтроллеры » TONE оповещения в ac696n_soundbox_sdk_v0.2.5

TONE оповещения в ac696n_soundbox_sdk_v0.2.5

Страница: 1

Сообщений 1 страница 8 из 8

1

  • Автор: Alcest
  • Активный участник
  • Alcest
  • Сообщений: 141
  • Уважение: +1

Еще одна проблема со звуковыми оповещениями аудиоинтерфейса. В первый раз были непонятки с SDK AC692n, но успешно разрешились тут JL SoC. 杰理芯片

Теперь возникли глюки с воспроизведением звуковых оповещений TONE в SDK AC696n версии 0.2.5 и с чипом 6965A. Свой код в отдельном файле. Звуковые оповещения запускаются вызовом функции tone_play_index(u8 index, u8 preemption). Первый аргумент функции - имя файла определенного звукового сигнала TONE. Второй аргумент 0 или 1, определяющие будет перед воспроизведением сигнала TONE остановлено воспроизведение аудиофайла с телефона или TONE сообщение наложится на звук аудиофайла (второй вариант шляпа, рывками звук воспроизводится и я его не использую).

Ну так вот, при озвучивании кнопок все отлично работает. При нажатии на кнопку в файле key_event_deal.c в селекторе switch (key_event) вызывается нужная функция в коде моего файла, куда включено tone_play_index(u8 index, u8 preemption). Тут все прекрасно, воспроизведение с телефона останавливается, звучит назначенное кнопке TONE оповещение, после чего снова воспроизводится аудиофайл с телефона.

Косяк появился при попытке вызвать упомянутую выше функцию из функции SYS_HI_TIMER_ADD(_func, _priv, _msec), из которой с определенной периодичностью вызывается та или иная функция. В частности, оповещения не воспроизводятся когда вызываются из функций в моем коде, которые в свою очередь вызываются из файла plcnt.c, из функции scan_capkey(void *priv). Последняя функция в том же файле вызывается из scan_capkey(void *priv) с периодичностью 2 ms. В этом случае полная тишина вместо звуковых сигналов. Функция tone_get_status() вызываемая сразу после tone_play_index(u8 index, u8 preemption) возвращает 0, что говорит о молчании ягнят об отсутствии воспроизведения TONE сообщения. Сама функция  tone_play_index(u8 index, u8 preemption) возвращает значение 22, чему в файле errno-base.h соответствует ошибка EINVAL - Invalid argument.

Может кто в курсе, чего не так с аргументами при обращении к функции tone_play_index(u8 index, u8 preemption) из SYS_HI_TIMER_ADD(_func, _priv, _msec)?

2

  • Автор: Alcest
  • Активный участник
  • Alcest
  • Сообщений: 141
  • Уважение: +1
Alcest написал(а):

Последняя функция в том же файле вызывается из scan_capkey(void *priv) с периодичностью 2 ms

Здесь опечатка, правильно будет: "Последняя функция в том же файле вызывается из sys_s_hi_timer_add(NULL, scan_capkey, 2) с периодичностью 2 ms".

3

  • Автор: Alcest
  • Активный участник
  • Alcest
  • Сообщений: 141
  • Уважение: +1

Наблюдение за работой кода выявило следующее. Для воспроизведения TONE оповещения в файле tone_player.c последовательно вызываются одна из другой следующие функции: tone_play_index(u8 index, u8 preemption) ->> tone_dec_open_with_callback(u8 is_mode, const char **list, u8 preemption, void (*user_evt_handler)(void *priv), void *priv) ->> tone_dec_open(const char **list, u8 preemption).

В последней функции программа обращается к функции file = fopen(list[index], "r"), которая есть макрос #define fopen sdfile_open в файле sdfile.h. В этом макросе прописана функция SDFILE *sdfile_open(const char *path, const char *mode) которая в конечном итоге вроде как и должна открывать аудиофайл mp.3 с записанным в него звуковым оповещением и возвращать указатель на результат выполнения функции. Ну так вот, результатом вызова этой функции становится 0, если изначально функция tone_play_index(u8 index, u8 preemption) (самая первая в цепочке функций) вызывается из SYS_HI_TIMER_ADD(_func, _priv, _msec). Из-за чего в функции  tone_dec_open(const char **list, u8 preemption) срабатывает условие вызывающее возврат с return -EINVAL (то самое 22, которое возвращает tone_play_index(u8 index, u8 preemption).

Почему так получается? Почему при обращении к tone_play_index(u8 index, u8 preemption) по событию нажатия кнопки все нормально, а тут нет? Какой такой неверный аргумент передается в SDFILE *sdfile_open(const char *path, const char *mode)? Надо думать ругается на первый аргумент, который есть элемент массива с номером воспроизводимого mp.3 файла. Но почему?

4

  • Автор: Alcest
  • Активный участник
  • Alcest
  • Сообщений: 141
  • Уважение: +1
Alcest написал(а):

В этом макросе прописана функция SDFILE *sdfile_open(const char *path, const char *mode) которая в конечном итоге вроде как и должна открывать аудиофайл mp.3 с записанным в него звуковым оповещением и возвращать указатель на результат выполнения функции

Опять выше не то написал. Она возвращает дескриптор открываемого файла. При нормальном воспроизведение TONE оповещений это какое-то число больше нуля. Когда же дескриптор равен нулю, тогда происходит return -EINVAL.

Отредактировано Alcest (2024-12-13 04:59:07)

5

  • Автор: kagaimiq
  • Активный участник
  • kagaimiq
  • Сообщений: 196
  • Уважение: +43

Дело в том, что обработчики, которые регистрируются через SYS_HI_TIMER_ADD или sys_s_hi_timer_add вызываются из прерывания от таймера (timer1), а функция fopen первым делом вызывает "os_mutex_pend", которая при вызове из прерывания сразу же выдаёт код 3 (OS_ERR_PEND_ISR), и вслед уже fopen выдаёт NULL, и далее по списку.

Если что, fopen на самом деле не является переопределением sdfile_open, так как в опциях проекта в #defines прописано "VFS_ENABLE=1", и поэтому та часть sdfile.h где это делается не имеет значения.

Отредактировано kagaimiq (2024-12-13 06:14:19)

Подпись автора

水Mizu-DEC JLtech since 22.06.2019

6

  • Автор: Alcest
  • Активный участник
  • Alcest
  • Сообщений: 141
  • Уважение: +1
kagaimiq написал(а):

Дело в том, что обработчики, которые регистрируются через SYS_HI_TIMER_ADD или sys_s_hi_timer_add вызываются из прерывания от таймера (timer1), а функция fopen первым делом вызывает "os_mutex_pend", которая при вызове из прерывания сразу же выдаёт код 3 (OS_ERR_PEND_ISR), и вслед уже fopen выдаёт NULL, и далее по списку.

Вот засада! В брежневские времена SDK 692x такого не было...

7

  • Автор: kagaimiq
  • Активный участник
  • kagaimiq
  • Сообщений: 196
  • Уважение: +43

Да там и RTOS никакой не было, всё работало засчёт периодичных прерываний от timer0, и в некоторых случаях через софтовые прерывания, и конечно же основного цикла программы, и о никакой вытесняющей многозадачности речи там и не идёт.

Подпись автора

水Mizu-DEC JLtech since 22.06.2019

8

  • Автор: Jobit Joseph
  • Участник
  • Сообщений: 10
  • Уважение: +1
kagaimiq написал(а):

There was no RTOS there, everything worked due to periodic interrupts from timer0, and in some cases through software interrupts, and of course the main program loop, and there was no talk of any preemptive multitasking there.

Yes. And if we're not careful adding any extracode, it can cause issues with the audio related tasks.

Страница: 1

Вы здесь » USMI » MCU, SoC, CPU Микроконтроллеры » TONE оповещения в ac696n_soundbox_sdk_v0.2.5