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

_lexa_

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

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

  • Посещение

Репутация

0 Обычный

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

  • Звание
    Участник
  1. IWDG на stm32f746

    В моем случае данные расположены в DTCM RAM. Кэш не участвует в процессе Вопрос почему без IWDG все нормально работает, а также с WWDG нормально работает остается открытым. Если бы FIFO SPI или DMA переполнялся - это было бы как с IWDG, так и без него. На счет рестарта - тоже маловероятно. в начале программы идет довольно длительная инициализация переферии (порядка 1 с) периодического сигнала мы бы не увидели.
  2. IWDG на stm32f746

    Я включал LSI генератор отдельно, без вочдога - сигнал был чистый. Судя по картинке на участках с минимальной производной (считаем там напряжение постоянным) выбросов нет и с уменьшением производной сигнала выбросы уменьшаются. Если увеличить картинку, складывается впечатление, что выбросы - это просто старые значения. По уровню они вроде как совпадают (разрешение картинки не очень, эксперимент пока повторить не могу). Здесь буду думать в этом направлении. Но опять не понятно почему настройки вочдога не совпадают с его реальной работой. Как будто тактирование идет частотой, пожалуй, раз в 300 большей.
  3. IWDG на stm32f746

    Всем доброго времени суток! В настоящем случае по SPI3 (через DMA) принимаются данные от АЦП. Когда включаю независимый вочдог, получаю странное искажение сигнала Скачки порядка 1000-1500 е.м.р. Код настройки и пуска вочдога: IWDG->KR = 0x0000CCCCu; IWDG->KR = 0x00005555u; IWDG->PR = 2; IWDG->RLR = 1; while(IWDG->SR); IWDG->KR = 0x0000AAAAu; При этом частота и величина скачков не зависит от от настройки регистров PR и RLR. Без IWDG все нормально работает. Кроме того, настраиваю (например) вочдог на частоту сброса 1 мс. Перезагрузку его счетчика в программе произвожу с частотой 15-30 мкс. Однако при запуске программы контроллер сбрасывается, т.е. программа не успевает перезагрузить счетчик вочдога С WWDG при этом все работает как надо Может кто сталкивался с этим?
  4. Мне оптика нужна, 5 портов
  5. KSZ9897S - 5 портов для меди, оптика только через единственный SGMII KSZ9567RTXI - также 5 портов для меди
  6. У них нет моего варианта. Есть FX с PTP, но трехпортовые; есть семипортовые с PTP, но TX; либо 7-портовые FX, но без PTP
  7. Доброго всем времени суток! Прошу помочь в найти микросхему эзернет-коммутатора. Обязательные параметры: 1) 5 портов PHY 100BaseFX, 1 - MII/RMII 2) Поддержка PTP v2 хотя бы по двум PHY портам 3) Температурный диапазон -40 - +85 Желательные параметры: 1) Поддержка PRP/HSR 2) напряжение питания 3.3 В
  8. Многопроцессорность на STM32f4 STM32f7

    Цитата(AVR @ Jan 18 2018, 11:09) Каково же число этих самых процессоров в пределе? Максимум каков? На текущий момент 4, в планах - до 10 Цитата(scifi @ Jan 18 2018, 15:58) Вас что, в детстве протоколами пугали? Дескать, придёт ночью протокол и скушает. Протокол может быть текстом в три строчки. Всё зависит от задачи. А вам похоже езернет деньги платит, раз он вам так нравится. Я просто хочу определить наиболее простой и эффективный вариант решения задачи. Что здесь такого? Цитата(scifi @ Jan 18 2018, 15:58) Предположим, что вы решили все эти заморочки с арбитражем и синхронизацией. Но у данных в этой общей памяти должен быть какой-то формат? Так же, как у кадра Ethernet должен быть формат. Где тут какое-то волшебное преимущество общей памяти - в упор не вижу. Вот пишите вы программу, работаете с какими-то данными в памяти и в каком формате они хранятся? Просто данные по определенному адресу, никакой дополнительной служебной информации
  9. Многопроцессорность на STM32f4 STM32f7

    Цитата(scifi @ Jan 18 2018, 09:13) Ага, изобретаем велосипед Ethernet switch. Эзернет свич тут причем? Будь вместо SPI Ethernet, вопрос с протоколом не уйдет Цитата(scifi @ Jan 18 2018, 09:13) Как будто разделяемая память не требует протокола. Вы просто не понимаете, о чём говорите. Ethernet, проще него трудно что-либо придумать. О каком протоколе речь - синхронизация доступа, арбитраж шины? Синхронизация доступа к памяти часто нужна и в одноядерном процессоре при работе с внутренней памятью. Про арбитраж шины был приведен пример АДСП-шарк, там он выполнен аппаратно, программно городить ничего не надо. Вы что-то из этого называете протоколом?
  10. Многопроцессорность на STM32f4 STM32f7

    Цитата(Forger @ Jan 17 2018, 22:24) STM32F4: "Up to 4 SPIs (45 Mbits/s)" STM32F7: "Up to 6 SPIs (up to 54 Mbit/s)" Есть еще QuadSPI - там еще больше получается. Со скоростями вроде как проблем нет. Идея была в разделяемой памяти. Не спорю,что можно использовать и SPI. Можно написать что-то на подобии шлюза, который с внешними устройствами будет работать по SPI, а для внутренней программы будут функции читающие и пишущие в виртуальные области памяти, которые могут быть собраны из разделов памяти контроллеров. Ну или что-то на подобии. Однако здесь не обойтись без какого-то протокола, кадры которого будут иметь служебные данные. Может случится, что при передаче небольшого куска информации, накладные расходы сожрут всю скорость. Цитата(AlexandrY @ Jan 18 2018, 07:35) А не путаетесь ли вы в предмете обсуждения? У SHARC-ов есть специальный Link Port для взаимодействия между чипами. Разделяемую память они нигде не предлагают для таких целей. Коммуникации внутри самих SHARC - совсем другая тема. Но SHARC-и то всего до 500 МГц работают. Слабовато, однако, по современным меркам. С шарками не имел дела года с 2005, но сейчас посмотрел наискосок документацию на ADSP-2106x, у них не только линк-порт, их также можно подключать на общую параллельную шину, на которой также может висеть и память. При этом не только внешняя память, но и части памяти всех процессоров на шине будут отображаться в общую область. Чем это не разделяемая память по сути? 500 МГц это конечно круто. Не стали с ним работать из-за его громоздкости, микросхемы на 100 ног подходили больше. И эзернета не было. Но столько воды с тех пор утекло. Может сейчас конечно все поменялось.
  11. Многопроцессорность на STM32f4 STM32f7

    Цитата(scifi @ Jan 17 2018, 11:13) Требования по скорости не озвучены. скорость порядка 40 Мбит/с Цитата(AlexandrY @ Jan 17 2018, 12:09) Не, это архаичный и устаревший подход. В гетерогенных мультиконтроллерных структурах его не применяют. Откуда эта сомнительная цифра в 64Кб. Параллельная шина тоже не вызывает энтузиазма. Речь же не о мультиядерных кристаллах. Мне нравится идея, что контроллеры могут работать с разделяемой областью памяти. Считаю, что такие системы обладают максимальной гибкостью. Здесь уже упоминались шарки. Чем плоха их идея построения кластеров? Цитата(AlexandrY @ Jan 17 2018, 12:09) Вам нужно что типа Greybus и RTOS с поддержкой мультипроцессорности. Главная фишка такой шины - хардварная маршрутизация. Из доступныйх RTOS с поддержкой мультипроцессорности и софтварной маршрутизацией будет MQX, какие-то потуги для отдельного железа были у FreeRTOS. В MQX вы можете посылать ивенты и сообщения любым задачам на другие микроконтроллеры. Запускать и останавливать задачи на любых микроконтроллерах. При этом шина связи может быть любая: I2C, SPI, UART, CAN, Ethernet... Думаю аппаратную быструю маршрутизацию можно сделать в i.MX RT на базе их периферии Flexible I/O и eDMA. Да, там еще есть HyperBus. Можно до 333 MB/s развить. Но роутер придется делать самому для нее. Это уже интереснее, хотя куча вопросов, надо изучать. Кроме того RTOS. Честно говоря никогда с ними не работал, возможно в силу предвзятого отношения. Иногда буквально приходится считать такты процессора
  12. Многопроцессорность на STM32f4 STM32f7

    Уточняю задачу. Необходимо сделать устройство состоящее из объединяющей платы с набором слотов, в которые устанавливются платы различного назначения (связь, оцифровка аналоговых сигналов, математические вычисления и др.). Добавление плат хотелось бы выполнять без перенастроек других плат (ну или выполнение минимума настроек). Идеальный вариант - SRAM объемом 64 кБ на объединяющей плате. Микроконтроллеры на платах в слотах получают доступ к SRAM и через нее взаимодействуют между собой. В SRAM выделены области для данных определенного назначения, в соответствии с заранее оговоренными правилами. Каждый Контроллер в системе мог бы обращаться к любой области по необходимости. Получается какая-то параллельная шина. Вопрос - какими средствами ее организовать? Есть документ armv7-m architecture reference manual, в котором предусмотрены средства синхронизации доступа к разделяемой памяти в многопроцессорной системе. Непонятно как и кем это реализовывалось физически (контроллеры с поддержкой разделяемой памяти). А аналог дивайсес этот вопрос неплохо проработан на АДСП, но его не применяем, не устраивает переферия. Цитата(iosifk @ Jan 17 2018, 10:32) Есть LIN - можно на них сделать сеть. Есть МАС - к ним можно добавить свитч напрямую без PHY... И реализовать сеть. А можно свитч сделать на ПЛИС, у Ксайлинкса был выложен проект "меш-коммутатора"... А вот "разделяемая память" - тут сложнее. На сколько абонентов? Какого объема, разрядности и с какой скоростью доступа. Ведь можно сделать Память+(ПЛИС и из нее много SPI). И на эти SPI посадить микропроцессоры. Или скажем квадро-SPI... Можно конечно сделать сеть на базе свича эзернет, можно даже на USART или по CAN шине. Придется использовать какой-то протокол передачи данных. Все это снижает скорость обмена информацией и усложняет алгоритм взаимодействия. Не хотелось бы
  13. Многопроцессорность на STM32f4 STM32f7

    Доброе время суток! Возникла необходимость сделать многопроцессорную систему, причем расширяемую. Также для всех процессоров в системе необходима разделяемая память. Есть запасы STM32f4 STM32f7, поэтому хотелось бы задействовать их. Подскажите, пожалуйста, как можно выполнить поставленные задачи (если возможно имеющимися средствами)?
  14. __LDREX __STREX в STM32F407

    Цитата(jcxz @ Jun 6 2017, 08:20) Открываем мануал на M4, читаем: "The Cortex-M4 processor implements a local exclusive monitor. The local monitor within the processor has been constructed so that it does not hold any physical address, but instead treats any access as matching the address of the previous LDREX. This means that the implemented exclusives reservation granule is the entire memory address range." судя по этому абзацу да по остальному в мануалах (применительно к cortex-m4) для синхронизации на LDREX/STREX достаточно одной единственной ячейки памяти, которую будут читать/писать LDREX/STREX, на весь исполняемый процессором код. А для STM32f4 даже настройки MPU не потребуется (кэша на RAM там нет) Цитата(jcxz @ Jun 6 2017, 08:20) Влияние доступов от DMA и прочих bus-masters на exclusive monitor - также представляется крайне сомнительным, так как: Я так понимаю, AVI-crak просто провел эксперимент, в результате которого DMA сбросил тэг монитора, и здесь не стоит вопрос нужно ли это или не нужно. По поводу того, где это сказано, конечно не совсем про то, но в принципе сюда можно взглянуть: ARMv7-M Architecture Reference Manual A3.4.5 Load-Exclusive and Store-Exclusive usage restrictions • An explicit store to memory can cause the clearing of exclusive monitors associated with other processors, therefore, performing a store between the LDREX and the STREX can result in a livelock situation. As a result, code must avoid placing an explicit store between an LDREX and an STREX in a single code sequence.
  15. __LDREX __STREX в STM32F407

    Цитата(jcxz @ Jun 5 2017, 21:35) Похоже Вы так и не поняли зачем нужен и как работает этот эксклюзивный доступ... AVI-crak доходчиво объяснил:Цитата(AVI-crak @ Jun 5 2017, 18:00) Сброс тег монитора из потока в прерывание - это нормальное поведение LDREX/STREX, именно для этого они и задумывались. Цитата(jcxz @ Jun 5 2017, 21:35) Они и не должны там использоваться если ОС должна быть мультиплатформенной. Они могут использоваться в портах ОС. Понятно - все дураки, и создатели ядра и создатели IAR-а например, да все кто поддерживает эти LDREX/STREX - не понимают они их бесполезность. Объясните им Я же чуть ниже написал, что погорячился. И сообщение поправил, чтоб глаза не резало.