Технический форум по робототехнике.
=DeaD= » 28 мар 2009, 23:11
Контроллер в дип-корпусах, постараемся минимизировать SMD-компоненты. Основная фишка - чтобы можно было поставлять незапаянным, на чем сильно экономить.
Видимо от 741G66DBV отказаться надо, и вообще чтобы все компоненты были распространенные, чтобы можно было самим сделать такую плату.
Вот начал рисовать.
На базе АТМега8/168, 8 портов GPIO из которых 4 штуки - входы АЦП, на борту порт ДД.
- Вложения
-
- OR-AVR-M8-DX.zip
- (59.92 КиБ) Скачиваний: 17
=DeaD= » 01 апр 2009, 00:34
Рабочая версия
- Вложения
-
- OR-AVR-M8-DX-sch.pdf
- (38.89 КиБ) Скачиваний: 54
-
- OR-AVR-M8-DX-brd.pdf
- (52.92 КиБ) Скачиваний: 41
-
- OR-AVR-M8-DX.zip
- (68.1 КиБ) Скачиваний: 17
=DeaD= » 01 апр 2009, 12:34
Замечание - регуляторы напряжения продублированы в 2 видах корпусов с порядком ног [VIN,GND,VOUT] и [GND, VOUT, VIN].
Добавлено спустя 3 часа 35 минут 13 секунд:Что - вообще ни у кого никаких замечаний?
frig » 01 апр 2009, 12:40
ну вопросы стандартные - цена не запаянной платы, цена платы с вложенными компонентами, отличия от стандартного контроллера, совместимость (т.е. смогу ли я потом выкинуть этот контроллер, купить другой контроллер OR и залить старый код)
=DeaD= » 01 апр 2009, 12:44
1. По цене платы и набора еще не считали, но безусловно будет ощутимо дешевле готового смонтированного и протестированного модуля на более мощном МК;
2. Отличия от стандартного контроллера по функционалу - 8 портов GPIO вместо 16, 2 порта I2C вместо 4, МК с меньшим объемом памяти (ATMega8/168), хотя основной функционал сохранён - есть разъемы под двойные энкодеры, есть порт ДД (правда только основные линии), есть светодиоды которыми можно помигать для отладки, есть переключатель напряжения 2 линии портов GPIO (правда уже один).
3. Форм-фактор и основные разъемы сохранены, т.е. переход на другой контроллер будет достаточно безболезненный, особенно если использованы прошивки шлюз-контроллера, тогда только адреса устройств GPIO переписать и всё.
4. Старый код залить не получится - разные МК, ну и вообще разный набор портов и т.п.;
frig » 01 апр 2009, 12:49
то, что программно несовместимы - плохо
понятно, что портов меньше, но если бы хотябы в пределах этого количества сделать совместимость, чтобы снизу вверх хотябы совместимость была. а так получается модуль особняком.
blindman » 01 апр 2009, 12:54
На уровне исходных кодов минимальную совместимость я думаю обеспечить можно
=DeaD= » 01 апр 2009, 13:42
frig писал(а):то, что программно несовместимы - плохо
понятно, что портов меньше, но если бы хотябы в пределах этого количества сделать совместимость, чтобы снизу вверх хотябы совместимость была. а так получается модуль особняком.
Так ну не делать же МК на SMD-версии такой же как и в DIP только потому что в DIP-версии не влезает больший МК?
Добавлено спустя 42 секунды:blindman писал(а):На уровне исходных кодов минимальную совместимость я думаю обеспечить можно
Реально думаю будет написать рекомендации, как писать код для МК, легко адаптируемый к любому МК из семейства.
Добавлено спустя 44 минуты 13 секунд:2frig: Ну и вообще - мы же не сказали, что у нас будет ровно 1 контроллер с 1 набором периферии и с ним всё совместимо на 100% - это значит ограничить развитие системы немедленно. А нам это не нужно, у нас как раз модульная система в которой фишка - это не обратная совместимость главного модуля, а просто совместимость модулей между собой при соблюдении стандартов на интерфейсы.
frig » 01 апр 2009, 16:18
надо и в сторону программной совместимости тоже двигаться. или написать уровень абстракции от оборудования, чтобы манипулировать не адресами портов а их алиасами. сменил шапку - твой код работает на другой платке.
это сумбурно и больше смахивает на псевдокод
, но смысл, думаю, понятен
=DeaD= » 01 апр 2009, 16:20
Если бы у нас в МК всё было так волшебно и вся периферия ограничивалась портами GPIO - конечно, но грабли в том, что там до кучи другой периферии - таймеры, счетчики, интерфейсы, внешние прерывания и т.п. Всё это сугубо индивидуальное для каждого МК.
frig » 01 апр 2009, 16:24
я ж и говорю - думать и двигаться.
=DeaD= » 01 апр 2009, 16:31
А есть вообще смысл думать о портируемости программного кода специфичного? Имхо надо просто культуру развивать написания кода под МК. Когда логика программы не перемешана с работой с периферией, таймерами и прерываниями. Тогда адаптация будет простой, всё остальное мне кажется - излишества.
Добавлено спустя 3 минуты 19 секунд:
Вообще мне не верится, что кто-то всерьез будет брать огромную прошивку и куда-то портировать без переписывания 30-50% кода для адаптации под новые возможности и т.п. - иначе зачем переходим?
blindman » 01 апр 2009, 16:52
Почему я и говорю - минимальная совместимость. То есть то, что можно обеспечить на уровне макросов и простейших функций. Тогда подменив один заголовок, можно часть работы по переносу кода исключить. Ну а остальное - ручками. Конечно, при условии "культуры написания кода".
Duhas » 01 апр 2009, 17:46
на счет адаптации кода, вам бы может свои хидеры сделать, с редефайном портов... чтобы в старших версия просто появлялись новые порты....
=DeaD= » 01 апр 2009, 18:28
2Duhas: Можно конечно, вообще масса вариантов есть, главное чтобы задача была реальная, а не надуманная, а то вдруг никто не будет портировать свой код?