haker_fox

Я, наверное, не в теме. Но коим образом процессы, происходящие внутри ОС Android и инициированные компанией Google, должны повлиять на выбор инструментария в нашем деле? Под "нашим делом" я подразумеваю программирование для встраиваемых систем, измерительных приборов и т.д. и т.п., а не мобильные и веб-приложения. Тем более исходный вопрос автора темы, как я понял, лежал в этом же русле встраиваемых систем.

Шта???? Опять??? 2023 год заканчивается. Неужели осталось ещё место для войн в стиле vs.? Ну, а если по сути, то где и кто заменяет Си++? На что и какими регламентами руководствуются?

Нет. Это всего лишь английские термины, которые могут быть использованы в любых программах. А язык написания программы абсолютно не важен.

Ну что ж, я узнал что-то новое - день прожит, как в своё время говорил мой сенсей, не зря! Спасибо! Выходит, что никто не заблуждался, все были правы с учётом собственного опыта...

Так дело не в процессоре, а в шине AHB. И я ожидал бы BusFault/MemManageFault. У других микроконтроллеров, даже фирмы ST, вызывает.

Адрес функции HardFault_Handler точно находится в используемой таблице векторов в соответствующем слоте? Это по map-файлу проверено? Это очень странно, что HF не вызывается при "записи" во Flash. Хотелось бы докопаться до сути.

В обработчике Hard Fauld стоит bkpt #0, а программа, после "записи во FLASH" запущена на исполнение? Т.е. выполнена ни одна команда STR, а и несколько после неё?

Возможно, это отдано на откуп производителю микроконтроллера. У меня нет STM32F405. Но есть LPC4337. Ядро то же самое. Запись во флешь приводит к Hard Fault с ошибкой шины. И это логично, т.к. мы фактически записать данные не можем в эту область данные, минуя специальный контроллер. GD32F450 ведёт себя также, вылетает в исключение. P.S. А Вы не смотрели в errata? Может быть для STM32F405 описанное поведение как раз ошибочным является? И задокументировано? P.S.S. Заглянул сам в errata. Такое поведение не описано, но, судя по количеству задокументированного, микроконтроллер с ошибками. Возможно, что данное поведение просто не отражено.

Возможно, что у группы "Новичок" не работает почта. P.S. Ну, и не "модера", а "модератора". Второй вариант более благозвучен, как мне кажется.

Вам не кажется, что написанное - противоречиво? С одной стороны я читаю "отлично работает запись", с другой стороны - "только не изменяется ничего". Если ничего не изменяется, то это уже не отлично. Это уже - провал. Это неуместное и неостроумное предположение можно развеять просто просмотрев мои сообщения и темы на этом форуме даже не за 20 лет, а хотя бы за полгода.

Если Вы заинтересованы в профессиональной работе с ядром ARM, то Вы должны (или Вам следует) прочитать на него вообще документацию полностью. Понятно, что делается это не за один вечер, и, возможно, не за одну неделю. Можно почитать по диагонали, неважно. Но хотя бы Вы будете знать об основном устройстве ядра и о том, как оно работает. Не хотите читать официальную документацию, допускаю такое - она объёмная и разрознена по разным файлам, но почитайте популярную книгу Дж. Ю. (Joseph Yui) по Вашему ядру. Я всегда её рекомендую. И в своё время я её прочёл. Там есть среди прочих глава о прерываниях. И вот в ней-то и сказано, что содержимое регистра LR определят место, куда вернётся ядро при выходе из прерывания. Поэтому в LR находится не адрес, а вполне себе конкретная сигнатура, одна из нескольких (на изусть не помню, но знаю, где посмотреть и этого достаточно). P.S. В этих же книгах есть и описание HardFault, а также примеры обработчиков.

Налицо проблема неполного понимания работы инструментария: 1. В какую память и что помещается. 2. Как, даже если строка и укладывается в ro-память, она может меняться? Тут хотя бы в дизассемблер заглянуть надо. Или в листинг функции. Только не на ARM))) HF или иное исключение шины гарантированно.

