MementoMori

Нагрузка - дисплей. Источник - у дисплея AVDD (он отмечен) у микросхемы - +3.3 вольт (могу дорисовать) Вопрос в другом - есть нагрузка, нужен ли ей рукав PGND. Взгляните на топологию Evaluation BOard - там к земляному пину разъема подходят в нижем слое общая земля, в верхнем - рукав аналоговой земли. Если этот рукав отсоединить, понятное дело, что нагрузка не "погаснет", но что-то должно произойти и для чего-то этот рукав нужен. Более того - самый мощный Vout - там конденсатор Сout соединен почти в одной точке и с цифровой землей и с аналоговой. ПРичем это только на одном из Vout.

Того что я нарисовал (хоть и коряво) недостаточно? Я ведь и даташит привел и пример платы. Это педагогическое предложение или по моей графической схеме непонятно?

Оранжевый прямоугольник - у меня в моей топологии такого элемента нет. Путь возвратного тока в той топологии, что у меня сейчас - PGND ножки->красный полигон->мостик->общая цифровая земля в отдельном слое (голубая)->разъем питания. Цифровой возвратный ток - GND ножки->общая цифровая земля в отдельном слое (голубая) -> разъем питания. В Evaluation board PGND на пузе микросхемы соединено кратчайшим путем с общей землей (внутренним слоем GND) мостиком. Дополнительно (у меня это отображено оранжевым прямоугльником, рядом с каждым из Vout идет полигон, который в начале посредством VIA соединен с PGND, а в конце, у самого разъема - с GND (причем далеко от разъема питания). На Evaluation board это смотрится логично - там куча разъемов, в самых разных частях платы. У меня же разъем дисплея, все компактно. Надо ли тянуть этот оранжевый мостик?

Aner, смотрите, на картинку - там в упрощенном виде то, что на моей плате. Оранжевым дорисован рукав, которого нет у меня, но есть на Evaluation Board.

Простите, я конечно любитель и чего-то не улавливаю. Но мне кажется что между этой картинкой и вот этим текстом Есть противоречие. Судя по тексту, ножки DGND и AGND нужно соединять поближе друг к другу и вести их к аналоговому полигону. Судя по картинке - каждую из этих ног нужно вести черти куда и в идеале соединять только у разъема питания. В конкретном устройстве на рассматриваемой микросхеме цифровая и аналоговая части соединяются посредством VIA на уровне 6 сверху в правом ряду ноге (пин 19). Но вот один из выходов - Vout 1 (на моей схеме это AVDD) почему то соединен и с аналоговой землей и, непосредственно у контактных площадок конденсаторов С1, С4 - с цифровой землей. У остальных выходов такого нет. Почему так?

Плотный монтаж, неоходимо один полигон (аналоговая земля) соединить с полигоном в другом слое (общая земля). Хочется сделать это изящно - воткнул VIA (компонент, в составе которого только VIA) и добился желаемого. Можно ли так?

Тогда в бетон нужно заливать. Бетон только долбить. Вместе с платой

Вы не поняли. Я знаю как это добавить, но я удивляюсь почему программа генерации проекта это не сделала (у меня нет двух ваших пунктов), но проект работает. Значит картинка во внутреннем флеше. Что странно, ведь если в тексте программы объявлен адрес внешней памяти то....

Хм.... у меня в сгенерированном проекте только первый пункт из тех, что приведены на скриншоте. По идее программа должна была сгенерировать правильные настройки, но этого не случилось. Значит картинка у меня во внутреннем флеше?

Вот схема LCD_Power_Sheet.pdf

что у них есть секретный растворитель компаунда?))

Вот то первое, что изучил я - там прекрасно, пошагово описано как на примере STM32F746 смоделировать сигналы SDRAM и QSPI. Мне хватило. По моделированию питания - были ролики на ютубе, найду ссылки, выложу. Но это по HyperLynx 9.4, по HyperLynx DRC мануалов у меня нет, но там все подозрительно просто. IBIS.pdf

Поигрался с платой STM32F746G-Disco и TouchGFXDesigner. Все предельно просто - кидаешь картинку на форму, указываешь в настойках ее размещение (если internal section - то она попадет во флеш контроллера, если external section - то во внешнюю память), генерируется проект, он открывается в Keil, прошивается контроллер - вуаля - картинка в дисплее. У меня вопрос - а как она туда попадает при прошивке? Прошивается ведь флеш контроллера и все.... Сам контроллер с QSPI при этом не общается. Решил что это какая-то фишка встроенного в отладочную плату ST-Link - то есть может быть он как-то распознает некие команды и программирует QSPI Flash - посмотрел схему платы Disco - ничего такого нет..... В чем фокус? Или я чего-то не понимаю и картинки все таки в мкроконтроллере, а не во внешней памяти?

Господа, есть микросхема TPS651000. В даташите указаны земли - цифровые, аналоговые. Есть даже Evaluation board https://www.farnell.com/datasheets/1883830.pdf Вроде бы все по классике - все аналоговые земли через VIA соединены с полигоном, в этот же полигон посредством VIA вшито пузо микросхемы, и вся эта аналоговая земля на уровне вывода 19 микросхемы соединяется с цифровой. Но если посмотреть на Fig 3, на страницах 3-2, 3-3 (такова нумерация) то там интересная картина - к каждому из разъемов, с которых снимаются выходные напряжения , тянется отдельный рукав земли, который вначале через VIA соединяется с аналоговой землей, а ближе к разъему - с цифровой. Есть мысль, что такое решение обусловлено тем обстоятельством, что это отладочная плата и напряжения выведены на разъемы (назовем их "потребители"), раскиданные по плате, у каждого из которых должна быть земля. У меня же ситуация другая - потребителем является дисплей, все питающие напряжения к нему идут рядышком, подходят к компактному разъему, земля у потребителей одна. При такой топологии, я что-то даже теряюсь, как повторить отмеченный мной принцип (заключающийся в наличии нескольких точек соединения цифровой земли с аналоговой). У меня вообще все компактно и ставить у выходных конденсаторов по два VIA - один в цифровую землю, другой в аналоговую мне кажется бредом. Посмотрите, как сделал я. Нужно ли что-то менять? Желтый слой - внутренний, в нем в центре полигон аналоговой земли. Синий слой - нижний - уходящие вправо трассы - выходы синтезированных напряжений - идут к дисплею. LCD_Power_Sheet.pdf

Спасибо. Смущало, что у двух LDO, один из которых питается от другого, расстояние между землями с десяток сантиметров.

Господа, есть DAC, не имеющий раздельных цифровой и аналоговой земель. И его земляной вывод рекомендуется подсоединять к "чистой", аналоговой земле, которая идет прямиком к разъему питания (по классике). Для пущей чистоты выходного сигнала принято решение питать DAC от LDO (На входе LDO 5 вольт, на выходе 3.3 В, от них DAC и питается). Возник вопрос - а GND от LDO куда вешать ? В чистую аналоговую землю, или в цифровую? К слову, 5 вольт, которые берет LDO берутся от другого LDO, питающего 5 вольтами много чего, в том числе и LDO 5->3.3 в. Так вот его земля не отделена, она подсоединена к общей цифровой земле.

Ах... нашел - поставил отрицательный отступ. А в библиотеке CERN кстати, это облегчено - там в подобных компонентах на слой пасты уже нанесены 4 квадратных маленьких региона. И если не трогать отступ пасты - то она сплошная. Если сделать его резко отрицательным - то основной полигон пасты исчезает, остаются квадратики

А как его закрыть? в редакторе параметров вкладка fullStack недоступна. У меня версия 20.0.7

Хочу разбить на квадраты слой трафарета для пасты. По существующему стандарту. Когда в редакторе компонентов пытаюсь редактировать этот слой у меня выбирается ПАД целиком. Я значит, удалил прямоугольник в слое, наивно думая, что это затронуло только слой пасты, добавил 4 более мелких - как выяснилось, я удалил весь пад. Что повлияло и на медь и на паяльную маску. Может функция где есть - разбить на квадраты слой пасты с заданием процента от исходного?

Так в этом то и вопрос - нужно ли оптимизировать ради таких величин помех? Потому как там настолько все впритык. И если подвинешь что-то и выиграешь 50 мВ в одном, то создашь еще большие проблемы в другом. Есть у меня и 0.2 в помеха. Там линии очень близко друг к другу, но в пределах правила 3W.

Скажите, насколько серьезно нужно относиться к небольшим перекрестным помехам? В HyperLynx DRC у меня по умолчанию стоит порог в 50 mV. Система забраковала все линии CLK при проверке перекрестных помех — при просмотре результатов обнаруживаются цифры вроде 85 mV, 135 mV. Может я конечно сравниваю кислое и черное, но при анализе на звон в программе HyperLynx 9.4 установлен нижний порог — 0.8 вольт и если уровень напряжения в переходных процессах не достигает 0.8, то диаграмма считается нормальной. Или это нельзя сравнивать? В общем, обращать ли внимания на такие предупреждения системы или 50 mV это просто идеал, который необязятелен? P.S. Для справки - у меня на плате SDRAM, QSPI, SDIO, i2c, Контроллер STM32F7

Привет!Только я не продать хочу, купить хочу. А в нашем чипедипе от 2 шт дешевле. 400 рублей всего выгадать можно, но все же мелочь а приятно.Никто не хочет? Я созрел купить уже сегодня. Ну или завтра.https://www.chipdip.ru/product/stm32f746g-disco

Ага.. то есть, если написать соответствующий софт, то железка будет не против. И FatFS тоже. Вопрос другой - умеет ли это библиотека от ST?

Что будет, если к связке STF32F7+FatFS, настроенной в режим USB_Host подключить USB хаб на USB и SD? Вот такой к примеру https://ru.aliexpress.com/item/32887217681.html?spm=a2g0o.productlist.0.0.620d5998dvaSNE&algo_pvid=a379d733-f5d7-4afa-9f80-66b48c7a15a9&algo_expid=a379d733-f5d7-4afa-9f80-66b48c7a15a9-30&btsid=2721b58b-b845-4e33-8a13-5ad8e30a1637&ws_ab_test=searchweb0_0,searchweb201602_3,searchweb201603_52 Увидит ли система два диска, то есть USB и SD карту?

Разобрался. Вдруг кому будет полезно. Если настроить некую ножку под этот Driver_VBUS_HS, то вот что будет в файле usbh_conf.c - MX_DriverVbusHS(state) - управляет той ногой, которую указать в Кубе. USBH_StatusTypeDef USBH_LL_DriverVBUS(USBH_HandleTypeDef *phost, uint8_t state) { if (phost->id == HOST_HS) { MX_DriverVbusHS(state); } /* USER CODE BEGIN 0 */ /* USER CODE END 0*/ HAL_Delay(200); return USBH_OK; } а в usb_h_platform.c void MX_DriverVbusHS(uint8_t state) { uint8_t data = state; /* USER CODE BEGIN PREPARE_GPIO_DATA_VBUS_HS */ if(state == 0) { /* Drive high Charge pump */ data = GPIO_PIN_SET; } else { /* Drive low Charge pump */ data = GPIO_PIN_RESET; } /* USER CODE END PREPARE_GPIO_DATA_VBUS_HS */ HAL_GPIO_WritePin(GPIOA,GPIO_PIN_10,(GPIO_PinState)data); } Можно просто оставить эту настройку в режиме undefined. Появится предупреждение, но код будет сгенерирован. Вот что будет в файле usbh_conf.c - вызов MX_DriverVbusHS(state) исчезнет. USBH_StatusTypeDef USBH_LL_DriverVBUS(USBH_HandleTypeDef *phost, uint8_t state) { /* USER CODE BEGIN 0 */ /* USER CODE END 0*/ if (phost->id == HOST_HS) { if (state == 0) { /* Drive high Charge pump */ /* ToDo: Add IOE driver control */ /* USER CODE BEGIN DRIVE_HIGH_CHARGE_FOR_HS */ /* USER CODE END DRIVE_HIGH_CHARGE_FOR_HS */ } else { /* Drive low Charge pump */ /* ToDo: Add IOE driver control */ /* USER CODE BEGIN DRIVE_LOW_CHARGE_FOR_HS */ /* USER CODE END DRIVE_LOW_CHARGE_FOR_HS */ } } HAL_Delay(200); return USBH_OK; } То есть управление VBUS - это необязательная фишка. Я так полагаю, придуманная для случая, если подключаемый EXT_PHY не умеет управлять VBUS. Я правильно понял смысл?