repstosw

Серьезнее некуда. Было и то и другое (случай с киви и со штрафом ГИБДД). К счастью всё разморозили, но нервов и времени потрачено - куча. Более я не пользователь карт, кошельков.

8 бит всего. Надо ШД 32 бит.

Оплата в банке занимает у меня не более 10 минут. И не иду туда целенаправленно, планирую сразу несколько дел по одному пути. А вот использовать киви которые могут заблокировать и присвоить себе деньги, а потом доказывать, что не верблюд, те же упомянутые вами комиссии от мудаков платёжных шлюзов - ой как удобно, да? Да и нет у меня банковских карт. Оплатил через знакомых. И заводить их нет желания. Про глобальную слежку слыхали? А приятно будет когда вам заморозят деньги на карте из-за того, что не вовремя оплатили штраф ГИБДД? Увы, это реалии сегодняшнего дня. Никаких карт, кошельков. Только наличные!

Мне линукс не нужен. Также как и другие операционки в МК. Ну и мутно в документации. SDK баре-метального нет. Нужно что-то наподобие как STMCube MX для STM32 + нормальный референс-мануал. Ни того и ни другого в олвиннерах нет. Раскурил его UART и GPIO. Ну и автономный загрузчик. Дальше понял, что секс с линуксом должен быть жестким. У меня только 1 жизнь всего, времени мало, чтобы позволить себе ковырять его BSP несколько месяцев. Мне тоже понравилась идея, но причем тут ардуинщики? Ну и сколько времени ждать, пока пойдут первые МК с такой шиной? Да, удивляет их консервативность подхода. Сделать 743-й чип и позиционировать его как для "графических приложений" с внутренней памятью 1 МБ, которая ещё и фрагментирована. Даже MMU не удосужились приделать как в AT91RM9200 с трансляцией физических адресов в виртуальные - так можно было фрагменты склеить на уровне программиста. И специфика по скорости ещё у этих кусков разная. Будущее за МК со встроенной памятью. Только сразу SRAM на частоте ядра. nDR-ы даже не понадобятся.

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

Там 16M x 32 максимально. Нужно хотя бы 32 M x 32. На маузере тоже смотрел - нет. А DDR нельзя использовать в режиме SDR SDRAM ? (на всякий случай спросил, вдруг чудо ожидаемо? :biggrin: )

Приветствую! :rolleyes: Напишите пожалуйста марки микросхем SDRAM с шиной 32 бита, ёмкостью, большей, чем 16M x 32 и желательно работающей на 200 МГц(SCLK). Желательно 128 МБайт или ещё лучше 256 МБайт. Для работы с STM32H743 Каскадирование микросхем по ширине шины и по размеру - не предлагать!

Да, попутал. Я думал, что паяльная маска убирается нечто похожим на снятие галочки с "force complete tenting on top/bottom", как это было с via или pad-ами. Искал именно её. А так да, создал в Top/Bottom Solder -слоях защитные регионы. Проблема решена. Решение найдено здесь: https://electronics.stackexchange.com/quest...tium-pcb-design

Использую Altium Designer 6-й версии по ряду причин, не позволяющих перейти на более поздний. Сделал контактные площадки сложной нестандартной формы с помощью Solid Region. При генерации гербера, площадки закрываются паяльной маской, а надо чтоб были открыты. В свойствах не нашёл где настраивается наличие/отсутствие паяльной маски. Картинка ниже. Как заставить Altium 6 эти контактные площадки делать открытыми от паяльной маски?

OK, спасибо. Посмотрел - 1,5 мА от силы. У ЦАП-а ещё меньше. Надеюсь, что в 50 мА уложусь (1 ЦАП + PLL).

Использую STM32H743 на частоте 400 МГц, шина 200 МГц. Питания Vdd , AVdd , VREF = 3.3V Интересует ток потребления аналоговой части(желательно максимальная амплитуда(пиковый)) - именно PLL (синтезаторы частоты) + ЦАП (один канал). В референсе инфу не нашёл. Где можно почитать об этом?