Компилятор ничего не помещает в память, т.к. это удел линковщика. Но и он подчиняется писанным законам - скрипту. В первую очередь разбирайтесь с ним)

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

Угу. А сам Spice где-то из 70-х годов прошлого века растёт из недр берклевского института. Сомневаюсь, что тогда за него брали деньги. А скопировать исходничек для СССР вполне могли с адаптацией к реалиям вычислительной техники тех времён.

Сейчас я повторю то, за что меня года три назад здесь гоняли и ругали))) Думаю, что понять причину неработоспособности порой будет трудно, т.к. чувство осознанной разработки нередко бывает атрофировано использованием различных кодогенераторов наподобие "куба". В этом случае используется готовый результат записи необходимых бит и битовых полей в необходимые регистры для надлежащего функционирования желаемой периферии. Но результат этот получен не после многочасовых чтений и изучений документации, а, не побоюсь этого плохого слова, на халяву или даром. Именно этим можно объяснить следующие за изначальной радостью рабочего проекта крики ужаса о том, что ничего не работает. Ибо если бы разработчик привык читать, анализировать, вдумчиво распоряжаться полученной информацией, то и криков-то таких бы не возникло. Т.к. он просто бы сел и разобрался. Поэтому, ни у кого, как мне кажется, узнать причины не получится. Первые - не знают и не читали документацию, вторые - читали, молча всё исправили, и наслаждаются результатом, и их тем на форуме нет. P.S. Прошу воспринимать написанное с некоторой долей здорового юмора. Но всё это пишу не на ровном месте, а по множеству прецедентов. И даже не здесь на форуме, а у себя на работе.

Ищите всё, что содержит в названии "электропривод". Очень давно, в 2007 - 2009 годах, занимался этой тематикой. Не проходите мимо и зарубежных статей. Обычно в их названии встречаются слова "motor control" и т.п. Сама тематика весьма непростая, т.к. сам двигатель - это не просто сопротивление. Это ещё и индуктивность, и возникающая противоэдс и т.д. и т.п. Но Вас же не на ровном месте попросили это сделать. Что-то по электроприводу читали небось?

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

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

Про адаптацию я ничего не говорил. Следовательно, акцент был сделан на том, что "тот же самый" - это именно тот же самый. Т.е. без каких-либо доработок.

74HC165/595 Но конфигурацию линий на ввод или вывод нужно делать в железе.

А какой смысл отвечать на сообщение полугодичной давности? Я для себя вывод сделал и вывод - однозначный: читать документацию как на иной микроконтроллер, ну может быть очень редко подглядывать в документацию на STM32 в надежде прояснить какие-то уж совсем тёмные моменты в аналогии, если таковая есть. Вот только практика обращений показывает, что люди нередко попадают в этот 1% заблуждений. А по сути - не читают документацию вообще, рассчитывая на то, что GD32 - это клон STM32. Даже bin-файл заливают тот же самый. И в целом: работает, да и ладно. P.S. Раз уж заговорили об этих GD32 снова, то хочу сказать, что за год работы пришёл к выводу, что не смотря на скудную документацию (если сравнивать с эталонами документописания от ST или NXP), эти микроконтроллеры вполне пригодны для полноценной работы. Но пока ни одного ещё прибора мы не выпустили, т.к. эти микроконтроллеры применили для свежих своих разработок. Поэтому сказать что-либо о полноценном их использовании в различных условиях климата, помех и т.д. и т.п. я не могу.

Я не искал западный аналог. Хотя о REF50xx слышал. Но всё же интересно, как этот китайский друг себя поведёт. Сегодня заказал 10 штук на 1.25 и 3 штуки на 2.048 В. Посмотрим.

Я постоянно и везде пользуюсь "хромом". Подобных проблем в нём тоже не видел. Зато видел другую проблему в этом браузере, но на разных компьютерах: очень редко при редактировании текста с помощью клавиши "Backspace" может перескочить курсор на несколько символов назад без их стирания. Но это поведение проявляется настолько редко, что я даже не переживаю, а просто возвращаю курсор мышкой в нужное место.

Простите, что не в тему, а чем хорош этот браузер? Кроме, конечно же той рекламы, которая написана на сайте разработчика