Занимаюсь на любительском уровне, отсюда и вопросы. Не знаю как реализовать код.
1) Имеем к примеру контроллер атмега, разведенный на N одинаковых слотов, по 3 порта на слот. платформа1_слот1_пин1 - PORTA.1, платформа1_слот1_пин2 - PORTA.2, платформа1_слот1_пин3 - PORTA.3 платформа1_слот2_пин1 - PORTC.1, платформа1_слот2_пин2 - PORTC.2, платформа1_слот2_пин3 - PORTC.3
2) Имеем к примеру модуль, который можно вставить в любой слот и у модуля есть 3 пина модуль1_пин1 - CLOCK, модуль1_пин2 - DATA, модуль1_пин3 - CS
Как через директивы, указатели или что-то еще реализовать инициализацию типа: #define платформа1, т.е. обозначить что используется именно такая платформа, где-то инклуде прописаны все имеющиеся в ней слоты и их порты #define слот1 модуль1, т.е. указать что в слоте 1 этой платформы стоит именно этот модуль1, в инклуде которого также прописано соответствие пинов и назначение
Чтобы в результате CLOCK, DATA и CS заменялись компилятором на соответствующие порты. В идеале, также чтобы и конфигурирование портов на вход/выход и подтяжки сразу производилось. Чтобы не заниматься кофигурированием вручную.
Хотя бы направление подскажите: директивы, указатели, структуры или что там еще, почитаю. Про указатели читал, но так и не догнал до конца принцип.
делаете нужное количество заголовков platformx.h, в которых описываете одинаковые макросы CLOCK, DATA и т.п. с разными пинами, портами и т.п. штуками, а потом перед указанным кодом просто описываете макрос для нужной в текущий момент платформы типа так #define PLATFORM3
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
В идеале, также чтобы и конфигурирование портов на вход/выход и подтяжки сразу производилось. Чтобы не заниматься кофигурированием вручную.
А вы в дефайнах определяете нужные порты и пины, как ARV подсказал вам. А уже дальше их конфигурируете в .c файле уже по именам, заданных в .h, которые разные через #ifdef. Главное не конфигурируйте в .h файлах - плохая практика.
если в коде применяется только одна платформа, и смешение платформ никогда не предусматривается, то все элементарно....
Спасибо за ответ Но, или я не понял ответа, или вы - задачу. Ваше решение - это лишь часть требуемого функционала.
Смешение платформ не предусматривается, как определить платформу через define и описать набор ее портов я понимаю.
Я ищу решение другой задачи: - у платформы i слотов; - у меня есть j типов разных модулей. Соответственно на базе одной платформы я могу собрать любую комбинацию, хоть 10 одинаковых модулей, хоть 10 разных. Соответственно, если по простому описывать, мне нужно втупую расписать все возможные комбинации в каждом хэдере на платформу, что грустно.
Я пытаюсь найти решение, которое позволит связать: -тип платформы; -тип модуля; -позицию установки модуля; воедино, тем самым автоматически определив на какой порт контроллера приходится какой пин исполнительного устройства в модуле.
Если 10 модулей будут одинаковые, полагаю буду оперировать функцией, которая требует указания номера модуля, к которому идет обращение.
Сейчас мысль посетила: Попробую определить все поле платформы как двумерный массив пинов слотов. Далее к каждому элементу массива прописать конкретный порт атмеги. Далее при инициализации какого-то типа модуля указывать номер слота в который его включить. И далее уже математическими методами связать конкретные функциональные ножки модуля с конретными портами контроллера через этот массив....
я и в самом деле не очень понял, что вы там затеваете. но предполагал так: 1. материнская плата у вас имеет порты, условно именованные P1, P2 и т.д. 2. навесные модули у вас имеют свои входы-выходы, именованные как-то типа IN1, IN2, OUT1, OUT2... 3. каждый навесной модуль имеет свой заголовочный файл, где константе IN1 задается "символьное" название сигнала материнской платы P1 4. в коде вы работаете только с символами модуля, который в текущей конфигурации выбран, то есть как бы пишите код под модуль, а то, как с ним работает материнская плата, получается автоматически.
в этом случае для модуля "радио" линии SDA и SCL будут определены, например, как P1 и P2. а для модуля "термодатчик" - те же самые SDA и SCL будут уже P3 и P4. код для работы с I2C всегда будет использовать SDA и SCL, но в зависимости от того, какой модуль вы "надели" на материнку, физическая работа будет вестись именно с теми пинами, которые нужны модулю.
Добавлено after 3 minutes 27 seconds: и еще: чем универсальнее решение, тем неудобнее им пользоваться на практике
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
// A majority of the pins are NOT PCINTs, SO BE WARNED (i.e. you cannot use them as receive pins) // Only pins available for RECEIVE (TRANSMIT can be on any pin): // (I've deliberately left out pin mapping to the Hardware USARTs - seems senseless to me) // Pins: 10, 11, 12, 13, 50, 51, 52, 53, 62, 63, 64, 65, 66, 67, 68, 69
Ес-но всё это несет накладные расходы. И вычитывание номера порта, пина и т.д. каждый раз при обращении к нему по виртуальному номеру. В отличии от #define'ов, предложенных выше. Но если вы хотите динамически в одном и том же назначать разную привязку порт-функционал, то от подобных расходов не уйти конечно.
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
