AVI-crak

У меня всё согласованно, даже бумаги с гербовой печатью есть, от этих самых старших товарищей. Но смысл того что я написал выше - намного проще. Не нужно вдаваться в мелкие детали - основное лежит на поверхности. Те модули что продаются от больших компаний - не пригодны для практического применения. Ни со стороны экономии, ни со стороны надёжности (свой колхоз всё убьёт), ни со стороны наличия требуемых интерфейсов. Идеальный модуль создать просто невозможно, найдётся задача в которой он будет не оптимален. Однако если самому делать такой модуль - то выгода есть. И кстати - получается даже дешевле чем покупной.

Показать не могу, NDA и всё такое. Даже специального человека наняли - чтобы он бормашиной сдирал названия вражеских микросхем. Частотник внешний, тоже отполирован бормашиной. Потому что у нас самая защищённая вычислительная техника в мире. Драйвера для сервоприводов на майне, но там нет экстрима. Ахтунг в требовании опторазвязки для всех внешних датчиков. Движки военные, качественные, тяжёлые, коллекторные, и дико искрящие. Металл наш, по ходу с консервации. А самое прикольное. Раньше на этом станке стаяла электроника собранная на советской рассыпухе, и каким-то невероятным образом позволяла изготавливать кривые зеркальные поверхности на металле и стекле (линзы, параболы и так далее). А у меня по началу получалась аккуратная ступенька... Логично. На шести слоях нет надобности в дополнительных экранах. А вот на двухслойке... без разделения землёй провести линию рядом с другой шумной линей - просто невозможно. К тому-же эта ситуация начинается уже в шлейфе - так зачем тянуть...

Давай считать: usb 2+(3 земля)+2(управление)+1(детектор)= 8 - otg порт usart 2+2(cts/rts)+1(земля)=5 - развязка по оптике на основной плате usart*2 2+1(земля)= 6 - два ведомых интерфейса на майне tim(encoder)*5 2+1(земля)+1(подтяжка)= 20 - энкодеры с развязкой по оптике tim 1= 1 - шим для управления питанием adc*3 1+(1 аналоговая земля)+1(vreg) = 9 - mcp6s28 3 штуки на майне spi 4+3(земля)= 7 - управление внешним mcp6s28 и расширителем портов на 74hc594+74hc165 tim*3 1= 3 - шим для сервомоторов spi 4+3(земля)= 7 - ведомый st чип sdmmc 6+1+6(земля)+1(питание)= 14 - разъём для sd карты eth 6+3(земля)= 9 - выход на трансформаторы развязки rj45, физика стоит на многослойке. 4 линии +2(земля)= 6 подключение резистивного тачскрина, разъём на многослойке, мозги на майне. dac*2 2+2(земля)= 4 -управление шпинделем, +динамик. 1 видеовход 1+1(земля)= 2 - ацп подключен к dcmi интерфейсу на многослойке, чёрно-белое изображение используется для юстировки инструмента. 10 горячих контактов с прямым подключением к чипу st (через защиту)= 10 - управление питанием, режимом инструмента, большая красная кнопка стоп... питание 5в = 7 контактов, земля распределена между экранами. Используется два разъёма FPC-60 по краям шестислойной печатной платы 6*5см. Майн 20*15см - двух_слойка. Этот бутерброд используется для ручного и автономного управления токарным станком. Цена разработки космическая, впрочем - я всей этой суммы не увидел... Использовать для этой цели готовые модули с линуксом - не выгодно. Хоть там и гигабайты с гигагерцами - а отклик в режиме реального времени получается чудовищным.

У вас модуль имеет размеры чуть больше площади используемых бга компонентов. Предложенный вами штыревой переходник займёт площадь больше чем сами чипы. Второе, использование разъёмов с очень мелким шагом (и габаритами) - переносит технологические нормы разводки пп на основную печатную плату. С чем боролись... Есть выход: FPC- коннекторы разного шага но одинакового количества пинов + шлейф изготовленный печатным способом на пластике (есть такие). Это единственный вменяемый способ выполнить соединение на 40+ контактов без роста стоимости многослойной печатной платы. Ну и возможность оперативно почесать пузико у многослойки - как бонус.

