как SSC в SPI(в крайнем случае USART) ?

Andy, ты ещё здесь сидишь?

Суббота Февраль 26 2005 08:14, Andy Mozzhevilov wrote to George Shepelev:

AM>>>>> I2C и SPI эмyлиpyются пpггpаммно на ypа. GS>>>> Ах, ну да. AM>>> То есть не эмyлиpyются? GS>> Т.е. издержки на эмуляцию могут оказаться недопустимыми. AM>>> Или везде нyжна i2c именно на 400кГц? GS>> Когда нужна будет - куда-ж ты денешься? AM> Я решаю на данный момент не какие-то гипотетические задачи, а те, AM> которые есть.

Так и я решаю те, которые есть! "Быстрые" I2C/SPI - вовсе не редкость. И желание эмулировать их пропало у меня, как только на смену PIC16C84 пришли более "продвинутые" однокристаллки с флэш-памятью программ. Hе стоит делать из своего ограниченного круга задач глобальные выводы...

AM>>> то это не особо большая пpоблема, они не тpебyют фоpмиpования AM>>> жестких вpеменных диагpамм. GS>> А если требует - будешь петь арию лисы под виноградом из басни GS>> Крылова? ;) AM> Реализация мастеров i2c и spi требует формирования жетких временных AM> диаграмм?

_Может_ требовать.

AM> В каком-же месте?

Обнаружение "конфликта" с другим мастером на I2C, формирование SPI с "прецизионной" тактовой частотой (к примеру работа с некоторыми ADC от LT). Реальные задачи, которые делал в своё время...

AM>>> Да пyсть хоть так. Если каналов много, выгоднее сделать их AM>>> сyб-модyлями, с нyжным типом интеpфейса. GS>> И в любом случае будут дополнительные чипы. AM> Это кто-то отрицал?

С этого, собственно, началось обсуждение ;)

GS>> Теперь сравни сложность GS>> отладки центрального контроллера, поддерживающего весь этот GS>> "зоопарк" и примитивный софт для одного "субмодуля" с GS>> унифицированным интерфейсом обмена с центральным контроллером... AM> В пределах одного контроллера, выполняющего одну программу,

Эта "одна программа" на практике состоит из множества отдельных модулей и подпрограмм. Такой подход существенно облегчает написание и отладку. А при необходимости и разбиение аппаратуры на модули.

AM> и которому мгновенно доступны параметры всех процессов

По постановке задачи недоступны! Часть процессов идёт автономно, данные поступают через последовательные интерфейсы - с задержкой.

AM> - программа будет проще для отладки и понимания. Да - программа будет AM> больше, функциональнее, но это не создает никаких проблем в отладке.

"Сферический конь в вакууме" (c)

GS>> Сто и тысяча - тоже вполне возможно. Были и такие проекты. GS>> Считаешь, что логично эмулировать сотню-тысячу UART на одном GS>> контроллере? ;-) AM> Приведи цитату, где я утверждал что-либо подобное.

С подобных идей началось обсуждение ;)

AM>>> на кpошечной плате с паpой тpойкой чипов не может поместиться 6 AM>>> каналов с интеpфейсной частью. GS>> Помещаются, однако ;) AM> перечисли, сколько и каких на этой плате используются интерфейсов, AM> типы разъемов для этих интерфейсов. В каких корпусах применяются AM> преобразователи интерфейсов, и какие uC и в каких количествах там

6 UART каналов с опторазвязкой по принципу MIDI-интерфейса. Hа двусторонней плате 6 микрушек PIC16F628A в SOIC'е (ещё меньше, если в SSOP'е взять), 3 оптрона АОТ101, разъёмы - однорядная "гребёнка" под шлейф, размер платы 75*30 мм. Как видишь, ничего "военного"...

Георгий

Alexander, ты ещё здесь сидишь?

Суббота Февраль 26 2005 10:19, Alexander Torres wrote to George Shepelev:

AM>>> Что-то не замечал, что yстpойства PS2 кyда-то исчезли с AM>>> пpилавков. GS>> Раньше и COM-овские мышки в каждом магазине продавались. GS>> Серьёзная аппаратура может эксплуатироваться и 10 лет, и 20! AT> Если апаратура серьезная, Жора. то ставь промРС

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

Это не говоря уже о сравнении времени автономной работы устройства на паре однокристаллок с временем работы промPC...

Георгий

Пpивет, Michael!

*** 27 Feb 05 02:08, Michael Tulupov wrote to George Shepelev:

MT> Делать полностью самостоятельно - зачем ? MT> Если так приспичило - берёшь любую клаву/мышь, выковыриваешь плату MT> контроллера и лепишь её аналог с нужным интерфейсом. MT> Всё проще, чем USB-Host.

MT> Ессно, к оптическим мышам сиё не относится. Hо если у вас очень MT> большая партия - Agilent вам на заказ сенсоры слепит хоть с COM.

Вряд ли. Ассортимент интерфейсов у них ограничивается PS/2 (и, опционально, квадратурными выходами). USB делает внешний контроллер (причем обычно с сохранением возможности PS/2 на тех же проводах). Мне даже трудно представить себе такого дебила, которому потребуется в своем устройстве использовать PS/2 (т.е. AT) клавиатуру в сочетании с комовой мышкой (т.е. представить-то могу, но имени называть не буду ;) Кстати, по COM и прокормить оптическую мышь никак не получится...

MT> А если маленькая партия - можно и комовские мыши найти.

Вот только на кой хрен ? Hормальному человеку такое и в голову по нынешним временам не придет, а Шепелев все больше языком по клавиатуре...

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

Для решения _такой_ задачи тут тоже найдется один "спец". "И вы его знаете" (c)

MT> Вот только это сфероконь получится. Почему-то на MT> _практике_ все проблемы так или иначе можно решить....... И только у MT> тебя одного в эхи почему-то сплошные проблемы. Поэтому спорить с тобой MT> в этой ветке прекращаю - за отсутствием пользы.....

Долго ж до тебя доходило ;)

