caxapa.ru :: Кажись по второму кругу пошли... Ниже в топике уже вроде все обсудили. Во флеш параметр запишет сама программа, длину записи можно указать внутри самой записи.

LightElf (02.10.2015 18:33, просмотров: 127) ответил abivan на длина записи фиксированная? А во флэш то кто параметр запишет? Или компилятор положит в константную секцию по фиксированному адресу?. А искать нужную строку как(как выбрать нужный параметр)?

Кажись по второму кругу пошли... Ниже в топике уже вроде все обсудили. Во флеш параметр запишет сама программа, длину записи можно указать внутри самой записи. В принципе, задача может быть несколькими способами решена. Можно завести глобальный хидер, в котором определить enum со всеми возможными видами параметров (так сейчас и сделано). А можно посчитать хэш от названия параметра. Можно наверно еще как-то извернуться. Вопрос изначально был в том, как заставить компилятор заменить строковый литерал на хэш от этого литерала прямо на этапе компиляции, чтобы строка в бинарник вообще не попадала. Решение, как ни удивительно, нашлось. Более того, нашлась такая фичастая штука как Boost.preprocessor. Сейчас пытаюсь осмыслить, насколько оно может быть полезно.

Не надо делать мне как лучше, оставьте мне как хорошо

Ответить

- Да пофиг нам решение, разбираемся, зачем оно! ;) Если хочется строки, то понятно, есть открытые исходники для обработки init-файлов. Хочется енумы, еще более понятнее, сам так делаю. Промежуточное - не понимаю. Но ладно, проехали. - VL(02.10.2015 18:45, )
  - Если совсем коротко - заколебало вести глобальный хидер с енумом. - LightElf(02.10.2015 18:49)
    - ~~Утки!~~ Х-макросы - VL(02.10.2015 18:54, )
      - Ну вот собственно и нашел в конце-концов решение в виде: LightElf(571 знак., 02.10.2015 19:01 - 19:06)
        
        Вам виднее, но по моему, с точки зрения документирования проекта, это тихий ужас. Тем более что Хэш не гарантирует уникальности. - Скрипач(02.10.2015 20:29)
        
        С точки зрения документирования, да и вообще сопровождения, проекты в одном workspace (термины IAR) - вообще ( . ). Не далее, как вчера, сам огрёб. - VL(03.10.2015 06:32, )
        
        А зачем их делать в одном workspace? А че делать, если используются разные компиляторы под разные процессоры? - LightElf(05.10.2015 08:37)
        
        Потому что код совпадает на 2/3. А если разные компиляторы под разные процессоры, тоже есть варианты, но это уже притянуто за уши. А workspace - не притянут. - VL(05.10.2015 16:50, )
        
        Ничего не притянуто. Из одних сорцов компилится тремя компиляторами: под HCS12, Coldfire и Cortex M. Есть шансы, что еще RX будет. Какой уж тут workspace. - LightElf(06.10.2015 08:22)
        
        А как это все организовано с учетом контроля версий? - VL(06.10.2015 21:45, )
        
        Да особо никак. Общие сорцы лежат в отдельном каталоге, откуда подтягиваются в проекты. Таким образом всегда компилится самая свежая версия общей части (HAL, протоколы, стек). В каждом конкретном проекте есть заголовочный файл, в котором дефайнами LightElf(148 знак., 07.10.2015 11:22)
        
        Вот и у меня практически так же, кстати есть аналогичный опыт MSP430 + Cortex, но "всегда компилится самая свежая версия" - это засада. Месяц назад заказчик захотел в одном проекте рюшечки одной версии, а в другом - рюшечки другой версии, тут я и VL(244 знак., 07.10.2015 13:17, )
        
        Третий месяц пытаюсь свести в один проект программные модули которые когда-то росли из одного места, но затем много лет развивались в разных проектах. Это оказалось неожиданно большой проблемой - вроде бы вот оно, все что нужно, но оно упорно не AlexG(23 знак., 07.10.2015 18:15)
        
        У меня задачи достаточно узкие. Все рюшечки общего кода старых версий доступны для новых версий. Старый функционал полностью сохраняется. Это временами огорчает (приходится поддерживать некоторые старые косячные опции параллельно новым прямым), но LightElf(293 знак., 07.10.2015 13:57)
        
        "Свежая версия общей части" - это мощно. Скажем, подпилили сорцы на Cortex, добавили баг, который проявляется только на Coldfire, и спокойно пошли пить чай. Красота! - SciFi(07.10.2015 11:28)
        
        Дык не надо общие сорцы "подпиливать на Cortex". На Cortex надо подпиливать только архитектурно-специфичные части, которые живут в своем собственном подкаталоге. Если возникла необходимость изменить общие сорцы в связи с новой архитектурой - это LightElf(38 знак., 07.10.2015 11:47)
        
        Можно, конечно, сделать вид, что существуют "архитектурно независимые" части, но это, скорее, иллюзия. Простейший пример - размеры целых типов. SciFi(36 знак., 07.10.2015 11:49 - 11:51)
        
        Размер целых типов прекрасно описывается в stdint.h Индейцы тоже легко обходятся макросами вида U32_TO_LE(), U16_FROM_BE() и т.д. - LightElf(07.10.2015 11:59)
        
        Естественно. Ну так вот, забыл на минутку про stdint.h или U32_TO_LE(). На Cortex работает, а на HCS12 заглючит. Что и требовалось доказать. - SciFi(07.10.2015 12:04)
        
        Это просто вопрос привычки. Если при переносе на новый камень возникла нужда править, например, код USB бутлодера - это, вообще говоря, тревожный звоночек. Значит там что-то непродумано, стоит взять паузу и еще раз поразмыслить. Последний раз LightElf(55 знак., 07.10.2015 12:20)

Средства и методы разработки