При том же напряжении на концах более длинного провода? Ну да, будет. Напряжённость поля-то меньше.
При резком включении поля. Пока электроны еще не начали двигаться. Или оно не будет сконцентировано в проводнике?
Но в проводнике просто гигантская плотность свободных электронов.
Ну да. Можно считать, что в металле каждый атом отдает по одному электрону. Если верить Википедии, ρ=8,92г/см³, M=63.5г/моль. Получается, m=ρV; N=Nₐ*m/M = NₐρV/M; n = N/V = ρNₐ/M = 8.92 * 63.5 * 6⋅10²³ = 8.42⋅10²² см⁻³. Немножко отличается от ваших данных, но именно что немножко. А теперь про скорость. I = q/t = eN/t = enV/t = enSL/t = enSvt/t = enSv. v = I/neS = 10 / 8.42⋅10²² * 1.6⋅10⁻¹⁹ * 10⁻² = 0,07 см/с Как-то маловато получилось. Мне что-то запомнилось про единицы сантиметров в секунду. Или я считать не умею?
С другой стороны чтобы скомпенсировать внешнее поле, этому гигантскому заряду не нужно полностью переползать на один конец провода. Достаточно немного перераспределиться.
Это-то да, но все равно ж придется перераспределиться по всему проводнику, должна возникнуть разность концентрации между концами.
Скорость дрейфа действительно получается не космическая. Всё верно. И там, где плотность носителей маленькая (в вакуумных или газоразрядных штуках), скорость дрейфа значительно выше.
Ну, в вакуумных приборах о дрейфе говорить не приходится, там баллистика.
Если собрать заряд свободных электронов на одном конце провода
... то никакой материал не выдержит, его просто порвет электростатическим отталкиванием.
Да, соглашусь. Отличная модель. Хотя и немножко ломает мозг. Получается, исходная формулировка вопроса получилась неудачной. Как на счет резкого включения внешнего поля, когда электроны еще не успели сместиться? Ну то есть будет ли зависеть действующая сила от длины в такой модели. В принципе, и на том форуме нашлись интересные тонкости. Например, мы знаем, что дрейфовая скорость электронов невелика. Но если взять провод и поднести к источнику напряжения, электроны почти мгновенно сдвинутся к одному краю, чтобы его компенсировать. Получается, в установившемся режиме электроны так медленно ползут именно из-за этой "антигравитации".
Верно. Никаких уточнений, что под проводником понимается всякая экзотика, нет. Никаких уточнений о том, что вместе с длиной меняется толщина, материал или температура, тоже нет. И нет даже уточнений, что по длине проводника к нему прикладываются внешние поля. Сформулируйте, что вам не понравилось, более внятно.
Этот вопрос - пересказ обсуждения с форума. TLDR: казалось бы, напряженность поля и соответственно, сила, действующая на электрон, пропорциональна длине проводника. Но в проводнике 1000 км она должна получиться совсем ничтожной. Но ток-то идет.
Ну, по операционникам код как раз-таки весь приведен. Там правда нет ничего больше, чем заполнение OPA->CR. А по встроенному АЦП я сам не слишком много разбирался. Но если хотите, вот делал игрушку на ch32v203. АЦП там используется. https://github.com/COKPOWEHEU/MailNotifer_ch32
У меня yaml-cpp вообще не установлен. Для компиляции достаточно libyaml-dev. Если вы устанавливаете библиотеку штатным способом, никаких путей к ней прописывать не надо. Все через pkg-config найдется. А что до недостающих файлов, apt-file search может помочь определить к какому пакету они относятся.
если попробовать в качестве компилятора указать g++, то тут вообще ж*па
Вы про то, что С++ возражает против неявного приведения указателей к void* и обратно? Ну, приведение можно сделать и явным.
/dev/ttyACM0. Нужен абсолютный путь. И не забывайте, что через бутлоадер можно прошивать только когда контроллер запущен в режиме бутлоадера (boot0 на питании). Прошивки по USB это тоже касается.
Через штатный программатор LinkE
Возможно, вам будет проще через SWD и шить. Придется либо найти пропатченный openocd от китайцев (в том же Mounriver должен быть), либо патчить самостоятельно. Там, правда, тоже есть свои проблемы: https://karakatitsariscv.github.io/12.ch32v303_intro.html
Я сделал бы несколько целей для сборки под конкретный контроллер.
Не понял что вы предлагаете. Чтобы можно было делать make v307, и код собрался под ch32v307 что ли? Но код собирается под конкретную плату с конкретной разводкой и конкретным камнем. Проще переменную MCU прописать.
Ну либо, как я уже сказал, я просто неправильно понял что вы предлагаете.
И другой вопрос. Меня интересует CH32V317. В makefile не указан такой контроллер, хотя он попадает в шаблон 3xx.
Насколько я знаю, единственное его отличие от v307 - более быстрый ethernet. Так что если лень писать свой шаблон, укажите v307. Я для тестов иногда и v303 / v307 на чужих шаблонах собираю. Там тоже отличия невелики, в основном набор периферии (скажем, в v303 меньше таймеров, UARTов и нет быстрого USB) и объем памяти.
По поводу шаблона выбора камня, первое важное отличие это семейство (какой стартап использовать и какие инклюды инклюдить), то есть v1x, v2x, ... Второе - доступные расширения (в v203, например, нет FPU, там список rv32imac, а в v303 - есть, там imafc). Ну и третье - объем памяти и ее распределение. То есть выбор ld-файла. А если вы optionbyte-ами соотношение захотите поменять, лучше этот ld-файл вообще положить поближе к своим исходникам отдельно от "системных" библиотек.
Но по большому счету разницы почти и нет. Какой-нибудь несложный код от v203 скорее всего запустится и на v317 даже без перекомпиляции.
Еще. Вы упомянули среду разработки MounriverStudio. Я конечно же заходил на китайский сайт, где они предлагают этот IDE. Но там многоступенчатое получение продукта.
Вот тут не подскажу. Я ее когда-то давно откуда-то скачал (не факт, что даже с официального сайта), но толком запустить так и не смог. Да в общем-то и не пытался: kwrite + make удобнее.
Из того, что я прочитал в первых строках выдачи гугла, такая ошибка возникает на Убунте. Что-то там в последней версии неудачно собрали. Попробуйте установить другую версию - более старую например. Или, возможно, из другого репозитория. Или той, что идет в комплекте с фирменной IDE, которая MounriverStudio - если, конечно, вы ей пользуетесь. Либо, в качестве времянки, можно использовать костыль: убрать этот zicsr, оставив только rv32imac / rv32imafc. Тогда он будет ругаться не неизвестные имена CSR-регистров. Но уж их можно руками задефайнить. Кажется, в первый раз про CSR я упоминаю в статье про прерывания. Там в примере кода написано
Адреса можно найти в документе priv-isa. В той версии, что лежит в репозитории, это таблица Table 7. Currently allocated RISC-V machine-level CSR addresses.
Например это пример 12.1.ch32v303_blink_C
Только что проверил. Оно почему-то компилируется и без zicsr. Видимо, я что-то делаю не так, ну да ладно. В общем, несколько вариантов обхода я озвучил, надеюсь, хоть один да сработает.
Если вдруг собственных шумов контроллера не хватит для oversampling-а. В принципе, было бы забавно продемонстрировать описанный 1-битный АЦП и какую точность из него можно выжать. Вот там искусственные шумы были бы необходимы, все-таки их амплитуда должна быть равна питанию.
Никогда не понимал любителей сделать отладочную плату как можно более монструозной. Вот зачем там антенна или разъем для SD-карточки? Они что, будут хотя бы в 20% проектов? Да даже если и так, их один раз отладил и забыл. Финальную отладку так и так вести на финальной плате. А место они занимают постоянно.
Потому что это отладочная плата. Навесные компоненты будут напаиваться, отпаиваться, снова напаиваться. А фольга за текстолит не так уж хорошо держится. Лучше ух взять отдельную макетку, распаять на ней гребенку, и подключать отладочную плату через нее.
Если вы пометите volatile только регистр конца списка
Ну, в реальности контроллеры при работе с массивами обычно не чудят. То есть как будто там volatile. Может, на более мощных системах по-другому, не знаю. В любом случае, разницы между разными типами синхронизации там не будет. Ну и, по-хорошему, если вы один и тот же массив хотите использовать в разных потоках, его бы тоже стоило объявить как volatile.
Вместо этого надо ставить явные барьеры перед записью отдельных элементов.
В теории (и, возможно, для больших систем) да. На практике для контроллеров - ставить fence на каждой второй строчке все-таки перебор. Тем более что все нужные области и без того обычно помечены производителем как volatile.
Прерывания - да. А сисколлы сейчас именно что функции.
Сисколы это вызовы функций ядра. Для "стандартных" ядер поведение и побочные эффекты стандартизированы. Если написано "записать кошку в ascii art", а состояние sp после вызова не определено, значит запишет кошку и испортит sp. Строгой договоренности на уровне RISC-V нет. Но, все-таки, сискол - вызов кода с машинными привилегиями. Со всеми вытекающими опасностями.
Там речь о формате, демонстрируемом пользователю. Сохранение измеренного массива в файл, отображение через UART и т.д. Внутри контроллера, естественно, удобнее оперировать абстрактными "попугаями". Вот что еще надо будет исправить (не помню, упоминал ли где-то). Всяческие настройки и дефайны для величин из реального мира. Их тоже стоит записывать в "человеческом" формате. Написать макрос, переводящий их во внутреннее представление, несложно. Зато потом проще разобраться что за что отвечает и в каких единицах записано.
При резком включении поля. Пока электроны еще не начали двигаться. Или оно не будет сконцентировано в проводнике?
Ну да. Можно считать, что в металле каждый атом отдает по одному электрону. Если верить Википедии, ρ=8,92г/см³, M=63.5г/моль. Получается,
m=ρV; N=Nₐ*m/M = NₐρV/M;
n = N/V = ρNₐ/M = 8.92 * 63.5 * 6⋅10²³ = 8.42⋅10²² см⁻³. Немножко отличается от ваших данных, но именно что немножко.
А теперь про скорость.
I = q/t = eN/t = enV/t = enSL/t = enSvt/t = enSv.
v = I/neS = 10 / 8.42⋅10²² * 1.6⋅10⁻¹⁹ * 10⁻² = 0,07 см/с
Как-то маловато получилось. Мне что-то запомнилось про единицы сантиметров в секунду. Или я считать не умею?
Это-то да, но все равно ж придется перераспределиться по всему проводнику, должна возникнуть разность концентрации между концами.
Ну, в вакуумных приборах о дрейфе говорить не приходится, там баллистика.
... то никакой материал не выдержит, его просто порвет электростатическим отталкиванием.
Да, соглашусь. Отличная модель. Хотя и немножко ломает мозг.
Получается, исходная формулировка вопроса получилась неудачной. Как на счет резкого включения внешнего поля, когда электроны еще не успели сместиться? Ну то есть будет ли зависеть действующая сила от длины в такой модели.
В принципе, и на том форуме нашлись интересные тонкости. Например, мы знаем, что дрейфовая скорость электронов невелика. Но если взять провод и поднести к источнику напряжения, электроны почти мгновенно сдвинутся к одному краю, чтобы его компенсировать. Получается, в установившемся режиме электроны так медленно ползут именно из-за этой "антигравитации".
Верно. Никаких уточнений, что под проводником понимается всякая экзотика, нет. Никаких уточнений о том, что вместе с длиной меняется толщина, материал или температура, тоже нет. И нет даже уточнений, что по длине проводника к нему прикладываются внешние поля.
Сформулируйте, что вам не понравилось, более внятно.
А еще электрон можно запустить в вакууме, там он тоже будет лететь без нужды во внешнем поле. И что?
Этот вопрос - пересказ обсуждения с форума.
TLDR: казалось бы, напряженность поля и соответственно, сила, действующая на электрон, пропорциональна длине проводника. Но в проводнике 1000 км она должна получиться совсем ничтожной. Но ток-то идет.
Ну, по операционникам код как раз-таки весь приведен. Там правда нет ничего больше, чем заполнение
OPA->CR. А по встроенному АЦП я сам не слишком много разбирался. Но если хотите, вот делал игрушку на ch32v203. АЦП там используется. https://github.com/COKPOWEHEU/MailNotifer_ch32У меня yaml-cpp вообще не установлен. Для компиляции достаточно libyaml-dev.
Если вы устанавливаете библиотеку штатным способом, никаких путей к ней прописывать не надо. Все через pkg-config найдется.
А что до недостающих файлов,
apt-file searchможет помочь определить к какому пакету они относятся.Вы про то, что С++ возражает против неявного приведения указателей к void* и обратно? Ну, приведение можно сделать и явным.
Возможно,
/dev/ttyACM0. Нужен абсолютный путь. И не забывайте, что через бутлоадер можно прошивать только когда контроллер запущен в режиме бутлоадера (boot0 на питании). Прошивки по USB это тоже касается.
Возможно, вам будет проще через SWD и шить. Придется либо найти пропатченный openocd от китайцев (в том же Mounriver должен быть), либо патчить самостоятельно. Там, правда, тоже есть свои проблемы: https://karakatitsariscv.github.io/12.ch32v303_intro.html
Переменная MCU: https://github.com/KarakatitsaRISCV/riscv-asm/blob/main/12.1.ch32v303_blink_C/makefile#L5 Там в makefile у меня немного противоестественная логика выбора стартапа и флагов получилась. Формирование имени переменной из содержимого другой переменной. Да и добавлял я эти настройки скорее для себя, чем для статей.
Не понял что вы предлагаете. Чтобы можно было делать
make v307, и код собрался под ch32v307 что ли? Но код собирается под конкретную плату с конкретной разводкой и конкретным камнем. Проще переменную MCU прописать.Ну либо, как я уже сказал, я просто неправильно понял что вы предлагаете.
Насколько я знаю, единственное его отличие от v307 - более быстрый ethernet. Так что если лень писать свой шаблон, укажите v307. Я для тестов иногда и v303 / v307 на чужих шаблонах собираю. Там тоже отличия невелики, в основном набор периферии (скажем, в v303 меньше таймеров, UARTов и нет быстрого USB) и объем памяти.
По поводу шаблона выбора камня, первое важное отличие это семейство (какой стартап использовать и какие инклюды инклюдить), то есть v1x, v2x, ... Второе - доступные расширения (в v203, например, нет FPU, там список rv32imac, а в v303 - есть, там imafc). Ну и третье - объем памяти и ее распределение. То есть выбор ld-файла. А если вы optionbyte-ами соотношение захотите поменять, лучше этот ld-файл вообще положить поближе к своим исходникам отдельно от "системных" библиотек.
Но по большому счету разницы почти и нет. Какой-нибудь несложный код от v203 скорее всего запустится и на v317 даже без перекомпиляции.
Вот тут не подскажу. Я ее когда-то давно откуда-то скачал (не факт, что даже с официального сайта), но толком запустить так и не смог. Да в общем-то и не пытался: kwrite + make удобнее.
Из того, что я прочитал в первых строках выдачи гугла, такая ошибка возникает на Убунте. Что-то там в последней версии неудачно собрали. Попробуйте установить другую версию - более старую например. Или, возможно, из другого репозитория. Или той, что идет в комплекте с фирменной IDE, которая MounriverStudio - если, конечно, вы ей пользуетесь.
Либо, в качестве времянки, можно использовать костыль: убрать этот zicsr, оставив только rv32imac / rv32imafc. Тогда он будет ругаться не неизвестные имена CSR-регистров. Но уж их можно руками задефайнить. Кажется, в первый раз про CSR я упоминаю в статье про прерывания. Там в примере кода написано
Адреса можно найти в документе priv-isa. В той версии, что лежит в репозитории, это таблица Table 7. Currently allocated RISC-V machine-level CSR addresses.
Только что проверил. Оно почему-то компилируется и без zicsr. Видимо, я что-то делаю не так, ну да ладно. В общем, несколько вариантов обхода я озвучил, надеюсь, хоть один да сработает.
Если вдруг собственных шумов контроллера не хватит для oversampling-а.
В принципе, было бы забавно продемонстрировать описанный 1-битный АЦП и какую точность из него можно выжать. Вот там искусственные шумы были бы необходимы, все-таки их амплитуда должна быть равна питанию.
Никогда не понимал любителей сделать отладочную плату как можно более монструозной. Вот зачем там антенна или разъем для SD-карточки? Они что, будут хотя бы в 20% проектов? Да даже если и так, их один раз отладил и забыл. Финальную отладку так и так вести на финальной плате. А место они занимают постоянно.
Потому что это отладочная плата. Навесные компоненты будут напаиваться, отпаиваться, снова напаиваться. А фольга за текстолит не так уж хорошо держится.
Лучше ух взять отдельную макетку, распаять на ней гребенку, и подключать отладочную плату через нее.
Обычно это переменная из линкер скрипта. Вершина ОЗУ. Но никто не мешает поправить ld-файл и руками.
Просто константа, которую "ручками" загружают в sp.
Ну, в реальности контроллеры при работе с массивами обычно не чудят. То есть как будто там volatile. Может, на более мощных системах по-другому, не знаю. В любом случае, разницы между разными типами синхронизации там не будет. Ну и, по-хорошему, если вы один и тот же массив хотите использовать в разных потоках, его бы тоже стоило объявить как volatile.
В теории (и, возможно, для больших систем) да. На практике для контроллеров - ставить fence на каждой второй строчке все-таки перебор. Тем более что все нужные области и без того обычно помечены производителем как volatile.
Спасибо, почитаю.
Сисколы это вызовы функций ядра. Для "стандартных" ядер поведение и побочные эффекты стандартизированы. Если написано "записать кошку в ascii art", а состояние sp после вызова не определено, значит запишет кошку и испортит sp. Строгой договоренности на уровне RISC-V нет. Но, все-таки, сискол - вызов кода с машинными привилегиями. Со всеми вытекающими опасностями.
Не знаю. Но расширения Zfinx, Zdinx выглядят удобно.
Там речь о формате, демонстрируемом пользователю. Сохранение измеренного массива в файл, отображение через UART и т.д. Внутри контроллера, естественно, удобнее оперировать абстрактными "попугаями".
Вот что еще надо будет исправить (не помню, упоминал ли где-то). Всяческие настройки и дефайны для величин из реального мира. Их тоже стоит записывать в "человеческом" формате. Написать макрос, переводящий их во внутреннее представление, несложно. Зато потом проще разобраться что за что отвечает и в каких единицах записано.
И это ровно ни на что не повлияет. Такое допущение приняли только для простоты расчета. Ну не надо считать разработчиков идиотами.