AVI-crak

Там написано что это снятие блокировки, но мне кажется это корявый перевод гугла. В реальности это очистка регистра адреса, который используется для мониторинга атомарного адреса. Прикол в том что когда __LDREXW и __STREXW применяется в прерывании, и перебивается другим прерыванием ровно между командами - при возврате получается глюк. Поймал пару раз, теперь просто ставлю CLREX. В майне любое прерывание работает как CLREX, команда короткая и простая, к тому-же с явным указанием перезагрузки операторов "memory". Этот барьер запрещает GCC размазывать функцию по всему коду, как он это любит делать. ---------------- Есть мысли? как в функцию передать адрес члена битовой структуры??? Гугол молчит на эту тему, наверное это особо_извращённая методика программирования, возможная исключительно под грибами (запрещёнными Законодательством Российской Федерации). Грибы есть, мыслей нет.

Атомарные операции не терялись. Вот только выглядят они как громадный костыль. Применимы к флагам которых безумно много, или как вариант - обязаны занимать минимальное место (не всегда правило). В общем у меня получатся так: глобальная структура с флагами ( ingl ) - цель, собрать в кучу мелкие имена флагов, строго 32б, ну и модификация с помощью стандартных команд __LDREXW и __STREXW. Поместил функции f_ask_с и f_ask_d в разные задачи, они там в цикле просто меняют свой флаг. Смысла в функции нет, потому как я не придумал способ передать указатель члена структуры (оно ниже физического адреса). Возможно можно перечислениями сделать, но как потом не запутаться - не знаю. Словом, если кто предложит решение - буду рад. typedef union { struct { uint32_t stop:5; uint32_t start:1; uint32_t a:1; uint32_t b:1; uint32_t c:1; uint32_t d:2; uint32_t e:1; uint32_t f:1; uint32_t g:1; uint32_t h:1; uint32_t i:1; uint32_t j:1; uint32_t k:1; uint32_t l:1; uint32_t m:1; uint32_t n:1; uint32_t o:1; uint32_t p:1; uint32_t q:1; uint32_t r:1; uint32_t s:1; uint32_t t:1; uint32_t u:1; uint32_t v:1; uint32_t w:1; uint32_t x:1; uint32_t y:1; uint32_t z:1; } Flags; uint32_t Flagi; } Flag_Type; Flag_Type ingl; static void f_ask_c (void); void f_ask_c (void) { Flag_Type tmp; do { tmp.Flagi = __LDREXW(&ingl.Flagi); tmp.Flags.c ^= 1; }while ( __STREXW(tmp.Flagi, &ingl.Flagi)); __CLREX(); } static void f_ask_d (void); void f_ask_d (void) { Flag_Type tmp; do { tmp.Flagi = __LDREXW(&ingl.Flagi); tmp.Flags.d ^= 1; }while ( __STREXW(tmp.Flagi, &ingl.Flagi)); __CLREX(); }

Я говорил о бюджете 200к, там посчитана вентиляция, ванны гальваники, ванны травления и ванны проявки фоторезиста. Именно ванны, а не домашние тазики!!! К тому-же это не всегда большой вес и объём, а часто даже наоборот - всё очень миниатюрное, максимально плоское и вертикальное.

http://www.pcbway.com/orderonline.aspx 100*100*1,6мм *5штук, 4 слоя, допуск 6/6mil, сквозные 0.3mm =48$ плата, 12$ доставка. Там ещё можно отдельно сбросить на доставке, но тогда они не гарантируют время. Кстати, китайцы продают реактивы для производства плат с переходными отверстиями (они всё продают), так-же как и текстолит 0,4мм, всё с бесплатной доставкой. Наборы как на один зуб, так и на вагон изделий, чем больше - тем дешевле. Общие затраты в пересчёте на ту-же плату 100*100 3~6 слой в домашних условиях ~ 300руб. (работу не учитываем) Есно нужно иметь горячий пресс, принтер с малыми геометрическими искажениями, ванну гальваники, и конечно качественную чпу сверлилку. Общее первоначальное вложение в данное направление для себя лично - более 200к. Самое дорогое - это принтер. Китайские подделки за 5к не подходят по уровню искажений. Идеальный вариант - станок прямой засветки фоторезиста. Набор может быть накопительным или кумулятивным, но ниже планка не опускается. Изготовлять 4 слоя дома получится только после покупки всего необходимого оборудования. Зато потом можно открывать свой собственный свечной заводик, примерно 4 платы в час в режиме конвейера. По получившемуся рисунку платы - размер переходных отверстий слишком мал. При заказе у китайцев получится дорого. Тут не в диаметре отверстия дело, а в размере пятака. У них разные нормы на совмещение трафаретов.