Слишком долго считает. Регистры TIM1->CCR1 не имеют теневых аналогов как у TIM1->ARR, записанное в них значение сразу начинает сравниваться. Но выход есть, завести статическую переменную, в которую считать новое значение, и при прерывании переполнения (не сравнения!!!) - записывать в регистр значение статической переменной. Получится минимальная задержка обновления, и стабильная задержка на один отчёт - которую уже можно компенсировать.

М7 может выполнять код из ITCM в режиме шины AXI. Это нулевая задержка. Памяти мало, может уместиться вектора, перемывания и критический код. Стек нужно натравить на DTCM, что не совсем очевидно(стек ниже данных). Там-же расположить критические данные. А всё остальное - на свободные банки памяти и флеша. Задержка 5 тактов на 200 МГц вполне возможна, однако бессмысленна. Чип обладает развитой периферией, в которой эти задержки программируются в режиме инстала. Разная память, разные правила, настраивать регионы памяти - обязательно. http://forum.ixbt.com/topic.cgi?id=48:11266:2178#2178

В чипах STM32F4 и выше - ремапа нет, в реальности нога процессора выбирает периферию. Однако можно получить вечный жёсткий отказ шины данных в случае двух ног мк на одной периферии в случае входа, выход успешно переваривается - но не имеет смысла.

А что произойдёт с адресом выделенной памяти после вторичного вызова функции?

Дык это программный ресет, при аппаратном ресете отладчик не успевает подключиться, по крайней мере у меня.

Я говорю о том, что в момент аппаратного срабатывания триггера выбора загрузочного интерфейса - всё остальное отключается!!!!. Потому как сам механизм записи в память флеша - не имеет арбитра. Да и всего остального фарша - тоже.

КАК? Каким образом смотреть содержимое ядра и адресного пространства мк в режиме явного срабатывания загрузчика по usart??? Вопрос на миллион баксов!!!

Режим отладки в памяти. Программа в флеш выполняет две функции: запись адреса стека (аппаратная команда), меняет адрес массива векторов прерываний (аппаратный переход на ресет), повторный переход на новый ресет в памяти мк. При физическом нажатии ресета - память sram не искажается. Запуск кода из допустимых для данного мк областей памяти - память sram не искажается. Ресет не искажает память. Запуск бута в режиме программирования (после успешной синхронизации!!!) - всегда портит stam и стирает флеш при включённой защите (сразу!!!), стирает сам флеш по секторам при программировании (последовательно). Без успешной синхронизации - содержимое памяти не искажается при ресете. Бут является аппаратным механизмом, без использования ресурсов ядра и памяти. Но в момент полноценной работы - память stam используется в качестве буфера. Адреса массивов являются аппаратными, изменить их нельзя. Максимальный бардак в памяти получается при загрузке через usb. Вас не должно волновать содержимое памяти после срабатывания бута - к этому моменту у вас уже поменялась прошивка.

case(OpenTCP): //Открытие TCP { // printf("\rOpen TCP Session\r");// GSM_State_Mashine = ConnMQTT;//Успешно GSM_Mashine_Errors = 0; // if(GPRSConnect1(TCP, MQTT_BROKER_SERVER, PORT, DEFAULT_TIMEOUT*8, DEFAULT_INTERCHAR_TIMEOUT*5) == 0) // { // эта функция всегда возвращает аргумент в регистре R0, выделять новую переменную для этого не нужно. printf("\rError TCP Open... Try Again...\r");// // int T = GPRSClose();// не вижу повторного использования Т GPRSClose(); GSM_Mashine_Errors++;// break; // } // GSM_State_Mashine = ConnMQTT;//Успешно GSM_Mashine_Errors = 0; // printf("\rTCP Session Open\r");// break;

Чтобы не ресетить девайс - нужно изначально закладывать архитектуру здоровой OS, с отдельным стеком прерываний и куче стеков задач. В этом случае запуск/отключение и управление уровнем прерывания - осуществляется через активную задачу, которая вызывает системное прерывание с заведомо максимальным уровнем. Без блокировки!!! Править уровни прерываний и их очереди в теле пользовательских прерываний - это есть громадный костыль, означающий что программист накосячил в нескольких местах и не смог исправить. Если прерывание пользователя зависает в бесконечном цикле - то лучше сразу сменить род деятельности, пока более опытные товарищи вам ноги руки не по отрывали. Уход в глубокий сон выполняется по команде OS, после чего все активные задачи должны свернуть свою деятельность и уйти в зависимость, вот после этого можно сохранять на флеш - активную память задач и их стеки, с последующим отключением питания. Предусмотреть все ньюансы работы периферии - просто невозможно. Однако в самой активной задаче - вполне реально. Просто блок инициализации будет выполняться повторно при перезапуске в каждой задаче отдельно. Глубокий сон - весьма специфическое требование, его трудно выполнить качественно, всегда придётся идти на компромисс. Гораздо чаще делают более простой вариант - сохраняют только данные объявленные как статические - в энергонезависимой памяти. С копированием их в память при запуске и сохранением перед отключением.

