Доброго дня всем.
Есть проект на PIC33 (MPLAB) и мне надо
автоматически сохранять параметры проекта
(время, дата, размер hex и т.п.) в некоторой переменной,
которую я могу вычитывать при функционировании
программы.
Полная версия этой страницы: Параметры проекта
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Все остальные микроконтроллеры > PIC
Так вопрос-то где?
Что именно Вам непонятно?
Чем конкретнее вопрос- тем конкретнее ответ.
Что именно Вам непонятно?
Чем конкретнее вопрос- тем конкретнее ответ.
Цитата(Ruslan1 @ Jan 15 2013, 18:00) 
Так вопрос-то где?
Что именно Вам непонятно?
Чем конкретнее вопрос- тем конкретнее ответ.
Что именно Вам непонятно?
Чем конкретнее вопрос- тем конкретнее ответ.
Конкретно.
В проекте создаю переменную (char, int, ...) какую конкретно пока не знаю.
Смысл вопроса в том, как этой переменной автоматически (после каждой копмиляции) присвоить, к примеру, значение текущего размера hex файла.
Цитата(skyv @ Jan 15 2013, 17:10)
Конкретно.
В проекте создаю переменную (char, int, ...) какую конкретно пока не знаю.
Смысл вопроса в том, как этой переменной автоматически (после каждой копмиляции) присвоить, к примеру, значение текущего размера hex файла.
В проекте создаю переменную (char, int, ...) какую конкретно пока не знаю.
Смысл вопроса в том, как этой переменной автоматически (после каждой копмиляции) присвоить, к примеру, значение текущего размера hex файла.
Я вижу решение только одно, но, конечно могут быть и другие, мне неизвестные:
После окончания компиляции вызовите Вашу программу, которая все и сделает
Как вызвать: укажите эту программу на вкладке Custom Build в Build Options в строчке "Post-Build Setup"
Как посчитать: сами думайте.
Как записать результат в итоговый hex: вариантов вроде бы море, мне нравится HexMate.
Нюанс: константа должна быть расположена по предопределенному адресу. Это делается стандартными средствами компилятора, не нужно никаких "посмотрел в листинге".
И еще: у HexMate другой папа чем у MPLAB-C компилятора, так что порядок байтов при записи многобайтной величины обратный (если я правильно помню этот момент)
Но если генерируете Вашей программой не число а hex-файл и дальше склеиваете с сырым хексом (с помощью того же HexMate), то порядок байтов Вас волновать не будет, как пропишете так и останется.
Спасибо за ответ.
Направление понятно.
Я спросил потому, что когда-то на форуме
встречал топик о возможности IAR, на этапе
компиляции, присвоить переменной время
и дату создания проекта.
Мне надо что-то подобное или
некий идентификатор проекта.
Направление понятно.
Я спросил потому, что когда-то на форуме
встречал топик о возможности IAR, на этапе
компиляции, присвоить переменной время
и дату создания проекта.
Мне надо что-то подобное или
некий идентификатор проекта.
Цитата(skyv @ Jan 17 2013, 08:10)
Спасибо за ответ.
Направление понятно.
Я спросил потому, что когда-то на форуме
встречал топик о возможности IAR, на этапе
компиляции, присвоить переменной время
и дату создания проекта.
Мне надо что-то подобное или
некий идентификатор проекта.
Направление понятно.
Я спросил потому, что когда-то на форуме
встречал топик о возможности IAR, на этапе
компиляции, присвоить переменной время
и дату создания проекта.
Мне надо что-то подобное или
некий идентификатор проекта.
Угу. А потом поменялась версия компилятора и метод вычисления или адрес куда пишут изменился. То-то радости при саппорте такого проекта будет. А Ваш батник как считал, так и будет продолжать считать, независимо от версии мплаба
Дату/время сборки можно узнать из стандартных макросов ANSI C http://gcc.gnu.org/onlinedocs/cpp/Standard...ned-Macros.html
А прочую инфу как размер бинарника как Ruslan1 говорит, только более надёжно писать это не в выходной хекс, а в константу в коде и запускать программку перед сборкой, а не после. Тогда при каждом билде будет подставляться размер бинарника от прошлого билда. Вам только следить за актуальностью этой информации перед выпуском релиза (собирать дважды). Вот пример Ruby-скрипта, генерирующий h-файл с номером крайнего коммита в git
Элементарно добавить сюда размер бинарника и любую другую инфу.
Заодно дисциплинирует делать отдельные коммиты на финальные релизы чтобы после пересборки в коде фактически был именно тот коммит, из которого проект собран.
А прочую инфу как размер бинарника как Ruslan1 говорит, только более надёжно писать это не в выходной хекс, а в константу в коде и запускать программку перед сборкой, а не после. Тогда при каждом билде будет подставляться размер бинарника от прошлого билда. Вам только следить за актуальностью этой информации перед выпуском релиза (собирать дважды). Вот пример Ruby-скрипта, генерирующий h-файл с номером крайнего коммита в git
Код
Dir.chdir(File.expand_path(File.dirname(__FILE__)))
filename = "git_revision.h"
git_exec = "git log --pretty=oneline -n1"
file_included = filename.gsub(".h", "_H").upcase
file = File.new(filename, "w")
file.puts("#ifndef #{file_included}")
file.puts("#define #{file_included}")
file.print "static volatile const char *GIT_REVISION = "
file.print %x[#{git_exec}].chomp.inspect
file.puts ";"
file.puts("#endif")
file.close
puts "************************************"
puts "Git revision written to #{filename} "
puts "************************************"
filename = "git_revision.h"
git_exec = "git log --pretty=oneline -n1"
file_included = filename.gsub(".h", "_H").upcase
file = File.new(filename, "w")
file.puts("#ifndef #{file_included}")
file.puts("#define #{file_included}")
file.print "static volatile const char *GIT_REVISION = "
file.print %x[#{git_exec}].chomp.inspect
file.puts ";"
file.puts("#endif")
file.close
puts "************************************"
puts "Git revision written to #{filename} "
puts "************************************"
Элементарно добавить сюда размер бинарника и любую другую инфу.
Заодно дисциплинирует делать отдельные коммиты на финальные релизы чтобы после пересборки в коде фактически был именно тот коммит, из которого проект собран.
Цитата(Cosmojam @ Jan 19 2013, 22:38)
...
Понятно, спасибо за ответ.
Цитата(Ruslan1 @ Jan 19 2013, 18:30)
Угу. А потом поменялась версия компилятора и метод вычисления или адрес куда пишут изменился. То-то радости при саппорте такого проекта будет. А Ваш батник как считал, так и будет продолжать считать, независимо от версии мплаба
Меня абсолютно не волнует по какому адресу будет находиться моя переменноя ("My_Var") и пусть ее компилятор ложит каждый раз
в другое место, что из того. Я считаю, что всегда смогу увитеть содержимое именно "My_Var" или я ошибаюсь?
Не думаю, что форма представления даты и времени будет меняется в каждой новой версии компилятора.
По поводу батника я уже писал, что это вполне реальный вариант.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.