Тады, ой! Я не обратил на этот факт внимание. Хотя все равно это чисто теоретический кусок кода, не имеющий практического применения. В реальности нужны еще кое-какие проверки, хотя бы на окончание буфера, выделенного для приемоперадачи или на количество байт заданных для чтения/записи.

Да врут они все тут. Всё будет работать в тех рамках, которые подразумеваются. Ну там мастер и прочее. Хорошая вобщем скорость. А все эти "нытики" видимо никогда не делали сверхскоростные проги. Пардон. Ничего личного. Хотя...

Да, ничего не делает, она сильно занята(:-)!
Отсюда вытекает интереснейший вопрос. Щас я его попробую сформулировать, может его надо бы в отдельную ветку вынести, чтобы не перегружать, ну да ладно.

Есть некая микроконтроллерная система, состоящая из нескольких МК, обменивающихся между собой, скажем по SPI. Как лучше сделать обмен, с точки зрения экономии производительности МК, по прерываниям или максимально быстрый программно-аппаратный обмен, как описано мною выше?

Поясню на примере, что имею ввиду. Хотим передать 128 байт. При программно-аппаратном обмене мы потеряем 16*128=2048 МЦ. При обмене по прерываниям мы должны учесть вызов прерывания, сохранение/восстановление временного регистра и статуса, возврат из прерывания, плюс такое же тело подпрограммы, если ничего не забыл, то получается не менее 22 МЦ (это если регистры указателей закреплены за данным прерыванием!). Все это надо делать для каждого байта, так что, в сумме будет 22*128=2816 МЦ на каждый обмен. Еще надо учесть, что прерывания должны следовать каждые 22 МЦ, значит максимальная скорость передачи будет ниже. чем при программно-аппаратном обмене! Да еще не забыть, что есть запасные 8 МЦ в каждом цикле, стоит ими грамотно распорядиться(:-). Конечно, экономия копеешная, но иногда ее так не хватает!

Вот такой философский вопрос по использованию и НЕ использованию прерываний где попало. Думайте сами, решайте сами, прерывать или не прерывать.

И еще, маленькая просьба, пжлст, не пишите РС, если нет подписи, это моветон, не обижайтесь. Okey-dokey?

Принято.

Что касается проверок. Код приведен практически реальный. Можно было бы, конечно, поставить декремент счетчика байт (но считать можно было бы только до 256, а если мне надо передать 300?) и переход по условию, но тогда было бы 9 МЦ, а у меня 8! Кто может написать быстрее(:-)? Ну ладно, это у меня отпускные настроения разыгрались(:-).

А по делу так. Устанавливаете таймер на прерывание точно после последнего переданного байта, вот вам и будет выход из цикла, останется только подчистить верхушку стека...Зато 8 МЦ! Кому они нужны, право? Ну скажем, можно сделать хороший джейтаг для отладки, на АВР с тактовой 20 МГц скорость может достигать 10 мбит/с.

Так потянет? 6 тактов в запасе.

А в Оксфорде учитесь?

Сообщение отредактировал GetSmart - Jul 14 2006, 13:58

=GM=, есть несколько нюансов в описываемой вами схеме.

В чем смысл гонять данные с максимальной скоростью? А обрабатывать их до/во время/после обмена не нужно? Что приоритетней, задача выполняемая МК или обмен данными? А оба МК будут успевать подавать данные на конвейер синхронного интерфейса? Или достоверность данных вас особо не волнует?
Отсюда наверное и будет решение по прерыванию или в цикле организовывать обмен по SPI. Я бы не стал столь рискованно (на пределе возможного) организовывать обмен даже двух МК. Вот если МК и DataFlash с аппаратным конвейером SPI, то это пожалуйста. предложенный вами кусок кода вполне можно имплантировать в программу.

Конечно, нюансы есть везде. Чёрт, как известно, сидит в деталях(:-).
А в чем смысл их гонять с минимальной скоростью(:-)? Выше я показал на примере, что при максимальной скорости есть некая экономия производительности МК.

Ну, типовой АВР не потянет обработать на такой скорости, увы. Вопрос в другом, что лучше ИЛИ быстро принять пакет, затрачивая минимум производительности, ведь последовательная передача - это непроизводственные затраты, и затем обработать принятый пакет? Во многих протоколах нельзя обработать пакет, не приняв его целиком. ИЛИ же обрабатывать пакет побайтно, теряя на производительности, и принимая решение на ходу?


