amiller
-
Постов
202 -
Зарегистрирован
-
Посещение
-
Победитель дней
1
Сообщения, опубликованные amiller
-
-
Опубликовано · Изменено пользователем amiller · Пожаловаться
Препроцессор не умеет сумму превращать в строку, так что умерьте хотелки.Я давно-давно (ещё до ARM-ов) начал использовать такой способ.
Размещаю основную структуру константных данных (элементы инициализации, диапазоны изменения, строковые описатели) в ассемблерном файле.
Мне тоже понадобилось делать подсчёт разных элементов внутри структуры.
Так вот, в ассемблере это достаточно легко, примерно так:
PAR_COUNT SET 0 ; Номер параметра ... PAR_COUNT SET PAR_COUNT + 1 ; Следующий параметр ... PAR_COUNT SET PAR_COUNT + 1 ; Следующий параметр ...
В любой момент значением этого счётчика можно с помощью компилятора инициализировать константу, а потом использовать где угодно.
device: DC8 A_LEN, 32 DC16 PAR_COUNT
-
Спасибо! Но всё же не понятно, настройка-настройкой, а функции, которые включают АЦП (в моём случае это HAL_ADC_Start()) сами АЦП не инициализируют, а всего лишь выставляют пару бит, которые включают и запускают режим преобразования.
Смотрите, что конкретно делают эти функции и как это соотносится с теорией.
dual and triple mode целесообразно рассматривать только с внешней синхронизацией на достаточно высокой частоте, например от таймера. Иначе вообще зачем использовать этот режим?
Поэтому запуск преобразования должен происходить не по команде, а автоматически. А для этого нужны соответствующие настройки.
-
Опубликовано · Изменено пользователем amiller · Пожаловаться
Всё же не подскажете где Вы это прочли? Я уже обкурился мануалами, и нигде не видел, чтобы было написано запустить слэйв АЦП вначале, в том же HAL_drivers_STM32F4, так вообще про это ни словаВ документе RM0090 на странице 429 (описание общих регистров АЦП) есть фраза:
Note: In multi mode, a change of channel configuration generates an abort that can cause a
loss of synchronization. It is recommended to disable the multi ADC mode before any
configuration change.
На мой взгляд это однозначно говорит о том, что прежде чем включать любой мульти-режим, нужно сначала настроить отдельные АЦП.
И не важно master или slave.
Я эти режимы использовал, поэтому могу подтвердить, что при включении АЦП нужно действовать именно так, а при отключении в обратном порядке.
А документы, что Вы приводите в качестве примера ("HAL_drivers_STM32F4"), вряд ли могут относится к документации на МК.
Ведь эти прослойки между пользователем и МК пишутся в первую очередь для неспециалистов.
А такие люди не используют специфичные режимы, как dual или triple mode. И есть очень большая вероятность, что в HAL такие режимы не тестировались на достаточном уровне.
Шаг вправо или влево от рекомендованных примеров, и у Вас уже ничего не работает.
Рано или поздно придётся читать первоисточники. Лучше раньше, меньше времени потратите бесцельно.
-
если поделка, типа померять температуру любимого проца - то да.
если надо каждую секунду иметь картину по нескольким точкам сразу - то юарт мягко говоря убогость...
(круглый)
Предлагаю не путать теплое с мягким.
UART, таймеры с DMA, или GPIO - это реализация интерфейса на физическом уровне.
А "иметь картину по нескольким точкам сразу" - это относится уже к логическому уровню протокола обмена.
И одно другому никак не мешает.
-
Если честно, я не понимаю, как можно накосячить в процессе прошивки.
Интерфейсная программа в совокупности с загрузчиком не допустит записи несоответствующей прошивки.
В сомнительных случаях задаст дополнительные вопросы.
Мне кажется как раз в случае ответственных применений предприятие не допустит ситуацию, когда какой то девайс сам обновляется.
Я не говорю о выборе времени, а о возможности в принципе что-то удаленно менять.
А вдруг разработчика обидели и он превратил в кирпичи устройства по всей стране? Это нельзя исключать, если такая возможность имеется.
Новая версия ПО должна поступать по официальному каналу связи от предприятия к предприятию. А при обновлении не помешает акт с парой подписей.
Телевизоры можно и по вайфаю обновлять, а когда речь о жизнях людей, то извините.
Поэтому про боинг что-то не очень верится. Если только они не положили на аборигенов большой болт.
-
Вы так и не указали какие условия для ваших железок, предполагаю что всё же большая часть списка (не линукс, не ретейл, без большой ответственности) для вашего железа справедлива. Но вот почему вы утверждаете что ваш подход единственно верный мне странно.
Не совсем понятно, с кем Вы сейчас общаетесь. Если со мной, то:
1. Я нигде не утверждал, что предложенный мною подход, единственно верный.
2. Просто предложил свой способ, как один из многих.
3. Более того, в разных проектах раньше я использовал разные способы обновления ПО, в том числе и централизованные.
4. По моему мнению, если процесс обновления ПО организован грамотно, то он никак не влияет на степень надежности ПО для устройства, как и на его другие характеристики.
5. Но для ответственных применений решение о том, как и когда обновлять ПО, должна принимать сервисная служба клиента с соответствующими полномочиями, а не сервер за 1000 км.
И процесс должен быть документально оформлен, а оборудование должно быть протестировано.
Так что насчёт оборудования "без большой ответственности" Вы попали с точностью до наоборот.
Ну и ещё один аргумент против централизованной системы обновления ПО. Интернет всё ещё есть далеко не везде.
Например много оборудования стоит на предприятиях, где внешний интернет запрещен или сильно ограничен.
-
Класная позиция пока у вас в устройстве нет линукса, девайсы не гуляют в ретейле и применение девайсов умеренно безответственное. Если продажи 100500 и большая часть из списка выше неверна - обновления должны быть принудительными.
Даже Microsoft до последнего времени оставляла клиентам возможность выбора, обновляться или нет. В десятке обновления отключить сложнее, но можно. А кто я такой, чтобы навязывать обновление своих устройств?
Версии с критическими ошибками во внешний мир не уходят. А исправление мелочей и добавление функционала - личное дело каждого.
-
Опубликовано · Изменено пользователем amiller · Пожаловаться
и не сможете отключить клиентов выборочно от обновлениядаже если это не злоумышленник
По моему мнению шифрование предназначено:
1. Для предотвращения копирования устройств третьими лицами.
2. Для обеспечения невозможности внесения несанкционированных изменений в ПО.
Идентификация клиентов и, соответственно, индивидуальное обновление ПО определяется другими параметрами.
Эти параметры всегда можно прочитать с устройства и эти же параметры входят в заголовок прошивки.
Идентификация по заголовку как минимум обеспечивает:
1. Прошивка одного клиента не подходит другому клиенту.
2. Прошивка для одного типа устройств не подходит к другому типу устройств.
Т.е. возможность не выпускать новое обновление для конкретного клиента существует.
Но мне в этом плане проще, так как у меня клиентов меньше десятка. Это достаточно крупные компании, закупающие наше оборудование.
Если бы пришлось заниматься розничными продажами, возможно подход был бы другой.
Лучше всего быть подобным Неуловимому Джо, который нафиг никому не нужен
+1
Не ломите цены и постоянно развивайте функционал. Если стоимость вхождения в бизнес высока, а потенциальная прибыль невелика, то никто к Вам и не полезет и взламывать не будет.
А если где то цены космические, то я и взламывать ничего не буду, а разработаю аналогичное устройство, напишу софт с нуля, и выйду на рынок.
-
предлагаете прошить одинаковый ключ во все девайсы ?
Если речь идёт о ключе шифрования, то да, я использую один сложный ключ для всех устройств, в которых предусмотрен механизм удаленной замены прошивки.
Алгоритм шифрования выбирал вынужденно. Устройства выпускаю на разных процессорах, поэтому нужен был чисто программный алгоритм. В свое время удалось найти только AES, на нем и остановился (AES-256).
Используется уже более 5 лет (около двух десятков видов устройств общим тиражом тысяч тридцать, наверное) и пока о случаях взлома ничего неизвестно.
Но кроме ключа шифрования есть ещё различные опции, которые характеризуют устройства и версию ПО.
Это идентификатор устройства, версия ПО, идентификатор клиента и ещё некоторые опции специализации.
Такая же информация находится в заголовке прошивки, который не зашифрован, но защищен от изменения зашифрованным ключом.
Заголовок использует программа загрузки, которая реализует интерфейс с пользователем, и принимает предварительное решение о том, подходит ли данная прошивка для данного устройства/клиента.
А окончательное решение о возможности заливки ПО принимает уже загрузчик в устройстве.
-
У меня проблем слишком большого количества клиентов нет, но в принципе считаю, что проблемы обновления миллиона прошивок лучше переложить на миллион клиентов.
Есть загрузчик, содержащий ключи шифрования, в устройстве, залоченном на предприятии.
И есть сайт, на котором публикуется актуальная программа для прошивки девайсов, а также последние прошивки (естественно зашифрованные) с информацией об изменениях в них.
Клиенты сами всё это скачивают и заливают. Для особо одаренных есть видеоролик с пояснениями.
Так как в расшифрованном виде прошивка восстанавливается только внутри залоченного девайса, то защита интеллектуальной собственности сводится к обычным правилам безопасности на предприятии.
А задача публичной программы для прошивки - передать загрузчику зашифрованную прошивку без каких либо преобразований.
-
Интересно, всегда считал что с C2prog что то не так, потому как f28335 прошивался через JTAG при выборе любой частоты в соответствующем combobox. (с SCI такое не прокатывало конечно)
Кстати а Uniflash через SCI разве прошить может, делали?
1. Старая версия uniflash (3.4.1) умеет программировать через сторонние JTAG или SCI (UART), но ничего ещё не знает про контроллер TMS320F28075.
Никогда не пробовал, но в интерфейсе такой режим выбрать можно, значит вероятно работает.
-
amiller. Подскажите, есть ли какая-то методика расчёта ограничения интегральной составляющей. Или оно находиться только экспериментальным путём?
Алгоритм очень простой:
Если выходной код ПИДа у Вас упирается в ограничение (снизу или сверху), то Вы должны блокировать дальнейшее изменение интегральной составляющей.
Это примерно эквивалентно насыщению ОУ в аналоговой схеме.
Как только выход возвращается в диапазон регулирования, интегральная составляющая разблокируется и снова может изменятся.
Нужно только не забывать про полярность ошибки. Если ошибка меняет знак, то блокировка тоже снимается.
-
Вообще говоря построение качественного преобразователя с прямым микропроцессорным управлением зависит от 3 основных факторов:
1. Измерения
2. Реализация регулятора
3. Формирование ШИМ
На каком процессоре это делать, конечно важно, но на частотах сравнимых с частотой сети - не очень уж и важно.
И конечно можно сделать качественный регулятор на гораздо меньших частотах преобразования и с гораздо менее производительным МК.
1. Измерения.
1.1. Желательно исключить время, когда происходит коммутация силовых ключей. Т.е. ШИМ модуль должен формировать отдельный строб запуска АЦП в момент времени, когда коммутаций нет.
1.2. Чтобы минимизировать воздействие помех нужно производить несколько измерений и использовать простое усреднение или накладывать фильтр с определенной характеристикой в зависимости от задачи.
2. Реализация регулятора.
2.1. В простейшем случае это может быть одноконтурный ПИД регулятор, на вход которого подается сигнал ошибки, на выходе формируется задание на ШИМ.
2.2. Нужно обязательно предусмотреть ограничение интегральной составляющей.
2.3. В более сложных случаях используются многоконтурные регуляторы подчиненного или параллельного регулирования.
2.4. Иногда требуется добавить контур токоограничения, который вступает в действие при резких изменениях нагрузки или в аварийных режимах.
2.5. Иногда целесообразно добавления контура регулятора по возмущению (то о чём писал ранее - это регулятор по отклонению).
В общем тема это отдельная и сложная, решению в лоб обычно не подчиняется, литературы в сети много, в том числе приведены и методики настройки ПИД-регулятора.
3. ШИМ-модуль.
3.1. Нужно рассчитать и проверить на модели требуемую длительность "мёртвого времени" для ключей.
Я уже не говорю о том, что нужно выбрать оптимальную топологию силовой схемы, есть масса вариантов обеспечения мягкой коммутации силовых ключей.
3.2. Обязательно предусмотреть несколько каналов программно-аппаратных защит разных уровней.
4. Ну и последнее, с точки зрения МК, при управлении силовым преобразователем важен абсолютный real time. Т.е. вы чётко должны представлять сколько времени у Вас выполняется тот или иной кусок кода, когда и в какой последовательности что у Вас выполняется и что никакие события в системе не повлияют а скорость обработки критически важного кода.
-
Спасибо, но насколько мне удалось выяснить:
1. Старая версия uniflash (3.4.1) умеет программировать через сторонние JTAG или SCI (UART), но ничего ещё не знает про контроллер TMS320F28075.
2. А новая версия (4.2.1) работает только через родные техасовские отладчики и не поддерживет последовательный интерфейс, увы.
-
Здравствуйте!
Совсем не DSP, скорее просто MCU, но всё же TI, может кто знает...
Долгое время работал с разными контроллерами серии С2000 и Piccolo. Программировал всегда с помощью C2Prog.
Сделали новое устройство на относительно новом контроллере TMS320F28075PZA.
Оказалось, что в C2Prog (1.7p-b7195) для программирования этого кристалла доступны только две опции: JTAG_20MHz и SCI_20MHz.
В обоих режимах C2Prog успешно загружает свой загрузчик и далее не получает ответа от кристалла.
Возникла мысль, что загрузчик C2Prog рассчитан на тактирование от внешнего кварца с частотой 20МГц.
Присоплил кварц на проводках, и о чудо, программа стала нормально загружаться.
Из-за особенностей проектирования конкретного устройства наличие внешнего кварца исключено.
Хотя мне интерфейс программирования нужен однократно только для загрузки собственного загрузчика, но необходимость для этого подключения кварца напрягает.
Подскажите другое доступное ПО для программирования TMS320F28075PZA, которое без проблем работает на внутреннем генераторе и через последовательный порт.
Спасибо.
-
Длительность прерывания проверял - 3 мкс.
В расчёт надо принимать частоту таймера а не ядра. В таймере есть модуль умножения частоты.
"fHRTIM x 8U = 1.152 GHz - Resolution: 868 ps - Min PWM frequency: 17.6 kHz (fHRTIM=144MHz)"
Ок. Я просто не пытался использовать STM32 для сложных проектов. Там где нужен ШИМ на высокой частоте, мой выбор - Texas.
Но если таймер этого семейства STM32 может работать в режиме Hi Resolution, то вопрос по этому поводу снимается.
Если у Вас частота обновления ШИМ 100кГц, то вся обработка данных (и все измерения), задействованных для расчётов ШИМ, должна проводится с этой частотой.
Если у Вас по факту задержки сравнимы с частотой сети, то вероятно в алгоритм где то затесались параметры, которые рассчитываются с этой частотой.
RMS или что-то подобное. Проверьте ещё раз код, чудес не бывает.
-
Так как я в теории ТАУ плохо ориентируюсь, было бы хорошо если выложете наглядное видео или картинки.
Частота обновления ШИМ 100 КГц . Частота импуьсов 200 КГц. Именно с такой частотой оцифровыется сигнал и запускаеться прерывание. Это всё проверялось.
Счётчик таймера считает до 5760.
Вопрос модераторам. Можно ли переместить тему в другой раздел?
Достаточно ориентироваться немного в физике, немного в математике.
Стоит напомнить, и неплохо проверить, что если обновляете относительную длительность ШИМ с частотой 100кГц, то у Вас на всю обработку 10мкс.
Т.е. чтобы алгоритм управление хоть как то работал, нужно, чтобы время обработки прерывания не превышало 70-80% от этого времени, т.е. не более 7-8мкс. Проверяли это?
Далее:
Вас спрашивали про таймер, который Вы используете для формирования PWM.
У STM32 таймера достаточно тупенькие и не могут работать на частотах выше тактовой ядра.
Если у Вас частота ШИМ 200кГц и при этом таймер считает до 5760.
Это должно бы было означать, что частота ядра равна 5760 * 200000 = 1152 МГц.
Такого быть не может, поэтому следует уточнить Ваши ответы.
А вообще при проектировании ШИМ контроллеров на базе МК нужно чётко представлять длительности и частоты всех процессов.
А особенно работу критичных по времени модулей, таки как PWM и ADC.
-
В плане адреса, согласно мануалу он существует. К тому же я практически методом перебора уже перепробовал всевозможные адреса
Простите, а где Вы это увидели?
На приведенной картинке видно, что flash расположена 0x08000000 - 0x08007FFF.
А Вы обращаетесь по адресу 0x08010000, что за пределами.
Может проблема в подсчёте ноликов?
-
Может быть запись из DMA по событию совпадения CCR3 == CNT совпадает с событием UEV и пропускается? при этом релоад регистр не переписывается в теневой?
Но с этим должны были столкнуться десятки и сотни?
В общем и целом не совсем корректно писать в теневой регистр ровно в тот момент, когда он переписывается в основной регистр сравнения. И неважно через ДМА или напрямую.
Время от события до выполнения записи ДМА не всегда одинаковое и может зависеть от многих факторов (частоты шин, их занятость и т.п.)
Я бы синхронизировал ДМА по какому нибудь событию таймера, которое гарантированно не совпадает с апдейтом.
Для этого можно задействовать свободный канал сравнения, если такие есть.
-
Сделал новую ревизию платы, в части МК изменилось только, что BOOT1 теперь идет на EN вход внешнего DC/DC. Вроде бы не должно никак мешать, когда контроллер в сбросе или загрузчике BOOT1 притянут к земле резистором 10К.
Может начать с самого начала?
Предполагаю, что на старой ревизии платы всё работало.
Осциллографом посмотреть сигнал BOOT1, Посмотреть документацию на DC/DC, нет ли там на входе ENABLE pull-up резистора, который пересиливает Ваши 10к.
По симптомам очень похоже, что при сбросе через отладчик сигнал не успевает подняться от нулевого уровня из за емкости дорожки и всё работает. А при подаче питания BOOT1 уже равен 1.
-
Опубликовано · Изменено пользователем amiller · Пожаловаться
Error[Lc036]: no block or place matches the pattern "rw data section .noinit in asmmain.o"Это же был просто пример.
У меня в файле *.icf объявлена секция ".noinit", в которой и размещаются эти переменные. У Вас видимо этой секции нет.
Размещайте переменные в существующей секции.
По поводу ключевых слов DATA и CODE - я всегда явно указываю, что размещаю: данные (переменные или константы в зависимости от секции) или код программы.
Возможно где то это и не обязательно, но и вроде как не мешает.
-
Я читал "IAR Assembler Reference Guide" пытался брать те куски кода которые там приводились но все никак не получается...
особенно непонятно как правильно пользоваться директивой SECTION.
Я так понимаю что нужно обьявить секцию для переменных сначала?
Так значение переменной не меняется:
#include "iostm8.h" MODULE asmmain PUBLIC __iar_program_start PUBLIC main EXTERN CSTACK$$Limit SECTION `.near_func.text`:CODE//начинается секция кода программ, что там в кавычках? __iar_program_start: a1 DC16 0 //двухбайтная переменная инициализируется значением 0 a2 DC16 9 //двухбайтная переменная инициализируется значением 9 LDW X, #0x000600; Set stackpointer LDW SP, X main: LD A,#5//загружаю в А число 5 LD a1,A// загружаю в переменную a1 значение из А END
По моему у Вас всё перепутано.
Вот фрагмент кода, ассемблер редко приходится использовать:
//-------------------------------------------ПЕРЕМЕННЫЕ--------------------------------------------- SECTION `.noinit`:DATA:NOROOT(2) DATA D_NUM DS16 1 ; Серийный номер D_DAT DS16 1 ; Дата выпуска dummy DS16 2 //-------------------------------------------КОНСТАНТЫ---------------------------------------------- SECTION `.rodata`:CONST:NOROOT(2) DATA ;--------------------------------------------------------------------------------------------------- sys_param: DC16 0, 9999, 1234, 0x90 + T_DEC + F_EXT + F_WRT DC8 ' Регистр команд '
Синтаксис скорее определяется используемой средой, чем платформой.
В секции, предназначенной для размещения кода, невозможно разместить переменные.
А различия в объявлении должны быть понятны из примера.
-
ну если из любви к искусству и если Вы действительно так въедливы как пишете, то изучите от корки до корки всю периферию своего камня и думаю сможете что-нить придумать.
Думаю, что более просто будет так:
При условии, что CS-ы посажены на один порт.
Задействовать 1 дополнительный канал DMA, который будет синхронно писать данные в регистр BSRR соответствующего порта, тем самым дергая нужные CS.
-
Согласен что кнопка и прерывание = неудачное решение, но тут даже до нажатия кнопки дело не доходит. Достаточно просто коснуться вывода PA0 щупом тестера для замера напряжения и БАЦ!, получите прерывание. Я бы ещё понял если бы вывод болтался без подтяжки в воздухе и я его касался проводником - тут уж без вариантов будет многократное срабатывание прерывания от наводок, емкости щупов и т.п. Но почему себя так ведёт полностью обвязанный и прикрытый от всех случайностей вывод мне совершенно неясно (
Почему то мне кажется, что во время экспериментов плата у Вас не заземлена, а на запястье нет браслета для снятия статики.
А значит в момент касания Вы подключаете к выводу микросхемы конденсатор на несколько десятков пикофарад, заряженный до нескольких киловольт.
Это эквивалент Вашего тела в достаточно сухом воздухе, если что.
А далее получается емкостной делитель, где ток разряда Вашей емкости заряжает емкость на входе. И вполне может быть, что эквивалентное напряжение на входе превысит логический уровень. А если бы это был просто висячий вход, то таким образом легко его убить.
Недаром всех монтажников заставляют браслеты одевать и работать заземленным инструментом.
Бывает, что у некоторых процессоров есть система внутренней синхронизации, которая не пропускает наносекундные (иногда и микросекундные) импульсы.
Видимо в STM такого нет. Это не значит, что процессоры плохие. Просто Вы использовать пытаетесь их не совсем правильно.
PIC24F сбои UART-ов при переключении режима DOZE
в PIC
Опубликовано · Пожаловаться
Я бы не рассчитывал на чудеса с самопроизвольной установкой бит по помехам.
А поискал бы в документации особенности данного переключения частоты.
Чисто теоретически могу предполагать, что если изменение тактирования происходит в середине приема байта, то не исключено появление ошибок.
Если это так, то нужна или взаимная синхронизация процессов или корректная отработка ошибочных состояний.