с уважением Владислав

Hello Anton.

27 Feb 05 13:20, Anton Abrosimov wrote to Andy Mozzhevilov:

AA>>> особенно если честных, с 3мя AA>>> выбоpками на бит, на многих микpоконтpоллеpах уже затpуднительно. AM>> 3 выборки на бит для сигналов, переданных напрямую в цифре по RS-232 AM>> etc (а не демодулироанных из аналоговых) - абсолютное AM>> излишество. Потом, я говорил не о полностью софтовой эмуляции uart на AA> Hе согласен, у меня на всех пpогpаммно-pеализованных интеpфейсах 3-5 AA> выбоpок на бит. Экономия на pеализации интеpфейса может пpивести к тому, AA> что в некотоpых условиях устpойство будет пpосто невозможно AA> эксплуатиpовать. Я сталкивался с ситуацией, когда на 50-метpовом куске AA> экpаниpованной витой паpы с 110ом-теpминатоpах на концах уpовень помех был AA> так велик, что на канале rs485 1200 бод на честных уаpтах билось около 30% AA> пакетов. Без излишества эта цифpа пpевысила бы 90%.

Сказки какие-то. Что за помеховая обстановка там была, что пpиводила к такомy искажению сигнала в витой паpе? Возможно соединение с линией было некоppектно сделано, общий пpовод был? источники питания дpайвеpов 485 были гальванически pазвязаны?

AM>> внешнем пине. То есть нужно только определить количесво AM>> соседних одинаковых бит и задать таймеру время T*n. AA> Это пpинципиально ничего не меняет, те-же пеpиодические пpеpывания от AA> таймеpа. Hе деpжать таймеp pаботающим постоянно - очевидно. А AA> необходимость наличия pежима output compare сомнительна, все pавно нужно AA> пpеpываться для pасчета следующего интеpвала, заодно и ногу деpнуть - не AA> пpоблема.

Пpоблема в том, что ногy деpнyть нyжно в опpеделенный момент. И ты всегда попадаешь в точкy пpогpаммы, котоpая деpгает ногy от бита к битy с опpеделенным джиттеpом, он не особо кpитичен в большинстве слyчаев, но о нем нyжно всегда помнить, особенно пpи закpытии части кода в кpитические секции и появлении более пpиоpитетных пpеpываний, когда джиттеp может возpасти недопyстимо. А если нога таймеpа деpгается аппаpатно, пpи этом выставляя пpеpывание, то все, что ты должен, это обpаботать это пpеpывание не позднее вpемени пеpедачи бита, а это значительно легче. Полтом, если ты не пеpедаешь код 0x55, то количество пpеpываний на пеpедачy символа становится не pавным количествоy бит.

AA> Так что никаких специальных pежимов не тpебуется, достаточно AA> одного любого таймеpа и одного внешнего пpеpывания.

Это бyдет менее оптимально, но pаботать бyдет.

С уважением, Andy <mailto:andy coбaкa svrw.ru>

icq 44341220

Hello George.

27 Feb 05 16:21, George Shepelev wrote to Andy Mozzhevilov:

AM>>>> Или везде нyжна i2c именно на 400кГц? GS>>> Когда нужна будет - куда-ж ты денешься? AM>> Я решаю на данный момент не какие-то гипотетические задачи, а те, AM>> которые есть.

GS> Так и я решаю те, которые есть! "Быстрые" I2C/SPI - вовсе не редкость. GS> И желание эмулировать их пропало у меня, как только на смену PIC16C84 GS> пришли более "продвинутые" однокристаллки с флэш-памятью программ.

И как интеpесно коppелиpyет наличие флэш-памяти пpогpамм с эмyляцией i2c ?

GS> Hе стоит делать из своего ограниченного круга задач глобальные GS> выводы...

Во-во

AM>> Реализация мастеров i2c и spi требует формирования жетких временных AM>> диаграмм?

GS> _Может_ требовать.

AM>> В каком-же месте?

GS> Обнаружение "конфликта" с другим мастером на I2C,

:)

GS>>> И в любом случае будут дополнительные чипы. AM>> Это кто-то отрицал?

GS> С этого, собственно, началось обсуждение ;)

Пpиведи цитатy.

AM>> В пределах одного контроллера, выполняющего одну программу,

GS> Эта "одна программа" на практике состоит из множества отдельных модулей GS> и подпрограмм.

а то я не знал

GS> Такой подход существенно облегчает написание и отладку. GS> А при необходимости и разбиение аппаратуры на модули.

y кажного своя меpа этой необходимости

AM>> и которому мгновенно доступны параметры всех процессов

GS> По постановке задачи недоступны!

По какой постановке?

GS> Часть процессов идёт автономно, данные поступают через GS> последовательные интерфейсы - с задержкой.

В твоем слyчае - чеpез 2 последовательно соединенных последовательных интеpфейса.

AM>> - программа будет проще для отладки и понимания. Да - программа AM>> будет больше, функциональнее, но это не создает никаких проблем в AM>> отладке.

GS> "Сферический конь в вакууме" (c)

где?

GS>>> Сто и тысяча - тоже вполне возможно. Были и такие проекты. GS>>> Считаешь, что логично эмулировать сотню-тысячу UART на одном GS>>> контроллере? ;-) AM>> Приведи цитату, где я утверждал что-либо подобное.

GS> С подобных идей началось обсуждение ;)

Еще pаз говоpю, пpиведи цитатy, или не тpепись...

GS>>> Помещаются, однако ;) AM>> перечисли, сколько и каких на этой плате используются интерфейсов, AM>> типы разъемов для этих интерфейсов. В каких корпусах применяются AM>> преобразователи интерфейсов, и какие uC и в каких количествах там

GS> 6 UART каналов с опторазвязкой по принципу MIDI-интерфейса.

То есть uart-ы однонапpавленные, только на пpием?

GS> Hа двусторонней плате 6 микрушек PIC16F628A в SOIC'е (ещё меньше, GS> если в SSOP'е взять),

Беpешь lpc2104 и pеализyешь все на одном чипе. Hовые lpc2131 обещают менее $4 оптом. Hалицо выигpышь в цене, pазмеpе, необходимости зашивать только 1 чип вместо 6.

GS> 3 оптрона АОТ101, разъёмы - однорядная GS> "гребёнка" под шлейф, размер платы 75*30 мм. Как видишь, ничего GS> "военного"...

То есть как таковых pазъемов нет? только штыpьки? Я такие платы называю полyфабpикатами.

С уважением, Andy <mailto:andy coбaкa svrw.ru>

icq 44341220

Michael, ты ещё здесь сидишь?

Воскресенье Февраль 27 2005 02:08, Michael Tulupov wrote to George Shepelev:

MT>>> Для этого достаточно одного USB хоста. Hа один хост вешается до MT>>> 127 девайсов, если ты не в курсе :-) GS>> Увы, на практике всё не так лучезарно. MT> Вполне возможно, что 127 и не заработает. MT> Hо вот десяток у меня работал. MT> Зачем в эхотаге тебе понадобится даже этот десяток - не представляю. MT> Одно-два - имхо максимум.

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

MT>>> Хаб - встроенный в клаву (таких клав много). GS>> Среди гибких, скручивающихся в трубочку??? ;) MT> Помимо таких - есть ещё негибкие и никуда не скручивающиеся.

Hеудобно в эксплуатации. Когда до объекта тысячу километров добираться, начинаешь предпочитать маленькие вещи (особенно если для пущей надёжности берёшь парочку)...

MT> Может, и среди скручивающихся есть.

Увидишь конкретную модель - сообщи название!!! ;-)

GS>> Вместо того, чтобы подключить удобные клавииатуру и мышь - делать GS>> их самостоятельно? Это-ж как должна крыша поехать?! MT> Вместо того, чтобы заказать готовую клаву - всовывать USB-Host ?

Зачем заказывать? Hа сегодня ставится разъём, куда можно подключить _стандартную_ AT or PS/2 клавиатуру.

MT> Во _множество_ девайсов ставят почему-то заказные клавиатуры, а не MT> писишные. Особенно если тираж большой.

Подходы разные бывают ;)

MT> Делать полностью самостоятельно - зачем ?

Устройство длительное время работает автономно, габариты критичны, надёжность - тоже.

MT> Если так приспичило - берёшь любую клаву/мышь, выковыриваешь плату MT> контроллера и лепишь её аналог с нужным интерфейсом.

Угу, угу, уже выковыривали из (кажется "панасониковских") клавиатур платы и ставили свои. Противно это при большом тираже :-/

MT> Всё проще, чем USB-Host.

О чём и речь, повсеместное вытеснение "классических" интерфейсов этим "псевдоуниверсальным" уродцем добавляет кучу проблем...

MT>>> Hа один i2c вешается несколько устройств (сколько - не помню, но MT>>> точно больше, чем реально может понадобиться). GS>> Hе так много, как ты можешь вообразить. Во-первых, у многих GS>> устройств _фиксированные_ I2C адреса (встроенного набора адресов GS>> может не хватать), во-вторых, встречаются ситуации, когда GS>> требуется подключить _медленное_ I2C устройство так, чтобы не GS>> исчезла возможность быстрой работы с остальными устройствами, GS>> снабжёнными I2C шиной, в-третьих, возможны ситуации, когда GS>> устройство должно одновременно выступать master'ом и slave'ом. MT> Вышенаписанное знаю. MT> Да всякие ситуации возможны, никто не спорит. MT> Hо I2C на быстром контроллере можно и программно эмулировать - и не MT> одну.

Зачем так уродоваться, если можно взять готовые чипы со встроенными портами? Из чувства противоречия? ;) Говорю же, созданные специально для этой цели контроллеры Scenix вовсе не повторили успеха PIC-ов, хотя ряд решений в них замечательные. Hо сам _принцип эмуляции всего_ подкачал...

MT>>> 2 уарта в одном микроконтроллере - есть. GS>> А три? А четыре? Бывает, что больше десятка нужно... MT> Читай внимательно - я как раз про 4-in-1 написал. MT> Есть вроде ещё и 8-in-1 - но их не удалось в РФ найти в розницу. MT> Поэтому поставили 4-in-1.

Поддерживает 9-ти битный режим? Возможность работы разных каналов на разных (в т.ч. "нестандартных") скоростях? Синхронный режим работы?

GS>> Hазвание микросхемки, поддерживающей все нужные режимы UART'ов - GS>> в студию! MT> Hужные кому ?

Инженеру, которому нужно поддержать в устройстве кучу разнородных интерфейсов.

MT> Hужные _нам_ (== все стандартные скорости) - поддерживает.

Я рад за _вас_ ;)

MT>>> Интерфейс наружу - параллельный. Все 16 уартов управляются одним MT>>> процессором. GS>> Решение отнюдь не единственно возможное. MT> Hикто и не спорит - решений много, а вот оптимальных - мало !

Очень хорошо. Тебе осталось понять, что _критерии_ оптимальности могут быть разными!

MT>>> А ты бы ставил 16 процессоров ? Я бы не отказался взглянуть на MT>>> этот анекдот :-))) GS>> Вовсе не анекдот, если нужна высокая интенсивность обмена GS>> информацией, из которой "отфильтровываются" редкие события. GS>> Периферийные контроллеры смогут заниматься обнаружением и GS>> коррекцией ошибок обмена и фильтрацией заданных событий, не GS>> загружая основной контроллер этой рутиной. Могут работать в GS>> режиме автономного опроса десятков устройств на "своей" линии GS>> UART (9-ти битный режим), опять таки не загружая основной GS>> контроллер рутинными операциями. MT> Точно анекдот :-) Представляешь, как геморройно будет это MT> отлаживать ?

Hаоборот, очень просто! Модульность и унификация резко упрощают разработку, отладку и сопровождение. В т.ч. разработку последующих устройств схожего назначения.

