jcxz

А ничего, что это два разных МК? :smile3046:

Вы уверены, что прошивка грузится именно из .sys, а не из флешки подключенной к CY7C68013A? Давно с ней имел дело, но насколько помню, прошивка ищется по сигнатуре в начале памяти флешки, сидящей на I2C. Если да - решение на вскидку: взять USBTrace (или другой сниффер) и захватить процесс загрузки. Если там имеется загрузка FW, то обнаружить начало и конец думаю - не составит труда (скорей всего прошивка будет идти большими блоками одинакового размера). Потом можно поискать содержимое этих блоков в файлах на диске. Только (насколько мне помнится) при загрузке "на лету" из драйвера, прошивка вроде грузилась не из .sys-файла, а именно из отдельного файла с прошивкой (лежащего или рядом или где-то).

У меня со старым клоном JLink-а подобная проблема в IAR. При коннекте IAR5.50 к Cortex-M3 выдаёт окно предупреждения о неэффективной работе, но тем не менее жмёшь "согласен" и дальше работает. А уже более новый IAR6.50 и вовсе отказывается работать с ним.

Да какое тут 32-битное выравнивание??? Кроме 32-битных инструкций (LDR/STR), у ARM-ов есть и 8-и (LDRB/STRB) и 16-битные (LDRH/STRH) инструкции доступа к памяти. И выравнивание зависит от разрядности инструкции. Для байтовых переменных будет конечно-же использованы LDRB/STRB (или LDRSB/STRSB). и ваш пример будет выполнен корректно. Иначе - следуя вашей логике, когда вы объявляете переменную размером байт, у вас всегда бы выделялось 32 бита памяти под неё. Но это-же бред.

От CPU зависит только максимальное выравнивание. Т.е. - struct T { u32 a; }; для 32-битных CPU будет выровнена на 32, а для 16-битных CPU - на 16. В соответствии с основной разрядностью CPU. А в чём тут проблема? В поле my_str.B будет скопирован 1 char из data. С любым выравниванием. Ну кроме процов, где char - не байт, а другой размер. Но там тоже всё ок, только будет скопирован не байт, а char ;)

Вы почему-то путаете невыровненный доступ CPU и работу си-компиляторов со структурами. Это две не относящиеся друг к другу вещи. Во всех примерах, что я привел нигде нет невыровненного доступа. Даже в случаях с пакованными структурами. :) В случае с пакованной структурой, вы указываете (величиной паковки в pack()) инструкциями какой максимальной длины следует обращаться к элементам структуры. Таким образом, чтение элемента T::a #pragma pack(push, 1) struct T { u32 a; }; #pragma pack(pop) на ARM7/9 будет осуществляться 4-мя байтовыми LDRB с последующей склейкой байт в u32. Для: #pragma pack(push, 2) struct T { u32 a; }; #pragma pack(pop) на ARM7/9 сгенерит две LDRH с последующей склейкой в u32. Для Cortex-M3 компилятор имеет право сгенерить в обоих случаях одну невыровненную LDR (если, как указал уважаемый Сергей Борщ, соответствующий бит разрешает невыровненный доступ) (не помню уж - есть-ли такая настройка в опциях компилёра, чтобы указать ему состояние этого бита). А может он просто - поступает так же, как для ARM7/9. Не помню. Так что в обоих случаях - с пакованными и непакованными структурами никаких проблем нет. Проблема возникает только когда вы обманываете компилятор - подсовываете адрес в указатель на структуру и выравнивание этого адреса не соответствует выравниванию структуры. Выравнивание непакованной структуры всегда равно выравниванию максимального её члена, выравнивание пакованной - не превышает величины паковки. PS: Я кстати стараюсь не пользоваться пакованными структурами. А там, где это нужно (например - для описания форматов кадров протоколов обмена), предпочитаю в качестве членов структур, размер которых превышает выравнивание структуры, использовать свои типы данных, реализованные классами с соответствующими методами доступа к ним. В таком случае не возникает проблем с указателями на пакованные структуры в компиляторе. И что ещё более важно - такие описания структур легко переносятся между разными компиляторами, так как не привязаны к прагмам, которые в разных компиляторах = разные.