Нет. Я хотел использовать один и тот же аккумулятор для всего питания. Так и сделано (см. схему). В схеме 2 LDO, запитывающихся от аккумулятора: один LDO для цифровых линий, второй LDO для аналога(ЦАП STM32, VREF и УНЧ). Но я хотел кинуть питание на УНЧ с аккумулятора, чтобы немного повысить КПД по энергетике и снизить нагрев(нагрузку) на второй аналоговый LDO. Но при этом чтобы в тракте НЧ не наводились шумы от перепадов напряжения питания аккумулятора. Видать не выйдет, поэтому буду брать питание с аналогового LDO (у него максимальный ток отдачи 150 мА, максимальный ток потребления УНЧ до 100 мА, + аналоговая часть STM32 ? мА). Каков ток потребления аналоговой части STM32H743 ? (PLL + ЦАП) ? В референсе есть эта информация?

У меня сомнения в том, что по входу включение не-дифференциальное : сигнал снимается с ножки выхода ЦАП (диапазон напряжения 0 В ...+VREF В) относительно AGND , которая организована как отдельный полигон и соединяется с полигоном цифровой земли через резистор 0 Ом в единственном месте. Боюсь, что перепады напряжения питания Li-Ion аккумулятора (общий ток потребления устройства 0.25 А максимум) будет наводить помеху в AGND через GND. На цифровые узлы свой LDO, который из 3.7 В Li-Ion делает 3.3 В (ток до 0.5 А максимально). Shutdown в схеме всегда посажен на землю (без управления от МК). Землю микросхемы УНЧ садить на аналоговую или цифровую(общую) ? Или всё-же подать питание на УНЧ от LDO, который используется для AVCC +VREF для STM32. И землю подключить к AGND STM32 ? Схема ниже. Пока запитал УНЧ от аналогового LDO (который также питает ЦАП и аналоговые цепи внутри STM32): свои AVCC и AGND. На схеме FB - ферритовая бусина. 3A3 - аналоговое питание 3.3V. A - аналоговая GND

Доброе время суток! Исходный звуковой сигнал (полоса частот 60 Гц - 24 кГц) беру с выхода ЦАП STM32, напряжение VREF хорошего качества - аналоговая земля, на AVCC свой стабилизатор напряжения LDO 3.3 В. Сигнал поступает на вход УНЧ на микросхеме LM4871, которая представляет собой мостовой УНЧ (нагрузка подключается гальванически напрямую к выходам двух ОУ без земли). Рисунок ниже. Выход ЦАП относительно Analog GND. Можно ли запитать УНЧ LM4871 напрямую от литиевого аккумулятора 3.7V, а не через аналоговый LDO 3.3V (который для опоры ЦАП STM32) без опасения, что помехи по цепи питания (микроконтроллер STM32 400 МГц + цифровые узлы) наведут шум тракте НЧ ?

Это здОрово, что есть уже аппаратное решение. Но в моём случае - возможность воспроизведения видео-потоков PackMan и H264 - это "ОДНА ИЗ ВСЕХ" возможностей, которых много. Поэтому гибче софтово было решить.

Оказывается, эта проблема существует уже много лет : https://community.st.com/s/question/0D50X00...-of-stm32f407ig

Всем привет! :rolleyes: :1111493779: В связи с освоением процессора STM32H743 на базе отладочной платы Nucleo-H743, были сделаны перенос и модификация Lossless кодека PackMan на разрешение 320x240. Ветка получила кодовое название "PackMan320". Подробнее вместе с исходными текстами программ тут: http://vrtp.ru/index.php?showtopic=29688&st=150 Видео(PackMan320 + FLAC) : http://www.youtube.com/watch?v=s2a_DqrIFaw Ну и попутно ещё сделал декодеры MP4(точнее H.264, пофиксил, у китайцев в коде была ошибка, приводящая к артефактам ) и MP3. Видео: http://www.youtube.com/watch?v=x3sADTqlfj8 Более подробнее - там же: http://vrtp.ru/index.php?showtopic=29688&st=150

