dead_cell 0 5 февраля, 2010 Опубликовано 5 февраля, 2010 · Жалоба здрасьте народ. недавно начал изучать freertos. кое как слабал usb устройство из примеров :). дошел в данный момент до описания обмена данными по SPI. по SPI данные и читаются и записываются, микросхем куча и все разные. по сути: начинаю обмозговывать как бы описать обмен по SPI в виде отдельной задачи (или двух одна на чтение другая на запись). вроде если переписать пример serial и comtest, то должно работать, только еще добавить обращение непосредственно к отдельной взятой микросхеме. у кого какие мысли? может у кого то есть уже реализованные варианты? :) ЕСЛИ ТЕМА БРЕД -> ГРОХНИТЕ ЕЕ :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 5 февраля, 2010 Опубликовано 5 февраля, 2010 · Жалоба Зачем в одну задачу увязывать работу с кучей разных микросхем? Делите сам SPI между разными задачами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dead_cell 0 5 февраля, 2010 Опубликовано 5 февраля, 2010 · Жалоба рассматриваю также и такой вариант. все относительно в этом мире :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Terminator 0 6 февраля, 2010 Опубликовано 6 февраля, 2010 · Жалоба Отдельная задача для SPI скорее всего будет бесполезной тратой ресурсов. Прислушайтесь к aaarrr Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Aurochs 0 6 февраля, 2010 Опубликовано 6 февраля, 2010 · Жалоба Могу предложить Вам критерий, которым пользуюсь сам. Если на уровне общей логики системы все подключенные к SPI микросхемы будут подчиняться неким общим правилам (например, составная долговременная память с общей системой адресации или что-нибудь подобное) - то тогда есть смысл оформлять как одну задачу. Если же это будут по сути совершенно разнородные устройства и общим у них будет только аппаратный интерфейс обмена, то слияние этого в одну задачу только добавит головной боли. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Axel 1 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба SPI - аппаратный ресурс, который "шарится" между различными задачами, поэтому отдельная SPI-задача может иметь смысл (ИМХО). Правда нормально это будет работать, если при этом не требуется перенастройки (скорость, полярность клока и т.д.). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба SPI - аппаратный ресурс, который "шарится" между различными задачами, поэтому отдельная SPI-задача может иметь смысл (ИМХО). Странный вывод. SPI-задача может иметь смысл, например, если не хочется блокировать вызывающую задачу при отсутствии DMA (не частый случай, прямо скажем). А вот зачем создавать ее на пустом месте, когда можно и так замечательно расшарить ресурс mutex'ами - не понимаю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба когда можно и так замечательно расшарить ресурс mutex'ами - не понимаю. Когда ресурс занимается минимальным действием по "байт переслать" в симплексе, то можно и mutex. Если за работой с SPI стоит протокол, то отдельная задача занимающаяся обслуживанием SPI совершенно естественна. Кроме прикрытия SPI mutex-ами, во многих случаях естественнее смотрится очередь сообщений/указателей на сообщения. И критические секции имеют право на жизнь тоже. Варианты..... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Когда ресурс занимается минимальным действием по "байт переслать" в симплексе, то можно и mutex. Для SPI это, пожалуй, и составляет большинство применений. Если за работой с SPI стоит протокол, то отдельная задача занимающаяся обслуживанием SPI совершенно естественна. Протокол обычно стоит за чем-то, висящим на SPI. Тогда работу с этим "чем-то" логично вынести в отдельную задачу, оставив сам SPI на более низком уровне. Кроме прикрытия SPI mutex-ами, во многих случаях естественнее смотрится очередь сообщений/указателей на сообщения. И критические секции имеют право на жизнь тоже. Варианты..... Очередь поможет в тех нечастых случаях, что упоминались мной в предыдущем посте. Во многих других - просто усложнит программу, без какой либо выгоды. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Для SPI это, пожалуй, и составляет большинство применений. Или нет. У меня за SPI "микросхемы" редко, все больше FPGA, да другие контроллеры. Протокол обычно стоит за чем-то, висящим на SPI. Тогда работу с этим "чем-то" логично вынести в отдельную задачу, оставив сам SPI на более низком уровне. Поскольку это единственная задача, то и всякие дробления и мютексы ей никчему. Очередь поможет в тех нечастых случаях, что упоминались мной в предыдущем посте. Во многих других - просто усложнит программу, без какой либо выгоды. Очередь по сложности нефатально отличается от мютекса, а в конкретно поминаемом случае FreeRTOS вообще не отличается. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Или нет. У меня за SPI "микросхемы" редко, все больше FPGA, да другие контроллеры. Поскольку это единственная задача, то и всякие дробления и мютексы ей никчему. Хочу только заметить, что у топикстартера "микросхем куча и все разные". Очередь по сложности нефатально отличается от мютекса, а в конкретно поминаемом случае FreeRTOS вообще не отличается. Разница в том, что очередь должен кто-то обслуживать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Хочу только заметить, что у топикстартера "микросхем куча и все разные". Для кидания "байта" в непойми чего ни система, ни мютексы не нужны - кидающий просто смотрит на SPI - свободен или нет. И ждет освобождения. Разница в том, что очередь должен кто-то обслуживать. Вызывающая передачу задача и обработчик события завершения передачи. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Для кидания "байта" в непойми чего ни система, ни мютексы не нужны - кидающий просто смотрит на SPI - свободен или нет. И ждет освобождения. Только не надо доводить до абсурда. Откуда такие крайности? Или у вас на SPI единственная FPGA с разлапистым протоколом, или "непойми чего". Другие варианты не рассматриваете? В общем случае работа с SPI сводится к передаче и приему N байт с предварительной установкой и последующим снятием CS, мьютекс тут как раз на месте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Или у вас на SPI единственная FPGA с разлапистым протоколом, или "непойми чего". Другие варианты не рассматриваете? Рассматриваю - кучка контроллеров с похожими, или одинаковыми протоколами. В общем случае работа с SPI сводится к передаче и приему N байт с предварительной установкой и последующим снятием CS, мьютекс тут как раз на месте. Для такого вырожденного случая софтовый мютекс совсем не нужен - уже писал - работают флаги в железе. Никакого абсурда. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 7 февраля, 2010 Опубликовано 7 февраля, 2010 · Жалоба Рассматриваю - кучка контроллеров с похожими, или одинаковыми протоколами. Хорошо, давайте рассмотрим случай, когда на шине одновременно присутствуют устройство с протоколом (например, SD/MMC карта в SPI-режиме) и без (например, 25-я еепромка для хранения каких-нибудь мелочей). Что будем делать? Для такого вырожденного случая софтовый мютекс совсем не нужен - уже писал - работают флаги в железе. Да имейте же меру в упрощениях и вырождениях! Это верно, только если слейв один и достучатся до него пытается только одна задача. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться