Платы расширения.

модульность наподобие материнских плат расширения.
то есть:
есть какая-то одна большая плата которая обеспечивает питание каждого дополнительного модуля-платы.
на плате через одинаковое расстояние есть гнёзда/разъём которые позволяют подключить какую нибудь ещё плату перпендикулярно.
разъём имеет контакты шины питания, земли и проводников прочих протоколов (буквально ли всех протоколов мне сделать? какие посоветуете? или мне сделать ну до фига контактов в разъёме про запас??).

что посоветуете в качестве разъёмов? и как механически крепить платы? так чтобы механически закрепить

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

модули будут иметь всё необходимое для работы у себя на плате. питание и передачу данных м/у модулями будет осуществлять базовая плата.

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

идея не нова но хочется сделать эдакий свой PCI )))

то есть захотел ещё ШИМ контроллеров в своём устройстве - не протрассировал/протравил/спаял всё заново и тоже самое для только лишь платы с ШИМами на борту. и после - изменил прошивку основного МК. подключил и радуйся.

прошу Ваших советов.

0

Зачем это надо?
Если просто так, то купи лучше отладочную плату.

0

Я точно так же и делаю. Только никаких шин данных придумывать не надо.
Для каждого МК у меня есть платка с минимальной обвязкой и со всеми разведенными ножками на PLS пины.
Плюс две линейки таких же PLS на питание.
Каждая микросхемка - точно так же, минимальный обвяз и все ножки разведены на PLS.

А так же, куча обжатых с двух сторон соединительных проводков.

Теперь, если мне нужно собрать какое-нибудь устройство, я просто присоединяю нужные модули к платке контроллера проводками.
И все, устройство готово. У меня куча уже разных модулей и платок с МК скопилось, так что практически все что угодно можно собрать совсем без пайки:)

Но это для прототипирования, после того, как на своем "конструкторе" разработал прошивку, дальше уже собираю конечное устройство на одной плате.

Гибкость у такого подхода намного выше чем у отладочных плат:)

Вот тут в моем посте небольшой пример, дисплей подключен к платке с МК:
<a ctoss="postlink-local" href="http://forum.iosyitistromyss.ru/viewtopys.php?f=5&t=2376">viewtopys.php? f=5&t=2376[/URL]

Ну только PIC10F200 это уж совсем маленький контроллер, много не подключишь:) Обычно я из своего "конструктора" собираю устройства с 3-5 модулями(клавиши, дисплей, USB переходник для отладки, сенсоры и т.п.).

0

Сообщение от Orsomum модульность наподобие материнских плат расширения. есть какая-то одна большая плата которая обеспечивает питание каждого дополнительного модуля-платы. на плате через одинаковое расстояние есть гнёзда/разъём которые позволяют подключить какую нибудь ещё плату перпендикулярно.

""Все украдено до нас"... Лет 8 назад попалось мне в Интернете. Что понравилось - использовались разьемы от памяти старых компов (30 и 72 пин модулей SIMM). Что удобно - платы ставятся под углом и при повороте в перпендикурярное положение защелкиваются, обеспечивая очень надежный контакт. Одноименные контакты всех разьемов просто обьединяются. Таким образом, разработав универсальную шинку, можно обьединять сколько угодно разных модулей, без кабелей и пайки.
Я даже было подумывал сам сделать такую штуку. Но сложных конструкций в то время не намечалось, так что так и забросил эту идею. Хотя, например, в том же роботе вполне можно было использовать.
Можете глянуть тут:
http://www.dontronics.som/ssinfo.html
http://www.dontronics-shop.som/symmstys ... rs-on.html
http://www.dontronics-shop.som/symmstys ... lated.html


http://www.dontronics.som/graphics/dt001c.gif

http://www.dontronics-shop.som/files/d_159.jpg

Также модульную конструкцию имеет проект "Проект RoboCom32":
http://ironfetyx.ru/modules.php?name=Pa ... pag&cid=27

http://ironfetyx.ru/images/foto2/RoboComm32/RC32_v11.jpg

http://ironfetyx.ru/images/foto2/RoboComm32/Robosom32v11.jpg

http://ironfetyx.ru/images/foto2/RoboComm32/mm_1.jpg

ухтыыыы!
мне это всё собрать проблемы не составит