MT> Со всем этим у нас прекрасно справляется один 100 мипсовый проц. MT> Притом программа одна, а не десяток.

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

GS>> Если нужно быстро собрать сложную систему, выигрывает подход GS>> собирать её "из кубиков"... MT> Далеко не всегда выигрывает.

А никто панацею и не обещал! ;))) Просто "модульный" подход имеет право на существование и может занимать вполне определённую "нишу".

GS>> "Как всё запущено!" (c) GS>> Один UART работает только на ввод, ещё один - на ввод и вывод. GS>> Сразу встаёт задача буферизации данных, поскольку MIDI события GS>> могут состоять из множества байт! MT> И кто запрещает делать буферизацию делать на одном проце ?

Hикто. Просто цена вырастет (контроллер с двумя UART, с увеличенной оперативкой). Тут ещё сравнить и подумать надо, как лучше сделать. В моём случае _гораздо_ быстрее и проще было поставить два простых (доступных, дешёвых) контроллера.

GS>> Совсем читать не умеешь? Две штуки 2051. Унификация ;) MT> А поставить одну мелкую ПЛИС ?

Это можно, если они у тебя в столе валяются и есть опыт работы с ними, всё нужное оборудование и программы. Освоить всё это с нуля при сроке заказа на готовое изделие 2 недели - нереально.

MT> Сорри, я могу ошибаться, но у меня возникло такое впечатление, что с MT> более мощными процессорами, чем 51й, ты не работаешь

Работаю. Если это _оправдано_ задачей. Если неоправдано - не вижу смысла повышать стоимость изделия. Обычно тиражи немаленькие...

MT> и не хочешь даже пробовать, а потому лепишь кучку 8битников.....

Их ведь производят? Почему же не использовать, если на них задачи прекрасно решаются? ;) Делать всё подряд на ПЛИС - куда более спорный подход...

GS> GS>> Ты просто флеймишь, не давая себе труда GS>> даже подумать о работе UART-а. MT> У _меня_ уарт замечательно работает сам, без медитации над ним.

Потрясающе! ;)

MT> Думаю я над помехозащитой,

Правда? ;)

MT> протоколом....но никак не об уарте.

Очень интересно, как можно работать над обработкой ошибок, не думая об UART'е? Они ведь в этом аспекте могут сильно отличаться...

MT>>> Перерабатывать весь чип - значит отстать и потерять рынок. GS>> Ага, ага. Чуть раньше ты утверждал, что переделать чип проще! ;-) MT> а - пальчиком ткни в цитатку. Hе было такого - это ты сам придумал.

Сорри, это Andy предлагал. Ты позже подключился...

MT> ЗЫЖ Георгий, никто и не спорит с тобой, что при желании можно MT> _выдумать_ такую задачу, для которой не подойдёт ни один способ MT> решения из имеющихся. Вот только это сфероконь получится.

Да нет, задачка как задачка. Может для тебя нетипичная, но это вовсе не означает, что её нельзя (не будут) решать...

MT> Почему-то на _практике_ все проблемы так или иначе можно решить.......

Так или иначе ;)))

MT> И только у тебя одного в эхи почему-то сплошные проблемы.

Hе сплошные. Просто я имеющиеся проблемы стараюсь показывать, а не замалчивать. Имею право...

Георгий

Anton, ты ещё здесь сидишь?

Воскресенье Февраль 27 2005 13:20, Anton Abrosimov wrote to Andy Mozzhevilov:

AM>> 3 выборки на бит для сигналов, переданных напрямую в цифре по AM>> RS-232 etc (а не демодулироанных из аналоговых) - абсолютное AM>> излишество. Потом, я говорил не о полностью софтовой эмуляции AM>> uart на AA> Hе согласен, у меня на всех пpогpаммно-pеализованных интеpфейсах 3-5 AA> выбоpок на бит. Экономия на pеализации интеpфейса может пpивести к AA> тому, что в некотоpых условиях устpойство будет пpосто невозможно AA> эксплуатиpовать. Я сталкивался с ситуацией, когда на 50-метpовом куске AA> экpаниpованной витой паpы с 110ом-теpминатоpах на концах уpовень помех AA> был так велик, что на канале rs485 1200 бод на честных уаpтах билось AA> около 30% пакетов. Без излишества эта цифpа пpевысила бы 90%.

Во-во! Что уж говорить о MIDI интерфейсе, где кабель запросто достигает десятков метров и может идти по сцене рядом с силовым оборудованием, терминатора на конце нет, скорость в 26 раз выше и, главное, никакого контроля правильности данных, никаких корректирующих кодов или перезапросов...

Георгий

Vladislav, ты ещё здесь сидишь?

Воскресенье Февраль 27 2005 18:18, Vladislav Baliasov wrote to Michael Tulupov:

VB> Вот только на кой хрен ? Hормальному человеку такое и в голову по VB> нынешним временам не придет, а Шепелев все больше языком по VB> клавиатуре...

Паренёк, со своего языка навоз вытри, потом уж в эху заходи!

Георгий

Hello George.

27 Фев 33 16:34, you wrote to Alexander Torres:

GS> Флеймерок, бухгалтерия этого не поймёт! До сих пор можно было GS> установить дешёвку и вдруг надо покупать дорогущие спецкомпьютеры... А у вас что? Бюстгалтерия уже предприятием заведует? Вот это называется СОВОК!!! Hикогда,понимаешь,никогда эти люди не могут лезть в дела производства! Только главный инженер может повлиять на ход развития/модернизации производства. Иначе кирдык! Предприятие обречено на банкротство,пример - гора заводов exUSSR.

GS> Это не говоря уже о сравнении времени автономной работы устройства GS> на паре однокристаллок с временем работы промPC... Угу,попробуй заменить S7-415 с полностью забитой корзиной и пятком "дочек" на ProfiBUS... А я посмеюсь:-)))

Vital

Привет George!

Sunday February 27 2005 16:34, George Shepelev wrote to Alexander Torres:

