Попробуем еще раз. Сигма-дельта АЦП отличается тем, что подстраивает сигнал порционно, то плюс опорой, то минус. И считает их соотношение.
В тактовые периоды 2 и 7 состояния системы идентичны, так как при неизменном входном сигнале Uвх=0,6 В цикл работы занимает пять тактовых периодов. Усреднение выходного сигнала ЦАП за цикл действительно дает величину напряжения 0,6 В: (1-1+1+1+1)/5=0,6.
Видите: складываются дискретные отсчеты и делятся на количество. Абсолютное значение времени там никакой роли не играет.
Вы же сами кидали ссылку на описание сигма-дельты. Там именно это и написано. А относительно вг015 вам открыть документацию ничуть не сложнее, чем мне. Но лично я там подробностей не нашел. Разве что то, что в источник опорного напряжения "выполнен с использованием напряжения запрещенной зоны полупроводника".
Оно N тактов линейно увеличивается, потом M тактов линейно уменьшается. И значение имеет только отношение N к M, а не их абсолютные величины. Только в примитивных АЦП однократного интегрирования измерялось абсолютное время. Но они практически нигде не применяются. Именно поэтому.
Вот только окно счета задается тем же генератором, что и окно интегрирования. Вы же не думаете, что разработчики самых точных АЦП настолько глупые чтобы завязываться на счетчик времени сомнительной стабильности?
Сдается мне, вы путаете точность и стабильность. То есть систематическую погрешность и случайную. То, что HSI отличается на 5% от номинала, не значит, что он на 5% плавает во время работы - это всего лишь значит, что НИИЭТ не стали его калибровать. Для АЦП важна именно стабильность частоты, а не точность. И интуитивно мне кажется, что стабильность у любых встроенных RC-генераторов будет примерно одинаковая, что у stm32, что у ch32, что у вг015.
int C = 5;
int foo(int a, int b) {
return a + b + C;
202: 952e add a0,a0,a1
204: 20000797 auipc a5,0x20000
208: dfc7a783 lw a5,-516(a5) # 20000000 <C>
}
20c: 953e add a0,a0,a5
20e: 8082 ret
Похоже, дело во флаге -mcmodel. У меня стоял medany, а у вас, вероятно, medlow. По крайней мере, я сейчас его поменял и ваше lui получилось. Так вот зачем этот флаг нужен. Спасибо что пнули в нужном направлении. Что забавно, в документации позиционно-независимым назван как раз medany:
The code generated by the medium-any code model is position-independent, but is not guaranteed to function correctly when linked into position-independent executables or libraries.
если у вас доступ к памяти через auipc, стартап-код как раз может обеспечить корректность выполняемого кода, передав на него управление по правильному адресу.
Если в ld-скрипте адрес начала прошивки указан 0x8000'0000, в реальности ее располагают в 0x8001'0000, а для доступа к оперативке используется auipc, стартап никак не может на это повлиять.
Другое дело, что если mcmodel действительно позволяет отвязать адреса оперативки от адресов флеша и генерировать позиционно-независимый код (надо будет еще проверить ссылки на функции, таблицы переходов и т.п.), то со стартапом заморачиваться уже стоит.
Еще раз. Любое обращение к памяти из юзерского кода на Си. Оно разворачивается в auipc, а не в lui. Если не предпринимать дополнительных мер. И с этой проблемой стартап-код никак не поможет, будь он хоть трижды позиционно-независимым.
Во всех этих случаях заботиться о позиционно-независимом коде приходится самому программисту. А речь-то шла о том, что компилятор gcc по умолчанию будет генерировать обычный, позиционно-зависимый код. И, на самом деле, это проблема: я-то надеялся написать бутлоадер, который бы располагался в начале флеша, а юзерский код записывал где-нибудь дальше. И если бы прошивка получалась позиционно-независимой, проблемы бы не было: ну стартует он не с 0x8000'0000, а с 0x8001`0000 - не страшно, переходы-то относительные. Но вот обращение к ОЗУ из-за la поломается. Поэтому придется либо вкручивать флаги компилятору (пока не знаю с какими побочными эффектами), либо править ld-скрипт. А раз так, то и возня с позиционно-независимым загрузчиком не особо полезна. А самое обидное, что я так и не нашел способа передать в li адрес метки, компилятор ругается и требует la.
может кнопки повешу на WAKEUP-ноги, если не хватит GPIO, но там, возможно, будет не просто фильтровать дребезг и удержание.
Это вы здорово недооцениваете бездну геморроя с использованием WKUP как входов. Нормального чтения там нет вообще никак. Единственный способ, которым мне удалось воспользоваться - через прерывание RTC. И этот способ невероятно кривой. Хотя есть шанс, что это я чего-то недоглядел.
Он может идти только на один АЦП, например, последовательного приближения, а сигма-дельта - от внутреннего (хотя логичнее наоборот). Но это все надо изучать отдельно.
То, что openocd из репозитория не подходит, нужно специальный от производителя. А стенд не у меня стоит, устанавливать туда сторонние программы не хочется. В любом случае, под "собрать стенд" я имел в виду скорее железо: эмулятор клавиатуры, экрана, UART, микрофона,...
Не буду настаивать. Я к местным АЦП пока что и близко не подходил. Важнее было с базовыми цифровыми интерфейсами разобраться. И даже сейчас важнее написать нормальный бутлоадер и собрать стенд для удобной прошивки. В общем, основной специфике вг015 придется подождать
По стабильности ИОНов есть более интересные планы (не только вг015), но там надо здорово с установкой замороситься. Не малейшего представления найдется ли вообще на это время. А что до SDADC, там же, наверное, можно внешний ИОН подключить на крайний случай?
Попробуем еще раз. Сигма-дельта АЦП отличается тем, что подстраивает сигнал порционно, то плюс опорой, то минус. И считает их соотношение.
Видите: складываются дискретные отсчеты и делятся на количество. Абсолютное значение времени там никакой роли не играет.
Вы же сами кидали ссылку на описание сигма-дельты. Там именно это и написано. А относительно вг015 вам открыть документацию ничуть не сложнее, чем мне. Но лично я там подробностей не нашел. Разве что то, что в источник опорного напряжения "выполнен с использованием напряжения запрещенной зоны полупроводника".
Оно N тактов линейно увеличивается, потом M тактов линейно уменьшается. И значение имеет только отношение N к M, а не их абсолютные величины. Только в примитивных АЦП однократного интегрирования измерялось абсолютное время. Но они практически нигде не применяются. Именно поэтому.
Вот только окно счета задается тем же генератором, что и окно интегрирования. Вы же не думаете, что разработчики самых точных АЦП настолько глупые чтобы завязываться на счетчик времени сомнительной стабильности?
Для него важно только насколько уплывет частота генератора за время одного преобразования. Абсолютная величина частоты никакого значения не имеет.
Сдается мне, вы путаете точность и стабильность. То есть систематическую погрешность и случайную. То, что HSI отличается на 5% от номинала, не значит, что он на 5% плавает во время работы - это всего лишь значит, что НИИЭТ не стали его калибровать. Для АЦП важна именно стабильность частоты, а не точность. И интуитивно мне кажется, что стабильность у любых встроенных RC-генераторов будет примерно одинаковая, что у stm32, что у ch32, что у вг015.
Похоже, дело во флаге
-mcmodel. У меня стоялmedany, а у вас, вероятно,medlow. По крайней мере, я сейчас его поменял и ваше lui получилось. Так вот зачем этот флаг нужен. Спасибо что пнули в нужном направлении.Что забавно, в документации позиционно-независимым назван как раз medany:
Если в ld-скрипте адрес начала прошивки указан 0x8000'0000, в реальности ее располагают в 0x8001'0000, а для доступа к оперативке используется auipc, стартап никак не может на это повлиять.
Другое дело, что если mcmodel действительно позволяет отвязать адреса оперативки от адресов флеша и генерировать позиционно-независимый код (надо будет еще проверить ссылки на функции, таблицы переходов и т.п.), то со стартапом заморачиваться уже стоит.
Еще раз. Любое обращение к памяти из юзерского кода на Си. Оно разворачивается в auipc, а не в lui. Если не предпринимать дополнительных мер. И с этой проблемой стартап-код никак не поможет, будь он хоть трижды позиционно-независимым.
Во всех этих случаях заботиться о позиционно-независимом коде приходится самому программисту. А речь-то шла о том, что компилятор gcc по умолчанию будет генерировать обычный, позиционно-зависимый код.
И, на самом деле, это проблема: я-то надеялся написать бутлоадер, который бы располагался в начале флеша, а юзерский код записывал где-нибудь дальше. И если бы прошивка получалась позиционно-независимой, проблемы бы не было: ну стартует он не с 0x8000'0000, а с 0x8001`0000 - не страшно, переходы-то относительные. Но вот обращение к ОЗУ из-за la поломается. Поэтому придется либо вкручивать флаги компилятору (пока не знаю с какими побочными эффектами), либо править ld-скрипт. А раз так, то и возня с позиционно-независимым загрузчиком не особо полезна.
А самое обидное, что я так и не нашел способа передать в li адрес метки, компилятор ругается и требует la.
Мне разбираться с openocd не под силу. Вот написать бутлоадер - другое дело. Впрочем, там видно будет.
Это вы здорово недооцениваете бездну геморроя с использованием WKUP как входов. Нормального чтения там нет вообще никак. Единственный способ, которым мне удалось воспользоваться - через прерывание RTC. И этот способ невероятно кривой. Хотя есть шанс, что это я чего-то недоглядел.
Видеокарта на 256 ядрах вг015. Суровая российская видеокарта с ручками для переноски.
А как же. Ради интереса решил попробовать сделать плату максимально подручными средствами, даже без принтера. Даже записал процесс этого мракобесия: https://www.youtube.com/watch?v=tPAHEwi4Fzg&list=PLc7FYD_FgfqcgaWyrxhSr8cy2q23xCY3Q&index=14
однокристальная микро-ЭВМ!
Что, недостаточно апокалиптично? Вот такая, наверное, покрасивее будет: https://habrastorage.org/r/w1560/webt/tq/q2/2b/tqq22bjmf-yx77utxwt-v0ia8u4.jpeg
Он может идти только на один АЦП, например, последовательного приближения, а сигма-дельта - от внутреннего (хотя логичнее наоборот). Но это все надо изучать отдельно.
То, что openocd из репозитория не подходит, нужно специальный от производителя. А стенд не у меня стоит, устанавливать туда сторонние программы не хочется.
В любом случае, под "собрать стенд" я имел в виду скорее железо: эмулятор клавиатуры, экрана, UART, микрофона,...
Чем-то напоминает то, что в gd32 реализовали
Не буду настаивать. Я к местным АЦП пока что и близко не подходил. Важнее было с базовыми цифровыми интерфейсами разобраться. И даже сейчас важнее написать нормальный бутлоадер и собрать стенд для удобной прошивки. В общем, основной специфике вг015 придется подождать
По стабильности ИОНов есть более интересные планы (не только вг015), но там надо здорово с установкой замороситься. Не малейшего представления найдется ли вообще на это время.
А что до SDADC, там же, наверное, можно внешний ИОН подключить на крайний случай?