1

Тема: Who is CANNY?..

Подскажите пожалуйста (что-то не нашел у вас описания), какой контр-р кан используется - сжа?..
И ещё - какие временнЫе ограничения по работам прошивок? Имею в виду, будут ли они держать заявленные кановские скорости при использовании вашего по верхнего уровня?
Вообще, испытания проводились?..

2

Re: Who is CANNY?..

О каком контроллере речь - CANNY 5, CANNY 5 nano или CANNY 7?
Специализированных контроллеров CAN мы не используем, используются микроконтроллеры общего назначения со встроенным CAN-ядром - Microchip PIC18, PIC24.
Что значит "держать" заявленную скорость CAN? Если принимать весь трафик на предельной скорости при максимальной его плотности и без потерь, то нет - не "держат". Для того чтобы избежать переполнения реализован механизм управляемых пользователем динамических аппаратных фильтров CAN, используя которые можно ограничить принимаемый контроллером трафик до приемлемого уровня.
Вообще, испытания проводились, про какие испытания речь? Для того чтобы определить, справляется ли контроллер с трафиком в конкретных условиях на конкретной диаграмме, пользователю доступны диагностические регистры переполнения CAN, ошибки CAN, продолжительности программного цикла диаграммы и т.п., используя которые, пользователь может поставить эксперимент самостоятельно.

3

Re: Who is CANNY?..

Испытания в таком смысле - как известно, любое ПО верхнего уровня (в коем у вас производится программирование) тянет за собой кучу накладных. А испытания производятся по разработанной методике самим производителем. Примерно так:
1. Создаются N программных переходов (циклов, условий и проч.), по выходу из которых посылается M сообщений с разными идентификаторами.
2. Заливается все это дело в девайс.
3. Контролируется, ну, допустим, общее количество прошедших сообщений за время, скажем, 1 сек. Вычисляется "прикладная" скорость.
4. Пункты 1 - 3 повторяются достаточное количество раз с различными значениями N и M, чтобы на выходе постороить соответствующие диаграммы и обозначить временнЫе ограничения..
Довольно странно, что такие тривиальные вещи приходится объяснять..

По поводу "предельного трафика" - тут как раз все понятно, - все зависит от приоритетности пользовательских сообщений (на то и шинный рабитраж, в конце концов). Да и разработчики протокола советуют не напрягать шину больше чем 70% (правда, у них тоже, по-ходу эта цифра с потолка взялась..)

4

Re: Who is CANNY?..

Да, и про аппаратные фильтры тоже все понятно, но я не о том - думаю, Вы уже поняли, о чем я ..

5

Re: Who is CANNY?..

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

Вы уже поняли, о чем я ..

С вашего позволения, я всё же уточню:

посылается M сообщений

Заливается все это дело в девайс.

Правильно ли я понял, что цель испытаний, методику которых вы изложили - определение производительности контроллера по отправке CAN-сообщений при различном составе и размере пользовательской диаграммы записанной в контроллер?

6

Re: Who is CANNY?..

