Может быть, я и не рублю в теме, но мне совершенно непонятно, каким именно образом отличие системы команд и открытая архитектура мешает реализовать векторный обработчик прерываний, а тем более не дают разместить в документации описание работы своего "более гибкого" контроллера прерываний.
Например, в GD32 вполне себе живет векторный режим, наряду с не-векторным, причем оба вполне себе описаны в документации. В рассматриваемом CH32V003 есть указания на VTF - не совсем вектора, но очень похоже.
Может, вместо того, чтобы раздувать щеки, можно просто признаться, что настоящая векторность в 2К слов памяти программ - слишком роскошное удовольствие?
1.Если какая либо части технического описания МК требуют для своего описания привлечения сторонних ресурсов, то в тексте это должно быть явным образом указано и в конце документа должен быть представлен перечень используемой литературы. Это по поводу призыва читать описание на RISC-V, какого бы размера оно не было.
2.Да, по моему мнению, две архитектуры весьма близки, и процедура обработки прерываний весьма похожа. А то, что ядро ARM само прячет рабочие регистры на стек, а в RISC-V это делается обработчиком - не принципиальное отличие, на мой взгляд.
3.И отсутствие векторов прерываний я ничем иным, кроме как отечественностью разработки, объяснить не могу. Если я неправ и на самом деле в МК АМУР наличествуют векторные прерывания и нет необходимости полингом определять источник, то укажите соответствующее место документации, поскольку я в ней нашел только фразу
4.Отнюдь не только цена, хотя это, наверное, главные недостаток. И питание и потребление и размер память программ не являются сильными сторонами АМУР - но это совсем не означает, что его нельзя применять - надо просто понимать недостатки и нивелировать их. Идеальный вариант - устранять недостатки, но, похоже, с Вашей точки зрения, это необязательно, если оно "настоящее".
5. Что касается китайского "шлака", то в чем именно заключается "шлаковость" конкретно CH32V003? Параметры, как я показал в статье, весьма близки, значит и АМУР тогда тоже "шлак"? Хотя конечно же нет, ведь он "настоящий". Отметьте, что я подобного вывода не делал.
6.Я никогда "с пеной у рта" не спрашивал, хотя прекрасно понимал шаткость конструкции, основанной на зарубежных фабриках. И замечательно, что появляются отечественные ("по настоящему") МК. Но, как говорил незабвенный МихМих, "Общим видом овладели, теперь про подробности надо не забывать", так что испытывать гордость я бы пока поостерегся.
7.Если Вы не смогли оперативно перейти на изделия Giga Device и приобретали оригинал по конских ценам (и при этом радовались, что характерно), у меня для Вас не очень хорошие новости. Хотя, возможно, именно этот тип МК наши китайские друзья не заместили, вполне допускаю, но повода для радости не нахожу. Пнп: при этом я предполагаю, что в Вашем изделии функциональность конкретного МК была именно необходима, и он при разработке не выбирался по принципу "Давайте поставим кристалл пожирнее, он стоит всего лишь 15 баксов, зато сколько памяти, нам будет проще".
PS. Ну, вообще то, китайцы пакуют свой МК в разные корпуса, в том числе 20-ноговые и это явно указано в таблице. А почему нельзя сравнивать МК в разных корпусах, я так и не понял, просветите.
В модемах была такая функция, но работала совсем по-другому, я смотрел код прошивок и делал так же.
Там вначале МК просто смотрит на ножку, ловит старт-бит, измеряет его длительность, далее в режиме программного UART с вычисленной скоростью принимает первый символ, затем включает аппаратный порт на нужной скорости и принимает остаток команды. При этом команда начинается с гарантированного префикса "AT" или "at" и все получается хорошо.
Забавно, что эта процедура повторяется для каждой ожидаемой команды и Вы можете передавать их на разной скорости, хотя не очень понятно, зачем.
А передаваемые/принимаемые данные дополнительно могут передаваться на скорости установленного сеанса связи.
Конечно, Вы совершенно правы, это ошибка, немедленно исправлю. А что касается формул, я не очень разобрался с новым редактором и попытка вставить формулы, как следует, приводит к разрастанию текста, буду дальше тренироваться.
Дело в том, что на конденсатор Вам дают верхнюю границу ESR, а конкретное значение заранее не известно, поэтому и не считается. Есть надежда на сопротивление диодов, сопротивление трансформатора, но гарантию дает только токо-ограничивающий резистор со всеми минусами, из него вытекающими.
А он вообще не считается, ясно только, что может быть очень большим :). Тема рашевого тока лежит несколько в стороне от поста, тут более узкая проблема рассматривается.
Хотя Вы правы, надо было добавить, что все расчеты для установившегося режима.
Хм, я не знал такой тонкости, мне казалось, что Е означает "расширенный" в противовес I, которая явно обозначена, как "базовый набор инструкций". Сходил на сайт RISCV, почитал, оказывается набор инструкций точно такой же, а регистров только 16 вместо 32, спасибо за поправку. Оценка по данной строке таблицы меняется на +2.
Наверное, ABI не совсем идет по указанному адресу, а смещается ?
Ну, может быть, у Вас на экране где то выше есть описание данного флага и дано его поведение в полном коде класса потока, но в представленной статье этого фрагмента нет.
Главное, чтобы не было ошибки - это что, типа "ну работает же", так и индусский код работает, что не мешает его обоснованно критиковать.
Что еще не понравилось? Например, использование постфиксного инкремента вместе префиксного, "мертвая переменная str, передача в метод класса значения его поля в качестве параметра, про именование переменных Вам уже писали и код производит впечатление очень неряшливого, я бы такой выкладывать не стал.
Именно так, с налогами, больничными и все отчеты для фондов делались менее, чем за пол-часа, основное время уходило на печать расчетных листочков на матричном принтере.
Даже атомарные типы не инкрементируются за 1 операцию, Вас обманули. Просто тем или иным способом все те же 3 операции делают не прерываемыми и снаружи они выглядят, как одна..
Вообще то тут засада почти в каждой строке: 4. предполагается зависание в ожидании bIfRun, но начальное значение переменной не представлено и модификация переменной не указана. Как говорят на одном ресурсе в ответ на подобные вопросы без должных условий : "Я свой магический шар сегодня дома оставил"
8-14 можно (и нужно) переписать и вместо:
if (bSm || bMx) {
if (bSm) pFThCounter->AddCounterSem();
else {
pFThCounter->AddCounterMx();
}
}
else pFThCounter->AddCounter();
получить значительно более вменяемое:
if (bSm) { pFThCounter->AddCounterSem();
}; else if (bMx) { pFThCounter->AddCounterMx();
}; else { pFThCounter->AddCounter();
};
Кстати, компилятор даже исходную (не оптимальную конструкцию) реализует также, как и для вменяемого варианта - это на тему, "что может компилятор оптимизировать".
Я вроде где то читал, что M0 заточен под FPGA реализации и может применяться свободно, но может, только в этих целях, не буду спорить.
Мне казалось, что тяжелая математика все таки не для МК (микроконтроллеров), а для МК (микрокомпьютеров), хотя, заказчик всегда прав.
Может быть, я и не рублю в теме, но мне совершенно непонятно, каким именно образом отличие системы команд и открытая архитектура мешает реализовать векторный обработчик прерываний, а тем более не дают разместить в документации описание работы своего "более гибкого" контроллера прерываний.
Например, в GD32 вполне себе живет векторный режим, наряду с не-векторным, причем оба вполне себе описаны в документации.
В рассматриваемом CH32V003 есть указания на VTF - не совсем вектора, но очень похоже.
Может, вместо того, чтобы раздувать щеки, можно просто признаться, что настоящая векторность в 2К слов памяти программ - слишком роскошное удовольствие?
Ну что же, вполне ожидаемое изделие, если к нему сделают нормальный софт, то вполне может получиться и Ардуино совместимость.
1.Если какая либо части технического описания МК требуют для своего описания привлечения сторонних ресурсов, то в тексте это должно быть явным образом указано и в конце документа должен быть представлен перечень используемой литературы. Это по поводу призыва читать описание на RISC-V, какого бы размера оно не было.
2.Да, по моему мнению, две архитектуры весьма близки, и процедура обработки прерываний весьма похожа. А то, что ядро ARM само прячет рабочие регистры на стек, а в RISC-V это делается обработчиком - не принципиальное отличие, на мой взгляд.
3.И отсутствие векторов прерываний я ничем иным, кроме как отечественностью разработки, объяснить не могу. Если я неправ и на самом деле в МК АМУР наличествуют векторные прерывания и нет необходимости полингом определять источник, то укажите соответствующее место документации, поскольку я в ней нашел только фразу
4.Отнюдь не только цена, хотя это, наверное, главные недостаток. И питание и потребление и размер память программ не являются сильными сторонами АМУР - но это совсем не означает, что его нельзя применять - надо просто понимать недостатки и нивелировать их. Идеальный вариант - устранять недостатки, но, похоже, с Вашей точки зрения, это необязательно, если оно "настоящее".
5. Что касается китайского "шлака", то в чем именно заключается "шлаковость" конкретно CH32V003? Параметры, как я показал в статье, весьма близки, значит и АМУР тогда тоже "шлак"? Хотя конечно же нет, ведь он "настоящий". Отметьте, что я подобного вывода не делал.
6.Я никогда "с пеной у рта" не спрашивал, хотя прекрасно понимал шаткость конструкции, основанной на зарубежных фабриках. И замечательно, что появляются отечественные ("по настоящему") МК. Но, как говорил незабвенный МихМих, "Общим видом овладели, теперь про подробности надо не забывать", так что испытывать гордость я бы пока поостерегся.
7.Если Вы не смогли оперативно перейти на изделия Giga Device и приобретали оригинал по конских ценам (и при этом радовались, что характерно), у меня для Вас не очень хорошие новости. Хотя, возможно, именно этот тип МК наши китайские друзья не заместили, вполне допускаю, но повода для радости не нахожу. Пнп: при этом я предполагаю, что в Вашем изделии функциональность конкретного МК была именно необходима, и он при разработке не выбирался по принципу "Давайте поставим кристалл пожирнее, он стоит всего лишь 15 баксов, зато сколько памяти, нам будет проще".
PS. Ну, вообще то, китайцы пакуют свой МК в разные корпуса, в том числе 20-ноговые и это явно указано в таблице. А почему нельзя сравнивать МК в разных корпусах, я так и не понял, просветите.
В модемах была такая функция, но работала совсем по-другому, я смотрел код прошивок и делал так же.
Там вначале МК просто смотрит на ножку, ловит старт-бит, измеряет его длительность, далее в режиме программного UART с вычисленной скоростью принимает первый символ, затем включает аппаратный порт на нужной скорости и принимает остаток команды. При этом команда начинается с гарантированного префикса "AT" или "at" и все получается хорошо.
Забавно, что эта процедура повторяется для каждой ожидаемой команды и Вы можете передавать их на разной скорости, хотя не очень понятно, зачем.
А передаваемые/принимаемые данные дополнительно могут передаваться на скорости установленного сеанса связи.
Конечно, Вы совершенно правы, это ошибка, немедленно исправлю. А что касается формул, я не очень разобрался с новым редактором и попытка вставить формулы, как следует, приводит к разрастанию текста, буду дальше тренироваться.
И какой именно - диодный мост?
Ну у gcc есть два флаг для E версии - march=rv32e и -мabi=rv32e.
Дело в том, что на конденсатор Вам дают верхнюю границу ESR, а конкретное значение заранее не известно, поэтому и не считается. Есть надежда на сопротивление диодов, сопротивление трансформатора, но гарантию дает только токо-ограничивающий резистор со всеми минусами, из него вытекающими.
Ну они вроде совместимость по корпусу и ножкам с STM8 декларировали.
А он вообще не считается, ясно только, что может быть очень большим :). Тема рашевого тока лежит несколько в стороне от поста, тут более узкая проблема рассматривается.
Хотя Вы правы, надо было добавить, что все расчеты для установившегося режима.
А что, вполне себе рабочий метод, то есть если периферия снята с STM8 в режиме "1 к 1"?
Хм, я не знал такой тонкости, мне казалось, что Е означает "расширенный" в противовес I, которая явно обозначена, как "базовый набор инструкций". Сходил на сайт RISCV, почитал, оказывается набор инструкций точно такой же, а регистров только 16 вместо 32, спасибо за поправку. Оценка по данной строке таблицы меняется на +2.
Наверное, ABI не совсем идет по указанному адресу, а смещается ?
Хм, а как Вам это удалось - Falstad симулятор на Вашем сайте?
Купцов С.В., Николаев Виктор Тихонович, Тикменов Василий Николаевич. "Практическая схемотехника" - приношу извинения за ошибку, бегу править в тексте.
Ну, может быть, у Вас на экране где то выше есть описание данного флага и дано его поведение в полном коде класса потока, но в представленной статье этого фрагмента нет.
Главное, чтобы не было ошибки - это что, типа "ну работает же", так и индусский код работает, что не мешает его обоснованно критиковать.
Что еще не понравилось? Например, использование постфиксного инкремента вместе префиксного, "мертвая переменная str, передача в метод класса значения его поля в качестве параметра, про именование переменных Вам уже писали и код производит впечатление очень неряшливого, я бы такой выкладывать не стал.
Именно так, с налогами, больничными и все отчеты для фондов делались менее, чем за пол-часа, основное время уходило на печать расчетных листочков на матричном принтере.
Даже атомарные типы не инкрементируются за 1 операцию, Вас обманули. Просто тем или иным способом все те же 3 операции делают не прерываемыми и снаружи они выглядят, как одна..
Вообще то тут засада почти в каждой строке:
4. предполагается зависание в ожидании
bIfRun,но начальное значение переменной не представлено и модификация переменной не указана. Как говорят на одном ресурсе в ответ на подобные вопросы без должных условий : "Я свой магический шар сегодня дома оставил"8-14 можно (и нужно) переписать и вместо:
получить значительно более вменяемое:
Кстати, компилятор даже исходную (не оптимальную конструкцию) реализует также, как и для вменяемого варианта - это на тему, "что может компилятор оптимизировать".
И так далее и тому подобное.