STM32 новичку в ARM что к чему

[VladislavS]

COKPOWEHEU писал(а):

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

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

COKPOWEHEU писал(а):

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

А Земля вращается вокруг Солнца. К чему эти очевидные истины тут? Я, кстати, собрал GCC 12.2 с поддержкой WCH-Interrupt.

COKPOWEHEU писал(а):

Отладка это возможность получить полную информацию о состоянии и поведении системы во времени в любой момент времени.

Разумеется, нет. Зачастую отладка это анализ записи последних действий, или состояния памяти, или еще что-то. И всегда - вдумчивое курение исходников.

А вот вы как раз сужаете набор инструментов отладки.

COKPOWEHEU писал(а):

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

В отличии от вас я не останавливаюсь перед проблемой и не обвиняю в этом весь мира, а решаю её и иду дальше. Проблема, которая решается приобретением WCH-Link, это никакая не проблема, а всего лишь трата $3.

[Eddy_Em]

Прочитал я о проблеме с wch-link: действительно, твари не откравыют исходники библиотеки, она как блоб идёт.
Ну и ладно, пока мне они не нужны, а лет через 5, если на будет ядерной войны, глядишь, и исходники появятся, так что можно будет в линуксе их прошивать.

[VladislavS]

Eddy_Em писал(а):

Прочитал я о проблеме с wch-link: действительно, твари не откравыют исходники библиотеки, она как блоб идёт.

Что-то ты фантазируешь. OpenOCD в исходниках есть. Исходников прошивки WCH-Link, естественно, нет. А на что она есть? На ST-Link? На J-Link? На много чего ещё... И ничего, все пользуются. Есть открытый CMSIS-DAP, но что-то как-то не завалено им всё (у меня есть).

Eddy_Em писал(а):

глядишь, и исходники появятся, так что можно будет в линуксе их прошивать.

Кто тебе сейчас не даёт прошивать в линуксе?

[Eddy_Em]

VladislavS, мне сейчас новых STM32 хватает. Я еще под F407 USB не написал даже + нужно быстренько пару железяк на F303 и F302 разработать…
Так что, китайские когда-нибудь совсем не скоро. И когда будет полностью все прозрачно. А не через жопу, как сейчас.

[COKPOWEHEU]

VladislavS писал(а):

Где я ставил знак равенства?

Везде, где вместо отладки подразумеваете JTAG.

Я, кстати, собрал GCC 12.2 с поддержкой WCH-Interrupt.

А WCH еще и прерывания не смогли по-человечески организовать?!
Вот про доработку gcc было бы неплохо расписать поподробнее.

А вот вы как раз сужаете набор инструментов отладки.

Где?! Во-первых, я свое мнение никому не навязываю.
А то, что сам пользуюсь только обычной отладкой, так это мое дело. И этот опыт, кстати, помогает в случаях, когда с более сложными средствами возникают проблемы, как в тех же risc-v. Что в gd32vf103 (это сейчас они вроде бы внесли патчи в openocd, но когда я их активно щупал, надо было собирать из исходников), что сейчас буду с wch разбираться. Да и с другими системами это прекрасно работает. В общем, мне пока хватает обычной универсальной отладки. Если есть более специализированные варианты - хорошо, нет - не страшно.

а решаю её и иду дальше.

То есть вы разобрались как решить проблему? В смысле, подключиться без wch-link и тамошнего openocd? Ох что-то не верится...

Что-то ты фантазируешь. OpenOCD в исходниках есть.

Точно сказать не могу (глубоко не копал), но вроде бы китайский openocd вызывает специальные функции wch-link, которых в других программаторах нет. А если так, то что толку с открытости кода openocd?

Кто тебе сейчас не даёт прошивать в линуксе?

На Хабре совсем недавно проскакивала статья как подобный камень заводили под линуксом, причем даже не в wch-link, а модифицированный j-link. Возможно, там можно будет что-то наковырять.

И когда будет полностью все прозрачно. А не через жопу, как сейчас.