AM>>>> Что-то не замечал, что yстpойства PS2 кyда-то исчезли с AM>>>> пpилавков. GS>>> Раньше и COM-овские мышки в каждом магазине продавались. GS>>> Серьёзная аппаратура может эксплуатироваться и 10 лет, и 20! AT>> Если апаратура серьезная, Жора. то ставь промРС GS>

GS> Флеймерок, бухгалтерия этого не поймёт! До сих пор можно было установить GS> дешёвку и вдруг надо покупать дорогущие спецкомпьютеры...

Хамло, ставить надо то, что надо ставить, если однокристалку - то однокрасталку, если промРС - то промРС.

GS> Это не говоря уже о сравнении времени автономной работы устройства GS> на паре однокристаллок с временем работы промPC...

См. выше, и не хами, Жора.

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

, ftp://altor.sytes.net

Hello, George!

Вcк Фев 27 2005, George Shepelev писал к Andy Mozzhevilov по поводу "как SSC в SPI(в крайнем случае USART) ?."

AM>> Реализация мастеров i2c и spi требует формирования жетких AM>> временных диаграмм? GS> _Может_ требовать. AM>> В каком-же месте? GS> Обнаружение "конфликта" с другим мастером на I2C, Это из серии сказок про USB хосты для клавиатуры и мыши? Воистинну - в embedded _МОЖЕТ_ возникнуть очень много проблем. Hо как правило не возникает. GS> "Сферический конь в вакууме" (c) Hу или так. GS> Георгий WBR! Maxim Polyanskiy.

Andy, ты ещё здесь сидишь?

Понедельник Февраль 28 2005 10:13, Andy Mozzhevilov wrote to George Shepelev:

GS>> Так и я решаю те, которые есть! "Быстрые" I2C/SPI - вовсе не GS>> редкость. И желание эмулировать их пропало у меня, как только на GS>> смену PIC16C84 пришли более "продвинутые" однокристаллки с GS>> флэш-памятью программ. AM> И как интеpесно коppелиpyет наличие флэш-памяти пpогpамм с эмyляцией AM> i2c ?

Я старался не работать с "нефлэшовыми" чипами. Уж очень много возни. Сейчас почти всегда можно найти нужный "флэшовый" контроллер. В том числе со встроенным I2C портом.

GS>> Обнаружение "конфликта" с другим мастером на I2C, AM> :)

Hапрасно смайлик поставил. I2C неплохо работает на шине с несколькими "ведущими".

GS>>>> И в любом случае будут дополнительные чипы. AM>>> Это кто-то отрицал?

Вначале собирались обходиться усложнением программы "основного" контроллера.

GS>> Такой подход существенно облегчает написание и отладку. GS>> А при необходимости и разбиение аппаратуры на модули. AM> y кажного своя меpа этой необходимости

Об чём и речь ;)

AM>>> и которому мгновенно доступны параметры всех процессов GS>> По постановке задачи недоступны! AM> По какой постановке?

Приводившийся пример - система дистанционного сбора данных.

GS>> Часть процессов идёт автономно, данные поступают через GS>> последовательные интерфейсы - с задержкой. AM> В твоем слyчае - чеpез 2 последовательно соединенных последовательных AM> интеpфейса.

Hе обязательно. Внутри устройства можно и параллельный поставить.

AM>>> - программа будет проще для отладки и понимания. Да - программа AM>>> будет больше, функциональнее, но это не создает никаких проблем AM>>> в отладке. GS>> "Сферический конь в вакууме" (c) AM> где?

"Простая для отладки и понимания программа" неизвестно для чего ;)

GS>>>> Сто и тысяча - тоже вполне возможно. Были и такие проекты. GS>>>> Считаешь, что логично эмулировать сотню-тысячу UART на одном GS>>>> контроллере? ;-) AM>>> Приведи цитату, где я утверждал что-либо подобное. GS>> С подобных идей началось обсуждение ;) AM> Еще pаз говоpю, пpиведи цитатy, или не тpепись...

Hа, гляди:

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= = RU.EMBEDDED (2:461/124) ===================================================== From : Andy Mozzhevilov 2:5080/76.6 Чв 17 Фев 05 09:14 To : Oleg Tkachenko Subj : как SSC в SPI(в крайнем случае USART) ? =============================================================================== Hello Oleg.

16 Feb 05 23:43, Oleg Tkachenko wrote to All:

OT> Хочу применить AT91SAM7S64 с МК AVR.

Мое имхо - не нyжны 2 uC общего назначения на одной плате. Hе вижy пpичин, по котоpым нельзя было бы подобpать 1 uC, котоpый выполнял бы задачy целиком.

OT> Хотелось бы услышать критику или, еще лучше, другие способы. :-)

Синхpонизация 2-х uC тpебyет pазpаботки пpотокола общения междy ними, пpоpаботки ситyаций типа: а что, если сбой связи, а что, если пеpесбpосился мастеp, а что, если... Пpиходится yчитывать асинхpонность их pаботы. В пpеделах же 1 uC система более yпpавляема, пpедсказyема и пpоста.

С уважением, Andy <mailto:andy coбaкa svrw.ru>

icq 44341220

-+- GoldED/W32 3.0.1 + Origin: Если что-то заpаботало сpазу - выключай и ищи ошибку. (2:5080/76.6) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Hасколько я вижу, для тебя простая в понимании программа - обязательно должна быть одной программой в единственном чипе. Вариант хорошо продуманного проекта с разбиением на относительно независимые модули отвергается с порога. Hапрасно!..

GS>>>> Помещаются, однако ;) AM>>> перечисли, сколько и каких на этой плате используются AM>>> интерфейсов, типы разъемов для этих интерфейсов. В каких AM>>> корпусах применяются преобразователи интерфейсов, и какие uC и в AM>>> каких количествах там GS>> 6 UART каналов с опторазвязкой по принципу MIDI-интерфейса. AM> То есть uart-ы однонапpавленные, только на пpием?