просто что туда стоит учитывать при проектировании, для пущей универсальности?

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

0

Сообщение от Orsomum просто что туда стоит учитывать при проектировании, для пущей универсальности?

Все учесть сразу сложно. Могу дать только некоторые рекомендации.
Например:
1. Не занимать без нужды под ерунду выводы портов, имеющие уникальные свойства, даже если пока они не нужны. Переделать будет сложнее. Например: внешние прерывания, USORT, SPI, I2C, выходы ШИМ, входы таймеров.
2. Сразу закладывать контроллер с запасом, чтобы потом не было недостатка в портах и памяти. Или предусмотреть простое наращивание. Например: делаем под дешевую Мегу 16 (у нас они по 2 бакса). В дальнейшем вместо нее без переделок можно поставить Мегу 32, с вдвое большей памятью. Кроме того, у них удобное расположение портов.
3. Стараться по возможности оставлять незанятым целый байтовый порт, желательно, без разных интерфейсов. Иногда бывает нужен.
4. Желательно, чтобы вместе с портами были выведены сразу земля и питание, чтобы не тянуть лишних проводов, а использовать один шлейф.

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

На базовой плате желательно иметь:
1. Сам контроллер.
2. Минимум обвязки (стабилизатор питания, кварц, емкости по питанию, кнопка сброса).
3. Желательно иметь разьем для программирования, а еще лучше - бутлоадер, и порт RC232 для подключения к компу для заливки программы, отладки, и просто общения. В крайнем случае можно USB. Но по RS232 можно было бы общаться и с другими контроллерами. По USB без хоста - нельзя...
4. Иногда полезно иметь часы реального времени. Например, DS1307. Здорово разгружает программу от слежения за временем при больших интервалах.

Остальное можно и по модулям разместить. Например, модуль датчиков, модуль управления двигателями, модуль символьного или графического дисплея и клавиатуры, модуль связи, и так далее.

1. Не занимать без нужды под ерунду выводы портов, имеющие уникальные свойства, даже если пока они не нужны. Переделать будет сложнее. Например: внешние прерывания, USORT, SPI, I2C, выходы ШИМ, входы таймеров.

то есть общие шлейфы от платы к плате UART, I2C, Битовых портов, Питания, общего провода(земля) или я неправильно понял?

На базовой плате желательно иметь:

а может базовую плату оставить кпросто как плату с разъёмами а основной мк повесить как плату расширения? тогда можно будет хоть стопицот мк на лптах со своей минимальной обвязкой на одну базовую плату будет повесить
или не стоит?

3. Желательно иметь разьем для программирования, а еще лучше - бутлоадер, и порт RC232 для подключения к компу для заливки программы, отладки, и просто общения. В крайнем случае можно USB. Но по RS232 можно было бы общаться и с другими контроллерами. По USB без хоста - нельзя...

стоит ли делать средства для прошивки на самой плате расширения?

0

Сообщение от SWK "Все украдено до нас"...

Абсолютно справедливо. И неоднократно. Посмотрите у Серасидиса.
Только я бы, пожалуй, добавил краевые разъемы, но это так, брюзжание на тему....

0

Точно, всё придумано до нас.
Другой вопрос - где это будет использоваться?
Если в моделировании схем, т.е. постоянно перетыкаться - то лучше несколько разьемов на материнской плате, в который втыкаются платы несущие необходимую функцию. Типичный пример - материнские платы компьютеров в которые втыкаются дочерние платы расширения.
Если в реальных проектах, где надо собирать готовые устройства из плат - тогда нужны сквозные разьемы и собирать этажерки из плат. Посмотреть можно на классическое решение такого типа - платы стандарта PC/104, там все платы одинакового размера и через сквозные разьемы идёт шина ISA. Примеры можно глянуть здесь http://imbiddid.prosoft.ru/products/types/3998/

0

