Xenia

Так он именно встроен в octave, а не просто вызывается, как dll-модуль, из gnuplot. Обычно ситуация такова, что чужие dll, как правило, вообще не вызываются :). Причиной тому служит то, что чужой программный продукт обычно содержит некий свой "фундамент", тогда как в dll вынесены редко или периодически используемые функции. Однако такие "удаленные функции" для своей работы все равно требуют наличия этого фундамента, а зачастую и его "инициации". Исключение составляют dll-модули в составе библиотек, да и то процедура инициации чаще всего оказывается неизбежной. В целом же проблема сводится к тому, что чужие/внешние функции не являются отдельными "кубиками", которые можно легко присоединять к своей программе, а связаны между собой неразрывными связями. Например, я вызываю одну функция, не ведая, что она неавтономна. Тогда как она при своем выполнении вызывает, скажем, пару других функций из того же ушата :), а те, в свою очередь, вызовут еще какие-то функции, а те свои, и т.д. до цепной реакции. Конечно, может случиться и так, что рост этих "метастаз" где-то остановится, но чаще случается так, что "метастазы" дорастают до фундамента, а тот, "возбудившись", грузит в память оптом все функции, какие на нем произрастают. Из-за этого выходит, что для того, чтобы воспользоваться всего лишь одной единственной функцией из чужого продукта, приходится инсталлировать его целиком, а то и предварительно запускать его в виде параллельно работающего приложения. С течением времени программные продуты становятся всё жирнее, превращаясь в отдельную экосистему, из которой снаружи ничего полезного не выудишь. А межпрограммный интерфейс мало кто из них официально поддерживает, а если неофициально, то и не догадаешься как. Но даже, если такой интерфейс возможен, то его использование портит реноме своей программы, когда она столь откровенно паразитирует на чужом продукте, а тем более нелицензированном.

На Borland C/C++ 6.0 пока рисую (с помощью TeeChart), а на MSVC приходится без рисунков обходиться. Впрочем, в одном из проектов рисовала на OWLNext (это дальнейшее развитие OWL из Borland C/C++ 5.02), но там довольно примитивные функции - готовых графиков и диаграмм нет. Отсюда и моё любопытство к этой теме - вдруг кто-то уже нашел достойную замену Билдеру.

У меня Windows 7 SP1, но Framework 3.5 по умолчанию на ней не установлен. Кроме того, я совершенно не желаю привязываться к Фреймворку, а тем более переходить на другой язык ради графика.

Так то C#. С поддержкой гигантского Фреймворка можно не то что графики, а и вприсядку плясать :). Такой дорогой ценой график мне не нужен.

Родной билдеровский teechart немного кривоват, но поверх него на тот же Buillder легко ставится более богатая версия teechart'a - 8-ая или выше (у меня 8.03, на которую есть исходники). В реальном времени рисовать графики teechart не годится, т.к. он при каждом обновлении станет перерисовывать всю кривую заново, а то и вместе с осями :). А вот OpenGL - ужасная гадость :), т.к. рисует медленно из-за слишком сложной реализации, а интерефейс крайне неудобный. Тогда как я речь веду не о примитивах, а о законченных решениях, примером которого может быть функция plot() в Matlab. Поиметь бы такую же функцию в MSVC, и больше ничего для счастья не надо :).

Чтобы со всей памятью работать (у меня 32 ГБ). Матрицы большого размера нужны, в 4 ГБ памяти не помещаются.

VS2013 - нормальная среда, не монстроидальная. Да и VS2015 еще терпимая. Тогда как VS2005 и VS2008 - старьё голимое :) , 64-разрядные приложения генерировать неспособное. Но вопрос у меня другой - как под VS разные графики и диаграммы рисовать, которые на Bulder 6.0 делались в пол тычка мышкой? Т.е. всё, что под Билдером делает teechart? Или вы всё GUI на MFC пишите?

Бывает по-разному. Но чаще как правило - CS активен весь передаваемый по SPI кадр. Так это же очевидно! А между кадрами?

Положено на каждый байт дергать :).

Нет, не оговорка. CS тактирует байты, а CLCK - биты. Но можно было бы и к битам счетчик привязать, т.к. их число четко привязано к байтам в отношении 8:1. Я же хотела байты таймером считать, а не биты. На STM32 нельзя - его таймеры логические события не воспринимают - только внешние сигналы. А вот на ATxmega такое можно было бы сделать.

Если обмен данными по SPI организован вами с тактированием слейва по ChipSelect (а иначе случайный пропуск единственного бита приведет к смещению форматного окна), то вы можете эту же линию CS завести на счетный вход одного из таймеров, запрограммировав его считать до 5-ти (ARR=5) и выдавать меандр со скважностью 1:4 (CCR1=4). Тогда на выходе этого таймера в течение 4-х байт будет низкий уровень, а на 5-ом высокий. Это у меня идея такая, а конкретно с нужными вам тактами разбирайтесь сами.