Хм... Я разве где-то подобное говорил?? Я вообще-то говорил почти противоположное: 1. Структуры в си по умолчанию не упакованные. 2. Выравнивание структуры равно выравниванию максимального члена структуры. 3. Максимальное выравнивание для встроенных типов данных как правило не превышает основной разрядности CPU (хотя это не могу утверждать с полной уверенностью). (т.е. - если CPU 32-разрядный, то выравнивание 64-битного встроенного типа будет всё равно ==32). Про упакованность - тоже Вы что-то не поняли. Я как раз писал, что пакование может выполняться не обязательно до уровня байт, может быть до уровня 16-бит или др. см. #pragma pack(push, N) в IAR к примеру. Пример IAR: #pragma pack(push, 2) struct T { u32 a; u8 b; }; #pragma pack(pop) В данной структуре будет sizeof(T)==6. И выравнивание её будет равно ==16бит. И вообще - упаковка не входит в язык си и может выполняться по-разному на разных компиляторах. Очевидно, что в си, если имеется структура (не важно - пакованная или нет), то в массиве элементов этой структуры начало каждого следующего элемента будет находиться по смещению sizeof() от предыдущего. А вот уже величина этого sizeof(T) будет зависеть от наличия pack() в её атрибутах и величины пакования этого самого pack().

В чём-же? :rolleyes: Ну разве, что если использовать её на разных системах, с разным размером int.... Вам известно, что в структурах (классах) си по умолчанию выполняется выравнивание (вне зависимости от CPU; это правило языка си)? Ну только если конечно не предпринять спец. мер (pack). Также и начало второй в массиве - всегда после sizeof() от начала первой как ни странно... :rolleyes: Размер (sizeof()) также выравнивается на размер выравнивания структуры (который в свою очередь равен размеру максимального члена).

Не очень понял как мешает выравнивание структуре struct str { int8_t A; int8_t B; } в ней-же все элементы - байт. На любом CPU, который умеет работать с байтами (и PC и Cortex-M0), с такой структурой никаких проблем выравнивания не будет. В компе-то - нет, но в си-компиляторах есть. Вне зависимости от CPU. Насчёт пакованных структур - тоже не понял. Компиляторы (IAR во всяком случае) при работе с пакованными структурами на CPU не умеющем невыровненный доступ, знают это прекрасно и выполняют доступ к членам структуры в соответствии с величиной пакованности (1,2,...) - разбивают обращения на несколько 8-и или 16-и-битных (загляните в листинг!). И си-программисту эта кухня невидима. Скорость конечно будет ниже. Но на удобство почти никак не повлияет. Единственно - будет проблема с указателями на такие структуры.

Только если для задачи с таким-же приоритетом могут отобрать! К примеру в uCOS, так как у всех задач уникальные приоритеты, процессор у активной задачи заберут только когда появится более приоритетная, готовая к выполнению задача. А это означает - где-то будет вызвана функция освобождения семафора/мьютекса или у более приоритетной задачи истечёт время приостановки задачи по OSTimeDelay(). И всегда есть самый низкоприоритетный IDLE-процесс, аккумулирующий все неиспользованные такты CPU в инструкциях WFE/WFI или в цикле вычисления загрузки CPU. Отличие корпоратвиной от вытесняющей в том, что в первой использование времени CPU контролирует каждая задача самостоятельно, и сама должна следить сколько она времени отработала и когда отпущенное ей время истечёт, самостоятельно передать управление другой задаче. В вытесняющей эти функции берёт на себя шедулер. Очевидно, что первый вариант более сложен для прикладных программистов, пишущих задачи, но более прост с точки зрения организации ОС. К тому-же в первом варианте будут сложности с организацией семафоров, которые могут освобождаться в ISR. PS: Вообще тема неверно озаглавлена. Ибо имеет отношение к STM ровно такое-же, как к любому другому Cortex-M, а к Keil - вообще никакого...

Я думаю - Вы немного путаете. Вам наверное нужна обычная вытесняющая многозадачность, но с возможностью существования равноприоритетных задач. И только если задача с равным приоритетом не отдаёт сама время CPU (вызывая одну из функций ожидания объекта синхронизации ОС), она может быть переключена на следующую с таким-же приоритетом. Приоритеты по-любому должны быть. Хотя-бы у фонового IDLE-процесса должен быть приоритет ниже, чем у любого другого процесса. Или вам нужна корпоративная многозадачность?