Ну вы же видите, что программа успевает и принять байт и передать его. А следующая передача может случиться через секунду. Ну вот скажем, вы делаете систему тестирования, вы принимаете байты из LPT ПК и хотите передать в JTAG, для проверки некой микросхемы или платы, используя пограничное сканирование. Что вы предпочтете, медленно заталкивать биты в последовательные регистры нескольких микросхем или быстро? Ответ очевиден, быстро (насколько позволяет система) затолкнуть скажем 600 бит, подождать процесса установления, затем протестировать...


Спасибо. Пользуйтесь, мне не жалко. Ну я тоже не сторонник работать на пределе. Жизнь иногда заставляет. Проект был - асик с доморощенным интерфейсом 5 Мбит/с с точностью до 10 нс, передается команда, затем переключение на прием, принимается 32 бита данных, что делать? А я еще клювом прощелкал, мог бы поработать с людьми, изменить интерфейс, асик был заказной, под нас делали..Пришлось извиваться. Сейчас из 150 мкс обмен занимает 35 мкс! Да я ДПФ делаю за 70 мкс!



Нормально, Григорий(:-). Хотя у вас 10 МЦ, а в исходной проге было 8 МЦ.

Не, работаю. Занесло вот в ЮКей. Не каждый московский голубь долетит до середины Ламанша(:-).

Сообщение отредактировал =GM= - Jul 14 2006, 14:49

Я всего-то заменил два NOPа на SUBI+SBCI. Может вы сами просчитались? В вашей проге было 16 МЦ и в моей 16.

Отлично, Константин.

Немного не так. Цикл исполняется за 16 МЦ, эт-да, нельзя ни убавить, ни прибавить. Но сама прога, вместе с командой перехода занимает 8 МЦ, следовательно, я могу что-то сделать полезное в оставшиеся 8 МЦ. Скажем, передаю 16 байт и одновременно осуществляю распределенное деление 16/16 (как часть другой задачи). Ну или умножение 16*16, не важно. Важно, что время даром не пропадает. Еще можно чего-нить по медленному программному RS-232C передавать, да мало ли что. А когда Атмел поставит второй SPI, то можно было бы и его задействовать на такой же скорости, в то же самое время!


Очень приятно, Костя, меня зовут Джордж, GM это мои инициалы.

1. А кто тогда Георгий?

2. А когда у вас в цикле стоит бесконечный цикл, это по-вашему в порядке вещей. И ещё ремарка, что можно даром время не терять, но считать кол-во переданных байт мы не будем из принципа.

ЗЫ. Эффект от "извращений" пропорционален скорости проца, ну и его стоимости. Для АВРа как-то мелко получается.


Ну так определитесь что будете делать уже. А то я могу ещё 2 МЦ в копилку добавить. А если очень захотите, то и передавать на 8 других процессоров одновременно.

Какой Георгий? А-а, Григорий! Это из юморески ММЖ, вы там просто смайлик не заметили!
А вообще у меня Джордж-джуниор, т.е. Георгий, подрастает.

Ну уже ответил, см. пост №19, отвечу здесь. Устанавливаете таймер на прерывание точно после последнего переданного байта, вот вам и будет выход из цикла, останется только подчистить верхушку стека...Вот вам и 8 МЦ, вместо 9 или ваших 10!

Это я не понимаю, это не ко мне.

Вот интересно, покажите, как это сделать. На 8 процессоров тоже интересно (теоретически). Но думаю вы шутите, это какое-то чудо передать на 8 процов одновременно на скорости 10 мбит/с. Надеюсь, передается индивидуальная для каждого проца информация?

Ну разумээтся. Не чудо. Только в одну сторону. Ну и со скоростью 6.666 мбит. Так ведь можно? (делитель 1/3) Ну или 1/4.
Подумайте денёк. Может догадаетесь.


Хммм...

Хотя постойте. Принимать-таки можно. Можно с одного. А можно с одного из восьми. Ну или со скольки угодно.

Пардон. 6.666 МБАЙТ.

Прошу пардону. Дайте постановку задачи. Что за делитель, что за 6,(6)Мбайт...

Делитель тока 1/4. Это обычный делитель синхросигнала SPI.
Поэтому скорость 5 МБАЙТ/сек.

Не. Лучше пусть будет 5.5 МБАЙТ.
И на 9 других процессоров.

2 ksv198

Чего-то я не допираю, счего вдруг сначала писать, а потом читать. Тем не менее мой вариант:
итого:
Замечу, что проверка флага - вышло неудачно. 6 nop у GetSmart эффективнее
2 =GM=

Зато у GetSmart с проверкой количества байт.
P.S. Приведенный код может содержать ошибки, укажите пожалуйста если таковые будут обнаружены.
P.P.S. Мне вообще кажется, что довольно трудно оптимизировать программу на RISC, кроме случаев когда она писалась бездумно .