Миландр

Ключевым подразделением нашей компании
является Центр Проектирования интегральных микросхем
Текущее время: 2020-июл-12 17:56

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 37 сообщений ]  На страницу « 1 2 3 »
Автор Сообщение
СообщениеДобавлено: 2013-мар-29 13:00 
Не в сети

Зарегистрирован: 2009-май-22 09:01
Сообщения: 1302
Откуда: АО "ПКК Миландр"
HEMAH писал(а):
-=Sergei=- писал(а):
1. Зависит о вашей реализации программного SLAVE I2C.
2. Разброс генераторов есть в ТУ. Внутренние генераторы стабилизированы по температуре, но этот параметр не охарактеризован и не контролируется.
3. Сложностей нет. Но только в новых проектах. Но мой взгляд I2C не тот интерфейс который стоит применять в ответственной аппаратуре.

Объедините два процессора по CAN. на порядок быстрее и надежней. Если точка-точка на плате, то можно и без приемопередатчиков обойтись.
Я бы ни за что не применил межкомпонентный по сути I2C в качестве межблочного, тем более, что в своё время наша компания уже имела опыт работы с данным интерфейсом и выводы были сделаны отрицательные, но... это воля заказчика.
Для этих целей лучше всего было бы взять 485ый при одинаковом количестве проводов, можно было бы вообще одну из разновидностей протоколов на базе LVDS, много вариантов.
  1. Меня интересует практическая возможность, т.е "возможно-ли в принципе?", быть может кто-то уже пытался или есть готовые, образцовые решения
  2. Не будет-ли каких-либо подводных камней с которыми, быть может, вы уже знакомы?
  3. И на что лучше обратить внимание при подобных "извращениях"?
  4. Тактирование от внутренних генераторов это "аварийный вариант", на случай если не выдержит внешний генератор.
1. Да возможно, никаких проблем нет. Но не пробовали.
2. Думаю нет, для ускорения обнаружения фронтов можно использовать таймер.
3. Думаю надо будет внимательно смотреть на заваленые фронты и скорее всего появится ограничение в длительности S и P битов, что бы они гарантированно обнаруживались слейвом.
4. Думаю не принципиально. Оверсемлинг с учетом разброса у Вас будет 40/0.4 = 100 тактов или 24/0.4= 60 тактов.
Т.е. если в 60 тактов уложитесь, то всего должно хватать. Ну и опять таки, вы имеете право замедлять слейвом тактовую частоту.


Вернуться к началу
СообщениеДобавлено: 2013-мар-29 20:27 
Не в сети
Аватара пользователя

Зарегистрирован: 2011-окт-19 17:25
Сообщения: 546
Откуда: г. Владимир ОАО "ВКБР"
-=Sergei=- писал(а):
HEMAH писал(а):
-=Sergei=- писал(а):
1. Зависит о вашей реализации программного SLAVE I2C.
2. Разброс генераторов есть в ТУ. Внутренние генераторы стабилизированы по температуре, но этот параметр не охарактеризован и не контролируется.
3. Сложностей нет. Но только в новых проектах. Но мой взгляд I2C не тот интерфейс который стоит применять в ответственной аппаратуре.

Объедините два процессора по CAN. на порядок быстрее и надежней. Если точка-точка на плате, то можно и без приемопередатчиков обойтись.
Я бы ни за что не применил межкомпонентный по сути I2C в качестве межблочного, тем более, что в своё время наша компания уже имела опыт работы с данным интерфейсом и выводы были сделаны отрицательные, но... это воля заказчика.
Для этих целей лучше всего было бы взять 485ый при одинаковом количестве проводов, можно было бы вообще одну из разновидностей протоколов на базе LVDS, много вариантов.
  1. Меня интересует практическая возможность, т.е "возможно-ли в принципе?", быть может кто-то уже пытался или есть готовые, образцовые решения
  2. Не будет-ли каких-либо подводных камней с которыми, быть может, вы уже знакомы?
  3. И на что лучше обратить внимание при подобных "извращениях"?
  4. Тактирование от внутренних генераторов это "аварийный вариант", на случай если не выдержит внешний генератор.