Можно подумать, те же stm полностью прозрачны. А к тому времени, как народ наделает костылей, чтобы избавиться от самого большого геморроя, уже выйдут новые творения необузданной китайской фантазии.

[Eddy_Em]

COKPOWEHEU, пока есть возможность, лучше вообще эти высеры китайского "творчества" не трогать. GD это тоже касается.
Пусть сначала культуре научатся: культуре писания документации и культуре писания кода. И слезут с гребаной мастдайки уже, заколебали, чесслово!
Но, подозреваю, что "восточный менталитет" не убить просто так. Боюсь, китайцы физически неспособны софт писать вменяемый.

[VladislavS]

COKPOWEHEU писал(а):

А WCH еще и прерывания не смогли по-человечески организовать?!

Вы всегда судите о вещах с которыми даже не соизволили ознакомиться? Ядро QingKeV4, используемое в CH32V, умеет аппаратно сохранять регистры, причем несколько уровней в аппаратный буфер для ускорения, а при бОльшей вложенности автоматом в стек. Фактически, прерывания работают так же как в Cortex-M, за одним исключением - возврат из прерывания командой mret надо делать. Плюс, есть 4 выделенных канала, которые могут вызывать прерывания напрямую, минуя таблицу векторов прерываний, что экономит ещё пару тактов.

COKPOWEHEU писал(а):

Вот про доработку gcc было бы неплохо расписать поподробнее.

Соответственно, в отличии от Cortex-M, должен быть механизм сказать компилятору, что перед ним функция обработки прерывания. Для этого в классическом RISC-V есть __attribute__((interrupt("machine"))), но он подразумевает программное сохранение регистров на стеке. В компиляторе, который поставляется с MounRiver, для прерываний с аппаратным сохранением регистров используется __attribute__((interrupt("WCH-Interrupt-fast"))). Но компилятор у них не первой свежести, поэтому хотелось бы это добавить и в актуальную версию. Вот тут есть патч. Сейчас там можно и готовые сборки скачать, а когда я начинал надо было самому собирать.

COKPOWEHEU писал(а):

То есть вы разобрались как решить проблему? В смысле, подключиться без wch-link и тамошнего openocd? Ох что-то не верится...

Зачем вы придумываете проблему там где её нет? Вас смущает, что код для WCH-Link пока не включен в основную ветку OpenOCD? Ну так это дело времени. WCH-link работает через OpenOCD как десятки других адаптеров. Исходники доступны. Хотите собирайте, хотите используйте сборку из MounRiver. Нет проблемы. Желаете без WCH-Link обойтись? Ну желайте дальше пока другие работают. На одном WCH-Link можно $3 сэкономить, а на 33 почти соточку

COKPOWEHEU писал(а):

Точно сказать не могу (глубоко не копал), но вроде бы китайский openocd вызывает специальные функции wch-link, которых в других программаторах нет. А если так, то что толку с открытости кода openocd?

А ещё он вызывает специальные функции j-link при работе с j-link, специальные функции st-link при работе с st-link и т.д. Если бы у всех адаптеров были одинаковые функции, зачем бы было столько интерфейсов в OpenOCD плодить? То есть, выдумали проблему там где её нет в принципе.

Добавлено after 11 minutes 6 seconds:
Предлагаю сравнить сколько кода для векторизированного прерывания надо написать на CH32V

Спойлер

Код:

#define __interrupt extern "C" void __attribute__((interrupt("WCH-Interrupt-fast")))

__interrupt SysTick_Handler()
{
  SysTick->SR = 0;
  LED_BLUE::Toggle();
}

А сколько для GD32VF103

Спойлер

Код:

#define __interrupt extern "C" void __attribute__((used, interrupt("machine")))

