AVI-crak Home

Есно да, причём вариантов реализации низкого уровня вагон и маленькая тележка, каждый лепит своё, под свои задачи. Мне например нравится когда чтение/запись происходит без контроля из кода пользователя, само, автоматом. С использованием усечённой по самые яйца файловой системы. Второй вариант - быстрый. Это когда под пространство флешки создаётся огромная структура - куда ещё на уровне компиляции помещается всё необходимое. После чего обращение происходит по символьным именам, фактически по прямому адресу.

До этого момента нужно немного изучить доки на внешнюю флеш память. Там не слишком сложная последовательность действий при записи, все тайминги документированы, их просто нужно сложить в верной последовательности. А потом разделить размер сектора на это время - будет средняя скорость. Не думаю что вас устроит подобная скорость. Это уже не осцил как таковой, а почти логгер, просто чуть более скоростной чем обычно. В любом случае скорость ацп уже будет избыточной.

Смотреть, сохранять с последующим разбором полётов - это одно, а работать - совершенно другое. То-есть либо собирай осцил, либо кард-ридер. Для осцила понадобится внешний быстрый ацп, с подключением к dcmi интерфейсу - чтобы само работало. +Внешний чип юсб с оптической развязкой, и качественный кварц - хотя-бы из термостабильной серии. Мегагерцев для мк в этом случае мало не бывает, так-что лучше сразу взять что-то из F7, или Н7 серии. Без внешнего ацп получится версия аля али экспресс, и куча потраченного за зря времени. Ну а для кард-ридера достаточно двух внешних компараторов, две линии цап, и пары таймеров. Мк кстати может быть настолько ущербный, настолько позволяет совесть.

Да их там сотни, невозможно пользоваться всем сразу. Резать каталоги для маленького размера тоже не выход. Переписывать подключение библиотек откровенно лень. В результате при компиляции непрерывный водопад из сообщений - "не используется, удалено". А отключать не хочется, там иногда что-то полезное прилетает.

Кхм... Функция не используется и была удалена. Если подскажешь как избавиться малой кровью, буду благодарен. Но с условием удаления только этого типа предупреждения, а не всего разом - это я и сам умею.

Ну теперь хотя-бы понятно как оно должно на выхлопе выглядеть. Насколько я верно понял - нужен статичный сдвиг на 90 градусов, при этом частота должна зависеть от "показаний" ацп... Во первых - ацп и таймер это два разных клока, синхронными они никогда не будут. Значит нужен промежуточный буфер в виде переменной в памяти мк. Ацп туда будет постоянно писать своё значение, а таймер - читать. Фазы не совпадут 100%, но ошибок не будет. Второе - насиловать кучу таймеров совершенно не обязательно, достаточно одного. Но на него нужно натравить сразу два дма: по переполнению - чтение нового значения в регистр счётчика, и по линии сравнения - на прямую запись в регистр BSRR выбранного порта. Первое дма - режим цикл: 1 отчёт. Второе дма: режим цикл - 4 отчёта. Регистр BSRR позволяет менять состояние произвольного количества битов выбранного порта, не затрагивая остальные. Причём приоритет имеет установка лог нуля.

Ну если рассматривать вопрос с остановкой таймера - то да, так просто не делают. Его либо запускают на разовое исполнение, либо на цикл. Остановить в процессе - это всегда лотерея. Таймер может управлять дма, однократной и множественной записью. Для однократной записи ничего трогать не нужно, она и так сработает. А для многократной придётся настраивать базисный адрес, смещение, и количество тиков дма на одно событие таймера. Причём смещение может быть очень жирным, например сразу на несколько разных периферийных узлов. Можно натравить на запись кучи регистров самого таймера - запретов нет, но тупиковых вариантов целая куча. У таймера есть теневые регистры предварительной загрузки. То-есть при записи значения - оно попадает в теневой регистр, и только при активном событии - происходит обновление. И ещё, 30 лет назад таймеры были очень простыми в обращении, с минимальным количество возможностей. А сейчас это почти комбайн. По этому читать доку на чип обязательно. http://www.unirail.org/wp-content/uploads/2016/04/STM_TIMERS.pdf https://arm-stm.blogspot.com/2016/01/stm32f-timer-diagramm.html