1. Да возможно, никаких проблем нет. Но не пробовали.
2. Думаю нет, для ускорения обнаружения фронтов можно использовать таймер.
3. Думаю надо будет внимательно смотреть на заваленые фронты и скорее всего появится ограничение в длительности S и P битов, что бы они гарантированно обнаруживались слейвом.
4. Думаю не принципиально. Оверсемлинг с учетом разброса у Вас будет 40/0.4 = 100 тактов или 24/0.4= 60 тактов.
Т.е. если в 60 тактов уложитесь, то всего должно хватать. Ну и опять таки, вы имеете право замедлять слейвом тактовую частоту.
Хорошо поставленный ответ по всем пунктам!)

2. Сильно благодарю, он оказался очень ценным, потому как на счёт таймера мы тоже подумали, а вы в свою очередь ещё и подтвердили наши размышления. Тут ещё нам всяких внутренних датчиков накидали с I2C, поэтому аппаратному мастеру кристалла будет чем заняться.
4. Передам программисту, опять же премного благодарствую :)


Вопрос, но не критичный, это так, мысль - А нельзя под слэйв I2C приспособить штатный SPI модуль?

На него тоже конечно всего навешали, но их в кристалле всё же два и если я правильно понял, то аппаратный блок может быть ведущим или ведомым, если в определённый момент выставлять нужный режим. Но быть может ошибаюсь.

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В


Вернуться к началу
СообщениеДобавлено: 2013-мар-30 22:44 
Не в сети

Зарегистрирован: 2009-июл-21 14:13
Сообщения: 1501
Откуда: Тула
HEMAH писал(а):
2. Сильно благодарю, он оказался очень ценным, потому как на счёт таймера мы тоже подумали, а вы в свою очередь ещё и подтвердили наши размышления. Тут ещё нам всяких внутренних датчиков накидали с I2C, поэтому аппаратному мастеру кристалла будет чем заняться.
4. Передам программисту, опять же премного благодарствую :)


Вопрос, но не критичный, это так, мысль - А нельзя под слэйв I2C приспособить штатный SPI модуль?

На него тоже конечно всего навешали, но их в кристалле всё же два и если я правильно понял, то аппаратный блок может быть ведущим или ведомым, если в определённый момент выставлять нужный режим. Но быть может ошибаюсь.
2. чё тут думать? таймер - фактически единственная адекватная возможность получить прерывание извне мк.
4. как-то пришлось реализовывать одновременный приём двух каналов arinc-429 48кбит/с на 1886ве2@4MIPS со всеми положенными проверками на скорость, пропадания сигнала, буферы, передача + основная задача. только интерфейсы генерировали 200000 прерываний в секунду. так что успехов вашему программисту)

spi вам вообще никак не поможет.

_________________
сочувствующий…


Вернуться к началу
СообщениеДобавлено: 2013-мар-30 23:47 
Не в сети
Аватара пользователя

Зарегистрирован: 2011-окт-19 17:25
Сообщения: 546
Откуда: г. Владимир ОАО "ВКБР"
prostoRoman писал(а):
HEMAH писал(а):
2. Сильно благодарю, он оказался очень ценным, потому как на счёт таймера мы тоже подумали, а вы в свою очередь ещё и подтвердили наши размышления. Тут ещё нам всяких внутренних датчиков накидали с I2C, поэтому аппаратному мастеру кристалла будет чем заняться.
4. Передам программисту, опять же премного благодарствую :)


Вопрос, но не критичный, это так, мысль - А нельзя под слэйв I2C приспособить штатный SPI модуль?

На него тоже конечно всего навешали, но их в кристалле всё же два и если я правильно понял, то аппаратный блок может быть ведущим или ведомым, если в определённый момент выставлять нужный режим. Но быть может ошибаюсь.
2. чё тут думать? таймер - фактически единственная адекватная возможность получить прерывание извне мк.
4. как-то пришлось реализовывать одновременный приём двух каналов arinc-429 48кбит/с на 1886ве2@4MIPS со всеми положенными проверками на скорость, пропадания сигнала, буферы, передача + основная задача. только интерфейсы генерировали 200000 прерываний в секунду. так что успехов вашему программисту)
spi вам вообще никак не поможет.
4. Ну в итоге-то получилось?

