Jump to content

    

Spider

Свой
  • Content Count

    446
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Spider

  • Rank
    В поисках истины
  • Birthday 10/03/1984

Старые поля

  • skype
    Array
  • Vkontakte
    Array
  • G+
    Array

Контакты

  • Сайт
    Array
  • ICQ
    Array
  • Yahoo
    Array

Информация

  • Город
    Array

Recent Profile Visitors

3633 profile views
  1. __HAL_AFIO_REMAP_SWJ_DISABLE(); пробовал делать? Но отладку ты тут же потряешь, да и проц будет шиться только под ресетом, коего на китайских программаторах обычно нет.
  2. Сохранил бинарный поток с логического анализатора обратно в WAV - получил всё ту же WAV. т.е. передаю я наверное правильно. Вот только что-то подключено видимо не так....
  3. Обижаете :) Этим SAI занимается. Как и раздвоением моно в псевдо-стерео. Но вот звука всё равно нет....
  4. Все привет! Вот потребовалось подключить к процессору эту штуку и чтобы ещё и работала. Как бы и всё понятно, но не работает. Подключил я её к SAI (Serial Audio Interface) процессора STM32H7 настроил интрефейс. Логическим анализатором вижу, что форма сигнала "как на картинке", а вот вместо звука - скрежет и писк. Теперь что я имею и делаю: RAW Audio данные в формате PCM signed 16bit, 1ch. К сожалению от процессора я имею дотуп только к BCLK, LRCLK, SDATA. Но этого вроде как и достаточно. Скриншота не сделал - а зря, но постараюсю на словах. В PulseView вижу точь в точь такую картину: BCLK у меня с частотой 16кГц - 50%. Каналы именно так по 16 бит каждый. Первый бит данных со смещением в 1 Бит. В каждый канал выводится 1 семпл из RAW Audio - 2 байта - в каждый канал дублируется 1канальный поток - PulseView это "подтверждает". Микросхему подключал по разному. Варианты уже все не перечислить, из тех что пробовал: 1. Standalone - без управления по i2c. Скрипит ( 2. Typical. 2.1 BLCK->MCLK-E, GND->BCLK, LRCLK->LRCLK, SDATA->SDATA. 2.2. BLCK->BLCK, GND->MCLK-E, LRCLK->LRCLK, SDATA->SDATA. Всё скрипит и пищит. На звук не похоже.
  5. Вот и я о том же. Скмпшинг в 10ки раз быстрее. Онг такое и есть.... Ну это то понятно. Вот только как быть с битами....
  6. Всем привет. Ковыряю тут железку и пытаюсь понять как она общается между 2мя своими модулями. Выглядит это вот так: С первого взгляда похоже на какой-то синхронный последовательный сигнал типа SPI half-duplex, но обратите внимание на следующее: 1. Шина DATA и CLOCK меняется местами в зависимости от того кто "оратор". 2. Какая-то странная кодировака DATA относительно CLOCK. Где-то "бит" данные на спадае, а где-то на возрастающем CLOCK. а где-то вообще сллошняком. Это что-то известное миру? или какая то отсебятина? Есть предложения как "правильнее" это представить в биты? Немного крупнее начало
  7. Появляется "джитер" в сигнале в этот момент :(
  8. Добрый день! Нацарапал прошивку для STM32F411, которая формирует ШИМ сигнал по содержимому в буфере. Значения в Таймер загружает DMA в кольцевом 2х буферном режиме. Пока грузится один буфер - основной цикл подготавливает второй буфер. И бывает так, что по окончании "полезного" сигнала буфер для DMA заполнен не полностью, ну к примеру DMA настроен на буфер в 512 отсчётов, а в очередной цикл буфер заполнился на 100 отсчётов и по окончании нужно остановить генерацию, т.е. выключить таймер. В очередном прерывании DMA (когда меняются местами буферы TCIFn) я могу определить что очередной "работающий" буфер короче ожидаемого, но вот как об этом сказать DMA? Если верить даташиту, то с запущенным DMA уже ничего не поделать, все манипуляции только после остановки. Но если я его остановлю, я получу "ошибки" в генерации выходного сигнала таймером. Варианты: 1. Забивать остаток не полного буфера "нейтральным" сигналом и останавливать DMA при очередном TCIFn после этого - "не полного" буфера. 2. "ловить" DMA на пол пути ещё одним таймером настроенным заранее в TCIFn из расчёта на кол-во отсчётов. Может как-то ещё?
  9. А нельзя в прерывании смотреть кто сейчас держит Mutex и от этого уже отталкиваться?
  10. Усыпляю проц в StandBy с последующим пробуждением по будильнику RTC. Настраиваю будильник, усыпляю, а про просыпается на 16 секунд позже запланированного. и всегда РОВНО на 16 секунд позже. т.е. чтобы мне получить корректное время пробуждения, я должен установить будильник на 16 секунд раньше и тогда получаю желаемый результат. Как так то? Привожу кусочек кода, максимально отчищеный по месту. uint32_t time; uint32_t date; uint32_t subsec; //Выгребаем время из RTC do { time = LL_RTC_TIME_Get(RTC); date = LL_RTC_DATE_Get(RTC); subsec = LL_RTC_TIME_GetSubSecond(RTC); } while (subsec != LL_RTC_TIME_GetSubSecond(RTC)); sec = __LL_RTC_CONVERT_BCD2BIN(__LL_RTC_GET_SECOND(time)); min = __LL_RTC_CONVERT_BCD2BIN(__LL_RTC_GET_MINUTE(time)); hour= __LL_RTC_CONVERT_BCD2BIN(__LL_RTC_GET_HOUR(time)); //Будем ставить будильник на 10 секунд sec+=10; //Тут конечно есть проверки на "переполнение", но для простоты примера этого достаточно. LL_RTC_DisableWriteProtection(RTC); CLEAR_BIT(PWR->CSR, PWR_CSR_EWUP); //Вроде как в Даташите написано, что наждо отключить будильник и дождаться его готовности к записи. LL_RTC_ALMA_Disable(RTC); do {} while (!LL_RTC_IsActiveFlag_ALRAW(RTC)); LL_RTC_ClearFlag_ALRA(RTC); //пишем новое время в будильник А LL_RTC_ALMA_ConfigTime(RTC, LL_RTC_ALMA_TIME_FORMAT_AM, __LL_RTC_CONVERT_BIN2BCD(hour), __LL_RTC_CONVERT_BIN2BCD(min), __LL_RTC_CONVERT_BIN2BCD(sec)); //Реагируем только на совпадение секунд, это отдельная тема LL_RTC_ALMA_SetMask(RTC, LL_RTC_ALMA_MASK_DATEWEEKDAY | LL_RTC_ALMA_MASK_HOURS | LL_RTC_ALMA_MASK_MINUTES); //Не реагируем на субсекунды LL_RTC_ALMA_SetSubSecondMask(RTC, 0); LL_RTC_ALMA_Enable(RTC); LL_RTC_EnableWriteProtection(RTC); //Вывожу в консольку фактическое значение будильника TRACE_INFO("RTC->ALRMAR: 0x%08X\r\n",RTC->ALRMAR); /* Enable the wake up pin */ SET_BIT(PWR->CSR, PWR_CSR_EWUP); //Всем спать. SET_BIT(PWR->CR, PWR_CR_PDDS | PWR_CR_CWUF | PWR_CR_CSBF); SET_BIT(SCB->SCR, ((uint32_t)SCB_SCR_SLEEPDEEP_Msk)); __WFI(); В результате проц проснётся НО! проснётся на 16 секунд позже запланированного. т.е. если в первых строка после пробуждения считать RTC время, то там ровно на 16 секунд больше чем записано в будильнике. Регистр RTC_ALRMAR при выводе в консольку имеет корректные значения на сколько я могу судить. Ну к примеру, выставил я время пробуждения 12:34:56, в регистре RTC_ALRMAR в младших битах значение 0x.....56 (BCD чтоб его так) но проснётся проц в 12:35:12 и в регистре RTC_TR, по мимо всего прочего будет 0x....12 (опять BCD). Как так то? Что я делаю не так?
  11. Спасибо, вроде разобрался. В итоге использую 3 прерывания: IDLE, HTC, TC. Обработчик во всех один и тот же. Вроде пока работает...
  12. Оно приходит спустя где-то 1,5 байта после приёма стоп бита последнего принятого байта.
  13. Всем привет! Что-то я делаю не так... цель моя - запустить DMA в кольцевом режиме для приёма данных с UART. Использую LL библиотеку от STM. Ожидаю получение IDLE прерывания от UART и как следствие чтение данных из DMA. Немного не допонимаю что делать с DMA в данный момент... Как понять сколько байт DMA положила в буфер? Как после обработки этих данных "объяснить" DMA что эти данные уже обработаны? Надо как-то сместить "начало" буфера? Чё-то я туплю :(
  14. Должен ли датчик в режиме термостата отвечать на Reset? Если отвечает, то он в 1-Wire режиме?