Всем добрый день.
Признаться, язык С совсем не мой конёк и по этому на первый взгляд глупо мне было влезать в этот блуд. Но...
Задался целью перевести на язык Arduino свою систему. Все прошло удачно, но как говориться "по минималке" тех возможностей, которые давала скорость программы на ассемблере. Причина - уперся в скорость работы встроенных способов чтения данных из памяти, особенно из области Flash.

Порылся в интернете и нашел интересную публикацию по гибридизации Си и Ассемблера. Сделал скетч и ... не компилируется.
Вот ни как не пойму почему. Повторяю, для меня эти программные изыски как Китайский язык - может и красиво, но нифига не понятно.
Может на Arduino IDE не все работает, что работает на AVR студии? А может какую-то глупость написал?

"Ардуина" и "ускорить код" - диаметрально противоположные вещи.
Если уж и ускорять, то писать на С/асме, да даже С++, но без классов и без оверхеда абдуриновского. А еще в абдуриновых "скетчах" многие операции делают блокирующими. Даже в обработке сигнала "сброс" по 1-wire эти олухи вполне могут выставить тупую блокирующую паузу в несколько миллисекунд!!!
В общем, учите С, а потом пишите на нем приличный код. И будет счастье. На асме, конечно, тоже можно приличный код написать, но дюже портянка длиннючая и нечитабельная получится.

Добавлено after 3 minutes 11 seconds:
P.S. А какие ошибки выдает? У меня нет avr-gcc за ненадобностью, так что проверить не могу. В принципе, с первого взгляда все должно собираться, нужно лишь Makefile правильный написать.

Языка Ардуино нет в природе. Ардуино среда использует язык С/С++, но в Ардуине принят общий стиль написания и использование универсальных написанных функций, которые не лучшим образом сказываются на быстродействии. Поэтому ускорять нужно не ассемблером, а отказом от универсальных медленных функций

Да лучше вообще от абдурины отказаться и по-старинке нормально код писать. Там вообще уйма всяких вещей ради универсальности ногодрыгом сделана. Даже UART, 1-wire, SPI, I2C!.. А уж все эти printf и флоаты — я б за это вообще убил! Не удивлюсь, если там даже аллокатор памяти есть…

Так это и есть попытка переписать функцию. Вообще поражаюсь. Спросил мнения почему не работает, а мне советы по использованию языков суют и к терминам придираются. Ну знаете, не тревожьте клаву.

Спрашиваете, почему не работает? Возможно потому что ассемблер очень аппаратно-зависимый язык и требует точного соответствия микроконтроллера. Если знакомы с ассемблером, должны же понимать. Во вторых, напо почитать, как выполняются ассемблерные вставки в Ардуине.
И я ответил, что основная проблема Ардуины не в отсутствии ассемблерных вставок, а в не оптимально универсальном готовом коде. Когда начнёте переписывать на свой лад, от Ардуины останется только язык С/С++ в степени синтаксиса названий, да и то не факт, что не замените обычным Си.

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

С.Н., приведите, какие ошибки выдает gcc в терминале. А то как можно понять, "почему не собирается"?
Ну и неплохо бы содержимое Makefile своего показать, может, у вас асмовский исходник неправильно собирается (хотя, конечно, просто avr-gcc sourse.S -o должно сработать)? Ну и туда еще потом абдуринолибы прилинковать правильно нужно…
Если собираете не по-человечески, а через абдурино-IDE, то проследите, правильно ли у вас там все выставлено (я эту дрянь даже длинной палкой касаться не буду, так что, ничем помочь не могу).

скотчем )

C.H., в файле asmroutine.h
строка 16:

вместо :
word rdindex(byte _ukj);

напишите:
word rdindex(byte _ukj) {};

(будет пустой функцией).

Спасибо, попробую. Ребята, я не Ардуинщик. Опыт работы на Си подобном языке - месяц. Ещё помучаюсь и пошлю этот ногодрыг куда подальше. Мой язык общения с контроллером - ассемблер. Просто хотел убедиться что могу и можно на этом ногодрыге сделать рабочую систему - оказывается можно! А плюшки всякие можно и потерять.