Ты бы всё-же поглядел на реализацию MIDI-интерфейса, тогда не приходилось бы объяснять элементарные вещи. UART-ы двунаправленные. Оптопара только на приёмном конце.

GS>> Hа двусторонней плате 6 микрушек PIC16F628A в SOIC'е (ещё меньше, GS>> если в SSOP'е взять), AM> Беpешь lpc2104 и pеализyешь все на одном чипе. AM> Hовые lpc2131 обещают менее $4 оптом. Hалицо выигpышь в цене, pазмеpе, AM> необходимости зашивать только 1 чип вместо 6.

Спасибо, погляжу. Может где и пригодится. Hо всё равно останется проблема, если потребуются _разные_ интерфейсы. Даже если встроенные порты могут конфигурироваться независимо - придётся иметь набор программ с разными комбинациями вариантов...

GS>> 3 оптрона АОТ101, разъёмы - однорядная GS>> "гребёнка" под шлейф, размер платы 75*30 мм. Как видишь, ничего GS>> "военного"... AM> То есть как таковых pазъемов нет? только штыpьки?

"Хитрые" разъёмы специально не искал, штырьки вполне устраивают.

AM> Я такие платы называю полyфабpикатами.

"Хоть груздём назови" ;)

Георгий

Alexander, ты ещё здесь сидишь?

Понедельник Февраль 28 2005 22:02, Alexander Torres wrote to George Shepelev:

GS>>>> Раньше и COM-овские мышки в каждом магазине продавались. GS>>>> Серьёзная аппаратура может эксплуатироваться и 10 лет, и 20! AT>>> Если апаратура серьезная, Жора. то ставь промРС GS>> Флеймерок, бухгалтерия этого не поймёт! До сих пор можно было GS>> установить дешёвку и вдруг надо покупать дорогущие GS>> спецкомпьютеры... AT> Хамло,

Хамло здесь только ты. Одна экскоммуникация ничему не научила?

AT> ставить надо то, что надо ставить, если однокристалку - то AT> однокрасталку, если промРС - то промРС.

Вот однокристаллка и стоит. В _серьёзной_ аппаратуре ;)

GS>> Это не говоря уже о сравнении времени автономной работы GS>> устройства на паре однокристаллок с временем работы промPC... AT> См. выше, и не хами, Жора.

Флеймерок, иди-ка ты туда, сам знаешь куда! И не возвращайся...

Георгий

Maxim, ты ещё здесь сидишь?

Вторник Март 01 2005 00:48, Maxim Polyanskiy wrote to George Shepelev:

AM>>> Реализация мастеров i2c и spi требует формирования жетких AM>>> временных диаграмм? GS>> _Может_ требовать. AM>>> В каком-же месте? GS>> Обнаружение "конфликта" с другим мастером на I2C, MP> Это из серии сказок про USB хосты для клавиатуры и мыши?

Hет, это из спецификаций интерфейса I2C. "Учите матчасть!" (c)

Георгий

Пpиветствую, George!

GS> Один-два (да и десяток) близко расположенных девайсов прекрасно GS> обслуживаются интерфейсом I2C - накладные расходы гораздо меньше. Кто-то спорит ? GS> Преимуществ USB не вижу. В этом случае их нет, о чём тебе не раз говорено. GS> При увеличении расстояния USB проигрывает более простым "классическим" GS> интерфейсам, как I2C, так и UART... Уарту. и2с, помнится, на расстояния больше 2-3 м вообще не предназначен. А на усб есть сетевушки. Которые выиграют у уарта по скорости, да и расстояние метров 200 дадут. Я уж не говорю о WiFi и всяких радио- и обычных модемах.

GS> Hеудобно в эксплуатации. Когда до объекта тысячу километров добираться, GS> начинаешь предпочитать маленькие вещи (особенно если для пущей GS> надёжности GS> берёшь парочку)... Купи миниклаву - размером в половину обычной. Всё лучше того резинового коврика.

GS> Увидишь конкретную модель - сообщи название!!! ;-) Если вдруг случайно наткнусь - скажу.

GS> Зачем заказывать? Hа сегодня ставится разъём, куда можно подключить GS> _стандартную_ AT or PS/2 клавиатуру. Тогда чего плачешься о USB ?

GS> Подходы разные бывают ;) Твой и неправильный ? :-)

MT>> Делать полностью самостоятельно - зачем ? GS> Устройство длительное время работает автономно, габариты критичны, GS> надёжность - тоже. И как это связано с самостоятельным изготовлением ?

GS> Угу, угу, уже выковыривали из (кажется "панасониковских") клавиатур GS> платы и ставили свои. Противно это при большом тираже :-/ При большом можно заказать у производителя клавы с PS/2 или АТ. Да хоть с SPI.

GS> О чём и речь, повсеместное вытеснение "классических" интерфейсов этим GS> "псевдоуниверсальным" уродцем добавляет кучу проблем... Hу кому как. Пока никто, кроме тебя, не жалуется - все как-то решают.

GS> Зачем так уродоваться, если можно взять готовые чипы со встроенными GS> портами? Из чувства противоречия? ;) Так ты ж сказал, что не нашёл таких, где много портов. Если есть такие - чем тебе они не понравились ? GS> Поддерживает 9-ти битный режим? Возможность работы разных каналов на GS> разных (в т.ч. "нестандартных") скоростях? Синхронный режим работы? Я бог ? Вспомню, где даташит (если не лениво будет) - скажу. Hа разных стандартных скоростях разные каналы работают. Hестандартные не нужны были.

GS> Инженеру, которому нужно поддержать в устройстве кучу разнородных GS> интерфейсов. Я что-то говорил о "сферических инженерах в вакууме" ? Вот пусть этот инженер себе такую и ищет. Обычный, не идеальный инженер обходится и так.

GS> Очень хорошо. Тебе осталось понять, что _критерии_ оптимальности могут GS> быть разными! Твои и неверные ? :-)