Даже если экстраполировать ваш вариант на мой случай, то это получается около 800к прерываний/сек, так? Ведь у вас два потока по 48кбит/сек, а здесь один но 400кбит/сек.

Да и почитав "Программа для контроллера I2C-шлюза (режим I2C-slave из терминалки ПК)" - если уж человек на 20ти МГц на ATTiny2313 получал 575 кбит/с, то не верится, что получить 400 кбит/с на 32ух или в крайнем случае на 64ёх или даже на 80ти МГц не получится.

Просто хочется чтобы в даже самых экстремальных случаях, даже при отказе внешнего кварца или генератора, всегда был запас. И я бы применил Миландровский 1886ВЕ2 с аппаратным блоком или НИИЭТовский 1887ВЕ3Т, но температура....

Запас, даже такой колоссальный как у этого МК это лучше, чем рассказы про то, "Как мне не хватило 1ого байта" или "Как мы охлаждали наши"утюги" ради одного лишь МК"...

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В


Вернуться к началу
СообщениеДобавлено: 2013-апр-01 14:45 
Не в сети

Зарегистрирован: 2009-июл-21 14:13
Сообщения: 1501
Откуда: Тула
HEMAH писал(а):
4. Ну в итоге-то получилось?

Даже если экстраполировать ваш вариант на мой случай, то это получается около 800к прерываний/сек, так? Ведь у вас два потока по 48кбит/сек, а здесь один но 400кбит/сек.

Да и почитав "Программа для контроллера I2C-шлюза (режим I2C-slave из терминалки ПК)" - если уж человек на 20ти МГц на ATTiny2313 получал 575 кбит/с, то не верится, что получить 400 кбит/с на 32ух или в крайнем случае на 64ёх или даже на 80ти МГц не получится.

Просто хочется чтобы в даже самых экстремальных случаях, даже при отказе внешнего кварца или генератора, всегда был запас. И я бы применил Миландровский 1886ВЕ2 с аппаратным блоком или НИИЭТовский 1887ВЕ3Т, но температура....

Запас, даже такой колоссальный как у этого МК это лучше, чем рассказы про то, "Как мне не хватило 1ого байта" или "Как мы охлаждали наши"утюги" ради одного лишь МК"...
разумеется получилось. обработчики были запутанные, но не длинные, команд по 20; не помню уже точно, а счтать лень, минимальная тактовая нужна была мегагерц 10-12 для двух одновременных приёмов и двух передач.

сравнивать атмегу и этот проц не совсем корректно: тут многостадийный конвеер, задержки флеша, оченнь большие (по меркам ядра авр8) накладные расходы на прерывания и т.д. т.е. у вас скорее всего всё получится, но готовьтесь к тому, что 400 кбит/сек будут отжирать приличную часть производителности проца даже на десятках МГц. Тут дело, скорее, как вам правильно сказал Сергей, в реализации.

_________________
сочувствующий…


Вернуться к началу
СообщениеДобавлено: 2013-апр-01 19:00 
Не в сети
Аватара пользователя

Зарегистрирован: 2011-окт-19 17:25
Сообщения: 546
Откуда: г. Владимир ОАО "ВКБР"
Вообще почему-то в нэте любят именно программную реализацию I2C, хотя непонятно почему...
Кроме того, пообщавшись с человеком, который с этим чудо-интерфейсом массово хм, наобщался, тоже услышал мнение, что программная реализация позволяет более гибко работать в случае возникновения отказа одного из устройств на шине.

Дк всё-таки, у программной реализации есть какие-то плюсы?

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В


Вернуться к началу
СообщениеДобавлено: 2013-апр-03 07:39 
Не в сети