Развязывай обратно. У меня есть реальные тесты скорости работы кейла иара и половины того что хрустит под гсс. Требовалось собрать прошивку для внешней 24q64, под завязку набитой графикой и звуками. Есно можно запустить на ней файловою систему, и обращаться к картинкам про имени файла... Но нужно быстро + камень имеет нативную поддержку квадрорежима для этой памяти. А это значит можно обращаться к графике через символьное имя, минуя файловою систему и программные функции чтения этой самой памяти. Достаточно собрать одну громадную статическую структуру для графики и звуков, и разместить её на адресном пространстве внешней памяти. Дык вот, собрать всё в один большой комок - не так уж и сложно. Сложность в сборке такого проекта. ГСС зависал на два с половиной часа. Кейл не прошёл тест, точнее я не дождался окончания компиляции. Иар был оставлен на ночь, и к утру он всё ещё трещал винчестером. Нафига всё это - а для скорости реакции интерфейса. Готовность за доли секунды после включения, экраны переключаются плавно и вовремя, и главное - в реальном времени работает то - что обычно требует отдельного процессора.

Кхе... странно. У меня первой задачей было подключить по интерфейсу dsi экран от нетбука, которых у меня много и даже один целый. Получилось коряво и нежизнеспособно, ширина памяти имеет значение в таких вопросах. Использование прибываний без ос - оно должно быть в зоне видимости майна. С ос - нужно прочитать соответствующий раздел доков выбранной ос. Там много нюансов, не вижу смысла перепечатывать. С ADC всё намного проще, прерывания от него есть - но использовать нет смысла. Зато у ADC море вариантов запуска, прямо-таки на все случаи жизни. Само ADC прекрасно умеет дёргать dma. А вот у dma уже есть нормальное прерывание - когда всё что требуется уже в памяти.

Несовместимо, но в оригинале написано красиво.

Что это? Это может быть чем угодно, только не сборкой текстовых данных на отправку, потому и спросил.

DrobyshevAlex - железо уже пришло?

42 (автостопом по галактике), не благодари. Мне кажется есть простое объяснение столь яркого отношения к халу у разных людей. Оно основывается на эксперименте со скрепками. Если на стол положить небольшую кучку скрепок, не больше 20-ти, то из этой кучи можно с большим успехом вытащить почти любую скрепку так - чтобы она не подцепила за собой соседнюю. С ростом количества скрепок такой фокус исчезает. Уже в процессе добавления скрепок в общую кучу - они сцепляются с другими, образуя длинные связи. И при определённом критическом количестве - достать одну скрепу уже практически невозможно. За одной будет подниматься уже 98% общего веса. Если только очень аккуратно положить, а потом так-же аккуратно поднять, при этом не шевеля всю кучу. Ничего не напоминает? А люди-то разные. Одни способны гордится любой получившейся фигурой монолита, даже без возможности что-то исправить. Всё новое будет посажено на китайский двухсторонний скотч, и заботливо обмотано синей изолентой. При этом комок этого г.. будет даже работать, если только не ковырять его слишком сильно. А другим требуется жёсткая иерархия и порядок на каждом уровне ступени привилегий. Без перекрёстных связей из разных слоёв программы. Такие проекты очень легко переносятся на новые камни, легко изменяются и дополняются. Всегда можно взять часть, и использовать в другом проекте. Как это происходит в реальности. Для инициализации FMC под халом - требуется три отдельных файла конфигурации, которые тянут за собой ещё около двадцати файлов. При этом нет чёткого места где происходит сама настройка, она почти вся косвенная. Да там есть структура для заполнения, но вот переменные для самой структуры - имеют слишком вольное представление. Приходится искать описание, что к чему подходит и при каких условиях. Прикол, если использовать весь связанный код в одном файле (да, я проверял!!!) - то его длинна будет выше двух тысяч строк!!! Некоторые части этого кода используются однократно, другие имеют перекрёстные связи, а часть - многоразовая. На регистрах получается 100 строчек, и в одном месте. В этом вся разница.

Это наверное уже не хобби, а основная работа. Когда имеющийся рога опыт мешает изучению нового материала. Ну не нужно изучать все регистры побуквенно, тот-же хал - вариация составных команд, изучать все вариации - сдохнуть можно преждевременно. Достаточно уловить суть работы с регистрами, последовательность чтения англоязычной справочной документации, и немного разобраться и id - хватит уровня обезьяны (кнопки нажимать). У вас ещё на первой странице должны были появиться вопросы выше уровня домохозяйки. Для этого достаточно запустить дефолтный проект от самой id, и приступить к его изменению. А чтоб дело было веселей - завести черепаху (обязана быть), и слить проект на гит или bitbucket.org. Не потому что это круто, а как инструмент обратной связи - который явно надёжнее испорченного телефона.

Не проблема, http://cxem.net/mc/mc.php - удачного заплыва.

Возможно имелось в виду весь доступный потенциал возможностей конкретно выбранной ос, без разбора работы алгоритма самой ос. Потому как я занимался именно разбором. Крайне муторное действие. Можете сами в отладчике пошагать по командам асмы ос, там уснуть можно до выхода...