template<typename F>
void TVecoredIRQFunc(F f)
{
  riscv::StackMove(-12);
  Nuclei::push_mcause(0);
  Nuclei::push_mepc(1);
  Nuclei::push_msubm(2);
  __enable_irq();
  f();
  __disable_irq();
  riscv::CSR<Nuclei::CSR_REGS::msubm>::write(riscv::StackRead(8));
  riscv::CSR<Nuclei::CSR_REGS::mepc>::write(riscv::StackRead(4));
  riscv::CSR<Nuclei::CSR_REGS::mcause>::write(riscv::StackRead(0));
  riscv::StackMove(12);
}

#define IRQ_VECT(HANDLER, F) __interrupt HANDLER() { TVecoredIRQFunc( F ); }

void OnSysTick()
{
  MTimer::Clear();
  LED_BLUE::Toggle();
}

IRQ_VECT(CLIC_INT_TMR_IRQHandler, OnSysTick);


А для невекторизированного ещё и регистры push/pop надо сделать ракуми. Вы Всего этого в своих лекциях, кстати, не сделали. А это всё в документации описано.

Ну и где сделано по-человечески?

Добавлено after 24 minutes 37 seconds:

Eddy_Em писал(а):

Боюсь, китайцы физически неспособны софт писать вменяемый.

Ты за китайцев не бойся, бойся за соотечественников, которые в километре от меня прямо сейчас вот такое делают и на сайт как рекламу выкладывают.

Спойлер

[Eddy_Em]

Товарищи, а есть в природе апноут о миграции с F0 на F3? Я почитал с F1 на F3, но у F3 многая периферия таки ближе к F0… Вот и хотелось бы почитать. Может, по тому же I2C просто код получится перекинуть (хотя, судя по фичам, F3 вообще не требует вручную мучиться с отправкой адреса и ACK). Ну и с CAN то же самое (хотя, пишут, что он такой же, как в F103 — а это у меня тоже есть уже)…

[COKPOWEHEU]

Eddy_Em писал(а):

COKPOWEHEU, пока есть возможность, лучше вообще эти высеры китайского "творчества" не трогать.

Меня заинтересовала тамошняя периферия. USB-HS вообще-то редкость. А там еще эзернет, куча UART'ов и прочего.

Пусть сначала культуре научатся

Боюсь, не скоро научатся. Хотя раз GD справились, возможно, не все так плохо.

И слезут с гребаной мастдайки уже, заколебали, чесслово!

Какой-то линуксовый софт у них тоже есть, но я его пока не ковырял.

Вы всегда судите о вещах с которыми даже не соизволили ознакомиться?

Я, в отличие от вас, без информации никаких выводов и не делаю. Что вам пришлось возиться с gcc чтобы запустить там прерывания - ваши слова. Именно об этом я спрашивал. Как вам удалось интерпретировать вопрос в качестве утверждения, надо у вас спрашивать.

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

Спасибо.

Желаете без WCH-Link обойтись? Ну желайте дальше пока другие работают. На одном WCH-Link можно $3 сэкономить, а на 33 почти соточку

Да обойтись-то наверняка удастся.
Вот только как у вас на лишних затратах экономия возникла?

Если бы у всех адаптеров были одинаковые функции, зачем бы было столько интерфейсов в OpenOCD плодить? То есть, выдумали проблему там где её нет в принципе.

Вполне допускаю, что и такая проблема есть. Вроде бы JTAG предполагался как универсальный интерфейс, и достойной причины городить кто во что горазд, я не вижу.

А сколько для GD32VF103

Какой-то у вас странный код. Достаточно

Код:

eclic_set_vmode( TIMER3_IRQn );
eclic_enable_interrupt( TIMER3_IRQn );
eclic_global_interrupt_enable();
...
void TIMER3_IRQHandler(){
...
  TIMER_INTF(TIMER3) = 0;
}

Да, прототип обработчика объявлен как

Код:

__attribute__((interrupt)) void TIMER3_IRQHandler(void);

Вот полный проект с этим прерыванием: https://github.com/KarakatitsaRISCV/ris ... in/8.timer

А для невекторизированного ещё и регистры push/pop надо сделать ракуми. Вы Всего этого в своих лекциях, кстати, не сделали. А это всё в документации описано.