На случай аварий - системой уже предусмотрено несколько стандартных аппаратных прерываний разного уровня. От мягких программных, до жёстких системных. Собаку можно обработать программно, и успеть перевести внешнюю периферию в необходимое для выключение состояние. Например полностью блокировать внешний силовой драйвер мощных транзисторов, да и вообще отрубить всё питание. Чтение мимо адресного пространства BusFault - можно поймать отладчиком, вернуться в точку остановки кода, и найти сбойное место. Часто причиной сбоя является неисправность указателей, тогда приходится искать намного дольше. Модуль защиты MPU - на самом деле замечательная вещь, на M4-M7 без него никак. Дело в том что ядро обрабатывает программный код на конвейере, дополнительно - сам код собирается для внеочередного исполнения. GCC знает про MPU, и умеет использовать его настройки. Например для линейной области памяти управления почти всей периферией (0x40000000 - (0.5G)) - запрет кеша, сквозная запись, запрет обратной записи, запрет исполнения кода, ожидать выполнения физической записи. В этом случае состояние периферии будет меняться программой - как задумал пользователь, но не как удобно GCC. Дополнительно - конвейер команд будет сбрасываться при обнаружении обращения к области периферии - чтоб ни одна сволочь вперёд очереди не проскочила (типа я только спросить). Если при таких настройках выполнить переход на адреса периферии (исполнение программного кода) - то сработает прерывание MemManage_Handler. Оно является мягким, и его можно обработать возвратом в программный код с поиском ошибки. HardFault - являться жёстким отказом системы, его можно обработать ручным способом, и даже найти место сбоя - но невозможно исправить в реальном времени. Ну и всё скопом по порядку: Reset_Handler - стартовый адрес прошивки NMI_Handler - неизвестное прерывание Default_Handler, любое из неопределённых HardFault_Handler - отказы: шины, арбитра памяти, сбой чтения вектора прерываний. MemManage_Handler - ошибка доступа к памяти, срабатывание правил MPU BusFault_Handler - чтение/запись по недопустимому адресу UsageFault_Handler - прерывание специально для пользователя, можно оформить как критическую секцию часть прерываний от старших ARM процессоров вырезана тупым ржавым скальпелем, ещё не успело зарубцеваться SVC_Handler - крутое прерывание пользователя из разряда - пусть весь мир подождёт DebugMon_Handler - запуск кода отладчика на ядре мк в момент контрольной точки, остановка ядра после кода - для считывания данных отладчиком пусто PendSV_Handler - типа удобная функция для переключения контекста, я так не думаю SysTick_Handler - самый примитивный таймер во всей системе, он даже не полностью 32 бита. /* External Interrupts */ WWDG_IRQHandler - сторожевая собака, гавкает когда перестают ходить строем

f7 h7 - имеют физику USB2.0 на кристалле чипа, внешняя физика не нужна. И кстати - достаточно шустро работает.

Где именно вы умудряетесь нарушить алгоритм? 1 прочитать в ЛОКАЛЬНЫЕ переменные указатели кольцевого буфера 2 обработать данные (записать или прочитать), если таковые имеются 3 переписать ОДИН указатель по ЗАВЕРШЕНИЮ работы с данными. Прошу внимательно прочитать, и дать простой ответ под номером строки 1-2-3. При выходе из этого цикла данные записанные в буфер теряют актуальность. Не в том смысле что их можно портить, это больше похоже на лог, данные не актуальны в следующий момент времени. Например нельзя дописывать в буфер или прочитывать старое уже после выхода из полного цикла, данные теряют актуальность, и могут затереться другим процессом. Прервать алгоритм можно в любом месте, например прерыванием или переключением задач. Главное корректно его восстанавливать.

