Connor 0 24 апреля, 2018 Опубликовано 24 апреля, 2018 · Жалоба Всем спасибо за ответы, очень помогли :) К слову работаю я на довольно низкой частоте 500 кбод/c, но я так понимаю скорость обмена зависит от тактовой частоты мастера, а не слейва? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlanDrakes 1 24 апреля, 2018 Опубликовано 24 апреля, 2018 · Жалоба Частота обмена ВСЕГДА зависит от частоты мастера. Ведомый кристалл только выставляет соответствующий уровень на пине MISO в момент(ы) смены тактового сигнала SCK. Необходимое условие - частота обмена не более четверти тактовой частоты ведомого чипа. Заметьте, тактовой частоты его периферии. Приведу пример: Мастер: 8МГц. Ведомый: 8МГц. SPI мастера тактируется от внутренней частоты с делителем /2. Результатирующая - 4МГц (внутренняя) и 2МГц (максимальная частота на пине SCK (здесь я имею в виду полную смену тактового сигнала 0-1-0)). SPI ведомого тактируется от внутренней шины с делителем /4. Результатирующая - 2МГц (вроди бы, совпадает с внешней), но максимальная внешняя - 1МГц (тот же полный импульс 0-1-0). Так что, мастер должен дёргать пином минимум в 2 раза медленнее. 500кБод - вполне достаточно 1МГц на шине. На шине ведомого. Ну и мастер должен с этой частотой данные читать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 24 апреля, 2018 Опубликовано 24 апреля, 2018 · Жалоба Я это осознал, другой вопрос заключается в том, что на мастере необходимо организовывать задержку перед отправкой "мусора", например, чтобы принять данные от слэйва(в котором включается дма в прерывании)? Используйте стандартные методы. Если слейв должен возвратить "быстрые" данные (например выборка параметра из RAM) то для этого таймауты не нужны и все можно "прокрутить" в одном запрос-ответе. Если же нужна задержка на подготовку данных (например отработка ADC) то это делается "наразвес", несколькими командами 1. Старт АЦП в слейве. 2. опрос регистра статуса слейва готовности данных АЦП. 3. Чтение слейва - данных АЦП. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Connor 0 25 апреля, 2018 Опубликовано 25 апреля, 2018 (изменено) · Жалоба Частота обмена ВСЕГДА зависит от частоты мастера. Ведомый кристалл только выставляет соответствующий уровень на пине MISO в момент(ы) смены тактового сигнала SCK. Необходимое условие - частота обмена не более четверти тактовой частоты ведомого чипа. Заметьте, тактовой частоты его периферии. Приведу пример: Мастер: 8МГц. Ведомый: 8МГц. SPI мастера тактируется от внутренней частоты с делителем /2. Результатирующая - 4МГц (внутренняя) и 2МГц (максимальная частота на пине SCK (здесь я имею в виду полную смену тактового сигнала 0-1-0)). SPI ведомого тактируется от внутренней шины с делителем /4. Результатирующая - 2МГц (вроди бы, совпадает с внешней), но максимальная внешняя - 1МГц (тот же полный импульс 0-1-0). Так что, мастер должен дёргать пином минимум в 2 раза медленнее. 500кБод - вполне достаточно 1МГц на шине. На шине ведомого. Ну и мастер должен с этой частотой данные читать. Спасибо, это действительно логично Используйте стандартные методы. Если слейв должен возвратить "быстрые" данные (например выборка параметра из RAM) то для этого таймауты не нужны и все можно "прокрутить" в одном запрос-ответе. Если же нужна задержка на подготовку данных (например отработка ADC) то это делается "наразвес", несколькими командами 1. Старт АЦП в слейве. 2. опрос регистра статуса слейва готовности данных АЦП. 3. Чтение слейва - данных АЦП. В том и проблема, что именно в такой системе как реализовано у меня, АЦП конвертируют данные, DMA записывает их в буфер, который копируется ещё в один (на отправку мастеру), по приходу флага копирование данных в этот буфер прекращается и я отправляю этот буфер мастеру, но как я уже говорил, флаг у меня приходит, срабатывает прерывания, на слэйве запускается DMA по Rx запросу, но чтобы мастер начал читать адекватные данные, когда я начинаю слать слэйву "мусор", нужно выждать что-то около 500мс, что очень плохо, потому что обновлять данные я должен несколько раз в секунду, поэтому решением этой ситуации, как мне подсказали выше, это реализовать просто обмен по DMA без всяких флагов, что я уже сделал и что гораздо проще в итоге Изменено 25 апреля, 2018 пользователем Connor Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rudy_b 1 25 апреля, 2018 Опубликовано 25 апреля, 2018 · Жалоба Я сделал так. Одну ногу мастера использую как CS. На слейве - передний фронт сигнала CS вызывает прерывание - предупреждение о том, что через 1 мсек (под мои задачи) мастер запустит обмен. За это время слейв готовит данные в буфере передачи и запускает свои DMA на прием и передачу, после чего занимается своими делами. По завершении DMA передачи от мастера он получает прерывание (TC DMA) и считывает полученные от мастера данные. Мастер получает прерывание от таймера (период обмена), ставит CS, готовит данные передачи и занимается своими делами. Через 1 мс после установки CS (опять же по прерыванию таймера) мастер запускает прием/передачу по DMA и занимается своими делами. По ее завершении получает прерывание (TC DMA), считывает данные слейва и снимает CS. Т.е. вся работа идет по прерываниям и DMA. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 26 апреля, 2018 Опубликовано 26 апреля, 2018 · Жалоба . . . .начинаю слать слэйву "мусор", нужно выждать что-то около 500мс, что очень плохо, . . . Если сделаете аппаратную синхронизацию по времени цикла 1с по всей системе (например от мастера), то проблемы с таймаутами и готовностью-неготовностью можете "разрулить" с использованием таймеров. (не будет необходимости ожидания или контроля отработки для асинхронных событий между мастером и слейвом). Например, мастер на такте 0 таймера дает команду слейву на старт АЦП. Время работі АЦП, скажем, 500 мс. Соответственно, мастер дает команду опроса слейву на 520-ом такте, а слейв заботится о том, чтобы эти данные и все подготовительные операции к 520-му такту у него были закончены. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVI-crak 0 26 апреля, 2018 Опубликовано 26 апреля, 2018 · Жалоба Если сделаете аппаратную синхронизацию по времени цикла 1с по всей системе (например от мастера), то проблемы с таймаутами и готовностью-неготовностью можете "разрулить" с использованием таймеров. Плавали, знаем... Всё это будет работать до очередной хотелки клиента. После чего придётся переписывать почти весь проект, причём на оба чипа, и почти с нуля. Мне лень убеждать, но посмотреть со стороны всегда приятно. И всё-же: разделяйте уровень железа и программной части, уровень интерфейса и протокола пакетной связи, а также разумно используйте абстракции данных на уровне приложения (алгоритма). При использовании подобного разделения - ваш проект можно масштабировать практически бесконечно (в разумных пределах), а так-же использовать части и даже целые куски в новых проектах - без подгонки напильником. Реальный пример существующего проекта. На ПП несколько чипов, в том числе и слабенький st для работы с сенсорным экраном (не я придумывал). Изначально алгоритм этого чипа был очень простым: получить координаты нажатия экрана, и в режиме слейва отдать главному чипу. Потом ему добавили работы в определении нажатия иконок - протокол связи стал намного сложнее и обрёл множество садового инструментария. Количество изменений в проекте между этими двумя точками - просто безумное. Переписывалось даже то, что имеет лишь косвенное влияние. А потом хозяин проекта узнал что существуют готовые железные контролёры сенсорных экранов, в которых эти функции реализованы изначально. Такого количества подстановок я не встречал даже у индусов. Количество изменений равнялось общему объёму проекта. Поле чего автор проекта решил пристрелить больное бешенством животное, и начать с нового листа. И с первых строчек прострелил себе ногу в трёх местах. Я к тому что уровень адруино не лечится, если уже заразились - то постарайтесь не распространять заразу. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 27 апреля, 2018 Опубликовано 27 апреля, 2018 · Жалоба Плавали, знаем... Все понятно, кроме одного, зачем процитирован мой пост. Если процитирован, то замечания по сути. ps Используя метод психоанализа я, кажется, понял в чем причина :) В терминах и их применении. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AVI-crak 0 27 апреля, 2018 Опубликовано 27 апреля, 2018 · Жалоба Если процитирован, то замечания по сути. Всё очень просто. Использование предсказания поведения внешней системы с использованием таймера - намного уменьшает гибкость общего алгоритма. То-есть если-бы внешней системой было железо, механика или нечто подобное - то реализация предсказаний оправдывается. Но в связке двух процессоров - это наличие недостатка в алгоритме. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Alechek 0 7 мая, 2018 Опубликовано 7 мая, 2018 · Жалоба Но в связке двух процессоров - это наличие недостатка в алгоритме. Делаю связку из нескольких процессоров с ипользованием half-duplex SPI (1 линия приема-передачи) Вот тут без жесткого тайминга никак.... Вовремя надо направление переключить - мастер-приемник-то шпарит постоянно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