А в чем разница, векторизованного или не-векторизованного? Автоматом сохраняются регистры, специфичные для функций, стек и тому подобное. Впрочем, ладно, проверю.

Ты за китайцев не бойся, бойся за соотечественников, которые в километре от меня прямо сейчас вот такое делают и на сайт как рекламу выкладывают.

В смысле бескорпусная сопля без вменяемой документации?

[Reflector]

COKPOWEHEU писал(а):

Меня заинтересовала тамошняя периферия. USB-HS вообще-то редкость. А там еще эзернет, куча UART'ов и прочего.

У STM32F7 HS есть, даже у меня валяется...

[ARV]

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

[VladislavS]

COKPOWEHEU писал(а):

Я, в отличие от вас, без информации никаких выводов и не делаю. Что вам пришлось возиться с gcc чтобы запустить там прерывания - ваши слова. Именно об этом я спрашивал. Как вам удалось интерпретировать вопрос в качестве утверждения, надо у вас спрашивать.

Да ладно. Спросить можно по разному. Ваш вопрос уже содержит утверждение, что они что-то там не по-человечески сделали. Хотя документацию ещё и не смотрели.

COKPOWEHEU писал(а):

Да обойтись-то наверняка удастся.

Ну давай, давай. А могли бы уже начать программировать, а не заявлять на форумах о желании.

COKPOWEHEU писал(а):

Вот только как у вас на лишних затратах экономия возникла?

Время тоже деньги.

COKPOWEHEU писал(а):

Вполне допускаю, что и такая проблема есть.

Конечно есть! Живите теперь с этим.

COKPOWEHEU писал(а):

Вроде бы JTAG предполагался как универсальный интерфейс, и достойной причины городить кто во что горазд, я не вижу.

Опять напрашивается вопрос, а вы спецификацию хоть краем глаза смотрели?

COKPOWEHEU писал(а):

Какой-то у вас странный код. Достаточно

Недостаточно. Открываем доки

Спойлер

vectored.jpg

(216.51 KiB) Скачиваний: 34

COKPOWEHEU писал(а):

Вот полный проект с этим прерыванием:

Спрячьте и никому не показывайте.

COKPOWEHEU писал(а):

А в чем разница, векторизованного или не-векторизованного?

Открываем доки снова

Спойлер

nvectored.jpg

(167.89 KiB) Скачиваний: 33

COKPOWEHEU писал(а):

Впрочем, ладно, проверю.

Обычно это делают перед написанием статей...

COKPOWEHEU писал(а):

В смысле бескорпусная сопля

С "безупречным" качеством пайки и старательно размазанной по плате канифолью. И это на главной странице сайта про этот микроконтроллер!

COKPOWEHEU писал(а):

без вменяемой документации?

У них код на github есть, можете ознакомиться самостоятельно.

Добавлено after 1 hour 17 minutes 29 seconds:

Reflector писал(а):

У STM32F7 HS есть, даже у меня валяется...

У него "The USB OTG_HS core includes an ULPI interface to connect an external HS PHY."

[Reflector]

VladislavS писал(а):

У него "The USB OTG_HS core includes an ULPI interface to connect an external HS PHY."

Это для F723, HS PHY появляется начиная с Vx, а для F730, например, с Zx...

Вложения

phy.png

(6.96 KiB) Скачиваний: 362

[VladislavS]

В больших и дорогих чипах. А в CH32V307 он за $4. Впрочем, нафига это надо в этом тормозе - не сильно понятно.

[COKPOWEHEU]

Reflector писал(а):

У STM32F7 HS есть, даже у меня валяется...

Это начиная со 144-ногого корпуса? Для моих целей F7 явно перебор.

Ваш вопрос уже содержит утверждение, что они что-то там не по-человечески сделали.

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

Опять напрашивается вопрос, а вы спецификацию хоть краем глаза смотрели?

Спецификацию JTAG? Нет.

Недостаточно. Открываем доки

Очередная картинка без контекста, которая должна непонятно что символизировать...

Спрячьте и никому не показывайте.