Ну, если с самого начала - кан сообщение (это то, которое с данными и по-максимуму, - 8 байт) занимает около 130 бит на шине. Квант времени зависит от частоты (ну, или скорости) шины. Контроллер sja1000, например, при полной загрузке и минимальной прошивке на низком уровне мегабитную шину может напрячь только на 90% без выхода за стандартное время (определяемое из бошевской спецификации). Далее, - ПО проца, который работает в связке с этим контроллером, вносит дополнительные потери, далее, если ещё есть по (а зачастую это вообще ОС, хоть и "реального времени", как заявляется) ещё вносят и т.д.
То есть, законченный продукт в итоге НЕ СПОСОБЕН ВЫДАВАТЬ то, что от него ждут по кан-стандарту (другое дело, что и не должен, однако, далеко это не все понимают).
У вас законченным продуктом является некий запрограммированный вашей же средой инж. прогр-ния прибор. Вот и вопрос - какие у него ограничения в этом плане?
Для авто- шины кан характерны высокие скорости. И ожидаемое время отклика соответственно, должно быть как можно меньше (не более 1 мс), иначе, во многих случаях (а вы же позиционируете свои аппараты как универсальные и легко программируемые даже для новичка (считай "чайника" - может такого наваять!) - могут быть непредсказуемые последствия ..

7

Re: Who is CANNY?..

Константин, CANNY пишет:

Правильно ли я понял, что цель испытаний, методику которых вы изложили - определение производительности контроллера по отправке CAN-сообщений при различном составе и размере пользовательской диаграммы записанной в контроллер?

Если огрубленно, - то да, можно и так упростить (без потери общности, так сказать)...

8

Re: Who is CANNY?..

Спасибо за пояснения - теперь намного понятнее.

Ваши познания в CAN впечатляют, говорю совершенно без иронии!

Про возможности контроллера:

Примем ПО контроллера состоящим двух частей: системное ПО (СПО) и пользовательская диаграмма (ПД). Контроллер работает в бесконечном цикле, исполняя на каждом проходе по одному разу СПО и ПД. Предсказать продолжительность такого цикла невозможно, но его можно измерить, и получить измеренное значение из соответствующего регистра.
Почему невозможно предсказать:
Время работы СПО зависит от числа задействованных драйверов периферии (UART CAN Dallas I2C ВЧШИМ...) контроллера и нагрузки на них, от числа и характера обращений ПД к периферии и системным ресурсам контроллера и т.п. Время работы пользовательской диаграммы так же недетерминировано: один тот-же функциональный блок может исполнятся за разное время в зависимости от текущего контекста диаграммы. Колебания продолжительности цикла могут составить от единиц до десятков процентов.

Теперь немного упростим: возьмем CANNY 7, пусть наша диаграмма для него не занимается ничем другим кроме арифметики и передачи в CAN, никакая другая периферия не задействована. Пусть фильтры CAN настроены таким образом, что через них на прием не проходит никаких сообщений, то есть нагрузки нет даже на принимающую часть драйвера CAN.

Что получится в цифрах:
Текущая (но не единственно возможная) реализация драйвера CAN CANNY7 позволяет отправить максимум одно CAN-сообщение за один цикл диаграммы. Продолжительность цикла, в зависимости от объема арифметики в нашей диаграмме, составит от 1-2 мс при минимуме блоков, до ~30 мс при 4-5 сотнях блоков в диаграмме. Соответственно, если "затыков" по вине других узлов сети на шине не возникнет, то CANNY 7 сможет передать от ~30 до до ~1000 сообщений в секунду.

Что касается трафика CAN в автомобиле, то его генерирует как правило (если не в вообще всегда) несколько узлов сети, а не один и при необходимости генерации массированного трафика, можно использовать несколько контроллеров CANNY. То же и с приемом. Как правило, ни один узел в автомобиле, кроме узлов-маршрутизаторов и, возможно ЭБУ в в системах с высокой степенью централизации, не принимает весь трафик, все фильтруют. И для "переваривания" массированного трафика CANNY так же можно включать параллельно.

Жесткие ограничения на время отклика в CAN могут оказаться технически несостоятельны: во первых, шина может быть забита более высокоприоритетными сообщениями и отправитель будет долго и непрерывно проигрывать арбитраж, во вторых, CAN не гарантирует прием сообщения всеми адресатами, сообщение будет считаться успешно отправленными, если его примет хотя бы один узел, и если в сети есть маршрутизатор (gateway) то остальные узлы могут запросто "прозевать" посылку адресованную им.
Я использовал слова "жесткие" и "могут оказаться" потому, что теоретически возможно построить CAN-сеть и протокол верхнего уровня таким образом, чтобы минимизировать влияние перечисленных выше факторов.

Да, мы позиционируем свои контроллеры как универсальные и простые в освоении, но у любой универсальности есть рамки, хоть мы и попытались их максимально раздвинуть. Да, наш контроллер, если он в сети один - не лучший выбор для построения на нем ЭБУ ДВС, но есть масса уже решенных и потенциально решаемых единственным контроллером задач. Ну и разумеется, последствия неграмотного применения подобного нашему оборудования могут быть непредсказуемы, согласен с вами полностью.

9

Re: Who is CANNY?..

Спасибо!
Это как раз то, что я хотел уяснить для себя.
Вы правы - я профессионально занимаюсь CAN-шинами СУ транспортных средств (но не авто-, а сложнее) уже достаточно долгое время. А шины авто- у меня как своеобразное хобби - и после этого вашего объяснения я понял, что не удастся мне собрать и с помощью вашего оборудования так мне необходимый управляемый шлюз (это когда в разрыв шины врезаются 2 канала и налаживается перекрестный обмен, с анализом, записью и изменений данных при необходимости "на лету") на основе CANNY также как и не удалось и на основе ARDUINO и всяческих IXAAT и MARATHON, именно из-за верхнеуровневой обработки, а "прикладная" скорость в авто- оказалась слишком высокой .. То есть, собрать-то удалось, однако, в авто- они не работают..
Видимо, ничего не остается как ваять на нижнем уровне (только вот немного непонятно, как можно ещё и "вклиниться" в процесс?)..
Но, прошу прощения, - последний вопрос уже не вам, а так - риторика..
Ладно, что хотел - узнал, ещё раз спасибо, - удачи (вообще, задумка у вас неплохая - со временем полностью ардуино клонируете, - и это правильно)..

10

Re: Who is CANNY?..

Хотя, мысль про несколько шлюзов в одном разрыве с настроенными фильтрами кажется не такой уж фантастичной.. Надо подумать и посчитать на основе выданных вами параметров. Навскидку кажется, что трех шлюзов с параметрами ваших приборов должно хватить, чтобы обеспечить отклик менее 1 мс на 500 кБит - ной шине.. Марафонов не хватит точно - минимальная обработка у них 5 мс/сообщ.
А 3 шлюза = 6 отдельных контроллеров.
Кстати, а нет ли у вас разработки подешевле - только с кан-юзб каналами (без остальных интерфейсов и входов)?..

11

Re: Who is CANNY?..

Вижу вы уже нашли соответствующую тему
http://forum.canny.ru/viewtopic.php?id=128