Проще всего это делается через SPI-интерфейс, способный сформировать командную посылку для LC7821 в нужном ей формате. Правда SPI посылает 8 бит (байт), а LC7821 принимает только 4 бита (тетраду), но это не страшно - важно лишь, чтобы последние передаваемые 4 бита были нужными, а лишние проскочат мимо (во входной буфер LC7821 помещаются только 4 последних бита, вытесняя из него все предшествующие). В вашем коде мне разбираться бессмысленно, поскольку схему присоединения LC7821 к ATmega8 вы не публикуете. Но подозреваю, что ваша программа не работает из-за того, что вы лишь добавляете новые биты командой |=, но нигде их не стираете. Предположу, что вместо операции |= где-то должны быть обычные операции присваивания =.

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

Скажите кто-нибудь, какой у GD32F103 загрузчик? На TTL или на USB? А то до сих пор вижу такую безрадостную картину, что USB-loader бывает только у STM32F4 (F2 и F3 не испытывала, т.к. их у меня их нет) и выше, а на STM32F1 только TTL-loader. Тогда как хотелось бы, чтобы и на F1 тоже был USB-loader. И вообще, можно ли USB-loader прошить F1? В смысле, где взять его бинарник, если таковой для F1 существует?

Залила. Лежит тут: /pub/FPGA/_Xilinx_/_ISE+Vivado+Vitis_/Vivado_2021.2/ На 72 GB удовольствие :) P.S. Кто-нибудь может объяснить, отчего такой огромный объём?

Конечно, можно! Только Bootloader надо не чистить, а залить вместо фабричного ардуиновский. Но лично у меня противоположные цели - покупаю ардуино-плату (поскольку сама платы изготавливать не умею), а затем затираю ней Bootloader и использую, как обычную, применяя компилятор IAR с программатором вместо Arduino Studio.

Вижу, что на отечественное "импортозамещение" надежды нет - аналоги импортных МК по ценам неконкуретноспособны. А что скажите про китайскую серию GD32, которая старалась быть похожей на STM32? Правда ли, что они по цоколевке и по программированию взаимозаменяемы? Кто-то пытался ими заменить STM32? https://www.eltech.spb.ru/mikrokontrollery-gigadevice-instrukciya-po-osvoeniyu

А что там с оборудованием от AMD для производства чипов с нормами 130-90 нм, купленного аж 13 лет назад (в 2008 -году)? То, что Ангстрем-Т банкрот, не суть важно, но ведь оборудование не сгноили же? Кому-то ведь оно должно было достаться. Неужели за эти 13 лет дело с мертвой точки так и не сдвинулось? https://habr.com/ru/post/413377/

Перенесла в /pub/BOOKS/DSP/Meyer-Baese U., Digital Signal Processing with Field Programmable Gate Arrays(2014)CD.zip Однако, удивительное дело, - там уже был CD-диск к этой книге, то только 2007-го года издания, причем на порядок большего размера - 414 МБ в zip-архиве, тогда как сейчас в архиве только 36 МБ. Не могли бы вы выяснить, что там пропало за 7 лет?

TM4C123 и TM4C129 плохи тем, что сделали и забыли. Тогда как линия должна развиваться, сохраняя какую-то преемственность. Позитивные примеры - AVR и STM32. Т.е. если даже первый блин комом, по последующие версии становятся всё лучше и лучше.

Бог с ней, с российской электроникой :). Ее недостатки уже и без того достаточно обсосаны в других темах. Тогда как в этой теме осталось совершенно неясным, что могло помешать компании ST производить свои STM32 на фабриках более низкого ранга (там где техпроцесс всё еще крупный). Ведь если STM32 не требуют для своего производства слишком уж передового техпроцесса (STM32 мельче 40 нм не бывает), то очевидно, что и нет необходимости обращаться с этим к TMSC, которая сейчас перегружена заказами. И если спрос на персональные компьютеры в пандемию мог и в самом деле возрасти, то совершенно неясно, с чего бы ему возрасти на микроконтроллеры.

Вроде бы для производства STM32 техпроцесс 65 нм не так уж необходим. В интернете нашла такую информацию: STM32 F3/F4 - 180 нм STM32 F7/G4 - 90 нм STM32 H7 - 40 нм Т.е. аналоги наиболее популярных STM32F0, STM32F1 и STM32F4 отечественная промышленность вполне могла бы выпускать сама. Причем не в урезанном варианте, как это сделал НИИЭТ в своих AVR-клонах (1887ВЕ), а так, как делают китайцы - стараются усовершенствовать то, что копируют. Ну, хотя бы ерраты исправить :). Тогда как у STM32 можно найти многое из того, что исправить было бы не грешно. Например, размножить периферийные регистры на старшие порты. А то на портах PA-PB густо, а на PF-PH пусто.

Это было бы так, если бы они сами микросхемы делали, а не заказывали их на Тайване. А раз делают не сами, то на них общая анафема распространяется - тайваньская фабрика завалена заказами и будет тормозить производство псевдо-отечественных микросхем еще пуще, чем остальных (ибо там более солидные клиенты).

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

Полагаю, что ошибка в том, что в ассемблере этого контроллера нет команды "memcpy".