Я не рассматривал операционок, где ведётся контроль времени на активную задачу. Очевидно что такое может делаться только в ОС, допускающих задачи с равным приоритетом. Я использую uCOS, а в ней не допускается двух задач с одинаковым приоритетом. Соответственно - всё время CPU всегда получает задача с наивысшим приоритетом, и менее приоритетная задача может получить время только если все более приоритетные уйдут в ожидание. Это более простая организация ОС, мне её хватает. Когда Вы говорите про таймер, Вы путаете два разных действия ОС - решедулинг (выбор новой задачи верхнего уровня, которой и будет теперь отдаваться время CPU) и собственно - переключение контекста (передача управления с переключением стека и рабочих переменных ОС). Так вот решедулинг выполняется во-первых: при выполнении любой операции ОС с объектами синхронизации ОС (семафорами, мьютексами и пр.). Т.е. - при вызове функций ОС ЗанятьСемафор(), ОсвободитьСемафор(), и т.п. во-вторых: в функции таймера, который отсчитывает счётчики времени приостановки задач (OSTimeDelay(N_тактов_таймера)) вызванные задачами для создания паузы в выполнении задач. Решедулинг определяет - изменилась-ли текущая high-priority task? И, если изменилась, ставит запрос PendSV. Например - задача вызвала ОжиданиеСемафора() который в настоящий момент занят. Тогда она будет переведена в состояние Wait (с опциональной привязкой дескриптора задачи к семафору). Соответственно - нужно найти новую текущую high-priority task. Решедулинг просматривает список задач находящихся в активном состоянии (хотя-бы одна должна быть, всегда имеется фоновая Idle-задача ОС, на самом низшем приоритете, которая никогда не должна уходить в Wait (не должна вызывать никаких функций ожидания ОС)), выбирает имеющую высший приоритет и ставит запрос PendSV. То же самое происходит в любом другом вызове функций ОсвободитьСемафор() или Занять/ОсвободитьМьютекс() или ПриостановитьЗадачуНаNТиков() и т.п. Само переключение контекста делается всегда в одном месте - в ISR PendSV. Это избавляет от необходимости запрета прерываний на время работы функции переключения контекста - она может быть прервана любым ISR и соответственно - совсем не мешает аппаратным прерываниям. Единственное, что делается в системном таймере (относительно переключения задач ОС) - это декремент счётчиков задержек выполнения задач (если задача вызвала ожидание функцией OSTimeDelay(N_тактов_таймера) и если какой-то из этих счётчиков обнулился, соответствующая задача переходит из состояния DELAYED в состояние ACTIVE и вызывается Решедулинг().

Если Вы "в точности так и обращаетесь", то в момент такой состыковки если даже это есть, ядро у вас будет работать от дефолтного источника (не от PLL), и на него этот такт никак не должен повлиять. А почему бы Вам переключение частоты не делать с предварительной перезагрузкой всего МК (аппаратным ресетом)? Я в своём проекте, где тоже нужно переключать частоту PLL, не стал усложнять, и просто делаю аппаратный ресет, а старт ПО и инициализация PLL идёт уже на новой clk. Всё работает прекрасно с какой-бы на какую-бы частоту не пробовал переключаться. LPC1758

Возможно автору нужно не http, а простой tcp/ip-коннект (сокет). Если на той стороне есть tcp-порт открытый в listen-режиме, то конечно на него можно установить активное соединение. Автору нужно почитать про TCP/IP-стек и как он работает чтобы понять, что ему нужно.

Скачайте порт Cortex-M для uCOS. Там всё на асм. И очень лаконично.

какое ограничение по времени? В прерывании таймера обычно ставится только запрос PendSV. Это чтобы всё переключение делалось в одном месте и не нужны были блокировки. И PendSV должно иметь низший приоритет, ниже любого другого ISR, в том числе таймера, чтобы не мешать работе аппаратных прерываний (не мешать "реальному времени"). Я уже писал об этом выше. А если вы сделаете в таймере, то как раз это будет хуже с точки зрения реалтаймовости, так как переключение будет на уровне приоритета аппаратного прерывания таймера. ...тем более когда вы это изобретёте, если всё сделаете правильно, то с удивлением обнаружите, что ваш код полностью совпадает с уже существующим

Так Вас и тут никуда дальше мануалов не посылали. А это как раз и есть дельный совет ;) К тому-же я только что почти подробно расписал весь механизм переключения задач в Cortex-M. А то что не можете найти описание (да хоть и на русском) на одно из самых распространённых ядер в настоящее время, говорит о том что плохо ищете. А перепостить сюда выдержки из мануалов - это значит просто захламлять форум. "Имеющий уши - да услышит, имеющий глаза - да увидит".

В STM32???