Вы серьезно думаете, что я буду что-то делать по такому дурацкому приказу?!

Открываем доки снова

И еще одна бесполезная картинка. Вы, наверное, ей что-то сказать хотели?

Обычно это делают перед написанием статей...

Весь мой код рабочий, в этом легко убедиться по видео.

С "безупречным" качеством пайки и старательно размазанной по плате канифолью. И это на главной странице сайта про этот микроконтроллер!

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

У них код на github есть, можете ознакомиться самостоятельно.

А документация-то есть? Описание регистров периферии, ядра, электрические параметры и все остальное? При беглом просмотре я только куски увидел, причем на некоторых было что-то вроде "допишем позже". А может, просто слишком хорошо спрятали.

Ну какой HS чипу с тактовой в сотню-две мегагерц?

480 МГц это всего лишь 60 МБ/с сырых данных, ну пускай 30-40 МБ/с если с учетом служебных пакетов и прочего. Даже если DMA не позволит занять всю шину, это лучше, чем 800 кБ/с на FS. Мало ли, дисплей подключить, хитрую флешку сделать, логический анализатор / осциллограф или еще какой измеритель.

[VladislavS]

COKPOWEHEU писал(а):

Программирование они очевидно сделали не по-человечески.

Ну вот, вопрос уже стал утверждением. При том что документация ещё, судя по всему, не прочитана. Ну разве что за ночь прочитали, но что-то я сомневаюсь.

COKPOWEHEU писал(а):

Спецификацию JTAG? Нет.

Но, осуждаю. Классика.

COKPOWEHEU писал(а):

И еще одна бесполезная картинка. Вы, наверное, ей что-то сказать хотели?

COKPOWEHEU писал(а):

Очередная картинка без контекста, которая должна непонятно что символизировать...

Это говорит о том, что документ, с которого надо было начать изучение, вы даже не открывали. Ясно, понятно.

COKPOWEHEU писал(а):

Вы серьезно думаете, что я буду что-то делать по такому дурацкому приказу?!

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

COKPOWEHEU писал(а):

Весь мой код рабочий, в этом легко убедиться по видео.

Просто он настолько примитивный, что не наступило условие, когда он перестанет работать. Что-то сложнее блинка работать не будет, по причине, изображённой на картинках, которые вы раньше в глаза не видели.

COKPOWEHEU писал(а):

Тут вопрос как они эту штуку позиционируют.

Как бы они её не позиционировали, это не самоделка для статьи на хабре, а лицо флагмана отечественной микроэлектроники

COKPOWEHEU писал(а):

480 МГц это всего лишь 60 МБ/с сырых данных

Вы количество SRAM на борту видели? У него ещё 1 ГБит ETH-MAC есть

[COKPOWEHEU]

Ну вот, вопрос уже стал утверждением. При том что документация ещё, судя по всему, не прочитана.

Главное, вы сами признались, что не знаете нормального способа прошить контроллер (wch-link, естественно, не считается), но ругаетесь, когда это говорю я.

Но, осуждаю. Классика.

Ну так не осуждайте, кто вас заставляет...

Это говорит о том, что документ, с которого надо было начать изучение, вы даже не открывали. Ясно, понятно.

Это говорит только о том, что вы не смотрите что выкладываете.

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

Кроме пустословия от вас хоть что-то будет? Или вы думаете, что обозвав мой рабочий код говном, вы чего-то добьетесь? Так я вас разочарую: пока вы не привели ни доказательств своего пустословия, ни примеров, на которых мой код будет падать, он считается рабочим.

Вы количество SRAM на борту видели? У него ещё 1 ГБит ETH-MAC есть

Если речь про wch32v307, то оперативка у него как-то хитро организована, от 32 до 128 кБ (по дефолту 64 кБ вроде). А что до эзернета, то 10 Мб/с встроенного это тоже весьма неплохо. Хотя пока не знаю для чего это нужно мне. И аж 8 UART'ов.

[VladislavS]

COKPOWEHEU писал(а):