Заимплементировал SDIO в работе декодера видео + FLAC. Переписал Хало-Куб для работы с картами в HIGH_SPEED Mode. У Куба 2 крайности: либо карта в Standard Mode, либо в Ultra High Speed Mode (с понижением питания до 1.8V). Мне же Ultra HS Mode не подошёл, так как питание карты 3.3V. Поэтому сделал поддержку High Speed Mode (3.3V). Частотомер выдал на SDIO CLK 48,6 МГц (вместо теоретических 50 МГц). Подробнее тут: http://vrtp.ru/index.php?showtopic=29688&st=150 Там же исходники (High Speed Mode отключен, включить его - раскомментарить последнюю строку в main.c). Видео в действии: http://www.youtube.com/watch?v=s2a_DqrIFaw

Пробовал все линии и по-очереди делать в LOW. Без бусины тоже не работало, даже при CLK < 1 МГц. И это Куб изначально выставил, а не я :) Был бы у меня глаз осциллограф, можно было посмотреть форму сигнала...... Соглашусь с ув. aaarrr, ферритовая бусина как раз душит СВЧ-всплески, от которых карта может несанкционированно передёргиваться. Это макет. Сделать короче уже трудновато, много другой периферии висит. На релизе будет печатная плата с земляными полигонами и всё как надо. Но футпринт заложить на резистор/бусину не помешает. Мне удалось повысить SD CLK до 48 МГц - карта работает, прикрутил FatFs (не та, то с Куб-ом идёт, а свою отлаженную версию). MP3-файл декодируется нормально. На 96 МГц уже не работает. Никакими командами перевода в High Speed Mode не пользовался, просто увеличил CLK до 48 МГц. Все три карты работают. Спрашивается, зачем нужна команда для перевода в High Speed Mode, когда она при 3,3V нормально работает на быстром клоке 48..50МГц ? В файле stm32h7xx_hal_sd.c сделать изменения в функции HAL_SD_ConfigWideBusOperation(): //.............. #if 0 /* Check if user Clock div < Normal speed 25Mhz, no change in Clockdiv */ if(hsd->Init.ClockDiv >= SDMMC_NSpeed_CLK_DIV) { Init.ClockDiv = hsd->Init.ClockDiv; } else { if(hsd->SdCard.CardSpeed == CARD_ULTRA_HIGH_SPEED) { Init.ClockDiv = hsd->Init.ClockDiv; } else { /* No High speed SD card */ Init.ClockDiv = SDMMC_NSpeed_CLK_DIV; } } #endif Init.ClockDiv = hsd->Init.ClockDiv; //!!! снимаем ограничение на SD CLK SDMMC_Init(hsd->Instance, Init); //.......