Страх и ненависть в Лас-Вегасе - фильм, по сценарию которого назначались функции на лапы чипа st.

Переходы слишком малы для домашнего изготовления пп, а для заказа можно и 4 слоя сделать. Разница в ценнике не столь важна как потраченное время. Землю на двухслойке можно и нужно располагать с двух сторон, с таким расчётом что-б на просвет всегда земля была - сверху/снизу или одновременно. Гнаться за малыми габаритами нет смысла, вы уже отказались от 4х слоёв. Земля если и уходит в переход - то должна иметь минимум три точки в разных местах, идеально -треугольник. Аналоговую землю вести отдельной линией, токи там малые, но смещение в попугаях ацп может получиться большим. Керамика на питании, кроме VCAP 2-4мкф - остальное можно смело ставить 0,1 и 0404 размер. Возле стаба кубик больше габаритами, и rc цепочку, ну или электролит.

[CENSORED] Разводка очень проста - подложка земля по всему пути вч линий, цвета и синхру нужно делить барьерами земли на стороне линий. Земли как можно больше. Иначе получится как у меня в первом варианте, дребезг произвольных разрядов rgb - помеха от sram.

Реальность, китайский автономный чпу станок, работает совершенно автономно, без постоянной связи с компьютером, по "программе" записанной на флешке. Дык вот, G код на флешке - это откомпилированная программа или всё-же набор управляющих команд?

В этом случае оперативно правится не сама программа - а только последовательность команд управления. Это возможно на любой стадии выполнения этих кодов, ничего сверхсекретного и магического. Это между прочим практически пользовательский уровень. Например работает вентиляция - можно оперативно перенастроить режим открытия/закрытия заслонок в общей системе воздуховодов, можно назначить новые условия срабатывания триггеров, можно вообще отрубить вентилятор. Просто необходимо понимать, что это система реального времени. Новая последовательность команд выполняется не с самого начала - а с момента назначенного времени, либо с момента срабатывания новых триггеров. Грохнуть программу в рабочем режиме - ну никак нельзя. В случае дублирования - невозможно грохнуть сравнивающий узел. И уж никак нельзя грохнуть или исправить саму ос. Но если подобный садомазо режим существует - я требую детального объяснения его алгоритма работы. С наскальными рисунками - выполненные кровью убитых мамонтов.

1000 запущенных активных задач - это уже перебор. Мне удалось запустить примерно 320 копий с двойным падением производительности, 600 копий теоретически дадут падение в 7 раз, а тысяча - уже в 20-50 раз замедление. На вытесняющей ос такое количество задач просто невозможно запустить. Но смысла в диком количестве работающих задач - нет. Сама ос должна висеть в кеше, так-же как и почти все аппаратные прерывания, у каждого мк свои варианты - ускорится всегда можно. Но есно ос одноразовая и единственная, работает от старта мк и до ресета, обновлению не подлежит. Весь низкий уровень обновлению не подлежит, это всё что работает с периферией. Очень желательно ассоциативный слой тоже сделать постоянным, иначе будет маленький ужас. И того, меняться может математика в чистом виде, графика, и наборы инструкций во всех смысловых вариантах. Всё это очень много весит. Менять внешнюю задачу или подменять - невозможно чисто физически. Любая задача работает не в чистом вакууме, она должна взаимодействовать с внешнем миром. Обрубать связи которых нет в новом варианте задачи - означает получить верный висяк. Вместо этого любая задача в удобном для себя месте содержит проверку на реакцию ос, ну типа нужна я ещё тут или нет. В случае когда ос просит задачу убиться об стенку - в самой задаче начинается протокол закрытия внешних связей. И да, удалять задачу корректно - может только сама задача. Ос может грохнуть выделяемое место памяти и время работы, о внешних связях самой ос ничего не известно. Чистка памяти - даже не смешно. Под любую задачу выделяется именные блоки памяти. Именно по имени они и грохаются. Когда задача активна - она может выделять и грохать собственные блоки памяти в рандомном хаосе, но при завершении исключений нет. Совместное использование памяти имеет свои ограничения, по сути - это обмен сообщениями, всегда однонаправленный. В одном ограниченном блоке памяти первая задача пишет и может читать, вторая и остальные задачи - только читать. Есть исключение для операции - занять ресурс, или что-то подобное. Цель - вписать свое имя, имеется поддержка на уровне команд асмы, ограничение - uint32_t размер, выше нет смысла, ниже - просто глупо. В любом случае общение задач выполняется через выделенную память по веткам структуры стандартного вида (размер резиновый). Вид структуры задаётся один раз, на этапе написания ос. Но не является стандартом для всех проектов без исключения, скорее наоборот - для каждого проекта - своя уникальная структура связи. Использование внешней памяти позволяет дописывать новые функции на свободное непрерывное место. Удалять сами функции уже не получится, но когда размер флешки большой - можно устроить глобальную перегрузку девайса с удалением и дефрагментацией. В любом случае система получается очень близкой по функционалу к домашнему настольному компу. В некоторых случаях проще использовать жирные макетки от интел или нечто арм-овское на андроеде. Особенно если у вас реально 1000 активных задач. Мне-бы хотелось взглянуть на подобного монстра, а ещё больше интересует склочная команда поддержки из многоэтажного центра управления. Иным способом штамповать обновления просто невозможно. Гораздо безопаснее менять всю прошивку одним махом, неважно сколько времени и как она будет грузится - важно что она будет проверяться на ошибки на всех этапах.