Главное, вы сами признались, что не знаете нормального способа прошить контроллер

Что? Где? Ссылку! Во-первых, я говорю про отладку через WCH-Link. И это самый что ни на есть нормальный способ. Во-вторых, если речь о прошивке, то у него DFU хоть через USB, хоть через UART - шей, не хочу. Впрочем, это тоже в документации написано, а её читать надо. Совсем не хочется?

COKPOWEHEU писал(а):

Ну так не осуждайте, кто вас заставляет...

На доводы "сам дурак" опускаетесь? Некрасиво!

COKPOWEHEU писал(а):

Это говорит только о том, что вы не смотрите что выкладываете.

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

COKPOWEHEU писал(а):

Кроме пустословия от вас хоть что-то будет?

У вас что-то со зрением? Я показал код обработчиков прерываний и цитаты из документации, поясняющие почему так сделано.

COKPOWEHEU писал(а):

Или вы думаете, что обозвав мой рабочий код говном, вы чего-то добьетесь?

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

COKPOWEHEU писал(а):

Так я вас разочарую: пока вы не привели ни доказательств своего пустословия,

Моего пустословия? Да ещё и я же его доказывать должен? У вас всё нормально с логикой? Или ИМХО (имею мнение хрен оспоришь) глаза застило?

COKPOWEHEU писал(а):

ни примеров, на которых мой код будет падать, он считается рабочим.

Любое прерывание поверх вашего всё сломает (а скорее всего даже не сработает). Ну это же очевидно, почитайте, наконец, документацию. Там обработка прерываний очень подробно расписана.

[COKPOWEHEU]

Что? Где?

Вы определитесь. Или wch-link-only, или по-человечески.

Во-вторых, если речь о прошивке, то у него DFU хоть через USB, хоть через UART - шей, не хочу.

Те же stm32flash и dfu-util не видят. Опять искать странный китайский софт, разбираться как его запустить и все в этом роде.
Кстати, я ведь уже писал, что через UART под виндовым софтом оно прошивается. Правда, сам софт кривой: запускается раза с пятого, может не показать интерфейс и т.д. А еще он, похоже, шифрует прошивку при передаче. Зачем - непонятно.

На доводы "сам дурак" опускаетесь? Некрасиво!

Вы же написали "не читал, но осуждаю". Ко мне это, очевидно, не относится, поскольку осуждаю я только то, с чем знаком. Значит, говорили вы про себя. В чем претензия-то?

Эти два скриншота...

...абсолютно бесполезны без контекста. Я не собираюсь угадывать что же вы хотели ими сказать.

Кроме пустословия от вас хоть что-то будет?

У вас что-то со зрением?

То есть не будет. А жаль.

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

Повторяю: сказать может кто угодно и что угодно. Но пока вы голословно утверждаете, что код работает неправильно, я столь же голословно могу утверждать, что все в порядке. Более того, мои утверждения в данном случае имеют даже больший вес, поскольку есть видеосвидетельство, что код работает.
Учитесь вести цивилизованную дискуссию. Это значит - аргументировать свою позицию.

Моего пустословия? Да ещё и я же его доказывать должен?

А кто кроме вас должен доказывать ваши слова?!

Любое прерывание поверх вашего всё сломает (а скорее всего даже не сработает).

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

Код:

USART0_IRQHandler:
  csrrw sp, mscratchcsw, sp //вот это уже не помню зачем делал. Возможно, экспериментировал со сменой режимов U-M.
  push t0, t1, a0, ra
  csrr t0, mepc
  csrr t1, mcause
  csrr a0, msubm
  push t0, t1, a0
 
  uart_puts_P "UART( "
 
  csrs mstatus, MSTATUS_MIE
 
  //собственно код обработчика

  csrc mstatus, MSTATUS_MIE
 
  uart_puts_P " )UART\r\n"
 
  pop t0, t1, a0
  csrw mepc, t0
  csrw mcause, t1
  csrw msubm, a0
  pop t0, t1, a0, ra
  csrrw sp, mscratchcsw, sp