Укоротил все линии соединения с SD карточкой до 4 см. Подключил карту к AVCC/AGND. На провод SDIO CLK надел ферритовую втулку. Между выводом питания и землями на карте - три конденсатора: 0,1 мкф(керамика) + 10 мкФ(тантал) + 220 мкФ(электролит) Заработали все три карты! Пробовал убирать ферритовую втулку с SDIO_CLK и понижать частоту SDIO CLK - карты не работают. Инит карты такой (HAL, Cube): static void MX_SDMMC1_SD_Init(void) { hsd1.Instance = SDMMC1; hsd1.Init.ClockEdge = SDMMC_CLOCK_EDGE_RISING; hsd1.Init.ClockPowerSave = SDMMC_CLOCK_POWER_SAVE_DISABLE; hsd1.Init.BusWide = SDMMC_BUS_WIDE_4B; hsd1.Init.HardwareFlowControl = SDMMC_HARDWARE_FLOW_CONTROL_DISABLE; hsd1.Init.ClockDiv = 0; } Частотомером обнаружил, что Куб не даёт сделать частоту SD CLK выше, чем 24.176 МГц. Иными словами, все делители hsd1.Init.ClockDiv, меньшие чем 4 - не прокатывают - частота 24.176 МГц. Снять это ограничение можно, расковыряв HAL Куба. Ниже частоты SD CLK, измеренные частотомером и значения hsd1.Init.ClockDiv: На сильно низких частотах касание щупа частотомера к SD CLK приводит к повисанию SD карты. GPIO настроены так (на всех линиях -встроенные PULL UP, кроме CLK. Внешних резисторов нет): void HAL_SD_MspInit(SD_HandleTypeDef* hsd) { GPIO_InitTypeDef GPIO_InitStruct; if(hsd->Instance==SDMMC1) { /* USER CODE BEGIN SDMMC1_MspInit 0 */ /* USER CODE END SDMMC1_MspInit 0 */ /* Peripheral clock enable */ __HAL_RCC_SDMMC1_CLK_ENABLE(); /**SDMMC1 GPIO Configuration PC8 ------> SDMMC1_D0 PC9 ------> SDMMC1_D1 PC10 ------> SDMMC1_D2 PC11 ------> SDMMC1_D3 PC12 ------> SDMMC1_CK PD2 ------> SDMMC1_CMD */ GPIO_InitStruct.Pin = GPIO_PIN_8|GPIO_PIN_9|GPIO_PIN_10|GPIO_PIN_11; // |GPIO_PIN_12; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_PULLUP; //!!! включить подтяжки! GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate = GPIO_AF12_SDIO1; HAL_GPIO_Init(GPIOC, &GPIO_InitStruct); //C12 => CK, NO PULL GPIO_InitStruct.Pin = GPIO_PIN_12; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_NOPULL; //!!! GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate = GPIO_AF12_SDIO1; HAL_GPIO_Init(GPIOC, &GPIO_InitStruct); GPIO_InitStruct.Pin = GPIO_PIN_2; GPIO_InitStruct.Mode = GPIO_MODE_AF_PP; GPIO_InitStruct.Pull = GPIO_PULLUP; //!!! включить подтяжки! GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_VERY_HIGH; GPIO_InitStruct.Alternate = GPIO_AF12_SDIO1; HAL_GPIO_Init(GPIOD, &GPIO_InitStruct); /* USER CODE BEGIN SDMMC1_MspInit 1 */ /* USER CODE END SDMMC1_MspInit 1 */ } } Иллюстрации ниже (подсоединение, втулки и SD-карты, которые успешно работают): Пробовал в High Speed Mode наскоряк переключить - не работает. Включал путём установки: #define USE_SD_TRANSCEIVER 1

Удалось запустить SD карту SD HC 10-й класс скорости + 1-й класс в терминологии UHS-I . Емкостью 16 ГБ. Сектора стали нормально читаться после как на линию CLK повешал ферритовую втулку (с провода питания ноутбука - длина суть больше 1 см). Без ферритовой втулки даёт CRC-ERROR и битые данные. Остальные карты с 2 и 4 ГБ не работают даже с втулкой. Карта подключена к отладке Nucleo-H743 проводами длиной около 15 см. Надо будет попробовать укоротить насколько возможно. Питание на карту беру от встроенного на плате LDO 3,3V. Между питанием и землёй карты - тантал 10 мкФ + керамика 0.1 мкФ.

Не переживайте. Скорее всего Хал/Куб что-то не учли, и проблема решается вставкой ворк-эраунда. На 407-м тоже пришлось копаться несколько дней(закончилось скачиванием обновленной библиотеки с фиксом). Приложил результат - слева правильное чтение сектора на ПК, справа - не верное чтение (пропуск символов, не те)- на STM32H743:

Подсоединил DS карту к STM32H743(отладка Nucleo) к SDIO1. Сгенерировал Кубом Хал и вперёд. Читаю нулевой сектор SD карты, который я видел и сравниваю с заранее правильно считанным эталоном побайтно. Сравнение показывает разный результат. Выводил содержимое 0-го сектора на дисплей: часть байтов пропускается или не те, что нужно. Режим без ДМА. Отключал кеширование, выравнивал буфер данных на 512 байт - ничего не помогло. Удалось обнаружить, что функция чтения HAL_SD_ReadBlocks(SD_HandleTypeDef *hsd, uint8_t *pData, uint32_t BlockAdd, uint32_t NumberOfBlocks, uint32_t Timeout) возвращает всегда: HAL_SD_ERROR_DATA_CRC_FAIL Эррата на H743 даёт мутное описание, что-то связанное с линией данных 2 (Wrong data line 2 generation between two blocks  during DDR transfer with Read wait mode enabled) Но раскурить не удалось. Клок тоже понижал , ставил делитель до 256 - не помогает. Поддтяжки к питанию (PULL UP) всех линий включены. Пробовал 3 карты: 2 ,4 и 16 ГБ - со всеми тремя фигня. На STM32H407 с SDIO все карты работают. В чем может быть проблема?

Ой, да ладно! :rolleyes: :biggrin: Мечтать оно не вредно, но реалии намного скромнее. В HAL идёт обращение к NAND как к регистрам: выставляем байты адреса(Addr section), байт команды(Cmd section), затем только читем/пишем(Data section). Нет тут обращения как к массиву даже и близко: HAL_NAND_Read_Page_8b(...) { //........ //Записывается адрес в несколько байт *(__IO uint8_t *)((uint32_t)(deviceAddress | ADDR_AREA)) = 0x00; __DSB(); *(__IO uint8_t *)((uint32_t)(deviceAddress | ADDR_AREA)) = ADDR_1ST_CYCLE(nandAddress); __DSB(); *(__IO uint8_t *)((uint32_t)(deviceAddress | ADDR_AREA)) = ADDR_2ND_CYCLE(nandAddress); __DSB(); //далее ждем....... //Read Page CMD *(__IO uint8_t *)((uint32_t)(deviceAddress | CMD_AREA)) = ((uint8_t)0x00U); __DSB(); //Читаем данные for(; index < size; index++) { *(uint8_t *)pBuffer++ = *(uint8_t *)deviceAddress; } //.............. } У меня делается обращение к дисплею всего 2 записями (CMD_AREA - это A16. =0 - регистр, =1 - данные.): *(__IO uint16_t *)((uint32_t)(deviceAddress )) = ((uint16_t)LCD_REGISTER_N); *(__IO uint16_t *)((uint32_t)(deviceAddress| CMD_AREA )) = ((uint16_t)LCD_DATA); Принцип тот же. А вы предлагаете сделать так (полагая, что если записать смещение в адрес, то оно упадёт на шину): *(__IO uint16_t *)((uint32_t)(deviceAddress | ADDR_AREA | LCD_REGISTER_N)) = ((uint16_t)LCD_DATA); Но этого не будет. Потому что либо товарищ AVI-crak никогда не работал с FMC в режиме NAND, либо он - циничный тролль и издевается надо мной. В мануале на H743 чётко прописан алгоритм взаимодействия FMC c NAND-flash. Что адрес выставляется записью значения в регистр, а не идёт в смещение относительно базы: AVI-crak, Вы бы Бога побоялись что-ли... Ну нельзя ж так издеваться! :05: И перестаньте вводить в заблуждение! ;)

Скажу по секрету, с USB на микроконтроллерах никогда не работал. Только на компе и только через FT232/245. :biggrin: C v3s вопрос о памяти снимается автоматически - 64 biultin :) А на отладках с A13 что есть там уже напаяна DDR. (Olinuxino и SOM) На счёт дисплеев. Пересмотрел все даташиты все LCD, которые использовал и оказалось, что у них всех HOLD после DATA SETUP от 0 до 7 нс. Становится понятным, почему ранее при подключении их к FMC проблем не было. Попался дисплей с обалденно хорошим качеством картинки с SE K800i оригинал (контроллер Toshiba). Но у него HOLD от 15 нс, что нереализуемо на частотах FMC выше 66 Мгц. Пришлось FMC в режим NAND загонять, чтобы выставить нужный HOLD без снижения тактовой частоты FMC (иначе остальные времянки прийдётся загрублять в большую сторону). Но до того как это понял и докопаться до сути - понаставил костыли: 1) Резистор около 2 кОм на !CS 2) Постоянно посыл команды Write Data , перед отправкой фреймбуфера 3) Костыль в алгоритме инициализации Теперь все костыли ушли в небытиё! Дисплей стабильно работает и рисует непрерывно кадр через DMA бе опорных команд (позиция по X,Y; write data) и ничего не съезжает. FMC в режиме NAND рулит! :rolleyes: Правда, на смежном форуме меня пытались убедить, что через NAND мол, можно к дисплею обращаться как к массиву. Но в STM32 адрес NAND Flash задаётся через запись в регистр, также как и данные. Так что смещения относительно базового адреса NAND не вышло. А было бы очень изящно: все регистры дисплея - элементы массива(или структуры), вместо раздельных посылок: адреса и данных.