Зарегистрирован: 2009-июл-21 14:13
Сообщения: 1501
Откуда: Тула
HEMAH писал(а):
Вообще почему-то в нэте любят именно программную реализацию I2C, хотя непонятно почему...
<...>
Рискну предположить, что программную реализацию любят из-за простоты использования: подключил библиотеку, указал пины и это будет работать на всех МК. А железку надо изучать, прерывания её и т.п. К тому же часто не стоит задача жесткого реалтайма, поэтому на время общения МК с устройством можно полностью отдаться поллингу битов порта.
HEMAH писал(а):
<...>
Кроме того, пообщавшись с человеком, который с этим чудо-интерфейсом массово хм, наобщался, тоже услышал мнение, что программная реализация позволяет более гибко работать в случае возникновения отказа одного из устройств на шине.
<...>
Весьма интересно и полезно было бы узнать подробности, аргументы, доводы. На первый взгляд не должно быть разницы при прочих равных.

_________________
сочувствующий…


Вернуться к началу
СообщениеДобавлено: 2013-апр-03 18:04 
Не в сети
Аватара пользователя

Зарегистрирован: 2011-окт-19 17:25
Сообщения: 546
Откуда: г. Владимир ОАО "ВКБР"
prostoRoman писал(а):
К тому же часто не стоит задача жесткого реалтайма, поэтому на время общения МК с устройством можно полностью отдаться поллингу битов порта.
В "сломанный телефон" играть не буду, но вот что-то вроде этого и ещё возможность быстро отслеживать состояние линии, если какое-то устройство начинает затягивать обмен, а другие начинают "Ша, я не понял? Хто здесь Мастер?". Но опять же, оговорюсь, может что-то и не так понял.

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В


Вернуться к началу
СообщениеДобавлено: 2013-апр-10 19:47 
Не в сети
Аватара пользователя

Зарегистрирован: 2011-окт-19 17:25
Сообщения: 546
Откуда: г. Владимир ОАО "ВКБР"
Тут такой вопрос ещё возник:
Вот есть в контроллере датчик температуры, но вопрос - вывести данные на экран или ещё куда, это не проблема, а вот как эти данные к чему-нибудь привязать, перевести в градусы Цельсия, они ведь собственно говоря в "попугаях"?
Неужели каждый контроллер придётся пихать в камеру и калибровать значения?

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В


Вернуться к началу
СообщениеДобавлено: 2013-апр-15 15:18 
Не в сети

Зарегистрирован: 2013-апр-13 14:21
Сообщения: 22
prostoRoman писал(а):
Весьма интересно и полезно было бы узнать подробности, аргументы, доводы. На первый взгляд не должно быть разницы при прочих равных.
Из своего опыта работы с I2C тоже пришел к программной реализации. Основная причина - повальная глючность реализации аппаратных контроллеров, причем у каждого контроллера - свои глюки. Программная реализация легко портируется и стабильнее себя чувствует.


Вернуться к началу
СообщениеДобавлено: 2013-апр-15 21:21 
Не в сети

Зарегистрирован: 2009-июл-21 14:13
Сообщения: 1501
Откуда: Тула
LightElf писал(а):
prostoRoman писал(а):
Весьма интересно и полезно было бы узнать подробности, аргументы, доводы. На первый взгляд не должно быть разницы при прочих равных.
Из своего опыта работы с I2C тоже пришел к программной реализации. Основная причина - повальная глючность реализации аппаратных контроллеров, причем у каждого контроллера - свои глюки. Программная реализация легко портируется и стабильнее себя чувствует.
ну так я и предполагал. А сколько ресурсов по вашему опыту будет откушивать один такой интерфейс у АРМа?

_________________
сочувствующий…


Вернуться к началу
СообщениеДобавлено: 2013-апр-16 07:34 
Не в сети

Зарегистрирован: 2013-апр-13 14:21
Сообщения: 22
prostoRoman писал(а):
ну так я и предполагал. А сколько ресурсов по вашему опыту будет откушивать один такой интерфейс у АРМа?
У меня на I2C обычно висят устройства, не требующие ни скорости, ни частоты опроса (RTC, датчики и т.д.) Поэтому скорость обмена ставлю очень низкую, ресурсы потребляются мизерные. Как оно будет у вас - судить не берусь.