Есть вариант - внешние функции на внешней памяти запускаемые по внешнему событию (буквально). В этом случае каталог функций можно разместить на внешней памяти, будет одна точка входа. Определение номера внешней функции для запуска - универсальное, описывается как изменяемое внешним процессом, в этом случае gcc не оптимизирует этот код до нуля. Ну и естественно варианты: исполнять код по месту хранения, или предварительно копировать в память - от этого зависит способ компиляции. Чем дальше в лес, тем больше дров можно наломать. Часто проще менять всю прошивку, даже если она весит гигабайты.

Как это - дырки между секциями??? По дефолту gcc самостоятельно может заполнить первую секцию, для второй необходимо ручным способом помечать функции и дату. Однако мне ентересно, как gcc будет лить автоматом то, что не влезло в первую секцию. Желательно с наскальными рисунками.

Разницы нет. Карту адресов смотрят в референсе - самая жирная дока. Осталось выяснить какой именно у вас чип, иначе дальше не продвинетесь. Дока на серию http://www.nxp.com/assets/documents/data/e...56M150SF3RM.pdf 0x000FA000 - реально в молоко попали, там пусто.

Я не понимаю слова "эксепшен"... Читать флешь память можно двумя способами, по прямому адресу и через мапинг. Прямой адрес флеша для st - обычно висит на 0x08000000. И читается/пишется исключительно родным для этой флеши размером посылки. Каким размером читать/писать - нужно смотреть доки на конкретный чип. Первый попавшийся пример из инета http://easystm32.ru/for-beginners/38-flash-stm32 И через мапинг, с нулевого физического адреса. По этому адресу может оказаться как флеш память, так и рам память, и даже внешняя память. Всё зависит от состояния ножек boot, и регистров переадресации мапинг. В случае когда по дефолту загрузка идёт с флеша (без всяких ускорителей как M7) - то флеш становится доступной для чтения с нулевого адреса. Вот тут её можно читать как угодно, и вдоль и поперёк и по 8 бит и по 64 бита за раз - как хочется. Все эти выкрутасы обработаются системной шиной - именно она будет читать флешь память. Записать через шину не получится.

Прежде чем что-то писать/читать из флеша - нужно расставить буйки. Точнее поделить основную флешь память на две части ещё в линкере. Назначить уникальное имя для оставшейся части флеша. Создать статическую структуру с расположением в этой части флеш. Запихнуть в структуру всё что требуется, со всеми немыслимыми выкрутасами. Например это 20 копий секретной инфы, которая должна меняться при каждом важном для вас событии. Если хорошо постараться - то можно уместиться в две-три страницы. Есно структуру объединить с более простым и наглядным двойным массивом. В событии будет запись новой структуры на чистое место, или стирание страницы и записи на новое чистое место. Поиск по возрастающему номеру в записи (для каждой страницы отдельное пространство цифр, например от 1 до 10, и от 11 до 21). Проверка на ликвидность записи - по чтению копии, и сверке rcr. Битые ячейки рано или поздно появятся, это норма. Тогда можно полностью избавится от указателей, и попаданием пальцем в небо. И главное - стабильное выполнение программы в не зависимости от уровня оптимизации. И ещё, memcpy, если это ваша личная функция - то написана она явно не слишком аккуратно. Флеш память мк в принудительном режиме читается/пишется по 8-16-32-64 бита - у разных моделей по разному. Зависит от конкретной модели мк. А прямая запись с неродным размером приёмного регистра - просто не корректна.

