Golikov
-
Постов
4 240 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные Golikov
-
-
О да, кстати. Научите использовать мпу для этой задачи. Как бы вы его настроили? Какие сведения он сможет мне дать?
-
Всё тривиально: какая-то переменная наезжает на другую и пакостит ей. Когда меняете размётку, то она наезжает или на пустое место или на некритичную переменную.
Вангую активное использование кучи и указателей в вашем проекте :laughing:
несостоятельная теория. Регионы большие я их двигал и вместе и отдельно, там общих данных меньше чем расстояния между регионами.
И не понятно почему если граница 0x10000 не наезжают, а если граница 0x20000 наезжают.
Куча расположена в конце памяти после bss, и стек она не может достать....
Там, где Ethernet, там и DMA. Если сделано криво, DMA тоже может напакостить там, куда ему лезть не положено.не объясняет изменение поведения от передвижки границы стек-память.
-
кеши выключены
уезжал в РАМ всей программой никаких изменений, есть рабочие сочетания, есть нет. Области увеличивали уменьшал, стек поглядел глазами, не улетает он далеко... переполнения практически невероятны
Включил отладку lwip ответ на пинг равномерный, говорит интерфейс данные получил, то есть пакет застревает при отправке... Там есть кривое место при заправке дма езернета, вероятно там и косяк...
-
там где? все еще хуже :
разметка
SP: 0x20010000
RAM:0x20010000
работает
SP: 0x20020000
RAM:0x20020000
каждый 4 пинг 1 секунда, прям регулярно, 3 нормальных, 1 в секунду...
SP: 0x20010000
RAM:0x20020000
задержки пинга
SP: 0x20080000
RAM:0x20020000
работает
SP: 0x20020000
RAM:0x2002С000
задержки пинга.
Какая то очень черная и очень магия...
-
Всем привет.
Столкнулся с очень непонятной штукой. GCC под Stm32F767, оптимизация О2, никакой линкер оптимизации.
Разметка памяти:
RAM = 0x20000000, size 0x80000,
data и bss - лежит с начала RAM
stack poitner задается на 0x20080000
тут все работает прекрасно, если сделать
RAM = 0x20000000, size 0x80000,
data и bss - лежит с 0x20010000
stack poitner задается на 0x20010000
тоже все работает хорошо, но если сделать
RAM = 0x20010000, size 0x70000,
data и bss - лежит с 0x20010000 (с начала RAM)
stack poitner задается на 0x20010000
то никаких падений нет, но начинаются проблемы в обмене по езернету. Пакеты застревают, причем не теряются, они все есть, но почему то временами не отправляются. То есть приходит UDP запрос, ответа нет, а со следующим запросом приходит ответ на этот и на предыдущий.
При этом в разметке
RAM = 0x20000000, size 0x20000,
data и bss - лежит с начала RAM
stack poitner задается на 0x20080000
тоже есть проблемы, но значительно реже проявляющиеся.
размеры областей роли особой не играют, то есть никаких невлезаний в область памяти нет. Из вещей мной неуправляемых это кусок работы с езернетом забранный из куба. Есть у кого какие-то идеи как может разметка памяти так драматически влиять?
-
-------------------------------------------------------------------------------------
В общем разобрался, тему можно закрывать.
Для старта на RX нужна 1, чтобы кан вышел из слип режима. Для этого надо подключить либо внешнюю физику, либо просто замкнуть RX на TX,
может можно ногу сделать выходной и зажать в 1.
После того как кан вышел из слип мода он уже работает в loopback нормально, независимо есть перемычка или физика, или нет. Вот...
проблема приема, естественно, была связана с неправильными фильтрами.
-
ну кан всегда слушает входную линию и при передаче естественно слушает прием для арбитража.
Режим loopback отбрасывает реакцию на отсуствие ака - это работает
А еще я полагал что линия rx станет точной копией TX но почему то это не так. Если подключить физику то она сама транслирует TX на RX, но по описанию RX пин должен был игнорироваться...
Он даже из слипа не выходит, без физики, явно слушает RX с 0 уровнем и ждет там единиц.
Физика работает так же как просто перемычка RX-TX но данных все равно не принимаю:(...
П,С, код на плюсах, своя библиотека, компилим gcc
-
Всем привет!
Пытаюсь получить отправляемое сообщение в режиме loopback на nucleo платке. Платка одна и без физики кана.
Кану клоки включил, скорость настроил, в регистре CAN_BTR битик loopback режима поставил.
Фильтры настроил на прием по маске, маска 0.
На tx пине вижу правильную посылку. Ни прерывания, ни счетчика сообщений входного фифо не вижу.
Если loopback отключить - то вижу ретрансмиты, если включить то посылается и вижу статусы удачной посылки, ack игнорируется - то есть как бы все как должно быть в loopback.
Однако если физически tx и rx на плате не замкнуть, то кан не выходит даже из слип режима, на rx видит вечный 0. Так и должно быть? Соединения rx и tx внутри кристалла не происходит?
Кто пробовал запускать в loopback, можно это сделать без внешней физики?
-
W25Qxxx импактом шились. Они очень стандартные, проверьте сами в импакте варианты, там же они из списка выпадают.
-
а w25q64... какие-нибудь пропали?
-
Входит изготовление платы в этот процесс или нет?
Если есть правильно сделанная плата с физикой, то вам надо воткнуть в ПЛИС IP мак контроллера (у производителей ПЛИС есть готовые, но полнофункциональные обычно платные). Воткнуть в ПЛИС софт процессор (ниос или микроблайз) и поднять на них ТСР стэк. Примеров куча, если совсем с езернетом дела не имели, то за месяц, другой разберетесь. Если имели то делов на пару недель.
Можно взять какие-либо преобразователи USB-UART это самое простое для организации интерфейса, если не езернет.
-
Ну напишите память на регистрах, в чем беда то?
-
Что если будет внешняя SRAM, хоть мегабайт?
Про RISC-V я понял, про OpenRISC пишут "Low resource usage: basic implementation fits easily in Spartan-6 LX9" - действительно low, но для меня уже не подходит.
Есть еще варианты? Пока думаю какое-нибудь AVR засунуть или подобное.
Процу все равно как реализована память. Главное сделать ему туда доступ по той шине по которой он любит, за столько тактов что он хочет. Микроблайз, например, может и с внешней памятью работать, в чем беда то?
То что какой-то проц влезает в ПЛИС это не говорит что он ей подходит. Чаще всего это просто как демонстрация верности реализации проца, он там работает на 8 МГц и это край. Если вам нужен проц в ФПГА, то вам нужен проц для нее, и лучше использовать процы от производителей, они тоже небольшие и весьма производительные. Все остальное по ресурсам будет хуже. Вид памяти не должен определять проц.
-
Процу надо же откуда то программу брать. Так что что-то типа памяти вам все равно надо. Хотя бы собранная на регистрах, но память.
Проц надо брать ниос или блейз, они оптимизированы под ФПГА, и будут хорошо работать, лучше чем абстрактные процы, оптимизированные под асики.
Риск 5 - это не проц, а система команд. По ней можно реализовать все что хошь от процов класса АРМ кортекс-м0, до апликайшен оут оф ордер процов.
-
а import package_name::enum_name::* не работает?
-
Генерируемое - это нетлист?
Если нетлист, то генерайт уже сработал, и естественно изменить чего-то после вы не можете.
Надо генерить 2 версии, а выбирать уже при подключении. ИМХО.
-
Надо включить MPU и задать атрибуты региону на запрет кеширования и все такое, есть вероятность что СТМ периферия правильно отработает эту ситуацию.
-
Скорее всего человек не чистить фифо перед началом работы, и пока настраивает линию у него наваливается нулей, которые он радостно вычитывает и выдает первыми..
-
define - это когда их используют как параметры. Тут все как с С, и проблемы те же. Им и прощай.
А дефайн для ветвления - ок и он все еще с нами
`define EDGE_CLK posedgeименно такое решение я и видел. Я бы предпочел генерайт, именно в силу ограничений дефайна.
Боюсь реально необходимость настраиваемого фронта для модуля - ненужная вещь, которая множит ошибки. Если же вы думаете про технику улучшения времянок когда не успевая принять по переднему фронту, переходят на задний - так это порочная практика, ее надо пресекать. Да, да...
-
строго говоря в СПИ иногда надо клок инвертировать:)
iff a - это конструкция для условной симуляции
Если оставить вопросы зачем это надо, то один раз я видел решение подобно проблемы через дефайн, который по сути текстовая подстановка. Но по мне генерайт лучше.
Кстати там же автор решал проблемы выбора синхронного и асинхронного сброса.
-
А зачем вы спорите то?
Kintex UltraScale
Block RAM Blocks
KU060 KU085 KU095 KU115
1,080 1,620 1,680 2,160
они 2 портовые, по 1 или 2 кБайта
ставим 1000 таких блоков. На один порт к каждому блоку вешаем модуль обработки (можно процессор). Другим портом все блоки цепляем к одному маку. Шина данных общая, адреса муксятся. Мак сможет во все блоки писать по очереди (как принимает данные), контроллеры одновременно забирать данные (параллельно).
Решение реализуемо, и не очень сложное.
Все! решение есть - тема исчерпана. Не надо его отговаривать, если человеку контроллер за 100 евро копейки, то зачем с ним спорить то?
-
Вы пишите по одному интерфейсу, а читаете по другому?
Есть возможность записать и считать по одному и тому же?
Может в угоду какой-то оптимизации линии данных переставлены.
-
Как правильнее поступать в подобных случаях ? У меня все работает, но нагромождение флагов и прочей фигни делает код нечитаемым даже для меня
Один раз решал подобную задачу так:
Было несколько блоков с сигналами старт-готово, и шиной управления (в вашем случае это СПИ). Блоки жили каждый в своем файле.
Был общий автомат который по очереди подключал шину управления выбранного блока к шине идущей на управляемое устройство и давал сигнал старта, потом ожидал сигнала готовности, отключал блок и переходил к следующему.
Все было достаточно управляемо
-
1. бинарная запись, с явным указанием размера
2. шестнадцетиричная запись, с явным указанием размера
3. десятичная запись, без указания размера, число по умолчанию имеет размер 32 бита
Stm32f7 stack pointer
в STM
Опубликовано · Пожаловаться
Воу воу воу!! Парни остановитесь:)
Я только jcxz хотел чтобы меня научил. Это связано его, очевидно, очень глубоким познанием работы АРМа...
По сути дела:
1. конфигурация переменные в начале - стэк в конце работает всегда, с небольшим общим объемом, и любыми передвижениями этой конструкции по памяти
2. конфигурация стек до переменных - работает временами на каких-то значения границы работает, на каких-то нет.
3. Я по всякому двигал границы, раздвигал их и перемещал, в случае плохой работы повторяемость 100%. При этом нет фатального падения, есть задержка работы.
Этим я исключаю случайные повреждения памяти, потому что вероятность такого везения что в разных конфигурациях я херю одну и туже переменную, да так что это не приводит к тотальному падению - ноль. Так же я исключаю нехватку памяти, потому что имею работоспособные комбинации на объеме значительно меньшем общего объема.
Из интересных симптомов пакет данных посылаемый по УДП не теряется, а задерживается до следующего приема (возможно отправки). Причем каждый 4 пакет. То есть я запускаю пинг 3 ответа приходят сразу, 4 приходить только вместе с 5 запросом. И так по кругу. Смотрю диагностику LwIP похоже пакет отдают, то есть скорее всего все застревает в драйвере езернет. Пока нет времени разбираться дальше, но я думаю неверно заправляется ДМА езернета. И мак не стартует перекладку до следующего пакета. Потом происходит еще одна заправка и 2 пакета уходят разом.
Как влияет раскладка в памяти? Думаю задержками при переключении басматрикса. Это изменяет время копирования пакетов данных, и конкуренцию с ДМА. Как то так...