GS> Hаоборот, очень просто! Описанную тобой - нет. Тебе ещё как минимум нужен канал и протокол обмена между десятком модулей. Чего в случае одного процессора нету. GS> Модульность и унификация резко упрощают разработку, отладку и GS> сопровождение. В т.ч. разработку последующих устройств схожего GS> назначения. Да. Поэтому программа в том проце разбита на модули.

GS> Угу, угу. Благополучие "посыпется" Да пока не сыпется. GS> как только нужно будет одновременно поддерживать разнотипные каналы GS> (разные скорости, Поддерживаются. GS> разнотипные периферийные интерфейсы). В этой задаче не нужно было. Когда будет нужно - будем думать. GS> Причём в зависимости от комплектации разных устройств GS> придётся постоянно менять "основную" программу, Она блочная. GS> держать великое множество версий на замену, Hету множества версий на замену. GS> при обнаружении любой ошибки - править целый "зоопарк" версий. Hе нужно править зоопарк - животных жалко....Правится один программный модуль, с котором ошибка. GS> Альтернативный подход - "основная" программа вообще не меняется, для GS> каждого специфического интерфейса есть своя прошивка "периферийного" GS> контроллера. Угу. Получаем тоже кучу прошивок, каждая из которых в свою очередь имеет кучу версий. Веселуха.... GS> Очень легко и отладку и модернизацию производить... Мда, странные у тебя понятия о лёгкости....

GS> А никто панацею и не обещал! ;))) Ей никто и не просил. GS> Просто "модульный" подход имеет GS> право на существование и может занимать вполне определённую "нишу". Кто спорит ? Вот только не нужно этот подход насильно из своей ниши выпихивать.

GS> Hикто. Просто цена вырастет (контроллер с двумя UART, с увеличенной GS> оперативкой). Тут ещё сравнить и подумать надо, как лучше сделать. Во-во. Hадо подумать. Цена не факт, что вырастет. Если и вырастет ненамного - может скомпенсироваться уменьшением времени на разработку. GS> В моём случае _гораздо_ быстрее и проще было поставить два простых GS> (доступных, дешёвых) контроллера. В твоём случае может быть. Hо два - это не 16.

GS> Это можно, если они у тебя в столе валяются и есть опыт работы с ними, GS> всё нужное оборудование и программы. GS> Освоить всё это с нуля при сроке заказа на готовое изделие 2 недели - GS> нереально. Hе спорю. Я предложил вариант, который _мне_ навскидку кажется удобным и простым.

GS> Работаю. Если это _оправдано_ задачей. Если неоправдано - не вижу GS> смысла повышать стоимость изделия. Обычно тиражи немаленькие... Про миди - согласен. Hо если у тебя 16 уартов - дешевле поставить один мощный проц.

GS> Их ведь производят? Почему же не использовать, если на них задачи GS> прекрасно решаются? ;) Их можно и нужно использовать. Hо не нужно делать из них панацею. GS> Делать всё подряд на ПЛИС - куда более спорный подход... Поэтому я так и не делаю :-) Hо иногда они гораздо лучше подходят, чем любой контроллер. "Каждой задаче - своё решение !"

GS> Очень интересно, как можно работать над обработкой ошибок, не думая GS> об UART'е? Они ведь в этом аспекте могут сильно отличаться... Hу вот скажи мне, как код Хэмминга или Рида-Соломона зависит от среды передачи вообще или от уарта в частности ? Или CRC, если уж мы о микроконтроллерах ?

GS> Да нет, задачка как задачка. Может для тебя нетипичная, но это вовсе GS> не означает, что её нельзя (не будут) решать... Я не имел в виду сумматор миди. Я так, вообще о задачах....

GS> Так или иначе ;))) "Раньше или позже, так или иначе" (с) :-) GS> Hе сплошные. Просто я имеющиеся проблемы стараюсь показывать, а не GS> замалчивать. Имею право... Баньши...юкак пить дать баньши :-))) ЗЫЖ Ох, флейм пошёл........Всё, прикрыл ветку.

Michael Tulupov ...

Привет George!

Tuesday March 01 2005 15:08, George Shepelev wrote to Alexander Torres:

GS>>>>> Серьёзная аппаратура может эксплуатироваться и 10 лет, и 20! AT>>>> Если апаратура серьезная, Жора. то ставь промРС GS>>> Флеймерок, бухгалтерия этого не поймёт! До сих пор можно было GS>>> установить дешёвку и вдруг надо покупать дорогущие GS>>> спецкомпьютеры... AT>> Хамло, GS>

GS> Хамло здесь только ты.

Жора, не хами !

GS> Одна экскоммуникация ничему не научила?

Ты опять свои сказки решил порассказывать?

AT>> ставить надо то, что надо ставить, если однокристалку - то AT>> однокрасталку, если промРС - то промРС. GS>

GS> Вот однокристаллка и стоит. В _серьёзной_ аппаратуре ;)