В моём понимании "выключен" - снято питание. Режим сон - есть питание, выключена периферия и остановлено ядро. Если отключить ещё и память (нет смысла) - то для отладочного интерфейса остаются регистры ядра. Режим стоп - остановлено ядро (потребление почти ноль), работает необходимая периферия. Из этого режима можно отладочным интерфейсом читать память. Насколько я верно понял - вам именно это и нужно. Есть выход, http://www.emblocks.com/forum/viewtopic.ph...89282df567ec09e Там всё просто. Есть буфер - который заполняется сообщениями от системы, есно когда она работает. Отладочный интерфейс читает этот буфер с максимальной скоростью без остановки ядра, как обычную память. Общаться можно в обе стороны. Этот режим отладки идеально подходит для систем реального времени. Хотя мне проще задействовать четыре контакта для варта, и через оптику. Насчёт ногодрыга, отправка сообщений через SWO - лишь частично аппаратная, проверку условий необходимо выполнять ручным способом. Это означает что таск работающий с отправкой сообщений - будет выполняться со скоростью физического порта. Тот-же варт можно пнуть через дма, и заняться другими делами.

И убить статикой нормально работающий дорогой девайс? увольте. Если хочется снимать логи, для этого есть куча возможностей. Начиная от варта с оптической развязкой, заканчивая запаянным на пузо чипом esp8266, без платки он занимает минимальное пространство. А мой последний логгер общался через вч пищалку, потому как висел на шине в десятки киловольт (буквально). Тут прикол в том что девайс может управлять массивной железякой, которая при наличии движения/вращения - может натворить не мало бед в случае сбоя основного чипа. Сломанные резцы, отключившийся насос, вентиляция не вовремя, или даже просто внезапно сработавшее силовое реле может стоить чей-то жизни. Когда ваша печатка с мк начинает реально управлять внешним оборудованием, доступ к ней должен быть ограничен. Это как замок на трансформаторной будке, все знают что может убить - но без замка идиоты всё-же находятся.

Чтобы задействовать тактирование, и вписаться в 5% допуска. Иначе частота может получится любой, и детект на приёмной стороне будет намного сложнее. Мне просто интересно, зачем внезапно понадобился SWO в автономном режиме? На чипе просто дофига аппаратных интерфейсов, нет - будем ногодрыгать через swo.

Первая ссылка из гугла http://pyviy.blogspot.ru/2010/12/gcc.html

Вы хотите установить большой жидкостный ракетный ускоритель на свой велосипед... Оно может-быть и будет двигаться, но исключительно по прямой. Cortex-M7 и даже А9 - бесконечно слабые камни для такой графической карты. И проблема в том что они не в состоянии нагрузить полезной нагрузкой такой ускоритель. Естественно, можно написать очень маленький рекурсивный код - который повесит абсолютно любую машину, но смысла в этом мало.

Туда не влезет блок питания и радиатор, чтобы отвести 37 ват тепла. SII - Это новая железяка, рекламируют как могут.

Прикольно чип на части разбит, я-то монстров рисую в натуральную величину... Кстати, а это случайно не кеш барахлит? И ещё один вариант - полностью убрать хал: https://electronix.ru/forum/index.php?s=&am...t&p=1453129

Это из доки: This register sets the refresh rate in number of SDCLK clock cycles between the refresh cycles by configuring the Refresh Timer Count value. Example where 64 ms is the SDRAM refresh period. Refresh rate = ( COUNT + 1 ) × SDRAM clock frequency COUNT = ( SDRAM refresh period ⁄ Number of rows ) – 20 Refresh rate = 64 ms ⁄ ( 8196rows ) = 7,81μ s 7,81μ s × 60MHz = 468,6

Примерно так. Refresh rate = ( 64 ms ⁄ ( 8196rows ) ) * 90000000 = 702 Кстати, в случае когда настройка sdram начинает кочевать из проекта в проект - проще один раз написать макрос вычисления этого числа, и забыть о проблеме.

Офигеть, так это ваш личный проект... Тогда проще делится через сторонние сервисы, например bitbucket.org . Только ссылку давать не на колонирование, а на готовое скачивание, например так https://bitbucket.org/AVI-crak/rtos-cortex-m3-gcc/downloads . А то они и тот сервак уронят. И конкретно по проекту - как так получилось??? (смотрим фото)