Jump to content

ruhi

Members
  • Content Count

    407
  • Joined

  • Last visited

Community Reputation

39 Обычный

About ruhi

  • Rank
    Постоялец

Информация

  • Пол
    Мужчина
  • Город
    Дзержинск

Электроника

  • Стаж в электронике
    10-20 лет
  • Сфера радиоэлектроники
    радиотехника, программирование
  • Оборудование
    радиотехника, цифровая обработка сигналов, управление, любые процессоры и их обвязка

Recent Profile Visitors

1032 profile views
  1. Как это "отключаю DHCP", кто ее включил? Мы вот ее не включаем и все работает. и "в кубе" - я не знаю, конечно, что это за звери, хотя догадываюсь. У нас голый LWIP.
  2. проблема совместимости DMA c кешем довольно простая - ДМА пишет в память, а процессор(ядро) может читать данные из кеша, и наоборот когда процессор пишет в память - данные могут задержаться в КЕШ и ДМА прочитает из памяти НЕ-актуальные данные. Самый простой и по моему лучший способ сделать ДМА-память НЕ-КЕШируемой. Если постоянно синхронизировать КЕШ с памятью - теряется смысл использования ДМА - убивается вся выигранная производительность! На любом процессоре максимальная производительность достигается написанием аппаратно зависимых функций на ассемблере, например я писал на IA32 такие спец-функции с использованием MMX, SSE регистров/инструкций, на AVR-ах тоже когда то измудрялся с хитрыми последовательностями инструкций на ассемблере. Вот вы там фильтры какие то упомянули - вот их, скорее всего и надо переписать на ассемблере, причем с привязкой к конфигурации всех ваших ДМА-АЦП-таймеров. Там, У ВАС, должна быть какая то достаточно наглядная идея о том что сколько времени занимает и как события накладываются-синхронизируются, идея на полторы странички - не более! Бездумный перебор настроек памяти/компилятора/... вряд ли может быть эффективным, для достижения границ производительности платформы по определенной вычислительной задаче. Эти границы (время исполнения конкретных операций) должны быть посчитаны с точностью до разброса по тикам для самой длинной цепочки ассемблерных инструкций.
  3. ruhi

    rcall

    а чего там непонятного то - сэкономили разработчики компилятора - вместо 4-х инструкций вставили две.
  4. А зачем тогда индикатор на панели??? Пусть при обслуживании обслуживатель подключает ноутбук (например) к разъему и читает сохраненные параметры работы насосов - получается регистратор с возможностью считывания нужен? Индикатор конечно не помешает, но в случае регистратора будет достаточно пары светодиодов (можно цветных) что бы контролировать штатную работу регистратора. А по схемотехнике вы не задали не одного вопроса, что бы ее обсуждать (разъемы, сигналы, уровни, цепи входные, ...) - я вижу только общий вопрос по общей конфигурации устройства. а может даже регистратор не нужен, нужен интерфейс чтобы считывать текущее состояние исполнительных устройств (клапанов) оператором при диагностике на обслуживании?
  5. Целую панель приборов сделали - забыли только какую то фигню - контроль насоса. Дальше, когда контроль насоса появится, обычно выясняется (с помощью этого контроля и может еще какого то контроля, и еще, и еще ...) что вообще все надо переделать. Лучше сразу начните все переделывать, мой вам совет.
  6. ну да, как то я коряво сформулировал, но вы все ответили! Вот такую работу с осцилографом я очень люблю и уважаю!
  7. Может не заканчиваться, а начинаться смена битности должна не раньше чем? Так этот период зависит от частоты СПИ-ая? Какая все таки частота СПИ-ая: что /256? 8МГц? тогда один такт СПИ значит = 8000/256 => 32 мксек - и получается 0,25мкс больше чем в десять раз меньше чем длительность бита на СПИ-ай?
  8. значит он - я точные названия уже не помню. Так это эквивалентно тому что ты маленькую задержку добавил! Задержка же решает проблему! Попробуй вернуть медленную скорость и поставить 5 или 10 NOP инструкций после ожидания бизи! Это может быть фича такая СТМ-мовского СПИ-ая что у него бизи срабатывает чуть раньше чем надо!? ты там читаешь регистр управления в прерывании, вот я бы так не стал делать, сделай флаг в памяти.
  9. почему не принятый - не переданный? он же у вас мастер? Или ты имеешь ввиду попробовать прочитать его? все надо пробовать - все что в голову приходит, в таких ситуациях. Все таки, если правильно что 1мс задержки решает проблему лишнего байта, значит что задержка до переключения битности решает проблему! АГА - вот! попробуй после бизи флага подождать еще флаг завершения передачи (есть такой? не опустошения буфера для записи следующего сампла, а именно что все выплюнули в шину!) Точно! если ты его дизейблишь а он еще не закончил посылать последний байт и до завершения посылки не дизейблится - тут ты и попадаешь в undefined behavior. Там может еще бит-флаг есть о том что СПИ-ай задизейблился, тогда его надо ждать после дизейбла! вряд ли - тогда наверно не получится сконфигурировать, если только выключить-включить сразу попробовать. вот такой флаг еще посмотри: Там может еще бит-флаг есть о том что СПИ-ай задизейблился, тогда его надо ждать после дизейбла!
  10. вот исходя из этого, например, как и по другим данным, у меня только одна гипотеза (кажется мне правдоподобной): переключение с 8бит на 16 - приводит к тому что СПИ-ай воспринимает это расширение как то что у него появился один НЕ переданный байт который он и отправляет, поэтому, я бы предложил, в качестве эксперимента, этот СПИ-ай выключить как то более кардинально, что бы не было сомнений что его настройки ни как не связаны с его предыдущими настройками. потому что если вы его просто задизейблили он все равно может запомнить что у него появился непереданный байт. который он сначала выплюнет при разрешении передачи!
  11. вот это вот что такое? и где дизэйбл???
  12. вообще то отключать надо после каждого из этих while -ов , конфигурировать и включать.
  13. я насколько помню-знаю отключение (это же просто запрет?) прерываний НЕ отключает СПИ! И, соответственно, я не вижу что у тебя СПИ воЩе отключается! то есть получается ты ему битность меняешь наживую - это вполне может приводить к генерации лишней посылки на шину!
  14. так это... ты говоришь модуль спи отключается при изменении битности - может он у тебя отключается ДО того как байт выплюнулся хотя это странно конечно - в общем надо проверить наложение момента отключения юнита на текущюю передачу, и вот так : SPI1_STM32F1_write_8bit_irq( data_8bit, 3); SPI1_STM32F1_write_8bit_irq( data_8bit, 3); SPI1_STM32F1_write_8bit_irq( data_8bit, 3); если передавать, что будет?
  15. что то я сомневаюсь что существует хоть одна статья про использовании прерываний СПИАя когда переключается режим из 16-битного в 8-ми битный. Если вы хотите изучать работу с прерываниями - уберите переключение режимов, если хотите изучать переключения режимов - уберите прерывания, когда по отдельности разберетесь, может у вас получится сотворить какое нибудь чудо, а пока рано о чудесах грезить .
×
×
  • Create New...