mret

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

[VladislavS]

COKPOWEHEU писал(а):

Вы определитесь. Или wch-link-only, или по-человечески.

Как бы вы не пытались переврать, моя позиция чёткая и однозначная. Отлаживать через WCH-Link совершенно нормально. Прошивать через WCH-Link, USB или UART - более чем нормально. Все ваши нечеловеческие страдания по этому поводу это какая-то нездоровая фобия.

COKPOWEHEU писал(а):

Те же stm32flash и dfu-util не видят.

Ещё есть sam-ba у бывшей Atmel, она тоже не видит. А с чего бы они должны видеть?

COKPOWEHEU писал(а):

Опять искать странный китайский софт, разбираться как его запустить и все в этом роде.

Скачать на официальном сайте и запустить даблкликом не судьба? Это выше ваших способностей?

COKPOWEHEU писал(а):

Правда, сам софт кривой: запускается раза с пятого, может не показать интерфейс и т.д.

Работает как автомат калашникова

Спойлер

DFU.png

(96.19 KiB) Скачиваний: 33

COKPOWEHEU писал(а):

В чем претензия-то?

Перевираете слова.

COKPOWEHEU писал(а):

...абсолютно бесполезны без контекста. Я не собираюсь угадывать что же вы хотели ими сказать.

Опять таки, я не виноват, что вы не можете уследить за контекстом беседы. Могу, разве что, посоветовать перечитывать по несколько раз.

COKPOWEHEU писал(а):

В том-то и дело, что просто не вызовется.

Зашибись, просто не вызовется прерывание. Это называется "всё работает"? А теперь усложним задачу - не прерывание, а немаскируемое исключение. Вызовется и таки все сломает.

COKPOWEHEU писал(а):

Если бы вы сами читали документацию, то видели бы, что для работы приоритетных прерываний сам обработчик должен произвести некие
манипуляции.

Интересно получается. Я показал код, который как раз эти "некие манипуляции" делает. У вас он вызвал вопрос "какой-то странный код". На картинку из документации с пояснениями вы ответили "не понимаю". И после этого именно я не читал документацию? Ну совесть то поимейте.

COKPOWEHEU писал(а):

Когда я с этим разбирался, набросал вот такой код:

Честно? Так себе код то. 1. Стек сломается при вложенных прерываниях. 2. Для быстрого сохранения контекста в ядре есть регистры pushmcause, pushmepc и pushmsubm. 3. Зачем целых три регистра временных задействовано? Можно одним обойтись - меньше в стек лазить. 4. Зачем по несколько раз регистры в стек кочуют? В начале сохранил, в конце восстановил.

COKPOWEHEU писал(а):

Там довольно интересный механизм обработки вложенных прерываний: чтобы прерывание вызвалось, надо чтобы его приоритет был выше текущего (у обычного кода приоритет, очевидно, самый низкий), и был поднят флаг глобального разрешения.

Ну надо же, как интересно В других контроллерах приоритетных прерываний не бывает?

COKPOWEHEU писал(а):

Насколько я понял, это сделано для того чтобы обработчик успел сохранить все необходимое на стеке, а главное - регистр возврата.

При вызове обработчика глобальные прерывания автоматически запрещаются. После того как сохранён контекст прерывания разрешаются либо руками в векторном режиме, либо автоматически в момент перехода на реальный обработчик по команде "csrrw ra, CSR_JALMNXTI, ra".

COKPOWEHEU писал(а):

В не-векторном режиме сделано еще более красиво, но им я не особо интересовался, поэтому подробностей не помню.

Я бы назвал это просто практично. В невекторном режиме команда "csrrw ra, CSR_JALMNXTI, ra" вызывает текущее прерывание по таблице векторов. Возврат происходит опять на неё и если есть ещё необработанные прерывания, то они тоже вызываются, но уже без этапа сохранения контекста. Если активных прерываний больше нет, то "csrrw ra, CSR_JALMNXTI, ra" выполняется как NOP и код переходит к восстановлению контекста.