Зачем посылать - надо научиться "готовить".

Да и "гибридизация" ассемблера под Си не есть хорошо для начинающего.
Как вариант - ассемблерные вставки или файлы под GCC, что не совсем то же самое что файлы на avrasm2.

У адуринок, исходя из моего опыта, "ускорение" требуется разве что в случае работы с uLAN и "мудрыми светиками" вида WS2812...
Остальные вопросы вполне решаемы средствами "референса" или незначительными дополнениями из арсенала GCC.

Нет, не "начинающий". Скорее "попробовавший и пославший". Я потерял интерес к этой теме.
Рабочий скетч для ATmega 88/168/328 создан. Жалко, что слишком сильная аппаратная привязка к контроллеру получилась. Если решусь сервисы накручивать, то буду вынужден тратить лишние 1-2 мкс при обращении в Flash. А что такое микросекунда на фоне миллисекунды - Пыль!

А вообще, мне и так достаточно уже синтаксис С мозги подпортил. Как теперь заставить себя писать "a:=2" вместо "a = 2" и { XXXXXX } мозгами игнорировать?

Ну, кому как, кому что больше нравится. Эт вы еще синтаксис С++ в ардуине не полностью осознали Namespace::NameClass::NameFoo(); самое простое из них Хотя помоему в ардуине сложнее этого и не используется в принципе то. По крайней мере, я не видел, чтобы кто-то писал foo = [](){ } Прикольный синтаксис, да? А это не шутка ведь

Да, я иногда в ауте от этих приколов. В моей юности так и говорили - "зтот язык - шутка математиков". Это про С говорили. Про ++ тогда ещё не знали. Кто тогда мог подумать, что так далеко зайдёт.

Да я сам фшоке Взять вот например новомодный нынче язык Питон - всё понятно и ясно. А глянешь на проверенный временем С++ и офигеваешь от тупизьма языка Вот не знаю, если честно, почему и по какой причине С++ взяли за основу для Ардуины. Видимо, её авторам понравился синтаксис имён функций. Потому как навряд ли ардуинщики решают что-либо на уровне объектов в правильном понимании этого явления. По крайней мере, я не встречал, чтобы писатель на ардуине понимал суть именно объектов, а не воспринимал это как синтаксическую форму записи object.Method()

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

"контейнер" на ардуринкин Си/С++ гнать не надо.
Задачи с подсчетом микросекунд штука весьма редкая для МК, работающего на частоте 16 МГц (0,0000000625 S на одноцикловую команду).
Это еще в случае, когда имеем дело со "стандартным минимумом" в 1 МГц имеет существенное значение.
Да разве что при необходимости интервалы в наносекундах стабильно выравнивать (и то не факт - ибо у кварцев также заметные отклонения имеются).
Неуж-то на практике 62,5 наносекунд на одноцикловую команду мало?
Это ж ведь минимум целых 16 одноцикловых команд для Ваших "....лишние 1-2 мкс..."...
Или нужный алгоритм подобрать сложно?

Сложность восприятия Си для привыкшего к ассемблеру - необходимость продумывания порой непривычных алгоритмов.
Зато потом и в работе с ассемблером многое проще/удобнее делать становится.

Я вот только не понял насчет вышевыложенного кода...
Это тест вывода данных на встроенный терминал?
Так там совсем иначе надо делать...

Спойлер

Код:

#include <avr/pgmspace.h> // подключить библиотеку работ с таблицами в ПЗУ



//const PROGMEM word index[]   = {3001, 4802, 6003, 8004, 12005, 24006, 48007,65535}; 
//volatile const word index1[] = {3001, 4800, 6000, 8000, 12000, 24000, 48000,65535}; 
const word index[]PROGMEM = {3001, 4802, 6003, 8004, 12005, 24006, 48007,65535};



volatile word sdd;

void setup() {

 Serial.begin(9600);
 
}

void loop() {



for (byte n=0; n<=7; n++)
 {
  sdd = pgm_read_word_near(index + n);
  Serial.print(F("index"));Serial.print(n,DEC);Serial.print(F(" = "));
  Serial.println(sdd,DEC);
 }
delay(2000);
Serial.println(F("     "));
}