Да я уже заметил... Вас постоянно кидает в крайности, от безумно простого - до задач уровня нобелевской премии. И подорожник тут не поможет.

Отличие очень простое, и сразу бросается в глаза. Программный код для больших машин пишется о чрезвычайно вольном стиле. Какое-то принудительное деление на отдельные потоки для задачи или множества задач - это всё стезя гиков и перфекционистов. Основная масса программистов даже не думает над этим вопросом, компилятор всегда умнее. В процессоре может быть разное количество ядер и аппаратных потоков. Но это не мешает выполнению программы. Для мк это дело выглядит несколько проще. Каждая отдельная задача всегда автономна, по сути это функция на Си с атрибутом "без возврата". Это означает что компилятор не отслеживает поведение задачи для анализа последствий в функции её запустившей. Для мк это просто новый кусок кода с автономным стеком. Сам код на ARM собирается и выполняется иначе чем на 86 машине. Прикол с параллельным выполнением двух задач в одном потоке как на 86 - тут не работает. Тут ужаснее и страшнее - часть функций одного потока могут выполняться одновременно. Эта хрень называется - предварительное исполнение кода (или что-то похожее по сути). Засунуть что-то ещё в один поток просто невозможно, там и так уже каша. По этому ос для ARM ядра просто сохраняет/восстанавливает все регистры процессора при переключении задач. Для задачи просто выключается машинное время пока другие работают. Спешу успокоить, ей не больно и она ничего не чувствует (наверное ). Ос для 86 сохраняет не все регистры, хотя вам лучше не знать как она вообще работает - для сохранения психического спокойствия. Ос для ARM бывают двух типов: вытесняющая, и потоковая. Разница в работе приоритетов. Для вытесняющей - приоритет позволяет буквально выключить все задачи ниже себя по уровню. Многим это нравится... Яркий пример FreeRTOS. В потоковом типе - все задачи выполняются независимо и безусловно, но разное время, которое тут является аналогом приоритета. Это позволяет одновременно запускать множество задач без потери производительности. Если задаче нечего делать в конкретный момент времени - она просто передаёт управление. При этом сохраняя сверх низкую задержку в реакции на внешнее воздействие. Это например embOS от segger. Кроме того ARM имеет аппаратную поддержку приоритетов прерываний, то чего нет в 86, пиков и атмела. И разные ос для мк по разному используют эту возможность. Некоторые складывают всё в одну большую кучу, и отдельно программно разгребают её содержимое. Потому-что выросли из маленьких чипов, когда аппаратной возможности ещё не существовало. Более свежие ос - дают возможность исполняться прерываниям в нативном виде. Оно и быстрее и проще. Для самих задач получается арифметика на уровне третьего класса средней школы. Допустим две задачи будут выполняться в два раза больше по времени чем одна. Но подобное представление только при решении в лоб. В реальности задача должна быть выполнена к моменту когда её результат будет кому-то нужен. Не сразу "кровь из носу", не потом после всех "я только спросить", а параллельно с задачей пережёвывающей предыдущую порцию данных. Это и называется - выполнить к моменту актуальности данных. К слову - вытесняющая многозначность меньше всего подходит под это дело, чисто физически.

Это не имеет значения для работы мк под ос. В составе ос всегда сеть таймер реального времени, типичное время 1мс. Две задачи будут выполняться кусочками по 1мс последовательно, общее время цикла выполнения будет чуть больше 200мс. Это если решение в лоб, то-есть вообще без оптимизации. В реальности задачи пишутся всегда и везде для определённой конечной цели, даже те что работают в цикле. Это означает что задача когда-либо достигнет точки выполнения, даже та что работает в цикле. Если мк не успевает выполнить задачу к расчётной точки времени - значит либо код гамно, либо мк слаб, или всё сразу. Но мне кажется что до применения ос ещё очень и очень далеко. Вам нужно разобраться с примитивными вещами, которые очень сильно отличаются от кода больших машин.

Это общее видимое действие, в реальности чуть сложнее. PLL - это управляемый напряжением генератор высокой частоты (VCO) + управляемые делители образцовой и выходной частот + фазовый детектор + аналоговый фильтр. Всё вместе получается PLL - дико нестабильная штука, с диким фазовым шумом, и с невероятной чувствительностью к напряжению питания и температуре. Но благодаря обратной связи в виде фазового детектора - выходная частота всегда совпадает по фазе с образцовой частотой. Фазовый шум не исчезает полностью, по этому для очень ответственных вещей нужно что-то внешнее. PLL - это блок который не может стартовать мгновенно, или заранее. Ему сначала нужно подать готовую, заранее стабильную входную частоту. В случае с внешним кварцем - необходимо дождаться пока он станет стабильным (опрос флагов готовности). Записать значения делителей в PLL. И только после этого можно включать PLL. + нужно дождаться пока он станет стабильным. Есно переключаться на использование PLL в качестве основной частоты мк - можно после настройки делителей за основным переключателем + настройки латентности флеша. Вся схема из кубика читается стандартно слева на право и сверху вниз. И точно так-же обслуживается.

