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

    

Golikov

Свой
  • Публикаций

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Гуру
  1. Stm32f7 stack pointer

    Воу воу воу!! Парни остановитесь:) Я только jcxz хотел чтобы меня научил. Это связано его, очевидно, очень глубоким познанием работы АРМа... По сути дела: 1. конфигурация переменные в начале - стэк в конце работает всегда, с небольшим общим объемом, и любыми передвижениями этой конструкции по памяти 2. конфигурация стек до переменных - работает временами на каких-то значения границы работает, на каких-то нет. 3. Я по всякому двигал границы, раздвигал их и перемещал, в случае плохой работы повторяемость 100%. При этом нет фатального падения, есть задержка работы. Этим я исключаю случайные повреждения памяти, потому что вероятность такого везения что в разных конфигурациях я херю одну и туже переменную, да так что это не приводит к тотальному падению - ноль. Так же я исключаю нехватку памяти, потому что имею работоспособные комбинации на объеме значительно меньшем общего объема. Из интересных симптомов пакет данных посылаемый по УДП не теряется, а задерживается до следующего приема (возможно отправки). Причем каждый 4 пакет. То есть я запускаю пинг 3 ответа приходят сразу, 4 приходить только вместе с 5 запросом. И так по кругу. Смотрю диагностику LwIP похоже пакет отдают, то есть скорее всего все застревает в драйвере езернет. Пока нет времени разбираться дальше, но я думаю неверно заправляется ДМА езернета. И мак не стартует перекладку до следующего пакета. Потом происходит еще одна заправка и 2 пакета уходят разом. Как влияет раскладка в памяти? Думаю задержками при переключении басматрикса. Это изменяет время копирования пакетов данных, и конкуренцию с ДМА. Как то так...
  2. Stm32f7 stack pointer

    О да, кстати. Научите использовать мпу для этой задачи. Как бы вы его настроили? Какие сведения он сможет мне дать?
  3. Stm32f7 stack pointer

    несостоятельная теория. Регионы большие я их двигал и вместе и отдельно, там общих данных меньше чем расстояния между регионами. И не понятно почему если граница 0x10000 не наезжают, а если граница 0x20000 наезжают. Куча расположена в конце памяти после bss, и стек она не может достать.... не объясняет изменение поведения от передвижки границы стек-память.
  4. Stm32f7 stack pointer

    кеши выключены уезжал в РАМ всей программой никаких изменений, есть рабочие сочетания, есть нет. Области увеличивали уменьшал, стек поглядел глазами, не улетает он далеко... переполнения практически невероятны Включил отладку lwip ответ на пинг равномерный, говорит интерфейс данные получил, то есть пакет застревает при отправке... Там есть кривое место при заправке дма езернета, вероятно там и косяк...
  5. Stm32f7 stack pointer

    там где? все еще хуже : разметка 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 задержки пинга. Какая то очень черная и очень магия...
  6. Stm32f7 stack pointer

    Всем привет. Столкнулся с очень непонятной штукой. 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 тоже есть проблемы, но значительно реже проявляющиеся. размеры областей роли особой не играют, то есть никаких невлезаний в область памяти нет. Из вещей мной неуправляемых это кусок работы с езернетом забранный из куба. Есть у кого какие-то идеи как может разметка памяти так драматически влиять?
  7. CAN stm32f767 without phy

    ------------------------------------------------------------------------------------- В общем разобрался, тему можно закрывать. Для старта на RX нужна 1, чтобы кан вышел из слип режима. Для этого надо подключить либо внешнюю физику, либо просто замкнуть RX на TX, может можно ногу сделать выходной и зажать в 1. После того как кан вышел из слип мода он уже работает в loopback нормально, независимо есть перемычка или физика, или нет. Вот... проблема приема, естественно, была связана с неправильными фильтрами.
  8. CAN stm32f767 without phy

    ну кан всегда слушает входную линию и при передаче естественно слушает прием для арбитража. Режим loopback отбрасывает реакцию на отсуствие ака - это работает А еще я полагал что линия rx станет точной копией TX но почему то это не так. Если подключить физику то она сама транслирует TX на RX, но по описанию RX пин должен был игнорироваться... Он даже из слипа не выходит, без физики, явно слушает RX с 0 уровнем и ждет там единиц. Физика работает так же как просто перемычка RX-TX но данных все равно не принимаю:(... П,С, код на плюсах, своя библиотека, компилим gcc
  9. CAN stm32f767 without phy

    Всем привет! Пытаюсь получить отправляемое сообщение в режиме loopback на nucleo платке. Платка одна и без физики кана. Кану клоки включил, скорость настроил, в регистре CAN_BTR битик loopback режима поставил. Фильтры настроил на прием по маске, маска 0. На tx пине вижу правильную посылку. Ни прерывания, ни счетчика сообщений входного фифо не вижу. Если loopback отключить - то вижу ретрансмиты, если включить то посылается и вижу статусы удачной посылки, ack игнорируется - то есть как бы все как должно быть в loopback. Однако если физически tx и rx на плате не замкнуть, то кан не выходит даже из слип режима, на rx видит вечный 0. Так и должно быть? Соединения rx и tx внутри кристалла не происходит? Кто пробовал запускать в loopback, можно это сделать без внешней физики?
  10. W25Qxxx импактом шились. Они очень стандартные, проверьте сами в импакте варианты, там же они из списка выпадают.
  11. Входит изготовление платы в этот процесс или нет? Если есть правильно сделанная плата с физикой, то вам надо воткнуть в ПЛИС IP мак контроллера (у производителей ПЛИС есть готовые, но полнофункциональные обычно платные). Воткнуть в ПЛИС софт процессор (ниос или микроблайз) и поднять на них ТСР стэк. Примеров куча, если совсем с езернетом дела не имели, то за месяц, другой разберетесь. Если имели то делов на пару недель. Можно взять какие-либо преобразователи USB-UART это самое простое для организации интерфейса, если не езернет.
  12. Ну напишите память на регистрах, в чем беда то?
  13. Цитата(AVR @ Feb 21 2018, 20:38) Что если будет внешняя SRAM, хоть мегабайт? Про RISC-V я понял, про OpenRISC пишут "Low resource usage: basic implementation fits easily in Spartan-6 LX9" - действительно low, но для меня уже не подходит. Есть еще варианты? Пока думаю какое-нибудь AVR засунуть или подобное. Процу все равно как реализована память. Главное сделать ему туда доступ по той шине по которой он любит, за столько тактов что он хочет. Микроблайз, например, может и с внешней памятью работать, в чем беда то? То что какой-то проц влезает в ПЛИС это не говорит что он ей подходит. Чаще всего это просто как демонстрация верности реализации проца, он там работает на 8 МГц и это край. Если вам нужен проц в ФПГА, то вам нужен проц для нее, и лучше использовать процы от производителей, они тоже небольшие и весьма производительные. Все остальное по ресурсам будет хуже. Вид памяти не должен определять проц.
  14. Процу надо же откуда то программу брать. Так что что-то типа памяти вам все равно надо. Хотя бы собранная на регистрах, но память. Проц надо брать ниос или блейз, они оптимизированы под ФПГА, и будут хорошо работать, лучше чем абстрактные процы, оптимизированные под асики. Риск 5 - это не проц, а система команд. По ней можно реализовать все что хошь от процов класса АРМ кортекс-м0, до апликайшен оут оф ордер процов.