...

Скажу больше. На самом деле считаются даже не такты кварцевого генератора, импульсы гораздо меньших частот 400 кГц-2МГц. Не в этом проблема. Проблема в том, что параллельно с работающей программой, обслуживающей измерительный таймер, есть сигналы входных датчиков, которые следует обрабатывать тем же контролером, и еще вращается металлический маховик, который не хочет ждать пока программа что-то там выдернет из памяти, посчитает, и запишет обратно. И вот пока скетч этим занимается, маховик пролетает уже положение, когда микроконтроллер должен был дать команду на искрообразование. В сухом остатке получается, что разница между временем чтения данных из области Flash и с ОЗУ между программой на ассемблере и скетчем Arduino IDE (обычными массивами и константами) составляет порядка 1 мкс. Таких операций надо сделать десятки во время расчета параметров, да и сам расчет, даже целочисленный требует временных затрат. В итоге на больших оборотах (период = 2-3 мс) маховик успеет уже сместится значительно.
Вообще, написание такого скетча интересная разминка для мозгов. Все должно происходить в нужное время и не мешать другим процессам. Вплоть до того, что специально управлять временем функционирования отдельных узлов программы синхронно с тактами управляемой её железки. Добавьте сюда еще обеспечение работы АЦП (для подключения дополнительных систем регулировок) и работающий одновременно с этим интерфейс UART (телеметрия и управления параметрами), и Вы поймете, что скетчу на Arduino IDE может и не хватить мощности. А вот на ассемблере еще время и остается… Вот и хотел сначала переписать пару функций (по ближе к ассемблеру), дабы вернуть эту микросекунду.

С этим трудно не согласиться.

По коду - так вот эту функцию pgm_read_word_near и хотел переписать.

Оптимальнее, чем это сделает компилятор вряд ли получится.
А вот насчет множества операций на одном МК - это вопрос конкретной схемотехники и организации программ.
МК (по крайней мере "одноядерный") никогда больше одной прожки в единицу времени исполнить не может.
В любом случае это последовательное выполнение нескольких задач. Каким способом такое можно получить - тут простор для творчества (ибо их множество вариантов).
Если уж совсем "крутокосмическое" требование - делаем смешанный проект из базового ядра на адуринке и прикладных периферийных МК (вполне вероятно из разных семейств или на рассыпухе/специализированных микросхемах).
Периферия готовит критичные по времени данные в реальном времени, а адуринка является центром обработки готовых данных и коммуникаций.
Так что... Придется таки поплотнее адуринкой заняться при желании строить сложные самоделки.


Пы. Сы.
Освоение написания качественных автономных файлов и/или ассемблерных вставок для компилятора Си может оказаться гораздо сложнее освоения самого Си.

У меня возникло впечатление, что вышеуказанный пост посвящен попытке решения задач реального времени не предназначенными для этого средствами. Полагаю, что углубленное изучение RTOS, которые вроде как уже прижились в т.ч. и в аматерских 32-разрядных МК STM32 и ESP32, ответит на все поставленные ТС вопросы.

Вам в самом начале дискуссии дали исчерпывающий ответ, но вы почему-то восприняли его в штыки.Разработчики ардуины не дураки, а осознанно пожертвовали производительностью в обмен на унификацию и низкий порог вхождения. Ускорять нужно не там где вы умеете, а там где реально тормозит. Я не скажу, что отказ от ардуины автоматом ускорит ваш код, но хотя бы даст шанс. У вас есть бесспорное преимущество - знание ассемблера. Пишете код, компилируете, смотрите листинг, анализируете где плохо, переписываете или меняете настройки компилятора. Со временем придёт понимание как инструкции языка высокого уровня реализуются в ассемблер и "подглядывать" не придётся.

PS: Чтобы не быть голословным, вот как ваш пример можно без ассемблера сделать. Ссылка на Compiler Explorer. Это лучше, чем вы хотели сделать на асме. И это только оптимизация -O2, а с -O3 ещё быстрее будет.

Спойлер

Вложение:

изображение_2022-12-16_071836120.png [92.41 KiB]
Скачиваний: 179