Разработка Open Robotics: Эконом. контроллер общ. назн., DIP

=DeaD=

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

Видимо от 741G66DBV отказаться надо, и вообще чтобы все компоненты были распространенные, чтобы можно было самим сделать такую плату.

Вот начал рисовать.

На базе АТМега8/168, 8 портов GPIO из которых 4 штуки - входы АЦП, на борту порт ДД.

=DeaD=

Рабочая версия

=DeaD=

Замечание - регуляторы напряжения продублированы в 2 видах корпусов с порядком ног [VIN,GND,VOUT] и [GND, VOUT, VIN].

Добавлено спустя 3 часа 35 минут 13 секунд:
Что - вообще ни у кого никаких замечаний? :shock:

frig

ну вопросы стандартные - цена не запаянной платы, цена платы с вложенными компонентами, отличия от стандартного контроллера, совместимость (т.е. смогу ли я потом выкинуть этот контроллер, купить другой контроллер OR и залить старый код)

=DeaD=

1. По цене платы и набора еще не считали, но безусловно будет ощутимо дешевле готового смонтированного и протестированного модуля на более мощном МК;

2. Отличия от стандартного контроллера по функционалу - 8 портов GPIO вместо 16, 2 порта I2C вместо 4, МК с меньшим объемом памяти (ATMega8/168), хотя основной функционал сохранён - есть разъемы под двойные энкодеры, есть порт ДД (правда только основные линии), есть светодиоды которыми можно помигать для отладки, есть переключатель напряжения 2 линии портов GPIO (правда уже один).

3. Форм-фактор и основные разъемы сохранены, т.е. переход на другой контроллер будет достаточно безболезненный, особенно если использованы прошивки шлюз-контроллера, тогда только адреса устройств GPIO переписать и всё.

4. Старый код залить не получится - разные МК, ну и вообще разный набор портов и т.п.;

frig

то, что программно несовместимы - плохо :-(

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

blindman

На уровне исходных кодов минимальную совместимость я думаю обеспечить можно

=DeaD=

frig писал(а):

то, что программно несовместимы - плохо :-(

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

Так ну не делать же МК на SMD-версии такой же как и в DIP только потому что в DIP-версии не влезает больший МК?

Добавлено спустя 42 секунды:

blindman писал(а):

На уровне исходных кодов минимальную совместимость я думаю обеспечить можно

Реально думаю будет написать рекомендации, как писать код для МК, легко адаптируемый к любому МК из семейства.

Добавлено спустя 44 минуты 13 секунд:
2frig: Ну и вообще - мы же не сказали, что у нас будет ровно 1 контроллер с 1 набором периферии и с ним всё совместимо на 100% - это значит ограничить развитие системы немедленно. А нам это не нужно, у нас как раз модульная система в которой фишка - это не обратная совместимость главного модуля, а просто совместимость модулей между собой при соблюдении стандартов на интерфейсы.

frig

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

это сумбурно и больше смахивает на псевдокод

, но смысл, думаю, понятен

=DeaD=

Если бы у нас в МК всё было так волшебно и вся периферия ограничивалась портами GPIO - конечно, но грабли в том, что там до кучи другой периферии - таймеры, счетчики, интерфейсы, внешние прерывания и т.п. Всё это сугубо индивидуальное для каждого МК.

frig

я ж и говорю - думать и двигаться.

=DeaD=

А есть вообще смысл думать о портируемости программного кода специфичного? Имхо надо просто культуру развивать написания кода под МК. Когда логика программы не перемешана с работой с периферией, таймерами и прерываниями. Тогда адаптация будет простой, всё остальное мне кажется - излишества.

Добавлено спустя 3 минуты 19 секунд:
Вообще мне не верится, что кто-то всерьез будет брать огромную прошивку и куда-то портировать без переписывания 30-50% кода для адаптации под новые возможности и т.п. - иначе зачем переходим?

blindman

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

Duhas

на счет адаптации кода, вам бы может свои хидеры сделать, с редефайном портов... чтобы в старших версия просто появлялись новые порты....

=DeaD=

2Duhas: Можно конечно, вообще масса вариантов есть, главное чтобы задача была реальная, а не надуманная, а то вдруг никто не будет портировать свой код?

roboforum.ru

Правила форума

Разработка Open Robotics: Эконом. контроллер общ. назн., DIP

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