Да это вообще не из этого мира. Часть инстала часов реального ремни. int rtc_initialize (void) { /* Enable PCLK to the RTC */ __set_PCONP(PCRTC); /* Start RTC with external XTAL */ RTC_CCR = 0x11; /* Stop PCLK to the RTC to reduce battery power consumption */ __clr_PCONP(PCRTC); return 1; } Я-ж говорил - всего один бит....

Применимо к кортексу в целом - это запуск резервного домена питания. Домен связан с часами реального времени не только питанием, но и системной шиной. (или наоборот) В lpc это просто один бит, в stm больше движений - но и возможностей по более. Нужно смотреть документацию конкретно на этот узел от lpc, точнее под конкретный чип. Потому как BKPSRAM имеет питание 2,1в, и очень низкую частоту такта. Подать питание на память - это пол дела, транслятор уровня заметно кушает - и его не всегда держат в рабочем режиме. В данном случае транслятор уровня - это разрешение доступа к памяти. Нужен конкретный чип, без xxx.

Да ёёёё. Кто-ж использует кольцевой буфер для физических устройств????? Для физики все (без исключения) применяют линейный буфер: одинарный или двойной - для одного!!! направления. Спокойно создаём сообщение, дожидаемся готовности физики, и пинаем дма. Всё, тайминги в порядке, процессорное время свободно, мозг никто не клюёт.

Я не понимаю, как читающий может переписать чужой указатель??? Ну не успели выбрать все данные, или наоборот - положить всё что нужное в буфер. Конец света от этого не наступает, успеете сделать когда будет такая возможность. Не понимаю, зачем жопу рвать на британский флаг??? По поводу неуловимых глюков. Я уже писал насчёт проблемы использования внешних глобальных переменных с атрибутом volatile. Прямое использование в функции под GCC4,8 и выше - будет давать ошибку. Например в простом выражении где А - внешняя глобальная volatile переменная. А= (А+ В +С +Е)/2 переменная А будет физически переписана 4 раза!!! Потому что она volatile и внешняя. Чтобы избавиться от подобного - необходимо объявить локальную переменную в пределах функции, и работать уже с ней, и уже готовый результат переписать в внешнюю А. По этой причине большая часть кода написанного под GCC4.2 - глючит. Когда стало широко применяться внеочередное исполнение инструкций в коде ARM процессоров (GCC4.8) - вздрогнули все аурдинщики, без исключения. Это отдельная тема, но вы должны быть в курсе.

Не плюй в колодец, пригодится. Сначала проверяем свободное место, потом пишем данные, потом переписываем указатель. Сначала проверяем наличие данных, потом их читаем, потом переписываем указатель. А для USART кольцевой буфер мало подходит, для него необходимо иметь два линейных!!! Переписывать данные в ручном режиме, дабы дма могло нормально работать. (я охреневаю от всплывающих подробностей :twak: )

UM10211.pdf Искать 4.8.11 Power domains Искать 26.9 Battery RAM Это дока общая для LPC23XX, конкретная реализация зависит от полного названия чипа. Бегло, PVD механизма контроля питания в lpc - нет. В этом случае нужно использовать внешний аппаратный монитор питания. В навороченном варианте - это отдельный чип, в простом - резисторный делитель напряжения питания до стабилизатора чипа, например 5в. Подобрать номиналы до уверенного срабатывания лог уровня на ноге чипа, использовать внешнее прерывание с максимальным приоритетом.

Конкретный пример кольцевого буфера на Си. Сначала проверяется возможность записи данных, и только потом пишется, и только после этого указатель переписывается. Сначала проверяется возможность чтения, потом читается, и только после этого - переписывается указатель. Кстати, лично у меня использование глобальных переменных в функции в прямом виде - приводит к их использованию в виде локальных переменных. В результате любое изменение сразу записывается в память (это грёбаное ускорение от GCC). Чтобы этого не происходило - нужно глобальные перемененные переписывать локальные принудительно, и уже с ними работать. Этот глюк появился в GCC с переходом от 4,2 до 4,8 версии. Кроме всего прочего, частое переписывание указателей (по чайной ложке) - это банальная нагрузка на память. Буфер всегда должен иметь хотя-бы один пустой элемент, это есть защита от глюка. Одинаковые указатели - признак пустого буфера.