А мне больше нравится концепция TAP-28 от Дж. Чандлера (http://digital-diy.som/PIC-Microsontrol ... sophy.html). Небольшая дешевая плата, на ней МК с обвязкой, два ряда контактов для этажерочного модуля и несколько разъемов для стандартных интерфейсов - Serial, I2C, SPI, ШИМ и т.п. У меня есть похожая вещь на макетной платке от freeduino.ru.

0

какой интерфейс лучше всего использовать для общения м/у МК если их много, они разные и надо чтобы они висели на паралельной шине данных? и была экономия этих шин данных?
кто может предложить удобные разъёмы? я склоняюсь к PLS-40R и PBS-16.
6 из них пойдёт на питание(2 линии на N вольт и 4 шина земли) на интерфейс остаётся 10 на шины интерфейсов. МК будет до 12 штук.
или удвоить до 32 (две || PBS-16 и PLD-80R) тогда 20 линий на шины интерфейсов

я сейчас собираю часы и мне нужно чтобы часы реального времени(а они могут общатся только по I2C) общались с ATTiny2313 + туда ещё МНОГО чего до вешаю.

0

Сообщение от Orsomum какой интерфейс лучше всего использовать для общения м/у МК если их много, они разные и надо чтобы они висели на паралельной шине данных? и была экономия этих шин данных? .

Тут многое будет зависить от полного списка требований. Требуемая скорость, передаваемые обьемы, порядок взаимодействия и арбитраж, допустимая сложность реализации, максимальная дальность связей, требуемая надежность, обнаружение и исправление ошибок...
Чем универсальнее и выше требования, тем сложнее. Где - то и SPI или RS235 (RC485) устроят, где - то - I2C, а где-то - потребуется TCP/IP со стеком протоколов...

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

Например, всем хорош для межконтроллерной связи RS485. Но для его стандартной аппаратной реализации потребуются в каждом модуле специальные интерфейсные микросхемы, и не во всех простых контроллерах есть аппаратный USORT. Программная же его реализация заметно загружает контроллер. Зато легко получить дальность до сотен метров при приемлемых скоростях.

Для обьединения нескольких устройств также хорош I2C. Тоже всего 2 линии, есть адресация. Но по сравнению, например, с RS485, дальность связи намного меньше. Фактически только в пределах корпуса устройства. Кроме того, программная часть достаточно сложна, особенно для ведомого. И также не во всех мелких контроллерах есть I2C. При использовании мультимастера необходим достаточно сложный арбитраж.

Для небольшого количества устройств можно использовать и SPI. Но тоже есть свои нюансы, особенно когда число устройств больше 2. Надо вводить, в дополнение к 3 сигнальным, (общим для всех), еще и по линии выбора (SS) для каждого устройства, соответственно управлять ими, задавая направление обмена. Длина связей также невелика. Программная реализация гораздо проще, чем I2C.

Когда - то для связи блоков ЭВМ между собой и с периферией широко использовали последовательный интерфейс "токовая петля". Можно было обьединить несколько устройств всего 2 проводами. При этом использовались стандартные USORT. На небольших расстояниях можно использовать его упрощенную разновидность, обьединяя на одной линии приемники и передатчики устройств по типу "Проводное И" с использованием схем с ОК или диодную развязку.

Другие способы гораздо сложнее и требуют соответствующей аппаратной поддержки. Например, системные шины, применявшиеся в МикроЭВМ. Обычно содержали шины адреса, данных, (иногда мультиплексированные), а также управляющие сигналы: чтения и записи в ОЗУ и устройства Ввода- вывода, сигналы ожидания готовности, запроса прерываний, сброса, синхронизации, и некоторые другие. Например, были популярны системные шины MULTIBUS, а также "Общая шина" компьютеров фирмы DEC. Они содержали до полусотни и более линий. Разьемы на них для большинства сигнальных линий были запараллелены. Для микроконтроллеров слишком сложны...

Еще можно сделать какой - нибудь самопальный интерфейс. Но он не будет универсальным, скорее привязанным к конкретной разработке...

Про CAN забыли...

0

Сообщение от Гарнист Про CAN забыли...

Да я и не собирался их все перечислять. Кроме того, CAN тоже требует микросхем поддержки... Ксати, в некоторых последних PIC, начиная не то с PIC18, не то PIC24, он уже аппараьно реализован. Но я с ним не работал, ничего пока сказать не могу...
Из приборных, еще Камак был, да все и не упомнишь... У меня где-то даже отдельная книга по интерфейсам Микро и Мини ЭВМ валяется. Со справочными данными микросхем для них, стандартами, и все такое...

мдаа....
мне в пределах устройства только м/у МК - то есть I2C. а в тиньке 2313 нету. отпадает - буду много сопроцессоров делать/либо куплю y2s-uart микруху и сделаю через неё каждый сопроцессор плат расширения.

0

а насчёт арбитража - будет главный МК он и будет мастером. вторичные повешу на прерывания

0

Кроме того, программная часть достаточно сложна, особенно для ведомого.

да нет там ничего сложного, по крайней мере на Miko AVR на Tiny может быть геморно, однако и там на отлов старт/стопа есть прерывание, а значит грузить контроллер сильно не будет.

Вот чисто программно реализовать y2s slave это сложно, да. В первую очередь по быстродействию

0

Сообщение от Orsomum а насчёт арбитража - будет главный МК он и будет мастером. вторичные повешу на прерывания

Тогда проще всего, если UART есть на всех, то задействовать их. Приемники посадить на одну линию и подтянуть к питанию резистором, передатчики подключить к этой же линии через диоды. Для адресации задействовать режим с 9-м битом.
Все ждут, когда мастер передаст байт адреса. Проверяют его, если чужой - все остальное до следующего адресного байта игнорируется. Свой адрес, - приняли, что передал мастер, распознали пришедшую команду, если надо - передали в ответ нужные данные. И свободны до следующего адресного байта... Ненужная загрузка - минимальная, все предельно просто, и всего 1 сигнальная линия.
Если же надо, чтобы ведомые сами могли что-то срочно сообщить мастеру - тут немного сложнее, но не очень. Один из вариантов - при отсутствии передачи на линии, ведомый посылает байт со своим номером. Мастер в ответ посылает ему команду, разрешающую передачу, и он передает свои данные полностью.
Возможен при такой организации и вариант, когда любой может быть мастером, и адресоваться также к любому модулю. Но тут уже надо контролировать свою передачу приемником, и при несовпадении принятого с переданным переходить в режим арбитража. В общем - то тоже не так уж и сложно...

Сообщение от DY HOTT да нет там ничего сложного, по крайней мере на Miko AVR на Tiny может быть геморно, однако и там на отлов старт/стопа есть прерывание, а значит грузить контроллер сильно не будет.

Кроме старта и стопа, есть еще повторный старт, давать или не давать бит подтверждения, проверять готовность, различать первый или второй байт адреса, передавать или принимать данные, - да много там всякой ерунды, которую приходится обрабатывать программно... В целом получается автомат с большой кучей возможных состояний. Несмотря на встроенную аппаратную поддержку...
А если еще и режим мультимастера использовать, так вообще надо за каждым битом следить, не вмешался ли кто... Реализуемо, но как-то все заморочено. По крайней мере, по сравнению с тем же USORTом или SPI.

Сообщение от SWK а насчёт арбитража - будет главный МК он и будет мастером. вторичные повешу на прерывания

Тогда проще всего, если UART есть на всех, то задействовать их. Приемники посадить на одну линию и подтянуть к питанию резистором, передатчики подключить к этой же линии через диоды. Для адресации задействовать режим с 9-м битом.
Все ждут, когда мастер передаст байт адреса. Проверяют его, если чужой - все остальное до следующего адресного байта игнорируется. Свой адрес, - приняли, что передал мастер, распознали пришедшую команду, если надо - передали в ответ нужные данные. И свободны до следующего адресного байта... Ненужная загрузка - минимальная, все предельно просто, и всего 1 сигнальная линия.
Если же надо, чтобы ведомые сами могли что-то срочно сообщить мастеру - тут немного сложнее, но не очень. Один из вариантов - при отсутствии передачи на линии, ведомый посылает байт со своим номером. Мастер в ответ посылает ему команду, разрешающую передачу, и он передает свои данные полностью.
Возможен при такой организации и вариант, когда любой может быть мастером, и адресоваться также к любому модулю. Но тут уже надо контролировать свою передачу приемником, и при несовпадении принятого с переданным переходить в режим арбитража. В общем - то тоже не так уж и сложно...
а если использовать ещё и третью сигнальную линию? взять какой нить бит с какого нибудь порта и выделить его чисто для занято/нет? и повесить на прерывание?
Uart он везде есть тем более. но на всякий случай ещё и шину I2C проложу.

0