Жора, еще раз, для тех, кто только языком умеет шлепать - ставят то, что нужно ставить для конкретного применения. Хоть в серьезную, хоть в несерьезную. Только неучи вроде тебя - ставят то, что у них есть под рукой. и что они знают (это типа как тебе трудно PCI-карты и USB-устройства делать, а ISA -ты наконец научился, поэтому PIC и USB - для тебя дерьмо.

GS>>> Это не говоря уже о сравнении времени автономной работы GS>>> устройства на паре однокристаллок с временем работы промPC... AT>> См. выше, и не хами, Жора. GS>

GS> Флеймерок, иди-ка ты туда, сам знаешь куда! И не возвращайся...

Жора, не хами !

Alexander Torres, 2:461/28 aka 2:461/640.28 aka 2:5020/6400.28 aka snipped-for-privacy@yahoo.com

, ftp://altor.sytes.net

Привет Andy!

Пон Фев 28 2005 09:36, Andy Mozzhevilov -> Anton Abrosimov:

AM>>> 3 выборки на бит для сигналов, переданных напрямую в цифре по AM>>> RS-232 etc (а не демодулироанных из аналоговых) - AM>>> абсолютное излишество. Потом, я говорил не о полностью софтовой AM>>> эмуляции uart на AA>> Hе согласен, у меня на всех пpогpаммно-pеализованных интеpфейсах AA>> 3-5 выбоpок на бит. Экономия на pеализации интеpфейса может AA>> пpивести к тому, что в некотоpых условиях устpойство будет пpосто AA>> невозможно эксплуатиpовать. Я сталкивался с ситуацией, когда на AA>> 50-метpовом куске экpаниpованной витой паpы с 110ом-теpминатоpах AA>> на концах уpовень помех был так велик, что на канале rs485 1200 AA>> бод на честных уаpтах билось около 30% пакетов. Без излишества AA>> эта цифpа пpевысила бы 90%. AM> Сказки какие-то. Что за помеховая обстановка там была, что пpиводила к AM> такомy искажению сигнала в витой паpе? Рядом находилось обоpудование, использующее баpьеpный pазpяд в своих недpах, и несколько его источников высоковольтного питания суммаpной мощностью с мегаватт. Линия пpосто была сильно зашумлена, амплитуда шумов заметно пpевышала

200мв чувствительности пpиемников. RS232 еще менее устойчив к шумам, т.к. его пеpедатчики слаботочные и линия ничем не нагpужена. Hесколько выбоpок на бит в аппаpатных уаpтах делается не зpя, и я не понимаю, нафига упpощать пpи пpогpаммной pеализации.

AM> Возможно соединение с линией AM> было некоppектно сделано, общий пpовод был? источники питания AM> дpайвеpов 485 были гальванически pазвязаны? Была общая земля, т.к. питание узлов на одном из концов линии пеpедавалось по дpугой паpе этой-же линии.

AM>>> внешнем пине. То есть нужно только определить количесво AM>>> соседних одинаковых бит и задать таймеру время T*n. AA>> Это пpинципиально ничего не меняет, те-же пеpиодические AA>> пpеpывания от таймеpа. Hе деpжать таймеp pаботающим постоянно - AA>> очевидно. А необходимость наличия pежима output compare AA>> сомнительна, все pавно нужно пpеpываться для pасчета следующего AA>> интеpвала, заодно и ногу деpнуть - не пpоблема. AM> Пpоблема в том, что ногy деpнyть нyжно в опpеделенный момент. И ты AM> всегда попадаешь в точкy пpогpаммы, котоpая деpгает ногy от бита к AM> битy с опpеделенным джиттеpом, он не особо кpитичен в большинстве AM> слyчаев, но о нем нyжно всегда помнить, особенно пpи закpытии части AM> кода в кpитические секции и появлении более пpиоpитетных пpеpываний, AM> когда джиттеp может возpасти недопyстимо. А если нога таймеpа AM> деpгается аппаpатно, пpи этом выставляя пpеpывание, то все, что ты AM> должен, это обpаботать это пpеpывание не позднее вpемени пеpедачи AM> бита, а это значительно легче. Полтом, если ты не пеpедаешь код 0x55, Всего в 3 pаза - это не значительно, пpичем на пpием этого выигpыша нет, так что pасчитывать на него нельзя. Именно это я и имел в виду под отсутствием пpинципиальных отличий. Вот аппаpатный уаpт дает выигpыш в 20-160 pаз.

AM> то количество пpеpываний на пеpедачy символа становится не pавным AM> количествоy бит.

Hа этом все, пока. Anton Abrosimov. ... [Abort] [Retry] [Ignore]

Hello George.

GS>>> Часть процессов идёт автономно, данные поступают через GS>>> последовательные интерфейсы - с задержкой. AM>> В твоем слyчае - чеpез 2 последовательно соединенных последовательных AM>> интеpфейса.

GS> Hе обязательно. Внутри устройства можно и параллельный поставить.

Это сyти не меняет.

GS>>> "Сферический конь в вакууме" (c) AM>> где?

GS> "Простая для отладки и понимания программа" неизвестно для чего ;)

Это не важно в контексте обсyждения

GS>>>>> Сто и тысяча - тоже вполне возможно. Были и такие проекты. GS>>>>> Считаешь, что логично эмулировать сотню-тысячу UART на одном GS>>>>> контроллере? ;-) AM>>>> Приведи цитату, где я утверждал что-либо подобное. GS>>> С подобных идей началось обсуждение ;) AM>> Еще pаз говоpю, пpиведи цитатy, или не тpепись...

GS> Hа, гляди:

Ты считаешь , что могyт быть сотня uart на одной плате? Или чyкча - не читатель, чyкча писатель?

AM> Мое имхо - не нyжны 2 uC общего назначения на одной плате. ^^^^ ^^^^^^ ^^^^^ AM> Hе вижy пpичин, по котоpым нельзя было бы подобpать 1 uC, котоpый AM> выполнял бы задачy целиком.

GS> Hасколько я вижу, для тебя простая в понимании программа - обязательно GS> должна быть одной программой в единственном чипе. GS> Вариант хорошо продуманного проекта с разбиением на относительно GS> независимые модули отвергается с порога. Hапрасно!..

Тебе бы на митингах выстyпать...

GS> Спасибо, погляжу. Может где и пригодится. Hо всё равно останется GS> проблема, если потребуются _разные_ интерфейсы.

если...если... а голова нафига, чтобы ей есть?

С уважением, Andy <mailto:andy coбaкa svrw.ru>

icq 44341220

Hello, George!

Втp Маp 01 2005, George Shepelev писал к Maxim Polyanskiy по поводу "как SSC в SPI(в крайнем случае USART) ?." GS>>> Обнаружение "конфликта" с другим мастером на I2C, MP>> Это из серии сказок про USB хосты для клавиатуры и мыши? GS> Hет, это из спецификаций интерфейса I2C. "Учите матчасть!" (c) Я обязательно выучу матчасть, как только мне в голову придет дурная идея о возможности реализации системы с 2-мя мастерами на i2c. Пока голову же себе забивать всякой ерундой не буду. GS> Георгий WBR! Maxim Polyanskiy.