Кхм, пожалуй стоит заменить на простое и понятное. Для исключения подобных ассоциаций. Хотя имело в виду совершенно иное - терпимость к новым ошибкам кода пользователя. С ростом сложности промежуточного слоя абстракции - добраться до реальной ошибки становится всё сложнее и сложнее. Дополнительные слои абстракции - это всегда двери в одно направление, как правило их очень легко закрыть, и многократно сложнее открыть. Самый яркий пример это естественно хал. На нём очень легко писать код. Но если что-то сломалось - то проще написать заново, чем разобраться в причине поломки. Чуть более сложное в понимании - внешние конструкторы настройки периферии и программного кода. Это то что не поддаётся логике и отладке в принципе (нет обратной связи). Это можно использовать или не использовать, и на этом опции заканчивается. Ну так вот, код в CooCox создаётся здесь и сейчас - буквально полностью помещаясь на экран. Там нет длинных ссылок с определениями и макросами на ещё десятке разных файлов. Оно конечно удобно, когда в конфиге меняется одно значение, и проект полностью перестраивается. Но всё хорошо в меру. В данном случае мера - это один конфиг, а не десяток файлов со сложной взаимосвязью. Рейтинг построен именно по этой методике - количество телодвижений в поиске ошибки.

Вопрос не в том кто и насколько преуспел в программировании, а в том где сейчас находится DrobyshevAlex. А ему сейчас нужен тёплый старт. Минимальный проект, который создаётся силами id, без внешних магических движений и воздействий. Проект, который всегда собирается без ошибок прямо из "коробки". Дык вот. По этому критерию лидирует CooCox. Можно сказать что его создали для этой цели - мягкого тёплого старта с чипами компании st. Далее идёт EmBitz, точнее его предыдущая версия Em::Blocks. Его создавали на базе Code::Blocks, путём длительной и очень тщательной кастрации всех некрасиво выступающих частей интерфейса. В результате id может работать с чипами st, и больше ничего. Но зато работает быстрее всех существующих платных и бесплатных пакетов id. И естественно имеет стартовые конфиги для наиболее популярных чипов. Потом идёт Keil, за ним IAR, потом плотной группой по уровню сложности: TrueSTUDIO, SW4STM32, SEGGER и так далее, и замыкает процессию Eclipse. Про Eclipse можно писать много, и очень желчно. Её судьба чем-то похожа на Code::Blocks. Она так-же стала прототипом для многих более крутых id. Но отличие в том что оптимизации не было. Весь этот монстр просто обрастал дополнительными слоями "удобных" плагинов, которые прятали всю избыточную сложность общения с id. Из плюсов - плагины есть для всего, всего что шевелится. Минусы - плагинов настолько много, что через некоторое время забывается сама цель поиска чего-то нужного. Установить самостоятельно Eclipse для неподготовленного пользователя - просто невозможно. Да, есть множество инструкций - но все они устаревшие.

Столкнулся лично. Одно дело когда разработку оплачивает большая компания, обеспечивает рабочим местом, доступом к железу, транспортом и так далее. И совершенно другое - когда комп твой личный домашний, при этом щедрость компании на него не распространяется. А мысля, она ведь и дома может сработать. Проект одной ревизии собирается в два немного отличающихся бинарника, причём отличие всегда случайно!!!

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

Насчёт ломанных кейла и иар - бесплатный сыр только в мышеловке. Эта ломалка не только всплывающее окошко закрывает, но ещё и запускает скрытые пакости от производителя. В результате проект будет собираться по разному - в платном и ломанном варианте. В ломанном варианте будет всегда присутствовать неуловимая плавающая дрянь, вызывающая весёлости разной степени тяжести. Самое безобидное - замена "о" на 0, в тексте на печать. Ну или стандартное - влетание в Default_Handler. Прикол в том что без выхода проекта за ограничение в размере - пакости не активны. Очень редко когда начинающий может так прямо с ходу накодить выше потолка. В большинстве случаев весь интерес ограничивается стартовым проектом. А дальше становится непонято, сложно, и не интересно. Странно что не упомянули EmBitz, но зато всплыл CooCox. Это-же просто не логично.