В реальности любое переключение контекста - это выход из прерывания. Т.е. - исполняется ваша задача (в thread-mode) ===>> происходит прерывание (либо PendSV (вызванное программно из этой-же самой задачи) либо любое другое аппаратное или исключение) ===>> контекст прерванной задачи сохраняется частично аппаратно (механизм Stacking: R0-R3, R12, SP, PC, PSR) частично программно (остальные регистры на входе в ISR) на стеке ===>> в этот момент, так как находимся внутри ISR, то активным является MSP, а на прерванный контекст указывает PSP (это если прерван thread-mode, а не handler-mode) ===>> если это обработчик PendSV, то он проверяет необходимость переключения задачи, если нужно переключать - просто сохраняет указатель из PSP в текущий указатель стека в дескрипторе данных прерванной задачи, а в PSP загружает значение текущего указателя стека из дескриптора данных новой задачи (которая теперь будет исполняться) ===>> дальше - просто выходит из прерывания, а так как PSP теперь указывает на новую задачу, то после выхода будет продолжено выполнение уже её, как будто прерыванием была прервана она, а не старая задача. Вот и всё. Такой механизм позволяет делать запрос на переключение задач хоть на уровне задачи, хоть внутри ISR - это будет отрабатываться единообразно. Так как PendSV имеет низший приоритет, то соответственно он не может прервать другой ISR, и не нужно в нём делать проверку случая прерывания другого ISR (и соответственно прерванным всегда будет PSP). Такой метод переключения задач хорошо совместим и с механизмом вложенных прерываний Cortex и с механизмом tail-chaining. Не требует много телодвижений для переключения (как например было в ARM7/ARM9 - там ужас какие выкрутасы приходилось делать с множественными переключениями режимов и копированиями контекстов). Исходники самого переключателя контекстов у Cortex и у ARM7/9 отличаются по объёму в разы. Естественно - перед стартом ОС, стеки всех задач должны быть проинициализированы правильно (так как будто эта задача была прервана прерыванием), а в дескрипторах задач должны быть указатели на верхушки стеков.

В реале - не совсем так. Переключатель контекста (задач) это собсно - ISR. Для Cortex - конкретно PendSV. И должен быть самым низкоприоритетным из всех прерываний. В нём переключается контекст (стек) задачи Thread-режима. Все задачи выполняются в Thread-режиме, обработчики (и PendSV) - в Handler-режиме. Выход из Handler - возврат к выполнению задачи (возможно новой, если было переключение в PendSV). Для переключения задачи из Thread-режима необходимо программно возбудить прерывание PendSV. PendSV собсно и создано для операционок. Это вкратце. Товарищ изобретает велосипед. Изобретать будет долго и получится он с квадратными колёсами, так как читать доки не хочет (ибо - писатель, а не читатель ;) и изучать существующие ОС тоже не хочет. Если-бы хоть что-то прочитал про режимы Cortex, его регистры, обработку прерываний/исключений, то глупых вопросов не задавал-бы. Ибо начинать надо всегда с глубокого изучения вопроса и читать-читать долго и долго, и только когда всё прояснится, тогда и только тогда можно начинать что-то писать. А если начинает с писания, то ничего путнего никогда не получится....

Вообще-то максимальная степень защиты (CRP3) достигается только с использованием IAP для обновления ПО, так как в этом случае ISP полностью запрещено.

Так Вы это как раз одним из пунктов ТЗ и укажете "необходимо провести реверс-инжиниринг протокола обмена" Так что - пишите ТЗ, бюджет, сроки и т.п. Народ тут душевный - всё растолкуют, обсосут проблему со всех сторон, а потом посмотрите - может сами за этот бюджет и возьмётесь за разработку ;) Какой-же это оффтоп??? Здесь-то - самый что ни на есть онтоп!!!

Так как здесь форум разработчиков электроники, то может Вам разработать эту СенсорБоард? :yeah:

Можно канеш. Минимум нужны TX/RX UART0 (но только определённые пины! - смотрите раздел ISP). P2.10 - на "0", в этом состоянии подаёте RESET на CPU (или просто включаете) и всё - вам доступно всё ISP-API. Хотя если вам для обновления ПО, а не для первоначальной прошивки, то лучше использовать IAP, а прошивку передавать по собственному протоколу обмена. Лучше смотреть UG на свой CPU. Соотв. раздел там есть.

Неужто в юзермануале на ваш CPU не описан McBSP??? :smile3046: Давно уж не использовал McBSP, но насколько помню - разделение каналов в нём временнОе. По временнЫм тайм-слотам. Т.е. - данные отдельных каналов (кодеков) находятся по-разным смещениям в клоках относительно фреймового импульса. Например: со смещения 0 клоков относительно начала фрейма - первый канал; R*1 - 2-й канал; R*2 - 3-й,...; где R-разрядность каналов. Период фреймового импульса устанавливается равным не менее суммы всех разрядностей. Каждый кодек должен иметь возможность установки величины смещения относительно фреймового импульса (например - по отдельному интерфейсу). Есть ещё McASP. Он позволяет и временнОе (по тайм-слотам) и по-канальное (он имеет несколько сериализаторов) разделение. А также - и то и другое одновременно. С ним можно использовать кодеки не умеющие задавать смещение относительно начала фрейма. Либо снизить частоту разнеся на разные сериализаторы. Получится. Иначе он не назывался-бы Multi-channel buffered serial port ;)