Вернуться к началу
СообщениеДобавлено: 2013-май-06 20:42 
Не в сети
Аватара пользователя

Зарегистрирован: 2011-окт-19 17:25
Сообщения: 546
Откуда: г. Владимир ОАО "ВКБР"
И всё же...
Вот к примеру в описании на тот же функциональный аналог STM32F103xx на 226ой странице присутствует формула, благодаря которой можно соотнести считываемые данные с внутреннего термодатчика с температурой в гра.Ц
Вложение:
[ attachment ]
1_1.png [ 135.65 КБ | 5796 просмотров ]
Вложение:
[ attachment ]
2_1.png [ 147.97 КБ | 5796 просмотров ]
А как быть с 1986ВЕхх ?

P.S. Заранее извиняюсь за большие картинки.... но был бы спойлер...

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В


Вернуться к началу
СообщениеДобавлено: 2013-май-07 08:28 
Не в сети

Зарегистрирован: 2009-май-22 09:01
Сообщения: 1302
Откуда: АО "ПКК Миландр"
HEMAH писал(а):
И всё же...
Вот к примеру в описании на тот же функциональный аналог STM32F103xx на 226ой странице присутствует формула, благодаря которой можно соотнести считываемые данные с внутреннего термодатчика с температурой в гра.Ц
Вложение:
Вложение 1_1.png больше недоступно
Вложение:
Вложение 2_1.png больше недоступно
А как быть с 1986ВЕхх ?

P.S. Заранее извиняюсь за большие картинки.... но был бы спойлер...
В 1986ВЕ9х термодатчик имеет очень большие разбросы от технологии. Или проще говоря без коллибровки не получился.
Температуру мерить можно но для каждого образа надо определять собственные зависимости и калибровать.

В аттаче его параметры типовые.


Вложения:
Отчет по термодатчику.pdf [319.67 КБ]
523 скачивания
Вернуться к началу
СообщениеДобавлено: 2013-май-07 11:41 
Не в сети
Аватара пользователя

Зарегистрирован: 2011-окт-19 17:25
Сообщения: 546
Откуда: г. Владимир ОАО "ВКБР"
-=Sergei=- писал(а):
В 1986ВЕ9х термодатчик имеет очень большие разбросы от технологии. Или проще говоря без калибровки не получился.
Температуру мерить можно, но для каждого образа надо определять собственные зависимости и калибровать.

В аттаче его параметры типовые.
А как в нашем, производственном случае его будет правильнее всего калибровать ?
  1. Это камера со своим термодатчиком, в которой происходит повышение температуры с дискретным шагом, например в 5 Гра.Ц. После изменения температуры в камере на указанный шаг например проходит 10 минут и производится съём данных.
  2. Та же камера, но эталонный термодатчик располагается например на расстоянии 10мм от корпуса или прямо на корпусе.
  3. Какой-либо ещё вариант.
В принципе, например нас не интересует точность до градуса, в нашем устройстве важно лишь отслеживать возможный перегрев МК, не внешнюю температуру окр. среды, а именно перегрев МК(Само изделие работает до 85ти Гра.Ц, а у МК макс. темп. 125 Гра.Ц, т.е получается что 10ти, и даже 15ти градусной точности вполне хватило бы) и не допустить возникновение точечного теплового мешка. Пусть бы это был разброс в плюс/минус 10-15 Гра.Ц, нас бы вполне устроило, так как то всего лишь элемент дополнительной термозащиты.
Для таких разбросов как правильно было бы соотнести температуру и значение, выдаваемое температурным сенсором?
Просто нужен какой-то единый алгоритм, иначе я не представляю, как можно в производственных условиях калибровать МК...

_________________
"В радиотехнике, как в церкви - многое не понятно, но приходится верить"
ВлГУ. к.т.н Садовский Н.В


Последний раз редактировалось HEMAH 2013-сен-25 18:23, всего редактировалось 1 раз.

Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 37 сообщений ]  На страницу « 1 2 3 »

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 3 гостя


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Перейти: 

Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB