Перейти к содержанию

    

Arlleex

Участник
  • Публикаций

    656
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о Arlleex

  • Звание
    Господин Никто

Контакты

  • Сайт
    http://
  • ICQ
    0

Посетители профиля

2 420 просмотров профиля
  1. Cosmic IdeaSTM8 и тип INT

    Я лично определил для себя типы известной размерности и их пользую. Либо всякие unit32_t, либо пишу свои typedef unsigned long u32 (как пример), в соответствии с документацией на компилятор.
  2. Я вот когда модули для лаборатории делал, себе одну платку отладочную (макет), естественно, спаял и оставил. На ней я применял F429. Сейчас запаяна туда H753, но допаять десяток конденсаторов и запустить как-то не хватает стимула ИМХО, артефакты пропадут, связанные с медленной прорисовкой. Да и поэкспериментировать не сильно большая проблема, полгода назад H753 вышел мне даже дешевле, чем F429. Покупал в Терраэлектронике, но сейчас у них дороговато. Не думаю, что плату переразводить Вам придется, хотя, вроде, у них несовместимость в 100-выводных корпусах. У меня LQFP-176...
  3. Предлагаю тогда не Cortex-M, а Cortex-A. Например, RZ/A1H от Renesas: https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rz/rza/rza1h.html или тот же Zynq 7015 - на ПЛИСе поднимите собственное графическое ядро с желаемым интерфейсом, а 2 Cortex-A9 задействуете по остальным функциям. Никаких линуксов, естественно, не потребуется.
  4. Хотя, я тут подумал... Данные из руководства по программированию не будут противоречить только в следующем случае. Производитель дает свободу выбора положения начала участка в 64 килобайт для размещения ОЗУ, которое может быть вплоть до 16 мегабайт. Но аппаратно выводится 16-битная адресная шина для этого участка, поэтому адресоваться могут только 64 килобайт произвольного, но заданного производителем диапазона. Накидал картинку, как я это вижу. Пишите, согласны, или нет - самому интересно Итак, допустим, адресное пространство команд, как и обещал производитель, 16 мегабайт. Оно слева на картинке. Допустим (самый тупой случай, но он отражает возможность любого положения ОЗУ), Flash начинается до адреса 0x110000, идет себе, идет, и тут вклинивается ОЗУ - по адресам 0x110000-0x11FFFF размещается 64 килобайт пространства ОЗУ, и физически она адресуется по адресам 0x0-0xFFFF 16-битной шиной. Просто контроллер, обращаясь к ОЗУ, будет реально обращаться к адресу со смещением 0x110000. А при доступе к Flash, контроллер адресов всего лишь внесет поправку при доступе к ячейкам, превышающих адрес 0x110000 на объем области для ОЗУ. То есть, если мы хотим адресовать Flash по адресу 0x110001, то физически контроллер сформирует на 24-битной шине к Flash адрес 0x120001. Лишь в этом случае документация не противоречит сама себе и своим картинкам. Подтверждается это тем, что документация гарантирует наличие Гарвардской архитектуры с ненакладываемыми диапазонами адресов в едином адресном пространстве:
  5. Дык самое интересное - утверждается, что область данных тоже 16 мегабайт. Про размещение ОЗУ в конкретной реализации понятно - она (как и вся регистровая модель, Flash, EEPROM и т.д.) сейчас лежит в нулевой секции и, по факту, инструкции с трехбайтной адресацией не нужно использовать. Но просто если я (допустим, как производитель МК) посчитал нужным разместить ОЗУ в конце 16 мегабайтного участка, то столкнулся бы с откровенной ложью товарищей из ST? Ведь область данных - это область данных, и вся она подразумевает возможность подключения RAM к любому участку этой области, как я понимаю. А 16-битная выходная шина адреса области данных как бы намекает, что хотелки нужно бы обрезать Печальненько... Где? К Flash - понятно - все честные 24 бита. К ОЗУ выходная шина адреса имеет 16-битную глубину.
  6. Плодить темы не хочу, отпишусь тут. Чем больше читаю Programming Manual, Datasheet, Reference Manual, тем больше понимаю, что авторы явно что-то путают, недоговаривают, опускают важные детали и особенности, которые могут сыграть злую шутку при разработке (на ассемблере). В общем, в руководстве по программированию CPU, на странице 19 написано: И вот картинка этой шинной архитектуры: Во всех местах, где не лень, в документации пишут, что адресное пространство данных 16Мбайт. Я, может быть, и поверю, только почему на рисунке 4 результирующая шина адреса к области данных идет 16-битная? Как 16 бит адресовать 16 мегабайт могут? И вот в документации куча нестыковок, хочется забросить это дромыхло уже
  7. Как работает DMA в STM32?

    Почему же? Времени между двумя соседними установками запросов на DMA-транзакции от UART, в сравнении с частотой работы контроллера DMA, настолько много, что, вклинившийся между ними запрос от модуля SPI будет обработан между транзакциями от UART, так что Вы этого даже не заметите. В случае же, когда модули UART и SPI выставят линии запроса DMA одновременно (или наложатся во времени), первым будет обработан тот, чей приоритет выше. А вот другое дело, если Вы работаете с высокоскоростными источниками/приемниками, например, памятью. В этом случае, при условии, что контроллер один (к примеру, DMA1), низкоприоритетный запрос будет отложен до лучших времен (пока более высокоприоритетный не будет полностью отработан), поскольку низкоприоритетный запрос не сможет "вклиниться" между двумя последовательными запросами более высокого приоритета.
  8. Как работает DMA в STM32?

    Но это, как уже было замечено выше, "не совсем о том". Да, действительно. Каюсь =(
  9. Как работает DMA в STM32?

    И не так, и не так. Роль активного мастера назначается в этих контроллерах по карусельному типу: контроллер шинных мастеров поочередно подключает активных мастеров одного приоритета к соответствующей разделяемой шине. Соответственно, вклинивание в транзакции USART каналом SPI может произойти в любой момент (зависит от соотношения скоростей работы UART и SPI). Например: UART посылает 100 байт за 1 секунду, а SPI в тот же самый момент активации отправляет данные со скоростью 3 байта в секунду. Это значит, что примерно через 33 байта, переданных по UART, управление шиной возьмет другой канал DMA и отправит байт по SPI. Потом на момент передачи 66 байт по UART настанет очередь выстрелить байт из SPI, а потом - спустя 99 байт и т.д...
  10. Keil MDK-ARM ошибка: L6236E

    1. МК какой? 2. Если в нем есть FPU, включен ли он? 3. Уровень оптимизации какой? 4. По шагам если идти, состояния переменных temper_int, temper_float правильные? Сделайте полную очистку и последующую пересборку проекта. И да, прототип все-таки нужно сделать.
  11. Keil MDK-ARM ошибка: L6236E

    Как оно вообще компилируется? Что за операция такая в Си <>? Где равенство открывающих и закрывающих скобок в выражении присвоения val1?
  12. Точность внутрених клоков в STM32L4

    Открыл даташит на камень. Вижу, что HSI там на 16МГц, а не на 8, как Вы представили. А второй не MCI, а MSI - он? Да даже если так, очень странно, что такие измерения получили... Чем частоту меряли? Поверенным прибором или китайским осциллографом с алиэкспресс? МК - китай-подделка, или оригинал? Ведь, судя по даташиту, производитель гарантирует уровень характеристик в указанном диапазоне температур...
  13. Да да, тут я уже впопыхах опечатался Ну я вот глядел на STM8S207 (или какие-то другие более старшие серии, нежели STM8S003, в общем) - там при наложении портов будет иметь приоритет бит в AFR, положение которого ближе к LSB. Вот я и подумал, а что, если я возьму, и включу AFR0 и AFR1 Собственно, тоже думаю, что копипаста... На всякий случай задал вопрос в поддержку STMicroelectronics, ради успокоения души.
  14. Я полагаю правильным не вступать с Вами в полемику хрен знает ради чего. Я лишь хотел сказать, что далеко не всегда нужно явно разрывать земли устройства. Иногда это может только ухудшить характеристики. А свой быдлоопыт оставьте при себе, а то, я смотрю, прям подорвало у Вас что-то беспричинно.
  15. ИМХО, разделение земель и прочая фигня - лишь фантазии каких-то теоретиков. На практике разделение земель может привести к полной или частичной неработоспособности девайса. Земля так вообще не должна рваться, а быть как можно сплошнее - одним полигоном без прорезей, огромных дырок и т.д. по путям возвратных токов. Проектировать плату нужно с пониманием структуры девайса: где питание будет проходить, где силовые токи от него потекут, куда возвратные токи от микросхем потекут и т.д., и не трассировать их там, где находятся нежные аналоговые каскады АЦП/ЦАП. Из личного опыта - даже по советам из мануалов на сами АЦП разделяя земли, точь-в-точь как в даташите, получали настолько хреновый результат, что возникло такое чувство, что тот самый мануал писали нанятые вчерашние студенты. Как только переделали сплошным неразрывным полигоном с хорошей разводкой питания и цифровых линий вывода данных, все стало на свои места. И такая картина была несколько раз в моей практике (хотя я больше программист, но, бывает, нужно развести платку - и начинается штудирование мануалов по разводке, расположению, взаимовлиянию компонентов и т.д.).